Subject: [Hipsec] hip-mm proposed revisions

From: [email-masked] (Henderson, Thomas R)
Date: Fri Apr 16 20:15:02 2004

All,
I made another pass at the mm draft.  It is posted at:
http://hip.piuha.net/drafts/draft-nikander-hip-mm-02-pre1.txt

In addition, I propose some changes to the base draft to
align it with the mm draft (and some cleanup involving NES).  
These changes are at the end of this message.  

Here is a brief summary of the changes I am proposing:

Base draft changes (against 10-pre1.txt):
i) move UPDATE ID out of the NES parameter and put it as a separate
   parameter (logically, this is part of the UPDATE packet header,
   but since we have fixed header, this becomes the first parameter
   in the UPDATE packet).

ii) rewrote UPDATE packet definition.  UPDATEs basically work the
    same way that we had them before-- a host sends an UPDATE with
    the R bit unset, and the peer replys with a matching UPDATE_ID
    but with the R bit set

iii) updated Section 8.10 on UPDATE/NES actions accordingly.   

Mobility management changes (against 02-pre-Jan22.txt):
i) biggest change is the substitution of "SPI" for "address group".
I felt that this was a more straightforward way to represent the
situation, since there seems to be a 1-1 correspondence with what
was calling an address group, and the SA (SPI).   Section 5 
describes this in more detail.

ii) consistently made the statement that a host may opt out of
explicit RR-check for REA if desired

iii) used the UPDATE-request/UPDATE-reply as the basis for the 
REA RR check (the practice of looking for data on the new SPI
is also a valid sign)

iv) decoupled REA from NES (NES is optional addition to REA).  This
is because the replay windows may be loose enough that they do not
necessitate a new SPI upon readdressing.

v) REA may also be included in NOTIFY packet, if it is informational.
The biggest distinction between NOTIFY and UPDATE is that NOTIFY
does not solicit a response from the peer.

vi) various minor nits to align with the current base.

Tom

<below, edits to draft-moskowitz-hip-10-pre1>

6.2.13 NES (New SPI)

   During the life of an SA established by HIP, one of the hosts may
   need to reset the Sequence Number to one (to prevent wrapping) and
   rekey.  The reason for rekeying might be an approaching sequence
   number wrap in ESP, or a local policy on use of a key.  Rekeying ends
   the current SAs and starts new ones on both peers.

   The NES parameter is carried in the HIP UPDATE packet.  It is used
   to reset Security Associations. It introduces a new SPI to be used 
   when sending data to the sender of the UPDATE packet.  The keys 
   for the new Security Association will be drawn from KEYMAT.  If 
   the packet contains a Diffie-Hellman parameter, the KEYMAT is first 
   recomputed before drawing the new keys.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Reserved                |         Keymat Index          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Old SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            New SPI                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type           9
      Length         12
      Keymat Index   Index, in bytes, where to continue to draw ESP keys
                     from KEYMAT. If the packet includes a new
                     Diffie-Hellman key, the field MUST be zero.  Note
                     that the length of this field limits the amount of
                     keying material that can be drawn from KEYMAT.  If
                     that amount is exceeded, the NES packet MUST contain
                     a new Diffie-Hellman key.
      Old SPI        Old SPI for data sent to the source address of
                     this packet
      New SPI        New SPI for data sent to the source address of
                     this packet

   A host that receives an NES must reply shortly thereafter with an 
   NES.  Any middleboxes between the communicating hosts will learn 
   the mappings from the pair of UPDATE messages.

6.2.XXX UPDATE_ID

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Type              |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Reserved    |R|                   Update ID                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type           TBD
      Length         4 (length in octets, excluding Type and Length)
      Reserved       zero when sent, ignored when received
      R              Response bit.  Conveys semantics to the Update ID
                     field.  If set to 0, the Update ID corresponds to the
                     host's update sequence number.  If set to 1, the 
                     Update ID corresponds to the echo of the Update ID
                     to which this UPDATE is in response.
      Update ID      24-bit sequence number 

   The Update ID is an unsigned quantity, initialized by a host to zero, 
   and is incremented by one before each new UPDATE that is sent by
   the host (i.e., the first UPDATE packet originated by a host has
   an Update ID of 1).  If the UPDATE packet is in response to 
   a peer's UPDATE packet, the R bit is set to 1, and the Update ID
   is the echoed value of the Update ID in the received UPDATE packet
   that triggered the response.

7.5 UPDATE - the HIP Update packet

   The UPDATE packet is MANDATORY.

   The UPDATE packet provides a mechanism for a host to send HIP
   parameters and receive an acknowledgment from its peer.  The UPDATE
   can be used to carry parameters such as NES and DIFFIE_HELLMAN,
   and parameters to be defined in the future, such as for readdressing.
   The UPDATE also contains mandatory HMAC and HIP_SIGNATURE parameters,
   since processing UPDATE signatures is a potential DoS attack against
   intermediate systems.

   The UPDATE packet carries one UPDATE_ID parameter, and one or more
   other optional parameters.  A host that originates an UPDATE packet 
   that is not in response to a peer's UPDATE includes an UPDATE_ID 
   with the R bit set to zero.  If a host receives an UPDATE parameter 
   with an UPDATE_ID that has the R bit set to zero, it MUST reply with 
   an UPDATE packet including an UPDATE_ID with the R bit set to one.  
   UPDATE packets are always used in pairs, one in both directions, with
   identical UPDATE IDs.  In the case both parties decide to UPDATE at
   the same time, the result is four UPDATE packets, two in both
   directions.

   Intermediate systems that use the SPI will have to inspect HIP
   packets for a UPDATE packet.  The packet is signed for the benefit of
   the intermediate systems.  Since intermediate systems may need the
   new SPI values, the contents of this packet cannot be encrypted.

   The HIP header values for the UPDATE packet:

      Header:
        Packet Type = 5
        SRC HIT = Sender's HIT
        DST HIT = Recipient's HIT

      IP ( HIP ( UPDATE_ID, [NES, DIFFIE_HELLMAN] HMAC, HIP_SIGNATURE ) )

   Valid control bits: None

/* Note:  Could move the "R" bit into the controls, and then allow */
/*        the UPDATE_ID sequence number to be 32 bits.             */

8.9 Initiating rekeying

   A system may initiate the rekey procedure at any time.  It MUST
   initiate a rekey if its incoming ESP sequence counter is about to
   overflow.

   The following steps define the conceptual processing rules for
   initiating a rekey:

   1.  The system SHOULD generate a new Diffie-Hellman public key.

   2.  The system increments the Update ID by one.

   3.  The system creates a UPDATE packet, which contains an
       UPDATE_ID parameter (with the current value of Update ID),
       NES parameter and an optional DIFFIE_HELLMAN parameter.  If the 
       UPDATE packet contains the DIFFIE_HELLMAN parameter, the 
       Keymat Index in the NES parameter MUST be zero.
   
   4.  The system sends the UPDATE packet and transitions to state 
       REKEYING.

   5.  The system SHOULD start a timer whose timeout value should be
       larger than the worst-case anticipated RTT, and MUST increment a
       timeout counter associated with UPDATE. The sender SHOULD
       retransmit the UPDATE upon a timeout and restart the timer, up to
       a maximum of UPDATE_RETRIES_MAX tries.

   6.  The system MUST NOT delete its existing SAs, but continue using
       them if its policy still allows.  The UPDATE procedure SHOULD be
       initiated prior enough in order to make sure that the SA replay
       counters do not overflow.

8.10 Processing UPDATE packets

   When a system receives a UPDATE packet, its processing depends on
   whether the packet is a reply to a previously sent UPDATE packet or
   the UPDATE is a new packet.  

   The order of the keys retrieved from the KEYMAT during rekeying
   process depends on the HIT value comparison. We denote the host with
   lower HIT value with HITl and, respectively, the host with greater
   HIT with HITg. The HITs are compared in network byte order. The keys
   are retrieved from the KEYMAT in the following order:

      SA-gl ESP encryption key for HITg's outgoing traffic

      SA-gl ESP authentication key for HITg's outgoing traffic

      SA-lg ESP encryption key for HITl's outgoing traffic

      SA-lg ESP authentication key for HITl's outgoing traffic

   The following steps define the conceptual processing rules for
   handling a received UPDATE packet:

   1.   If the system is in state ESTABLISHED and the UPDATE has the
        R-bit set in the UPDATE_ID parameter, the packet is silently 
        dropped.  

   2.   If the R-bit is cleared, and if the Update ID in the received 
        UPDATE_ID parameter is smaller than the stored Update ID for
        the host, the packet MUST BE dropped.  Note that if the Update 
        ID is equal to the stored value, the packet can be expected to 
        be a retransmission, and acted upon accordingly.  However, the 
        HMAC verification (next step) MUST NOT be skipped.  (A 
        byte-by-byte comparison of the received and a stored packet 
        would be OK, though.)

   3.   The system MUST verify the HMAC in the UPDATE packet.  If the
        verification fails, the packet MUST be dropped.

   4.   If the received UPDATE contains a DIFFIE_HELLMAN parameter, the
        received Keymat Index MUST be zero.  If this test fails, the
        packet SHOULD be dropped and the system SHOULD log an error
        message.

   5.   If the received UPDATE does not contain a DIFFIE_HELLMAN
        parameter, the received Keymat Index MUST be larger or equal to
        the index of the next byte to be drawn from the current KEYMAT.
        If the host is in REKEYING state, a smaller Keymat Index value
        MAY be accepted.  If the host is in ESTABLISHED state and this
        test fails, the packet SHOULD be dropped and the system SHOULD
        log an error message.

   6.   The system MAY verify the SIGNATURE in the UPDATE packet. If the
        verification fails, the packet SHOULD be dropped and an error
        message logged.

   7.   The system MUST record the Update ID in the received packet, for
        replay protection.

   8.   If the system is in state ESTABLISHED, and the UPDATE does not
        have the R-bit set in the UPDATE_ID parameter, the packet is 
        processed as specified in Section 8.10.1.

   9.   If the system is in state REKEYING, and the UPDATE has the R-bit
        set in the UPDATE_ID parameter, the packet is further processed 
        as specified in Section 8.10.2.

   10.  If the system is in state REKEYING, and the UPDATE doesn't have
        the R-bit set in the UPDATE_ID parameter, there are apparently 
        two UPDATE packets crossing each other in the network. 
        Consequently, the R-bit-less packet is handled as specified in 
        Section 8.10.1.  However, in order not to unnecessarily spend 
        cycles in Diffie-Hellman computations, there are minor differences 
        with respect to receiving such a packet in state ESTABLISHED.

8.10.1 Processing an initial UPDATE packet

   When a system receives an initial UPDATE packet, i.e. one that does
   not have the R-bit set, it prepares new incoming and outgoing SAs,
   but does not change the outgoing SA yet. Once it has the new SAs in
   place, it sends a reply UPDATE. The contents of the reply UPDATE
   depend on whether the system was in state ESTABLISHED or REKEYING
   upon receiving the initial UPDATE packet.

   The following steps define the conceptual processing rules responding
   handling a received initial UPDATE packet:

   1.  If the system is in state ESTABLISHED, it consults its policy to
       see if it needs to generate a new Diffie-Hellman key, and
       generates a new key if needed. If the system is in state
       REKEYING, it may already have generated a new Diffie-Hellman key,
       and SHOULD use it.

   2.  If either the received UPDATE contains a new Diffie-Hellman key,
       the system has a new Diffie-Hellman key from the previous step,
       or both, the system generates new KEYMAT.  If there is only one
       new Diffie-Hellman key, the other old key is used.

   3.  If the system generated new KEYMAT in the previous step, it sets
       Keymat Index to zero, independent on whether the received UPDATE
       included a Diffie-Hellman key or not.

   4.  If the host is in REKEYING state, and neither the incoming UPDATE
       packet nor the sent UPDATE packet required new KEYMAT generation,
       the bigger Keymat Index number of those two UPDATE packets shall
       be used.

   5.  The system draws keys for new incoming and outgoing ESP SAs,
       starting from the Keymat Index, and prepares new incoming and
       outgoing ESP SAs.  The SPI for the outgoing SA is the new SPI
       value from the received UPDATE. The SPI for the incoming SA is
       locally generated, and SHOULD be random.  The system MUST NOT
       start using the new outgoing SA before it receives traffic on the
       new incoming SA.

   6.  The system prepares a reply UPDATE packet, with the R-bit one in
       the UPDATE_ID parameter, Keymat Index being the one used above, 
       Update ID being equal to the one in the received UPDATE, old SPI 
       being the current incoming SPI, and new SPI being the newly 
       generated incoming SPI.  If the system generated a new 
       Diffie-Hellman key above, the new key is included in the packet 
       in the Diffie-Hellman payload.  Note that if the system is 
       in state REKEYING, the new Diffie-Hellman key was probably 
       generated and sent already earlier, in which case it MUST NOT 
       be included into the reply packet.

8.10.2 Processing a reply UPDATE packet

   When a system receives a reply UPDATE packet, i.e. one that has the
   R-bit set in the UPDATE_ID parameter, it starts to use the new 
   outgoing SA.  It must also complete its new incoming SA.

   The following steps define the conceptual processing rules responding
   handling a received reply UPDATE packet:

   1.  If either the received UPDATE contains a new Diffie-Hellman key,
       the system has a new Diffie-Hellman key from initiating rekey, or
       both, the system generates new KEYMAT.  If there is only one new
       Diffie-Hellman key, the old key is used as the other key.

   2.  If the system generated new KEYMAT in the previous step, it sets
       Keymat Index to zero, independent on whether the received UPDATE
       included a Diffie-Hellman key or not.

   3.  The system draws keys for new incoming and outgoing ESP SAs,
       starting from the Keymat Index, and prepares new incoming and
       outgoing ESP SAs.  The SPI for the outgoing SA is the new SPI
       value from the UPDATE.  The SPI for the incoming SA was generated
       when rekey was initiated.

   4.  The system starts to send to the new outgoing SA.  It should
       start receiving data on the new incoming SA as soon as the peer
       receives data on the new SA.