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

RE: QoS selectors (was LAST CALL: IKE)


> 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

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

David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754