[secdir] secdir review of draft-ietf-dhc-dhcpv6-failover-requirements

"Scott G. Kelly" <scott@hyperthought.com> Sat, 13 July 2013 22:09 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C48521F9EA7 for <secdir@ietfa.amsl.com>; Sat, 13 Jul 2013 15:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raqOGLmPstCm for <secdir@ietfa.amsl.com>; Sat, 13 Jul 2013 15:09:05 -0700 (PDT)
Received: from smtp122.iad.emailsrvr.com (smtp122.iad.emailsrvr.com [207.97.245.122]) by ietfa.amsl.com (Postfix) with ESMTP id E538521F9E2D for <secdir@ietf.org>; Sat, 13 Jul 2013 15:09:04 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id C1C9B240272; Sat, 13 Jul 2013 18:09:02 -0400 (EDT)
X-Virus-Scanned: OK
Received: from legacy7.wa-web.iad1a (legacy7.wa-web.iad1a.rsapps.net [192.168.2.216]) by smtp52.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8F9B9240260; Sat, 13 Jul 2013 18:09:02 -0400 (EDT)
Received: from hyperthought.com (localhost [127.0.0.1]) by legacy7.wa-web.iad1a (Postfix) with ESMTP id 60E8D3200B4; Sat, 13 Jul 2013 18:09:02 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sat, 13 Jul 2013 15:09:02 -0700 (PDT)
Date: Sat, 13 Jul 2013 15:09:02 -0700 (PDT)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: draft-ietf-dhc-dhcpv6-failover-requirements.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1373753342.3954517@apps.rackspace.com>
X-Mailer: webmail7.0
Cc: "iesg@ietf.org" <iesg@ietf.org>
Subject: [secdir] secdir review of draft-ietf-dhc-dhcpv6-failover-requirements
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 13 Jul 2013 22:09:10 -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 describes requirements for dhcpv6 failover. The document seems to be a combined problem statement and requirements document.

When I read requirements document like this, I expect to see a progression from use cases to goals to requirements. Sometimes the use cases (and some/all goals) are outlined in a problem statement, but the point is that the described requirements have some associated basis/rationale. This allows us to understand the relative importance of a given requirement, and the tradeoffs if we can't meet it for some reason.

I didn't find this when it comes to security. There is a security considerations section, and for convenience, here it is:

   The design must allow secure communication between the failover
   partners.  This requirement applies to the specification only, i.e.
   the design must include a way to secure communication.  It does not
   mandate such security be employed, just that it be available.

   The protocol specification, when it is written, should provide
   operational guidelines in the case of authentication mechanisms that
   require access to network servers that have the potential to be
   unreachable (e.g. what to do if a partner is reachable, but remote
   Certificate Authority is unreachable due to network partition event).

   The security considerations for the design itself will be discussed
   in the design document.

What is "secure communication", and why is it required? The second paragraph seems to imply that authentication is part of it, but is that all? 

The last line seems to punt on security considerations, and maybe that is acceptable to the working group. I'm not advocating for a detailed security analysis in the requirements document, but I do think a high level discussion of goals/requirements for confidentiality, integrity, and availability makes sense. You will need this in order to discuss the suitability of any proposed security mechanisms in later documents. This document seems like the right place for that.

--Scott