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

   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.

   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)

        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

   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

   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.

   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

   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.)

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)],
                           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+]

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)]

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

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).