[secdir] SecDir Review of draft-ietf-sidr-bgpsec-reqs-11

"Adam W. Montville" <adam@stoicsecurity.com> Mon, 30 June 2014 14:56 UTC

Return-Path: <adam@stoicsecurity.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3E7F21A0367 for <secdir@ietfa.amsl.com>; Mon, 30 Jun 2014 07:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CLCSTcOu8Sg7 for <secdir@ietfa.amsl.com>; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
Received: from mail-pd0-f182.google.com (mail-pd0-f182.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9610E1A035C for <secdir@ietf.org>; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id y13so8386241pdi.13 for <secdir@ietf.org>; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:message-id:date:to :mime-version; bh=PGjwujretsGeV5CMKVAAbvE/WKgReitjjuZlZrETFrA=; b=YUO/+WR8HReYjImYktxNETXlkxAZNHBoLrmp1ubyOEcXSdnulrHo9kq/A1FgxNY3El 85G+ajW7mVkDPjK+G7KMcgisH4ZFNaIH9OnGIPR7t6qmybhKXF71D3oN3pAYeaZ5++mo GHSN7C9hseJxGUq5wvxZC0mEIiQj/2iWV5mmIDatFaK7Gao41P8mpNTnviYINt2MI/49 LqSGKtGSk6i9xvmYDpgHSA9JEmnB3WFI/VYt7hV7tT3E2UEcAGpJfJxQjZZ9mPnAcmoR KF7l7dLQ6vQYqJpr5qniySvjSDoFnrrQhvrBF6hw3PTzFRFGVTqimIxNCDrlpVDhg9dt Vcag==
X-Gm-Message-State: ALoCoQk6dFVSblBEXiEJBJta6jPnRmRD0/2zEPrGyenosM+sayfAB/1Rj9F4RH1Bf85hYgGJoUIx
X-Received: by with SMTP id ul4mr52481044pbc.15.1404140188177; Mon, 30 Jun 2014 07:56:28 -0700 (PDT)
Received: from [] (99-64-100-240.lightspeed.austtx.sbcglobal.net. []) by mx.google.com with ESMTPSA id vy5sm100992457pac.13.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 07:56:26 -0700 (PDT)
From: "Adam W. Montville" <adam@stoicsecurity.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_E335DD80-1BA7-4BF6-A7C3-9A51961A8E25"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Message-Id: <468FCC23-2398-4165-BACA-E9F0AEF742E7@stoicsecurity.com>
Date: Mon, 30 Jun 2014 09:56:27 -0500
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-sidr-bgpsec-reqs.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BVCkuBzZI5uUr1HY-CVKR97t-9U
Subject: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-reqs-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 30 Jun 2014 14:56:31 -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 is ready with (potential) nits.  When reading this requirements draft I tried to keep an eye on measurability: When implementing drafts are created, how will they be objectively measured to meet the requirements?

Potential Nits:

1. Requirements 3.1 and 3.2 indicate that a “strong level of certainty” is needed, but does not define what that means in context.  This may be common knowledge within the community, however. 

2. Requirement 3.13 indicates that BGPsec “MUST provide backward compatibility”, but we are left to assume that downgrade prevention is enabled.  We might assume that it is, but it’s probably better not to.  Perhaps adding a statement to the effect of “MUST provide backward compatibility…. but also allow for strict BGPsec adherence” or something similar.  I also recognize that there may be obviating circumstances behind this requirement (i.e. it’s not practical to *not* allow strict adherence), which I might also assume as a reader.

3. Requirement 3.18 uses the phrase “necessary degree of assurance” regarding validity of certain data, and I don’t know what that is really saying.  Is this really a statement of integrity and authenticity or something else?  What is the gradient of assurance and how do we know when we’ve reached that “necessary degree”?

4. In the Security Considerations section (6) it seems that more explanation pertaining to the following sentence might be warranted: “The data plane might not follow the control plane.”  This might be readily apparent to anyone in-the-know, but it’s not so apparent to those not-in-the-know.