Subject: [Hipsec] Text for solving the R2 losses problem

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 12 06:33:00 2004

At the Seoul meeting it was decided that I would
produce proposal text for the R2 loss problem, basically
adding a new state "R2 sent".  We now need your comments
on this, in order to resolve this issue in the base spec.

Here are my proposed changes; all references to RESYNC
should be changed accordingly (staying at R2-SENT) if
the WG decision is to remove resynch from the base spec.

1. Section 5.4.1 HIP States:

-  Add a new state "R2-SENT", just after "I2-SENT" state:

    R2-SENT Waiting to finish HIP

2. Section 5.4.2 HIP State Process:

-  In states UNASSOCIATED, I1-SENT and I2-SENT, change the rule for
    receiving an I2 as follows:

    Receive I2, process
         if successful, send R2 and go to R2-SENT
         if fail, stay at UNASSOCIATED/I1-SENT/I2-SENT

-  In state ESTABLISHED, REKEYING and RESYNC, change the rule
    for receiving an I2 as follows:

    Receive I2, process with Birthday check
         if successful, send R2, drop old SAs, establish new SA, go to
         R2-SENT
         if fail, stay at ESTABLISHED/REKEYING/RESYNC

-  Add a new state "R2-SENT", just after "I2-SENT" state:

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

    Receive I1, send R1 and go to RESYNC
    Receive I2, process,
       if successful, send R2, and cycle at R2-SENT
       if failed, stay at R2-SENT
    Receive R1, drop and stay at R2-SENT
    Receive R2, drop and stay at R2-SENT

    Receive ESP for SA, process and go to ESTABLISHED
    Receive UPDATE, process
       if successful, send UPDATE and go to ESTABLISHED
       if failed, stay at R2-SENT
    Should not ever need rekey

Comments/questions:
- should we have a timeout?  What if we do, should the
   Responder move to ESTABLISHED, send yet another R2 and
   move to ESTABLISHED, or drop the association?
- In practice, an implementation may just stay in R2-SENT
   for a brief period of time (few seconds), poll the SA
   to see if any traffic has been received, and if so, move
   to ESTABLISHED.
- I am unsure of what we should do with UPDATE.  It is
   perfectly possible to receive an UPDATE.  That is,
   the Initiator may send an UPDATE immediately as a response
   to a R2, informing the Responder about its multi-homing
   situation.  As a consequence, receiving an UPDATE should
   also be an indication that the Initiator is in ESTABLISHED.
   However, what if processing fails?  Is staying at R2-SENT
   the right approach?

3. Section 5.4.3 Simplified HIP State Diagram

The state diagram has to be redrawn accordingly.  Here is a
suggestion:

           DGM to send  +--------------+  I2 received
        +---------------| UNASSOCIATED |---------------+
        |               +--------------+               |
        v                                              |
   +---------+  I2 received                            |
   | I1-SENT |---------------------------------------+ |
   +---------+                                       | |
        |                 +------------------------+ | |
        | R1 received     | I2 received            | | |
        v                 |                        v v v
   +---------+            |                     +---------+
   | I2-SENT |------------+                     | R2-SENT |
   +---------+                                  +---------+
        |                                         |  ^  ^
        |                                         |  |  |
        | R2 received   +--------------+   ESP    |  |  | I2 w/BD
        +-------------->| ESTABLISHED  |<---------+  |  |
                        +--------------+             |  |
          Rekey to perform | ^  ^ |  | I2 w/BD       |  |
        +------------------+ |  | |  +---------------+  |
        |                    |  | |                     |
        v                    |  | |                     |
   +---------+ UPDATE recvd  |  | | R1 w/BD    +---------+
   | REKEY   |---------------+  | +----------->| RESYNC  |
   +---------+                  |              +---------+
                                | ESP/UPDATE/timeout |
                                +--------------------+

Note that the diagram above reverts back to the previous
practice that it is an R1, not I1, that triggers resync.
But most probably we just remove the whole resync from
the state machine; the diagram above just suggests where
it plugs in, if we add it in a different draft.

I'll propose text to Section 8 once we have agreement on
the basic approach.

Comments?  Questions?

--Pekka

---

From: [email-masked] (Petri Jokela)
Date: Fri Mar 12 08:40:02 2004

> -  Add a new state "R2-SENT", just after "I2-SENT" state:

I would say that we should send another R2 and stay at R2-SENT. (How many 
times?) If there is no data after N retries, we should probably drop the 
association. Isn't it so that the reason why the initiator starts the 
negotiation is that it has some data to send? On the other hand, can there be 
a situation when the Initiator sets up an SA, just to make sure that there is 
an SA for some data that will come later?

>    However, what if processing fails?  Is staying at R2-SENT

The information that we need in R2-SENT state (for state transition) from the 
UPDATE packet is that the correct node has sent it. Thus, if the signature 
check is ok, we know that the UPDATE has come from the correct host and that 
it has received our R2 packet. In this case we could move to ESTABLISHED. It 
doesn't matter if the packet is otherwise correct or not; if not ok, we just 
move to ESTABLISHED and do not respond with an UPDATE. But, if signature 
fails, we naturally should stay at R2-SENT as we do not know who sent the 
packet. 

However, this makes things more complicated as we should determine how the 
UPDATE fails and the next state would depend on that. I think that it is 
simpler just stay at R2-SENT if the incoming UPDATE fails. 

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