[secdir] Secdir review of draft-ietf-ipsecme-failure-detection-05

Magnus Nyström <magnusn@gmail.com> Mon, 07 March 2011 07:13 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 94DFC3A6902; Sun, 6 Mar 2011 23:13:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id hmZyAbmUd7S3; Sun, 6 Mar 2011 23:13:38 -0800 (PST)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id 692633A68F2; Sun, 6 Mar 2011 23:13:38 -0800 (PST)
Received: by iyj8 with SMTP id 8so4528508iyj.31 for <multiple recipients>; Sun, 06 Mar 2011 23:14:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=9cu1G2XccRxlGjnuicfzIsfy/UK1vb9BBdiTEWrGIYg=; b=xGUs66d6jcfhMrl3c64dLy5xpIkGCFNxNPIr3HaDBNHLD/CTbtgnRPCqh5piyRP5vK Vyg4voho2njuDgbS4ESy8E2m8z/enMGL2rQ/BnHoF8dIM9qM85UbSG4L3mLu81bsdkxL X3eNJ0JedeR2/jyFzhyqhJhsl1Mx0qYnDCqDA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZZfEzjKXkaMzkp6M6UlfJ0nm7EIYnIKjXByfd+6XayNZQbmusUHHxKRClcw/u8/ZQ3 sM8jTZe6iJGNOwI3XDnnjOJ5QTfOUZJBt1NU0Qg58iwUzMldKS5c+ScJQWBXuBSmp46b 5Hpz3oYXWU0QrnZJtPrRHJyTyyJLQnv+vI7Iw=
MIME-Version: 1.0
Received: by with SMTP id t10mr4064881ics.34.1299482091288; Sun, 06 Mar 2011 23:14:51 -0800 (PST)
Received: by with HTTP; Sun, 6 Mar 2011 23:14:51 -0800 (PST)
Date: Sun, 6 Mar 2011 23:14:51 -0800
Message-ID: <AANLkTimnm6bwA+YmfiSaTRhqPYVK0AgLh1vVdNCWb+qA@mail.gmail.com>
From: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= <magnusn@gmail.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ipsecme-failure-detection@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] Secdir review of draft-ietf-ipsecme-failure-detection-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2011 07:13:39 -0000

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