job at ntt.net
Wed Jan 23 17:40:52 UTC 2019
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
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.
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 <ben at 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 <cunha at dcc.ufmg.br> wrote:
> >> NANOG,
> >> This is a reminder that this experiment will resume tomorrow
> >> (Wednesday, Jan. 23rd). We will announce 184.108.40.206/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 220.127.116.11/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 18.104.22.168/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
> > --
> > 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+unsubscribe at googlegroups.com.
> > To post to this group, send email to disco-experiment at 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.
More information about the NANOG