Subject: [Hipsec] Multiple SAs and UPDATE, mm-02

From: [email-masked] (Henderson, Thomas R)
Date: Tue Sep 28 12:01:08 2004

> -----Original Message-----
> From: Mika Kousa [mailto:[email-masked]]=20
> Sent: Wednesday, September 15, 2004 3:35 AM
> To: [email-masked]
> Subject: Re: [Hipsec] Multiple SAs and UPDATE, mm-02
>=20
>=20
> The more I read the draft the more I'm beginning to get confused..
>=20
>=20
> If the initial UPDATE contains multiple NES parameters as=20
> mentioned in=20
> section 6.2, does the reply UPDATE also have to include all=20
> NES parameters=20
> in a single packet ?

I do not believe that this is (or should be) a requirement.

>=20
> The draft doesn't seem to answer this, so let's speculate=20
> what happens=20
> when NES parameters are not sent in a single packet:
>=20
> The initial UPDATE packet sent by host A contains NES1+NES2+SEQ. The=20
> packet is sent out and the peer host B starts to process it.
>=20
> Let's assume that the peer B sends corresponding NES+SEQ+ACK=20
> for each of=20
> the NES received in the initial UPDATE. B sends a reply=20
> UPDATE containing=20
> only one NES, and moves to rekeying state. Then assume that=20
> before the=20
> host B continues processing on to NES2, host A sends ACK, and=20
> B receives=20
> it. According to the base draft host B can now move back to=20
> established,=20
> because B has sent its own NES and even received ACK for it.

I don't think that B can move back to established because it
has additional NES pending to process.  The base draft doesn't=20
cover the multihomed case, so there should be language in hip-mm
to clarify this.

>=20
> Now B continues to process the rest of the A's NES=20
> parameters, NES2 that=20
> is. At this point B is in established state, but the NES processing=20
> function might think it is in still in rekeying state. Problems might=20
> arise.

I don't think that state machine should transition in the
middle of packet processing.

>=20
> The other thing here is that the SEQ parameter can not be the=20
> same for all=20
> reply UPDATES of B, or else they are considered as=20
> retransmissions (and=20
> therefore possibly dropped).
>=20

Agreed.  Each time a new UPDATE is generated, a new SEQ should
be used.

>=20
> So, in short I assume that the answer to my question is=20
> "yes"; all NES=20
> parameters of B have to be in a single packet. The solution=20
> to the state=20
> machine problem would be to send the reply UPDATE not before=20
> all of the=20
> NES parameters are ready.

I think that one can certainly hold the reply UPDATE, but it
is not mandated. =20

>=20
> If someone else understood what I'm trying to=20
> say here, I would like to get some confirmation whether I'm right or=20
> wrong. The draft might also be updated regarding this issue.
>=20
>=20
> I also have a feeling that the possibility of sending a=20
> separate UPDATE=20
> containing only ACK and then a separate UPDATE containing the=20
> corresponding NES+SEQ could be removed. Allowing reply=20
> UPDATEs to contain=20
> only NES+SEQ+ACK might provide cleaner implementations.

I would prefer to avoid such restrictions on packetization unless
necessary.

Tom