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

From: [email-masked] (Ahrenholz, Jeffrey M)
Date: Wed Sep 8 19:18:01 2004

Could host A choose the SPI of the SA associated with the interface that the UPDATE was received on? The destination address of the received UPDATE may  help in choosing the SPI to respond with -- although the draft says "a basic property of HIP SAs is that the inbound IP address is not used as a selector for the SA." (sect. 4.1) If B wants to rekey, it seems that both SAs/SPIs will be affected.

-Jeff

-----Original Message-----
From:	Mika Kousa [mailto:[email-masked]]
Sent:	Wed 9/8/2004 4:42 PM
To:	[email-masked]
Cc:	
Subject:	[Hipsec] Multiple SAs and UPDATE, mm-02
Assume that hosts A and B, both supporting mm-02 specification, have set 
up SAs. This is the situation after the base exchange (as in Figure 1 in 
mm-02).

Then host A adds a new interface, so A creates a new SA for it and 
performs the things written in section 5.2 Host multihoming.

Now B wants to rekey using the UPDATE mechanism as defined in the base 
specification (only NES and SEQ parameters). Selection of values what to 
put into the NES is trivial, because B has only one SA to update. When A 
receives the B's UPDATE, it has to reply to the UPDATE packet. The problem 
is now that what SPI value A has to put into the NES's field Old SPI ? The 
one from the SA which was set up during the base exchange or the one from 
the SA which was set up later ?

Is the selection a matter of some policy, eg. update the SA we have used 
last when sending data to the peer ? Or are we just undeterministic: just 
update any SA so the update process finishes smoothly according to the 
specifications. Is the described issue a design error or just my own 
misunderstanding ?
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: [email-masked] (Mika Kousa)
Date: Thu Sep 9 07:24:01 2004

On Wed, 8 Sep 2004, Ahrenholz, Jeffrey M wrote:

-> Could host A choose the SPI of the SA associated with the interface 
-> that the UPDATE was received on? The destination address of the 
-> received UPDATE may help in choosing the SPI to respond with -- 
-> although the draft says "a basic property of HIP SAs is that the 
-> inbound IP address is not used as a selector for the SA." (sect. 4.1) 
-> If B wants to rekey, it seems that both SAs/SPIs will be affected.

This looks like one possible alternative. If the implementation uses the 
suggested "one SA per interface" scheme, then I think that the selection 
of correct SPI to use in the reply-UPDATE is quite simple to implement. 
Just get the interface through which the packet was received, and then 
perform a simple lookup from the network_interface-SA relationship table.