tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4718

 
 
 

IKEv2 Clarifications and Implementation Guidelines

Part 2 of 3, p. 14 to 37
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 14 
4.  Creating CHILD_SAs

4.1.  Creating SAs with the CREATE_CHILD_SA Exchange

   Section 1.3's organization does not lead to clear understanding of
   what is needed in which environment.  The section can be reorganized
   with subsections for each use of the CREATE_CHILD_SA exchange
   (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)

   The new Section 1.3 with subsections and the above changes might look
   like the following.

   NEW-1.3 The CREATE_CHILD_SA Exchange

        The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
        to rekey both IKE_SAs and CHILD_SAs.  This exchange consists of
        a single request/response pair, and some of its function was
        referred to as a phase 2 exchange in IKEv1.  It MAY be initiated
        by either end of the IKE_SA after the initial exchanges are
        completed.

        All messages following the initial exchange are
        cryptographically protected using the cryptographic algorithms
        and keys negotiated in the first two messages of the IKE
        exchange.  These subsequent messages use the syntax of the
        Encrypted Payload described in section 3.14.  All subsequent
        messages include an Encrypted Payload, even if they are referred
        to in the text as "empty".

        The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
        This section describes the first part of rekeying, the creation
        of new SAs; Section 2.8 covers the mechanics of rekeying,
        including moving traffic from old to new SAs and the deletion of
        the old SAs.  The two sections must be read together to
        understand the entire process of rekeying.

Top      Up      ToC       Page 15 
        Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
        this section the term initiator refers to the endpoint
        initiating this exchange.  An implementation MAY refuse all
        CREATE_CHILD_SA requests within an IKE_SA.

        The CREATE_CHILD_SA request MAY optionally contain a KE payload
        for an additional Diffie-Hellman exchange to enable stronger
        guarantees of forward secrecy for the CHILD_SA or IKE_SA.  The
        keying material for the SA is a function of SK_d established
        during the establishment of the IKE_SA, the nonces exchanged
        during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
        value (if KE payloads are included in the CREATE_CHILD_SA
        exchange).  The details are described in sections 2.17 and 2.18.

        If a CREATE_CHILD_SA exchange includes a KEi payload, at least
        one of the SA offers MUST include the Diffie-Hellman group of
        the KEi.  The Diffie-Hellman group of the KEi MUST be an element
        of the group the initiator expects the responder to accept
        (additional Diffie-Hellman groups can be proposed).  If the
        responder rejects the Diffie-Hellman group of the KEi payload,
        the responder MUST reject the request and indicate its preferred
        Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
        payload.  In the case of such a rejection, the CREATE_CHILD_SA
        exchange fails, and the initiator SHOULD retry the exchange with
        a Diffie-Hellman proposal and KEi in the group that the
        responder gave in the INVALID_KE_PAYLOAD.

   NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange

        A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
        The CREATE_CHILD_SA request for creating a new CHILD_SA is:

            Initiator                                 Responder
           -----------                               -----------
            HDR, SK {[N+], SA, Ni, [KEi],
                       TSi, TSr}        -->

        The initiator sends SA offer(s) in the SA payload, a nonce in
        the Ni payload, optionally a Diffie-Hellman value in the KEi
        payload, and the proposed traffic selectors for the proposed
        CHILD_SA in the TSi and TSr payloads.  The request can also
        contain Notify payloads that specify additional details for the
        CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
        ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.

Top      Up      ToC       Page 16 
        The CREATE_CHILD_SA response for creating a new CHILD_SA is:

                                       <--    HDR, SK {[N+], SA, Nr,
                                                    [KEr], TSi, TSr}

        The responder replies with the accepted offer in an SA payload,
        and a Diffie-Hellman value in the KEr payload if KEi was
        included in the request and the selected cryptographic suite
        includes that group.  As with the request, optional Notification
        payloads can specify additional details for the CHILD_SA.

        The traffic selectors for traffic to be sent on that SA are
        specified in the TS payloads in the response, which may be a
        subset of what the initiator of the CHILD_SA proposed.

   The text about rekeying SAs can be found in Section 5.1 of this
   document.

4.2.  Creating an IKE_SA without a CHILD_SA

   CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
   exchange, or using a separate CREATE_CHILD_SA exchange.  The
   specification is not clear about what happens if creating the
   CHILD_SA during the IKE_AUTH exchange fails for some reason.

   Our recommendation in this situation is that the IKE_SA is created as
   usual.  This is also in line with how the CREATE_CHILD_SA exchange
   works: a failure to create a CHILD_SA does not close the IKE_SA.

   The list of responses in the IKE_AUTH exchange that do not prevent an
   IKE_SA from being set up include at least the following:
   NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
   INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.

   (References: "Questions about internal address" thread, April 2005.)

4.3.  Diffie-Hellman for First CHILD_SA

   Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
   Ni/Nr payloads.  This implies that the SA payload in IKE_AUTH
   exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
   any other value than NONE.  Implementations should probably leave the
   transform out entirely in this case.

Top      Up      ToC       Page 17 
4.4.  Extended Sequence Numbers (ESN) Transform

   The description of the ESN transform in Section 3.3 has be proved
   difficult to understand.  The ESN transform has the following
   meaning:

   o  A proposal containing one ESN transform with value 0 means "do not
      use extended sequence numbers".

   o  A proposal containing one ESN transform with value 1 means "use
      extended sequence numbers".

   o  A proposal containing two ESN transforms with values 0 and 1 means
      "I support both normal and extended sequence numbers, you choose".
      (Obviously this case is only allowed in requests; the response
      will contain only one ESN transform.)

   In most cases, the exchange initiator will include either the first
   or third alternative in its SA payload.  The second alternative is
   rarely useful for the initiator: it means that using normal sequence
   numbers is not acceptable (so if the responder does not support ESNs,
   the exchange will fail with NO_PROPOSAL_CHOSEN).

   Note that including the ESN transform is mandatory when creating
   ESP/AH SAs (it was optional in earlier drafts of the IKEv2
   specification).

   (References: "Technical change needed to IKEv2 before publication",
   "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
   and "Results of straw poll regarding: IKEv2 interoperability issue"
   threads, March-April 2005.)

4.5.  Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED

   The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
   Section 3.10.1 says that "This notification asserts that the sending
   endpoint will NOT accept packets that contain Flow Confidentiality
   (TFC) padding".

   However, the text does not say in which messages this notification
   should be included, or whether the scope of this notification is a
   single CHILD_SA or all CHILD_SAs of the peer.

   Our interpretation is that the scope is a single CHILD_SA, and thus
   this notification is included in messages containing an SA payload
   negotiating a CHILD_SA.  If neither endpoint accepts TFC padding,
   this notification will be included in both the request proposing an
   SA and the response accepting it.  If this notification is included

Top      Up      ToC       Page 18 
   in only one of the messages, TFC padding can still be sent in one
   direction.

4.6.  Negotiation of NON_FIRST_FRAGMENTS_ALSO

   NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
   simply as "Used for fragmentation control.  See [RFC4301] for
   explanation."

   [RFC4301] says "Implementations that will transmit non-initial
   fragments on a tunnel mode SA that makes use of non-trivial port (or
   ICMP type/code or MH type) selectors MUST notify a peer via the IKE
   NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.  The peer MUST reject this
   proposal if it will not accept non-initial fragments in this context.
   If an implementation does not successfully negotiate transmission of
   non-initial fragments for such an SA, it MUST NOT send such fragments
   over the SA."

   However, it is not clear exactly how the negotiation works.  Our
   interpretation is that the negotiation works the same way as for
   IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
   is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
   in both the request proposing an SA and the response accepting it.
   In other words, if the peer "rejects this proposal", it only omits
   NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
   reject the whole CHILD_SA creation.

4.7.  Semantics of Complex Traffic Selector Payloads

   As described in Section 3.13, the TSi/TSr payloads can include one or
   more individual traffic selectors.

   There is no requirement that TSi and TSr contain the same number of
   individual traffic selectors.  Thus, they are interpreted as follows:
   a packet matches a given TSi/TSr if it matches at least one of the
   individual selectors in TSi, and at least one of the individual
   selectors in TSr.

   For instance, the following traffic selectors:

        TSi = ((17, 100, 192.0.1.66-192.0.1.66),
               (17, 200, 192.0.1.66-192.0.1.66))
        TSr = ((17, 300, 0.0.0.0-255.255.255.255),
               (17, 400, 0.0.0.0-255.255.255.255))

   would match UDP packets from 192.0.1.66 to anywhere, with any of the
   four combinations of source/destination ports (100,300), (100,400),
   (200,300), and (200, 400).

Top      Up      ToC       Page 19 
   This implies that some types of policies may require several CHILD_SA
   pairs.  For instance, a policy matching only source/destination ports
   (100,300) and (200,400), but not the other two combinations, cannot
   be negotiated as a single CHILD_SA pair using IKEv2.

   (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)

4.8.  ICMP Type/Code in Traffic Selector Payloads

   The traffic selector types 7 and 8 can also refer to ICMP type and
   code fields.  As described in Section 3.13.1, "For the ICMP protocol,
   the two one-octet fields Type and Code are treated as a single 16-bit
   integer (with Type in the most significant eight bits and Code in the
   least significant eight bits) port number for the purposes of
   filtering based on this field."

   Since ICMP packets do not have separate source and destination port
   fields, there is some room for confusion what exactly the four TS
   payloads (two in the request, two in the response, each containing
   both start and end port fields) should contain.

   The answer to this question can be found from [RFC4301] Section
   4.4.1.3.

   To give a concrete example, if a host at 192.0.1.234 wants to create
   a transport mode SA for sending "Destination Unreachable" packets
   (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
   over this SA pair, the CREATE_CHILD_SA exchange would look like this:

      Initiator                   Responder
     -----------                 -----------
      HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
                TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->

         <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
                       TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                       TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }

   Since IKEv2 always creates IPsec SAs in pairs, two SAs are also
   created in this case, even though the second SA is never used for
   data traffic.

   An exchange creating an SA pair that can be used both for sending and
   receiving "Destination Unreachable" places the same value in all the
   port:

Top      Up      ToC       Page 20 
      Initiator                   Responder
     -----------                 -----------
      HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
                TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->

         <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
                       TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
                       TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }

   (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)

4.9.  Mobility Header in Traffic Selector Payloads

   Traffic selectors can use IP Protocol ID 135 to match the IPv6
   mobility header [MIPv6].  However, the IKEv2 specification does not
   define how to represent the "MH Type" field in traffic selectors.

   At some point, it was expected that this will be defined in a
   separate document later.  However, [RFC4301] says that "For IKE, the
   IPv6 mobility header message type (MH type) is placed in the most
   significant eight bits of the 16 bit local "port" selector".  The
   direction semantics of TSi/TSr port fields are the same as for ICMP
   and are described in the previous section.

   (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
   message type as selector", 2003-10-14.  "ICMP and MH TSs for IKEv2"
   thread, Sep 2005.)

4.10.  Narrowing the Traffic Selectors

   Section 2.9 describes how traffic selectors are negotiated when
   creating a CHILD_SA.  A more concise summary of the narrowing process
   is presented below.

   o  If the responder's policy does not allow any part of the traffic
      covered by TSi/TSr, it responds with TS_UNACCEPTABLE.

   o  If the responder's policy allows the entire set of traffic covered
      by TSi/TSr, no narrowing is necessary, and the responder can
      return the same TSi/TSr values.

   o  Otherwise, narrowing is needed.  If the responder's policy allows
      all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
      in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
      acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].

Top      Up      ToC       Page 21 
   o  If the responder's policy does not allow all traffic covered by
      TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
      an acceptable subset of TSi/TSr.

   In the last two cases, there may be several subsets that are
   acceptable (but their union is not); in this case, the responder
   arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE
   notification in the response.

4.11.  SINGLE_PAIR_REQUIRED

   The description of the SINGLE_PAIR_REQUIRED notify payload in
   Sections 2.9 and 3.10.1 is not fully consistent.

   We do not attempt to describe this payload in this document either,
   since it is expected that most implementations will not have policies
   that require separate SAs for each address pair.

   Thus, if only some part (or parts) of the TSi/TSr proposed by the
   initiator is (are) acceptable to the responder, most responders
   should simply narrow TSi/TSr to an acceptable subset (as described in
   the last two paragraphs of Section 2.9), rather than use
   SINGLE_PAIR_REQUIRED.

4.12.  Traffic Selectors Violating Own Policy

   Section 2.9 describes traffic selector negotiation in great detail.
   One aspect of this negotiation that may need some clarification is
   that when creating a new SA, the initiator should not propose traffic
   selectors that violate its own policy.  If this rule is not followed,
   valid traffic may be dropped.

   This is best illustrated by an example.  Suppose that host A has a
   policy whose effect is that traffic to 192.0.1.66 is sent via host B
   encrypted using Advanced Encryption Standard (AES), and traffic to
   all other hosts in 192.0.1.0/24 is also sent via B, but encrypted
   using Triple Data Encryption Standard (3DES).  Suppose also that host
   B accepts any combination of AES and 3DES.

   If host A now proposes an SA that uses 3DES, and includes TSr
   containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
   B.  Now, host B can also use this SA to send traffic from 192.0.1.66,
   but those packets will be dropped by A since it requires the use of
   AES for those traffic.  Even if host A creates a new SA only for
   192.0.1.66 that uses AES, host B may freely continue to use the first
   SA for the traffic.  In this situation, when proposing the SA, host A
   should have followed its own policy, and included a TSr containing
   ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

Top      Up      ToC       Page 22 
   In general, if (1) the initiator makes a proposal "for traffic X
   (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
   does not actually accept traffic X' with SA, and (3) the initiator
   would be willing to accept traffic X' with some SA' (!=SA), valid
   traffic can be unnecessarily dropped since the responder can apply
   either SA or SA' to traffic X'.

   (References: "Question about "narrowing" ..." thread, Feb 2005.
   "IKEv2 needs a "policy usage mode"..." thread, Feb 2005.  "IKEv2
   Traffic Selectors?" thread, Feb 2005.  "IKEv2 traffic selector
   negotiation examples", 2004-08-08.)

4.13.  Traffic Selector Authorization

   IKEv2 relies on information in the Peer Authorization Database (PAD)
   when determining what kind of IPsec SAs a peer is allowed to create.
   This process is described in [RFC4301] Section 4.4.3.  When a peer
   requests the creation of an IPsec SA with some traffic selectors, the
   PAD must contain "Child SA Authorization Data" linking the identity
   authenticated by IKEv2 and the addresses permitted for traffic
   selectors.

   For example, the PAD might be configured so that authenticated
   identity "sgw23.example.com" is allowed to create IPsec SAs for
   192.0.2.0/24, meaning this security gateway is a valid
   "representative" for these addresses.  Host-to-host IPsec requires
   similar entries, linking, for example, "fooserver4.example.com" with
   192.0.1.66/32, meaning this identity a valid "owner" or
   "representative" of the address in question.

   As noted in [RFC4301], "It is necessary to impose these constraints
   on creation of child SAs to prevent an authenticated peer from
   spoofing IDs associated with other, legitimate peers."  In the
   example given above, a correct configuration of the PAD prevents
   sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents
   fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.

   It is important to note that simply sending IKEv2 packets using some
   particular address does not imply a permission to create IPsec SAs
   with that address in the traffic selectors.  For example, even if
   sgw23 would be able to spoof its IP address as 192.0.1.66, it could
   not create IPsec SAs matching fooserver4's traffic.

   The IKEv2 specification does not specify how exactly IP address
   assignment using configuration payloads interacts with the PAD.  Our
   interpretation is that when a security gateway assigns an address

Top      Up      ToC       Page 23 
   using configuration payloads, it also creates a temporary PAD entry
   linking the authenticated peer identity and the newly allocated inner
   address.

   It has been recognized that configuring the PAD correctly may be
   difficult in some environments.  For instance, if IPsec is used
   between a pair of hosts whose addresses are allocated dynamically
   using Dynamic Host Configuration Protocol (DHCP), it is extremely
   difficult to ensure that the PAD specifies the correct "owner" for
   each IP address.  This would require a mechanism to securely convey
   address assignments from the DHCP server and link them to identities
   authenticated using IKEv2.

   Due to this limitation, some vendors have been known to configure
   their PADs to allow an authenticated peer to create IPsec SAs with
   traffic selectors containing the same address that was used for the
   IKEv2 packets.  In environments where IP spoofing is possible (i.e.,
   almost everywhere) this essentially allows any peer to create IPsec
   SAs with any traffic selectors.  This is not an appropriate or secure
   configuration in most circumstances.  See [Aura05] for an extensive
   discussion about this issue, and the limitations of host-to-host
   IPsec in general.

5.  Rekeying and Deleting SAs

5.1.  Rekeying SAs with the CREATE_CHILD_SA Exchange

   Continued from Section 4.1 of this document.

 NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange

      The CREATE_CHILD_SA request for rekeying an IKE_SA is:

          Initiator                                 Responder
         -----------                               -----------
          HDR, SK {SA, Ni, [KEi]} -->

      The initiator sends SA offer(s) in the SA payload, a nonce in
      the Ni payload, and optionally a Diffie-Hellman value in the KEi
      payload.

      The CREATE_CHILD_SA response for rekeying an IKE_SA is:

                                     <--    HDR, SK {SA, Nr, [KEr]}

Top      Up      ToC       Page 24 
      The responder replies (using the same Message ID to respond)
      with the accepted offer in an SA payload, a nonce in the Nr
      payload, and, optionally, a Diffie-Hellman value in the KEr
      payload.

      The new IKE_SA has its message counters set to 0, regardless of
      what they were in the earlier IKE_SA.  The window size starts at
      1 for any new IKE_SA.  The new initiator and responder SPIs are
      supplied in the SPI fields of the SA payloads.

 NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange

      The CREATE_CHILD_SA request for rekeying a CHILD_SA is:

          Initiator                                 Responder
         -----------                               -----------
          HDR, SK {N(REKEY_SA), [N+], SA,
              Ni, [KEi], TSi, TSr}  -->

      The leading Notify payload of type REKEY_SA identifies the
      CHILD_SA being rekeyed, and it contains the SPI that the initiator
      expects in the headers of inbound packets.  In addition, the
      initiator sends SA offer(s) in the SA payload, a nonce in the Ni
      payload, optionally a Diffie-Hellman value in the KEi payload,
      and the proposed traffic selectors in the TSi and TSr payloads.
      The request can also contain Notify payloads that specify
      additional details for the CHILD_SA.

      The CREATE_CHILD_SA response for rekeying a CHILD_SA is:

                                     <--    HDR, SK {[N+], SA, Nr,
                                                  [KEr], TSi, TSr}

      The responder replies with the accepted offer in an SA payload,
      and a Diffie-Hellman value in the KEr payload if KEi was
      included in the request and the selected cryptographic suite
      includes that group.

      The traffic selectors for traffic to be sent on that SA are
      specified in the TS payloads in the response, which may be a
      subset of what the initiator of the CHILD_SA proposed.

5.2.  Rekeying the IKE_SA vs. Reauthentication

   Rekeying the IKE_SA and reauthentication are different concepts in
   IKEv2.  Rekeying the IKE_SA establishes new keys for the IKE_SA and
   resets the Message ID counters, but it does not authenticate the
   parties again (no AUTH or EAP payloads are involved).

Top      Up      ToC       Page 25 
   While rekeying the IKE_SA may be important in some environments,
   reauthentication (the verification that the parties still have access
   to the long-term credentials) is often more important.

   IKEv2 does not have any special support for reauthentication.
   Reauthentication is done by creating a new IKE_SA from scratch (using
   IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
   payloads), creating new CHILD_SAs within the new IKE_SA (without
   REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
   deletes the old CHILD_SAs as well).

   This means that reauthentication also establishes new keys for the
   IKE_SA and CHILD_SAs.  Therefore, while rekeying can be performed
   more often than reauthentication, the situation where "authentication
   lifetime" is shorter than "key lifetime" does not make sense.

   While creation of a new IKE_SA can be initiated by either party
   (initiator or responder in the original IKE_SA), the use of EAP
   authentication and/or configuration payloads means in practice that
   reauthentication has to be initiated by the same party as the
   original IKE_SA.  IKEv2 base specification does not allow the
   responder to request reauthentication in this case; however, this
   functionality is added in [ReAuth].

   (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)

5.3.  SPIs When Rekeying the IKE_SA

   Section 2.18 says that "New initiator and responder SPIs are supplied
   in the SPI fields".  This refers to the SPI fields in the Proposal
   structures inside the Security Association (SA) payloads, not the SPI
   fields in the IKE header.

   (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
   Geoffrey Huang's reply, 2005-01-24.)

5.4.  SPI When Rekeying a CHILD_SA

   Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
   identifies the SA being rekeyed."

   Since CHILD_SAs always exist in pairs, there are two different SPIs.
   The SPI placed in the REKEY_SA notification is the SPI the exchange
   initiator would expect in inbound ESP or AH packets (just as in
   Delete payloads).

Top      Up      ToC       Page 26 
5.5.  Changing PRFs When Rekeying the IKE_SA

   When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
   new IKE_SA is computed using SK_d from the existing IKE_SA as
   follows:

      SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"

   If the old and new IKE_SA selected a different PRF, it is not totally
   clear which PRF should be used.

   Since the rekeying exchange belongs to the old IKE_SA, it is the old
   IKE_SA's PRF that is used.  This also follows the principle that the
   same key (the old SK_d) should not be used with multiple
   cryptographic algorithms.

   Note that this may work poorly if the new IKE_SA's PRF has a fixed
   key size, since the output of the PRF may not be of the correct size.
   This supports our opinion earlier in the document that the use of
   PRFs with a fixed key size is a bad idea.

   (References: "Changing PRFs when rekeying the IKE_SA" thread, June
   2005.)

5.6.  Deleting vs. Closing SAs

   The IKEv2 specification talks about "closing" and "deleting" SAs, but
   it is not always clear what exactly is meant.  However, other parts
   of the specification make it clear that when local state related to a
   CHILD_SA is removed, the SA must also be actively deleted with a
   Delete payload.

   In particular, Section 2.4 says that "If an IKE endpoint chooses to
   delete CHILD_SAs, it MUST send Delete payloads to the other end
   notifying it of the deletion".  Section 1.4 also explains that "ESP
   and AH SAs always exist in pairs, with one SA in each direction.
   When an SA is closed, both members of the pair MUST be closed."

5.7.  Deleting a CHILD_SA Pair

   Section 1.4 describes how to delete SA pairs using the Informational
   exchange: "To delete an SA, an INFORMATIONAL exchange with one or
   more delete payloads is sent listing the SPIs (as they would be
   expected in the headers of inbound packets) of the SAs to be deleted.
   The recipient MUST close the designated SAs."

Top      Up      ToC       Page 27 
   The "one or more delete payloads" phrase has caused some confusion.
   You never send delete payloads for the two sides of an SA in a single
   message.  If you have many SAs to delete at the same time (such as
   the nested example given in that paragraph), you include delete
   payloads for the inbound half of each SA in your Informational
   exchange.

5.8.  Deleting an IKE_SA

   Since IKE_SAs do not exist in pairs, it is not totally clear what the
   response message should contain when the request deleted the IKE_SA.

   Since there is no information that needs to be sent to the other side
   (except that the request was received), an empty Informational
   response seems like the most logical choice.

   (References: "Question about delete IKE SA" thread, May 2005.)

5.9.  Who is the original initiator of IKE_SA

   In the IKEv2 document, "initiator" refers to the party who initiated
   the exchange being described, and "original initiator" refers to the
   party who initiated the whole IKE_SA.  However, there is some
   potential for confusion because the IKE_SA can be rekeyed by either
   party.

   To clear up this confusion, we propose that "original initiator"
   always refers to the party who initiated the exchange that resulted
   in the current IKE_SA.  In other words, if the "original responder"
   starts rekeying the IKE_SA, that party becomes the "original
   initiator" of the new IKE_SA.

   (References: Paul Hoffman's mail "Original initiator in IKEv2",
   2005-04-21.)

5.10.  Comparing Nonces

   Section 2.8 about rekeying says that "If redundant SAs are created
   though such a collision, the SA created with the lowest of the four
   nonces used in the two exchanges SHOULD be closed by the endpoint
   that created it."

Top      Up      ToC       Page 28 
   Here "lowest" uses an octet-by-octet (lexicographical) comparison
   (instead of, for instance, comparing the nonces as large integers).
   In other words, start by comparing the first octet; if they're equal,
   move to the next octet, and so on.  If you reach the end of one
   nonce, that nonce is the lower one.

   (References: "IKEv2 rekeying question" thread, July 2005.)

5.11.  Exchange Collisions

   Since IKEv2 exchanges can be initiated by both peers, it is possible
   that two exchanges affecting the same SA partly overlap.  This can
   lead to a situation where the SA state information is temporarily not
   synchronized, and a peer can receive a request it cannot process in a
   normal fashion.  Some of these corner cases are discussed in the
   specification, some are not.

   Obviously, using a window size greater than one leads to infinitely
   more complex situations, especially if requests are processed out of
   order.  In this section, we concentrate on problems that can arise
   even with window size 1.

   (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/
   Jan 2006.  "Problem with exchanges collisions" thread, Dec 2005.)

5.11.1.  Simultaneous CHILD_SA Close

   Probably the simplest case happens if both peers decide to close the
   same CHILD_SA pair at the same time:

      Host A                      Host B
     --------                    --------
      send req1: D(SPIa) -->
                              <-- send req2: D(SPIb)
                              --> recv req1
                              <-- send resp1: ()
      recv resp1
      recv req2
      send resp2: () -->
                              --> recv resp2

   This case is described in Section 1.4 and is handled by omitting the
   Delete payloads from the response messages.

Top      Up      ToC       Page 29 
5.11.2.  Simultaneous IKE_SA Close

   Both peers can also decide to close the IKE_SA at the same time.  The
   desired end result is obvious; however, in certain cases the final
   exchanges may not be fully completed.

      Host A                      Host B
     --------                    --------
      send req1: D() -->
                              <-- send req2: D()
                              --> recv req1

   At this point, host B should reply as usual (with empty Informational
   response), close the IKE_SA, and stop retransmitting req2.  This is
   because once host A receives resp1, it may not be able to reply any
   longer.  The situation is symmetric, so host A should behave the same
   way.

      Host A                      Host B
     --------                    --------
                              <-- send resp1: ()
      send resp2: ()

   Even if neither resp1 nor resp2 ever arrives, the end result is still
   correct: the IKE_SA is gone.  The same happens if host A never
   receives req2.

5.11.3.  Simultaneous CHILD_SA Rekeying

   Another case that is described in the specification is simultaneous
   rekeying.  Section 2.8 says

      "If the two ends have the same lifetime policies, it is possible
      that both will initiate a rekeying at the same time (which will
      result in redundant SAs).  To reduce the probability of this
      happening, the timing of rekeying requests SHOULD be jittered
      (delayed by a random amount of time after the need for rekeying is
      noticed).

      This form of rekeying may temporarily result in multiple similar
      SAs between the same pairs of nodes.  When there are two SAs
      eligible to receive packets, a node MUST accept incoming packets
      through either SA.  If redundant SAs are created though such a
      collision, the SA created with the lowest of the four nonces used
      in the two exchanges SHOULD be closed by the endpoint that created
      it."

Top      Up      ToC       Page 30 
   However, a better explanation on what impact this has on
   implementations is needed.  Assume that hosts A and B have an
   existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
   rekeying it at the same time:

      Host A                      Host B
     --------                    --------
      send req1: N(REKEY_SA,SPIa1),
         SA(..,SPIa2,..),Ni1,..  -->
                              <-- send req2: N(REKEY_SA,SPIb1),
                                     SA(..,SPIb2,..),Ni2,..
      recv req2 <--

   At this point, A knows there is a simultaneous rekeying going on.
   However, it cannot yet know which of the exchanges will have the
   lowest nonce, so it will just note the situation and respond as
   usual.

      send resp2: SA(..,SPIa3,..),Nr1,.. -->
                              --> recv req1

   Now B also knows that simultaneous rekeying is going on.  Similarly
   as host A, it has to respond as usual.

                              <-- send resp1: SA(..,SPIb3,..),Nr2,..
       recv resp1 <--
                              --> recv resp2

   At this point, there are three CHILD_SA pairs between A and B (the
   old one and two new ones).  A and B can now compare the nonces.
   Suppose that the lowest nonce was Nr1 in message resp2; in this case,
   B (the sender of req2) deletes the redundant new SA, and A (the node
   that initiated the surviving rekeyed SA) deletes the old one.

      send req3: D(SPIa1) -->
                              <-- send req4: D(SPIb2)
                              --> recv req3
                              <-- send resp4: D(SPIb1)
      recv req4 <--
      send resp4: D(SPIa3) -->

   The rekeying is now finished.

   However, there is a second possible sequence of events that can
   happen if some packets are lost in the network, resulting in
   retransmissions.  The rekeying begins as usual, but A's first packet
   (req1) is lost.

Top      Up      ToC       Page 31 
      Host A                      Host B
     --------                    --------
      send req1: N(REKEY_SA,SPIa1),
         SA(..,SPIa2,..),Ni1,..  -->  (lost)
                              <-- send req2: N(REKEY_SA,SPIb1),
                                     SA(..,SPIb2,..),Ni2,..
      recv req2 <--
      send resp2: SA(..,SPIa3,..),Nr1,.. -->
                              --> recv resp2
                              <-- send req3: D(SPIb1)
      recv req3 <--
      send resp3: D(SPIa1) -->
                              --> recv resp3

   From B's point of view, the rekeying is now completed, and since it
   has not yet received A's req1, it does not even know that these was
   simultaneous rekeying.  However, A will continue retransmitting the
   message, and eventually it will reach B.

      resend req1 -->
                               --> recv req1

   What should B do in this point?  To B, it looks like A is trying to
   rekey an SA that no longer exists; thus failing the request with
   something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
   reasonable approach.

                               <-- send resp1: N(NO_PROPOSAL_CHOSEN)
      recv resp1 <--

   When A receives this error, it already knows there was simultaneous
   rekeying, so it can ignore the error message.

5.11.4.  Simultaneous IKE_SA Rekeying

   Probably the most complex case occurs when both peers try to rekey
   the IKE_SA at the same time.  Basically, the text in Section 2.8
   applies to this case as well; however, it is important to ensure that
   the CHILD_SAs are inherited by the right IKE_SA.

   The case where both endpoints notice the simultaneous rekeying works
   the same way as with CHILD_SAs.  After the CREATE_CHILD_SA exchanges,
   three IKE_SAs exist between A and B; the one containing the lowest
   nonce inherits the CHILD_SAs.

   However, there is a twist to the other case where one rekeying
   finishes first:

Top      Up      ToC       Page 32 
      Host A                      Host B
     --------                    --------
      send req1:
         SA(..,SPIa1,..),Ni1,.. -->
                              <-- send req2: SA(..,SPIb1,..),Ni2,..
                              --> recv req1
                              <-- send resp1: SA(..,SPIb2,..),Nr2,..
      recv resp1 <--
      send req3: D() -->
                              --> recv req3

   At this point, host B sees a request to close the IKE_SA.  There's
   not much more to do than to reply as usual.  However, at this point
   host B should stop retransmitting req2, since once host A receives
   resp3, it will delete all the state associated with the old IKE_SA
   and will not be able to reply to it.

                              <-- send resp3: ()

5.11.5.  Closing and Rekeying a CHILD_SA

   A case similar to simultaneous rekeying can occur if one peer decides
   to close an SA and the other peer tries to rekey it:

      Host A                      Host B
     --------                    --------
      send req1: D(SPIa) -->
                              <-- send req2: N(REKEY_SA,SPIb),SA,..
                              --> recv req1

   At this point, host B notices that host A is trying to close an SA
   that host B is currently rekeying.  Replying as usual is probably the
   best choice:

                              <-- send resp1: D(SPIb)

   Depending on in which order req2 and resp1 arrive, host A sees either
   a request to rekey an SA that it is currently closing, or a request
   to rekey an SA that does not exist.  In both cases,
   NO_PROPOSAL_CHOSEN is probably fine.

      recv req2
      recv resp1
      send resp2: N(NO_PROPOSAL_CHOSEN) -->
                              --> recv resp2

Top      Up      ToC       Page 33 
5.11.6.  Closing a New CHILD_SA

   Yet another case occurs when host A creates a CHILD_SA pair, but soon
   thereafter host B decides to delete it (possible because its policy
   changed):

      Host A                      Host B
     --------                    --------
      send req1: [N(REKEY_SA,SPIa1)],
         SA(..,SPIa2,..),.. -->
                              --> recv req1
                       (lost) <-- send resp1: SA(..,SPIb2,..),..

                              <-- send req2: D(SPIb2)
      recv req2

   At this point, host A has not yet received message resp1 (and is
   retransmitting message req1), so it does not recognize SPIb in
   message req2.  What should host A do?

   One option would be to reply with an empty Informational response.
   However, this same reply would also be sent if host A has received
   resp1, but has already sent a new request to delete the SA that was
   just created.  This would lead to a situation where the peers are no
   longer in sync about which SAs exist between them.  However, host B
   would eventually notice that the other half of the CHILD_SA pair has
   not been deleted.  Section 1.4 describes this case and notes that "a
   node SHOULD regard half-closed connections as anomalous and audit
   their existence should they persist", and continues that "if
   connection state becomes sufficiently messed up, a node MAY close the
   IKE_SA".

   Another solution that has been proposed is to reply with an
   INVALID_SPI notification that contains SPIb.  This would explicitly
   tell host B that the SA was not deleted, so host B could try deleting
   it again later.  However, this usage is not part of the IKEv2
   specification and would not be in line with normal use of the
   INVALID_SPI notification where the data field contains the SPI the
   recipient of the notification would put in outbound packets.

   Yet another solution would be to ignore req2 at this time and wait
   until we have received resp1.  However, this alternative has not been
   fully analyzed at this time; in general, ignoring valid requests is
   always a bit dangerous, because both endpoints could do it, leading
   to a deadlock.

   This document recommends the first alternative.

Top      Up      ToC       Page 34 
5.11.7.  Rekeying a New CHILD_SA

   Yet another case occurs when a CHILD_SA is rekeyed soon after it has
   been created:

      Host A                      Host B
     --------                    --------
      send req1: [N(REKEY_SA,SPIa1)],
         SA(..,SPIa2,..),..  -->
                       (lost) <-- send resp1: SA(..,SPIb2,..),..

                              <-- send req2: N(REKEY_SA,SPIb2),
                                     SA(..,SPIb3,..),..
      recv req2 <--

   To host A, this looks like a request to rekey an SA that does not
   exist.  Like in the simultaneous rekeying case, replying with
   NO_PROPOSAL_CHOSEN is probably reasonable:

      send resp2: N(NO_PROPOSAL_CHOSEN) -->
      recv resp1

5.11.8.  Collisions with IKE_SA Rekeying

   Another set of cases occurs when one peer starts rekeying the IKE_SA
   at the same time the other peer starts creating, rekeying, or closing
   a CHILD_SA.  Suppose that host B starts creating a CHILD_SA, and soon
   after, host A starts rekeying the IKE_SA:

      Host A                      Host B
     --------                    --------
                              <-- send req1: SA,Ni1,TSi,TSr
      send req2: SA,Ni2,.. -->
                              --> recv req2

   What should host B do at this point?  Replying as usual would seem
   like a reasonable choice:

                              <-- send resp2: SA,Ni2,..
      recv resp2 <--
      send req3: D() -->
                              --> recv req3

   Now, a problem arises: If host B now replies normally with an empty
   Informational response, this will cause host A to delete state
   associated with the IKE_SA.  This means host B should stop
   retransmitting req1.  However, host B cannot know whether or not host
   A has received req1.  If host A did receive it, it will move the

Top      Up      ToC       Page 35 
   CHILD_SA to the new IKE_SA as usual, and the state information will
   then be out of sync.

   It seems this situation is tricky to handle correctly.  Our proposal
   is as follows: if a host receives a request to rekey the IKE_SA when
   it has CHILD_SAs in "half-open" state (currently being created or
   rekeyed), it should reply with NO_PROPOSAL_CHOSEN.  If a host
   receives a request to create or rekey a CHILD_SA after it has started
   rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.

   The case where CHILD_SAs are being closed is even worse.  Our
   recommendation is that if a host receives a request to rekey the
   IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
   closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
   receives a request to close a CHILD_SA after it has started rekeying
   the IKE_SA, it should reply with an empty Informational response.
   This ensures that at least the other peer will eventually notice that
   the CHILD_SA is still in "half-closed" state and will start a new
   IKE_SA from scratch.

5.11.9.  Closing and Rekeying the IKE_SA

   The final case considered in this section occurs if one peer decides
   to close the IKE_SA while the other peer tries to rekey it.

      Host A                      Host B
     --------                    --------
      send req1: SA(..,SPIa1,..),Ni1 -->
                              <-- send req2: D()
                              --> recv req1
      recv req2 <--

   At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
   and host A should reply as usual, close the IKE_SA, and stop
   retransmitting req1.

                              <-- send resp1: N(NO_PROPOSAL_CHOSEN)
      send resp2: ()

   If host A wants to continue communication with B, it can now start a
   new IKE_SA.

5.11.10.  Summary

   If a host receives a request to rekey:

   o  a CHILD_SA pair that the host is currently trying to close: reply
      with NO_PROPOSAL_CHOSEN.

Top      Up      ToC       Page 36 
   o  a CHILD_SA pair that the host is currently rekeying: reply as
      usual, but prepare to close redundant SAs later based on the
      nonces.

   o  a CHILD_SA pair that does not exist: reply with
      NO_PROPOSAL_CHOSEN.

   o  the IKE_SA, and the host is currently rekeying the IKE_SA: reply
      as usual, but prepare to close redundant SAs and move inherited
      CHILD_SAs later based on the nonces.

   o  the IKE_SA, and the host is currently creating, rekeying, or
      closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.

   o  the IKE_SA, and the host is currently trying to close the IKE_SA:
      reply with NO_PROPOSAL_CHOSEN.

   If a host receives a request to close:

   o  a CHILD_SA pair that the host is currently trying to close: reply
      without Delete payloads.

   o  a CHILD_SA pair that the host is currently rekeying: reply as
      usual, with Delete payload.

   o  a CHILD_SA pair that does not exist: reply without Delete
      payloads.

   o  the IKE_SA, and the host is currently rekeying the IKE_SA: reply
      as usual, and forget about our own rekeying request.

   o  the IKE_SA, and the host is currently trying to close the IKE_SA:
      reply as usual, and forget about our own close request.

   If a host receives a request to create or rekey a CHILD_SA when it is
   currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.

   If a host receives a request to delete a CHILD_SA when it is
   currently rekeying the IKE_SA: reply without Delete payloads.

5.12.  Diffie-Hellman and Rekeying the IKE_SA

   There has been some confusion whether doing a new Diffie-Hellman
   exchange is mandatory when the IKE_SA is rekeyed.

   It seems that this case is allowed by the IKEv2 specification.
   Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets.
   Section 3.3.3 does not contradict this when it says that including

Top      Up      ToC       Page 37 
   the D-H transform is mandatory: although including the transform is
   mandatory, it can contain the value "NONE".

   However, having the option to skip the Diffie-Hellman exchange when
   rekeying the IKE_SA does not add useful functionality to the
   protocol.  The main purpose of rekeying the IKE_SA is to ensure that
   the compromise of old keying material does not provide information
   about the current keys, or vice versa.  This requires performing the
   Diffie-Hellman exchange when rekeying.  Furthermore, it is likely
   that this option would have been removed from the protocol as
   unnecessary complexity had it been discussed earlier.

   Given this, we recommend that implementations should have a hard-
   coded policy that requires performing a new Diffie-Hellman exchange
   when rekeying the IKE_SA.  In other words, the initiator should not
   propose the value "NONE" for the D-H transform, and the responder
   should not accept such a proposal.  This policy also implies that a
   successful exchange rekeying the IKE_SA always includes the KEi/KEr
   payloads.

   (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange"
   thread, Oct 2005.  "Comments of
   draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)



(page 37 continued on part 3)

Next RFC Part