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

From: [email-masked] (Henderson, Thomas R)
Date: Sun Jan 25 16:49:00 2004

> -----Original Message-----
> From: Petri Jokela [mailto:[email-masked]]
> Sent: Friday, January 23, 2004 3:09 AM
> To: [email-masked]
> Subject: [Hipsec] draft-moskowitz-hip-09: sections 5.3 and 5.4
>=20
>=20
> I have been updating the draft-hip-09-pre1. Changes that are=20
> (almost) done:
>=20
> 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=20
> packet sending with RESYNC bit set.
>=20
> I include new versions of 5.3 and 5.4 here. The state machine is from=20
> Julien's earlier post (not directly copied, it may contain typos...)
> The HIP basic header will contain a RESYNC -bit.
>=20
> /petri
>=20
>=20
>=20
> 5.3 Reboot and SA timeout restart of HIP
>=20
>     Simulating a loss of state is a potential DoS attack. =20
> The following
>     process has been crafted to manage state recovery without=20
> presenting
>     a DoS opportunity.
>=20
>     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=20
> 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=20
> reboot of a
>     peer.  Note that either the original Initiator or the=20
> Responder could
>     end up restarting the exchange, becoming the new Initiator.
>=20
>     If a system receives an ESP packet for an unknown SPI, it=20
> 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=20
> the SA. The
>     RESYNC bit in the I1 packet is set to indicate the peer about the
>     possible state loss.

I would prefer to make the above a "MAY" (initiate a new exchange).

Does it make any difference to the peer whether I1 has RESYNC set or
not?  (does it cause any different behavior?).  Maybe rather than
RESYNC bit, we should allow for "Unknown SPI" parameter to be
included in the I2.

>=20
>     The initiating host cannot know, if the SA indicated by=20
> the received
>     ESP packet is either a HIP SA or and IKE SA. If the old=20
> SA was not a
>     HIP SA, the peer may not respond to the I1 packet.
>=20
>     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.
>=20
> 5.4 HIP State Machine
>=20
>     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=20
> needs to be
>     re-established, the controlling parameters are which peer=20
> still has
>     state and which has a datagram to send to its peer.  The following
>     state machine attempts to capture these processes.
>=20
>     The state machine is presented in a single system view,=20
> representing
>     either an Initiator or a Responder.  There is not a=20
> complete overlap
>     of processing logic here and in the packet definitions.  Both are
>     needed to completely implement HIP.
>=20
>     Implementors must understand that the state machine, as described
>     here, is informational.  Specific implementations are free to
>     implement the actual functions differently.
>=20
> 5.4.1 HIP States
>=20
>     UNASSOCIATED State machine start
>=20
>     I1-SENT Initiating HIP
>=20
>     I2-SENT Waiting to finish HIP
>=20
>     ESTABLISHED HIP SA established
>=20
>     REKEYING HIP SA established, rekeying
>=20
>     RESYNC Peer lost state, resyncing
>=20
>     E-FAILED HIP SA establishment failed
>=20
>=20
> 5.4.2 HIP State Processes
>=20
>     +------------+
>     |UNASSOCIATED|  Start state
>     +------------+
>=20
>     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
>=20
>     +---------+
>     | I1-SENT |  Initiating HIP
>     +---------+
>=20
>     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=20
> stay at 		=20
> I1-SENT
>          If counter is greater than I1_RETRIES_MAX, go to E-FAILED
>=20
>     +---------+
>     | I2-SENT | Waiting to finish HIP
>     +---------+
>=20
>     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=20
> stay at 		=20
> I2-SENT
>          If counter is greater than I2_RETRIES_MAX, go to E-FAILED
>=20
>     +------------+
>     |ESTEBALISHED| HIP SA established

ESTABLISHED

>     +------------+
>=20
>     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

Should we say "old SAs" in the case of possible multihoming?

maybe say:
           if successful, send R2, drop old SAs, establish new SA, =
reenter ESTABLISHED

>          if fail, stay at ESTABLISHED
>     Receive R1, drop and stay at ESTABLISHED
>=20
>=20
>     Receive R2, drop and stay at ESTABLISHED
>=20
>     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
>=20
>     +----------+
>     | REKEYING | HIP SA established, rekey pending
>     +----------+
>=20
>     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=20
> go to 		=20
> ESTABLISHED
>          if fail, stay at REKEYING

what triggers the above R1?  If I am in REKEYING I have recently
been in ESTABLISHED and I have sent an UPD.

Should R1 be an illegal packet here?

>     Receive R2, drop and stay at REKEYING
>=20
>     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=20
> stay at 			REKEYING
>          If counter is greater than UPD_RETRIES_MAX, go to E-FAILED
>=20
>     +--------+
>     | RESYNC | HIP SA established, resync pending
>     +--------+
>=20
>     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=20
> cycle at 		=20
> RESYNC
>          if fail, stay at RESYNC
>     Receive R2, process with SA and Birthday check
>          if successful, go to ESTABLISHED
>          if fail, stay at RESYNC
>=20
>     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=20
> stay at 		RESYNC
>          if counter is greater than RESYNC_RETRIES_MAX, go to=20
> ESTABLISHED
>=20

how about a description for E-FAILED?

    +----------+
    | E-FAILED | HIP failed to establish association with peer
    +----------+

Implementation-dependent wait until you go back to UNASSOCIATED and =
permit=20
retries?  Log the error?

> 5.4.3 Simplified HIP State Diagram
>=20
>     Receive packets cause a move to a new state.
>=20
>     +------------+
>     |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
>=20
=20
nice artwork.  Too bad there is no way to do simple vector graphics
other than ASCII in IETF documents.

Tom=20
=20
=20

---

From: [email-masked] (Petri Jokela)
Date: Thu Jan 29 06:02:01 2004

> RESYNC bit, we should allow for "Unknown SPI" parameter to be

I don't know what the host in ESTABLISHED state would gain from the 
RESYNC bit.

What about the case when hosts A and B do not have any association. The 
host C sends ESP packets to B with A's source IP address. The B would 
then initiate a connection to A with an I1 (if host B considers that ESP 
packets may belong to a lost association). The A responds with R1, 
thinking that someone is trying to establish a connection. Thus, we end 
up with an SA that neither A nor B needs.

If the I1 contains a RESYNC bit, the A could just drop the packet. (Or 
R1 could include also a RESYNC bit. A responds with R1 without RESYNC 
bit, saying "I don't have any association, but feel free to continue if 
you want." and from that B would notice that something is wrong.)

>            if successful, send R2, drop old SAs, establish new SA, reenter ESTABLISHED

Ok.

>>         if successful, send I2, prepare to drop old SA and 
>>go to 		 
>>ESTABLISHED

Yes, I think so.

>>         if successful, send I2, prepare to drop old SA and 
>>cycle at 		 
>>RESYNC

Here is also the same question: what triggers R1 or R2. The change to 
RESYNC should be triggered by the incoming I1 and we should not have 
sent any I1 or I2.

> how about a description for E-FAILED?

Ok.

/petri

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