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

From: [email-masked] (Henderson, Thomas R)
Date: Mon Mar 15 17:41:00 2004

>=20
> We seem to have a (slight) disagreement on two points:
> - the architectural goal of no distinction between responder
>    and initiator in ESTABLISHED state

I agree that to preserve this goal, it may be necessary to
explicitly have the substate. =20

(from your original message)
> - 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?

I would not favor sending unsolicited R2s.   I would favor
moving to ESTABLISHED as you suggest below.

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

Agreed.  It would be easiest if the main difference between
R2-SENT and ESTABLISHED were only the willingness to respond
to retransmitted I2. =20

How about, "leave R2-SENT if either some time has expired
(allowing for maximal retransmission of I2s), or some data=20
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)."

> - the question about whether we need initial RR
>=20

I'm having a hard time imagining a responder application
that blasts away on a newly created SA that it didn't
even initiate or receive any application data on. =20

(from previous message)
> - 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?

I would vote for treating the UPDATE as grounds for moving to
ESTABLISHED, and dealing with "UPDATE processing fails" case
the same as is done in ESTABLISHED.

Tom