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

From: Mika Kousa <[email-masked]>
Date: Thu, 9 Sep 2004 02:42:48 +0300 (EEST)

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: Jan Mikael Melen <[email-masked]>
Date: Thu, 9 Sep 2004 09:48:09 +0300

Hi!

On Thursday 09 September 2004 02:42, Mika Kousa wrote:
> receives the B's UPDATE, it has to reply to the UPDATE packet. 

How has your implementation gotten out from the rekeying state if it has not 
sent a NES parameter that would create a new SA? Atleast base spec says that 
the update must be ACKed and a NES parameter received before you can move 
back to the established state. This would mean that you'll probably have two 
pairs of SAs on both ends. Not one pair and a half as you are suggesting if I 
have understood you correctly.

> The problem 

You'll anyway have to pair these SAs in order to know which SA is associated 
to which interface otherwise you will be asking for trouble. From this 
pairing you know that if you'll receive with old SPI X value then the 
corresponding old SPI Y value is the one to put in to the NES. 

Next question probably is that the B has only one interface well then the B 
has to do some sort of "virtual" interface for itself because B still has two 
different routes to A as A has said that I'll have two different interfaces. 

Now If the B also creates a new interface then this gets interesting and the 
number of created SAs is a policy matter IMHO.

  Regards,
	Jan

---

From: Mika Kousa <[email-masked]>
Date: Thu, 9 Sep 2004 15:18:25 +0300 (EEST)

On Thu, 9 Sep 2004, Jan Mikael Melen wrote:

-> On Thursday 09 September 2004 02:42, Mika Kousa wrote:
-> > 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. 
-> 
-> How has your implementation gotten out from the rekeying state if it has not 
-> sent a NES parameter that would create a new SA? Atleast base spec says that 
-> the update must be ACKed and a NES parameter received before you can move 
-> back to the established state. This would mean that you'll probably have two 
-> pairs of SAs on both ends. Not one pair and a half as you are suggesting if I 
-> have understood you correctly.

Maybe you misunderstood a little bit, I guess. I try to clarify a bit 
(assuming that I read the specification correctly):

After the base exchange:

  --SPI_AtoB_1-->
A                 B
  <--SPI_BtoA_1--

A adds a new interface which has SPI=SPI_BtoA_2. According to section "5.2 
Host multihoming":

A sends UPDATE(NES(Old SPI=SPI_BtoA_2, New SPI=SPI_BtoA_2), SEQ)
B sends UPDATE(NES(Old SPI=SPI_AtoB_1, New SPI=SPI_AtoB1'), SEQ, ACK)
A sends UPDATE(ACK)

(SPI_AtoB1' indicates that it replaces the old SPI SPI_AtoB1.)

Now A and B are back in established state, and B sees that it can select 
from two possible SPIs of A:

  --SPI_AtoB_1'-->
A                 B
  <--SPI_BtoA_1--
  <--SPI_BtoA_2--

See, no two pairs of SAs. I have understood that a host can have 1..n 
active SAs at the same time, so SAs need not to be "paired" somehow. Or 
they even can not be paired: how to pair SAs if A has 3 SAs and B has 4 
SAs ?

Then host B wants to rekey:

B sends UPDATE(NES(Old SPI=SPI_AtoB_1', New SPI=Old SPI=SPI_AtoB_1''), SEQ)
A sends UPDATE(NES(Old SPI= X ..)

This is the issue I was just thinking: how to select the SPI X. 
"Is it SPI_BtoA_1 or SPI_BtoA_2 or what ? And why ?"

-> You'll anyway have to pair these SAs in order to know which SA is associated 
-> to which interface otherwise you will be asking for trouble. From this 
-> pairing you know that if you'll receive with old SPI X value then the 
-> corresponding old SPI Y value is the one to put in to the NES. 

I'll have to think about this issue a little bit more. Especially what 
this pairing of SAs mean from an implementation point of view.

-> Next question probably is that the B has only one interface well then the B 
-> has to do some sort of "virtual" interface for itself because B still has two 
-> different routes to A as A has said that I'll have two different interfaces. 

These virtual intefaces add complexity to the implementation.

-> Now If the B also creates a new interface then this gets interesting and the 
-> number of created SAs is a policy matter IMHO.

Currently I'm trying to implement some level of support for mm-02. It has 
been a while since a read the mm-02, so I can not yet say if there are any 
flaws in the mm-02 regarding the handling of multiple SA handling.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Jan Mikael Melen <[email-masked]>
Date: Fri, 10 Sep 2004 10:16:10 +0300

> they even can not be paired: how to pair SAs if A has 3 SAs and B has 4

Yes, I'll see but how are you planning to use those SAs. For example if 
interfaces on A have different link speeds? 

You will never be able to use the full link capacity from either interface as 
returning packets are always going through one interface. (You have one pair 
and a half)

OR are you planning to use the AtoB SA on two different interfaces then I'll 
have to ask how are planning to protect yourself from replay protection 
window over run?

  Regards,
	Jan

---

From: Mika Kousa <[email-masked]>
Date: Tue, 14 Sep 2004 12:14:46 +0300 (EEST)

On Fri, 10 Sep 2004, Jan Mikael Melen wrote:

-> -----BEGIN PGP SIGNED MESSAGE-----
-> Hash: SHA1
-> 
-> On Thursday 09 September 2004 15:18, Mika Kousa wrote:
-> >
-> > After the base exchange:
-> >
-> >   --SPI_AtoB_1-->
-> > A                 B
-> >   <--SPI_BtoA_1--
-> >
-> >
-> > A adds a new interface which has SPI=SPI_BtoA_2. According to section "5.2
-> > Host multihoming":
-> >
-> > A sends UPDATE(NES(Old SPI=SPI_BtoA_2, New SPI=SPI_BtoA_2), SEQ)
-> > B sends UPDATE(NES(Old SPI=SPI_AtoB_1, New SPI=SPI_AtoB1'), SEQ, ACK)
-> > A sends UPDATE(ACK)
-> >
-> > (SPI_AtoB1' indicates that it replaces the old SPI SPI_AtoB1.)
-> >
-> > Now A and B are back in established state, and B sees that it can select
-> > from two possible SPIs of A:
-> >
-> >   --SPI_AtoB_1'-->
-> > A                 B
-> >   <--SPI_BtoA_1--
-> >   <--SPI_BtoA_2--
-> >
-> > See, no two pairs of SAs. I have understood that a host can have 1..n
-> > active SAs at the same time, so SAs need not to be "paired" somehow. Or
-> > they even can not be paired: how to pair SAs if A has 3 SAs and B has 4
-> > SAs ?
-> 
-> Yes, I'll see but how are you planning to use those SAs. For example if 
-> interfaces on A have different link speeds? 

I really haven't even thought that far. The only thing I just wanted to 
know is that what to put in the Old SPI field of the NES parameter when 
there are multiple choices. I would like to see some guidance about this 
issue in the specification, because I can't even test alternative 
implementations if I can't figure out what data I should put into the 
packets.

-> You will never be able to use the full link capacity from either interface as 
-> returning packets are always going through one interface. (You have one pair 
-> and a half)

As above...

-> OR are you planning to use the AtoB SA on two different interfaces then I'll 
-> have to ask how are planning to protect yourself from replay protection 
-> window over run?

What I'm trying is to implement is the one-SA-per-network interface, as 
recommended in the draft (section 4.1). Not to use some kind of a shared 
SA for all interfaces.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Mika Kousa <[email-masked]>
Date: Wed, 15 Sep 2004 13:35:27 +0300 (EEST)

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 ?

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.

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.

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).

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.

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.
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec