Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4718

IKEv2 Clarifications and Implementation Guidelines

Pages: 58
Obsoleted by:  5996
Part 3 of 3 – Pages 37 to 58
First   Prev   None

ToP   noToC   RFC4718 - Page 37   prevText

6. Configuration Payloads

6.1. Assigning IP Addresses

Section 2.9 talks about traffic selector negotiation and mentions that "In support of the scenario described in section 1.1.3, an initiator may request that the responder assign an IP address and tell the initiator what it is." This sentence is correct, but its placement is slightly confusing. IKEv2 does allow the initiator to request assignment of an IP address from the responder, but this is done using configuration payloads, not traffic selector payloads. An address in a TSi payload in a response does not mean that the responder has assigned that address to the initiator; it only means that if packets matching these traffic selectors are sent by the initiator, IPsec processing can be performed as agreed for this SA. The TSi payload itself does not give the initiator permission to configure the initiator's TCP/IP stack with the address and use it as its source address. In other words, IKEv2 does not have two different mechanisms for assigning addresses, but only one: configuration payloads. In the scenario described in Section 1.1.3, both configuration and traffic selector payloads are usually included in the same message, and they
ToP   noToC   RFC4718 - Page 38
   often contain the same information in the response message (see
   Section 6.3 of this document for some examples).  However, their
   semantics are still different.

6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS

When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section 3.15.1 says that "In a request message, the address specified is a requested address (or zero if no specific address is requested)". The question here is whether "zero" means an address "0.0.0.0" or a zero-length string. Earlier, the same section also says that "If an attribute in the CFG_REQUEST Configuration Payload is not zero-length, it is taken as a suggestion for that attribute". Also, the table of configuration attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0 or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17 octets". Thus, if the client does not request a specific address, it includes a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute containing an all-zeroes address. The example in 2.19 is thus incorrect, since it shows the attribute as "INTERNAL_ADDRESS(0.0.0.0)". However, since the value is only a suggestion, implementations are recommended to ignore suggestions they do not accept; or in other words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS, "0.0.0.0", and any other addresses the implementation does not recognize as a reasonable suggestion.

6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET

Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected sub-networks that this edge-device protects. This attribute is made up of two fields: the first is an IP address and the second is a netmask. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes." INTERNAL_IP6_SUBNET is defined in a similar manner. This raises two questions: first, since this information is usually included in the TSr payload, what functionality does this attribute add? And second, what does this attribute mean in CFG_REQUESTs? For the first question, there seem to be two sensible interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA response) indicates which subnets are accessible through the SA that was just created.
ToP   noToC   RFC4718 - Page 39
   The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
   that they indicate additional subnets that can be reached through
   this gateway, but need a separate SA.  According to this
   interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
   mainly when they contain addresses not included in TSr.

   The second interpretation is that the INTERNAL_IP4/6_SUBNET
   attributes express the gateway's policy about what traffic should be
   sent through the gateway.  The client can choose whether other
   traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
   through the gateway or directly to the destination.  According to
   this interpretation, the attributes are useful mainly when TSr
   contains addresses not included in the INTERNAL_IP4/6_SUBNET
   attributes.

   It turns out that these two interpretations are not incompatible, but
   rather two sides of the same principle: traffic to the addresses
   listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
   this gateway.  If there are no existing IPsec SAs whose traffic
   selectors cover the address in question, new SAs have to be created.

   A couple of examples are given below.  For instance, if there are two
   subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
   contains the following:

        CP(CFG_REQUEST) =
          INTERNAL_IP4_ADDRESS()
        TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
        TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

   Then a valid response could be the following (in which TSr and
   INTERNAL_IP4_SUBNET contain the same information):

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
               (0, 0-65535, 192.0.2.0-192.0.2.255))

   In these cases, the INTERNAL_IP4_SUBNET does not really carry any
   useful information.  Another possible reply would have been this:

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
ToP   noToC   RFC4718 - Page 40
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

   This would mean that the client can send all its traffic through the
   gateway, but the gateway does not mind if the client sends traffic
   not included by INTERNAL_IP4_SUBNET directly to the destination
   (without going through the gateway).

   A different situation arises if the gateway has a policy that
   requires the traffic for the two subnets to be carried in separate
   SAs.  Then a response like this would indicate to the client that if
   it wants access to the second subnet, it needs to create a separate
   SA:

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)

   INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
   only part of the address space.  For instance, if the client requests
   the following:

        CP(CFG_REQUEST) =
          INTERNAL_IP4_ADDRESS()
        TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
        TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

   Then the gateway's reply could be this:

        CP(CFG_REPLY) =
          INTERNAL_IP4_ADDRESS(192.0.1.234)
          INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
          INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
        TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
        TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

   It is less clear what the attributes mean in CFG_REQUESTs, and
   whether other lengths than zero make sense in this situation (but for
   INTERNAL_IP6_SUBNET, zero length is not allowed at all!).  This
   document recommends that implementations should not include
   INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
   CFG_REQUESTs.

   For the IPv4 case, this document recommends using only netmasks
   consisting of some amount of "1" bits followed by "0" bits; for
ToP   noToC   RFC4718 - Page 41
   instance, "255.0.255.0" would not be a valid netmask for
   INTERNAL_IP4_SUBNET.

   It is also worthwhile to note that the contents of the INTERNAL_IP4/
   6_SUBNET attributes do not imply link boundaries.  For instance, a
   gateway providing access to a large company intranet using addresses
   from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
   attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
   routers and separate links.

   (References: Tero Kivinen's mail "Intent of couple of attributes in
   Configuration Payload in IKEv2?", 2004-11-19.  Srinivasa Rao
   Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
   IKEv2", 2004-09-10.  Yoav Nir's mail "Re: New I-D: IKEv2
   Clarifications and Implementation Guidelines", 2005-02-07.
   "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
   April 2005.)

6.4. INTERNAL_IP4_NETMASK

Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says that "The internal network's netmask. Only one netmask is allowed in the request and reply messages (e.g., 255.255.255.0) and it MUST be used only with an INTERNAL_IP4_ADDRESS attribute". However, it is not clear what exactly this attribute means, as the concept of "netmask" is not very well defined for point-to-point links (unlike multi-access links, where it means "you can reach hosts inside this netmask directly using layer 2, instead of sending packets via a router"). Even if the operating system's TCP/IP stack requires a netmask to be configured, for point-to-point links it could be just set to 255.255.255.255. So, why is this information sent in IKEv2? One possible interpretation would be that the host is given a whole block of IP addresses instead of a single address. This is also what Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed- IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the specification supports this interpretation, and discussions on the IPsec WG mailing list have confirmed it was not intended. Section 3.15.1 also says that multiple addresses are assigned using multiple INTERNAL_IP4/6_ADDRESS attributes. Currently, this document's interpretation is the following: INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET containing the same information ("send traffic to these addresses through me"), but also implies a link boundary. For
ToP   noToC   RFC4718 - Page 42
   instance, the client could use its own address and the netmask to
   calculate the broadcast address of the link.  (Whether the gateway
   will actually deliver broadcast packets to other VPN clients and/or
   other nodes connected to this link is another matter.)

   An empty INTERNAL_IP4_NETMASK attribute can be included in a
   CFG_REQUEST to request this information (although the gateway can
   send the information even when not requested).  However, it seems
   that non-empty values for this attribute do not make sense in
   CFG_REQUESTs.

   Fortunately, Section 4 clearly says that a minimal implementation
   does not need to include or understand the INTERNAL_IP4_NETMASK
   attribute, and thus this document recommends that implementations
   should not use the INTERNAL_IP4_NETMASK attribute or assume that the
   other peer supports it.

   (References: Charlie Kaufman's mail "RE: Proposed Last Call based
   revisions to IKEv2", 2004-05-27.  Email discussion with Tero Kivinen,
   Jan 2005.  Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
   Implementation Guidelines", 2005-02-07.  "Clarifications open issue:
   INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)

6.5. Configuration Payloads for IPv6

IKEv2 also defines configuration payloads for IPv6. However, they are based on the corresponding IPv4 payloads and do not fully follow the "normal IPv6 way of doing things". A client can be assigned an IPv6 address using the INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could look like this: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() INTERNAL_IP6_DNS() TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) In particular, IPv6 stateless autoconfiguration or router advertisement messages are not used; neither is neighbor discovery.
ToP   noToC   RFC4718 - Page 43
   The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
   in the CFG_REQUEST to request a specific address or interface
   identifier.  The gateway first checks if the specified address is
   acceptable, and if it is, returns that one.  If the address was not
   acceptable, the gateway will attempt to use the interface identifier
   with some other prefix; if even that fails, the gateway will select
   another interface identifier.

   The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
   field.  When used in a CFG_REPLY, this corresponds to the
   INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
   called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
   See the previous section for more details.

   While this approach to configuring IPv6 addresses is reasonably
   simple, it has some limitations: IPsec tunnels configured using IKEv2
   are not fully-featured "interfaces" in the IPv6 addressing
   architecture [IPv6Addr] sense.  In particular, they do not
   necessarily have link-local addresses, and this may complicate the
   use of protocols that assume them, such as [MLDv2].  (Whether they
   are called "interfaces" in some particular operating system is a
   different issue.)

   (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
   "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
   April 2005.)

6.6. INTERNAL_IP6_NBNS

Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending the IPv6 address of NetBIOS name servers. However, NetBIOS is not defined for IPv6 and probably never will be. Thus, this attribute most likely does not make much sense. (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS) BoF at IETF62.)

6.7. INTERNAL_ADDRESS_EXPIRY

Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply." Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when
ToP   noToC   RFC4718 - Page 44
   the client has gone away.  However, in IKEv2 this is known, and the
   gateway can simply free the address when the IKE_SA is deleted.

   Also, Section 4 says that supporting renewals is not mandatory.
   Given that this functionality is usually not needed, we recommend
   that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
   (And since this attribute does not seem to make much sense for
   CFG_REQUESTs, clients should not send it either.)

   Note that according to Section 4, clients are required to understand
   INTERNAL_ADDRESS_EXPIRY if they receive it.  A minimum implementation
   would use the value to limit the lifetime of the IKE_SA.

   (References: Tero Kivinen's mail "Comments of
   draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
   "Questions about internal address" thread, April 2005.)

6.8. Address Assignment Failures

If the responder encounters an error while attempting to assign an IP address to the initiator, it responds with an INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1. However, there are some more complex error cases. First, if the responder does not support configuration payloads at all, it can simply ignore all configuration payloads. This type of implementation never sends INTERNAL_ADDRESS_FAILURE notifications. 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.)
ToP   noToC   RFC4718 - Page 45

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.
ToP   noToC   RFC4718 - Page 46

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. [...]
ToP   noToC   RFC4718 - Page 47
   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.)
ToP   noToC   RFC4718 - Page 48

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."
ToP   noToC   RFC4718 - Page 49
   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.
ToP   noToC   RFC4718 - Page 50

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
ToP   noToC   RFC4718 - Page 51
      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.
ToP   noToC   RFC4718 - Page 52

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.
ToP   noToC   RFC4718 - Page 53
   [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.
ToP   noToC   RFC4718 - Page 54

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+]
ToP   noToC   RFC4718 - Page 55
   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)], SA, TSi, TSr, [V+] first response <-- IDr, [CERT+], AUTH, EAP, [V+] / --> EAP repeat 1..N times | \ <-- EAP last request --> AUTH last response <-- 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+]
ToP   noToC   RFC4718 - Page 56

A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs

request --> [N(REKEY_SA)], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, Ni, [KEi], TSi, TSr response <-- [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, Nr, [KEr], TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)]

A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA

request --> SA, Ni, [KEi] response <-- SA, Nr, [KEr]

A.6. INFORMATIONAL Exchange

request --> [N+], [D+], [CP(CFG_REQUEST)] response <-- [N+], [D+], [CP(CFG_REPLY)]
ToP   noToC   RFC4718 - Page 57

Authors' Addresses

Pasi Eronen Nokia Research Center P.O. Box 407 FIN-00045 Nokia Group Finland EMail: pasi.eronen@nokia.com Paul Hoffman VPN Consortium 127 Segre Place Santa Cruz, CA 95060 USA EMail: paul.hoffman@vpnc.org
ToP   noToC   RFC4718 - Page 58
Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).