RE: Final editing changes to IKEv2

["Michael Roe" <mroe@microsoft.com>]

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com 
> [mailto:owner-ipsec@lists.tislabs.com] On Behalf Of Theodore Ts'o
> Sent: 17 March 2004 23:59
> To: Michael Roe
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Final editing changes to IKEv2
> 
> On Wed, Mar 17, 2004 at 01:14:15PM -0000, Michael Roe wrote:
> > I agree with this change. But Charlie's original message also asked
> > for clarification of how the mobility header type is encoded.
> > I think we should adopt Charlie's suggestion for encoding 
> the mobility
> > header type as well (note that it isn't obvious, so interoperability
> > problems are likely if it isn't described)
> 
> Currently IKEv2 specifies that for ESP and AH, SA's always exist in
> pairs.  So there's a higher level issue which is whether or not
> unidirectional traffic selectors should be supported in the first
> place.
> 
> I'll note that Charlie Lynn's suggestion (setting the responder's
> traffic selectors to Opaque) doesn't seem to make sense since whether
> or not the selectors should be unidrectional or not is orthoganal to
> what the responder's ip port/address range would be.  
> 
> In any case, adding support for a unidrectional traffic selector would
> appear to be adding new feature to IKEv2, at a time when we're trying
> come to closure on the specification.  Is this something that has to
> be done in the base spec, or should we do this as a later extension to
> IKEv2?
> 
> 						- Ted

I was referring to a different part of Charlie Lynn's message. I was talking
about bidirectional SA's that protect some MIPv6 messages and not others, not
unidirectional SA's.

Suppose that you want to have a SA that only protects the Home Test message
(MH type = 3). Charlie Lynn's suggestion was that it would be
negotiated with the following traffic selector:

protocol = 135
start port = 0x300
end port = 0x300

(He said: "and text saying that the  Mobility Header Type should be in the most
significant 8 bits and the least significant 8 bits should be 0 for the "start"
field of the range and 255 for the "end" field)".

Another obvious possibility would have been:

protocol = 135
start port = 3
end port = 3

If we don't specify which of these it is, there could be some nasty interop problems.

However, I'm not going to be too upset if this doesn't make it into the IKEv2 RFC.
I suspect we're going to need a separate RFC to explain how MIPv6 uses IKEv2 ---
just as we have draft-ietf-mobileip-mipv6-ha-ipsec-06.txt to explain how MIPv6 uses
IKEv1 ---  so it can always go in there.

There's a general problem here: whenever someone assigns a new value of the protocol
field in the IP header, there needs to be a document explaining what the IKEv2 "start
port" and "end port" mean for the new protocol. It's clearly undesirable to revise the
IKE specification every time this happens, so a separate document explaining the encoding
is OK.

Mike