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

["Brian Weis (bew)" <[e-mail]>]

Hi Stefano,

Thanks for your notes below, which make sense to me. I don’t have any more comments. 

Brian

> On Jul 26, 2017, at 6:18 AM, stefano previdi <[e-mail]> wrote:
> 
> Hi Brian,
> 
> thanks for the review. Some comments here below.
> 
> 
>> On Jul 22, 2017, at 12:21 PM, Brian Weis <[e-mail]> wrote:
>> 
>> 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.
> 
> 
> 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.
> 
> 
>> (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”?
> 
> 
> More generally, by domain we intend the set of AS under control of the same organization/operator.
> 
>> 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.
> 
> 
> 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.
> 
> 
>> 
> 

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: [phone]
Email: [e-mail]