[secdir] secdir review of draft-ietf-bess-fat-pw-bgp-03

"Scott G. Kelly" <scott@hyperthought.com> Fri, 16 February 2018 14:06 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A501E12D87F for <secdir@ietfa.amsl.com>; Fri, 16 Feb 2018 06:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3cLdYkc8GPp6 for <secdir@ietfa.amsl.com>; Fri, 16 Feb 2018 06:06:31 -0800 (PST)
Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2464812D86B for <secdir@ietf.org>; Fri, 16 Feb 2018 06:06:31 -0800 (PST)
Received: from smtp9.relay.iad3a.emailsrvr.com (localhost []) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 61A2457D0; Fri, 16 Feb 2018 09:06:26 -0500 (EST)
Received: from app29.wa-webapps.iad3a (relay-webapps.rsapps.net []) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 536A85608; Fri, 16 Feb 2018 09:06:26 -0500 (EST)
X-Sender-Id: scott@hyperthought.com
Received: from app29.wa-webapps.iad3a (relay-webapps.rsapps.net []) by (trex/5.7.12); Fri, 16 Feb 2018 09:06:26 -0500
Received: from hyperthought.com (localhost.localdomain []) by app29.wa-webapps.iad3a (Postfix) with ESMTP id 441466098C; Fri, 16 Feb 2018 09:06:26 -0500 (EST)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Fri, 16 Feb 2018 06:06:26 -0800 (PST)
X-Auth-ID: scott@hyperthought.com
Date: Fri, 16 Feb 2018 06:06:26 -0800 (PST)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-bess-fat-pw-bgp-all@ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1518789986.277131687@apps.rackspace.com>
X-Mailer: webmail/12.11.1-RC
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Ub-iZHY-iaY1bBZmF4HLtgaKpEg>
Subject: [secdir] secdir review of draft-ietf-bess-fat-pw-bgp-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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, 16 Feb 2018 14:06:33 -0000

I have 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 editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is Ready with issues.

From the last line of the abstract, this draft updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.

I'm not expert in routing protocols, so I can't say for sure that the one minor issue I'm calling out is the only one. The security considerations section is very brief, saying only

   This extension to BGP does not change the underlying security issues
   inherent in the existing [RFC4271].

RFC4271 is the BGP4 RFC. I agree that those security considerations apply, but as noted in the abstract, this draft updates RFC4761, and since that document calls out additional security considerations, don't those also apply here? Shouldn't this document's security considerations also reference RFC4761?