IPsec will be supported for IPv4 only as specified in IETF RFCs 2401, 2402 and 2406 [7.3-39a, 39c, and 39j], unless clarified or specified otherwise below.
IPsec will be implemented as a “bump-in-the-stack” (BITS, see Section 3.3 of RFC 2401).
Support of transport mode IPsec will be required when IPv6 is supported.
Rationale:
While support of tunnel mode only is a violation of the last paragraph of Section 4.1 of RFC 2401, the VPN capability is only intended to support a connection to a VPN security gateway, not to other hosts.
Note:
Many of the capabilities of IPsec are specified in 96x1H-IPI.5.1.320, because that is where the Security Association negotiation is specified.
Approved
The Security Policy Database (SPD, see RFC 2401, Section 4.4.1) will contain an ordered list of policy entries (rules). Each policy entry will have the following information.
Source IP Address range (IP Address / Subnet Mask)
Destination IP Address range (IP Address / Subnet Mask)
Protocol
Source Port (if protocol is UDP or TCP)
Destination Port (if protocol is UDP or TCP)
Action (Drop, Apply IPsec, Bypass-IPsec)
The SPD shall have following rules at the beginning of the list, where SGIP is the IP Address of the security gateway, and IPSEC implies AH, ESP or UDP Encapsulated ESP:
Rule #1 causes all packets sent by the phone to SGIP to remain outside the VPN tunnel
(i.e., IKE/ISAKMP; IPsec packets are sent to SGIP, but they are the output resulting from packets addressed to other IP addresses being processed by IPsec).
Rule #2 causes IPsec packets received from SGIP to be processed by IPsec.
Rule #3 causes any other packets received from SGIP (i.e., IKE/ISAKMP) to not be processed by IPsec.
Rule #4a causes DHCPINFORM messages sent by the phone to go inside the VPN tunnel
(a DHCPACK sent in response would be processed per Rule #2).
Rule #4b causes DHCP packets sent by the phone to remain outside the VPN tunnel.
Rule #5 causes DHCP packets received by the phone to notbe processed by IPsec
(the 46xx did not have this rule, so they would only process received DHCP packets if DROPCLEAR was set to 0).
Rules based on NVIPSECSUBNET cause packets sent by the phone to any IP address in one of the specified protected ranges to be processed by IPsec.
The last rule is applied to a packet only if none of the other rules in the SPD have been applied:
if DROPCLEAR = 1, all other packets will be discarded, and
if DROPCLEAR = 0, all other packets will be processed, but not by IPsec.
Rationale:
Section 4.4 of RFC 2401 indicates that separate SPDs should be maintained for inbound and outbound traffic due to the directionality of the source and destination port numbers and IP addresses, however, the requirement above for a single database should work, and it was carried over from the 46xx VPN phone requirements in case it better reflects the implementation. Rule 5 and the rules based on the values of NVIPSECSUBNET were not in the 46xx VPN phone requirement, but they seem to be needed. If separate SPDs were maintained, rules 1, 4, and the rules based on NVIPSECSUBNET would be in the outbound SPD, and rules 2, 3 and 5 would be in the inbound SPD. The last rule would apply to both.
A rule is not needed for DNS traffic to the Internet Service Provider network, because DNS is only used to resolve VPN Security Gateway DNS names before IPsec is active.
Some VPN clients may use the subnet mask for the corporate intranet, along with the “inner” IP address, to create a rule for applying IPsec to packets being sent to other IP addresses on that network, but that would only work if the intranet IP addresses were all on the same subnet. However, most enterprise intranets consist of more than one subnet, and in most cases, after VPN establishment, all traffic from an IP telephone should be processed by IPsec, which is supported by the default value of NVIPSECSUBNET (“0.0.0.0/0”). However, if it is desired to have some traffic go directly to the Internet (e.g., a URL for a WML web page, or possibly SRTP-encrypted audio streams to endpoints that are not on the corporate intranet), the “protected” subnets would have to be specified by NVIPSECSUBNET.
Approved
When constructing outbound IPsec packets (see Section 5.1.2 of IETF RFC 2401):
if the value of the parameter NVVPNCOPYTOS is “1”, the value of the TOS bits will be copied from the inner IP header to the outer IP header, otherwise the TOS bits of the outer IP header will be set to 0,
the value of the DF bit will be copied from the inner IP header to the outer IP header, and
the TTL of the inner IP header will not be decremented because the telephone is the originator and the encapsulator of the inner header.
If the value of NVVPNENCAPS is “1”, UDP encapsulation of the “inner” IP layer will not be provided. However, if the value of NVVPNENCAPS is not “1”, UDP encapsulation of the “inner” IP layer will be supported as specified in RFC 3948 [7.3-41c], using the same UDP source and destination port numbers that were used during the final phase of IKE.
Note:
The value of NVVPNENCAPS also controls the port numbers used for IKE and the negotiation of NAT traversal, as specified in 96x1H-IPI.5.1.320.
Rationale:
The 46xx VPN phone R/FS also required support of all of the Internet Drafts that led up to RFC 3948 (i.e., draft-ietf-ipsec-udp-encaps-00.txt through draft-ietf-ipsec-udp-encaps-08.txt), but it seemed unreasonable to expect development or system verification to try to figure out what, if any, alternate operation might be implied by such a requirement, so the requirement to support them was eliminated until or unless specific important variations can be identified.
96x1H-IPI.5.1.320: Internet Key Exchange (IKE, including ISAKMP)
Approved
The IP Security Domain of Interpretation will be supported as specified in RFC 2407 [7.3-40a],
ISAKMP will be supported as specified in IETF RFC 2408 [7.3-40b],
the ISAKMP configuration method will be supported as specified in [7.3-40c],
IKEv1 will be supported for IPv4 only as specified in IETF RFC 2409 [7.3-40d],
XAUTH will be supported as specified in [7.3-40i], and
Hybrid Authentication will be supported as specified in [7.3-40j],
all unless clarified or specified otherwise below.
Note:
ISAKMP (Internet Security Association and Key Management Protocol) provides a framework of message exchanges for key management that is independent of the specific cryptographic mechanisms used to create the keys. IKE is a specific implementation that uses ISAKMP. Therefore, the requirements for both, as well as additional requirements from related RFCs and drafts that relate to their operation are combined in this requirement. In fact, the specification for IKEv2 (RFC4306) combines the requirements for ISAKMP, IKE, NAT traversal, and configuration into a single document.
Rationale:
The 46xx VPN phone R/FS [7.1-28] also required support of Internet Draft draft-ietf-ipsec-isakmp-mode-cfg-04 that preceded [7.3-40c], as well as beaulieu-ike-xauth-02 and draft-ietf-ipsec-isakmp-xauth-03 through draft-ietf-ipsec-isakmp-xauth-05 that led up to [7.3-40i], but it seemed unreasonable to expect development or system verification to try to figure out what, if any, alternate operation might be implied by such a requirement, so the requirement to support them was eliminated until or unless specific important variations can be identified.
The publication of IKEv2 (RFC 4306) has made IKEv1 (RFC 2409) obsolete, but support for IKEv1 is still required to maintain interoperability with existing VPN gateway implementations.
Note:
The transport protocol used for IKE / ISAKMP is determined by the parameter NVIKEOVERTCP, as specified by the flowchart in 96x1H-IPI.4.2.200, and the port numbers are determined as specified below.
Approved
If the value of NVVPNENCAPS is “0”, the procedures for the negotiation of NAT traversal will be supported as specified in IETF RFC 3947 [7.3-41b], except that IKE negotiation will begin with a source port of 2070 (instead of 500), and that source port will continue to be used unless the source and destination port numbers are changed to 4500 per RFC 3947.
If the value of NVVPNENCAPS is “1”, the procedures for the negotiation of NAT traversal specified in IETF RFC 3947 will not be supported.
If the value of NVVPNENCAPS is “2”, the procedures for the negotiation of NAT traversal will be supported as specified in IETF RFC 3947, except that IKE will use a source port of 2070, and the source and destination port numbers will not be subsequently changed.
If the value of NVVPNENCAPS is “4”, the procedures for the negotiation of NAT traversal will be supported as specified in IETF RFC 3947.
Note:
Section 2.5.1 of RFC 2408 specifies that a source and destination port number of 500 be used for ISAKMP, however, Section 4 of RFC 3947 specifies that the source and destination port numbers be changed to 4500 if a NAT device is detected.
Note:
IANA assigned port 500 for ISAKMP based on RFC 2408, it assigned port 4500 for IKE NAT traversal based on RFC 3947, and it assigned port 2070 to VPNet for UDP Encapsulation of IPsec traffic in a NATed environment.
Rationale:
An NVVPNENCAPS value of “3” was supported by the 46xx, and it specified the use of port 2070 as both the source and the destination port, but support for this value was removed at the recommendation of one of the 46xx VPN software developers, probably because it was only needed for use with some VPNet product that is no longer supported.
Approved
If the value of NVVPNENCAPS is "0", "2" or "4", when the telephone initiates IKE phase 1 for a VPN connection to establish an ISAKMP SA, Vendor ID payloads (payload type 13) with the following Vendor ID payload values will be included in the initial message:
Vendor ID Payload Value (hexadecimal)
NAT-Traversal Version
4A131C81070358455C5728F20E95452F
RFC 3947
90CB80913EBB696E086381B5EC427B1F
draft-ietf-ipsec-nat-t-ike-02
CD60464335DF21F87CFDB2FC68B6A448
draft-ietf-ipsec-nat-t-ike-02
4485152D18B6BBCD0BE8A8469579DDCC
draft-ietf-ipsec-nat-t-ike-00
4485152D18B6BBCC0BE8A8469579DDCC
draft-ietf-ipsec-nat-t-ike-00
Rationale:
The 46xx VPN phone R/FS (see 108639.2.2.350 and 108639.2.2.366 in [7.1-28]) required support of all of the Internet Drafts that led up to RFC 3947, because the drafts specified the use of some payload values that changed between drafts and for the final RFC (draft 00 is dated 10 December 2001 and RFC 3947 is dated January 2005). Many customers were (and some still are) using gateway software based on these drafts. Multiple payloads are often included for backwards compatibility.
Note:
The support of NAT-Traversal is indicated and detected through the inclusion of a Vendor ID payload (payload type 13) in the first messages of IKE Phase 1 that contain the MD5 hash of a string.
RFC 3947 specifies the use of 4A131C81070358455C5728F20E95452F,
which is the hash of “RFC 3947”.
Drafts 04 through 08 only include a placeholder for the eventual RFC payload value.
Draft 03 specifies the use of 7D9419A65310CA6F2C179D9215529D56, which is the hash of
“draft-ietf-ipsec-nat-t-ike-03”, but no equipment seems to support it.
Draft 02 specifies the use of 90CB80913EBB696E086381B5EC427B1F, which was actually an error, because it is the hash of “draft-ietf-ipsec-nat-t-ike-02\n” (the name of the Internet Draft with a newline character at the end, which was not supposed to be included in the hash), so CD60464335DF21F87CFDB2FC68B6A448 is also included above, because it is the correct hash of “draft-ietf-ipsec-nat-t-ike-02” (the name of the Internet Draft without a newline character at the end), which is supported by some VPN gateways.
Drafts 00 and 01 specify the use of 4485152D18B6BBCD0BE8A8469579DDCC, which is the hash of “draft-ietf-ipsec-nat-t-ike-00”. The last hash value included above is due to a 1-character typo of the draft 00 hash that was included in “NOS 3.x”, according to a comment in the software source code. This was probably the operating system used in VPNet VPN devices, VPNos, and as such, support could probably be discontinued.
Approved
If the telephone is the responder to an ISAKMP SA rekey exchange that includes any of the above Vendor ID payloads, the telephone will respond with the one or two Vendor ID payload(s) that correspond to the latest version of NAT-Traversal that is indicated as supported by the gateway.
Note:
The telephone is always the initiator for the initial ISAKMP SA exchange, but the VPN gateway may be the initiator when the SA is rekeyed. While it does not seem necessary to do NAT detection during a rekey exchange, RFC 3947 does not address this, although sections 3 and 4 of RFC 3947 indicate that when the original responder initiates a rekey of the ISAKMP SA, it MUST continue to use the IKE UDP ports that are already in use, which seems to imply that NAT detection should not be done again. However, some VPN gateways seem to include them anyway.
Approved
If the value of NVVPNENCAPS is "0", "2" or "4", received payloads with payload types of 15, 20 or 130 will be processed as NAT-D payloads, but NAT-D payloads will only be transmitted with the NAT-D payload type corresponding to the negotiated NAT-Traversal version, as indicated below.
NAT-D Payload Type
NAT-Traversal Version
20
RFC 3947
130
draft-ietf-ipsec-nat-t-ike-02
130
draft-ietf-ipsec-nat-t-ike-00
Rationale:
The payload type specified for NAT discovery (NAT-D) payloads has also changed between the drafts and for the final RFC.
Drafts 00 through 03 specify the use of payload type 130 for NAT-D payloads.
Drafts 04 through 08 specify the use of payload type 15 for NAT-D payloads.
RFC 3947 specifies the use of payload type 20 for NAT-D payloads.
Approved
If the value of NVVPNENCAPS is "1", only IPsec Security Associations with an Encapsulation Mode attribute value of 1 will be proposed, or accepted if received.
If the value of NVVPNENCAPS is "0", "2" or "4", IPsec Security Associations with an Encapsulation Mode attribute value of 3 or 61443 will be accepted if received, but only IPsec Security Associations with an Encapsulation Mode attribute value corresponding to the negotiated NAT-Traversal version, as indicated below, will be proposed.
IPsec
Security Association
Encapsulation Mode
NAT-Traversal Version
3
RFC 3947
61443
draft-ietf-ipsec-nat-t-ike-02
61443
draft-ietf-ipsec-nat-t-ike-00
Rationale:
Since only tunnel mode is supported for IPsec (see 96x1H-IPI.5.1.310), a Security Association Encapsulation Mode attribute value of 1 (tunnel) will be used per Section 4.5 of RFC 2407 [7.3-40a] when RFC 3974 or one of its earlier drafts is not being supported, however, when RFC 3974 or one of its earlier drafts is being supported, the Security Association Encapsulation Mode attribute value for UDP-Encapsulated-Tunnel is used, but the specific value depends on the version being supported. Drafts 00 through 03 specify the use of an attribute value of 61443.
Drafts 04 through 08 and RFC 3947 specify the use of an attribute value of 3.
Approved
NAT-OA payloads will not be sent, and payload types 16, 21 and 131 will be ignored if received.
Rationale:
RFC 3947 and its earlier drafts state “For tunnel mode, both ends SHOULD NOT send original addresses to the other end.”
Drafts 00 through 03 specify the use of payload type 131 for NAT-OA payloads.
Drafts 04 through 08 specify the use of payload type 16 for NAT-OA payloads.
RFC 3947 specifies the use of payload type 21 for NAT-OA payloads.
Approved
The ISAKMP Anti-Clogging Token (“cookie”, see Section 2.5.3 of RFC 2408) will be generated from a MD5 hash of MACADDR (see 96x1H-IPI.2.1.100) concatenated with a free-running elapsed time string with millisecond precision (but not necessarily accuracy, see 9xxxHW.2.8.100 in [7.1-2]).
Rationale:
The 46xx VPN phone R/FS (see 108639.2.2.350 in [7.1-28]) required a cookie based on the MAC address, the IP address, and a count of the number of resets since the telephone powered up: Cookie = MD5(MACADDR | NVRESETS | IPADDRESS). However, the IP address is very likely to be the same for many telephones that access the Internet through home routers that use the same private IP address space (192.168.1.x), and a reset counter only provides one digit of variability. A free-running internal clock that generates a “tick” at least once every millisecond, combined with traffic-based variable delays from the network, the DNS server (resolving the DNS name of the VPN security gateway), and the VPN security gateway itself, should produce at least as much, if not more, variability.
Approved
The following ISAKMP exchange types will be supported:
Identity Protection Exchange (see Section 4.5 in RFC 2408 [7.3-40b])
Aggressive Exchange (see Section 4.7 in RFC 2408 [7.3-40b])
Informational Exchange (see Section 4.8 in RFC 2408 [7.3-40b] and Section 5.7 in RFC 2409 [7.3-40d])
Transaction Exchange (see Section 3.1 in [7.3-40c])
Note:
The Base Exchange and the Authentication Only Exchange are not required to be supported.
Approved
The exchange method used for IKE Phase 1 will be as specified by the value of NVIKEXCHGMODE:
NVIKEXCHGMODE
IKE Phase 1 Exchange Method
“1”
Aggressive Mode (see Section 5 in RFC 2409 [7.3-40d])
“2”
Main Mode (Identity Protection, see Section 5 in RFC 2409 [7.3-40d])
New Group Mode (see Section 5.6 in RFC 2409 [7.3-40d]) will not be supported.
The following IKE attribute classes will be supported (RFC 2409 Appendix A):
Encryption Algorithm
Hash Algorithm
Authentication Method
Group Description
Life Type
Life Duration
Key Length
The encryption algorithm proposed for IKE Phase 1 will be as specified by the value of NVIKEP1ENCALG, and the encryption algorithm proposed for IPsec SAs in IKE Phase 2 will be as specified by the value of NVIKEP2ENCALG.
NVIKEP1ENCALG
NVIKEP2ENCALG
Encryption Algorithm
“0”
“0”
Any
“1”
“1”
AES-CBC-128 (see RFC 3602 [7.3-39i])
“2”
“2”
3DES-CBC (see RFC 2451 [7.3-39h])
“3”
“3”
DES-CBC (see RFC 2405 [7.3-39g])
“4”
“4”
AES-CBC-192 (see RFC 3602 [7.3-39i])
“5”
“5”
AES-CBC-256 (see RFC 3602 [7.3-39i])
n/a
“6”
NULL (see RFC 2410 [7.3-39q])
Approved
The hash algorithm proposed for IKE Phase 1 will be as specified by the value of NVIKEP1AUTHALG, and the hash algorithm proposed for IPsec SAs in IKE Phase 2 will be as specified by the value of NVIKEP2AUTHALG.
NVIKEP1AUTHALG
NVIKEP2AUTHALG
Hash Algorithm
“0”
“0”
Any
“1”
“1”
MD5 (see RFC 2403 [7.3-39e])
“2”
“2”
SHA (see RFC 2404 [7.3-39f])
The authentication method used will be as specified by the value of NVVPNAUTHTYPE unless the value of NVVPNSVENDOR is “5” (Nortel):
NVVPNAUTHTYPE
Authentication Method
“3”
Pre-Shared Key (PSK, see Section 5.4 in RFC 2409 [7.3-40d])
“4”
PSK with XAUTH (XAUTHInitPreShared, see Section 5 in [7.3-40i])
“5”
RSA signatures with XAUTH (XAUTHInitRSA, see Section 5 in [7.3-40i])
“6”
Hybrid XAUTH (HybridInitRSA, see Section 3.2.1 in [7.3-40j])
“7”
RSA Signatures (see Section 5.1 in RFC 2409 [7.3-40d])
If the value of NVVPNAUTHTYPE is “3” or “4”, the value of NVIKEID will be used for the identity (group name), and the value of NVIKEPSK will be used for the pre-shared key.
If the value of NVVPNAUTHTYPE is “4”, “5” or “6” and the value of NVXAUTH is “1”, XAUTH user authentication will be enabled. If the value of NVVPNAUTHTYPE is not “4”, “5” or “6” or if the value of NVXAUTH is “2”, XAUTH user authentication will be disabled.
Note:
NVVPNAUTHTYPE values of “1” and “2” only apply to Avaya Security Gateways, and probably should have been specified by a separate parameter similar to NORTELAUTH. However, because they are not, if NVVPNSVENDOR is set to “0” (Avaya), the value of NVVPNAUTHTYPE should be forced to “2” if it is not already equal to “1” or “2”, and if the value of NVVPNSVENDOR is not set to “0”, the value of NVVPNAUTHTYPE should be forced to a value other than “1” or “2”
(see 96x1H-IPI.4.2.200).
Approved
If the value of NVVPNSVENDOR is “5” (Nortel), ISAKMP, IKE and authentication will also comply with Sections 7-10 of [7.9-1], and the user authentication method will be as specified by the value of NORTELAUTH:
If the value of NVVPNSVENDOR is "5" (Nortel) and the value of NORTELAUTH is "1", PSK will be used, the value of NVVPNUSER will be used for the identity, and the value of NVVPNPSWD will be used as the pre-shared key.
If the value of NVVPNSVENDOR is "5" (Nortel) and the value of NORTELAUTH is "2", "3" or "4", PSK with XAUTH will be used, the values of NVIKEID and NVIKEPSK will be used for PSK, and the values of NVVPNUSER and NVVPNPSWD will be used for XAUTH.
Approved
The DH Group Description proposed for IKE Phase 1 will be as specified by the value of NVIKEDHGRP:
NVIKEDHGRP
DH Group
“1”
First Oakley Group (see Section 6.1 in RFC 2409 [7.3-40d])
“2”
Second Oakley Group (see Section 6.2 in RFC 2409 [7.3-40d])
“5”
1536-bit MODP Group (see Section 2 in RFC 3526 [7.3-40h])
“14”
2048-bit MODP Group (see Section 3 in RFC 3526 [7.3-40h])
“15”
3072-bit MODP Group (see Section 4 in RFC 3526 [7.3-40h])
If the value of NVPFSDHGRP is not “0”, a new Diffie-Hellman exchange will be initiated for each IKE Phase 2 Quick Mode exchange, where the proposed DH group will be as specified by the value of NVPFSDHGRP, and the meaning of the values will be the same as those specified above for NVIKEDHGRP.
The proposed Life Type will be “seconds”, the Life Duration will be based on the value of NVIKEP1LIFESEC for IKE Phase 1, and the Life Duration will be based on the value of NVIKEP2LIFESEC for IKE Phase 2.
When the remaining lifetime of an IPsec Security Association that is allowed to be refreshed/rekeyed (see Sections 4.4.3 (at the bottom of p.22) and 4.6.2 in IETF RFC 2401 [7.3-39a]) becomes less than 20% of the original lifetime in either seconds or bytes, the establishment of a new Security Association will be initiated.
Note:
Since the minimum lifetime of an IPsec SA (as specified for the valid values of NVIKEP2LIFESEC) is 600 seconds (10 minutes), rekeying would not happen more often than every 8 minutes.
Approved
If the value of NVIKECONFIGMODE is “1”, the ISAKMP configuration method will be supported as specified in [7.3-40c] for setting the following values:
IPADD will be set from a received value of INTERNAL_IP4_ADDRESS,
the IPADD lease time will be set from a received value of INTERNAL_ADDRESS_EXPIRY,
DNSSRVR will be set from received value(s) of INTERNAL_IP4_DNS,
DHCPSRVR will be set from received value(s) of INTERNAL_IP4_DHCP, and
NVIPSECSUBNET will be set from received value(s) of INTERNAL_IP4_SUBNET.
The Identification Type (see Section 4.6.2.1 of RFC 2407) used for IKE Phase 1 will be as specified by the value of NVIKEIDTYPE:
NVIKEIDTYPE
Identification Type
“1”
ID_IPV4_ADDR
“2”
ID_FQDN
“3”
ID_USER_FQDN
“9”
ID_DER_ASN1_DN
“11”
ID_KEY_ID
The following Identification Type values will be supported for IKE Phase 2:
ID_IPV4_ADDR
ID_IPV4_ADDR_SUBNET
Approved
The following Security Protocol Identifier (see Section 4.4.1 of RFC 2407) and Transform Identifier (see Sections 4.4.2 – 4.4.5 of RFC 2407) combinations will be supported:
Security Protocol Identifier
Transform Identifiers
PROTO_ISAKMP
KEY_IKE
PROTO_IPSEC_AH
AH_MD5
AH_SHA
PROTO_IPSEC_ESP
ESP_DES
ESP_3DES
ESP_NULL
ESP_AES (with a Key Length of 128, 192 and 256; see Section 7 of RFC 3602 [7.3-39i])
PROTO_IP_COMP
IPCOMP_LZS (see RFC 2395 [7.3-38c])
The Security Association payload will be sent as the first payload in ISAKMP messages. However, the Security Association payload need not be the first payload in received ISAKMP messages.
Rationale:
Sending the Security Association payload first is recommended in Section 4.1 of RFC 2408 [7.3-40b].
Approved
MACADDR (see 96x1H-IPI.2.1.100) will be used as a component for generating an SPI for an inbound SA (see RFC 2401, Sections 4.4.3 and 4.7).
Rationale:
The above requirement is to address a bug in the Avaya Security Gateway implementation by virtually eliminating the probability of an SPI conflict with an SPI generated by another client.
Approved
If a Certificate Payload (see Section 3.9 in RFC 2408 [7.3-40b]) is received with any Certificate Encoding value other than 1 (PKCS #7 wrapped X.509 certificate), IKE Phase 1 negotiation will fail, and an Informational Exchange will be initiated that contains a Notification Payload with an INVALID-CERT-ENCODING message type (see Section 5.9 in RFC 2408 [7.3-40b]).
If the Certificate Data is invalid or improperly formatted, IKE Phase 1 negotiation will fail, and an Informational Exchange will be initiated that contains a Notification Payload with an INVALID-CERTIFICATE message type (see Section 5.9 in RFC 2408 [7.3-40b]).
If the received Certificate Encoding value is 1 and the Certificate Data is valid and properly formatted, the certificate will be saved in the Phase 1 negotiation context.
If a Signature Payload (see Section 3.12 in RFC 2408 [7.3-40b]) is received, each of the certificates saved in the Phase 1 negotiation context will be used to attempt to verify the signature.
If the signature cannot be verified, IKE Phase 1 negotiation will fail, and an Informational Exchange will be initiated that contains a Notification Payload with an INVALID-SIGNATURE message type (see Section 5.12 in RFC 2408 [7.3-40b]).
If the signature is verified by one of the Peer Certificates, and if a certificate chain can be created for that Peer Certificate using other certificates saved in the Phase 1 negotiation context, the certificate chain will be authenticated per 96x1H-IPI.5.1.1550.
If a certificate chain cannot be created or authenticated, IKE Phase 1 negotiation will fail, and an Informational Exchange will be initiated that contains a Notification Payload with an AUTHENTICATION-FAILED message type (see Section 5.12 in RFC 2408 [7.3-40b]).
Approved
If a Notification Payload (see Section 3.14 in RFC 2408 [7.3-40b]) is received that is encrypted, it will be accepted for further processing.
If a Notification Payload is received that is not encrypted, it will be ignored if the value of ALWCLRNOTIFY is “0”, and it will be accepted for further processing if the value of ALWCLRNOTIFY is “1”.
If a Notification Payload with an INVALID-SPI message type is accepted for further processing, it will be ignored if an INVALID-SPI Notification was received for the same SPI within the last 2 minutes, otherwise, the IPsec SA identified by the INVALID-SPI Notification will be deleted and the establishment of a new IPSec SA with a new SPI will be initiated.
If a Notification Payload with an INVALID-COOKIE message type is accepted for further processing, all of the currently active ISAKMP SAs with the peer from which the INVALID-COOKIE Notification was received will be deleted.
If a Notification Payload with a Private Use message type of 32800 is received, the Notification Data will be treated as a SAP challenge.
Issue:
What is a SAP challenge, and where is it specified?
Note:
An INVALID-SPI notification will most likely be sent in the clear.
Rationale:
The SA or SAs are deleted for faster resynchronization after a peer has restarted.
