6 Appendix A: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.
The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.
|
Windows Client Releases |
All Initiator Roles |
All Responder Roles |
|---|---|---|
|
Windows 2000 Professional operating system |
Yes |
Yes |
|
Windows XP operating system |
Yes |
Yes |
|
Windows Vista operating system |
Yes |
Yes |
|
Windows 7 operating system |
Yes |
Yes |
|
Windows 8 operating system |
Yes |
Yes |
|
Windows 8.1 operating system |
Yes |
Yes |
|
Windows 10 operating system |
Yes |
Yes |
|
Windows 11 operating system |
Yes |
Yes |
|
Windows Server Releases |
All Initiator Roles |
All Responder Roles |
|---|---|---|
|
Windows 2000 Server operating system |
Yes |
Yes |
|
Windows Server 2003 operating system |
Yes |
Yes |
|
Windows Server 2008 operating system |
Yes |
Yes |
|
Windows Server 2008 R2 operating system |
Yes |
Yes |
|
Windows Server 2012 operating system |
Yes |
Yes |
|
Windows Server 2012 R2 operating system |
Yes |
Yes |
|
Windows Server 2016 operating system |
Yes |
Yes |
|
Windows Server operating system |
Yes |
Yes |
|
Windows Server 2019 operating system |
Yes |
Yes |
|
Windows Server 2022 operating system |
Yes |
Yes |
|
Windows Server 2025 operating system |
Yes |
Yes |
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 1.3: IKEv2 Protocol Implementation Notes
[RFC4306] IKEv2 MUST / MUST NOT implementation notes
-
RFC Requirement
RFC 4306 Section
Compliance statement
"If a node receives a delete request for SAs for which it has already issued a delete request, it MUST delete the outgoing SAs while processing the request and the incoming SAs while processing the response."
Section 1.4
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"Note that Message IDs are cryptographically protected and provide protection against message replays. In the unlikely event that Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be closed."
Section 2.2
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"The management interface by which the Shared Secret is provided MUST accept ASCII strings of at least 64 octets and MUST NOT add a null terminator before using them as shared secrets. It MUST also accept a HEX encoding of the Shared Secret."
Section 2.15
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"IKEv2 simplifies this situation by requiring that ECN be usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. Specifically, tunnel encapsulators and decapsulators for all tunnel-mode SAs created by IKEv2 MUST support the ECN full-functionality option for tunnels specified in [RFC3168] and MUST implement the tunnel encapsulation and decapsulation processing specified in [RFC4301] to prevent discarding of ECN congestion indications."
Section 3.6
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"MUST be capable of being configured to send and accept the first two Hash and URL formats (with HTTP URLs)."
Section 3.6
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
[RFC4306] IKEv2 SHOULD / SHOULD NOT implementation notes
-
RFC Requirement
RFC 4306 Section
Compliance statement
"The initiator SHOULD repeat the request, but now with a KEi payload from the group the responder (1) selected."
Section 1.3
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"…regard half-closed connections as anomalous and audit their existence should they persist."
Section 1.4
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"IKEv2 implementations SHOULD be aware of the maximum UDP message size supported."
Section 2
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"An IKE endpoint supporting a window size greater than one SHOULD be capable of processing incoming requests out of order to maximize performance in the event of network failures or packet reordering."
Section 2.4
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"An endpoint SHOULD suspect that the other endpoint has failed based on routing information and initiate a request to see whether the other endpoint is alive."
Section 2.4
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"…implementations SHOULD reject as invalid a message with those payloads in any other order."
Section 2.5
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"Implementations SHOULD support in-place rekeying of SAs."
Section 2.8
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it."
Section 2.8
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"If an initiator receives a message on an SA for which it has not received a response to its CREATE_CHILD_SA request, it SHOULD interpret that as a likely packet loss and retransmit the CREATE_CHILD_SA request."
Section 2.8
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"If an error occurs outside the context of an IKE request (e.g., the node is getting ESP messages on a nonexistent SPI), the node SHOULD initiate an INFORMATIONAL exchange with a Notify payload describing the problem."
Section 2.21
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"A node SHOULD treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and SHOULD initiate a liveness test for any such IKE_SA. An implementation SHOULD limit the frequency of such tests."
Section 2.21
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that are not behind a NAT SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end."
Section 2.23
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"To assure maximum interoperability, implementations MUST be configurable to send at least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and MUST be configurable to accept all of these types. Implementations SHOULD be capable of generating and accepting all of these types."
Section 3.5
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"Implementations SHOULD be capable of being configured to send and accept Raw RSA keys."
Section 3.6
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder (1) SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them."
Section 3.16
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
[RFC4306] IKEv2 MAY implementation notes
-
RFC Requirement
RFC 4306 Section
Compliance statement
"The traffic selectors for traffic to be sent on that SA are specified in the TS payloads, which may be a subset of what the initiator of the CHILD_SA proposed."
Section 1.3
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"If the receiving node has an active IKE_SA to the IP address from whence the packet came, it MAY send a notification of the wayward packet over that IKE_SA in an INFORMATIONAL exchange."
Section 1.5
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"IKEv2 implementations SHOULD be aware of the maximum UDP message size supported and MAY shorten messages by leaving out some certificates or cryptographic suite proposals if that will keep messages below the maximum."
Section 2
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"In order to maximize IKE throughput, an IKE endpoint MAY issue multiple requests before getting a response to any of them if the other endpoint has indicated its ability to handle such requests. For simplicity, an IKE implementation MAY choose to process requests strictly in order and/or wait for a response to one request before issuing another."
Section 2.3
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"To prevent this, the initiator MAY be willing to accept multiple responses to its first message, treat each as potentially legitimate, respond to it, and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its requests."
Section 2.4
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"The responder (1) in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of <secret> around for a short time and accept cookies computed from either one."
Section 2.6
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"An implementation MAY refuse all CREATE_CHILD_SA requests within an IKE_SA."
Section 2.8
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"An initiator MAY send a dummy message on a newly created SA if it has no messages queued in order to assure the responder (1) that the initiator is ready to receive messages."
Section 2.8
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"If more than one subset is acceptable but their union is not, the responder (1) MUST accept some subset and MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to try again."
Section 2.9
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY contain any number of additional attributes the initiator wants returned in the response."
Section 2.19
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"An IKE peer wishing to inquire about the other peer's IKE software version information MAY use the method below."
Section 2.20
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"A node receiving a suspicious message from an IP address with which it has an IKE_SA MAY send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA."
Section 2.21
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"A node requesting a CHILD_SA MAY advertise its support for one or more compression algorithms through one or more Notify payloads of type IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single compression algorithm with a Notify payload of type IPCOMP_SUPPORTED."
Section 2.22
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"IPv6-only implementations MAY be configurable to send only ID_IPV6_ADDR."
Section 3.5
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"INVALID_SPI MAY be sent in an IKE INFORMATIONAL exchange when a node receives an ESP or AH packet with an invalid SPI."
Section 3.10.11
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"INVALID_SELECTORS MAY be sent in an IKE INFORMATIONAL exchange when a node receives an ESP or AH packet whose selectors do not match those of the SA on which it was delivered (and that caused the packet to be dropped)."
Section 3.10.11
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"INITIAL_CONTACT: It MAY be sent when an IKE_SA is established after a crash,…"
Section 3.10.11
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"NAT_DETECTION_SOURCE_IP: There MAY be multiple Notify payloads of this type in a message if the sender does not know which of several network attachments will be used to send the packet."
Section 3.10.11
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"NAT_DETECTION_DESTINATION_IP: Alternately, it MAY reject the connection attempt if NAT traversal is not supported."
Section 3.10.11
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"HTTP_CERT_LOOKUP_SUPPORTED: This notification MAY be included in any message that can include a CERTREQ payload and indicates that the sender is capable of looking up certificates based on an HTTP-based URL."
Section 3.10.11
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"The CFG_REPLY Configuration Payload MAY return that value, or a new one. It MAY also add new attributes and not include some requested ones. Requestors MUST ignore returned attributes that they do not recognize. Some attributes MAY be multi-valued, in which case multiple attribute values of the same type are sent and/or returned."
Section 3.15
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
"INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS: With IPv6, a requestor MAY supply the low-order address bytes it wants to use. Multiple internal addresses MAY be requested by requesting multiple internal address attributes."
Section 3.15.1
Supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
<2> Section 1.3: The following tables list the extensions that each release supports.
Windows releases support the IKE version 1 proposal for Encapsulating Security Payload (ESP) and Authentication Headers (AH).
The IKE proposal for Encapsulating Security Payload (ESP) and Authentication Headers (AH) is not supported in the Windows 7 implementation of IKE version 2.
-
IKE extension
Windows NT 4.0 operating system (with additional download)
Windows 2000 operating system
Windows 2000 operating system Service Pack 4 (SP4) post-SP4 rollup
NAT-T
X
X
IKEv1 fragmentation
X
IKEv2 fragmentation
CGA authentication
Fast failover
Reliable delete
X
-
IKE extension
Windows XP
Windows XP operating system Service Pack 2 (SP2)
Windows Server 2003
Windows Vista and Windows Server 2008
Windows 7 and Windows Server 2008 R2
Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2
Windows 10, Windows Server 2016, Windows 10 v1709 operating system, and Windows Server v1709 operating system
Windows 10 v1803 operating system and Windows Server v1803 operating system
Windows 10 v1809 operating system and Windows Server v1809 operating system
Windows Server 2019
NAT-T
X
X
X
X
X
X
X
X
X
IKEv1 fragmentation
X
X
X
X
X
X
X
X
X
IKEv2 fragmentation
X
X
X
CGA authentication
X
X
X
X
X
X
X
Fast failover
X
X
X
X
X
X
X
X
X
Negotiation discovery
X
X
X
X
X
X
X
Reliable delete
X
X
X
X
X
X
X
X
X
X
IKEv2 SA Correlation
X
X
X
X
X
X
IKEv2 Configuration Attributes
X
X
X
X
X
X
Denial of Service protection
X
X
X
X
X
X
X
X
X
X
Dead Peer Detection
X
X
X
X
X
Xbox Multiplayer Gaming (IKEv2) Vendor IDs
X
X
X
X
Security Realm (IKEv2) Vendor IDs
X
X
X
X
<3> Section 1.3.8: The IKE/AuthIP Coexistence extension is not implemented in Windows 2000, Windows XP and Windows Server 2003.
<4> Section 1.7: The following table lists the algorithms that are implemented in each Windows release.
|
Authentication method |
Windows 2000 |
Windows XP |
Windows Server 2003 |
Windows Vista and Windows Server 2008 |
Windows 7 and Windows Server 2008 R2 |
Windows 8 and later, and Windows Server 2012 and later |
|---|---|---|---|---|---|---|
|
Pre-shared key (as specified in [RFC2409]) |
X |
X |
X |
X |
X |
X |
|
RSA signature (as specified in [RFC2409]) |
X |
X |
X |
X |
X |
X |
|
X |
X |
X |
X |
X |
X |
|
|
CGA (as specified in [RFC3972]) |
|
|
|
X |
X |
X |
<5> Section 1.7: The following tables list the cryptographic parameters that are implemented in each Windows release.
|
Diffie-Hellman group |
Windows 2000 |
Windows XP |
Windows Server 2003 |
Windows Vista and Windows Server 2008 |
Windows 7 and Windows Server 2008 R2 |
Windows 8 and later, and Windows Server 2012 and later |
|---|---|---|---|---|---|---|
|
Default 768-bit MODP group [RFC2409] |
X |
X |
X |
X |
X |
X |
|
Alternate 1,024-bit MODP group [RFC2409] |
X |
X |
X |
X |
X |
X |
|
2,048-bit MODP group [RFC3526] |
|
|
X |
X |
X |
X |
|
ECP256 [ECP]) |
|
|
|
X |
X |
X |
|
ECP384 (as specified in [ECP] |
|
|
|
X |
X |
X |
|
Authentication algorithm |
Windows 2000 |
Windows XP |
Windows Server 2003 |
Windows Vista and Windows Server 2008 |
Windows 7 and Windows Server 2008 R2 |
Windows 8 and later, and Windows Server 2012 and later |
|---|---|---|---|---|---|---|
|
NULL [RFC2410] |
X |
X |
X |
X |
X |
X |
|
HMAC-SHA1-96 [RFC2404] |
X |
X |
X |
X |
X |
X |
|
HMAC-MD5-96 [RFC2403] |
X |
X |
X |
X |
X |
X |
|
AES-MAC [RFC4543] |
|
|
|
|
X |
X |
|
SHA-256 [SHA256] |
|
|
|
|
X |
X |
|
Encryption algorithm |
Windows 2000 |
Windows XP |
Windows Server 2003 |
Windows Vista and Windows Server 2008 |
Windows 7 and Windows Server 2008 R2 |
Windows 8 and later, and Windows Server 2012 and later |
|---|---|---|---|---|---|---|
|
NULL [RFC2410] |
X |
X |
X |
X |
X |
X |
|
DES-CBC [RFC2405] |
X |
X |
X |
X |
X |
X |
|
3DES-CBC [RFC2451] |
X |
X |
X |
X |
X |
X |
|
AES-CBC with 128, 192, and 256 Bit Keys [RFC3602] |
|
|
|
X |
X |
X |
|
AES-GCM with 128, 192, and 256 Bit Keys [RFC4106] |
|
|
|
|
X |
X |
<6> Section 1.7: The Microsoft implementation of IKE supports the following vendor IDs.
The Microsoft implementation vendor ID (for example, in rows of the second table that follows, where the Common name starts with "Microsoft implementation"), is constructed by appending a 32-bit (4-byte) version number in network byte order to the 128-bit (16-byte) MD5 hash of the "MS NT5 ISAKMPOAKLEY" string. The version number is the additional 4 bytes that denote the Windows release, as detailed in the first table that follows.
|
Windows release |
4-byte version number |
|---|---|
|
Windows 2000 |
00 00 00 02 |
|
Windows XP |
00 00 00 03 |
|
Windows Server 2003 |
00 00 00 04 |
|
Windows Vista |
00 00 00 05 |
|
Windows Server 2008 |
00 00 00 06 |
|
Windows 7 |
00 00 00 07 |
|
Windows Server 2008 R2 |
00 00 00 08 |
|
Windows 8 |
00 00 00 09 |
|
Windows Server 2012 |
00 00 00 09 |
|
Windows 8.1 |
00 00 00 09 |
|
Windows Server 2012 R2 |
00 00 00 09 |
|
Windows 10 |
00 00 00 09 |
|
Windows Server 2016 |
00 00 00 09 |
|
Windows Server operating system |
00 00 00 09 |
|
Windows Server 2019 |
00 00 00 09 |
In other cases, a keying module vendor ID is constructed by appending a 32-bit (4-byte) module value in network byte order to the 128-bit (16-byte) MD5 hash of the “KEY_MODS” string to create its wire representation. Examples of this are shown in the table immediately below in rows where the Common name contains the text “Microsoft supported keying modules”. A similar organization applies to constructing a vendor ID for the “AUTHIP_INIT_KE_DH_GROUP” strings shown in rows of the table that follows which have the Common name “AuthIP Initiator DH type sent in KE”. Other vendor IDs are as stated in the same table.
Additional tables that follow the table immediately below specify key module values and Diffie Hellman (DH) group values that are available for constructing vendor IDs for keying modules and AuthIP Initiator DH groups, respectively.
|
Common name |
String representation |
Wire representation (MD5 hash of string) |
Windows release |
|---|---|---|---|
|
Microsoft implementation Windows 2000 |
"MS NT5 ISAKMPOAKLEY" + version number 2 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 02 |
Windows 2000 |
|
Microsoft implementation Windows XP |
"MS NT5 ISAKMPOAKLEY" + version number 3 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 03 |
Windows XP |
|
Microsoft implementation Windows Server 2003 |
"MS NT5 ISAKMPOAKLEY" + version number 4 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 04 |
Windows Server 2003 |
|
Microsoft implementation Windows Vista |
"MS NT5 ISAKMPOAKLEY" + version number 5 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 05 |
Windows Vista |
|
Microsoft implementation Windows Server 2008 |
"MS NT5 ISAKMPOAKLEY" + version number 6 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 06 |
Windows Server 2008 |
|
Microsoft implementation Windows 7 |
"MS NT5 ISAKMPOAKLEY" + version number 7 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 07 |
Windows 7 |
|
Microsoft implementation Windows Server 2008 R2 |
"MS NT5 ISAKMPOAKLEY" + version number 8 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 08 |
Windows Server 2008 R2 |
|
Microsoft implementation Windows 8 |
"MS NT5 ISAKMPOAKLEY" + version number 9 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 09 |
Windows 8 |
|
Microsoft implementation Windows Server 2012 |
"MS NT5 ISAKMPOAKLEY" + version number 9 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 09 |
Windows Server 2012 |
|
Microsoft implementation Windows 8.1 |
"MS NT5 ISAKMPOAKLEY" + version number 9 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 09 |
Windows 8.1 |
|
Microsoft implementation Windows 10 |
"MS NT5 ISAKMPOAKLEY" + version number 9 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 09 |
Windows 10 |
|
Microsoft implementation Windows Server 2012 R2 |
"MS NT5 ISAKMPOAKLEY" + version number 9 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 09 |
Windows Server 2012 R2 |
|
Microsoft implementation Windows Server 2016, Windows Server operating system, and Windows Server 2019 |
"MS NT5 ISAKMPOAKLEY" + version number 9 |
1E 2B 51 69 05 99 1C 7D 7C 96 FC BF B5 87 E4 61 00 00 00 09 |
Windows Server 2016, Windows Server operating system, and Windows Server 2019 |
|
Microsoft supported keying modules |
“KEY_MODS” + Key Module (IKE) |
01 52 8b bb c0 06 96 12 18 49 ab 9a 1c 5b 2a 51 00 00 00 00 |
Windows 7 and later, and Windows Server 2008 R2 operating system and later |
|
Microsoft supported keying modules |
“KEY_MODS” + Key Module (AuthIP) |
01 52 8b bb c0 06 96 12 18 49 ab 9a 1c 5b 2a 51 00 00 00 01 |
Windows 7 and later, and Windows Server 2008 R2 and later |
|
Microsoft supported keying modules |
“KEY_MODS” + Key Module (IKEv2) |
01 52 8b bb c0 06 96 12 18 49 ab 9a 1c 5b 2a 51 00 00 00 02 |
Windows 7 and later, and Windows Server 2008 R2 and later |
|
Kerberos authentication supported (as specified in [GSS]) |
"GSSAPI" |
62 1B 04 BB 09 88 2A C1 E1 59 35 FE FA 24 AE EE |
All versions listed in the Product Behavior Appendix
|
|
NLB/MSCS fast failover supported |
"Vid-Initial-Contact" |
26 24 4D 38 ED DB 61 B3 17 2A 36 E3 D0 CF B8 19 |
All versions listed in the Product Behavior Appendix
|
|
NLB/MSCS fast failover supported |
"NLBS_PRESENT" |
72 87 2B 95 FC DA 2E B7 08 EF E3 22 11 9B 49 71 |
All versions listed in the Product Behavior Appendix
|
|
Fragmentation avoidance supported |
"FRAGMENTATION" |
40 48 B7 D5 6E BC E8 85 25 E7 DE 7F 00 D6 C2 D3 |
All versions listed in the Product Behavior Appendix
|
|
NAT-T supported |
"draft-ietf-ipsec-nat-t-ike-02\n" |
90 CB 80 91 3E BB 69 6E 08 63 81 B5 EC 42 7B 1F |
All versions listed in the Product Behavior Appendix
|
|
NAT-T supported |
"RFC 3947" |
4A 13 1C 81 07 03 58 45 5C 57 28 F2 0E 95 45 2F |
All versions listed in the Product Behavior Appendix except Windows 2000, Windows XP, and Windows Server 2003
|
|
AuthIP supported |
"MS-MamieExists" |
21 4C A4 FA FF A7 F3 2D 67 48 E5 30 33 95 AE 83 |
All versions listed in the Product Behavior Appendix except Windows 2000, Windows XP, and Windows Server 2003
|
|
CGA supported |
"IKE CGA version 1" |
E3 A5 96 6A 76 37 9F E7 07 22 82 31 E5 CE 86 52 |
All versions listed in the Product Behavior Appendix except Windows 2000, Windows XP, and Windows Server 2003
|
|
Negotiation discovery supported |
"MS-Negotiation Discovery Capable" |
FB 1D E3 CD F3 41 B7 EA 16 B7 E5 BE 08 55 F1 20 |
All versions listed in the Product Behavior Appendix except Windows 2000, Windows XP, and Windows Server 2003
|
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_GROUP_NONE) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 00 |
Windows 8 and later, and Windows Server 2012 and later |
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_GROUP_1) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 01 |
Windows 8 and later, and Windows Server 2012 and later |
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_GROUP_2) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 02 |
Windows 8 and later, and Windows Server 2012 and later |
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_ECP_256) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 04 |
Windows 8 and later, and Windows Server 2012 and later |
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_ECP_384) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 05 |
Windows 8 and later, and Windows Server 2012 and later |
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_GROUP_24) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 06 |
Windows 8 and later, and Windows Server 2012 and later |
|
AuthIP Initiator DH type sent in KE |
“AUTHIP_INIT_KE_DH_GROUP” + Diffie Hellman group (IKEEXT_DH_GROUP_MAX) |
7B B9 38 67 D7 6C 8D 80 DF 0F 40 FA E8 FC 3B 19 00 00 00 07 |
Windows 8 and later, and Windows Server 2012 and later |
|
Microsoft Xbox One 2013 |
"Microsoft Xbox One 2013" |
8A A3 94 CF 8A 55 77 DC 31 10 C1 13 B0 27 A4 F2 |
Windows 10, Windows Server 2016, Windows Server operating system, and Windows Server 2019 |
|
Xbox IKEv2 Negotiation |
"Xbox IKEv2 Negotiation" |
66 08 22 B3 A7 3A 24 41 49 57 8D 62 E0 EB 46 A0 |
Windows 10, Windows Server 2016, Windows Server operating system, and Windows Server 2019 |
|
Security Realm ID |
"MSFT IPsec Security Realm Id" |
68 6A 8C BD FE 63 4B 40 51 46 FB 2B AF 33 E9 E8 |
Windows 10, Windows Server 2016, Windows Server operating system, and Windows Server 2019 |
|
Keying Module |
4-Byte Value |
|---|---|
|
IKEEXT_KEY_MODULE_IKE |
00 00 00 00 |
|
IKEEXT_KEY_MODULE_AUTHIP |
00 00 00 01 |
|
IKEEXT_KEY_MODULE_IKEV2 |
00 00 00 02 |
|
DH Group |
4-Byte Value |
|---|---|
|
IKEEXT_DH_GROUP_NONE |
00 00 00 00 |
|
IKEEXT_DH_GROUP_1 |
00 00 00 01 |
|
IKEEXT_DH_GROUP_2 |
00 00 00 02 |
|
IKEEXT_DH_GROUP_14 / IKEEXT_DH_GROUP_2048 |
00 00 00 03 |
|
IKEEXT_DH_ECP_256 |
00 00 00 04 |
|
IKEEXT_DH_ECP_384 |
00 00 00 05 |
|
IKEEXT_DH_GROUP_24 |
00 00 00 06 |
|
IKEEXT_DH_GROUP_MAX |
00 00 00 07 |
<7> Section 2.1: These IKE extensions run on UDP ports 500 and 4500 only.
<8> Section 2.2.6: This field can contain any Windows error code value. For more information about these codes, see [MS-ERREF].
<9> Section 2.2.7: This field can take on any Windows error code value. For more information about these codes, see [MS-ERREF].
<10> Section 2.2.10: Security Realm Vendor Ids are implemented in Windows 10 and in Windows Server 2016 and later operating systems.
<11> Section 2.2.10: For Windows implementations, the "MSFT IPsec Security Realm Id" payload is 32 bytes long. The first 16 bytes is the MD5 hash of the vendor ID string. The remaining 16 bytes is an HMAC-MD5 encrypted string that identifies a particular security realm (as discussed in section 1.3.12). The key that is used for this purpose is the string "SecurityRealmPolicyHmacKey".
<12> Section 3.1.5: Initialization vectors (IV) choice for encrypted notifications sent prior to MM SA establishment:
If the peer sent the MS NT5 ISAKMPOAKLEY notify vendor ID and the 4-byte version number is 0x00000002, 0x00000003, 0x0000004, or 0x00000005, (denoting Windows 2000, Windows XP, Windows Server 2003 and Windows Vista, respectively), the IV used in encrypting the notify is the last cipher block of the last sent packet. Otherwise, the IV will be the last cipher block of the last decrypted packet.
<13> Section 3.2: Windows releases implement both [RFC3947] and [DRAFT-NATT], except Windows 2000 SP4, Windows XP SP2, and Windows Server 2003, which implement the [DRAFT-NATT] revision only.
<14> Section 3.2.2: A NAT-T keep-alive message is sent every 20 seconds. Windows Vista prior to Windows Vista operating system with Service Pack 2 (SP2) and Windows Server 2008 prior to Windows Server 2008 operating system with Service Pack 2 (SP2) do not send keep-alive messages.
<15> Section 3.2.4.1: [NAT-T IKE] message construction is not implemented in Windows 2000 prior to Windows 2000 Server operating system Service Pack 4 (SP4) or in Windows XP prior to Windows XP SP2.
-
NAT-T revision support
Version
[DRAFT-NATT] and [RFC3947]
Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2
[DRAFT-NATT]
Windows 2000 Server SP4, Windows XP SP2, and Windows Server 2003
Windows releases do not support NAT-T for IPv6 and therefore, does not send the NAT-T vendor IDs for IPv6 negotiations.
<16> Section 3.3.2: The fragmentation timer is variable. The timer interval is computed as the sum of the first two packet retransmission times.
Except in Windows 2000, Windows XP, and Windows Server 2003, the timer is started from the first main mode packet of the exchange. Although 3 seconds is the norm, there is variance in the timer implementation up to ½ second per retransmission. This is an artifact of the underlying timer implementation. Hence the observed timer will be within the range of 2 to 4 seconds. Only the initiator implements a fragmentation timer.
In Windows 2000, Windows XP, and Windows Server 2003, the timer is started from the IKE exchange (the second round trip in main mode). In these versions, both the initiator and the responder (1) implement a fragmentation timer.
<17> Section 3.3.2: The fragment reassembly timer is set to 70 seconds.
<18> Section 3.3.5.3: The Fragmentation active flag is set on receipt of a Fragment payload.
<19> Section 3.3.5.3: IKE Message Fragmentation active flag behavior. Implemented in Windows 2000 Professional through Windows 7 and Windows 2000 Server through Windows Server 2008 R2. IKE messages are fragmented if the Fragmentation active flag is set, as per the conditions specified in section 3.3.6.1.
<20> Section 3.5.4.1: In Windows Vista and Windows Server 2008 operating system, the host sends the "Vid-Initial-Contact" vendor ID payload if it has no open TCP connections to the peer and new connection attempts cause the retransmission of SYN packets.
<21> Section 3.5.7.1: The QM SA idle timer is set to 1 minute if the Fast Failover flag is set on the parent MM SA, and it is set to 5 minutes if the Fast Failover flag is not set.
<22> Section 3.6.5.1: Vendor ID processing is used to evaluate whether the MM SA is allocated to a different host within the cluster. For more information, see [MSFT-WLBS]. Vendor ID processing is not implemented in Windows 2000.
<23> Section 3.8.4.1: Nonces are 32-byte, random numbers that are generated from a FIPS-140–compliant random-number generator. For more information, see [FIPS140]. Nonces are not implemented in Windows 2000.
<24> Section 3.8.6.1: Delete Retransmission timer is not implemented in Windows 2000. The first retransmission occurs after 1 second. The time-out is doubled for each subsequent retransmission up to a maximum of six retransmissions. The maximum retransmission interval is capped at 16 seconds; so if the doubling of the previous interval exceeds 16 seconds, 16 seconds is used. The timer is started only if the remote host is a Windows peer, as identified by the "MS NT5 ISAKMPOAKLEY" vendor ID payload.
<25> Section 3.8.7.1: Shutdown behavior. On shutdown for Windows 2000, Windows XP, and Windows Server 2003, IKE runs as specified in the footnote regarding the delete transmission timer in section 3.8.6.1. Note that the machine can shut down before the maximum number of retransmissions has actually been sent.
<26> Section 3.8.7.2: After a delete has been triggered, Windows releases immediately send the delete notify, and delays deleting the MM state internally to handle quick mode delete processing. Also, Windows releases do not immediately delete the quick mode(s) associated with the MM on receiving the MM delete, but waits for them to be deleted as a result of other protocol events.
<27> Section 3.9.5.1: The Windows implementation uses the following algorithm to generate the cookie (prevTimeSlice is a Boolean input parameter to the algorithm). iCookie is the Initiator Cookie as defined in [RFC2408] section 3.1.
-
Set Curtime to the 32 bits number of seconds elapsed since midnight, January 1, 1970 Set LocalIPaddr to the local IP address in network order Set Localport to the 16 bits local listening UDP port (500 or 4500) in network order /* This port is the local port that the packet was received on. */ Set Peerport to the 16 bits remote port in network order Set PeerIPaddr to the peer IP address in network order Set cookieKey to a 50-byte random number Set COOKIE_KEY_TIME to 150 seconds If LocalIPaddr and PeerIPaddr are IPv4 addresses then Compute localAddr as 01 00 02 00 concatenated with LocalPort concatenated with LocalIPAddr concatenated with 26 bytes of 0 Compute peerAddr as 01 00 02 00 concatenated with peerPort concatenated with peerIPAddr concatenated with 26 bytes of 0 end if If LocalIPaddr and PeerIPaddr are IPv6 addresses then Compute localAddr as 0x01 0x00 0x02 0x00 concatenated with LocalPort concatenated with LocalIPAddr concatenated with 14 bytes of 0 Compute peerAddr as 0x05 0x00 0x17 0x00 concatenated with peerPort concatenated with peerIPAddr concatenated with 14 bytes of 0 end if Compute Curtime as ((Curtime + COOKIE_KEY_TIME) / COOKIE_KEY_TIME) * COOKIE_KEY_TIME If prevTimeSlice is true then Compute Curtime as Curtime - COOKIE_KEY_TIME End if Compute tempCookie as SHA1(cookieKey concatenated with iCookie concatenated with peerAddr concatenated with localAddr concatenated with curTime) Compute cookie as the first 8 bytes of tempCookie
<28> Section 3.9.5.3: The Windows implementation checks the validity of the Responder Cookie field by regenerating the cookie using the algorithm specified in section 3.9.5.1. The algorithm is as follows.
-
Set RCookie to the cookie field from message #2 Set prevTimeslice to FALSE Compute cookie as described in <ref2> If RCookie=cookie then RCookie is valid Else Set prevTimeslice to TRUE Compute cookie as described in <ref2> If RCookie=cookie then RCookie is valid Else RCookie is invalid End if End if
<29> Section 3.9.7: In Windows Vista and Windows Server 2008, Windows goes into DoS Protection mode if the number of negotiations for which only one message has been received from any initiator is more than 500. This is detected when the number of MM SAs in the MMSAD (see section 3.1.1) is more than 500, and these SAs have only received one message. For a given IP address, if the number of negotiations for which only one message has been received is above 35, Windows releases drop new incoming negotiations from this IP address. For this reason, incoming messages have to come from multiple IP addresses in order to trigger the Denial of Service Protection mode. In Windows 2000, Windows XP, or Windows Server 2003, Windows goes into DoS protection mode immediately after setting the registry key and restarting the service.
Windows releases go out of DoS Protection mode if the number of MM SAs in the MMSAD for which only one message has been received from any initiator is less than 100.
To enable the DoS Protection mode in Windows Vista through Windows 10 and Windows Server 2008 through Windows Server 2016, set the following Windows registry DWORD to 1.
SYSTEM\\CurrentControlSet\\Services\\IKEEXT\\Parameters\EnableDOSProtect (DWORD)
To enable DoS Protection mode in Windows 2000, Windows XP, or Windows Server 2003, set the following Windows registry DWORD to 1.
SYSTEM\\CurrentControlSet\\Services\\PolicyAgent\\Oakley\EnableDOSProtect (DWORD).
Stop and restart the PolicyAgent service for this setting to take effect.
<30> Section 3.11: This feature is not supported in Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008.
<31> Section 3.11.5.1: Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008 do not add this attribute.
<32> Section 3.11.5.2: Windows 2000 Professional through Windows Vista and Windows 2000 Server through Windows Server 2008 do not process this attribute.
<33> Section 3.12.1: Dead Peer Detection is implemented only for IKEv2-based server-to-server, site-to-site-tunnel mode IPsec tunnels on Windows Server 2012 and later. Dead Peer Detection is not implemented on Windows 8 and later for IKEv2-based VPN (that is, VPN Reconnect).
<34> Section 3.12.7.1: The QM SA idle timer is set to 1 minute if the Fast Failover flag is set on the parent MM SA, and it is set to 5 minutes if the Fast Failover flag is not set.
<35> Section 3.13.1: Implemented in Windows 10 and Windows Server 2016 for Xbox multiplayer gaming scenarios.
<36> Section 3.13.1: The integer value associated with the "Xbox IKEv2 Negotiation" vendor ID can be 0 or 1. These values denote different types of secure connections for Xbox multiplayer gaming. Their significance is beyond the scope of this document.
<37> Section 3.14.1: Implemented in Windows 10 for Xbox multiplayer gaming scenarios.
<38> Section 3.14.1: This data is used to negotiate various IPsec SA proposals and different authentication methods for securing traffic for different game titles.
<39> Section 3.14.5.1: If the IKE_SA_INIT message does not have an "MSFT IPsec Security Realm Id" vendor ID, Windows releases skip all security realm-based IPsec policies.
If an IKEv2 responder receives an IKE_SA_INIT message with "MSFT IPsec Security Realm Id" vendor payload, the Windows implementation does not send the optional CERTREQ payload ([RFC5996] section 1.2) in the IKE_SA_INIT response message.