[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.