Re: an SPD syntax example

[Stephen Kent <kent@bbn.com>]

At 4:32 +0200 1/23/04, Tero Kivinen wrote:
>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.

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.

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

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

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

yes.

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

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