Subject: Re: QoS selectors (was LAST CALL: IKE)

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Jul 2003 12:36:07 +0300

Stephen Kent writes:
> >In order to support simultaneous rekey tie-breaking as currently 
> >defined, one needs to be able to be able to determine
> >if the attempt to create a child is a rekey and if so, which SA is 
> >being rekeyed. The only way to do this per current
> >version is to examine the traffic selectors which presumes no redundant SAs.
> Any suggestions on how to avoid messing up the rekey heuristic and 
> not negotiating the DiffServ values for SAs?

One proposal that was made earlier, was to create traffic selector
type of SPI, i.e say that this is going to replace that SPI and copy
all traffic selector data from that SPI. This was not accepted by the
WG, and it is too late to add this kind of new features to the IKEv2.

The real problem can be solved if the end that does the rekey actually
makes sure that it also deletes the old SA almost immediately, before
it rekeys any other SA.

I.e

Host A and B have no SAs in the beginning. The Host A decides to send
packet using TOS 0x01. It creates SA pair SPI-0x0001 (inbound) and
SPI-0x8001 (outbound). It sends the packet with TOS 0x01 to
SPI-0x8001, and associates that SA to be with TOS 0x01.

The host A then receives another packet with different TOS 0x02. Host
A notices that it cannot put that packet to any of the existing SAs,
thus it creates another SA pair SPI-0x0002 (inboud) and SPI-0x8002
(outbound). Now the host A sends that packet to SPI-0x8002 and marks
it to be outbound traffic for TOS 0x02.

Host A continues to do that, and it creates new SA for each TOS value
that the policy specifies that it needs to use separate SA. There is
no need to communicate this information to B, because there is no use
for B to verify that packets come from the right SA, as when the
packets arrive to the B the possible damage of messing up QoS is
already done. There will not be reordering problems because each SA
contains only one (or multiple if specified by policy) TOS values.

When host B decides to send back packet with TOS 0x02, it notices that
it have 2 SA pairs up, and neither one of those is associated with any
TOS value. It selects any one of those SAs and associates it with TOS
value of 0x02. Lets say it took SPI-0x0001. For the next packet with
different TOS it tooks the next one (SPI-0x0002). If it have more
packets with different TOS, it needs to create more SA pairs.

Now, when the host A is rekeying the SA pair SPI-0x0001, SPI-0x8001,
it will first create new SA pair SPI-0x0003, SPI-0x8003, and then
associate the SPI-0x8003 to TOS 0x01 because that was associated with
the SA it is rekeying. After that host A sends delete notification for
the SPI-0x0001. Host B sees that delete notification, and deletes the
SA pair SPI-0x0001, SPI-0x8001, and replies with delete notification
to SPI-0x8001. Next time host B tries to send packet with TOS 0x02 it
notices, that it does not have SA associated to that TOS value, thus
it takes the next non associated SA and assings it to TOS 0x02.

Note, that this style option described here, can be made completely
optional, i.e if the other end does not support it it will simply see
multiple SAs and only use one of them (or all based on the
implementation), and the other end can send packets to separate SAs to
make sure them all arrive with proper QoS levels to other end.

As you can see from the above example it can be made work without any
need for actual negotiation of the TOS values in the IKEv2 level. We
do need the selector capability in the IPsec engine and architecture,
as we need to associate the TOS to some SAs. The selection of the
right outbound SA based on the TOS can be left to the local
implementation. I do not think we actually gain anything by doing the
checks for the inbound traffic (damage is already done when we see the
packet).

I do not know if adding TOS to IKEv2 (and explicitly associate them to
SA pair) is better than this kind of decide on the fly style, but I
simply wanted to explain how I see, how this could be done. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 01 Jul 2003 09:05:48 -0400

The only thing that comes to mind is to add a notify payload when 
rekeying that identifies the SPI of
the SA being rekeyed. But this is a bits on wire change.... I guess this 
is why Radia decided to just drop
the diffserv issue in SF.

- Jeff

Stephen Kent wrote:

> At 11:08 AM -0400 6/30/03, [email-masked] wrote:
> 
>> Re: multiple "redundant" SAs:
>> - Jeff
> Whoops!
> Any suggestions on how to avoid messing up the rekey heuristic and not 
> negotiating the DiffServ values for SAs?
> 
> Steve
> 
> 
>

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 1 Jul 2003 16:44:37 +0300

[email-masked] writes:
> Simul rekey tiebreaking from IKE's protocol perspective, requires that 
> the responder be able to
> determine at this point if the attempt to create this new SA is a rekey 
> or different SA. If there is nothing in
> the traffic spec (eg a uniqueifier) or elsewhere (eg a new notify 
> payload) to differentiate, tiebreaking
> does not work.

I do not think there is need for tiebraking in those cases. If host A
and B are going to have several SAs up anyways, and they both happen
to rekey one pair simultaneously, they create one extra SA pair, which
they can use next time they need SA which is not tied to any TOS (i.e
when they start rekying next SA, they notice that they already have
new unused SA ready, thus use it instead and simply delete the old
one).

I myself do not consider those extra SAs as a problem in general. Just
make sure that they are not all rekeyed next time, so the number of
SAs does not multiply every rekey. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Henry Spencer <[email-masked]>
Date: Tue, 1 Jul 2003 11:19:46 -0400 (EDT)

On Tue, 1 Jul 2003, Stephen Kent wrote:
> >the SA being rekeyed. But this is a bits on wire change...
>
> ...Using the SPI to identify an SA being rekeyed avoids ambiguity, no 
> matter what the source, and that seems worthwhile.

This sounds like an excellent idea.  One substantial headache with IKEv1
was the extent to which the responding end had to *guess* what the
initiating end was really trying to do.  The fewer such ambiguities there
are, the better. 

                                                          Henry Spencer
                                                       [email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2003 10:51:10 -0400

At 9:05 AM -0400 7/1/03, [email-masked] wrote:
>the SA being rekeyed. But this is a bits on wire change.... I guess 
>this is why Radia decided to just drop

That's the sort of thing I would suggest too, but wanted to hear what 
others would say.

Using the SPI to identify an SA being rekeyed avoids ambiguity, no 
matter what the source, and that seems worthwhile.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 1 Jul 2003 11:05:03 -0400

>WG, and it is too late to add this kind of new features to the IKEv2.

I agree that we ought not add a traffic selector to solve this 
problem.  But use of the SPI does seem reasonable.

>makes sure that it also deletes the old SA almost immediately, before

You don't want to kill off the old SA until traffic has migrated to 
the new SA, to minimize disruption, right?