RE: The remaining IKEv2 issues - #64

[Black_David@emc.com]

Charlie,

As part of this (unless I missed it), please add sentences
to make the following points:

- IKEv2 deliberately allows parallel SAs with the same traffic
	selectors between common endpoints.  One of the purposes of
	this is to support traffic QoS differences among the SAs;
	see Section 4.1 of RFC 2983 (informative reference).
- Hence unlike IKEv1, given two endpoints, traffic selectors need
	not uniquely identify an SA between those endpoints.
- Therefore the IKEv1 rekeying heuristic (use of same traffic
	selectors as an existing SA indicates rekeying, so existing
	SA should be deleted shortly after new one is up) SHOULD NOT
	be used, as it will result in unintended SA deletion.

This may help avoid some surprises arising from implementation code
reuse.

Also, [RFC2401bis] needs to be added to the list of normative references.

Thanks,
--David
----------------------------------------------------
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
----------------------------------------------------

> -----Original Message-----
> From: Charlie_Kaufman@notesdev.ibm.com 
> [mailto:Charlie_Kaufman@notesdev.ibm.com] 
> Sent: Tuesday, August 19, 2003 9:21 PM
> To: jpickering@creeksidenet.com
> Cc: ipsec@lists.tislabs.com
> Subject: Re: The remaining IKEv2 issues - #64
> 
> 
> 
> 
> 
> 
> jpickering@creeksidenet.com wrote:
> > I must have missed the resolution on issue 64, can someone 
> remind me of
> > the resolution
> > and rationale?
> 
> The issue was that people were concerned about how an 
> implementation could
> know which SA was being rekeyed when a rekey request arrived. 
> In the past,
> I had assumed that they would know because the traffic selectors would
> match the traffic selectors on the replaced SA. But recent 
> discussions have
> allowed for the possibility of multiple SAs with the same 
> traffic selectors
> for playing games with QOS and such.
> 
> The proposed solution was to include the SPI of the rekeyed SA in the
> request to create a new SA, so there would be no ambiguity. 
> It might also
> help with the race conditions that can produce duplicate SAs and the
> "continuity across rekeying" issue raised by Nicolas 
> Williams. I added an
> additional field to the Create_Child_SA exchange to carry the SPI.
> 
>       --Charlie
>