[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [209.85.210.172]) 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 10.42.130.10 with SMTP id t10mr4064881ics.34.1299482091288; Sun, 06 Mar 2011 23:14:51 -0800 (PST)
Received: by 10.231.11.140 with HTTP; Sun, 6 Mar 2011 23:14:51 -0800 (PST)
Date: Sun, 06 Mar 2011 23:14:51 -0800
Message-ID: <AANLkTimnm6bwA+YmfiSaTRhqPYVK0AgLh1vVdNCWb+qA@mail.gmail.com>
From: Magnus Nyström <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 accurate. - 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
- [secdir] Secdir review of draft-ietf-ipsecme-fail… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ipsecme-… Magnus Nyström
- Re: [secdir] Secdir review of draft-ietf-ipsecme-… Yoav Nir