Re: [secdir] SecDir review of draft-ietf-rtgwg-bgp-routing-large-dc-10

Jon Mitchell <> Fri, 06 May 2016 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67B1C12D0A6; Thu, 5 May 2016 21:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, 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 Mckm49n6XCic; Thu, 5 May 2016 21:57:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1CCF512B04E; Thu, 5 May 2016 21:57:21 -0700 (PDT)
Received: by (Postfix, from userid 507) id 786A3540B7D; Fri, 6 May 2016 00:57:20 -0400 (EDT)
Date: Fri, 06 May 2016 00:57:20 -0400
From: Jon Mitchell <>
To: Yoav Nir <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <>
Cc:, The IESG <>, secdir <>
Subject: Re: [secdir] SecDir review of draft-ietf-rtgwg-bgp-routing-large-dc-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, 06 May 2016 04:57:23 -0000

On 05/05/16 10:24 +0300, Yoav Nir wrote:

> The document does not deal with security questions such as what kind of damage a rogue node can do, and that is fine. That is not the subject of this document. 

Ack, and agreed.

> My one issue is with the Security Considerations section. Section 9 defers to the BGP RFCs (4271 and 4272) for the security considerations. This is a common pattern and it's usually fine, but in this case it is missing something. RFC 4271 requires the use of TCP-MD5 (RFC 2385) for authenticating the BGP connections between routers. RFC 4271 also mentions (but does not solve) the problem of key management. ISTM that in a large-scale and dynamically scalable data center, the problem of key management should be addressed. It might also be nice to use something less antiquated than TCP-MD5. 

Since this a document describing what is possible to do in a real
design, I will try to avoid talking about something less antiquated than
TCP-MD5 since such things do not exist widely in implementations.  :-)

> Now it's possible to decide that all elements within the data center are trusted and under the administrator's control, and that therefore no authentication is necessary as long as BGP is somehow blocked from outside the DC to internal nodes. But if these assumptions exist, I believe they should be stated.

Agreed and this is the reality of the matter.  We will update the
section to mention that MD5 may not be practical given key management
issues and that perimeter controls (ACLs) may be a more feasible option
in the design.  Expect a revision shortly (may wait a bit for AD/other
directorate feedback).