BGP Path Attribute Filtering, YES or NO?

Wed Jan 8 14:59:10 UTC 2020

> From: Saku Ytti <saku at ytti.fi>
> Sent: Wednesday, January 8, 2020 1:09 PM
> 
> On Wed, 8 Jan 2020 at 14:46, <adamv0025 at netconsultings.com> wrote:
> 
> > Other  might be: “These experimental work is of great value to the
> community and there’s a process now to announce and manage these
> experiments, what about net neutrality, and besides modern BGP
> implementations should handle well formatted attributes and if it’s not the
> case its good that these flaws are being exposed and fixed.”
> 
> This is my position. Unfortunately it's a pipe dream, as you only need very
> few to think filtering is needed to ruin the utility.
> 
In an ideal world that would be my position too, but I suppose it depends on the context,  
Imagine: 
CTO: Could you have prevented this major financial and market loss and damage to our reputation resulting from this major network outage, is this something that never happened before and couldn't be foreseen?
Me: Nah happened already and sure I could have simply dropped the offending BGP attribute 254 in this case since it's not used anyways.
CTO: What the ..., why haven’t you do so then?!?!?
Me: Well because "this experimental work is of great value to the community and there’s a process now to announce and manage these experiments, what about net neutrality, and besides modern BGP implementations should handle well formatted attributes and if it’s not the case it's good that these flaws are being exposed and fixed".
CTO: You mean exposed like this? Like breaking my network?!?!? Get the ... out of here you're fired!!!!

  

> Some specific examples
> 
> - don't clean up communities which don't belong to you (
Agreed, whatever you do only condition communities with your AS# on them.  

> - don't clean up TOS byte (I may want to communicate QoS over internet
> between my islands)
Agreed, will dump it all into best-effort or scavenger class in my MPLS backbone anyways, along with all the SD-WAN super high priority stuff...
Falls into do not touch transit traffic unless under DoS.

> - don't clean up BGP attributes (128 would have utility if it transit, but due to
> old issues, it often does not)
Looking at https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml (don't know how well maintained it is actually), I see 128 as assigned to ATTR_SET [RFC6368], so if I filtered only Unassigned, Deprecated and Reserved from that list that shouldn't do any harm right?

> - don't drop ICMP (ICMP TS would be high utility if not filtered)
So obvious that you shouldn't even mention it, but again falls into do not touch transit traffic unless under DoS,
Traffic (ICMP included) destined to your infrastructure -well that's subject to the iACL policies.  

> I think we need specific good reason to mangle/filter and if you cannot come
> up with one, don't do it. If you can come up with one, consider if it's
> persistent or workaround to deal with specific active defect.
> 
Well the BGP attribute induced outage has a precedence and had quite a positive fallout in terms of BGP enhanced error handling etc...
My pipedream is to have the time to shoot random stuff at BGP to see what happens and then report back to vendors about my findings,...
But no, this is not part of our software certification test suite.

adam