Re: an SPD syntax example

[Stephen Kent <kent@xxxxxxx>]

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