Re: [secdir] Secdir review of draft-ietf-idr-ix-bgp-route-server-10

Nick Hilliard <nick@foobar.org> Fri, 10 June 2016 22:36 UTC

Return-Path: <nick@foobar.org>
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 5538012D9AE; Fri, 10 Jun 2016 15:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 IcACrCPqOgEl; Fri, 10 Jun 2016 15:36:01 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243FD12D575; Fri, 10 Jun 2016 15:36:00 -0700 (PDT)
X-Envelope-To: draft-ietf-idr-ix-bgp-route-server.all@ietf.org
Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u5AMZwHH008396 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jun 2016 23:35:58 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local
Message-ID: <575B40CD.2030404@foobar.org>
Date: Fri, 10 Jun 2016 23:35:57 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "Waltermire, David A. (Fed)" <david.waltermire@nist.gov>
References: <DM2PR09MB0365563370AB330550517C50F05C0@DM2PR09MB0365.namprd09.prod.outlook.com>
In-Reply-To: <DM2PR09MB0365563370AB330550517C50F05C0@DM2PR09MB0365.namprd09.prod.outlook.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KGu5LjmyhXXUYDAgRqp-nwdh4XQ>
Cc: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-idr-ix-bgp-route-server.all@ietf.org" <draft-ietf-idr-ix-bgp-route-server.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-idr-ix-bgp-route-server-10
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: Fri, 10 Jun 2016 22:36:04 -0000

Hi Dave,

thank you for your review.

Waltermire, David A. (Fed) wrote:
> The following is a minor nit on the organization of the text:
> 
> In general the security considerations section covers the issues
> fairly well. In the first paragraph, the last sentence suggests that
> steps should be taken to address path hiding, but the text does not
> point to the text in section 2.3.2 on this topic. One way to improve
> this consideration would be to move the text in 2.3.3 to the end of
> this paragraph. Section 2.3.3 is adjacent to the security
> consideration section, so I don't see this as a significant change.

I see what you're saying here, but we wanted to have a specific
recommendations section in the main body of the draft.  The security
considerations section is clear about what needs to be done and the
reference is given a couple of lines previously.  We've also added some
more text to the Implementation Suggestions section (after a suggestion
from Alvaro), so in the current version, it would probably look a bit
peculiar to move the path hiding recommendation into the security
considerations section.

> Some (potentially) minor issues:
> 
> A number of the requirements in section 2.2 and the subsections
> define requirements that differ and often conflict with requirements
> in RFC 4271. It would be good to indicate this at the start of 2.2.

yes, good point. [commit #8c113b3]

> Should this relationship also be called out in the abstract?

Mmm, it's already in the introduction and now in section 2.0.  Having it
in three places would be repetitive.

> I am not an expert in BGP security, so please consider this issue in
> that context:
> 
> The statement at the end of the security considerations section
> points the reader to RFC7454. I was left wondering if this draft
> changes any of considerations in RFC7454. It would be beneficial if
> some text was added to this draft speaking to this point. Again not
> being an expert in BGP security, I am not certain what the new text
> should say on this matter.

The short answer is that it mostly doesn't.

The longer answer is that this ID is a draft about RS implementations
rather than RS operations.  There is a parallel draft
(ietf-grow-ix-bgp-route-server-operations), where this reference and
comment are more appropriate instead.  RFC7454 didn't make it into the
-operations draft because it was published after the last update was
done.  I've just made a note to add this into the operations draft
during AUTH48, along with a side note to say that care needs to be taken
with section 11 of RFC7454.

I've just posted draft -11.  Can you check if this deals with your comments?

Nick