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

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 28 Sep 2004 10:07:29 -0700

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

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

> 
> The draft doesn't seem to answer this, so let's speculate 
> what happens 
> when NES parameters are not sent in a single packet:
> 
> The initial UPDATE packet sent by host A contains NES1+NES2+SEQ. The 
> packet is sent out and the peer host B starts to process it.
> 
> Let's assume that the peer B sends corresponding NES+SEQ+ACK 
> for each of 
> the NES received in the initial UPDATE. B sends a reply 
> UPDATE containing 
> only one NES, and moves to rekeying state. Then assume that 
> before the 
> host B continues processing on to NES2, host A sends ACK, and 
> B receives 
> it. According to the base draft host B can now move back to 
> established, 
> 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 
cover the multihomed case, so there should be language in hip-mm
to clarify this.

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

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

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

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

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

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

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

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

Tom
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec