Subject: [secdir] Secdir early review of draft-ietf-idr-bgp-prefix-sid-06

From: Brian Weis <[email-masked]>
Date: Sat, 22 Jul 2017 03:21:39 -0700

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.

---

From: stefano previdi <[email-masked]>
Date: Wed, 26 Jul 2017 15:18:40 +0200

Hi Brian,

thanks for the review. Some comments here below.

> On Jul 22, 2017, at 12:21 PM, Brian Weis <[email-masked]> wrote:
> 
> Reviewer: Brian Weis
> Review result: Has Nits
> 

usually we don’t define these condition because they are related to each individual operator policy. What we want to be sure of is that any compliant implementation, by default, will not propagate the attribute outside the AS.

Under which conditions propagation is allowed is a local matter of the operator and how it is effectively achieved is a matter of local implementation.

> “domain”. Is that intending to say an “SR domain”?

More generally, by domain we intend the set of AS under control of the same organization/operator.

> is reasonable to share an SID between ASes.

Well, I’m not sure that would be a good idea because the conditions may vary over time and we will never be exhaustive anyway.

Thanks.
s.