The remaining IKEv2 issues

["Theodore Ts'o" <tytso@mit.edu>]

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