Re: The remaining IKEv2 issues

["jpickering@creeksidenet.com" <jpickering@creeksidenet.com>]

I must have missed the resolution on issue 64, can someone remind me of 
the resolution
and rationale?

Thanks,
Jeff

Theodore Ts'o wrote:

> Last week on August 12, Angelos posted a status of the remaining issues
> reamining open on the IKEv2 document at the end of wg last call, and
> thos that were closed as of the -09 document.  The only comments made to
> Angelos' issues were some editorial nits raised by Abraham Shacham,
> which were recorded in the issue tracker as issue #66.
> 
> Of the remaining issues left open per Angelos' message of August 12:
> 
>  1: (Rekeyed SA use)
>  7: (Fragmentation negotiation (before/after IPsec processing)
>  10: (NAT Traversal support)
>  16: (Negotiate ToS in IKEv2)
>  41: (NAT traversal missing text)
>  55: (ICMP fields as selectors ?)
>  64: (Use the SPI of SA being rekeyed in a notify payload during rekey)
>  65: (EAP)
> 
> Issues 1, 10, 41, 55, and 64 were actually addressed in the -09, but had
> not been marked as closed.
> 
> Of the remaining three issues:
> 
>  7: (Fragmentation negotiation (before/after IPsec processing)
>  16: (Negotiate ToS in IKEv2)
>  65: (EAP)
> 
> There does not seem to be consensus for issue #7, and this is something
> which can be added later as an extension to IKE if and when there is
> consensus.  Nor does it seem that the lack the ability to do red side
> fragmentation (and the ability to forbid black side fragmentation) to be
> a fundemental lack in the IKEv2 specification.  (Indeed, it has been
> pointed out that the transmitter can not guarantee that other gateways
> might fragmented encrypted packets, and that this situation might change
> dynamically as routing changes.)
> 
> Issue #16 is something which has yet to be discussed as part of the RFC
> 2401-bis discussion.  As we discussed earlier, if we came to consensus
> before this document exited IETF last call, subject to AD approval, we
> could add the necessary text to support TOS selectors to the IKE
> specification.  (The IKEv2 specification has a dependency on RFC
> 2401-bis, so it can't be published by the RFC editor until we finish RFC
> 2401-bis anyway.)  Alternatively, if we do not come to consensus,
> support for TOS selectors can be added in a subsequent document easily
> enough.
> 
> The final issue #65, concerns whether or not non key-generating EAP
> methods should be supported, in order to avoid a Man-in-the-middle
> attack (MITM) attack.  However, as Charlie has pointed out, as used in
> IKEv2, the server is authenticated with a certificate before the
> authentication code is passed.  In addition, given the requirement to
> support one-time password and Generic Token cards, we can not forbid the
> use of non-kg EAP schemes.  Hence, given that the MITM attack which was
> the concern raised by issue #65 is not an issue for IKEv2, we believe
> that this is not something that should hold back the publication of
> IKEv2 as a Proposed Standard.
> 
> Charlie has just put out the -10 version of the IKEv2 document, which
> addresses the editorial nits which were raised by Abraham Shacham and
> others after -09 was released.  With these issues closed (or as closed
> as they are going to be), we believe that the -10 version is ready for
> IETF last call, once it the -10 version has been processed by the IETF
> secretariat.
> 
> 					- Ted and Barbara
> 
> 
>