Default IPSec policies

  • Article

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

Default IPSec policies

Windows XP and the Windows Server 2003 family provide a set of predefined IPSec filter lists and filter actions and default policies. This is only intended to provide an example. It is not designed for operational use without modification. A knowledgeable IPSec network administrator or advanced user should design new, custom polices for operational use.

Computers that are connected to the Internet must be carefully protected from network attacks with custom policies. The default policies are defined as examples for intranets because they allow a computer to receive unsecured traffic. The default policies are designed for computers that are members of an Active Directory domain.

Predefined filter lists

The following predefined filter lists are provided as examples for use in the default policies:

  • All ICMP Traffic

    A filter list for all ICMP traffic (IP protocol 1) sent and received between this computer and all other computers.

  • All IP Traffic

    A filter list for all IP traffic sent and received between this computer and all other computers. By default, all Internet Key Exchange (IKE) traffic is excluded. All other traffic types are matched against IPSec filters, however, and you can configure, block, or permit filter actions specifically for multicast and broadcast traffic (IPSec does not negotiate security associations for multicast and broadcast traffic).

Predefined filter actions

The following predefined filter actions are provided as examples for use in the default policies:

  • Permit

    Traffic is permitted (the security method is set to Permit).

  • Request Security (Optional)

    Traffic is secured (the security method is set to Negotiate security), however, the following exceptions apply:

    • Initial incoming unsecured communication is allowed. This behavior is known as inbound passthrough.

    • If security negotiation fails after 3 seconds, unsecured communication to a non-IPSec-aware computer is allowed. This filter action secures traffic to IPSec-aware computers, but allows unsecured communication if it is required. This behavior is known as fallback to clear.

    In order to avoid the potential for denial-of-service attacks, this filter action must not be used on the Internet.

    The following table lists the security methods (in preference order) for the Request Security (Optional) predefined filter action.

    Type AH integrity ESP confidentiality ESP integrity Key lifetimes (KB/sec)

    Custom

    None

    3DES

    SHA1

    100000/900

    Custom

    None

    DES

    SHA1

    100000/900

    Custom

    SHA1

    None

    None

    100000/300

    Custom

    MD5

    None

    None

    100000/300

    The security negotiation for traffic using this filter action attempts ESP encryption (first 3DES, and then DES) with SHA1 integrity. If those security methods cannot be negotiated with the peer, AH integrity (first SHA1, and then MD5) only is attempted.

  • Require Security

    Traffic is secured (the security method is set to Negotiate security), however, initial incoming unsecured communication is allowed (inbound passthrough is enabled). Unsecured communication with non-IPSec-aware computers is not allowed (fallback to clear is disabled). For example, an incoming connection request packet is allowed. The computer's reply to the connection request matches the outbound filter, causing a request for security to be sent to the sender of the unsecured traffic. If security negotiation is successful, traffic in both directions is required to be secure. If security negotiation is not successful, outgoing traffic is not allowed. The computer might continue to receive incoming unsecured traffic and will continue to attempt to negotiate security.

    In order to avoid the potential for denial-of-service attacks, this filter action must not be used on the Internet.

    The following table lists the security methods (in preference order) for the Require Security predefined filter action.

    Type AH integrity ESP confidentiality ESP integrity Key lifetimes (KB/sec)

    Custom

    None

    3DES

    SHA1

    100000/900

    Custom

    None

    3DES

    MD5

    100000/900

    Custom

    None

    DES

    SHA1

    100000/900

    Custom

    None

    DES

    MD5

    100000/900

    The security negotiation for traffic using this filter action will only attempt to negotiate ESP encryption (first 3DES, and then DES) with differing ESP authentication methods (first SHA1, and then MD5).

The most secure filter action is one that negotiates security and neither receives unsecured traffic (inbound passthrough is disabled) nor allows communication with non-IPSec-aware computers (fallback to clear is disabled). This is known as a lockdown filter action. When a server is using this filter action, clients must initiate secured communication before sending any IP traffic. The IPSec policy for client computers must be configured with additional rules that force the client to negotiate security with the server. A client configured with policy that consists of only the default response rule is not able to communicate with a locked down server.

Predefined rules

The only predefined rule that is available on all policies is the default response rule. The default response rule is automatically created in a new policy and cannot be created manually. It is used to respond to security requests when no other rule applies. For example, a client policy that enables a client to respond to security requests but does not secure any traffic by default, would have only the default response rule active. In some cases, it is enabled by default. You can disable the default response rule on the Rules tab in properties for a policy. You can also modify the authentication method and security methods of the default response rule for specific needs. For more information, see the section "Default response rule" in IPSec Policy Rules.

Default policies

The following are provided as examples for use as default policies:

  • Client (Respond Only)

    This is an example policy for computers that secure communication on request. For example, intranet clients might not require IPSec except when requested by another computer. This policy enables the computer on which it is active to respond to requests for secured communications. This policy contains the default response rule, which creates dynamic IPSec filters for inbound and outbound traffic based on the requested protocol and port traffic for the communication that is being secured.

    This policy has the following settings:

    First rule (default response rule)

    • IP Filter List: <Dynamic>

    • Filter Action: Default Response

    • Authentication: Kerberos

    • Tunnel Setting: None

    • Connection Type: All

  • Server (Request Security)

    This is an example policy for computers that should secure communications in most cases, allowing unsecured communication with non-IPSec-aware computers. With this policy, the computer accepts unsecured traffic, but always attempts to secure additional communications by requesting security from the original sender. This policy allows the entire communication to be unsecured if the other computer is not IPSec-enabled. For example, communication to specific servers can be secure while allowing the server to communicate in an unsecured manner to accommodate a mixture of clients (some of which support IPSec and some of which do not).

    This policy has a rule to request security for all IP traffic, a rule to permit ICMP traffic, and the default response rule to respond to requests for security from other computers.

    This policy has the following settings:

    First rule

    • IP Filter List: All IP Traffic

    • Filter Action: Request Security (Optional)

    • Authentication: Kerberos

    • Tunnel Setting: None

    • Connection Type: All

    Second rule

    • IP Filter List: All ICMP Traffic

    • Filter Action: Permit

    • Authentication: N/A

    • Tunnel Setting: None

    • Connection Type: All

    Third rule (default response rule)

    • IP Filter List: <Dynamic>

    • Filter Action: Default Response

    • Authentication: Kerberos

    • Tunnel Setting: None

    • Connection Type: All

  • Secure Server (Require Security)

    This is an example policy for computers on an intranet that require secure communications, such as a server that transmits highly sensitive data. Administrators can use this IPSec policy as an example to create their own custom IPSec policy for production use. The filters used in this policy require all outbound communication to be secured, allowing only the initial inbound communication request to be unsecured.

    This policy has a rule to require security for all IP traffic, a rule to permit ICMP traffic, and the default response rule to respond to requests for security from other computers.

    First rule

    • IP Filter List: All IP Traffic

    • Filter Action: Require Security

    • Authentication: N/A

    • Tunnel Setting: None

    • Connection Type: All

    Second rule

    • IP Filter List: All ICMP Traffic

    • Filter Action: Permit

    • Authentication: Kerberos

    • Tunnel Setting: None

    • Connection Type: All

    Third rule (default response rule)

    • IP Filter List: <Dynamic>

    • Filter Action: Default Response

    • Authentication: Kerberos

    • Tunnel Setting: None

    • Connection Type: All

Notes

  • In the Windows Server 2003 family, IPSec provides new source and destination address options for defining filters. In addition, the default behavior for traffic exemptions has changed. If you require previously exempted traffic types, you must create filters to permit this traffic. For more information about the new source and destination options provided by IPSec and for instructions on how to configure permit filters for several previously exempted traffic types, see Special IPSec considerations.

  • Computers running Windows 2000 must have the High Encryption Pack or Service Pack 2 (or later) installed in order to use the 3DES algorithm. If a computer running Windows 2000 receives a 3DES setting, but does not have the High Encryption Pack or Service Pack 2 (or later) installed, the 3DES setting in the security method is set to the weaker DES, to provide some level of confidentiality for communication, rather than blocking all communication. However, you should only use DES as a fallback option if not all computers in your environment support the use of 3DES. Computers running Windows XP or a Windows Server 2003 operating system support 3DES and do not require installation of the High Encryption Pack.