Subject: an SPD syntax example

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Jan 2004 14:42:58 -0500

Folks,

In trying to more precisely explain the nominal structure for the 
SPD, we found it helpful to create a sample syntax using ASN.1. 
Remember, this is not a requirement to use ASN.1 to represent the 
SPD, but rather a way of explaining the structure of the SPD, now 
that we have more complex entries. We're thinking of putting this in 
the next rev of 2401bis, either as part of the SPD description, or as 
an appendix.

Comments welcome, other than those arguing for use of another syntax :-)

Steve

P.S.  make your e-mail viewing wide enough to preserve the 
indentation, for easy reading.
---------

SPD ::= SEQUENCE of SPDEntry

SPDEntry ::= SET OF SelectorSet

SelectorSet ::= SEQUENCE {
	sourceAddr	AddrList,
	destAddr	AddrList,
	protocol	INTEGER,	-- 8 bits
	next CHOICE {
		ports	SEQUENCE {
				SourcePort	INTEGER, -- 16 bits
				DestPort }	INTEGER, -- 16 bits
		mobilityHdr	INTEGER, -- 16 bits
		ICMP [0] SEQUENCE {
			type	INTEGER,	-- 8 bits
			code	INTEGER } }	-- 8 bits

AddrList ::=  SET OF AddrOrList

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 22 Jan 2004 04:03:45 +0200

> SelectorSet ::= SEQUENCE {

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:

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. 

In IKEv2 you still need to convert the IPaddr to IPRange before using
it in the traffic selector.

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):

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

> 				DestPort }	INTEGER, -- 16 bits

This should be range of ports not single port. IKEv2 allows port
ranges. 

> 		mobilityHdr	INTEGER, -- 16 bits

This is not yet negotiable by the IKEv2. 

> 			code	INTEGER } }	-- 8 bits

This is also type and code range in IKEv2. Also one closing } is
missing (matchintg the SelectorSet sequence). 

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

> 						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 {
-- 
[email-masked]

---

From: [email-masked]
Date: Thu, 22 Jan 2004 10:55:12 +0530 (IST)

> 				DestPort }	INTEGER, -- 16 bits
Range of ports can be allowed.

> AddrList ::=  SET OF AddrOrList

It is better to make this as close to IKEv2 Traffic Selector as
possible. Based on that, each IP address range should be combined with
Protocol/Port Range. This ASN1 description seems to be creating a set with
multiple IP address ranges to a single Protocol and Port (Range).

AddrList ::= AddrOrRangeOrSubnet

> 			range	IPRange} -- IP address range

Above should become
AddrOrRangeOrSubnet ::= CHOICE {
                         ipAddr IPaddr
                         range IPRange
                         subnet subNet
                      }
> 						end	INTEGER } } -- 128 bits

Internally, subnet and IPAddr should be converted to range, if IKEv2 is
used for key management.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Jan 2004 10:20:32 -0500

>multiple IP address ranges to a single Protocol and Port (Range).

Good point. I'll change the syntax, and the 2401bis text to align 
with the IKEv2 proposal format more closely.  The effect is the same, 
ultimately, in terms of associating a set of values with the same SA.

>AddrOrRangeOrSubnet ::= CHOICE {

I don't see a need to refer to subnets separately. ranges suffice.

>Internally, subnet and IPAddr should be converted to range, if IKEv2 is

Yes, we ultimately convert to range for the selector payload.

Steve

---

From: vamsi <[email-masked]>
Date: Thu, 22 Jan 2004 15:38:43 -0800

Hi,
    I felt that original SPD syntax is good, which provides very good
    flexibility and ease of administering the policies in large enterprise
    environments.

    Consider that, there are 50 discrete subnets in an organization and
    the security needs to be applied for port 25, port 80 and port 110.
    With the original approach (ASN1), proposed by Steve, it only requires
    configuration of 50 ranges of IP addresses, 3 ranges of Ports and
    put them in one Selector list.

    If we go by approach suggested by 'Ravi', configuration of 150
    selector lists need to be created. This problem compounds when the
    remote site has multiple discrete subnets. Consider that, remote site
    has 20 subnets and that requires 3000 Selectors lists at the local end.

    Due to this, I feel, original ASN1 text, with some minor modification
    would be good.

           sourcePort   srcPorts,
           destPort       dstPorts
         }

AddrOrList ::= CHOICE {

srcPorts :=  SET OF Ports

Ports :=  SEQUENCE OF {
                    startPort  start
                    endPort    end
               }
   Note: For clarity, I took ICMP part away.

If we go with this approach, some changes to 'Traffic Selector' in IKEv2 
are required.
It means that, each traffic Selector should be able to accommodate
        Number of IP address ranges
        <all IP address ranges>
         Protocol
         Number of Port ranges
         <all Port ranges>

thoughts?

Thanks
Vamsi
CTO Office
www.intoto.com

At 10:20 AM 1/22/2004 -0500, Stephen Kent wrote:

>Good point. I'll change the syntax, and the 2401bis text to align with the 
>IKEv2 proposal format more closely.  The effect is the same, ultimately, 
>in terms of associating a set of values with the same SA.
>
>>
>>>                                                 end     INTEGER } -- 32 
>>> bits

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Jan 2004 20:52:40 -0500

>having one range. The bad thing is that now we have two different ways

Good point.  We'll just refer to ranges, and note that a single 
address is a trivial range.

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

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

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

>This should be range of ports not single port. IKEv2 allows port

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?

>This is not yet negotiable by the IKEv2.

it needs to be, and it can be represented using the port fields.

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

>						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

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Jan 2004 04:32:23 +0200

> selector payload conventions do not apply. Also, the PFP flag is not 

I do not see need for that. In the IKEv2 format there is source and
destination addresses and ports tied to together under one SPDEntry.
The difference is that the SPD entry consist of two items, one listing
list of source addresses and ports and another listing list of
destination addresses and ports. In your approach the SPD entry
contains list of items each having both source and destination
address.

What is the problem with the IKEv2 style format when using bypass and
discard items?

> the protocol, not a range, with 0 being the way to indicate ANY. It 

I said range of PORTS, not range of protocols. The protocol is not
range, it is always only one single value or ANY, and if ANY is used
then port numbers are not used (there is no point using port range as
the usage of the port fields depends on the protocol). 

> payload. did this change in the latest version?

No.

> it needs to be, and it can be represented using the port fields.

Hmmm.. so we need to add some more text to the IKEv2?

> be trivial, unless we want to signal ANY, in which case the range 

The reason IKEv2 allows ranges also in the ICMP types is to allow
saying allow ICMP 3/0 - 3/3 (type/code), i.e allow ICMP
NET/HOST/PROTOCOL/PORT unreachable, but do not allow NEEDFRAG, source
route failed etc. Or to allow 3/0 - 3/13 meaning any known ICMP
unreachable erros. Note, that in most cases the code 0 is reserved,
thus it cannot be used as special ANY value.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 23 Jan 2004 04:37:11 +0200

>     flexibility and ease of administering the policies in large enterprise

The SPD format described in the RFC2401bis is going to be example SPD,
which gives out the minimal requirements for the SPD to support.
Implementations can implement any kind of compressed / optimized SPDs
as long as they can express same thing that the minimalistic example
SPD in the RFC2401bis can express. 

>     put them in one Selector list.

So implement it as subnets and compressed source and destination
addresses. You can still "convert" that to the basic format meaning,
that anyone from the outside cannot really see which format you are
using. 

>         Number of IP address ranges

No. I think it is way too late to make that kind of changes to IKEv2,
and also I think the current format is so much simplier and easier to
parse, that we can live with the few extra bytes for that kind of
cases. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Jan 2004 21:45:43 -0500

>contains list of items each having both source and destination

i was not suggesting that the original synatx was right, just that 
there are syntactic differences between what IKE assumes and what one 
might choose to do for non-SA SPD entries. For example, IKE assumes 
thet the source and destination addresses and ports are flipped re 
directional authorization, something that one need not do for 
bypass/discard entries.

>the usage of the port fields depends on the protocol).

Sorry, I misread your text. Yes, ports are ranges.

>Hmmm.. so we need to add some more text to the IKEv2?

yes.

>-

This works only in some cases, like the example you cite above, but 
not generally.  I think it a bad idea to suggest use of a syntax that 
makes sense only in some cases, maybe only for the case of 
destination unreachable.

Steve