Re: Addresses in traffic selectors in IKEv2

[Stephen Kent <kent@bbn.com>]

Folks,

This has been a helpful message exchange, as I think there is a clear 
desire to move to a uniform way of negotiating values for all 
selectors, and the list of ranges (allowing for trivial ranges) does 
just that. Steve Bellovin reminded me that JFK proposes this approach 
and I think it is an excellent one. This approach encompasses what 
could be expressed via masks, a single value, or a list of individual 
values.

As others have noted, it may be preferable for a management interface 
to allow other forms of data entry, e.g., masks, but what we're 
talking about is what will appear in the SPD model and in IKE 
exchanges. Also recall that the SPD model does not say how one must 
implement the functionality, just what the required functionality is. 
Thus it's OK for a management interface to provide a mask capability 
that is translated into a range representation internally. I am aware 
of several IPsec implementations that offer management interfaces 
that map well into the SPD functional requirements even though they 
do not translate the SPD description directly.

Finally, re use of CAMs in high speed hardware, I think it was useful 
to observe that one can represent all of these forms of selector 
values via (ternary) CAM entries, but not necessarily on a one-to-one 
basis.  Going forward, I plan to use a model for 2401bis that assumes 
use of de-correlated SPD entries, which is consistent with use of a 
ternary CAM for processing.  Again, the processing model is not 
proscriptive from an implementation perspective, but it does 
establish functional requirements.

Some folks have noted that allowing ranges and multiple discrete 
values for selectors associated with a single SA will eat up CAM 
entries faster. That's true, but the motivation for including these 
sorts of multi-valued selectors is to address real world 
requirements. We used to have analogous requirements in 2401, prior 
to publication, but we removed them at the last minute to accommodate 
limitations in IKE v1.  I've been told by several vendors that this 
is a feature that clients have asked for, which reinforces the notion 
that it is appropriate to include in 2401bis.

The goal here is to allow a security administrator/user to cause all 
traffic directed to a peer IPsec device, and that meets certain 
syntactic criteria, to be mapped to a single SA. This is desirable to 
avoid creation of additional SAs when not otherwise desired by the 
administrator/user.

Steve