Or you could simply fix your gear rather than leaving a big hole in your infrastructure.
*shrug* On Thu, Jan 24, 2019, 7:25 AM 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 > >
