Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20
Russ Housley <housley@vigilsec.com> Wed, 28 December 2016 17:49 UTC
Return-Path: <housley@vigilsec.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 B72C6129639 for <secdir@ietfa.amsl.com>; Wed, 28 Dec 2016 09:49:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bBDnW__sFHR for <secdir@ietfa.amsl.com>; Wed, 28 Dec 2016 09:49:04 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7411D129635 for <secdir@ietf.org>; Wed, 28 Dec 2016 09:49:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 336FB30040A for <secdir@ietf.org>; Wed, 28 Dec 2016 12:38:47 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fWjkj0wS-30g for <secdir@ietf.org>; Wed, 28 Dec 2016 12:38:44 -0500 (EST)
Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 50790300260; Wed, 28 Dec 2016 12:38:44 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <DM2PR09MB04468E344A052BFE55830D2D84680@DM2PR09MB0446.namprd09.prod.outlook.com>
Date: Wed, 28 Dec 2016 12:46:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A569C181-B91F-4883-9B7B-6069B87C405A@vigilsec.com>
References: <D915BDA3-A15D-4445-8C18-DA155A73E0D0@vigilsec.com> <DM2PR09MB04468E344A052BFE55830D2D84680@DM2PR09MB0446.namprd09.prod.outlook.com>
To: Sriram Kotikalapudi <kotikalapudi.sriram@nist.gov>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/x5gNIkwhVIUPlq99MBj2g23EzoE>
Cc: "draft-ietf-sidr-bgpsec-protocol.all@ietf.org" <draft-ietf-sidr-bgpsec-protocol.all@ietf.org>, IETF SecDir <secdir@ietf.org>
Subject: Re: [secdir] SecDir Review of draft-ietf-sidr-bgpsec-protocol-20
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 28 Dec 2016 17:49:06 -0000
Sriram: Thanks for your very comprehensive response to my review. I think it is ready to move forward, Russ On Dec 28, 2016, at 12:30 PM, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> wrote: > Russ, > > Thanks once again for your detailed review and very helpful comments. > The recently submitted version-21 of the draft incorporates changes to reflect > all your comments except two minor comments that have to do with packet format tweaks. > (Please see Oliver's response on the SIDR list about the latter.) > > Please see my specific responses inline below marked with [Sriram]. > Please let me know if there is anything that I have missed. > > Sriram > > > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com] > Sent: Thursday, December 08, 2016 11:26 AM > To: draft-ietf-sidr-bgpsec-protocol.all@ietf.org > Cc: IETF SecDir <secdir@ietf.org> > Subject: SecDir Review of draft-ietf-sidr-bgpsec-protocol-20 > > I 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 authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-sidr-bgpsec-protocol-20 > Reviewer: Russ Housley > Review Date: 2016-12-08 > IETF LC End Date: 2016-12-16 > IESG Telechat date: Unknown > > Summary: Almost Ready > > I also did a review for Gen-ART. This SecDir review is identical to that Gen-ART review. > > I was involved in the design of BGPsec, but I have not reviewed the document for a long time. > > > Question > > I do not see any guidance on the handling of private AS numbers. I'm not sure whether it belongs in the document or not. I am thinking about a BGP stub customer that employs a private AS. If I understand properly, that stub customer cannot publish a ROA for the private AS number and the prefixes that it uses. So, the stub customer cannot become a BGPsec speaker. So, my question is about the BGPsec speaker that receives an announcement from the stub customer. Does that BGPsec speaker strip the private AS and sign an announcement? Will their ROA that cover the prefixes used by the stub customer? > > [Sriram] There are new paragraphs added in the ops and mgmt. section (S 7) > to discuss proper handling of private ASNs that may be used for stub ASes > or inside confederations. > > > Major Concerns > > Section 2.2 says: > > ... A BGP speaker MAY > announce BGPsec capability only if it supports the BGP multiprotocol > extension [RFC4760]. ... > > This needs to be worded as a MUST NOT statement. > The current wording does not align with the definition of MAY in RFC 2119. > > [Sriram]: Done > > I think an additional consideration is needed in Section 6.2. This protocol design assumes a signer will compute a message digest and then digitally sign that digest. If someone wants to use a digital signature that works differently, there may be a significant change to this protocol. > > [Sriram]: Please refer to our earlier discussion in this thread on this topic. > I have left the section as is. > > It is very unusual for the IANA Considerations to contain a figure, and Figure 10 really seems out of place. The version number can be put in an IANA registry, but there really is no need until a second value is needed. There is no reason to put Dir in an IANA registry, there are only two values and both are fully specified in this document. The unassigned bits must be zero until a new version is specified. > > [Sriram] I have modified Figures 10 to make clear that the Dir values > are fully specified by the RFC-to-be. I have similarly added more clarity in Figure 11 also. > The IANA reviewer Sabrina Tanamal has used Figure 10 in her response. > Seems like she found it useful. So I am keeping it in the document for now. > In the IANA section (including Figs. 10 and 11), it is now clearly stated > that the unassigned bits must be set to zero. > > Minor Concerns > > I find the Abstract misses some important information. Also, the old wording suggests that the attribute contains a single digital signature. > I suggest: > > This document describes BGPsec, an extension to the Border Gateway > Protocol (BGP) that provides security for the path of autonomous > systems (ASes) through which a BGP update message passes. BGPsec is > implemented via an optional non-transitive BGP path attribute that > carries digital signatures produced by each autonomous system that > propagates the update message. The digital signatures provide > confidence that every AS on the path of ASes listed in the update > message has explicitly authorized the advertisement of the route. > > [Sriram] Thanks for providing the additional wording. The document now has > the modified version of the abstract that you've provided above. > > Section 2.1 says: > > ... The BGP speaker > sets this bit to 0 to indicate the capability to receive BGPsec > update messages. The BGP speaker sets this bit to 1 to indicate the > capability to send BGPsec update messages. > > It seems a bit wasteful to repeat the whole capability for each direction. Wouldn't it be better to follow the example used in other capability definitions (such as RFC 7911) by using one of the unassigned bits? The Send/Receive pair of bits would have these > semantics: > > This field indicates whether the sender is (a) able to receive > BGPsec update messages from its peer (value 1), (b) able to send > BGPsec update messages to its peer (value 2), or (c) both (value 3) > for the address family identified in the AFI. > > [Sriram]: I have followed your suggestion to put this out on the SIDR list for comments. > Please see Oliver's response on the SIDR list. Let us see if anyone else comments. > > For completeness, please add a paragraph to the end of Section 3.1 that describes the 4-octet AS Number field. Please state how an old 16-bit AS number is carried. > > [Sriram] Done. > > In Section 3.2, the Signature Length within the Signature Segment does not count the length field itself. It seems that all of the other length values in this specification count the size of the length too. > Consistency will avoid implementation errors. > > [Sriram] I have followed your suggestion to put this out on the SIDR list for Comments. > Please see Oliver's response on the SIDR list. Let us see if anyone else comments. > > Section 4.2 references the MP_REACH_NLRI attribute; please add a citation to the RFC that defines that attribute. > > > [Sriram] Done. RFC7460 added as citation. > > Nits > > Section 2.1 says: > > The second and third octets contain the 16-bit Address Family > Identifier (AFI) which indicates the address family for which the > BGPsec speaker is advertising support for BGPsec. This document only > specifies BGPsec for use with two address families, IPv4 and IPv6, > AFI values 1 and 2 respectively. BGPsec for use with other address > families may be specified in future documents. > > Please reference RFC 4760 for a place to learn about AFI. > > [Sriram] Done. > > In Section 4.1, the comma is in the wrong place, but when I tried to offer a correction, I thought that a slight rewording would also improve the clarity: > > OLD: > > If a BGPsec router has received only a non-BGPsec update message > (without the BGPsec_Path attribute), containing the AS_PATH > attribute, from a peer for a given prefix then it MUST NOT ... > > NEW: > > If a BGPsec router has received only a non-BGPsec update message > containing the AS_PATH attribute (instead of the BGPsec_Path > attribute) from a peer for a given prefix, then it MUST NOT ... > > [Sriram] Done. Thank you for providing the better wording for this. > > Please reword the first paragraph of Section 4.2 to avoid the phrase "said route advertisement". While it is not wrong, it does feel very awkward. This is not a patent claim. > > [Sriram] Done. Now the document avoids patent-like usage of "said". > > The acronym "ASN" is not used until Section 4.4, and it is not expanded there. I suggest that all uses of ASN should be expanded to AS number. > > [Sriram] Done. >
- [secdir] SecDir Review of draft-ietf-sidr-bgpsec-… Russ Housley
- Re: [secdir] SecDir Review of draft-ietf-sidr-bgp… Sriram, Kotikalapudi (Fed)
- Re: [secdir] SecDir Review of draft-ietf-sidr-bgp… Russ Housley
- Re: [secdir] SecDir Review of draft-ietf-sidr-bgp… Sriram, Kotikalapudi (Fed)
- Re: [secdir] SecDir Review of draft-ietf-sidr-bgp… Russ Housley