Understanding Default IPSec Policies

  • Article

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

Windows Server 2003 includes three default IPSec policies that are provided as examples only. Do not use any part of the examples as templates to edit or change when creating your own IPSec policies. Instead, design new custom IPSec policies for operational use. The example policies will be overwritten during operating system upgrades and when IPSec policies are imported (when the import files contain other definitions of the same example policies). The three default IPSec policies are as follows:

  • Client (Respond Only). This default policy contains one rule, the default response rule. The default response rule secures communication only upon request by another computer. This policy does not attempt to negotiate security for any other traffic.

  • Server (Request Security). This default policy contains two rules: the default response rule and a second rule that allows initial incoming communication to be unsecured. The second rule then negotiates security for all outbound unicast IP traffic (security is not negotiated for multicast or broadcast traffic). The filter action for the second rule allows IKE to fall back to unsecured communication when required. This policy can be combined with the Client (Respond Only) policy when you want traffic secured by IPSec when possible, yet allow unsecured communication with computers that are not IPSec-enabled. If IKE receives a response from an IPSec-enabled client, but the IKE security negotiation fails, the communication is blocked. In this case, IKE cannot fall back to unsecured communication.

  • Secure Server (Require Security). This default policy has two rules: the default response rule and a rule that allows the initial inbound communication request to be unsecured, but requires that all outbound communication be secured. The filter action for the second rule does not allow IKE to fall back to unsecured communication. If the IKE security negotiation fails, the outbound traffic is discarded and the communication is blocked. This policy requires that all connections be secured with IPSec. Any clients that are not IPSec-enabled cannot establish connections.

Both the Server (Request Security) and Secure Server (Require Security) default policies allow inbound unsecured communication, so that they can be used with the Client (Respond Only) policy. IPSec policies that are designed for operational use are typically customized to combine these behaviors as needed for a specific computer or network environment. The most secure IPSec configuration is not be represented by the default policies.

The most secure configuration is one that negotiates security and neither receives unsecured traffic nor allows communication with non-IPSec-aware computers. In such a configuration, the client computer policy must have a filter in a rule to initiate secured communication when applications on the client computer attempt outbound connections to the server.

Predefined Filter Lists

There are two predefined example filter lists included with Windows Server 2003:

  • All ICMP Traffic. This filter affects any ICMP traffic (IP protocol 1) that is sent and received by using the unicast IP address of any network interface on a computer and all other computers. In Windows Server 2003, this filter matches outbound IP broadcast and multicast traffic when that traffic also uses the ICMP protocol.

  • All IP Traffic. This filter affects all IP traffic that is sent and received using the unicast IP address of any network interface on the computer to any destination IP address. Because inbound broadcast and multicast traffic use a multicast or broadcast type for the destination address, the inbound traffic is exempt. All ISAKMP traffic sent over UDP port 500, which is required for establishing IPSec-secured communication, is also exempted from IPSec filtering. For more information, see "Understanding IP Filters, Filter Actions, and Filter Lists" later in this chapter.

Predefined Filter Actions

There are three predefined example filter actions included with Windows Server 2003:

  • Permit. All traffic that matches the associated filters in the filter list is permitted. This permit behavior is static, not stateful.

  • Request Security. All inbound traffic that matches the associated filters in the filter list is allowed unsecured. All outbound traffic that matches the associated filters in the filter list negotiates security. Traffic is secured if the computer at the other end of the connection supports IPSec with a complementary filter action and filter in its policy. If security negotiation fails to elicit a response from the peer within three seconds, a security association for plaintext traffic is created (this association is known as a soft SA). If the peer responds within three seconds and the security negotiation fails, the communication is blocked. After IPSec SAs are established, all traffic that matches the associated filters is secured in both directions between the two computer IP addresses. This behavior is designed so that servers can request security for all clients, but fall back to unsecured communication with computers that are not IPSec-enabled.

  • Require Security. As with the Request Security filter action, all inbound traffic that matches the associated filters in the filter list is allowed unsecured, and all outbound traffic that matches the associated filters in the filter list negotiates security. Unlike Request Security, if IKE fails to receive a response and the security negotiation fails, the communication is blocked. After IPSec SAs are established, all traffic that matches the associated filters is secured in both directions between the two computer IP addresses.

Each of these three filter actions allows inbound unsecured communication. This is not the most secure behavior, nor can it be used to initiate secured communication in some trust environments. These filter actions allow the Server (Request Security) and Secure Server (Require Security) example policies to be used with the Client (Respond Only) example policy. If Kerberos authentication is used, this behavior is appropriate for servers that only communicate with clients in mutually trusted domains. For servers that are in one-way domain trust environments, the client computer policy must have a filter in a rule to initiate secured communication with the server.

It is not appropriate to allow inbound unsecured communication for servers that have an Internet interface, because it can make the servers vulnerable to a denial-of-service attack. Internet attackers can easily spoof IP packets to flood the server, causing a denial of service as the server attempts many IKE negotiations with non-existent source IP addresses. The most secure filter action is one that requires security for all inbound and outbound traffic. To create this filter action, verify that the Accept unsecured communication, but always respond using IPsec and Allow unsecured communication with non-IPsec aware computers check boxes are cleared.