> Note that > the current text MUST be changed, as it gives the wrong reason for > not including the flow label under the ICV. So, we either change the > rationale provided, or we change how we handle the field. All I was > asking was which of these would folks prefer. > > Steve
Perhaps the reason given in RFC 2402bis should be simply stated. The flow label described in AH v1 was mutable, and in RFC 2460 was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AH v2. Since no one has been able to articulate a compelling security-related reason to include the flow label in the ICV, it would be unwise to knowingly introduce an incompatibility between AH v1 and AH v2? Bert > -----Original Message----- > From: Stephen Kent [mailto:[EMAIL PROTECTED] > > At 12:39 PM +0300 9/13/04, Jari Arkko wrote: > >Steve, > > > >>We are not talking about changing AH v1; we are discussing AH v2. > >>To correctly implement AH v2, one already has to be able to > >>accommodate 64 bit sequence numbers, vs. the 32 bit sequence > >>numbers in v1. AH v2 is still an I-D, not an RFC. So, while a > >>change in whether to include the flow label in the ICV would make > >>v2 not backward compatible with v1, v2 is already not backward > >>compatible with v1 due to the required sequence number support > >>difference. > > > >I think the word "compatible" is inadequate to describe the > >situation completely. > > > >It is true that AHv2 defines 64 bit sequence numbers, but the > >last time I looked at the draft, the extended sequence number > >space was an option that was only used when peers agreed to > >use it. So AHv2 still supports the old 32 bit sequence numbers > >too. The use of the 64 bit range is negotiated in IKE, and > >it is not used if either side wants to avoid it. I think > >this applies to the other changes of AHv2 as well. > > Note that the 64 bit sequence number option is the default for IKEv2. > We have no other way to signal use of the newest versions of these > protocols, so the sequence number option really acts as a signal, at > least for AH. It is not clear that there are any backwards > compatibility problem re the current and next versions of AH, if we > don't make this change. ESP might be an issue, depending on how > folks react to receipt of the "no next protocol" header, etc. > > >This leads me to believe that AHv2 is an *extension* of > >AHv1, and an AHv1 implementation can still work well together > >with an AHv2 implementation. To put it in another way, > >an AHv1 implementation may not fullfill all the requirements > >of AHv2, but an AHv2 implementation will fulfill all the > >requirements of AHv1. Correct? > > see above comments > > >If so, the change of the flow label ICV calculation rules > >would break this compatibility between AHv1 and AHv2. > >I think we need to be careful when making such changes. > >Is it really necessary? Will AHv2 use a different protocol > >number as Itojun suggested, or will the use of the new > >ICV calculation rules be signalled in IKE? Otherwise it > >is not possible to have interoperability. OTOH, assuming > >we need to allocate new protocol numbers or add yet another > >negotiation parameter, are the benefits of the change > >worth the cost? > > same protocol number, unless someone says something very soon! > > Yes, the question is whether it is worth whatever cost (new protocol > number or lack of backwards compatibility) we incur. I'm not sure it > is. I just want to make sure that the IPsec and IPv6 WGs have a > chance to explore the issues before we declare AH done. Note that > the current text MUST be changed, as it gives the wrong reason for > not including the flow label under the ICV. So, we either change the > rationale provided, or we change how we handle the field. All I was > asking was which of these would folks prefer. > > Steve -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
