Last Call Review of draft-ietf-ipsecme-failure-detection-

Request Review of draft-ietf-ipsecme-failure-detection
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-03-15
Requested 2011-02-26
Draft last updated 2011-03-11
Completed reviews Secdir Last Call review of -?? by Magnus Nystrom
Tsvdir Last Call review of -?? by Mark Allman
Assignment Reviewer Magnus Nystrom
State Completed
Review review-ietf-ipsecme-failure-detection-secdir-lc-nystrom-2011-03-11
Review completed: 2011-03-11


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document defines a new extension (the "QCD token") to the IKEv2
protocol that allows for faster detection of SA de-synchronization.

- General:
  o "Quick Crash Detection": Is "crash" really the right term here? As
the document indicates, the SA de-synchronization may have had other
reasons than a crash...? The term "failure detection" seems more

- Section 1, Introduction:
  o "However, in many cases the rebooted peer is a VPN gateway that
protects only servers, or else the non-rebooted peer has a dynamic IP
address" - it is not clear from this how or why the dynamic IP address
of the non-rebooted peer impacts the tunnel re-establishment?
  o Editorial: "is a quick" -> "in a quick"?

- Section 2, RFC 5996 Crash Recovery :
  o "There are cases where the peer loses state and is able to recover
immediately; in those cases it might take several minutes to recover."
- so a peer is able to recover immediately, yet it might take several
minutes to recover?? Unclear what is meant here.

- Section 5, Token Generation and Verification:
  o (Not sure why these methods are called stateless as the QCD_SECRET
must be maintained?)
  o By adding a nonce to the token generation the attack outlined in
Section 9.3 would be impossible, as the attacker would also need to
guess the nonce (adding a nonce to the TOKEN_SECRET_DATA generation
would also have the effect that even for the same SPIs, the
TOKEN_SECRET_DATA would be different). More generally, a standard key
derivation scheme such as the Concatenation KDF in NIST SP 800-56 may
be considered.

- Section 9.2, Security Considerations:
  o Last paragraph: "This method should not be used..." - unclear what
method is being referred to here?

- Appendix A.2:
  o Would have been useful with a sentence or two that indicated why
the working group preferred the QCD proposal over the SIR one.

-- Magnus