BGP Experiment

Wed Jan 23 17:00:27 UTC 2019

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 <cunha at 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 <cunha at 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-experiment at 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: ben at packet.gg & ben at multicast.net.au
W: https://packet.gg
W: https://multicast.net.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190124/39533092/attachment.html>