BGP Experiment

Sat Jan 26 21:16:46 UTC 2019

Randy Bush wrote on 26/01/2019 16:15:
> if you know of an out-of-spec vulnerability or bug in deployed router,
> switch, server, ... ops and researchers should exploit it as much as
> possible in order to encourage fixing of the hole.

It came out as "please continue", but the sentiment sounded less like 
malice / ignorance, and more like a lack of sympathy for people who 
leave equipment connected to the dfz which shouldn't be connected to the 
dfz.

> given the number of bugs/vulns, are you comfortable that this is going
> to scale well?  and this is prudent when our primary responsibility is a
> running internet?

This isn't the first time that a malformed IANA BGP attribute 
implementation caused service loss, and it's unlikely to be the last 
time either.

https://sempf.net/post/On-Testing1

Some time in the future, it will be acceptable to continue the DISCO 
experiment along its current lines because bgp stack authors will 
remember the time that attribute 255 caused things to explode and their 
code bases will be resilient to this problem.

When this happens, will it be acceptable to announce prefixes with 
arbitrary unassigned attributes with random contents?  Where does the 
boundary lie between what is and what is not acceptable?  Do we assign a 
time limit after which it's considered generally acceptable to announce 
attributes or capabilities which are known to cause problems?  If 
someone were to set up a beacon system which announced prefixes with 
unassigned attributes and garbage content, is that a useful community 
service or simply a nuisance?

The research people acted correctly in stopping the experiment. They 
could engage with the IETF IDR working group to get a temporary 
attribute code point rather than using 255, and it would be interesting 
to see results from this.

But I'm not convinced that it's feasible for the internet community to 
assert that any particular machination of bgp announcement is out of 
bounds in perpetuity - in the longer term, this will promote systemic 
infrastructural weakness rather than doing what we all aspire to, namely 
creating a more resilient internet.

Nick