Subject: [Hipsec] ESP draft - state machine and simultaneous UPDATEs

From: Petri Jokela <[email-masked]>
Date: Thu, 09 Jun 2005 13:58:11 +0300

Hi,

We tried to figure out how the system should behave when UPDATE messages
for rekeying or ESP transform changes are initiated simultaneously and
cross each other in the network. With the current UPDATE ACK system the
state machine became a chaos because the ACK is not necessarily included
in the response packet (response packet = response to the change
request, not response to the UPDATE packet), but can arrive in a
separate UPDATE packet later.

One way to manage this is to make it mandatory to send the ACK in the
same packet as SEQ in the following way:

 UPD(SEQ...)
---------------->
 UPD(SEQ, ACK...)
<----------------
 UPD(ACK)
---------------->

This would help a host that has initialized rekeying/family change so
that it knows if the received packet is an answer or if it is an
initialization message.

The other way would be to include some "initialization" parameter in the
ESP_INFO/ESP_TRANSFORM parameters that could be used to track the
packets. But that would be adding yet another acknowledgement system on
top of the UPDATE ack system.

We created a following state machine, when the middle UPDATE message
must contain both SEQ and ACK:

EI = ESP_INFO
TR = ESP_TRANSFORM
[C] = conditional, the behaviour is based on the HIT value comparison
(if local HIT is greater, choose one path and if smaller, choose the
other path)

DIFFIE_HELLMAN is not included in the picture, as it is OPTIONAL and not
necessary included in messages to both directions

TR_CH_IN = ESP transform family change initiated by the peer host
TR_CH_OUT = ESP transform family change initiated by this host
REKEY_IN = rekeying initiated by the peer host
REKEY_OUT = rekeying initiated by this host

          +---------------------------------------+[C]<-+
          |                                       |     |
          |out: EI+TR+ACK                   (drop)|     |in: EI+TR
          V                                       V     |
  +-----------+                               +-----------+
+>| TR_CH_IN  |<-----------+         +------->| TR_CH_OUT |
| +-----------+            |         |        +-----------+
|       |                  |         |              |  ^ in: EI
|       |         in: EI+TR|         |              |  | out: EI+TR
|       |    out: EI+TR+ACK|         |out: EI+TR    +--+
|       |                  |         |
|       |                  |         |
|       |in: ACK           |         |
|       |                  |         |
|       |               +-------------+
|       +-------------->| ESTABLISHED |<---------+
|                       +-------------+          |
|                        |    ^      |           |in: EI+ACK
|           +------------+    |      |           |out: ACK
|           |                 |      |           |
|           |in: EI           |      |out: EI    |
|           |out: EI+ACK      |      |           |
|           |                 |      |           |
|           v                 |      |           |
| +-----------+               |      |        +-----------+
| | REKEY_IN  |---------------+      +------->| REKEY_OUT |
| +-----------+    in: ACK                    +-----------+
|     |  ^   ^                                 |  ^      |
|     |  |   |                        in: EI   |  |      |
|     +--+   |                                 V  |drop  | in: EI+TR
|   in: EI   +--------------------------------[C]-+      | out:EI+TR+ACK
|   out: EI+ACK                  out: EI+ACK             |
|                                                        |
+--------------------------------------------------------+

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

_______________________________________________
Hipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 9 Jun 2005 10:14:28 -0400

I don't have time to consider this now in detail, but
just an idea:  Can't we apply ideas from the TCP state
machine?  It allows SYNs and FINs to be crossing in
parallel and handles them nicely, and IIRC in a simpler
way than what you are now suggesting.

--Pekka