Subject: [Hipsec] new preview of mobility mgmt. draft

From: [email-masked] (Henderson, Thomas R)
Date: Wed Jul 7 11:39:01 2004

> -----Original Message-----
> From: Mika Kousa [mailto:[email-masked]]=20
> Sent: Wednesday, July 07, 2004 5:12 AM
> To: [email-masked]
> Subject: Re: [Hipsec] new preview of mobility mgmt. draft
>=20
>=20
> About section 5.1 "Mobility with single SA pair" bullet point=20
> 1, when the
> UPDATE does not have a NES parameter, the draft says "the=20
> host transitions
> to a logical READDRESSING state, in which it waits until its UPDATE is
> acknowledged."
>=20
> What does this "logical READDRESSING state" mean from an=20
> implementation
> point of view ? I did not find any other references what this logical
> state really means. It is not related to the state machine in any way,
> right ?

It means that the host is waiting for the other side to acknowledge
its UPDATE.  Whether we consider the substate of "waiting for UPDATE
acknowledgement" to be part of ESTABLISHED state or a separate state
may be a matter of style.  "READDRESSING" might be renamed "UPDATING"
if we are just waiting for UPDATE ack-- it may apply to more than=20
READDRESSING.  I am not convinced that we need to extend the overall
state machine, but we might want to clarify what is meant there--
the host is basically in ESTABLISHED state but it requires an
acknowledgment of its UPDATE or it will retransmit it eventually.

Presently, we have a REKEYING state.  The reason that this is slightly
different than the readdressing case or general update case is that
a host that is rekeying needs to receive both an ack of its UPDATE
and the peer's NES (and optionally, DIFFIE_HELLMAN), since rekeying
always occurs for a pair of security associations.  Also, to make the
protocol simpler, we suppress generating further UPDATEs while in=20
REKEYING.  So this amount of departure from ESTABLISHED state seemed
to me to justify defining the separate REKEYING state in the state
machine.

>=20
> If we receive other than the acknowledging UPDATE packets before we
> receive the acknowledging UPDATE packet, are they just dropped ?

In general, I would say no.  Do you have a specific example where
you think it should be dropped?

Tom

---

From: [email-masked] (Mika Kousa)
Date: Thu Jul 8 05:18:01 2004

On Wed, 7 Jul 2004, Henderson, Thomas R wrote:

-> > -----Original Message-----
-> > From: Mika Kousa [mailto:[email-masked]]
-> > Sent: Wednesday, July 07, 2004 5:12 AM
-> > To: [email-masked]
-> > Subject: Re: [Hipsec] new preview of mobility mgmt. draft

-> > If we receive other than the acknowledging UPDATE packets before we
-> > receive the acknowledging UPDATE packet, are they just dropped ?
->
-> In general, I would say no.  Do you have a specific example where
-> you think it should be dropped?

Actually no, at least not yet. I haven't thought about this so much yet.