Subject: [Idr] Warren Kumari's Discuss on draft-ietf-idr-bgp-prefix-sid-13: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Wed, 07 Feb 2018 07:43:10 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-idr-bgp-prefix-sid-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I had the same logging question an Alexey and guessed (perhaps incorrectly)
that this was to try and prevent DoSing the logging infrastructure by sending
too many log messages. If this is the reason, I think that it should be better
spelled out -- and if this is *not* the reason, I think that there needs to be
a good explanation. Note that I will happy clear as soon as someone says "Yeah,
we've heard and will deal with this" -- I think that this is a fine document
and that addressing this issue should be a minor change, but important enough
for operational reasons that it needs to be discussed.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Major(ish) issue:
Section 5.  Advertising BGP Prefix-SID Attribute
   "The BGP Prefix-SID attribute MAY be attached to labeled BGP prefixes
   (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
   order to prevent distribution of the BGP Prefix-SID attribute beyond
   its intended scope of applicability, attribute filtering SHOULD be
   deployed."
Thank you for including this -- however, as I'm sure you know, the state of BGP
filtering in the wild is, er, poor. Can you please provide some additional
guidance? For example, could you include an appendix with examples? Or simply a
bit more text on determining the scope of applicability? Apologies if I missed
this, but should this by default be filtered on eBGP sessions? The included
text is a great start, but some more (so people don't miss it and shoot
themselves in the foot would be much appreciated.

Nits:
Section 1:
" the SID consists of a label while when SR is applied to the IPv6 dataplane
the SID consists of an IPv6 address." I think that "of a label, while" would
make this much more readable. It took me a few tries without it.

Section 4:
" A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP
   neighbor residing outside the boundaries of the SR domain, MUST
   discard the attribute unless it is configured to accept the attribute
   from the EBGP neighbor."
Spurious comma between domain and MUST (yeah, I want a comma above, I don't
want one here, no pleasing some people. They are nits :-))

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 7 Feb 2018 22:22:29 +0000

Hi Warren, 

On 2/7/18, 10:43 AM, "Warren Kumari" <[email-masked]> wrote:

    

I've added this to the "Security Considerations". This is so common, there probably should be boilerplate text for it. 

+    To prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service
+    (DDoS) attack due to excessive BGP updates with an unacceptable BGP
+    Prefix-SID attribute, message rate-limiting as well as suppression of
+    duplicate messages SHOULD be deployed.
+

    
    Major(ish) issue:

You realize that local BGP policy has been traditionally not been standardized and there have been books written on the subject. Also, we have a whole WG, i.e., GROW to take on topics such as these. I have made the statement more explicit.

     (IPv4/IPv6) [RFC8277] or to IPv6 unicast prefixes [RFC4760].  In
     order to prevent distribution of the BGP Prefix-SID attribute beyond
     its intended scope of applicability, attribute filtering SHOULD be
!    deployed to remove the BGP Prefix-SID attribute at the adminstrative
!    boundary of the segment routing domain.

    Nits:
    Section 1:
    
    Section 4:

I agree with both and have made the changes. I was not the original editor of this document. 

Thanks,
Acee

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Feb 2018 17:36:42 -0500

>     https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-prefix-sid/

Thank you.
I agree, this is a really common issue / point, some sort of bcp for
designing logging in protocols that we could reference would be
awesome.

I've cleared my DISCUSS, thanks for addressing it so quickly.

> You realize that local BGP policy has been traditionally not been standardized and there have been books written on the subject.
>  Also, we have a whole WG, i.e., GROW to take on topics such as these.

Yup, I think that you are making my point for me :-P - having
additional guidance from the people building to protocol can't hurt.

>  I have made the statement more explicit.
>

Thank you. I was hoping for even more (so that we can point at people
and knock their heads together when they leak) but this was only a
comment -- thanks for addressing it, I'm fine with your response.

> I agree with both and have made the changes. I was not the original editor of this document.

Thanks,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf