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
