Subject: RE: Final editing changes to IKEv2

From: "Michael Roe" <[email-masked]>
Date: Wed, 17 Mar 2004 13:14:15 -0000

> 4.  Clarification about encoding the icmp type/code 
> (bit-packing issue) from
>     Charlie Lynn
> 
>         http://www.vpnc.org/ietf-ipsec/mail-archive/msg02701.html
>                                                               
>                  

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)

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

Thanks!
Mike

---

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 17 Mar 2004 18:59:08 -0500

> 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