If the initiator requires the assignment of an IP address, it will
treat a response without CFG_REPLY as an error.
A second case is where the responder does support configuration
payloads, but only for particular type of addresses (IPv4 or IPv6).
Section 4 says that "A minimal IPv4 responder implementation will
ignore the contents of the CP payload except to determine that it
includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the
initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
IPv6 part and process the IPv4 request as usual.
A third case is where the initiator requests multiple addresses of a
type that the responder supports: what should happen if some (but not
all) of the requests fail? It seems that an optimistic approach
would be the best one here: if the responder is able to assign at
least one address, it replies with those; it sends
INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
(References: "ikev2 and internal_ivpn_address" thread, June 2005.)
7. Miscellaneous Issues
7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR
When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
payloads, IKEv2 does not require this address to match anything in
the TSi/TSr payloads. For example, in a site-to-site VPN between two
security gateways, the gateways could authenticate each other as
ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create
a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host
behind the first security gateway) and 192.0.2.240/28 (a network
behind the second security gateway). The authenticated identities
(IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr)
using "Child SA Authorization Data" in the Peer Authorization
Database (PAD).
Furthermore, IKEv2 does not require that the addresses in
ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
IKE packets. However, other specifications may place additional
requirements regarding this. For example, [PKI4IPsec] requires that
implementation must be capable of comparing the addresses in the
ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
IKE packets, and this comparison must be enabled by default.
(References: "Identities types IP address,FQDN/user FQDN and DN and
its usage in preshared key authentication" thread, Jan 2005.
"Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
7.2. Relationship of IKEv2 to RFC 4301
The IKEv2 specification refers to [RFC4301], but it never clearly
defines the exact relationship.
However, there are some requirements in the specification that make
it clear that IKEv2 requires [RFC4301]. In other words, an
implementation that does IPsec processing strictly according to
[RFC2401] cannot be compliant with the IKEv2 specification.
One such example can be found in Section 2.24: "Specifically, tunnel
encapsulators and decapsulators for all tunnel-mode SAs created by
IKEv2 [...] MUST implement the tunnel encapsulation and
decapsulation processing specified in [RFC4301] to prevent discarding
of ECN congestion indications."
Nevertheless, the changes required to existing [RFC2401]
implementations are not very large, especially since supporting many
of the new features (such as Extended Sequence Numbers) is optional.
7.3. Reducing the Window Size
In IKEv2, the window size is assumed to be a (possibly configurable)
property of a particular implementation and is not related to
congestion control (unlike the window size in TCP, for instance).
In particular, it is not defined what the responder should do when it
receives a SET_WINDOW_SIZE notification containing a smaller value
than is currently in effect. Thus, there is currently no way to
reduce the window size of an existing IKE_SA. However, when rekeying
an IKE_SA, the new IKE_SA starts with window size 1 until it is
explicitly increased by sending a new SET_WINDOW_SIZE notification.
(References: Tero Kivinen’s mail "Comments of
draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
7.4. Minimum Size of Nonces
Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
MUST be at least 128 bits in size, and MUST be at least half the key
size of the negotiated prf."
However, the initiator chooses the nonce before the outcome of the
negotiation is known. In this case, the nonce has to be long enough
for all the PRFs being proposed.
7.5. Initial Zero Octets on Port 4500
It is not clear whether a peer sending an IKE_SA_INIT request on port
4500 should include the initial four zero octets. Section 2.23 talks
about how to upgrade to tunneling over port 4500 after message 2, but
it does not say what to do if message 1 is sent on port 4500.
IKE MUST listen on port 4500 as well as port 500.
[...]
The IKE initiator MUST check these payloads if present and if
they do not match the addresses in the outer packet MUST tunnel
all future IKE and ESP packets associated with this IKE_SA over
UDP port 4500.
To tunnel IKE packets over UDP port 4500, the IKE header has four
octets of zero prepended and the result immediately follows the
UDP header. [...]
The very beginning of Section 2 says "... though IKE messages may
also be received on UDP port 4500 with a slightly different format
(see section 2.23)."
That "slightly different format" is only described in discussing what
to do after changing to port 4500. However, [RFC3948] shows clearly
the format has the initial zeros even for initiators on port 4500.
Furthermore, without the initial zeros, the processing engine cannot
determine whether the packet is an IKE packet or an ESP packet.
Thus, all packets sent on port 4500 need the four-zero prefix;
otherwise, the receiver won’t know how to handle them.
7.6. Destination Port for NAT Traversal
Section 2.23 says that "an IPsec endpoint that discovers a NAT
between it and its correspondent MUST send all subsequent traffic to
and from port 4500".
This sentence is misleading. The peer "outside" the NAT uses source
port 4500 for the traffic it sends, but the destination port is, of
course, taken from packets sent by the peer behind the NAT. This
port number is usually dynamically allocated by the NAT.
7.7. SPI Values for Messages outside an IKE_SA
The IKEv2 specification is not quite clear what SPI values should be
used in the IKE header for the small number of notifications that are
allowed to be sent outside an IKE_SA. Note that such notifications
are explicitly not Informational exchanges; Section 1.5 makes it
clear that these are one-way messages that must not be responded to.
There are two cases when such a one-way notification can be sent:
INVALID_IKE_SPI and INVALID_SPI.
In case of INVALID_IKE_SPI, the message sent is a response message,
and Section 2.21 says that "If a response is sent, the response MUST
be sent to the IP address and port from whence it came with the same
IKE SPIs and the Message ID copied."
In case of INVALID_SPI, however, there are no IKE SPI values that
would be meaningful to the recipient of such a notification. Also,
the message sent is now an INFORMATIONAL request. A strict
interpretation of the specification would require the sender to
invent garbage values for the SPI fields. However, we think this was
not the intention, and using zero values is acceptable.
(References: "INVALID_IKE_SPI" thread, June 2005.)
7.8. Protocol ID/SPI Fields in Notify Payloads
Section 3.10 says that the Protocol ID field in Notify payloads "For
notifications that do not relate to an existing SA, this field MUST
be sent as zero and MUST be ignored on receipt". However, the
specification does not clearly say which notifications are related to
existing SAs and which are not.
Since the main purpose of the Protocol ID field is to specify the
type of the SPI, our interpretation is that the Protocol ID field
should be non-zero only when the SPI field is non-empty.
There are currently only two notifications where this is the case:
INVALID_SELECTORS and REKEY_SA.
7.9. Which message should contain INITIAL_CONTACT
The description of the INITIAL_CONTACT notification in Section 3.10.1
says that "This notification asserts that this IKE_SA is the only
IKE_SA currently active between the authenticated identities".
However, neither Section 2.4 nor 3.10.1 says in which message this
payload should be placed.
The general agreement is that INITIAL_CONTACT is best communicated in
the first IKE_AUTH request, not as a separate exchange afterwards.
(References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
April 2005. "Initial Contact messages" thread, December 2004.
"IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
7.10. Alignment of Payloads
Many IKEv2 payloads contain fields marked as "RESERVED", mostly
because IKEv1 had them, and partly because they make the pictures
easier to draw. In particular, payloads in IKEv2 are not, in
general, aligned to 4-octet boundaries. (Note that payloads were not
aligned to 4-octet boundaries in IKEv1 either.)
(References: "IKEv2: potential 4-byte alignment problem" thread, June
2004.)
7.11. Key Length Transform Attribute
Section 3.3.5 says that "The only algorithms defined in this document
that accept attributes are the AES based encryption, integrity, and
pseudo-random functions, which require a single attribute specifying
key width."
This is incorrect. The AES-based integrity and pseudo-random
functions defined in [IKEv2] always use a 128-bit key. In fact,
there are currently no integrity or PRF algorithms that use the key
length attribute (and we recommend that they should not be defined in
the future either).
For encryption algorithms, the situation is slightly more complex
since there are three different types of algorithms:
o The key length attribute is never used with algorithms that use a
fixed length key, such as DES and IDEA.
o The key length attribute is always included for the currently
defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
(CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
(GCM)). Omitting the key length attribute is not allowed; if the
proposal does not contain it, the proposal has to be rejected.
o For other algorithms, the key length attribute can be included but
is not mandatory. These algorithms include, e.g., RC5, CAST, and
BLOWFISH. If the key length attribute is not included, the
default value specified in [RFC2451] is used.
7.12. IPsec IANA Considerations
There are currently three different IANA registry files that contain
important numbers for IPsec: ikev2-registry, isakmp-registry, and
ipsec-registry. Implementers should note that IKEv2 may use numbers
different from those of IKEv1 for a particular algorithm.
For instance, an encryption algorithm can have up to three different
numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier"
isakmp-registry. Although some algorithms have the same number in
all three registries, the registries are not identical.
Similarly, an integrity algorithm can have at least the IKEv2
"Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2
"IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1
phase 2 ESP "Authentication Algorithm Security Association Attribute"
identifier in isakmp-registry. And there is also the IKEv1 phase 1
"Hash Algorithm" list in ipsec-registry.
This issue needs special care also when writing a specification for
how a new algorithm is used with IPsec.
7.13. Combining ESP and AH
The IKEv2 specification contains some misleading text about how ESP
and AH can be combined.
IKEv2 is based on [RFC4301], which does not include "SA bundles" that
were part of [RFC2401]. While a single packet can go through IPsec
processing multiple times, each of these passes uses a separate SA,
and the passes are coordinated by the forwarding tables. In IKEv2,
each of these SAs has to be created using a separate CREATE_CHILD_SA
exchange. Thus, the text in Section 2.7 about a single proposal
containing both ESP and AH is incorrect.
Moreover, the combination of ESP and AH (between the same endpoints)
had already become largely obsolete in 1998 when RFC 2406 was
published. Our recommendation is that IKEv2 implementations should
not support this combination, and implementers should not assume the
combination can be made to work in an interoperable manner.
(References: "Rekeying SA bundles" thread, Oct 2005.)
8. Implementation Mistakes
Some implementers at the early IKEv2 bakeoffs didn’t do everything
correctly. This may seem like an obvious statement, but it is
probably useful to list a few things that were clear in the document,
but that some implementers didn’t do. All of these things caused
interoperability problems.
o Some implementations continued to send traffic on a CHILD_SA after
it was rekeyed, even after receiving an DELETE payload.
o After rekeying an IKE_SA, some implementations did not reset their
message counters to zero. One set the counter to 2, another did
not reset the counter at all.
o Some implementations could only handle a single pair of traffic
selectors or would only process the first pair in the proposal.
o Some implementations responded to a delete request by sending an
empty INFORMATIONAL response and then initiated their own
INFORMATIONAL exchange with the pair of SAs to delete.
o Although this did not happen at the bakeoff, from the discussion
there, it is clear that some people had not implemented message
window sizes correctly. Some implementations might have sent
messages that did not fit into the responder’s message windows,
and some implementations may not have torn down an SA if they did
not ever receive a message that they know they should have.
9. Security Considerations
This document does not introduce any new security considerations to
IKEv2. If anything, clarifying complex areas of the specification
can reduce the likelihood of implementation problems that may have
security implications.
10. Acknowledgments
This document is mainly based on conversations on the IPsec WG
mailing list. The authors would especially like to thank Bernard
Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero
Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their
contributions.
In addition, the authors would like to thank all the participants of
the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
for their questions and proposed clarifications.
11. References
11.1. Normative References
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
11.2. Informative References
[Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with
Host-to-Host IPsec", 13th International Workshop on
Security Protocols, Cambridge, UK, April 2005.
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
Work in Progress, July 2006.
[IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support
Enhancements", http://www.cisco.com/univercd/cc/td/
doc/product/software/ios121/121newft/121limit/121dc/
121dc3/ipcp_msk.htm, January 2003.
[IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
IKEv2, and PKIX", Work in Progress, April 2006.
[RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 3664,
January 2004.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, January 2005.
[RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4434,
February 2006.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", RFC 822, August 1982.
[ReAuth] Nir, Y., "Repeated Authentication in Internet Key
Exchange (IKEv2) Protocol", RFC 4478, April 2006.
[SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
T. Polk, "Simple Certificate Validation Protocol
(SCVP)", Work in Progress, June 2006.
Appendix A. Exchanges and Payloads
This appendix contains a short summary of the IKEv2 exchanges, and
what payloads can appear in which message. This appendix is purely
informative; if it disagrees with the body of this document or the
IKEv2 specification, the other text is considered correct.
Vendor-ID (V) payloads may be included in any place in any message.
This sequence shows what are, in our opinion, the most logical places
for them.
The specification does not say which messages can contain
N(SET_WINDOW_SIZE). It can possibly be included in any message, but
it is not yet shown below.
A.1. IKE_SA_INIT Exchange
request --> [N(COOKIE)],
SA, KE, Ni,
[N(NAT_DETECTION_SOURCE_IP)+,
N(NAT_DETECTION_DESTINATION_IP)],
[V+]
normal response <-- SA, KE, Nr,
(no cookie) [N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[V+]
A.2. IKE_AUTH Exchange without EAP
request --> IDi, [CERT+],
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
AUTH,
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[V+]
response <-- IDr, [CERT+],
AUTH,
[CP(CFG_REPLY)],
[N(IPCOMP_SUPPORTED)],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],
SA, TSi, TSr,
[N(ADDITIONAL_TS_POSSIBLE)],
[V+]
A.3. IKE_AUTH Exchange with EAP
first request --> IDi,
[N(INITIAL_CONTACT)],
[[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
[IDr],
[CP(CFG_REQUEST)],
[N(IPCOMP_SUPPORTED)+],
[N(USE_TRANSPORT_MODE)],
[N(ESP_TFC_PADDING_NOT_SUPPORTED)],
[N(NON_FIRST_FRAGMENTS_ALSO)],