Re: [Idr] [ I-D Action: draft-haas-idr-extended-experimental-00.txt]

Jeffrey Haas <> Tue, 01 November 2016 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E989129508 for <>; Tue, 1 Nov 2016 10:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.913
X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FAKE_REPLY_C=1.486, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w3E_r8xqYoEK for <>; Tue, 1 Nov 2016 10:31:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CF76C1294AD for <>; Tue, 1 Nov 2016 10:31:43 -0700 (PDT)
Received: by (Postfix, from userid 1001) id E5B121E337; Tue, 1 Nov 2016 13:34:14 -0400 (EDT)
Date: Tue, 1 Nov 2016 13:34:14 -0400
From: Jeffrey Haas <>
To: Peter Hessler <>, Jared Mauch <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <> <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] [ I-D Action: draft-haas-idr-extended-experimental-00.txt]
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Nov 2016 17:31:45 -0000

On Tue, Nov 01, 2016 at 06:04:14PM +0100, Peter Hessler wrote:
> if adopted by the WG, I'd be interested in tightening it up a bit more
> but that can be handled then.

On Tue, Nov 01, 2016 at 01:10:59PM -0400, Jared Mauch wrote:
> I’m for adopting this draft as well.
> I would like to clean up the security text, as there is a lot of history behind the section 6 text:

Feel free to suggest patches:

> 6.  Security Considerations
>    This document does not introduce any new security considerations into
>    the BGP-4 protocol.  While the injection of unknown or badly
>    formatted Optional-Transitive Path Attributes has been and remains an
>    issue impacting the stability of the Internet, this proposal doesn't
>    increase exposure to that issue.  It is rather expected that this
>    proposal helps remediate the accidental attack surface that
>    incremental BGP protocol work exposes to the Internet at large.
>  - snip -
> I believe it should acknowledge that in the pre-7606 world the handling
> was as defined but subsequently considered harmful and with 7606 covers
> the risks from this document.  Simply put, striking the text after the first
> paragraph and saying the handling in 7606 covers the risk SHOULD be
> sufficient.

Time constraints aside, I thought a bit about this as I was scribbling up a
quick security section.  I think it might make sense to do some level of
brief overview of the issues RFC 7606 addressed in prior sections as part of
the motivation of why we need a bit better sandboxing of early work.
Section 1 covers this to some extent.  However, I'm not sure it belongs in
the considerations for this document.

-- Jeff