Use this dialog box to configure a data integrity algorithm offer 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 its 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 causing a mismatch of the hash. This is critical when data is exchanged over an unsecured network, such as the Internet, because it provides a way to know that the message was not changed during transit.
|How to get to this dialog box|
On 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, select an algorithm combination from the list, and click Edit or Add.
The following protocols are used to embed the integrity information into an IP packet.
ESP provides authentication, integrity, and anti-replay protection for the IP payload. ESP used in transport mode does not sign the entire packet. Only the IP payload, not the IP header, is protected. ESP can be used alone or in combination with AH. With ESP, the hash calculation includes the ESP header, trailer, and payload only. ESP can optionally provide data confidentiality services by encrypting the ESP payload with one of several supported encryption algorithms. Packet replay services are provided through the inclusion of a sequence number for each packet.
AH provides authentication, integrity, and anti-replay for the entire packet (both the IP header and the data payload carried in the packet). It does not provide confidentiality, which means that it does not encrypt the data. The data is readable, but protected from modification. Some fields that are allowed to change in transit are excluded from the hash calculation. Packet replay services are provided through the inclusion of a sequence number for each packet.
The AH protocol is not compatible with network address translation (NAT) because NAT devices change information in some of the packet headers that are included in the integrity hash. To allow IPsec-based traffic to pass through a NAT device, you must use ESP and ensure that NAT Traversal (NAT-T) is enabled on the IPsec peer computers.
Null encapsulation specifies that you do not want to use any integrity or encryption protection on your network traffic. Authentication is still performed as required by the connection security rules, but no other protection is provided to the network packets that are exchanged through this security association.
Because this option provides no integrity or confidentiality protection of any kind, we recommend that you use it only if you must support software or network devices that are not compatible with ESP or AH.
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-GMAC 256
- AES-GMAC 192
- AES-GMAC 128
MD5 is no longer considered secure and should only be used for testing purposes or in cases in which the remote computer cannot use a more secure algorithm. It is provided for backward compatibility only.
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.
This key regeneration is for quick mode data integrity only. These settings do not affect the key lifetime settings for main mode key exchange.
Use this setting to configure how long the key used in the quick mode security association lasts, in minutes. After this interval, a new key will be generated. 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.
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.