<div dir="ltr"><div>I would be very interested in hearing Ben's definition of something that is "massive", if announcing or withdrawing a single /24 from the global routing table constitutes, quote, "a massive prefix spike/flap".</div><div><br></div><div>Individual /24s are moved around all the time by fully automated systems.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 23, 2019 at 9:42 AM Job Snijders <<a href="mailto:job@ntt.net">job@ntt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Ben, all,<br>
<br>
I'm not sure this experiment should be canceled. On the public Internet<br>
we MUST assume BGP speakers are compliant with the BGP-4 protocol.<br>
Broken BGP-4 speakers are what they are: broken. They must be fixed, or<br>
the operator must accept the consequences.<br>
<br>
"Get a sandbox like every other researcher" is not a fair statement, one<br>
can also posit "Get a compliant BGP-4 implementation like every other<br>
network operator".<br>
<br>
When bad guys explicitly seek to target these Asian and Australian<br>
operators you reference (who apparently have not upgraded to the vendor<br>
recommended release), using *valid* BGP updates, will a politely emailed<br>
request help resolve the situation? Of course not!<br>
<br>
Stopping the experiment is only treating symptoms, the root cause must<br>
be addressed: broken software.<br>
<br>
Kind regards,<br>
<br>
Job<br>
<br>
On Wed, Jan 23, 2019 at 12:19:09PM -0500, Italo Cunha wrote:<br>
> Ben, NANOG,<br>
> <br>
> We have canceled this experiment permanently.<br>
> <br>
> On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper <<a href="mailto:ben@packet.gg" target="_blank">ben@packet.gg</a>> wrote:<br>
> <br>
> > Can you stop this?<br>
> ><br>
> > You caused again a massive prefix spike/flap, and as the internet is not<br>
> > centered around NA (shock horror!) a number of operators in Asia and<br>
> > Australia go effected by your “expirment” and had no idea what was<br>
> > happening or why.<br>
> ><br>
> > Get a sandbox like every other researcher, as of now we have black holed<br>
> > and filtered your whole ASN, and have reccomended others do the same.<br>
> ><br>
> > On Wed, 23 Jan 2019 at 1:19 am, Italo Cunha <<a href="mailto:cunha@dcc.ufmg.br" target="_blank">cunha@dcc.ufmg.br</a>> wrote:<br>
> ><br>
> >> NANOG,<br>
> >><br>
> >> This is a reminder that this experiment will resume tomorrow<br>
> >> (Wednesday, Jan. 23rd). We will announce <a href="http://184.164.224.0/24" rel="noreferrer" target="_blank">184.164.224.0/24</a> carrying a<br>
> >> BGP attribute of type 0xff (reserved for development) between 14:00<br>
> >> and 14:15 GMT.<br>
> >><br>
> >> On Tue, Dec 18, 2018 at 10:05 AM Italo Cunha <<a href="mailto:cunha@dcc.ufmg.br" target="_blank">cunha@dcc.ufmg.br</a>> wrote:<br>
> >> ><br>
> >> > NANOG,<br>
> >> ><br>
> >> > We would like to inform you of an experiment to evaluate alternatives<br>
> >> > for speeding up adoption of BGP route origin validation (research<br>
> >> > paper with details [A]).<br>
> >> ><br>
> >> > Our plan is to announce prefix <a href="http://184.164.224.0/24" rel="noreferrer" target="_blank">184.164.224.0/24</a> with a valid<br>
> >> > standards-compliant unassigned BGP attribute from routers operated by<br>
> >> > the PEERING testbed [B, C]. The attribute will have flags 0xe0<br>
> >> > (optional transitive [rfc4271, S4.3]), type 0xff (reserved for<br>
> >> > development), and size 0x20 (256bits).<br>
> >> ><br>
> >> > Our collaborators recently ran an equivalent experiment with no<br>
> >> > complaints or known issues [A], and so we do not anticipate any<br>
> >> > arising. Back in 2010, an experiment using unassigned attributes by<br>
> >> > RIPE and Duke University caused disruption in Internet routing due to<br>
> >> > a bug in Cisco routers [D, CVE-2010-3035]. Since then, this and other<br>
> >> > similar bugs have been patched [e.g., CVE-2013-6051], and new BGP<br>
> >> > attributes have been assigned (BGPsec-path) and adopted (large<br>
> >> > communities). We have successfully tested propagation of the<br>
> >> > announcements on Cisco IOS-based routers running versions 12.2(33)SRA<br>
> >> > and 15.3(1)S, Quagga 0.99.23.1 and 1.1.1, as well as BIRD 1.4.5 and<br>
> >> > 1.6.3.<br>
> >> ><br>
> >> > We plan to announce <a href="http://184.164.224.0/24" rel="noreferrer" target="_blank">184.164.224.0/24</a> from 8 PEERING locations for a<br>
> >> > predefined period of 15 minutes starting 14:30 GMT, from Monday to<br>
> >> > Thursday, between the 7th and 22nd of January, 2019 (full schedule and<br>
> >> > locations [E]). We will stop the experiment immediately in case any<br>
> >> > issues arise.<br>
> >> ><br>
> >> > Although we do not expect the experiment to cause disruption, we<br>
> >> > welcome feedback on its safety and especially on how to make it safer.<br>
> >> > We can be reached at <a href="mailto:disco-experiment@googlegroups.com" target="_blank">disco-experiment@googlegroups.com</a>.<br>
> >> ><br>
> >> > Amir Herzberg, University of Connecticut<br>
> >> > Ethan Katz-Bassett, Columbia University<br>
> >> > Haya Shulman, Fraunhofer SIT<br>
> >> > Ítalo Cunha, Universidade Federal de Minas Gerais<br>
> >> > Michael Schapira, Hebrew University of Jerusalem<br>
> >> > Tomas Hlavacek, Fraunhofer SIT<br>
> >> > Yossi Gilad, MIT<br>
> >> ><br>
> >> > [A] <a href="https://conferences.sigcomm.org/hotnets/2018/program.html" rel="noreferrer" target="_blank">https://conferences.sigcomm.org/hotnets/2018/program.html</a><br>
> >> > [B] <a href="http://peering.usc.edu" rel="noreferrer" target="_blank">http://peering.usc.edu</a><br>
> >> > [C] <a href="https://goo.gl/AFR1Cn" rel="noreferrer" target="_blank">https://goo.gl/AFR1Cn</a><br>
> >> > [D]<br>
> >> <a href="https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment" rel="noreferrer" target="_blank">https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment</a><br>
> >> > [E] <a href="https://goo.gl/nJhmx1" rel="noreferrer" target="_blank">https://goo.gl/nJhmx1</a><br>
> >><br>
> > --<br>
> > Ben Cooper<br>
> > Chief Executive Officer<br>
> > PacketGG - Multicast<br>
> > M(Telstra): 0410 411 301<br>
> > M(Optus):  0434 336 743<br>
> > E: <a href="mailto:ben@packet.gg" target="_blank">ben@packet.gg</a> & <a href="mailto:ben@multicast.net.au" target="_blank">ben@multicast.net.au</a><br>
> > W: <a href="https://packet.gg" rel="noreferrer" target="_blank">https://packet.gg</a><br>
> > W: <a href="https://multicast.net.au" rel="noreferrer" target="_blank">https://multicast.net.au</a><br>
> ><br>
> > --<br>
> > You received this message because you are subscribed to the Google Groups<br>
> > "DISCO Experiment" group.<br>
> > To unsubscribe from this group and stop receiving emails from it, send an<br>
> > email to <a href="mailto:disco-experiment%2Bunsubscribe@googlegroups.com" target="_blank">disco-experiment+unsubscribe@googlegroups.com</a>.<br>
> > To post to this group, send email to <a href="mailto:disco-experiment@googlegroups.com" target="_blank">disco-experiment@googlegroups.com</a>.<br>
> > To view this discussion on the web visit<br>
> > <a href="https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com" rel="noreferrer" target="_blank">https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com</a><br>
> > <<a href="https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com?utm_medium=email&utm_source=footer" rel="noreferrer" target="_blank">https://groups.google.com/d/msgid/disco-experiment/CAPZQKs8aVT%3D7gJdGcoC-KOPDR0F4Ms33KAKKG5-4k96SVCSFEw%40mail.gmail.com?utm_medium=email&utm_source=footer</a>><br>
> > .<br>
> > For more options, visit <a href="https://groups.google.com/d/optout" rel="noreferrer" target="_blank">https://groups.google.com/d/optout</a>.<br>
> ><br>
</blockquote></div>