Re: Addresses in traffic selectors in IKEv2

[Derek Atkins <warlord@mit.edu>]

The problem is that with a mask you cannot specify as specific a set
of addresses as you can with a range?

For example, how would you specify the set of addresses from, say,
18.101.1.3-18.101.1.9 (inclusive) using a mask?

-derek

"Casey Carr" <kcarr@nc.rr.com> writes:

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

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available