Re: QoS selectors (was LAST CALL: IKE)

[Tero Kivinen <kivinen@ssh.fi>]

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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/