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