RE: QoS selectors (was LAST CALL: IKE)

[Stephen Kent <kent@bbn.com>]

At 7:57 PM -0400 6/30/03, Black_David@emc.com wrote:
>Steve,
>
>>  At 11:08 AM -0400 6/30/03, jpickering@creeksidenet.com wrote:
>>  >Re: multiple "redundant" SAs:
>>  >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.
>>
>>  Whoops!
>>
>>  Any suggestions on how to avoid messing up the rekey heuristic and
>>  not negotiating the DiffServ values for SAs?
>
>We've already concluded that the DiffServ values are functionally
>opaque to the other side from a traffic classification standpoint.
>OTOH, I'm concerned that if we pass them across IKE, someone's going
>to try to use them in a way that s/he shouldn't.  So, let's go back
>to an old proposal from Radia:
>
>	So I'd propose one more field in the traffic
>	elector for "uniquifier". Alice can create
>	ultiple child-SAs to Bob with the same
>	raffic selectors, as long as they have different
>	niquifiers.
>
>The uniquifier could be some sort of internal index or pointer;
>even a simple counter works.
>
>Another possibility if rekeying is really the only problem,
>would be to pass the other side's SPI as the "uniquifier" indicating
>exactly which SA is being rekeyed.  If this is always done, the
>rekeying "heuristic" turns into a rule - when the "old SPI"
>is passed, this is a rekey of that SPI, otherwise it's a new
>SA creation.  A minor downside is that if one fails to pass the
>"old SPI" on rekey, SAs that are no longer useful may accumulate
>on the peer, but the peer is already free to garbage collect SAs,
>and these will be good candidates as they will carry no further
>traffic.
>
>Thanks,
>--David

As you note, we already SPIs as locally unique ways to refer to SAs 
between consenting IPsec implementations.  I don't see a need to add 
an arbitrary, new selector for address this problem.

Steve