[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: an SPD syntax example

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