Re: an SPD syntax example

[Tero Kivinen <kivinen@iki.fi>]

Stephen Kent writes:
> >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 

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?

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

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

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

No.

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

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

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

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.
-- 
kivinen@safenet-inc.com