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

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.