Use this dialog box to configure an algorithm offer that includes both data integrity and data confidentiality (encryption) and that is available when negotiating quick mode security associations. You must specify both the protocol and the algorithm used to protect the integrity of the data in the network packet.
Internet Protocol security (IPsec) provides integrity by calculating a hash generated from the data in the network packet. The hash is then cryptographically signed (encrypted) and embedded in the IP packet. The receiving computer uses the same algorithm to calculate the hash, and compares the result to the hash that is embedded in the received packet. If it matches, then the information received is exactly the same as the information sent, and the packet is accepted. If it does not match, then the packet is dropped.
Using an encrypted hash of the transmitted message makes it computationally infeasible to change the message without a resulting mismatch with the hash. This is critical when data is exchanged over an unsecured network such as the Internet and provides a way to know that the message was not changed during transit.
In addition to integrity protection, this dialog box allows you to specify an encryption algorithm that helps prevent the data from being read if the network packet is intercepted while in transit.
|
How to get to this dialog box |
-
In the Windows Firewall with Advanced Security MMC snap-in page, in Overview, click Windows Firewall Properties.
-
Click the IPsec Settings tab.
-
Under IPsec defaults, click Customize.
-
Under Data protection (Quick Mode), select Advanced, and then click Customize.
-
Under Data integrity and encryption, select an algorithm combination from the list, and click Edit or Add.
Protocol
The following protocols are used to embed the integrity and encryption information into an IP packet.
ESP (recommended)
Encapsulating Security Payload (ESP) provides confidentiality (in addition to authentication, integrity, and anti-replay) for the IP payload. ESP in transport mode does not sign the entire packet. Only the IP data payload, not the IP header, is protected. ESP can be used alone or in combination with Authentication Header (AH). With ESP, the hash calculation includes the ESP header, trailer, and payload only. ESP provides data confidentiality services by encrypting the ESP payload with one of the supported encryption algorithms. Packet replay services are provided through the inclusion of a sequence number for each packet.
ESP and AH
This option combines the security of the ESP protocol with the AH protocol. AH provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet).
|
Important |
|
The AH protocol is not compatible with network address translation (NAT) because NAT devices need to change information in the packet headers. To allow IPsec-based traffic to pass through a NAT device, you must ensure that NAT Traversal (NAT-T) is supported on your IPsec peer computers. |
Algorithms
Encryption algorithm
The following encryption algorithms are available to computers running this version of Windows. Some of these algorithms are not available on computers running earlier versions of Windows. If you must establish IPsec-protected connections with a computer running an earlier version of Windows, then you must include algorithm options that are compatible with the earlier version.
For more information, see IPsec Algorithms and Methods Supported in Windows (http://go.microsoft.com/fwlink/?LinkID=129230).
- AES-GCM 256
- AES-GCM 192
- AES-GCM 128
- AES-CBC 256
- AES-CBC 192
- AES-CBC 128
- 3DES
- DES
|
Security Note |
|
We recommend that you do not use DES. It is provided for backward compatibility only. |
|
Note |
|
If you specify an AES-GCM algorithm for encryption, then you must specify the same algorithm for integrity. |
Integrity algorithm
The following integrity algorithms are available to computers running this version of Windows. Some of these algorithms are not available on computers running other versions of Windows. If you must establish IPsec-protected connections with a computer running an earlier version of Windows, then you must include algorithm options that are compatible with the earlier version.
For more information, see IPsec Algorithms and Methods Supported in Windows (http://go.microsoft.com/fwlink/?LinkID=129230).
- AES-GCM 256
- AES-GCM 192
- AES-GCM 128
- AES-GMAC 256
- AES-GMAC 192
- AES-GMAC 128
- SHA-1
- MD5
|
|
Security Note |
|
We recommend that you do not use MD5. It is provided for backward compatibility only. |
|
|
Note |
|
If you specify an AES-GCM algorithm for integrity, then you must specify the same algorithm for encryption. |
Key lifetimes
Lifetime settings determine when a new key is generated. Key lifetimes allow you to force the generation of a new key after a specified time interval or after a specified amount of data has been transmitted. For example, if the communication takes 100 minutes and you specify a key lifetime of 10 minutes, 10 keys will be generated (one every 10 minutes) during the exchange. Using multiple keys ensures that if an attacker manages to gain the key to one part of a communication, the entire communication is not compromised.
|
|
Note |
|
This key regeneration is for quick mode data integrity and encryption and does not affect the key lifetime settings for main mode key exchange. |
Minutes
Use this setting to configure how long the key used in the quick mode security association lasts, in minutes. After this interval, the key will be regenerated. Subsequent communications will use the new key.
The maximum lifetime is 2,879 minutes (48 hours). The minimum lifetime is 5 minutes. We recommend that you rekey only as frequently as your risk analysis requires. Excessively frequent rekeying can impact performance.
KB
Use this setting to configure how many kilobytes (KB) of data are sent using the key. After this threshold is reached, the counter is reset, and the key is regenerated. Subsequent communications will use the new key.
The maximum lifetime is 2,147,483,647 KB. The minimum lifetime is 20,480 KB. We recommend that you rekey only as frequently as your risk analysis requires. Excessively frequent rekeying can impact performance.