Subject: RE: [Hipsec] Some mm-02-pre1 comments

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 15 Jun 2004 15:04:43 -0700

> -----Original Message-----
> From: Mika Kousa [mailto:[email-masked]]
> Sent: Tuesday, June 15, 2004 8:18 AM
> To: [email-masked]
> Subject: Re: [Hipsec] Some mm-02-pre1 comments
> 
> 
> Do we need a new parameter (or modify NES) for indicating 
> that the old SAs
> should not be deleted ? I read and re-read the draft several 
> times but I
> couldn't figure out how the simultaneous SPI/address 
> associations can be
> accomplished as in Figure 2 of chapter 5.1. Or have have just
> misunderstood something..

mm-02-pre1 doesn't deal with that issue explicitly.  I have
thought about setting old SPI = new SPI to indicate the
case for which the new SPI was not replacing anything.

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

---

From: Mika Kousa <[email-masked]>
Date: Wed, 23 Jun 2004 15:14:57 +0300 (EEST)

On Tue, 15 Jun 2004, Henderson, Thomas R wrote:

-> > -----Original Message-----
-> > From: Mika Kousa [mailto:[email-masked]]
-> > Sent: Tuesday, June 15, 2004 8:18 AM
-> > To: [email-masked]
-> > Subject: Re: [Hipsec] Some mm-02-pre1 comments
-> >
-> >
-> > Do we need a new parameter (or modify NES) for indicating
-> > that the old SAs
-> > should not be deleted ? I read and re-read the draft several
-> > times but I
-> > couldn't figure out how the simultaneous SPI/address
-> > associations can be
-> > accomplished as in Figure 2 of chapter 5.1. Or have have just
-> > misunderstood something..
->
-> mm-02-pre1 doesn't deal with that issue explicitly.  I have
-> thought about setting old SPI = new SPI to indicate the
-> case for which the new SPI was not replacing anything.

All right, that could be one option.

If we use this scheme where Old SPI and New SPI fields in the NES
parameter are the same, then this means that we do not need to create any
new SAs. Because of this the Keymat Index field should be just ignored
(maybe it should be set to zero).

Anyway, we need to acknowledge the initial UPDATE containing the addresses
belonging to the current SPI. This kind of an UPDATE packet might need
some alternative processing rules. When a host receives an initial UPDATE
with Old SPI=New SPI, should the peer host follow the same convention ?
That is, both hosts do not create any new SAs, so we need some kind of a
reply UPDATE packet which just tells the peer "I got your address list
belonging to the previous SPI you have been using". In this case the "wait
for data on new SA" phase can be skipped. If the sender of the reply
UPDATE would like to create new SAs, it sends an another UPDATE after
sending the reply UPDATE, just as in the current draft says.

I haven't looked so closely at the latest base draft
(draft-ietf-hip-base-00) yet, but looks like a simple reply UPDATE packet
containing just the ACK parameter and no SEQ parameter would act as an
acknowledgement.

One more thing in this scenario: if there is not need for rekeying, should
we move into REKEYING state anyway or stay at ESTABLISHED ?
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec