Subject: RE: Final editing changes to IKEv2

From: "Michael Roe" <[email-masked]>
Date: Wed, 24 Mar 2004 14:41:43 -0000

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Theodore Ts'o
> Sent: 17 March 2004 23:59
> To: Michael Roe
> Cc: [email-masked]
> 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

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 24 Mar 2004 20:20:57 -0500

On Wed, Mar 24, 2004 at 02:41:43PM -0000, Michael Roe wrote:
> Suppose that you want to have a SA that only protects the Home Test
> message (MH type = 3). Charlie Lynn's suggestion was...  "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)".

That was the part of Charlie Lynn's message which we specifically
commended to Charlie's attention, and indeed it is in
draft-ietf-ipsec-ikev2-13.txt.

						- Ted