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

RE: Addresses in traffic selectors in IKEv2



I second the motion to get rid of ranges.   We are not supporting ranges in
our implementation for this same reason.

Casey
-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of dracca@quarrytech.com
Sent: Tuesday, March 19, 2002 7:20 AM
To: msa@burp.tkv.asdf.org; kent@bbn.com
Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org;
ipsec@lists.tislabs.com
Subject: RE: Addresses in traffic selectors in IKEv2


Have you ever tried to implement a range using a CAM-based lookup engine for
policy matching?  Masks are easy  - (arbitrary) ranges are most definitely
not.  If you're going to do away with something, get rid of the range.  At
the risk of stirring the pot a bit more, since I was neither in Mr.
Simpson's hotel room, nor anywhere near San Diego in '93 (or whatever the
year was), I might ask, who thought up this range thing, and why was it
thought to be a good idea, anyway?

regards

-----Original Message-----
From: Markku Savela [mailto:msa@burp.tkv.asdf.org]
Sent: Tuesday, March 19, 2002 12:06 AM
To: kent@bbn.com
Cc: andrew.krywaniuk@alcatel.com; paul.hoffman@vpnc.org;
ipsec@lists.tislabs.com
Subject: Re: Addresses in traffic selectors in IKEv2


> From: Stephen Kent <kent@bbn.com>

> Ranges can be used to express what masks can express and so we should
> probably do away with masks. We should also prohibit trivial ranges
> that define a single address.

Or more uniform, express all in ranges, including single address.

> We are adding enumerated lists for all selector types, and that
> should replace the singleton  selector values.
>
> Any more suggestions for reducing ambiguity in expressing selectors?

Everyone seems to ignore my previous comment about TS: they should not
been as SPD selectors, but SAD information instead.

SPD selectors are not needed for any IKE, the SAD values are.

As to other suggestions: can your TS handle connection specific SA's?
For that you need both src and dst ports.

I repeat my earlier example: if you want connection specific SA's for
all of your SMTP connections to a specific mail server, you can write
a policy

   dst=mailserveraddress, remote-port=25 -> SA-requirements

where, SA-requirements include the bit of information that each
connection is to have a different SA, and thus the port information
from the matched packets is passed to the IKE. And IKE needs a way to
pass this info over while negotiating the SAs. I assumed TS was
representing this information set. If not, what payload will do it
then?

Note the on server side the policy line is naturally expressed

  local-port=25 -> SA-requirements


Note, that SPD selectors do not match. It would be pointless to
transfer them.