[Hipsec] Text for solving the R2 losses problem

[Pekka Nikander <pekka.nikander at nomadiclab.com>]

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