> From: Randy Bush
> Sent: Thursday, January 31, 2019 6:56 PM
>
> > I suspect simple bugs are found by vendor, complex bugs are not
> > economic to find.
>
> the running internet is complex and has a horrifying number of special
cases
> compounded by kiddies being clever. no one, independent
> I suspect simple bugs are found by vendor, complex bugs are not
> economic to find.
the running internet is complex and has a horrifying number of special
cases compounded by kiddies being clever. no one, independent of
resource requirements, could build a lab to the scale needed to test.
and
Hey,
> This is because you did your due diligence during the testing.
> Do you have statistics on the probability of these "complex" bugs occurrence?
No. I wish I had and I hope to make change on this. Try to translate
how good investment test is, how many customer outages it has saved
etc.
I
> From: Saku Ytti
> Sent: Friday, January 25, 2019 7:59 AM
>
> On Thu, 24 Jan 2019 at 18:43, wrote:
>
> > We fight with that all the time,
> > I'd say that from the whole Design->Certify->Deploy->Verify->Monitor
> service lifecycle time budget, the service certification testing is almost
>
On 23/01/2019 19:40, Job Snijders wrote:
I agree with Job. Continue the experiment and warn us in advance.
-Hank
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
On Sun, Jan 27, 2019 at 01:21:56PM -0500, William Allen Simpson wrote:
> On 1/26/19 6:37 PM, Randy Bush wrote:
> > to nick's point. as nick knows, i am a naggumite; one of my few
> > disagreements with dr postel. but there is a difference between
> > writing protocol specs/code, and with sending
William Allen Simpson wrote on 27/01/2019 18:21:
OK, Randy, you peaked my interest: what is a naggumite?
http://naggum.no/worse-is-better.html
a.k.a. "perfect is the enemy of good enough".
Nick
> OK, Randy, you peaked my interest: what is a naggumite?
erik naggum, an early and strong proponent of being strict. you've been
around long enough you should remember erik.
> Many of us disagreed with Jon Postel from time to time, but he usually
> understood the alternative points of view.
On 27/01/2019 19:21, William Allen Simpson wrote:
> OK, Randy, you peaked my interest: what is a naggumite?
... (scouring the internet)
o
https://www.nanog.org/mailinglist/mailarchives/old_archive/2006-01/msg00250.html
o https://en.wikipedia.org/wiki/Erik_Naggum
o
On 1/26/19 6:37 PM, Randy Bush wrote:
to nick's point. as nick knows, i am a naggumite; one of my few
disagreements with dr postel. but there is a difference between
writing protocol specs/code, and with sending packets on the global
internet. rigor in the former, prudence in the latter.
> As we've discovered after many such events, the overlap between the
> people who read those lists and the people running outdated vulnerable
> software isn't very large.
to steal from a reply to a private message:
there are a jillion folk at the edges of the net running with low end
gear, low
> On Jan 26, 2019, at 16:48, valdis.kletni...@vt.edu wrote:
>
> On Sat, 26 Jan 2019 11:37:05 -0800, Owen DeLong said:
>>1.Compile a list of lists that should be notified of such experiments
>> in
>>advance. Try to get the word out to as much of the community
>>as
On Sat, 26 Jan 2019 11:37:05 -0800, Owen DeLong said:
> 1. Compile a list of lists that should be notified of such
> experiments in
> advance. Try to get the word out to as much of the community
> as possible through various NOGs and other relevant industry
> I think a better question is, once a vulnerability has become
> widespread public knowledge, do you expect malicious actors, malware
> authors and intelligence agencies of autocratic nation-states to obey
> a gentlemens' agreement not to exploit something?
false anology, or maybe just a subject
Randy Bush wrote on 26/01/2019 16:15:
if you know of an out-of-spec vulnerability or bug in deployed router,
switch, server, ... ops and researchers should exploit it as much as
possible in order to encourage fixing of the hole.
It came out as "please continue", but the sentiment sounded less
I think a better question is, once a vulnerability has become widespread
public knowledge, do you expect malicious actors, malware authors and
intelligence agencies of autocratic nation-states to obey a gentlemens'
agreement not to exploit something?
There is not a great deal of venn diagram
I think that’s a bit of reductio ad absurdum from what has been said.
I would prefer that researchers collaborate to:
1. Compile a list of lists that should be notified of such
experiments in
advance. Try to get the word out to as much of the community
i just want to make sure that folk are really in agreement with what i
think i have been hearing from a lot of strident voices here.
if you know of an out-of-spec vulnerability or bug in deployed router,
switch, server, ... ops and researchers should exploit it as much as
possible in order to
tions [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
> >>> 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 Universit
cially 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 d
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
It does, Ytti. And not just in testing. In feature development too.
Often in design discussions, someone pipes up: "someone does bla bla,
Let's not break it". One I remember from years ago was setting two
route reflectors as clients of each other and thinking route reflection
wasn't designed for
On Thu, 24 Jan 2019 at 18:43, wrote:
> We fight with that all the time,
> I'd say that from the whole Design->Certify->Deploy->Verify->Monitor service
> lifecycle time budget, the service certification testing is almost half of it.
> That's why I'm so interested in a model driven design and
On Thu, 24 Jan 2019 04:00:27 +1100, Ben Cooper said:
> You caused again a massive prefix spike/flap,
That's twice now you've said that without any numbers or details.
Care to explain what you mean by "massive" in a world where the IPv4 table has
like 700K+ routes? And as percieved by what
ow 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 G
> From: Saku Ytti
> Sent: Thursday, January 24, 2019 4:28 PM
>
> On Thu, 24 Jan 2019 at 17:52, wrote:
>
> > This actually makes me thing that it might be worthwhile including
> > these types of test to the regression testing suite.
>
> I seem to recall one newish entrant to SP market
On Thu, 24 Jan 2019 at 17:52, wrote:
> This actually makes me thing that it might be worthwhile including these
> types of test to the regression testing suite.
I seem to recall one newish entrant to SP market explaining that they
are limited by wall-time in blackbox testing. They would have no
sat down and generated BGP packets with slight deviations to see how the BGP
session, process or whole RPD copes with these?
I've got to say no, never.
And judging from the overly positive (or even negative) responses to the BGP
Experiment I'm not alone in this.
Otherwise everyone would be like, nah I
On Thu, Jan 24, 2019 at 03:49:46PM -, adamv0...@netconsultings.com wrote:
> This actually makes me thing that it might be worthwhile including these
> types of test to the regression testing suite.
> So that every time we evaluate new code or vendor we don't only test for
> functionality,
> From: James Jun
> Sent: Wednesday, January 23, 2019 7:02 PM
>
> Agreed; Please resume the experiment. We're all operators here, and we
> MUST have confidence that BGP speakers on our network are compliant with
> protocol specification. Experiments like this are opportunities for a
real-life
.@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
> > T
On Thu, Jan 24, 2019, 5:40 PM Mike Tancsa wrote:
> On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote:
> > +1. I've yet to see any disruptions caused by the experiment in my area.
> >
> Speaking of which, were there any statistics gathered and published
> before, during and after the experiment about
On 1/23/2019 8:27 PM, Töma Gavrichenkov wrote:
>
>> Replying to throw in my support behind continuing the experiment as well.
> +1. I've yet to see any disruptions caused by the experiment in my area.
>
Speaking of which, were there any statistics gathered and published
before, during and after
On Wed, Jan 23, 2019 at 10:16 AM Filip Hruska wrote:
> This experiment should be continued.
> It's the only way to get people to patch stuff.
Agreed. But be gentle. Wait a couple months between repeats to give
folks a generous amount of time to patch their gear. If you create the
emergency that
On 23/Jan/19 21:01, James Jun wrote:
> Agreed; Please resume the experiment. We're all operators here, and we MUST
> have confidence
> that BGP speakers on our network are compliant with protocol specification.
> Experiments like
> this are opportunities for a real-life validation of how
On Thu, Jan 24, 2019 at 3:23 AM Paul S. wrote:
> As others have noted, the right target to be angry at is your
> equipment vendor.
...whose name I'd personally be quite delighted to finally hear.
Is it just the same FRR that got a patch someone failed to apply, or
this time the issue is more
Replying to throw in my support behind continuing the experiment as well.
Assurance that my gear will NOT fall over under adversarial situations
is paramount, thank you for the research that you're doing to ensure that.
Ben, you may wish to re-evaluate how "rock solid" [1] your networking
> On Jan 23, 2019, at 10:16 , Filip Hruska wrote:
>
> This experiment should be continued.
>
> It's the only way to get people to patch stuff.
> And if all it takes to break things is a single announcement, than that's
> something that should be definitely fixed.
>
> Blacklisting an ASN is
On 23/01/2019 20:01, James Jun wrote:
> Kudos to researchers by the way, for sending courtesy announcements in
> advance, and testing
> against some common platforms available to them (Cisco, Quagga & BIRD) prior
> to the experiment.
On 18/12/2018 16:05, Italo Cunha wrote:
> We have
On Wed, Jan 23, 2019 at 06:45:50PM +, Nikolas Geyer wrote:
> Throwing my support behind continuing the experiment also. A singular
> complaint from a company advertising unallocated ASN and IPv4 resources (the
> irony) does not warrant cessation of the experiment.
Agreed; Please resume the
> On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper 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
Throwing my support behind continuing the experiment also. A singular complaint
from a company advertising unallocated ASN and IPv4 resources (the irony) does
not warrant cessation of the experiment.
The experiment is in compliance with the relevant RFCs, the affected “vendor”
has released
On 23/01/2019 18:19, Italo Cunha wrote:
> We have canceled this experiment permanently.
Sad to hear! :/
My impression if you continue is more users will get aware of bugs with
running BGP implementations. Not all follow announcement from $vendor
and will continue to run older broken code and
Sorry. Correction.
If it IS RFC compliant they should accept the attribute. If it is NOT, they
should drop (and maybe log it).
Steve
>Contact your hardware vendor. That is not acceptable behavior. If it is not
>RFC compliant they need to accept the attribute, if it's not RFC compliant
Agreed, do you think you will not see that attribute again now that the public
knows that you are vulnerable to this DoS method. Expect to see an attack
based on this method shortly. They just did you a favor by exposing your
vulnerability, you should take it as such. I would be putting in
Contact your hardware vendor. That is not acceptable behavior. If it is not
RFC compliant they need to accept the attribute, if it's not RFC compliant they
should gracefully ignore it. Now we all know that anyone using that gear is
vulnerable to a DoS attack. Won't be long until anyone else
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 Cun
Töma Gavrichenkov wrote on 23/01/2019 18:00:
What if next time e.g. the bad guys would be doing this? Would you
urge them to also get a sandbox?
Send them a strongly worded memo.
If that doesn't work, threaten to send them a second.
Nick
On Wed, Jan 23, 2019 at 9:05 PM Aled Morris via NANOG wrote:
> I'd go further and say that as long as you're connected
> to the Internet, your equipment better be resilient when
> receiving packets with any combination of bits set,
> RFC compliant or not.
Well, here, when you receive this
On Wed, 23 Jan 2019 at 17:58, Naslund, Steve wrote:
> I hope you are as critical of your hardware vendor that cannot accept BGP4
> compliant attributes or have you just not updated your code? You can black
> hole anything you want but as long as the “Internet” is sending you an RFC
> compliant
> On Wed, Jan 23, 2019 at 12:00 PM Ben Cooper wrote:
> 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.
>
>
I hope you are as critical of your hardware vendor that cannot accept BGP4
compliant attributes or have you just not updated your code? You can black
hole anything you want but as long as the “Internet” is sending you an RFC
compliant BGP you better be able to handle it.
Steven Naslund
od 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.
> > >&g
e 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 Fe
er.
>> > 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
>> > M
m.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
tt, 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
Is that a competition in sarcasm? Because I can do better than that!
10 Jan. 2019 г., 2:41 :
> > Töma Gavrichenkov
> > Sent: Wednesday, January 9, 2019 7:08 PM
> >
> > On Wed, Jan 9, 2019 at 10:03 PM Saku Ytti wrote:
> > > Finding forwarding issues indeed is harder due to the limited access
> >
> Töma Gavrichenkov
> Sent: Wednesday, January 9, 2019 7:08 PM
>
> On Wed, Jan 9, 2019 at 10:03 PM Saku Ytti wrote:
> > Finding forwarding issues indeed is harder due to the limited access
> > to devices, so bit of security through obscurity I guess.
>
> Or, rather, security by complexity.
On Wed, Jan 9, 2019 at 10:33 PM Owen DeLong wrote:
> Fair enough, but the frequency of vulnerability announcements
> even in some of the best implementations is still more often than
> I think my customers will tolerated reboots.
Well, and when I think about it for the second time, I can't help
On Wed, Jan 9, 2019 at 10:33 PM Owen DeLong wrote:
> At the end of the day, this is really about risk analysis
> and it helps to put things into 1 of 4 risk quadrants
> based on two axes… Axis 1 is the likelihood of the
> vulnerability being exploited, while axis 2 is the
> severity of the
> On Jan 9, 2019, at 10:51 , Saku Ytti wrote:
>
> On Wed, 9 Jan 2019 at 20:45, Töma Gavrichenkov wrote:
>
>> Nope, this is a misunderstanding. One has to *check* for advisories at
>> least once or twice a week and only update (and reboot is necessary)
>> if there *is* a vulnerability.
>
>
> On Jan 9, 2019, at 10:37 , Töma Gavrichenkov wrote:
>
> On Wed, Jan 9, 2019 at 9:31 PM Owen DeLong wrote:
>> So if I understand you correctly, your statement is that everyone
>> should be (potentially) rebooting every core, backbone, edge,
>> and other router at least once or twice a week…
On Wed, Jan 9, 2019 at 10:03 PM Saku Ytti wrote:
> Finding forwarding issues indeed is harder due to the limited access
> to devices, so bit of security through obscurity I guess.
Or, rather, security by complexity. Today's network infrastructure is
complex enough for people to dive into it,
Hey,
> firmware which only runs on certain expensive devices. My point is
> that e.g. FRR is an open source software which is designed to run on
> the same Intel-based systems as the one which probably powers your
> laptop.
Most vendors have virtual image for your laptop, all of the modern
On Wed, Jan 9, 2019 at 9:51 PM Saku Ytti wrote:
> I think this contains some assumptions
>
> 1. discovering security issues in network devices is expensive (and
> thus only those you glean from vendor notices realistically exist)
> 2. downside of being affected by network device security issue is
On Wed, 9 Jan 2019 at 20:45, Töma Gavrichenkov wrote:
> Nope, this is a misunderstanding. One has to *check* for advisories at
> least once or twice a week and only update (and reboot is necessary)
> if there *is* a vulnerability.
I think this contains some assumptions
1. discovering security
On Wed, Jan 9, 2019 at 9:32 PM Saku Ytti wrote:
> Those are scheduled, they have to meet some criteria to be pushed on
> scheduled lot. There are also out of cycle SIRTs. And yes, vendors are
> delaying them, because customers don't want to upgrade often, because
> customer's customers don't want
On Wed, Jan 9, 2019 at 9:31 PM Owen DeLong wrote:
> So if I understand you correctly, your statement is that everyone
> should be (potentially) rebooting every core, backbone, edge,
> and other router at least once or twice a week…
Nope, this is a misunderstanding. One has to *check* for
On Wed, 9 Jan 2019 at 20:24, Töma Gavrichenkov wrote:
> So, network device vendors releasing security advisories twice a year
> isn't a big part of the explanation?
Those are scheduled, they have to meet some criteria to be pushed on
scheduled lot. There are also out of cycle SIRTs. And yes,
> On Jan 9, 2019, at 09:51 , Töma Gavrichenkov wrote:
>
> 9 Jan. 2019 г., 9:56 Randy Bush mailto:ra...@psg.com>>:
> > the question is how soon the frr
> > users out on the internet will upgrade.
> > there are a lot of studies on
> > this. it sure isn't on the order of a week
>
> Which is, as
On Wed, Jan 9, 2019 at 9:07 PM Saku Ytti wrote:
> Not disputing bug or bog house as ideal location for said policy, just
> want to explain my perspective why it is so.
So, network device vendors releasing security advisories twice a year
isn't a big part of the explanation?
> Hitless upgrades
On Wed, 9 Jan 2019 at 19:54, Töma Gavrichenkov wrote:
> Which is, as usual, a pity, because, generally, synchronizing a piece of
> software with upstream security updates less frequently than once to twice in
> a week belongs in Jurassic Park today; and doing it hardly more frequently
> than
9 Jan. 2019 г., 9:56 Randy Bush :
> the question is how soon the frr
> users out on the internet will upgrade.
> there are a lot of studies on
> this. it sure isn't on the order of a week
Which is, as usual, a pity, because, generally, synchronizing a piece of
software with upstream security
> On Jan 8, 2019, at 09:06 , valdis.kletni...@vt.edu wrote:
>
> On Tue, 08 Jan 2019 17:48:46 +0100, niels=na...@bakker.net said:
>
>> After seeing this initial result I'm wondering why the researchers
>> couldn't set up their own sandbox first before breaking code on the
>> internet. I
* Job Snijders
> Given the severity of the bug, there is a strong incentive for people to
> upgrade ASAP.
The buggy code path can also be disabled without upgrading, by building
FRR with the --disable-bgp-vnc configure option, as I understand it.
I've been told that this is the default in
On Wed, Jan 9, 2019 at 9:55 Randy Bush wrote:
> >>> We plan to resume the experiments January 16th (next Wednesday), and
> >>> have updated the experiment schedule [A] accordingly. As always, we
> >>> welcome your feedback.
> >> i did not realize that frr updates propagated so quickly. very
>>> We plan to resume the experiments January 16th (next Wednesday), and
>>> have updated the experiment schedule [A] accordingly. As always, we
>>> welcome your feedback.
>> i did not realize that frr updates propagated so quickly. very cool.
>
> FRR is undergoing a fairly rapid pace of
FRR is undergoing a fairly rapid pace of development, thanks to the
cloud-scale operators and hosting providers which are using it in
production.
https://cumulusnetworks.com/blog/welcoming-frrouting-to-the-linux-foundation/
On Tue, Jan 8, 2019 at 11:55 AM Randy Bush wrote:
> > We plan to
> Steve Noble
> Sent: Tuesday, January 8, 2019 6:42 PM
>
> There is no such thing as a fully RFC compliant BGP :
>
Which RFC do you mean 6286, 6608, 6793, 7606, 7607, 7705 or 8212 when you say
fully RFC compliant BGP please?
>
On 1/8/19 9:31 AM, Töma Gavrichenkov wrote:
> 8 Jan. 2019 г., 20:19 :
>> In the real world, doing the correct thing
>
> — such as writing RFC compliant code —
>
>> is often harder than doing
>> an incorrect thing, yes.
>
> Evidently, yes.
I "grew up" during the early days of PPP. As a member
> We plan to resume the experiments January 16th (next Wednesday), and
> have updated the experiment schedule [A] accordingly. As always, we
> welcome your feedback.
i did not realize that frr updates propagated so quickly. very cool.
randy
There is no such thing as a fully RFC compliant BGP :
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/bgp.html
does not list 7606
Cisco Bug: CSCvf06327 - Error Handling for RFC 7606 not implemented for NXOS
This is as of today and a 2 second google search..
8 Jan. 2019 г., 20:19 :
> In the real world, doing the correct thing
— such as writing RFC compliant code —
> is often harder than doing
> an incorrect thing, yes.
Evidently, yes.
>
> On Jan 8, 2019, at 12:10 PM, niels=na...@bakker.net wrote:
>
> * thomasam...@gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]:
>> There are a fair number of open source BGP implementations now. It would
>> require additional effort to test all of them.
>
> In the real world, doing the
Hi Saku,
After seeing this initial result I'm wondering why the researchers
couldn't set up their own sandbox first before breaking code on the
internet. I believe FRR is a free download and comes with GNU autoconf.
We probably should avoid anything which might demotivate future good
guys
> On Jan 8, 2019, at 12:06 PM, valdis.kletni...@vt.edu wrote:
>
> On Tue, 08 Jan 2019 17:48:46 +0100, niels=na...@bakker.net said:
>
>> After seeing this initial result I'm wondering why the researchers
>> couldn't set up their own sandbox first before breaking code on the
>> internet. I
OOn Tue, Jan 8, 2019 at 19:59 Tom Ammon wrote:
> On Tue, Jan 8, 2019, 11:50 AM
>> * cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]:
>> >[A] https://goo.gl/nJhmx1
>>
>> For the archives, since goo.gl will cease to exist soon, this links to
>>
>>
* valdis.kletni...@vt.edu (valdis.kletni...@vt.edu) [Tue 08 Jan 2019, 18:06
CET]:
(Personally, I'd never heard of FRR before)
Martin Winter of OSR/FRR has attended many a NANOG, RIPE and other
industry meetings, so it's not for their lack of trying
-- Niels.
* thomasam...@gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]:
There are a fair number of open source BGP implementations now. It
would require additional effort to test all of them.
In the real world, doing the correct thing is often harder than doing
an incorrect thing, yes.
niels=na...@bakker.net wrote on 08/01/2019 16:48:
After seeing this initial result I'm wondering why the researchers
couldn't set up their own sandbox first before breaking code on the
internet. I believe FRR is a free download and comes with GNU autoconf.
the researchers didn't break code -
On Tue, 08 Jan 2019 17:48:46 +0100, niels=na...@bakker.net said:
> After seeing this initial result I'm wondering why the researchers
> couldn't set up their own sandbox first before breaking code on the
> internet. I believe FRR is a free download and comes with GNU autoconf.
Perhaps you'd
Hey,
> After seeing this initial result I'm wondering why the researchers
> couldn't set up their own sandbox first before breaking code on the
> internet. I believe FRR is a free download and comes with GNU autoconf.
We probably should avoid anything which might demotivate future good
guys
Hi Niels, we did run the experiment in a controlled environment with
different versions of Cisco, BIRD, and Quagga routers and observed no
issues. We did add FRR to the test suite yesterday for future tests.
On Tue, Jan 8, 2019 at 11:49 AM wrote:
>
> * cu...@dcc.ufmg.br (Italo Cunha) [Tue 08
On Tue, Jan 8, 2019, 11:50 AM * cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]:
> >[A] https://goo.gl/nJhmx1
>
> For the archives, since goo.gl will cease to exist soon, this links to
>
> https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview
>
* cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]:
[A] https://goo.gl/nJhmx1
For the archives, since goo.gl will cease to exist soon, this links to
https://docs.google.com/spreadsheets/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview
After seeing this initial result I'm
> 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
as 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
, 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
1 - 100 of 101 matches
Mail list logo
