[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.