Determining Your IPSec Needs

The first step in deploying IPSec on your network is to determine which computers need to be secured. Some data on your network might need higher levels of security than others. Although adding IPSec can protect your network and data, it can also reduce performance, and some computers might not support IPSec. As shown in Figure 6.2, you must decide which data and which computers on your network you need to secure and at what level of security.

Figure 6.2: Determining Your IPSec Needs

When beginning your design process, make sure to have specifications about your current network environment available for use. Your hardware and software inventory and a map of network topology are essential tools for the design phase. Because IPSec policies are based on which computers and data you want to secure, where that data is stored within the network, and the operating systems you need to support, this information lets you know where you can deploy IPSec. For more information about creating those documents, see "Planning for Deployment" in Planning, Testing, and Piloting Deployment Projects of this kit.

Some network environments are well suited to IPSec as a security solution and others are not. This section lists some common examples.

Recommended IPSec Uses

IPSec is recommended for the following uses:

• Packet filtering. IPSec provides limited firewall capabilities for end systems. You can use IPSec with the NAT/Basic Firewall component of the Routing and Remote Access service to permit or block inbound or outbound traffic. You can also use IPSec with ICF, which provides stateful filtering. However, to ensure proper IKE management of IPSec security associations (SAs), you must configure ICF to permit ISAKMP UDP port 500 traffic.

• Securing host-to-host traffic on specific paths. You can use IPSec to provide protection for traffic between servers or other static IP addresses or subnets. For example, IPSec can secure traffic between domain controllers in different sites or between Web servers and database servers.

• Securing traffic to servers. You can require IPSec protection for all client computers that access a server. In addition, you can set restrictions on which computers are allowed to connect to a server running Windows Server 2003.

• L2TP/IPSec for VPN connections. You can use the combination of the L2TP and IPSec (L2TP/IPSec) for all VPN scenarios. This does not require the configuration and deployment of IPSec policies.

• Site-to-site (gateway-to-gateway) tunneling. You can use IPSec in tunnel mode for site-to-site (gateway-to-gateway) tunnels when you need interoperability with third-party routers, gateways, or end systems that do not support L2TP/IPSec or Point-to-Point Tunneling Protocol (PPTP) connections.

Note

Because IPSec depends on IP addresses for establishing secure connections, you cannot specify dynamic IP addresses. It is often necessary for a server to have a static IP address in IPSec policy filters. In large network deployments and in some mobile user cases, using dynamic IP addresses at both ends of the connection can increase the complexity of IPSec policy design.

IPSec Uses That Are Not Recommended

IPSec can reduce processing performance and increase network bandwidth consumption. Additionally, IPSec policies can be quite complex to configure and manage. Finally, the use of IPSec can introduce application compatibility issues. For these reasons, IPSec is not recommended for the following uses:

• Securing communication between domain members and their domain controllers. In addition to reduced network performance, using IPSec for this scenario is not recommended because of the complexity of the IPSec policy configuration and management required.

• Securing all traffic in a network. In addition to reduced network performance, using IPSec for this scenario is not recommended because:

  • IPSec cannot negotiate security for multicast and broadcast traffic.

  • Traffic from real-time communications, applications that require Internet Control Message Protocol (ICMP), and peer-to-peer applications might be incompatible with IPSec.

  • Network management functions that must inspect the TCP, UDP, and protocol headers are less effective or cannot function at all, due to IPSec encapsulation or encryption of IP payloads.

Additionally, the IPSec protocol and implementation have characteristics that require special consideration in the following scenarios:

• Securing traffic over wireless 802.11 networks. You can use IPSec transport mode to protect traffic sent over 802.11 networks. However, IPSec is not the recommended solution for providing security for corporate 802.11 wireless LAN networks. Instead, it is recommended that you use 802.11 Wired Equivalent Privacy (WEP) encryption and IEEE 802.1X authentication. Support for IPSec, configuration management, and trust are required on client computers and servers. Because many computers on a network do not support IPSec or are not managed, it is not appropriate to use IPSec alone to protect all 802.11 corporate wireless LAN traffic. Additionally, IPSec tunnel mode policies are not optimized for mobile clients with dynamic IP addresses, nor does IPSec tunnel mode support dynamic address assignment or user authentication, which is needed for remote access VPN scenarios. To secure remote access traffic to organization networks when that traffic is sent over public wireless networks that are connected to the Internet, use L2TP/IPSec VPN connections.

• Using IPSec in tunnel mode for remote access VPN connections. Using IPSec in tunnel mode is not recommended for remote access VPN scenarios. Instead, use L2TP/IPSec or PPTP for remote access VPN connections.

Using IPSec in Transport Mode

Table 6.2 provides a summary of when IPSec transport mode is appropriate to use.

Table 6.2: IPSec Transport Mode Uses

IPSec Scenario	IPSec Transport Mode Usage
Require packet filtering	Although IPSec does not provide full firewall functionality, it can be used to statically permit or block traffic based on source and destination address combinations, and based on the IP protocol and TCP and UDP ports. Some of the functions found in standard firewalls that IPSec does not provide include stateful inspection, application protocol awareness, intrusion inspection, and packet logging. Although IPSec lacks some features of firewalls, the packet blocking and filtering it provides can be effective in limiting the spread of viruses or in thwarting specific attacks known to use specific ports. It can also be used to prevent specific applications and services from being used on the network.
Require end-to- end security	This is the easiest way to secure traffic with IPSec, typically between servers or clients and servers. End-to-end security creates a secure channel for trustworthy communication.

You can also combine these two IPSec methods to enhance the network-level security of your infrastructure. Both methods are detailed later in this chapter.

IPSec Packet Filtering

You can use Windows Server 2003 IPSec to secure specific servers in your enterprise. IPSec can be configured to permit or block specific types of traffic based on source and destination address combinations and specific protocols and specific ports. You can use this feature of IPSec to block well-known ports of software so that even if a server is infected, it cannot be used to infect other computers or allow access via the well-known port.

For example, nearly all the systems illustrated in Figure 6.3 can benefit from packet filtering to restrict communication to only specific addresses and ports.

Figure 6.3: Filtering Packets by Using IPSec

By blocking communication to specific ports of a server, it is more difficult for an intruder to access the server or for the server to be used to attack other computers. You can strengthen security by using IPSec filtering to control exactly the type of communication that is allowed between systems. For example, as illustrated in Figure 6.3:

• The internal network domain administrator can assign a domain-based IPSec policy to block all traffic from the perimeter network.

• A perimeter network domain administrator can assign a domain-based IPSec policy to block all traffic to the internal network.

• The administrator of the computer running Microsoft SQL Server™ on the internal network can create an exception to the domain-based IPSec policy to permit SQL protocol traffic to the Web application server on the perimeter network.

• The administrator of the Web application server on the perimeter network can create an exception to the domain-based policy to permit SQL traffic to the computer running SQL Server on the internal network.

• The administrator of the Web application server on the perimeter network can also block all traffic from the Internet, except requests to TCP port 80 (HTTP) and TCP port 443 (SSL), which are used by Web services. This provides additional security against traffic allowed in from the Internet in case the firewall was mis-configured or compromised by an attacker.

• The domain administrator can block all traffic to the management computer, but allow traffic to the perimeter network.

You can also use IPSec with the NAT/Basic Firewall component of the Routing and Remote Access service or IP packet filtering to enhance IPSec permit or block filtering of inbound or outbound traffic.

End-to-End Security

IPSec end-to-end security establishes trust and security from a unicast source IP address to a unicast destination IP address (peer-to-peer). You can use this IPSec capability for secured server scenarios in which only trusted computers are allowed access to a server. In secured server scenarios, you can use IPSec to control access to all applications and services running on the server, and then either encrypt or only simply authenticate all application network traffic. The computers (IPSec peers) are authenticated through the use of Kerberos V5, certificate-based public key authentication, or — only if necessary — preshared key authentication.

Peer-to-Peer Communication

As shown in Figure 6.4, only the sending and receiving computers need to be aware of IPSec. Each handles security at its respective end and assumes that the medium over which the communication takes place is not secure. The two computers can be located near each other, as on a single network segment, or across the Internet. Computers or network elements that route data from source to destination are not required to support IPSec. A firewall between IPSec peers must be configured to forward IPSec traffic on UDP source and destination port 500, IP protocol 50 (ESP), or IP protocol 51 (AH). If network address translation is taking place between two computers, they must both support IETF IPSec NAT-T specification draft version 2. A firewall must be configured to forward traffic on UDP source and destination port 4500.

Figure 6.4: Peer-to-Peer Security in IPSec

End-to-end security is typically used to secure data sent over connections that transmit sensitive data or that might be susceptible to eavesdropping, such as:

• Servers within a corporate network.

• Servers over the Internet. For example, end-to-end security can secure traffic used by business-to-business application systems, protect file and database content as it is distributed to your business partners, or encrypt Remote Authentication Dial-In User Service (RADIUS) traffic between RADIUS clients, proxies, and servers.

• Front-end servers in a data center or perimeter network and servers inside the corporate internal network. There are two methods for securing data in this scenario:

  • End-to-end IPSec transport protection of traffic between the servers. Use IPSec to guarantee authenticity and unmodified traffic between servers, other computers using static IP addresses, or subnets. For example, IPSec can secure traffic between domain controllers, between routers connecting remote sites or forests, or between Web servers and database servers. You can use encryption if the traffic does not require inspection by an intrusion detection system between the servers.

  • End-to-gateway IPSec protection of traffic, so that the traffic is secured with IPSec, but can be fully inspected or modified by a firewall. Depending on the gateway, you can use IPSec transport mode or IPSec tunnel mode.

For any VPN scenarios, you can use the combination of L2TP and IPSec (L2TP/IPSec). For compatibility with other routers and gateways, or end-systems that do not support L2TP/IPSec or PPTP connections, you can use IPSec in tunnel mode for site-to-site (gateway-to-gateway) tunnels.

Securing an Application Server

Figure 6.5 shows end-to-end IPSec in transport mode securing an application server.

Figure 6.5: Using IPSec to Secure an Application Server

In this scenario, an application server in an internal corporate network must communicate with clients running Windows 2000 or Windows XP Professional; a WINS server, DNS server, and DHCP server; Active Directory domain controllers; and a third-party data backup server. Typically, an administrator uses Group Policy to configure and assign an Active Directory-based IPSec policy to an application server. In this scenario, the IPSec policy specifies that traffic is secured or permitted for different data paths, as described below.

Secured traffic

The users on the client computers are company employees who access the application server to view their personal payroll information and performance review scores. Because the traffic between these clients and the application server involves highly sensitive data, and because the administrator wants the server to only communicate with other domain members, he or she uses an IPSec policy that requires ESP encryption and communication only with trusted computers in the Active Directory domain.

Additionally, in Windows Server 2003, a specific group of computers can be authorized to use IPSec when either Kerberos V5 or certificates are used for IKE authentication. This capability is known as certificate-to-account mapping. When IPSec certificate-to-account mapping is used, an administrator can control which computers are authorized to use IPSec by configuring Group Policy security settings and assigning either the Access this computer from the network or the Deny access to this computer from the network logon right to individual or multiple computers, as needed. For more information, see "Public Key Certificate" later in this chapter.

Permitted traffic

Traffic is permitted for the following data paths:

• Traffic between the WINS server, DNS server, DHCP server, and the application server is permitted because WINS servers, DNS servers, and DHCP servers must typically communicate with computers that run on a wide range of operating systems, some of which might not support IPSec.

• Traffic between Active Directory domain controllers and the application server is permitted, because using IPSec to secure communication between domain members and their domain controllers is not a recommended usage due to the complexity of the IPSec policy configuration and management required in Active Directory.

• Traffic between the third-party data backup server and the application server is permitted because the third-party backup server does not support IPSec.

Example: Contoso's Use of End-to-End Security

The fictitious Contoso Corporation implemented a mix of IPSec solutions to meet its end-to-end security needs. Using IPSec end-to-end security makes sense for Contoso because it has branches throughout the world that need to securely exchange data; messages need to pass securely and smoothly across the Internet. Also, Contoso might need to prevent network access to its servers from attackers who might penetrate their network, either through the perimeter network or by directly using a network port in any Contoso office.

Contoso considered using IPSec end-to-end security on all communications, but quickly realized that this was unnecessary and instead chose to authenticate network access to a select set of computers, and to encrypt only its most sensitive communications. Contoso uses IPSec on traffic sent between the following computers or locations:

• Servers within their network, such as between their Distributed File System (DFS) shares and all clients. Contoso used Kerberos authentication for these connections.

• Contoso headquarters servers and partner sites at which Contoso products are manufactured. In the case of the partner connections, Contoso also restricted which partner computers can connect to their corporate network. In this case, Contoso used public key certificate authentication because they shared common root certification authorities (CAs) with their partners. Their partners obtained computer certificates from third-party PKI providers. Contoso allowed only IPSec traffic to pass through the firewall when communicating with partner networks. Contoso mapped computer certificates for partner networks to a shadow computer account in Active Directory, and specified that only computer accounts from the partner networks were allowed IPSec access to their servers. To do this, they configured the Access this computer from the network logon right on each of their servers and assigned this right to computer accounts in the partner networks.

• Web server access to the data center database on cluster servers. Contoso used certificate authentication to enable IPSec-protected connections because the Web servers did not have a security domain trust with the data center cluster servers. The IPSec policy on the data center servers allowed only inbound SQL traffic from the Web servers. To allow IPSec-protected access to Web servers that are managed by a contractor and that do not run the Windows operating system, Contoso used preshared key authentication.

By protecting these connections, Contoso protected high-value communications that were critical to their business success. If they had failed to properly protect order information, competitors might have gained valuable data, or orders might have been canceled or modified by attackers.

Using IPSec in Tunnel Mode

Tunnel mode is primarily used for interoperability with gateways or end systems that do not support L2TP/IPSec or PPTP VPN site-to-site connections. Table 6.3 provides a summary of scenarios in which IPSec tunnel mode is appropriate to use.

Table 6.3: IPSec Tunnel Mode Usage

IPSec Scenario	IPSec Tunnel Mode Usage
Establish gateway-to-gateway tunnels between sites, when the gateways or end systems do not support L2TP/IPSec VPN connections.	Use only when necessary for interoperability with gateways or end systems that do not support L2TP/IPSec VPN connections. When L2TP/IPSec VPN connections are supported, use L2TP/IPSec (IPSec transport mode) instead. When IPSec in tunnel mode is used for gateway-to-gateway tunnels, static IP addresses are required for the IPSec tunnel endpoints. For an illustration of this scenario, see Figure 6.6.
Protect traffic end-to-end, but one end point of the communication does not support IPSec.	Use an IPSec tunnel from one endpoint to a firewall or IPSec-enabled router nearest to the endpoint that does not support IPSec. This scenario requires static IP addresses for both tunnel endpoints. For an illustration of this scenario, see Figure 6.7.
Encrypt traffic end-to-end between two computers, but a third-party firewall or network intrusion detection system requires that traffic be decrypted.	Use one IPSec tunnel to reach the third-party firewall or the network intrusion detection system. Use another tunnel from the third-party firewall or network intrusion detection system to reach the destination. This scenario requires static IP addresses for all four tunnel endpoints. For an illustration of this scenario, see Figure 6.8.

Figure 6.6: Gateway-to-Gateway Tunneling Between Sites

Figure 6.7: One Endpoint Does Not Support IPSec

Figure 6.8: Traffic Must Be Decrypted for Third-Party Firewall Inspection

Gateway-to-Gateway Traffic Must be Secured

In this scenario, traffic is being sent between a client computer in a vendor site (Site A) and a File Transfer Protocol (FTP) server at the corporate headquarters site (Site B). Although an FTP server is used for this scenario, the traffic can be any unicast IP traffic. The vendor uses a third-party gateway, while corporate headquarters uses a gateway running Windows Server 2003. An IPSec tunnel is used to secure traffic between the third-party gateway and the gateway running Windows Server 2003. Figure 6.6 shows IPSec in tunnel mode for gateway-to-gateway tunneling between sites.

Note

For ease of deployment, it is recommended that the gateway running Windows Server 2003 be a stand-alone computer and that you remotely manage this computer by using Remote Desktop Connection. If this computer is joined to a domain, the computer must be able to access Active Directory locally, not through an IPSec tunnel.

One Endpoint Does Not Support IPSec

In this scenario, an IPSec tunnel is used to secure traffic between a computer running Windows Server 2003 in a perimeter network and an IPSec-enabled router (for example, a Cisco IOS router). Traffic on the path between the router and the third-party server in the internal corporate network is not secured, because the third-party server does not support IPSec. Note that this is not a VPN remote access scenario, because there is no dynamic address assignment, nor is user authentication used to establish the tunnel. The tunnel rules can be defined to protect traffic between the computer running Windows Server 2003 and either the internal network subnet or the specific IP address of the third-party server. Figure 6.7 shows IPSec in tunnel mode to provide end-to-end security of traffic when one endpoint of the communication does not support IPSec.

Traffic Must Be Decrypted for Third-Party Firewall Inspection

In many cases, IPSec transport mode can provide secure end-to-end communication through firewalls. If traffic must be inspected at the firewall, you can use IPSec AH or ESP with null encryption in transport mode to maintain end-to-end security. However, if the traffic must be encrypted and inspected, you can use IPSec tunnel mode to secure traffic to the inspection point.

Figure 6.8 shows IPSec in tunnel mode encrypting traffic end-to-end between two computers: a line of business (LOB) application server running Windows Server 2003 in a perimeter network, and a computer running SQL Server that functions as a data store for the application server in an internal corporate network.

In this scenario, IPSec tunnels are used to secure traffic between the application server and the third-party firewall's external interface and between the third-party firewall's internal interface and the computer running SQL Server. Traffic is decrypted for firewall inspection and then reencrypted when it is forwarded to the IPSec peer. The tunnel rules can be defined to protect traffic between the application server and either the internal network subnet or the specific IP address of the computer running SQL Server.

Note

This scenario cannot work if a computer running Microsoft Internet Security and Acceleration (ISA) Server is used as the firewall. Use IPsec transport mode on the side where the ISA interface IP address is being used as the source or destination IP address.

For more information about using IPSec in tunnel mode, including detailed configuration procedures, see article Q252735, "How to Configure IPSec Tunneling in Windows 2000," in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Weighing IPSec Tradeoffs

Whether you use packet filtering or end-to-end security, deploying IPSec provides greater security at the expense of network and processing performance and compatibility with other services, tools, and features. Use the information in this section to determine the impact on your environment before deploying IPSec.

For example, you might decide that information sent between some departments, such as Accounting and Legal, require higher security than information sent to or from other departments, such as Production. You might also decide that all private information transmitted across the Internet must be secured. Finally, you might decide that you only want trusted computers to have network access to your servers. When planning your deployment, be aware that deploying IPSec on your network increases the overall cost of network and system administration. The exact cost cannot be predicted because it depends on many factors, including the level of application traffic. However, if you stage IPSec deployment in a lab, you can arrive at a good estimate. Do not deploy IPSec if the security it provides is not required. Consider whether the added cost is worth the added protection.

Slower connection establishment

IPSec is not recommended for scenarios in which clients make infrequent, short-lived connections. IPSec increases the time required to initially establish authenticated connections. Depending on policy design, network roundtrip time, and the load on the systems required to establish the connection, negotiating security initially using IKE typically increases connection time by one to three seconds. Make sure that you want to trade the one- to three-second increase in connection time for the added security. Typically, after IPSec SAs are established, no further delays occur. Because IPSec is not integrated with TCP, TCP connections can be established and ended rapidly after IPSec SAs are established.

Reduced computing performance

Although the Windows Server 2003 IPSec filtering engine is enhanced to provide significantly faster packet processing, filtering and encryption of each packet consumes computing power. As the volume of IPSec traffic — including policies, rules, and filters — increases, the load placed on the network and on computer CPUs increases also. For example, policies with 1,000 or more filters can cause a small load increase. Filters with specific source and destination IP addresses can be processed much more quickly than filters that specify a subnet or Any IP Address. IPSec implements a cache algorithm that can accelerate the processing of packets that match a filter. Packets that do not match any filter require the greatest amount of time to process.

If your systems already have high loads on their CPUs, consider adding more computers or using IPSec offload network adapters before deploying IPSec. IPSec offload network adapters accelerate cryptographic operations used to secure IPSec packets. However, these adapters do not accelerate filter processing time. IPSec-enabled network adapters can be used with Windows 2000, Windows XP, and Windows Server 2003. Such network adapters typically complete IPSec operations at such a high rate that there is minimal change in transmission speeds, resulting in minimal performance degradation. However, such adapters generally have a maximum number of SAs that they can support, after which additional SAs are processed by the Windows IPSec components.

Thwarting some networking inspection technologies

ESP and AH encapsulate IP payloads by adding a security header to every packet. Existing network management and diagnostic tools typically cannot interpret IPSec-protected packets. The tools that might be impacted include:

• Router-based access control lists.

• Firewall access controls.

• Network traffic analysis and reporting tools.

• Quality of Service (QoS).

• Third-party load balancing devices. Windows Server 2003 IPSec supports the Windows Server 2003 Network Load Balancing service for host-based load balancing, which might provide an alternate solution.

• Network address translation. Windows Server 2003 supports IPSec NAT-T, which is used to allow IPSec ESP-protected traffic to traverse one or more network address translators.

• Stateful filtering controls on the direction of traffic flow. IKE and IPSec communication typically function best when traffic flows in both directions. IPSec does not easily allow for connections in only one direction.

• Network-based intrusion detection.

These functions require that network packets be inspected, modified, or both. If IPSec protocols are not used to encrypt packets, these functions can be enhanced to inspect inside the IPSec protocol header. If IPSec encryption is required for security, however, it might be difficult to maintain full network management functionality.

Increased packet size reduces throughput, increases network utilization

IPSec protection adds overhead to IP packets, reducing effective throughput and increasing network utilization. Although the IETF design and Microsoft implementation of IPSec attempt to minimize both impacts, existing networks and servers might be operating at maximum capacity without IPSec. Before deploying IPSec, test several different IPSec policy configurations, because each policy configuration is likely to result in different performance impacts on clients and servers. It might be necessary to increase the available network bandwidth or CPU power, or install IPSec offload adapters to compensate for the increased overhead of IPSec.

Application incompatibility with IPSec NAT-T

Windows Server 2003 supports IPSec NAT-T as described by version 2 of the IPSec NAT-T Internet drafts, but some applications might not work when their traffic is first protected with IPSec and then passed through a network address translator. Test how your planned implementation of IPSec interacts with network address translators in a lab before deploying IPSec in your environment.

Loss of connectivity during cluster node addition or removal

IPSec establishes and maintains cryptographic state between computers. Many clustering and load-balancing services use the same IP address for all nodes in a cluster, which creates incompatibilities with IPSec. Windows Server 2003 IPSec has proprietary extensions that allow it to work with the Windows Server 2003 Network Load Balancing service and Windows Cluster Service. However, support for these extensions does not exist in the current Windows 2000 and Windows XP IPSec client implementations, so you might experience some loss of connectivity when you add or remove cluster nodes.

Requiring IPSec for communication between Active Directory domain members and domain controllers might block connections

IPSec is based on the authentication of computers on a network; therefore, before a computer can send IPSec-protected data, it must be authenticated. The Active Directory security domain provides this authentication using the Kerberos protocol. Accordingly, when IKE uses Kerberos to authenticate, the Kerberos protocol and other dependent protocols (DNS, UDP LDAP and ICMP) are used for communication with domain controllers. Additionally, Active Directory-based IPSec policy settings are typically applied to domain members through Group Policy. As a result, if IPSec is required from domain members to the domain controllers, authentication traffic will be blocked and IPSec communications will fail. In addition, no other authenticated connections can be made using other protocols, and no IPSec other policy settings can be applied to that domain member through Group Policy. For these reasons, using IPSec for communications between domain members and domain controllers is not supported.

ICMP-based functionality might fail

When designing an IPSec policy to secure or block ICMP traffic, keep in mind that such a policy might cause services and tools that rely on ICMP to measure network response times to produce misleading results. For example, Windows 2000 and Windows XP domain members have an IP/DNS-compatible locator, which measures ICMP response times for domain controller load balancing within a site. Also, Group Policy measures ICMP response times to determine if the connection to the domain controller is a slow link. Also, tools that depend on ICMP, such as Tracert, might not work when ICMP traffic is protected by IPSec.

Multicast and broadcast traffic might fail

In Windows Server 2003, you can configure IPSec filters to block multicast and broadcast traffic. Therefore, any application that uses multicast or broadcast might fail if the computer has an IPSec policy that blocks such traffic.

Examples: IPSec in a Corporate Network

The fictitious Contoso Corporation evaluated their security needs when considering whether to implement IPSec. Although there are many tools to counter threats in a computing environment, this example focuses on security concerns and solutions that relate to IPSec. To begin this process, administrators created a map of the hardware and software in their environment. Notable aspects of an environment include domain membership, operating system versions, computer roles, and the location of computers on the network.

Some computers have relatively low security needs or are very difficult to manage. Although it might be advantageous to secure all data, using IPSec demands administrative resources on both the client side and the server side of the communication. Accordingly, using ICF and anti-virus tools protects computers that are difficult to manage or that have relatively low security needs. Contoso relied on firewall functionality provided by a perimeter network, and a proxy server for Internet access from their internal network. Contoso specified a default client configuration consisting of computers running Windows 2000 and Windows XP. Client computers are configured as follows:

• The client computers and users have accounts in the corporate Active Directory security domain. An enterprise CA is installed on a server running Windows Server 2003, to provide automatic certificate enrollment for user and computers.

• An antivirus program is used to examine all incoming and outgoing files and e-mail.

• Encrypting File System (EFS) encrypts sensitive documents on the client computers' hard disk.

• Services and applications use Kerberos authentication when it is available.

• All domain members are assigned Group Policy settings that do the following:

  • Automatically enroll with the CA to obtain a computer certificate. This certificate can be used to gain remote access to the corporate network when the computer is connected to the Internet for L2TP/IPsec client VPN connections. It is also used for IPSec when Kerberos authentication is not available.

  • ICF is enabled by default for all network connections on portable computers running Windows XP. However, domain administrators disable ICF on portable computers when those computers are connected to the corporate network. ICF is disabled so that users on can share files and allow inbound access to other applications on their desktop.

  • Enforce an IPSec policy to negotiate security with specific IPSec-protected servers and to block ports that are used by known viruses and prohibited applications.

Three examples of how Contoso used IPSec on their servers are as follows:

• The Contoso IT group used a set of servers to receive order information from customers, and decided that they needed to ensure that the orders were received only from their partners and were not modified in transit. Because data authenticity and integrity were important, but confidentiality was not, they required AH protection for customers to connect with these computers. IPSec ESP with null encryption was allowed for customers that must traverse a network address translator to make the IPSec-protected connection to Contoso. Contoso allowed customers to use certificates from a specific list of third-party PKI providers (public PKI root CAs).

• The Contoso Human Resources department stored information about employee salaries and medical claims. The department carefully controlled access with user security settings. But it was also necessary to meet health care regulations to maintain the privacy of this traffic as it flowed over the network. Further, Contoso wanted a defense-in-depth strategy to protect against attackers who might gain remote access to their servers over the network, through the use of compromised employee user IDs and passwords. IPSec allows Contoso to restrict client network access only to computers that are members of the domain. If necessary, access can be further restricted to a specific group of computers in the domain. Accordingly, to secure their servers, Contoso used an IPSec policy to require ESP encryption for domain members to connect.

Because Windows Server 2003 IPSec can detect the presence of network address translators and automatically use UDP headers to allow IPSec traffic to traverse the network address translators, Contoso was able to discontinue using PPTP for remote access VPN connections. For enhanced security, administrators switched all remote users to L2TP/IPSec VPN connections using L2TP/IPSec NAT-T-capable clients, newly available from Microsoft. For more information, see the Virtual Private Networks link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Use the job aid "Designing an IPSec Policy" (DNSIPS_1.xls) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing an IPSec Policy" on the Web at http://www.microsoft.com/reskit) to record information about your environment. Use a separate copy of the worksheet for each policy you create to meet the security needs of each group of servers.