Chapter 13 - Internet Protocol Security and Packet Filtering

Published: December 27, 2005 | Updated: April 19, 2006

Writer: Joe Davies

Abstract

This chapter describes the support for Internet Protocol security (IPsec) and IP packet filtering in Microsoft® Windows Server™ 2003 and Windows® XP operating systems. IPsec can provide cryptographic protection for IP packet payloads. Packet filtering can specify which types of packets are received or dropped. A network administrator must understand IPsec and packet filtering and its effect on IP network traffic to configure network security and troubleshoot connectivity problems.

For a download of the entire "TCP/IP Fundamentals for Microsoft Windows" online book, which contains a version of this chapter that has been updated for Windows Vista and Windows Server 2008, click here.

On This Page

Chapter Objectives
IPsec and Packet Filtering Overview
IPsec
Packet Filtering
Chapter Summary
Chapter Glossary

Chapter Objectives

After completing this chapter, you will be able to:

• Describe the roles that IPsec and IP packet filtering play in helping to protect network nodes.

• Define IPsec and its uses to block, permit, or help protect IP traffic.

• Define packet filtering and its uses to block or permit IP traffic.

• List and describe the security properties of IPsec-protected traffic.

• Describe the functions of the Authentication Header, Encapsulating Security Payload, and Internet Key Exchange IPsec protocols.

• Distinguish between transport mode and tunnel mode.

• Describe the purposes of main mode and quick mode IPsec negotiations.

• Define an IPsec policy in terms of its general settings and rules.

• List and describe the configuration elements of an IPsec rule.

• Describe Windows Firewall and how you can use it to help protect against malicious users and programs.

• Describe Internet Connection Firewall.

• Describe TCP/IP filtering and its configuration.

• Describe what Basic Firewall does and how Routing and Remote Access can filter IPv4 packets.

• Describe how the basic IPv6 firewall, the IPv6 Internet Connection Firewall, and Windows Firewall filter IPv6 packets.

IPsec and Packet Filtering Overview

The Internet was originally designed for wide-open communications between connected computers. However, today's Internet is a hostile networking environment. Computers on the Internet must protect themselves from malicious users and programs that attempt to disable, control, or improperly access the resources of the computer. Private intranets can also contain malicious users and programs. On either the Internet or a private intranet, sensitive data should be cryptographically protected before being sent to its destination. In some cases, laws require you to cryptographically protect data sent over the network.

To help protect traffic or prevent unwanted traffic, Windows Server 2003 and Windows XP include the following technologies:

• IPsec A framework of open standards for helping ensure private, protected communications over Internet Protocol (IP) networks through the use of cryptographic security services. The Windows XP and Windows Server 2003 implementations of IPsec are based on standards developed by the IPsec working group of the Internet Engineering Task Force (IETF).

• Packet filtering The ability to configure interfaces to accept or discard incoming traffic based on a variety of criteria such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports, source and destination IP addresses, and whether the incoming traffic was sent because the receiving computer requested it.

This chapter describes these two technologies and how Windows Server 2003 and Windows XP support them.

IPsec

The original standards for the TCP/IP protocol suite were not designed to protect IP packets. By default, IP packets are easy to interpret, modify, replay, and forge. Without protection for IP packet payloads, both public and private networks are susceptible to unauthorized monitoring and access. Although internal attacks might result from minimal or nonexistent intranet security, risks from outside a private network stem from connections to both the Internet and extranets. Requiring passwords to access network resources, such as permissions on a shared folder, does not protect data transmitted across a network.

IPsec is the long-term direction for standards-based, protected, IP-based networking. It provides a key line of defense against private network and Internet attacks, balancing ease of deployment with strong security. IPsec has two goals:

1. To protect IP packets

2. To defend against network attacks

Both of these goals are met through the use of cryptography-based protection services, security protocols, and dynamic key management. This foundation provides the strength and flexibility required to help protect communications between private network computers, domains, sites, remote sites, extranets, and dial-up clients. You can further use IPsec to block receipt or transmission of specific traffic types.

IPsec is based on an end-to-end security model. The only computers that must be aware of IPsec are the sending and receiving computers. Each handles security at its respective end and assumes that the medium over which the communication takes place is not protected. Computers that only route data from source to destination are not required to support IPsec, but they are required to forward IPsec traffic.

Security Properties of IPsec-protected Communications

IPsec provides the following security properties to help protect communications:

• Data integrity Helps protect data from unauthorized modification in transit. Data integrity helps ensure that the data received is exactly the same as the data sent. Hash functions authenticate each packet with a cryptographic checksum using a shared, secret key. Only the sender and receiver have the key that is used to calculate the checksum. If the packet contents have changed, the cryptographic checksum verification fails and the receiver discards the packet.

• Data origin authentication Helps verify that the data could have been sent only from a computer that has the shared, secret key. The sender includes a message authentication code with a calculation that includes the shared, secret key. The receiver performs the same calculation and discards the message if the receiver’s calculation does not match the message authentication code that is included in the message. The message authentication code is the same as the cryptographic checksum that is used for data integrity.

• Confidentiality (encryption) Helps ensure that the data is disclosed only to intended recipients. Confidentiality is achieved by encrypting the data before transmission. Encryption ensures that the data cannot be interpreted during its transit across the network, even if a malicious user intercepts and captures the packet. Only the communicating computers with the shared, secret key can easily decrypt the packet contents and determine the original data.

• Anti-replay Helps ensure the uniqueness of each IP packet by placing a sequence number on each packet. Anti-replay is also called replay prevention. Anti-replay helps ensure that a malicious user cannot capture data and reuse or replay it, possibly months later, to establish a session or to gain access to information or other resources.

IPsec Protocols

IPsec provides its security services by wrapping the payload of an IP packet with an additional header or trailer that contains the information to provide data origin authentication, data integrity, data confidentiality, and replay protection. IPsec headers consist of the following:

• Authentication header (AH)

  Provides data authentication, data integrity, and replay protection for an IP packet.

• Encapsulating Security Payload (ESP) header and trailer

  Provides data authentication, data integrity, replay protection, and data confidentiality for an IP packet payload.

The result of applying the AH or the ESP header and trailer to an IP packet transforms the packet into a protected packet.

To negotiate the set of security parameters to help protect the traffic, such as whether to use AH or ESP and what types of encryption and authentication algorithms to use, IPsec peers use the Internet Key Exchange (IKE) protocol.

IPsec Modes

IPsec supports two modes—transport mode and tunnel mode—that describe how the original IP packet is transformed into a protected packet.

Transport Mode

Transport mode protects an IP payload through an AH or an ESP header. Typical IP payloads are TCP segments (which contain a TCP header and TCP segment data), UDP messages (which contain a UDP header and UDP message data), and Internet Control Message Protocol (ICMP) messages (which contain an ICMP header and ICMP message data).

AH in transport mode provides data origin authentication, data integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet, except for fields in the IP header that must change in transit). This type of protection does not provide confidentiality, which means that it does not encrypt the data. The data can be read but not easily modified or impersonated. AH uses keyed hash algorithms for packet integrity.

For example, Computer A sends data to Computer B. The IP header, the AH header, and the IP payload are protected with data integrity and data origin authentication. Computer B can determine that Computer A really sent the packet and that the packet was not modified in transit.

AH is identified in the IP header with an IP protocol ID of 51. You can use AH alone or combine it with ESP.

The AH header contains a Security Parameters Index (SPI) field that IPsec uses in combination with the destination address and the security protocol (AH or ESP) to identify the correct security association (SA) for the communication. IPsec at the receiver uses the SPI value to determine with which SA the packet is identified. To prevent replay attacks, the AH header also contains a Sequence Number field. An Authentication Data field in the AH header contains the integrity check value (ICV), also known as the message authentication code, which is used to verify both data integrity and data origin authentication. The receiver calculates the ICV value and checks it against this value (which is calculated by the sender) to verify integrity. The ICV is calculated over the IP header, the AH header, and the IP payload.

AH authenticates the entire packet for data integrity and data origin authentication, with the exception of some fields in the IP header that might change in transit (for example, the Time to Live and Checksum fields). Figure 13-1 shows the original IP packet and how it is protected with AH in transport mode.

Figure 13-1 A packet protected with AH in transport mode

ESP in transport mode provides confidentiality (in addition to data origin authentication, data integrity, and anti-replay) for an IP packet payload. ESP in transport mode does not authenticate the entire packet. Only the IP payload (not the IP header) is protected. You can use ESP alone or combine it with AH. For example, Computer A sends data to Computer B. The IP payload is encrypted and authenticated. Upon receipt, IPsec verifies data integrity and data origin authentication and then decrypts the payload.

ESP is identified in the IP header with the IP protocol ID of 50 and consists of an ESP header that is placed before the IP payload, and an ESP and authentication data trailer that is placed after the IP payload.

Like the AH header, the ESP header contains SPI and Sequence Number fields. The Authentication Data field in the ESP trailer is used for message authentication and integrity for the ESP header, the payload data, and the ESP trailer.

Figure 13-2 shows the original IP packet and how it is protected with ESP. The authenticated portion of the packet indicates where the packet has been protected for data integrity and data origin authentication. The encrypted portion of the packet indicates what information is confidential.

Figure 13-2 A packet protected with ESP in transport mode

The IP header is not authenticated and is not protected from modification. To provide data integrity and data origin authentication for the IP header, use ESP and AH.

Tunnel Mode

Tunnel mode helps protect an entire IP packet by treating it as an AH or ESP payload. With tunnel mode, an IP packet is encapsulated with an AH or an ESP header and an additional IP header. The IP addresses of the outer IP header are the tunnel endpoints, and the IP addresses of the encapsulated IP header are the original source and final destination addresses.

As Figure 13-3 shows, AH tunnel mode encapsulates an IP packet with an AH and an IP header and authenticates the entire packet for data integrity and data origin authentication.

Figure 13-3 A packet protected with AH in tunnel mode

As Figure 13-4 shows, ESP tunnel mode encapsulates an IP packet with both an ESP and IP header and an ESP authentication trailer.

Figure 13-4 A packet protected with ESP in tunnel mode

Because a new header for tunneling is added to the packet, everything that comes after the ESP header is authenticated (except for the ESP Authentication Data field) because it is now encapsulated in the tunneled packet. The original header is placed after the ESP header. The entire packet is appended with an ESP trailer before encryption occurs. Everything that follows the ESP header is encrypted, including the original header that is now part of the data portion of the packet but not including the ESP authentication data field.

The entire ESP payload is then encapsulated within a new IP header, which is not encrypted. The information in the new IP header is used only to route the packet to the tunnel endpoint.

If the packet is being sent across a public network, the packet is routed to the IP address of the tunnel server for the receiving intranet. In most cases, the packet is destined for an intranet computer. The tunnel server decrypts the packet, discards the ESP header, and uses the original IP header to route the packet to the destination intranet computer.

In tunnel mode, you can combine ESP with AH, providing both confidentiality for the tunneled IP packet and data integrity and data origin authentication for the entire packet.

Negotiation Phases

Before two computers can exchange protected data, they must establish a contract. In this contract, called a security association (SA), both computers agree on how to protect information. An SA is the combination of a negotiated encryption key, security protocol, and SPI, which together define the security used to protect the communication from sender to receiver. The SPI is a unique, identifying value in the SA that is used to distinguish among multiple SAs that exist at the receiving computer.

For example, multiple SAs might exist if a computer using IPsec protection is communicating with multiple computers at the same time. This situation occurs frequently when the computer is a file server or a remote access server that serves multiple clients. In these situations, the receiving computer uses the SPI to determine which SA the computer should use to process the incoming packets.

To build this contract between the two computers, the IETF has defined IKE as the standard method of SA and key determination. IKE does the following:

• Centralizes SA management, reducing connection time.

• Generates and manages shared, secret keys that help protect the information.

This process not only helps protect communication between computers, it also helps protect remote computers that request protected access to a corporate network. In addition, this process works whenever a security gateway performs the negotiation for the final destination computer.

Phase I or Main Mode Negotiation

To help ensure successful and protected communication, IKE performs a two-phase operation. IKE helps ensure confidentiality and authentication during each phase by using encryption and authentication algorithms that the two computers agree on during security negotiations. With the duties split between two phases, keys can be created rapidly.

During the first phase, the two computers establish a protected, authenticated channel. This phase is called the phase I SA or main mode SA. IKE automatically protects the identities of the two computers during this exchange.

A main mode negotiation consists of the following steps:

1. Policy negotiation

   The following four mandatory parameters are negotiated as part of the main mode SA:

   • The encryption algorithm (for the Windows implementation of IPsec: Data Encryption Standard [DES] or Triple-DES [3DES])

   • The hash algorithm (for the Windows implementation of IPsec: Message Digest 5 Hashed Message Authentication Code [MD5-HMAC] or Secure Hash Algorithm 1-HMAC [SHA1-HMAC])

   • The authentication method (for the Windows implementation of IPsec: Kerberos V5, Certificate, or preshared key authentication)

   • The Diffie-Hellman (DH) group to be used for the base keying material

2. DH exchange

   At no time do the two computers exchange actual keys. The computers exchange only the base information that the DH key determination algorithm requires to generate the shared, secret key. After this exchange, the IKE service on each computer generates the master key that the computers use for subsequent communications.

3. Authentication

   The computers attempt to authenticate the DH key exchange. A DH key exchange without authentication is vulnerable to a man-in-the-middle attack. A man-in-the-middle attack occurs when a computer masquerades as the endpoint between two communicating peers. Without successful authentication, communication cannot proceed. The communicating peers use the master key, in conjunction with the negotiation algorithms and methods, to authenticate identities. The communicating peers hash and encrypt the entire identity payload (including the identity type, port, and protocol) using the keys generated from the DH exchange in the second step. The identity payload, regardless of which authentication method is used, is protected from both modification and interpretation.

The initiator offers a potential SA to the receiver. The responder cannot modify the offer. Should the offer be modified, the initiator rejects the responder's message. The responder sends either a reply accepting the offer or a reply with alternatives.

Phase II or Quick Mode Negotiation

In this phase, the IPsec peers negotiate the SAs to protect the actual data sent between them. A quick mode negotiation consists of the following steps:

1. Policy negotiation occurs.

   The IPsec peers exchange the following requirements to protect the data transfer:

   • The IPsec protocol (AH or ESP)

   • The hash algorithm (MD5-HMAC or SHA1-HMAC)

   • The encryption algorithm, if requested (DES or 3DES)

   The computers reach a common agreement and establish two SAs. One SA is for inbound communication, and the other is for outbound communication.

2. Session key material is refreshed or exchanged.

   IKE refreshes the keying material, and new shared keys are generated for data integrity, data origin authentication, and encryption (if negotiated). If rekeying is required, either a second DH exchange (as described in main mode negotiation) occurs, or a refresh of the original DH key is used.

The main mode SA helps protect the quick mode negotiation of security settings and keying material (for the purpose of securing data). The first phase helped protect the computers’ identities, and the second phase helps protect the keying material by refreshing it before sending data. IKE can accommodate a key exchange payload for an additional DH exchange if a rekey is necessary. Otherwise, IKE refreshes the keying material from the DH exchange completed in main mode.

IPsec Policy Settings

An IPsec policy consists of the following:

• General IPsec policy settings

  Settings that apply regardless of which rules are configured. These settings determine the name of the policy, its description for administrative purposes, main mode key exchange settings, and main mode key exchange methods.

• Rules

  One or more IPsec rules that determine which types of traffic IPsec must examine, how traffic is treated (permitted, blocked, or protected), how to authenticate an IPsec peer, and other settings.

IPsec policies can be applied to local computers, domains, sites, or organizational units on any Group Policy object in the Active Directory® directory service. Your IPsec policies should be based on your organization's written guidelines for protected traffic. Policies can store multiple rules, so one policy can govern multiple types of traffic.

IPsec policies can be stored in two locations:

• Active Directory

  IPsec policies that are stored in Active Directory are part of Computer Configuration Group Policy settings and are downloaded to an Active Directory domain member when it joins the domain and on an ongoing basis. The Active Directory-based policy settings are locally cached. If the computer has downloaded such policy settings but is not connected to a network that contains a trusted Microsoft Windows 2000 or Windows Server 2003 domain controller, IPsec uses the locally cached Active Directory IPsec policy settings.

• Local

  Local IPsec policies are defined in the local computer's Computer Configuration Group Policy for stand-alone computers and computers that are not always members of a trusted Windows 2000 or Windows Server 2003 domain.

Windows Server 2003 and Windows XP include default policies that you can use as examples for your own custom policies.

General IPsec Policy Settings

You configure the general settings for an IPsec policy in the Group Policy snap-in (under Computer Configuration-Windows Settings-Security Settings-IP Security Policies) by right-clicking an IPsec policy, clicking Properties, clicking the General tab, and configuring the following:

• Name The name for the policy.

• Description Optional text that describes the purpose of the IPsec policy. You should type a description to summarize the settings and rules for the policy.

• Policy change poll interval The number of minutes between consecutive polls for changes in IPsec policies that are based on Active Directory. This polling does not detect changes in domain or organizational unit membership or the assigning or unassigning of a new policy. These events are detected when the Winlogon service polls for changes in Group Policy, which occurs by default every 90 minutes.

Figure 13-5 shows the General tab for the default Server (Request Security) IPsec policy.

Figure 13-5 The General tab of the properties of an IPsec policy

By clicking Settings, you can configure the following:

• Key exchange settings

  The way in which new keys are derived and how often they are renewed.

• Key exchange methods

  The ways in which identities are protected during the key exchange.

The default key exchange settings and methods are configured to work for most IPsec deployments. Unless you have special security requirements, you should not need to change these default settings.

Figure 13-6 shows the Key Exchange Settings dialog box for the default Server (Request Security) IPsec policy.

Figure 13-6 The Key Exchange Settings dialog box

Rules

An IPsec policy consists of one or more rules that determine IPsec behavior. You configure IPsec rules on the Rules tab in the properties of an IPsec policy. For each IPsec rule, you can configure the following items:

• Filter list

  You specify a single filter list that contains one or more predefined packet filters that describe the types of traffic to which the configured filter action for this rule is applied.

• Filter action

  You specify a single filter action that includes the type of action required (permit, block, or secure) for packets that match the filter list. For the secure filter action, the negotiation data contains one or more security methods that are used (in order of preference) during IKE negotiations and other IPsec settings. Each security method determines the security protocol (such as AH or ESP), the specific cryptographic algorithms, and the settings for regenerating session keys used.

• Authentication methods

  You configure one or more authentication methods (in order of preference) for authenticating IPsec peers during main mode negotiations. You can specify the Kerberos V5 protocol, use of a certificate issued from a specified certification authority, or a preshared key.

• Tunnel endpoint

  You can specify whether the traffic is using tunnel mode and, if so, the IP address of the tunnel endpoint. For outbound traffic, the tunnel endpoint is the IP address of the IPsec tunnel peer. For inbound traffic, the tunnel endpoint is a local IP address.

• Connection type

  You can specify whether the rule applies to local area network (LAN) connections, dial-up connections, or both.

Figure 13-7 shows the properties of a rule for the default Server (Request Security) IPsec policy.

Figure 13-7 Properties of an IPsec rule

The rules for a policy appear in reverse alphabetical order based on the name of the filter list selected for each rule. You cannot specify an order in which to apply the rules in a policy. The Windows implementation of IPsec automatically derives a set of IPsec filters that specify IP traffic and the action that IPsec has been configured to take for the traffic. IPsec filters are ordered based on the most specific to the least specific IP traffic. For example, an IPsec filter that specifies individual IP addresses and TCP ports is ordered before an IPsec filter that specifies all addresses on a subnet.

Default Response Rule

The default response rule, which can be used for all policies, has the IP filter list of <Dynamic> and the filter action of Default Response when the list of rules is viewed with IP Security Policies. You cannot delete the default response rule, but you can deactivate it. It is activated for all of the default policies, and you can enable it when you create IPsec policies.

The default response rule ensures that the computer responds to requests for protected communication. If an active policy does not have a rule defined for a computer that is requesting protected communication, the default response rule is applied, and protection is negotiated. For example, the default response rule is used when Computer A communicates with protection with Computer B and Computer B does not have an inbound filter defined for Computer A.

You can configure authentication methods and the connection type for the default response rule. The filter list of <Dynamic> indicates that the filter list is not configured, but filters are created automatically when IKE negotiation packets are received. The filter action of Default Response indicates that you cannot configure the action of the filter (permit, block, or negotiate security). However, you can configure:

• The security methods and their preference order. To configure these settings, obtain properties on the IPsec policy, click the Rules tab, click the default response rule, click Edit, and then click the Security Methods tab.

• The authentication methods and their preference order. To configure these settings, click the default response rule, click Edit, and click the Authentication Methods tab.

Filter List

An IP filter list triggers a filter action based on a match with the source, destination, and type of IP traffic. This type of IP packet filtering enables a network administrator to precisely define what IP traffic to allow, block, or protect. Each IP filter list contains one or more filters, which define IP addresses and traffic types. You can use one IP filter list for multiple types of IP traffic.

For protected packets, IPsec requires you to configure both an inbound and outbound filter between the computers specified in the filter list. Inbound filters apply to incoming traffic, enabling the receiving computer to respond to requests for protected communication or to match traffic against the IP filter list. Outbound filters apply to traffic leaving a computer toward a destination, triggering a security negotiation that takes place before traffic is sent. For example, if Computer A wants to exchange protected data with Computer B:

• The active IPsec policy on Computer A must have a filter that specifies any outbound packets to Computer B.

• The active IPsec policy on Computer A must have a filter that specifies any inbound packets from Computer B.

Each peer must also have the reverse filter. For example:

• The active IPsec policy on Computer B must have a filter that specifies any inbound packets from Computer A.

• The active IPsec policy on Computer B must have a filter that specifies any outbound packets to Computer A.

Filter Settings

Each filter defines a particular subset of inbound or outbound network traffic. You must have a filter to cover any traffic to which the associated rule applies. A filter can contain the following settings:

• The source and destination address of the IP packet. You can configure any IP address assigned to the IPsec peer, a single IP address, IP addresses by DNS name, or address ranges to specify IP subnets.

• The protocol over which the packet is being transferred. This setting by default covers all protocols in the TCP/IP protocol suite. However, you can configure the filter for an individual protocol to meet special requirements, including custom protocols.

• For TCP and UDP, the source and destination port of the protocol. By default, all TCP and UDP ports are covered, but you can configure the filter to apply to only a specific TCP or UDP port.

Figure 13-8 shows the All ICMP Traffic filter list for the default Server (Request Security) IPsec policy.

Figure 13-8 An example IP filter list

Filter Action

A filter action defines how the Windows implementation of IPsec must treat IP traffic. Figure 13-9 shows the Require Security filter action for the default Server (Request Security) IPsec policy.

Figure 13-9 An IPsec filter action

You can configure a filter action to:

• Permit traffic (the Permit setting)

  The Windows implementation of IPsec forwards the traffic without modification or protection. This setting is appropriate for traffic from specific computers that cannot support IPsec.

• Block traffic (the Block setting)

  IPsec silently discards this traffic.

• Negotiate IPsec (the Negotiate Security setting)

  IPsec requires the sender and receiver to negotiate SAs and to send and receive IPsec-protected traffic. After you choose to negotiate IPsec, you can also do the following:

  • Specify security methods and their order

  • Allow initial incoming unprotected traffic (the Accept unsecured communication, but always respond using IPsec setting)

    If you configure this setting, IPsec allows an incoming packet that matches the configured filter list to be unprotected by IPsec. However, the outgoing response to the incoming packet must be protected. This behavior is also known as inbound pass-through.

    This setting is useful when you are using the default response rule for clients. For example, a group of servers are configured with a rule that protects communications with any IP address, accepts communication that is not protected, and responds with only protected communications. To ensure that the clients will respond to the server request to negotiate security, you must enable the default response rule on client computers.

  • Enable communication with computers on which IPsec is not enabled (the Allow unsecured communication with non-IPsec-aware computer setting)

    If you configure this setting, IPsec falls back to unprotected communication, if necessary. This behavior is known as fallback to clear.

    You can use this setting to allow communication with computers that cannot initiate IPsec, such as computers running Microsoft operating systems older than Windows 2000.

  • Generate session keys from new keying material (the Session key perfect forward secrecy (PFS) setting)

    This setting determines whether a new session key can be derived from existing material for keying a master key determined from a main mode negotiation. By enabling session key PFS, you ensure that master key keying material cannot be used to derive more than one session key. When session key PFS is enabled, a new Diffie-Hellman key exchange is performed to generate new master key keying material before the new session key is created. Session key PFS does not require main mode reauthentication and uses fewer resources than master key PFS.

IPsec Security Methods

Each security method defines the security requirements of any communications to which the associated rule applies. By creating multiple security methods, you increase the chance that a common method can be found between two computers. The IKE component reads the list of security methods in descending order and sends a list of allowed security methods to the other peer. The first method in common is selected. Typically, the methods with the most cryptographic strength are at the top of the list and the methods with the least cryptographic strength are at the bottom of the list.

The following security methods are predefined:

• Encryption and integrity Uses ESP to provide data confidentiality (encryption) with 3DES, data integrity and data origin authentication with SHA1, and default key lifetimes (100MB, 1 hour). If you require both data and addressing (IP header) protection, you can create a custom security method. If you do not require encryption, you can use Integrity only.

• Integrity only Uses ESP to provide data integrity and authentication with SHA1 and default key lifetimes (100MB, 1 hour). In this configuration, ESP does not provide data confidentiality (encryption). This method is appropriate when your security plan calls for standard levels of security.

Figure 13-10 shows the New Security Method tab, which appears when you add a security method to a filter action.

Figure 13-10 The New Security Method tab

Custom Security Methods

If the predefined Encryption and integrity or Integrity only settings do not meet your security requirements, you can specify custom security methods. For example, you can use custom methods to specify encryption and address integrity, stronger algorithms, or key lifetimes.

When you configure a custom security method, you can specify the following:

• Security protocols

  You can enable both AH and ESP in a custom security method when you require IP header integrity and data encryption. If you chose to enable both, you do not need to specify an integrity algorithm for ESP. The algorithm that you select for AH provides integrity.

• Integrity algorithm

  • MD5

  • SHA1, which is a stronger hash than MD5 and complies with the Federal Information Processing Standard (FIPS). Microsoft recommends using SHA1 over MD5.

• Encryption algorithm

  • DES

  • 3DES, which is much stronger than DES. Microsoft recommends using 3DES over DES.

• Session key settings

  Session key settings determine when a new key is generated, rather than how it is generated. You can specify a lifetime in kilobytes, seconds, or both. For example, if the communication takes 10,000 seconds and you specify the key lifetime as 1000 seconds, 10 keys will be generated to complete the transfer. This approach ensures that, even if an attacker manages to determine one session key and decipher part of a communication, deciphering the entire communication is not possible. By default, new session keys are generated for every 100 MB of data transferred or every hour.

Figure 13-11 shows the Custom Security Method Settings dialog box, which appears when you add a custom security method to a filter action.

Figure 13-11 The Custom Security Methods dialog box

Authentication

Each IPsec rule defines a list of authentication methods. Each authentication method defines the requirements for how identities are verified in protected communications to which the associated rule applies. The two peers must have at least one authentication method in common or communication will fail. By creating multiple authentication methods, you increase the chance that the two computers can find a common method.

Only one authentication method can be used between a pair of computers, regardless of how many you configure. If you have multiple rules that apply to the same pair of computers, you must configure the authentication methods lists in those rules to enable the pair to use the same method. For example, authentication will fail if a rule between a pair of computers specifies only Kerberos for authentication and filters only TCP data and another rule specifies only certificates for authentication and filters only UDP data.

IPsec supports the following authentication methods:

• Kerberos V5 The Kerberos V5 security protocol is the default authentication method for clients that are running the Kerberos V5 protocol and that are members of the same or trusted Active Directory domains.

  Kerberos V5 authentication is not supported on computers running Windows XP Home Edition or computers running any other Windows 2000, Windows XP, or Windows Server 2003 operating system that are not members of an Active Directory domain.

• Public key certificate You should use a public key certificate in situations that include Internet access, access to corporate resources from remote locations, communications with external business partners, or computers that do not run the Kerberos V5 security protocol. This method requires you to obtain certificates from at least one trusted certification authority (CA). Computers running Windows Server 2003, Windows XP, or Windows 2000 support X.509 Version 3 certificates, including certificates generated by commercial CAs.

• Preshared key This method involves a shared, secret key similar to a password. It is simple to use and does not require the client to run the Kerberos V5 protocol or have a public key certificate. Both parties must manually configure IPsec to use this preshared key. Preshared key is a simple method for authenticating computers that are not running Windows Server 2003, Windows XP, or Windows 2000; stand-alone computers; or any computers that are not using the Kerberos V5 protocol. This key is for peer authentication protection only and is not used to protect the data sent between IPsec peers.

Tunnel Endpoint

IPsec tunnels help protect entire IP packets. You configure the tunnel to help protect traffic between either two IP addresses or two IP subnets. If you configure the tunnel between two computers instead of two routers (also known as gateways), the IP address outside the AH or ESP payload is the same as the IP address inside the AH or ESP payload.

IPsec can perform layer 3 tunneling for scenarios in which Layer Two Tunneling Protocol (L2TP) cannot be used. You do not need to configure a tunnel if you are using L2TP for remote communications because the client and server virtual private networking (VPN) components of Windows XP automatically create the appropriate rules to protect L2TP traffic.

To create a layer 3 tunnel using IPsec, use IP Security Policies or Group Policy to configure and enable the following two rules for the appropriate policy:

1. A rule for outbound traffic through the tunnel.

   You configure the rule for outbound traffic with both a filter list, which describes the traffic to be sent across the tunnel, and a tunnel endpoint, which is an IP address assigned to the IPsec tunnel peer (the computer or router on the other side of the tunnel).

2. A rule for inbound traffic through the tunnel.

   You configure the rule for inbound traffic with both a filter list, which describes the traffic to be received across the tunnel, and a tunnel endpoint, which is a local IP address (the computer or router on this side of the tunnel).

For each rule, you must also specify filter actions, authentication methods, and other settings.

Connection Type

For each IPsec rule, you must define to which connection types on your computer the rule will apply. The connection types include all connections in Network Connections on the computer for which you are configuring IPsec policy.

Each rule has one connection type setting:

• All Network Connections The rule applies to communications sent through any network connection that you have configured on the computer.

• Local Area Network (LAN) The rule applies only to communications sent through LAN connections that you have configured on the computer.

• Remote Access The rule applies only to communications sent through any remote access or dial-up connections that you have configured on the computer.

IPsec for IPv6 Traffic

The IPv6 protocol for Windows Server 2003 and Windows XP:

• Supports AH in transport or tunnel mode using MD5 or SHA1 and ESP in transport or tunnel mode using the NULL ESP header and MD5 or SHA1. IPv6 does not support ESP data encryption.

• Is separate from—and not interoperable with—IPsec for the IPv4 protocol. IPsec policies that are configured with IP Security Policies or Group Policy have no effect on IPv6 traffic.

• Does not support the use of IKE to negotiate SAs. You must use the Ipsec6.exe tool to manually configure IPsec policies, SAs, and encryption keys. For more information, see Help and Support in Windows XP or Windows Server 2003.

Packet Filtering

In addition to using IPsec filter actions to perform packet filtering, computers running Windows Server 2003 or Windows XP also support the following packet filtering features:

• Windows Firewall

• Internet Connection Firewall

• TCP/IP filtering

On computers running Windows Server 2003 with Routing and Remote Access, you can also use the following:

• IP packet filtering

• Basic Firewall

Windows Firewall

A firewall is a protective boundary between a computer or network and the outside world. Windows Firewall is a stateful host firewall for IPv4 and IPv6 traffic in Windows XP with Service Pack 2 (SP2) and in Windows Server 2003 with Service Pack 1 (SP1). This feature allows incoming traffic only if it is either solicited (sent in response to a request of the computer) or excepted (unsolicited traffic that has been specified as allowable). Windows Firewall provides a level of protection from malicious users and programs that use unsolicited traffic to attack computers. With the exception of some Internet Control Message Protocol (ICMP) messages, Windows Firewall allows all outgoing traffic.

Windows Firewall is designed for use on all network connections, including those that are accessible from the Internet, connected to small office/home office networks, or connected to private organization networks. An organization network's firewall, proxy, and other security systems provide some level of protection from the Internet to intranet network computers. However, the absence of host firewalls such as Windows Firewall on intranet connections leaves computers vulnerable to malicious programs brought onto the intranet by mobile computers.

For example, an employee connects an organization laptop to a home network that does not have adequate protections. Because the organization laptop does not have a host firewall enabled on its network connection, the laptop gets infected with a malicious program (such as a virus or worm) that uses unsolicited traffic to spread to other computers. The employee then brings the infected laptop back to the office and connects it to the organization intranet, effectively bypassing the security systems that are at the edge of the intranet. While connected to the intranet, the malicious program begins to infect other computers. If Windows Firewall were enabled by default, the laptop computer might not get infected with the malicious program when connected to the home network. Even if the laptop computer did get infected, the local intranet computers might not become infected when the laptop computer connected to the intranet, because they also have Windows Firewall enabled.

If the computers running Windows XP with SP2 or Windows Server 2003 with SP1 are running client-based programs, enabling Windows Firewall does not impair communications. Web access, e-mail, Group Policy, and management agents that request updates from a management server are examples of client-based programs. For client-based programs, the client computer always initiates the communication, and the firewall allows all response traffic from a server because it is solicited incoming traffic.

In Windows XP with SP2, Windows Firewall is enabled by default on all network connections. You can configure exceptions from the Windows Firewall item in Control Panel, which you can run from Windows Security Center, which also was introduced in SP2. In Windows Server 2003 with SP1, Windows Firewall is disabled by default. Figure 13-12 shows the Windows Firewall dialog box that was introduced in Windows XP with SP2.

Figure 13-12 The Windows Firewall dialog box in Windows XP with SP2

The Windows Firewall dialog box has the following tabs:

• The General tab, from which you can enable, enable but do not allow any exceptions, or disable Windows Firewall.

• The Exceptions tab, from which you can specify exceptions for allowed incoming traffic. You can specify these exceptions by TCP or UDP port or by program name.

• The Advanced tab, from which you can enable and disable Windows Firewall on individual interfaces, configure advanced settings on individual interfaces, and configure logging and ICMP options.

How Windows Firewall Works

Windows Firewall is a stateful, host-based firewall for incoming traffic. Windows Firewall performs a different purpose from that of a router-based firewall, which is deployed at a boundary between a private network and the Internet. A router-based firewall protects traffic that is sent to the router as an intermediate stop between the traffic’s source and its destination. Windows Firewall, on the other hand, acts as a firewall for traffic that is destined for the same computer on which Windows Firewall is running.

Windows Firewall operates according to the following process:

• Windows Firewall inspects each incoming packet and compares it to a list of allowed traffic. If the packet matches an entry in the list, Windows Firewall passes the packet to the TCP/IP protocol for further processing. If the packet does not match an entry in the list, Windows Firewall silently discards the packet and, if logging is enabled, creates an entry in the Windows Firewall logging file.

You specify traffic in the exceptions list using IP addresses, TCP ports, and UDP ports. You cannot specify traffic based on the IP Protocol field in the IP header.

The list of allowed traffic is populated in two ways:

• When the connection on which Windows Firewall is enabled sends a packet, Windows Firewall creates an entry in the list so that any response to the traffic will be allowed. The response traffic is incoming solicited traffic.

  For example, if a host sends a Domain Name System (DNS) Name Query Request message to a DNS server, Windows Firewall adds an entry so that, when the DNS server sends a DNS Name Query Response message, it can be passed to the TCP/IP protocol for further processing. This behavior makes the Windows Firewall a stateful firewall because it maintains state information about the traffic initiated by the local computer so that the corresponding incoming response traffic will be allowed.

• When you configure Windows Firewall to allow exceptions, the excepted traffic is added to the list. This capability allows a computer using Windows Firewall to accept unsolicited incoming traffic when acting as a server, a listener, or a peer.

  For example, if your computer is acting as a Web server, you must configure Windows Firewall to allow Web traffic so that the local computer can respond to requests from Web clients. You can configure exceptions based on programs or on TCP or UDP ports. For program-based exceptions, Windows Firewall automatically adds ports to the exceptions list when requested by the program and when it is running and removes them when requested by the program or when the program stops running. For port-based exceptions, the ports are opened whether the application or service using them is running or not.

Internet Connection Firewall (ICF)

ICF, a stateful host firewall for IPv4 traffic, is provided in Windows XP with no service packs installed, Windows XP with SP1, and Windows Server 2003 with no service packs installed. You should enable ICF on the Internet connection of any computer that is running one of these operating systems and connected directly to the Internet.

When ICF has been enabled on a network connection, the network connection icon in Network Connections appears with a lock and a status of Enabled, Firewalled. Figure 13-13 shows an example in which ICF is enabled on a network connection named Internet.

Figure 13-13 Example of a connection in Network Connections on which ICF has been enabled

You can manually enable ICF from the Network Connections folder by doing the following:

1. Click Start, click Control Panel, click Network and Internet Connections, and then click Network Connections.

2. Right-click the network connection that is connected to the Internet, and then click Properties.

3. On the Advanced tab, select the Protect My Computer And Network By Limiting Or Preventing Access To This Computer From The Internet check box.

4. Click OK to save changes to your connection.

You can perform advanced configuration of ICF by clicking Settings on the Advanced tab in the properties dialog box of a network connection. Figure 13-14 shows the Advanced Settings dialog box for ICF.

Figure 13-14 The Advanced Settings dialog box for configuring ICF

The Advanced Settings dialog box has the following tabs:

• The Services tab, from which you can configure service definitions to allow excepted traffic.

• The Security Logging tab, from which you can configure options for the firewall log file. By default, the firewall log file is named Pfirewall.log and stored in your main Windows folder.

• The ICMP tab, from which you can specify the types of incoming ICMP messages that ICF allows. ICMP messages are used for diagnostics, reporting error conditions, and configuration. By default, no ICMP messages are allowed.

TCP/IP Filtering

TCP/IP for Windows Server 2003 and Windows XP supports TCP/IP filtering, which you can use to specify exactly which types of incoming IP traffic destined for a computer are processed for each IP interface. Incoming IP traffic destined for a computer, also known as local host or locally destined traffic, includes all packets sent to a unicast address assigned to the interface, any of the different kinds of IP broadcast addresses, and IP multicast addresses to which the host is listening. This feature isolates the traffic that Internet and intranet servers process in the absence of other TCP/IP filtering provided by Routing and Remote Access or other TCP/IP applications or services. TCP/IP filtering is disabled by default.

You can use a single check box to enable or disable TCP/IP filtering for all adapters. This approach can help troubleshoot connectivity problems that might be related to filtering. Filters that are too restrictive might not allow expected kinds of connectivity. For example, if you specify a list of UDP ports and do not include UDP port 520, your computer will not receive Routing Information Protocol (RIP) announcements. This limitation can impair the computer's ability to be a RIP router or a silent RIP host when using the RIP Listener service.

A packet is accepted for processing if it meets any of the following criteria:

• The destination TCP port matches the list of TCP ports. By default, traffic to all TCP ports are permitted.

• The destination UDP port matches the list of UDP ports. By default, traffic to all UDP ports are permitted.

• The IP protocol matches the list of IP protocols. By default, all IP protocols are permitted.

• The packet is an ICMP packet.

You cannot filter ICMP traffic with TCP/IP filtering. If you need ICMP filtering, you must configure IP packet filters through Routing and Remote Access.

To configure TCP/IP filtering on a network connection, do the following:

1. Click Start, click Control Panel, and then double-click Network Connections.

2. Right-click the network connection you want to configure, and then click Properties.

3. On the General tab (for a local area connection) or the Networking tab (for all other connections), click Internet Protocol (TCP/IP), and then click Properties.

4. Click Advanced.

5. Click Options, click TCP/IP Filtering, and then click Properties.

6. Do one of the following:

   • To enable TCP/IP filtering for all adapters, select the Enable TCP/IP filtering (all adapters) check box.

   • To disable TCP/IP filtering for all adapters, clear the Enable TCP/IP filtering (all adapters) check box.

7. Based on your requirements for TCP/IP filtering, configure TCP ports, UDP ports, or IP protocols for the allowed traffic.

Figure 13-15 shows the TCP/IP Filtering dialog box.

Figure 13-15 The TCP/IP Filtering dialog box

Packet Filtering with Routing and Remote Access

Using Routing and Remote Access, you can filter IPv4-based traffic in two ways:

• Basic Firewall

  Basic Firewall, which you enable through the NAT/Basic Firewall routing protocol component, is a stateful firewall that, like ICF, automatically discards unsolicited incoming IPv4 packets.

• IP packet filters

  By using IP packet filters, you can specify the exact set of IPv4 packets that are either allowed or discarded. Packet filters affect both incoming and outgoing packets on a per-interface basis.

Basic Firewall

You can use Basic Firewall to help protect your network from unsolicited public network traffic, such as traffic sent from the Internet. You can enable Basic Firewall for any public interface, including one that also provides network address translation for your network.

To enable Basic Firewall on a public interface, do the following:

1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Routing and Remote Access.

2. In the tree, open the name of your server, then click IP Routing, and then click NAT/Basic Firewall.

3. In the details pane, right-click the interface you want to configure, and then click Properties.

4. On the NAT/Basic Firewall tab, do one of the following:

   • Click Public interface connected to the Internet, and select the Enable a basic firewall on this interface check box.

   • Click Basic firewall only.

Figure 13-16 shows the Network Address Translation Properties dialog box.

Figure 13-16 The Network Address Translation Properties dialog box

IP Packet Filtering

By using IP packet filtering in Routing and Remote Access, you can precisely define what IPv4 traffic is received and sent. To use IP packet filtering, you must create a series of definitions called filters, which define for the router what types of traffic to allow or discard on each interface. You can set filters for incoming and outgoing traffic.

• Input filters define what incoming traffic on that interface the router is allowed to forward or process.

• Output filters define what traffic the router is allowed to forward or send from that interface.

Because you can configure both input and output filters for each interface, you can also create contradictory filters. For example, the input filter on one interface might allow the incoming traffic, but the output filter on the other interface does not allow the same traffic to be sent. The end result is that the traffic is not passed across the router running Windows Server 2003.

You can also implement packet filtering to filter incoming and outgoing traffic to a specific subset of traffic on a computer that is running Windows Server 2003 but that is not configured as a router.

You should implement packet filters carefully to prevent the filters from being too restrictive, which would impair the functionality of other protocols that might be operating on the computer. For example, if a computer running Windows Server 2003 is also running Internet Information Services (IIS) as a Web server and packet filters are defined so that only Web-based traffic is allowed, you cannot use the ping command (which uses ICMP Echo and Echo Reply messages) to perform basic IP troubleshooting. If the Web server is a silent RIP host, the filters prevent the silent RIP process from receiving the RIP announcements.

To configure IP packet filters on an interface, do the following:

1. Click Start, click Control Panel, double-click Administrative Tools, and then double-click Routing and Remote Access.

2. In the tree, open the name of your server, then click IP Routing, and then click General.

3. In the details pane, right-click the interface on which you want to add a filter, and then click Properties.

4. On the General tab, click Inbound Filters to configure filters for incoming traffic to the interface or Outbound Filters to configure filters for outgoing traffic from the interface.

Figure 13-17 shows an example of adding an IP packet filter.

Figure 13-17 The Add IP Filter dialog box

You can configure the following settings on an IP packet filter:

• You can specify the IP Protocol, which is the identifier for an upper layer protocol. For example, TCP uses a Protocol of 6, UDP uses a Protocol of 17, and ICMP uses a Protocol of 1.

• You can specify the Source IP Address, which is the IP address of the source host. You can configure this address with a subnet mask to specify an entire range of IP addresses (corresponding to an IP subnet or address prefix) with a single filter entry.

• You can specify the Destination IP Address, which is the IP address of the destination host. You can configure this address with a subnet mask to specify an entire range of IP addresses (corresponding to an IP subnet or address prefix) with a single filter entry

• For TCP traffic, you can specify the values for two fields: the TCP Source Port field, which identifies the source process that is sending the TCP segment, and the TCP Destination Port, which identifies the destination process for the TCP segment.

• For UDP traffic, you can specify the values for two fields: the UDP Source Port field, which identifies the source process that is sending the UDP message and the UDP Destination Port, which identifies the destination process for the UDP message.

• For ICMP traffic, you can specify the values for two fields: the ICMP Type field, which identifies the type of ICMP packet (such as Echo or Echo Reply) and the ICMP Code field, which identifies one of the possible multiple functions within a specified type. If only one function exists within a type, the Code field is set to 0.

IPv6 Packet Filtering

You can perform packet filtering for IPv6 traffic with the following:

• Basic IPv6 firewall

• IPv6 ICF

• Windows Firewall

Basic IPv6 Firewall

IPv6 for Windows Server 2003 with no service packs installed includes support for a basic firewall on IPv6 interfaces. When enabled, IPv6 drops incoming TCP Synchronize (SYN) segments and drops all incoming unsolicited UDP messages. This firewall is disabled by default on all interfaces and can be enabled with the netsh interface ipv6 set interface interface= NameOrIndex firewall=enabled command. The basic IPv6 firewall is not related to the Basic Firewall feature of Routing and Remote Access.

IPv6 ICF

The Advanced Networking Pack for Windows XP is a free download available from Microsoft for computers running Windows XP with SP1. This download includes IPv6 ICF, which is a stateful IPv6 firewall. You can use IPv6 ICF to dynamically restrict traffic allowed from the Internet. IPv6 ICF is different from the existing ICF in Windows XP, which filters IPv4 traffic. IPv6 ICF does the following:

• Runs automatically and filters traffic through all network connections on which IPv6 is enabled.

• Monitors all outbound traffic and dynamically filters for incoming response traffic. This behavior is known as stateful filtering. IPv6 ICF silently discards all unsolicited incoming traffic.

• Logs IPv6 traffic events to a separate log file (from IPv4 ICF). By default, this log file is located at: Systemroot\Pfirewall-v6.log).

You can configure IPv6 ICF by using commands in the netsh firewall context. You can use Netsh commands to configure IPv6 ICF to allow specific types of ICMPv6 traffic or traffic to specific TCP or UDP ports.

Windows Firewall

Windows Firewall in Windows XP with SP2 and Windows Server 2003 with SP1 supports IPv6 traffic and replaces both the basic IPv6 firewall and IPv6 ICF. IPv4 and IPv6 traffic share settings for excepted traffic. For example, if you allow file and print sharing traffic, then both IPv4-based and IPv6-based unsolicited incoming file and print sharing traffic is allowed.

Chapter Summary

The chapter includes the following pieces of key information:

• Internet Protocol security (IPsec) is a framework of open standards for helping ensure private, protected communications over IP networks. You can use IPsec in Windows Server 2003 and Windows XP to block, permit, or cryptographically protect IP traffic.

• IPsec provides data integrity, confidentiality (encryption), data origin authentication, and anti-replay security properties for IP-based communications.

• IPsec can help protect traffic through the use of AH (which provides data origin authentication, data integrity, and replay protection for an IP packet), ESP (which provides data origin authentication, data integrity, replay protection, and data confidentiality for the ESP-encapsulated portion of the packet), or AH with ESP.

• IPsec can use transport mode, in which the original IP header is used, or tunnel mode, in which the entire IP packet is encapsulated with a new IP header.

• IPsec uses main mode negotiation to determine encryption key material and to authenticate IPsec peers. IPsec uses quick mode negotiation to determine how to protect the traffic sent between peers.

• An IPsec policy consists of general IPsec policy settings and rules.

• For each rule of an IPsec policy, you must configure a single filter list, a single filter action, one or more authentication methods, a tunnel endpoint (if you are using IPsec tunnel mode), and the connection type.

• IPsec support for IPv6 traffic in Windows XP and Windows Server 2003 does not support ESP data encryption and must be manually configured using the Ipsec6.exe tool.

• Windows Firewall is a stateful IPv4 and IPv6 firewall in Windows XP with SP2 and Windows Server 2003 with SP1. Windows Firewall drops unsolicited incoming traffic that has not been explicitly allowed.

• ICF is a stateful IPv4 firewall provided with Windows XP with no service packs installed, Windows XP with SP1, and Windows Server 2003 with no service packs installed.

• Basic Firewall is a feature of Routing and Remote Access that functions as a stateful IPv4 firewall for public interfaces.

• By using IP packet filtering in Routing and Remote Access, you can specify the exact set of IPv4 traffic that is either allowed or discarded for both incoming and outgoing packets on a per-interface basis.

• By using TCP/IP filtering, you can specify exactly which types of incoming IPv4 traffic destined for a computer are processed for each interface.

• You can perform IPv6 packet filtering with the basic IPv6 firewall, IPv6 ICF, and Windows Firewall.

For additional resources about IPsec in Windows Server 2003 and Windows XP, see the Microsoft IPsec Web page.

Chapter Glossary

AH – See Authentication Header.

Authentication Header – A header that is placed between the IP header and the payload and that provides data integrity, data origin authentication, and anti-replay security services.

Basic Firewall – A feature of Routing and Remote Access that functions as a stateful IPv4 firewall for public interfaces.

Encapsulating Security Payload – A header and trailer that is placed around an IP packet payload and that provides confidentiality (encryption), data integrity, data origin authentication, and anti-replay security services.

ESP – See Encapsulating Security Payload.

ICF – See Internet Connection Firewall.

IKE – See Internet Key Exchange.

Internet Connection Firewall – A stateful firewall built into Windows XP with no service packs, Windows XP with SP1, and Windows Server 2003 with no service packs.

Internet Key Exchange – A protocol for authentication and key exchange between IPsec peers.

IP filter – A description of network traffic can include source address, source mask, destination address, destination mask, protocol, source port, and destination port.

IP packet filtering – A capability of Routing and Remote Access that you can use to specify the exact set of IPv4 traffic that is either allowed or discarded for both incoming and outgoing packets on a per-interface basis.

IPsec policy – A collection of rules and settings that you create to specify IPsec services.

Rule – A list of IP filters and a collection of security actions that occur when a packet matches a filter.

SA – See security association.

security association (SA) – A combination of a mutually agreeable policy and keys that defines the security services, mechanisms, and keys used to help protect communication between peers. A main mode SA helps protect one or more quick mode negotiations. A quick mode SA helps protect the traffic that it carries in one direction between IPsec peers.

Security Parameters Index (SPI) – A unique, identifying value in an SA that distinguishes among multiple security associations that exist at the receiving computer. For example, IPsec communication between two computers uses two SAs on each computer. One SA is for inbound traffic, and the other is for outbound traffic. Because the source and destination addresses for the two SAs are the same, the SPI distinguishes between the inbound and outbound SA.

SPI – See Security Parameters Index.

TCP/IP filtering – A capability of the Internet Protocol (TCP/IP) component of Windows Server 2003 and Windows XP that you can use to specify exactly which types of incoming locally destined IPv4 traffic is processed for each interface.

Windows Firewall – A stateful IPv4 and IPv6 firewall built into Windows XP with SP2 and Windows Server 2003 with SP1.