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

Nick Hilliard <> Fri, 10 June 2016 22:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5538012D9AE; Fri, 10 Jun 2016 15:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IcACrCPqOgEl; Fri, 10 Jun 2016 15:36:01 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 243FD12D575; Fri, 10 Jun 2016 15:36:00 -0700 (PDT)
Received: from cupcake.local ( [] (may be forged)) (authenticated bits=0) by (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
X-Authentication-Warning: Host [] (may be forged) claimed to be cupcake.local
Message-ID: <>
Date: Fri, 10 Jun 2016 23:35:57 +0100
From: Nick Hilliard <>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: "Waltermire, David A. (Fed)" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-idr-ix-bgp-route-server-10
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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?