Subject: [Hipsec] moving from R2-SENT to UNASSOCIATED

From: "Henderson, Thomas R" <[email-masked]>
Date: Sat, 21 May 2005 14:13:29 -0700

In the paper by Aura et al., there is a proposal:

"7a) The timeout transition from the R2-SENT state should lead to
the UNASSOCIATED state."

Earlier, it is said:
"The reason for waiting for the ESP packet is key confirmation;
only after receiving the ESP packet the Responder knows that the
Initiator received a fresh Diffie-Hellman key (rather than a
replay) in R1 and has computed the valid session key.  The
timeout transition breaks this mechanism."

Actually, key confirmation is not the reason-- instead, the
reason is the desire to avoid distinguishing between Initiator
and Responder after the exchange completes, yet be able to
properly handle the possible transmission loss of R2.  See:
http://honor.trusecure.com/pipermail/hipsec/2004-April/000672.html

The Responder can learn that the Initiator received a fresh DH-key
when it checks the HMAC on the I2.

But getting back to proposal 7a), I question whether transition
to UNASSOCIATED is solving the real problem.  It may be that we
do not want to have any special timeout transition from R2-SENT.

The reason that R2-SENT is a useful state is that it allows the
Responder to reply to a duplicate (retransmitted, or replayed)
I2 without changing its state.  If R2 was truly lost, this reply
will serve the same purpose as the original R2.  If R2 were not
lost, the retransmitted R2 will simply be ignored.

Consider if the timeout value of R2-SENT is too short (or
zero), and the following situation occurs-- the first R2 sent
is successfully received (moving Initiator to ESTABLISHED)
but I2 is retransmitted or replayed (or retransmission of I2
crosses paths with the initial R2).  The (previous) Responder
may process this I2 as if it were a new one, following the
rules for ESTABLISHED state, and cycle back into R2-SENT or
ESTABLISHED.  The new R2 (with new SPI) will be sent to
the previous Initiator, but it will discard it.  The two
sides will be out of sync now.  The situation would be the
same if R2-SENT transitioned to UNASSOCIATED.

Because of this, the timeout value to move from R2-SENT
should be large enough to avoid such possibilities.  And
that makes me question whether any timer is needed.  Moving
from R2-SENT to ESTABLISHED could instead just be triggered
based on reception of a packet (data on a SPI, HIP UPDATE)
that indicates that the peer got the R2.

If the group agrees, I'll propose some text to change this
behavior.

Tom

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

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 22 May 2005 07:13:30 +0300

> If the group agrees, I'll propose some text to change this

In principle, sounds fine to me.  OTOH, I think it might be
good to allow a *long* timeout after which the Responder
MAY revert to UNASSOCIATED.  That timeout could be in the
order of the default inactivity timeout of the association...

--Pekka