[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: an SPD syntax example
At 4:03 +0200 1/22/04, Tero Kivinen wrote:
>Stephen Kent writes:
>> Comments welcome, other than those arguing for use of another syntax :-)
>>
>> SPD ::= SEQUENCE of SPDEntry
>>
>> SPDEntry ::= SET OF SelectorSet
>>
>> SelectorSet ::= SEQUENCE {
>> sourceAddr AddrList,
>> destAddr AddrList,
>
>Why are these AddrList types? Why not simply AddrOrList, or actually
>even better remove AddrList, AddrOrList, IPaddr and change this to
>IPRange, and add comment to IPRange saying that if start == end then
>it is single address (==IPaddr). As this is explaining the minimal
>SPD, I think it should really be minimal, and it should not do
>optimizations where we save 4/16 bytes by not expressing IPaddr as
>IPRange constructs, or by having less SelectorSets by allowing each
>list have list of ranges, instead of having multiple SelectorSets each
>having one range. The bad thing is that now we have two different ways
>to express same thing:
Good point. We'll just refer to ranges, and note that a single
address is a trivial range.
>
>SPDEntry = {
> SelectorSet = {
> sourceAddr = { 10.0.0.1, 10.0.0.5 }
> destAddr = { 10.0.2.1 }
> ... rest omitted
> }
>}
>
>and
>
>SPDEntry = {
> SelectorSet = {
> sourceAddr = { 10.0.0.1 }
> destAddr = { 10.0.2.1 }
> ... rest omitted
> }
> SelectorSet = {
> sourceAddr = { 10.0.0.5 }
> destAddr = { 10.0.2.1 }
> ... rest omitted
> }
>}
>
>of course when the number of items in the list grows then the
>combinatory explosion will create huge number of SPDEntry items, but
>on the other hand this is simply explaining minimal format for the
>SPD, real SPDs will propably have more compressed formats anyways.
right. My goal here is just to better explain what the text was
trying to say, and it is not trying to optimize the representation.
>
>In IKEv2 you still need to convert the IPaddr to IPRange before using
>it in the traffic selector.
right, and the other suggestion we received pointed this out. We'll
remind folks that the admin interface can use various syntactic
options to make it easier, even though a list of ranges is all one
needs and it is precisely what IKEv2 sends.
>Also in the IKEv2 there is no construct of AddrList at all, we have
>two lists (source and destination) of Traffic Selectors (==
>SelectorSet), each having on start and end addresses (IPRange), and
>port range.
>
>Because in the IKEv2 we do have separate source and destination lists,
>it will remove the combinatory explosion, thus the same example can be
>expressed as (using the format described in the end of this email):
yes, but the SPD is also used to represent bypass and discard access
controls. So, maybe we need to define two classes of entries, one
for IPsec SA creation and one for bypass/discard, where the IKE
selector payload conventions do not apply. Also, the PFP flag is not
in this syntax, yet, and it does need to be in the syntax for the
former class of SPD entries, even though it is not sent in the IKE
payload.
>SPDEntry = {
> source = {
> TrafficSelector = { Addr = 10.0.0.1-10.0.0.1, ... }
> TrafficSelector = { Addr = 10.0.0.5-10.0.0.5, ... }
> }
> destination = {
> TrafficSelector = { Addr = 10.0.2.1-10.0.2.1, ... }
> }
>}
>
>> protocol INTEGER, -- 8 bits
>> next CHOICE {
>> ports SEQUENCE {
>> SourcePort INTEGER, -- 16 bits
>> DestPort } INTEGER, -- 16 bits
>
>This should be range of ports not single port. IKEv2 allows port
>ranges.
I'm confused. In the current version of IKE (12), section 3.13.1
describes the Traffic Selector format. It consists of one byte for
the protocol, not a range, with 0 being the way to indicate ANY. It
defines a range for ports (directional) and a range for addresses
(directional). This structure can be repeated multiple times in the
payload. did this change in the latest version?
>
>> mobilityHdr INTEGER, -- 16 bits
>
>This is not yet negotiable by the IKEv2.
it needs to be, and it can be represented using the port fields.
>
>> ICMP [0] SEQUENCE {
> > type INTEGER, -- 8 bits
>> code INTEGER } } -- 8 bits
>
>This is also type and code range in IKEv2. Also one closing } is
>missing (matchintg the SelectorSet sequence).
I agree that IKE allows this, but I think it is a bad idea. In
general it does not make sense to list a range of types for which a
range of codes is applicable, since codes are interpreted for each
type differently. It's not like UDP, TCP, and SCTP, where all the
well known ports are interpreted in the same way for each protocol.
Yes, it is syntactically possible to list ranges here, but is it a
good idea? We do have a problem in that the value 0 is assigned to
echo reply, so we can't use that value to indicate ANY. maybe the
best solution here is to say that the ICMP Type and Code range MUST
be trivial, unless we want to signal ANY, in which case the range
MUST be 0-255.
>
>> AddrList ::= SET OF AddrOrList
>
>This is not possible in the IKEv2. I assume this is union of all
>ranges, and this can be combined with any source and destination
>pairs?
>
>> AddrOrList ::= CHOICE {
>> iPAddr IPaddr -- individual IP address
>> range IPRange} -- IP address range
>>
>> IPaddr ::= CHOICE {
>> v4Addr INTEGER, -- 32 bits
>> v6Addr [0] INTEGER } -- 128 bits
> >
>> IPRange ::= CHOICE {
>> v4range SEQUENCE {
>> start INTEGER, -- 32 bits
>> end INTEGER } -- 32 bits
>> v6range [0] SEQUENCE {
>> start INTEGER, -- 128 bits
>> end INTEGER } } -- 128 bits
>
>Using same syntax the actual TrafficSelector which can be expressed in
>the IKEv2 is:
>
>SPD ::= SEQUENCE of SPDEntry -- List of SPD Entries
>
>SPDEntry ::= SEQUENCE { -- Each entry
>consist of
> source TrafficSelectorList, -- source and
> destination TrafficSelectorList } -- destination selectorlists
>
>TrafficSelectorList ::= SET OF TrafficSelector -- Each selectorList
> -- is list of selectors
>
>TrafficSelector ::= SEQUENCE { -- either source or
> -- destination selector
> Addr IPRange,
> protocol INTEGER, -- 8 bits
> next CHOICE {
> ports SEQUENCE {
> portStart INTEGER, -- 16 bits
> portEnd } INTEGER, -- 16 bits
> ICMP [0] SEQUENCE {
> typeStart INTEGER, -- 8 bits
> codeStart INTEGER, -- 8 bits
> typeEnd INTEGER, -- 8 bits
> codeEnd INTEGER } } } -- 8 bits
>
>IPRange ::= CHOICE {
> v4range SEQUENCE {
> start INTEGER, -- 32 bits
> end INTEGER } -- 32 bits
> v6range [0] SEQUENCE {
> start INTEGER, -- 128 bits
> end INTEGER } } -- 128 bits
I like the more compact syntax, but we need to resolve the
disagreement about the protocol field representation in IKE, and
maybe adopt the conventions re ICMP type/code values. We also need
text to accommodate the mobility header support. Plus, I need to add
in the PFP flag, and create a separate entry type for bypass/discard.
I'll take another cut at this at the start of next week.
Thanks for all the feedback.
Steve