[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QoS selectors (was LAST CALL: IKE)



At 12:36 PM +0300 7/1/03, Tero Kivinen wrote:
>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.

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

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

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

>
>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/