Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4

From: [email-masked] (Petri Jokela)
Date: Fri Jan 23 05:29:00 2004

I have been updating the draft-hip-09-pre1. Changes that are (almost) done:

o NES is changed to UPD
o NES_INFO parameter changed to NES
o State names have been changed
o In case of node reboot, incoming unknown ESP packet triggers an I1 
packet sending with RESYNC bit set.

I include new versions of 5.3 and 5.4 here. The state machine is from 
Julien's earlier post (not directly copied, it may contain typos...)
The HIP basic header will contain a RESYNC -bit.

/petri

5.3 Reboot and SA timeout restart of HIP

    Simulating a loss of state is a potential DoS attack.  The following
    process has been crafted to manage state recovery without presenting
    a DoS opportunity.

    If a host reboots or times out, it has lost its HIP state. If the
    system that lost state has a datagram to deliver to its peer, it
    simply restarts the HIP exchange.  The peer sends an R1 HIP packet,
    but does not reset its state until it receives the I2 HIP packet.
    The I2 packet MUST have a Birthday greater than the current SA's
    Birthday.  This is to handle DoS attacks that simulate a reboot of a
    peer.  Note that either the original Initiator or the Responder could
    end up restarting the exchange, becoming the new Initiator.

    If a system receives an ESP packet for an unknown SPI, it is possible
    that it has lost the state and its peer has not. In this case, the
    system initiates a new HIP exchange for re-establishing the SA. The
    RESYNC bit in the I1 packet is set to indicate the peer about the
    possible state loss.

    The initiating host cannot know, if the SA indicated by the received
    ESP packet is either a HIP SA or and IKE SA. If the old SA was not a
    HIP SA, the peer may not respond to the I1 packet.

    After sending the I1, the HIP negotiaton proceeds as normally and,
    when successful, the SA is created at the initiating end. The peer
    end removes the OLD SA and replaces it with the new one.

5.4 HIP State Machine

    The HIP protocol itself has very little state.  In the HIP base
    exchange, there is an Initiator and a Responder.  Once the SAs are
    established, this distinction is lost.  If the HIP state needs to be
    re-established, the controlling parameters are which peer still has
    state and which has a datagram to send to its peer.  The following
    state machine attempts to capture these processes.

    The state machine is presented in a single system view, representing
    either an Initiator or a Responder.  There is not a complete overlap
    of processing logic here and in the packet definitions.  Both are
    needed to completely implement HIP.

    Implementors must understand that the state machine, as described
    here, is informational.  Specific implementations are free to
    implement the actual functions differently.

5.4.1 HIP States

    UNASSOCIATED State machine start

    I1-SENT Initiating HIP

    I2-SENT Waiting to finish HIP

    ESTABLISHED HIP SA established

    REKEYING HIP SA established, rekeying

    RESYNC Peer lost state, resyncing

    E-FAILED HIP SA establishment failed

5.4.2 HIP State Processes

    +------------+
    |UNASSOCIATED|  Start state
    +------------+

    Datagram to send, send I1 and go to I1-SENT
    Receive I1, send R1 and stay at UNASSOCIATED
    Receive I2, process
         if successful, send R2 and go to ESTABLISHED
         if fail, stay at UNASSOCIATED
    Receive ESP for unknown SA, send I1 and go to I1-SENT
    Receive ANYOTHER, drop and stay at UNASSOCIATED

    +---------+
    | I1-SENT |  Initiating HIP
    +---------+

    Receive I1, send R1 and stay at I1-SENT
    Receive I2, process
         if successful, send R2 and go to ESTABLISHED
         if fail, stay at I1-SENT
    Receive R1, process
         if successful, send I2 and go to I2-SENT
         if fail, go to E-FAILED
    Receive ANYOTHER, drop and stay at I1-SENT
    Timeout, increment timeout counter
         If counter is less than I1_RETRIES_MAX, send I1 and stay at 		 
I1-SENT
         If counter is greater than I1_RETRIES_MAX, go to E-FAILED

    +---------+
    | I2-SENT | Waiting to finish HIP
    +---------+

    Receive I1, send R1 and stay at I2-SENT
    Receive I2, process
         if successful, send R2 and go to ESTABLISHED
         if fail, stay at I2-SENT
    Receive R2, process
         if successful, go to ESTABLISHED
         if fail, go to E-FAILED
    Receive ANYOTHER, drop and stay at I2-SENT
    Timeout, increment timeout counter
         If counter is less than I2_RETRIES_MAX, send I2 and stay at 		 
I2-SENT
         If counter is greater than I2_RETRIES_MAX, go to E-FAILED

    +------------+
    |ESTEBALISHED| HIP SA established
    +------------+

    Receive I1, send R1 and stay at go to RESYNC
    Receive I2, process with Birthday check
         if successful, send R2, drop old SA and cycle at ESTABLISHED
         if fail, stay at ESTABLISHED
    Receive R1, drop and stay at ESTABLISHED

    Receive R2, drop and stay at ESTABLISHED

    Receive ESP for SA, process and stay at ESTABLISHED
    Receive UPD, process
         if successful, send UPD and stay at ESTABLISHED
         if failed, stay at ESTABLISHED
    Need rekey,
         send UPD and go to REKEYING

    +----------+
    | REKEYING | HIP SA established, rekey pending
    +----------+

    Receive I1, send R1 and stay at REKEYING
    Receive I2, process with Birthday check
         if successful, send R2, drop old SA and go to ESTABLISHED
         if fail, stay at REKEYING
    Receive R1, process with SA and Birthday check
         if successful, send I2, prepare to drop old SA and go to 		 
ESTABLISHED
         if fail, stay at REKEYING
    Receive R2, drop and stay at REKEYING

    Receive ESP for SA, process and stay at REKEYING
    Receive UPD, process
         if successful, replace SAs and go to ESTABLISHED
         if failed, stay at REKEYING
    Timeout, increment timeout counter
         If counter is less than UPD_RETRIES_MAX, send UPD and 
stay at 			REKEYING
         If counter is greater than UPD_RETRIES_MAX, go to E-FAILED

    +--------+
    | RESYNC | HIP SA established, resync pending
    +--------+

    Receive I1, send R1 and cycle at RESYNC
    Receive I2, process with Birthday check
         if successful, send R2, drop old SA and go to ESTABLISHED
         if fail, stay at RESYNC
    Receive R1, process with SA and Birthday check
         if successful, send I2, prepare to drop old SA and cycle at 		 
RESYNC
         if fail, stay at RESYNC
    Receive R2, process with SA and Birthday check
         if successful, go to ESTABLISHED
         if fail, stay at RESYNC

    Receive ESP for SA, process and go to ESTABLISHED
    Receive UPD, process
         if successful, send UPD and go to ESTABLISHED
         if failed, stay at RESYNC
    Timeout, increment timeout counter
         if counter is less than RESYNC_RETRIES_MAX, send I2 and 
stay at 		RESYNC
         if counter is greater than RESYNC_RETRIES_MAX, go to ESTABLISHED

5.4.3 Simplified HIP State Diagram

    Receive packets cause a move to a new state.

    +------------+
    |UNASSOCIATED|>---+
    +------------+    |
     | ^ |            |
     | | | Dgm to     |
     +-+ | send       |
     I1  | ESP-       |  (note: ESP- means ESP with unknown SPI)
         |            |
         v            |
    +---------+       |
    | I1-SENT |>---|----------+
    +---------+    |          |
         |         |          |
         | R1      |          |
         |         |I2        |I2
         v         |          |
    +---------+    |          |
    | I2-SENT |>---|----------|-----+
    |         |    |          |     |
    +---------+    |          |     |
         |         |          |     |
         | R2      |          |     |I2
         |         |          |     |
         v         |          |     |
    +-----------+<-+          |     |
    |           |             |     |
    |ESTABLISHED|<------------+     |
    |           |<------------------+
    |           |<------------------+
    |           |>------------+     |
    |           |<-----+      |     |
    |           |--+   |      |     |
    +-----------+  |   |      |     |
     |  ^  ^       |   |      |     |
     |  |  |       |   |      |     |
     +--+  |       |   |      |     |
     ESP,  |  rekey|   |R1,I2 |     |
     UPD,  |       |   |      |     |
     I1,   |UPD    |   |      |     |
     I2,   |       |   |      |     |
     R1    |       |   |      |     |
           |       |   |      |     |
    +---------+    |   |      |     |
    |         |<---+   |      |     |
    |REKEYING |>-------+      |     |
    +---------+               |     |
     |  ^  v                  |     | I2, R2, ESP
     |  |  |               R1 |     | UPD, Timeout
     +--+  |                  |     |
     ESP,  |                  |     |
     I1,   |                  |     |
           |                  v     ^
           |    R1          +--------+
           +--------------->| RESYNC |
                            +--------+
                               |  ^
                               |  |
                               +--+
                                I1,
                                R1

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]