Partager via

Filter action

  • Article

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

Filter action

A filter action defines the security requirements for the data transmission. A filter action can be configured to:

  • Permit traffic (Permit)

    IPSec passes this traffic without modification or the requirement for security. This is appropriate for traffic from specific computers that are not IPSec-capable. Be sure to limit the IP filter list to a minimal scope when using this type of filter action, so you do not let traffic through which should be secured.

  • Block traffic (Block)

    IPSec silently discards this traffic. Be sure to use an IP filter list that appropriately defines the scope of traffic when using a blocking filter action so that you do not block valid computers from communicating.

  • Negotiate IPSec (Negotiate security)

    IPSec requires the negotiation of security associations and the sending or receiving of IPSec-secured traffic. After you choose to negotiate IPSec, you can also configure the following:

    • Security methods and their order

      For more information, see IPSec security methods.

    • Allowance of initial incoming unsecured traffic (Accept unsecured communication, but always respond using IPSec)

      IPSec allows an incoming packet that matches the configured filter list to be unsecured (not protected by IPSec). However, the outgoing response to the incoming packet must be protected. This setting is useful when you are using the default response rule for clients. When a group of servers are configured with a rule that secures communications with any IP address and accepts unsecured communication, responding with only secured communications, enabling the default response rule on client computers ensures that the clients will respond to the server request to negotiate security. This option should be disabled for secure computers connected to the Internet to prevent denial of service attacks.

    • Enabling of communication with non-IPSec-enabled computers (Allow unsecured communication with non-IPSec-aware computer)

      IPSec falls back to unsecured communication, if necessary. Again, you might need to limit the IP filter list to a minimal scope. Otherwise, if negotiation fails for any reason, any communications affected by the rule in which this filter action resides could result in data being sent without security. If you are concerned about unsecured communication, you might consider disabling this setting. However, communication with computers that cannot initiate IPSec, such as legacy systems, might be blocked. This option should be disabled for secure computers connected to the Internet.

    • Generation of session keys from new keying material (Use session key perfect forward secrecy (PFS))

      This determines whether existing master key keying material can be used to derive a new session key. Enabling session key perfect forward secrecy (PFS) ensures 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 less resources than master key PFS.

For information about how to configure filter actions, see Add, edit, or remove filter actions.

IPSec security methods

Each security method defines the security requirements of any communications to which the associated rule applies. Creating multiple security methods increases 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 most secure methods are placed at the top of the list and the least secure methods are placed at the bottom of the list.

Predefined security methods

The following security methods are predefined:

  • Encryption and Integrity

    Uses the ESP protocol to provide data confidentiality (encryption) with the triple Data Encryption Standard (3DES) algorithm, data integrity and authentication with the Secure Hash Algorithm 1 (SHA1) integrity algorithm, 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, use Integrity only.

  • Integrity only

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

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 when encryption and address integrity, stronger algorithms, or key lifetimes need to be specified. When configuring a custom security method, you can configure the following:

  • Security protocols

    Both AH (Data and address integrity without encryption) and ESP (Data integrity and encryption) can be enabled 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

    • Message Digest 5 (MD5), which uses a 128-bit key.

    • Secure Hash Algorithm 1 (SHA1), which uses a 160-bit key.

  • Encryption algorithm

    • 3DES is the most secure of the DES combinations, and somewhat slower in performance. 3DES processes each block three times, using three unique 56-bit keys.

    • DES is used when the higher security and overhead of 3DES is not necessary. DES uses a single 56-bit key.

  • 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 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 or every hour. Note that any time a key lifetime is reached, the quick mode SA is also renegotiated in addition to the key refresh or regeneration.

Note

  • When IPSec provides data confidentiality between a Windows XP or Windows Server 2003 family-based computer (or a Windows 2000-based computer that has the High Encryption Pack or Service Pack 2 or higher installed) and another computer that does not use 3DES, your list of security methods must include DES. Otherwise, the computer that you are trying to communicate with might not be able to reach a common security agreement with your computer. If confidentiality of the data is not required, you can select ESP format with an integrity algorithm only and set the encryption to <None>. Alternately, you can select an AH format with an integrity algorithm.

For information about how to configure security methods, see Add, edit, or remove IPSec security methods.