RE: Temporary version of the new IKEv2 draft

["Charlie Kaufman" <charliek@microsoft.com>]

----On Wednesday, March 24, 2004 5:55 AM, Michael Row wrote:
>The phrase "or port is OPAQUE" is dangerously ambiguous here.
>What I *think* this text means is that the "ANY" selector is encoded
>as [0, 65535], and that the "ANY" selector will match a non-initial
>fragment ("OPAQUE" port number).

I was trying to do something minimal but helpful, and may have disturbed
a hornet's nest. My instructions were to clarify the encoding of icmp
type/code but with a pointer to a message from Charlie Lynn that
proposed several changes including clarifications to handling of OPAQUE.

There has been much debate on this list as to how OPAQUE should be
handled in 2401bis. I have been hoping that debate would conclude with
something that did not require changes to IKEv2. The specification of
traffic selectors in IKEv2 is already imperfect. There is a provision,
for example, to open parallel SAs with identical traffic selectors for
the purpose of dividing streams with different QOS processing but there
is no way to specify how they are divided in the traffic selectors (or
in 2401bis as far as I know).

However the OPAQUE debate gets resolved in the specs, I believe most
implementations will ignore the issue because they will not filter on
ports. I wanted to make it clear that specifying start and end ports of
[0, 65535]
means ALL (any port number) and OPAQUE (port number unknown). I believe
that was a reasonable interpretation of the old language, but wanted to
make it explicit. How implementations handle fragments in the case where
they are filtering on ports (or worse, are sending different ports'
traffic over different SAs) is a corner case that has to be decided or
there will be interoperability problems in that corner case. But I don't
think it's reasonable for us to design mechanisms for implementations to
negotiate how those cases are handled using IKEv2. Either design a
mechanism everyone can live with or fight it out in interoperability
testing.

I'd be happy to take out the phrase "or port is OPAQUE" if people think
it's confusing. Just so long as everyone understands and agrees that [0,
65535]
means ALL packets and fragments regardless of port.

	--Charlie

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Michael Roe
Sent: Wednesday, March 24, 2004 5:55 AM
To: ipsec@lists.tislabs.com
Subject: Re: Temporary version of the new IKEv2 draft

draft-ietf-ipsec-ikev2-13.txt says:
>  o  Start Port (2 octets) - Value specifying the smallest port
>      number allowed by this Traffic Selector. For protocols for
>      which port is undefined, or if all ports are allowed or
>      port is OPAQUE, this field MUST be zero. 

The phrase "or port is OPAQUE" is dangerously ambiguous here.
What I *think* this text means is that the "ANY" selector is encoded
as [0, 65535], and that the "ANY" selector will match a non-initial
fragment ("OPAQUE" port number).

However, as well as OPAQUE port numbers, we also have the "OPAQUE"
selector,
which matches non-initial fragments. There's a question of how IKE
represents the "OPAQUE" selector - how do you negotiate a fragment-only
SA.
Someone might read this text as saying that to negotiate a fragment-only
SA (an SA whose selector is "port=OPAQUE") you set start_port=0 and
end_port=65535. But that won't work, because there's no way to
distinguish
between "ANY" and "OPAQUE" if they are both encoded as [0, 65535].

I thought that Charlie Lynn's proposal was to represent an "OPAQUE"
selector
as [65535, 0], to distinguish it from the "ANY" selector [0, 65535].

See http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html:
> Please add text saying that OPAQUE is encoded by setting a "start"
> field to the maximum value and the "end" field to the minimum value.

Note that "start" is the *maximum* value and "end" is the *minimum*
value...

Mike