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