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

From: [email-masked] (Pekka Nikander)
Date: Mon Apr 19 03:33:04 2004

[Returning to an old issue.]

>> Pekka Nikander <[email-masked]> wrote:
>>>   1. Do we want to preserve the distinction between the
>>>      initiator and responder once we are in ESTABLISHED?
>>>      The original goal was NOT to have any distinction.

> Andrew McGregor wrote:
>> Which is, I think, pretty much essential to retain.  That way it is 
>> always safe for either end to be the initator of any further 
>> mechanisms, without having to deal with differences to do with who 
>> was the initiator of the whole session.

On Mar 26, 2004, at 11:42, Petri Jokela wrote:
> Further developing the idea: store R2 when we as responder send it 
> out. As an initiator, we do nothing. Define in ESTABLISHED that 
> respond to an I2 with an R2 if stored, otherwise drop the I2. In this 
> case, I think, we move in the grey zone (as the term is in sports when 
> you use something "almost" doping), because we "know" that we are a 
> responder if we have an R2.

I think that is a good way to implement.  However, I would be
more careful with the spec.

What seems to be essential is that a Responder is prepared to
reply to a resent I2 with an R2 as long as it does *not* know,
for sure, that the Initiator has got the R2 as is therefore
in the ESTABLISHED state.  IMHO, it MAY reply longer, even if
it knows that the Initiator is in ESTABLISHED.  That would
give pretty much leeway for different implementations.

-10-pre1 seems to have adopted my suggestion of the state
machine with R2-SENT.  If I remember correctly, Tom objected
having that as a separate state, or at least having the
statement "leave R2-SENT if either some time has expired
(allowing for maximal retransmission of I2s), or some data
has been received on the SA, or an UPDATE packet has been
received (or some other packet that indicates that the peer
has moved to ESTABLISHED)."  I think this suggestion is good,
and I am folding it in below.

We still need changes to Section 8.7. and probably a new
section handling moving out from R2-SENT.  The following
changes are against -10-pre1

For Section 8.7, I would suggest the following:

   Add new steps between current 2 and 3:

     2.1  If the system is in the R2-SENT state, it MAY check
          if the newly received I2 is similar to the one that
          triggered moving to R2-SENT.  If so, it MAY retransmit
          a previously sent R2, reset the R2-SENT timer, and stay
          in R2-SENT.

     2.2  If the system is in any other state, it SHOULD
          check that the birthday value in I2 is larger than
          the currently stored peer birthday value, if there is
          a stored value.  If the newly received I2 has a lower
          or equal birthday value than the stored one, the I2 is
          stale (perhaps replayed) and SHOULD be dropped.

   Remove step 9, as the birthday check is now performed earlier.

   Change Step 17 to read:

      17. Upon successful processing of an I2 in states UNASSOCIATED,
          I1-SENT, I2-SENT, and R2-SENT, an R2 is sent and the state
          machine transitions to state R2-SENT.

   In Step 18, replace

      s/transitions to ESTABLISHED,/transitions to R2-SENT,/

   Add a new step after 18:

     19. Upon transitioning to R2-SENT, start a timer.  Leave
         R2-SENT if either the timer expires (allowing for
         maximal retransmission of I2s), some data has been
         received on the incoming SA, or an UPDATE packet has
         been received (or some other packet that indicates
         that the peer has moved to ESTABLISHED).  Implementing
         this step is OPTIONAL.

Question:  Should #19 be RECOMMENDED instead of OPTIONAL?

Are there anything else with this issue (#23), or could we
close it?

--Pekka