[secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06
Brian Weis <bew@cisco.com> Sat, 22 July 2017 10:21 UTC
Return-Path: <bew@cisco.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BB7131DF6; Sat, 22 Jul 2017 03:21:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Brian Weis <bew@cisco.com>
To: secdir@ietf.org
Cc: iesg@ietf.org, draft-ietf-idr-bgp-prefix-sid.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.57.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150071889993.20425.5273428383173596948@ietfa.amsl.com>
Date: Sat, 22 Jul 2017 03:21:39 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0If6B8IZbm1mT_q9eeMztRSDLIQ>
Subject: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 22 Jul 2017 10:21:40 -0000
Reviewer: Brian Weis Review result: Has Nits 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. This document describes a BGP extension to signal the BGP Prefix-SID use with Segment Routing. as well as the rules to originate, receive and handle error conditions. The BGP extension defines a new type of BGP path attribute passed within BGP, and does not change the security considerations of the BGP protocol itself. I consider this document “ready with nits”. The Security Considerations section reasonably states that the use of this BGP attribute “inherits the security considerations” of the BGP-4 RFC as well as the RFC defining how labels are carried in BGP-4. As an aside, those documents are quite old. For example, RFC 4271 says that the TCP-MD5 option is required to implement for authentication, but this has been replaced by a much stronger authentication method (TCP-AO). It would be nice if we had newer security considerations for BGP-4 but that advice doesn’t belong in this document. The Security Considerations might have said something about the how an AS would protect itself against a peer sending the Prefix-SID attribute across AS boundaries, but that text is contained in useful places elsewhere in the document and seems sufficient. I have only one nit, which is some confusion regarding scoping of the SID. The document clearly states that a SID has a limited scope within the network, which is important because outside of that scope an SID value would have a different meaning. This is a security consideration, because accepting a SID in the wrong scope could possibly cause a security issue if packets are forwarded to the wrong identity (e.g, the packets were intended for a firewall within the AS, not a service outside of the AS). (a) Section 5.1 says it should not be advertised outside of an AS unless “explicitly configured to do so”. It would be nice if the conditions for explicitly configuring the SID to be advertised outside of the AS were mentioned here. (b) The last paragraph of Section 8 says it is applicable within an SR Domain (i.e., more than an AS), and Security Considerations says something similar. (c) Security Considerations speaks of limiting BGP Prefix-SID within a “domain”. Is that intending to say an “SR domain”? I suspect whether an SID should be advertised outside of the AS depends on whether an AS is part of an “SR domain” or not, and that there's likely never a good case to advertise it outside of an AS unless it is part of an "SR domain". But it would be good if there was some text clarifying the conditions when it is reasonable to share an SID between ASes.
- [secdir] Secdir early review of draft-ietf-idr-bg… Brian Weis
- Re: [secdir] Secdir early review of draft-ietf-id… stefano previdi
- Re: [secdir] Secdir early review of draft-ietf-id… Brian Weis (bew)
- Re: [secdir] Secdir early review of draft-ietf-id… John G. Scudder
- Re: [secdir] Secdir early review of draft-ietf-id… Brian Weis (bew)
- Re: [secdir] Secdir early review of draft-ietf-id… Arjun Sreekantiah (asreekan)
- Re: [secdir] Secdir early review of draft-ietf-id… Arjun Sreekantiah (asreekan)