BGP Experiment

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
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 <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.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
> >
> > --
> > 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.
> >