BGP Experiment

Job Snijders job at ntt.net
Tue Jan 8 17:16:03 UTC 2019


OOn Tue, Jan 8, 2019 at 19:59 Tom Ammon <thomasammon at gmail.com> wrote:

> On Tue, Jan 8, 2019, 11:50 AM <niels=nanog at bakker.net wrote:
>
>> * cunha at dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]:
>> >[A] https://goo.gl/nJhmx1
>>
>> For the archives, since goo.gl will cease to exist soon, this links to
>>
>> https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview
>>
>> After seeing this initial result I'm wondering why the researchers
>> couldn't set up their own sandbox first before breaking code on the
>> internet.  I believe FRR is a free download and comes with GNU autoconf.
>>
>
> There are a fair number of open source BGP implementations now. It would
> require additional effort to test all of them.
>


Not just every implementation, but also every version, and every
configuration permutation. This type of black box testing is not scalable.
It is not feasible work, nor the job of these researchers. It’s the job of
the software the developer to ensure the product is standards compliant.

In the case of FRR:

- improper use of the 0xFF codepoint
- FRR is not compliant with RFC 7606 (the devs indicated they will be
working on this)

Ultimately, the developers are responsible for their product, not random
other internet users. This situation was avoidable if standards had been
followed.

I’m happy the FRR developers quickly identified the issue and published a
fix. We can now all move on.

Kind regards,

Job

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190108/93eeacc9/attachment.html>


More information about the NANOG mailing list