Partager via

Determining Your IPSec Needs

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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

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.

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 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.