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