don't filter your customers. when they leak the world to you, it will
get you a lot of free press and your marketing department will love you.
just ask telstra.
randy
Who once said, there is no such thing as bad press?
http://www.itnews.com.au/News/291364,telstra-router-causes-major-internet-outage.aspx
"Dodo has revealed a "minor hardware issue" was behind a Telstra outage that impacted multiple service providers and internet services nationwide"
Does anyone have any additional details?
Christian
"Dodo has revealed a "minor hardware issue" was behind a Telstra
outage that impacted multiple service providers and internet services
nationwide"
bs, trying to blame it on a vendor.
a customer leaked a full table to smellstra, and they had not filtered.
hence the $subject.
and things when further downhill from there, when telstra also did not
filter what they announced to their peers, and the peers went over
prefix limits and dropped bgp.
randy
\
and things when further downhill from there, when telstra also did not
filter what they announced to their peers, and the peers went over
prefix limits and dropped bgp.
Oh! so protections worked!
and things when further downhill from there, when telstra also did not
filter what they announced to their peers, and the peers went over
prefix limits and dropped bgp.Oh! so protections worked!
imiho, prefix count is too big a hammer.
it would have been better if optus had irr-based filters in place on
peerings with telstra. then they would not have dropped the sessions
and their customers could still reach telstra customers.
of course, if telstra did not publish accurately in an irr instance,
not much optus could do.
randy
IOS-XR
I'm laughing now, but it wasn't funny a couple of hours ago. Seems a lot of the .au govt needs to learn some carrier diversity...
not just the .au govt
C
and things when further downhill from there, when telstra also did not
filter what they announced to their peers, and the peers went over
prefix limits and dropped bgp.Oh! so protections worked!
imiho, prefix count is too big a hammer.
sure. aspath-filter! 
it would have been better if optus had irr-based filters in place on
peerings with telstra. then they would not have dropped the sessions
and their customers could still reach telstra customers.
really, both parties need/should-have filters, right?
both parties should have their 'irr data' up-to-date...
both parties should also filter outbound prefixes (so they don't leak
internals, or ...etc)
telstra seems to have ~8880 or so prefixes registered in IRRs (via
radb whois lookup)
optus has ~1217 or so prefixes registered in IRRs (again via the same
lookup to radb)
of course, if telstra did not publish accurately in an irr instance,
not much optus could do.
it's not clear how accurate the data is 
I do see one example that's
not telstra (and which I don't see through telstra from one host I
tested from)
203.59.57.0/24
a REACH customer, supposedly, registered by REACH on the behalf of the
customer... the whole /16 there is allocated to the same entity not
REACH though, so that's a tad confusing.
-chris
Speaking of leaking the world, I remember one of our transit peer during
their nightly maintenance decided they needed people to talk to, so they
decided to share some love by passing ~ 350k routes causing a meltdown.
As lesson learned, we included a combination of prefix-list &
maximum-prefix filters as part of our config script.
When the hard limit hits a certain percentage, we get alerted that the
neighbor is approaching the limit.
regards,
/virendra
a customer leaked a full table to smellstra, and they had not filtered.
hence the $subject.
Ahh, this is I think the customer "leak" problem I'm trying to illustrate
that an RPKI/BGPSEC-enabled world alone (as currently prescribed)
does NOT protect against.
If it can happen by accident, it can certainly serve as smoke screen or
enable an actual targeted attack quite nicely by those so compelled.
and things when further downhill from there, when telstra also did not
filter what they announced to their peers, and the peers went over
prefix limits and dropped bgp.
Prefix limits are rather binary and indiscriminate, indeed.
-danny
a customer leaked a full table to smellstra, and they had not filtered.
hence the $subject.Ahh, this is I think the customer "leak" problem I'm trying to illustrate
that an RPKI/BGPSEC-enabled world alone (as currently prescribed)
does NOT protect against.
the problem is that you have yet to rigorously define it and how to
unambiguously and rigorously detect it. lack of that will prevent
anyone from helping you prevent it.
randy
AS-PATH filters and max-length filters, OTOH, are not.
Also, it's important that network operators understand that flap-dampening has been iatrogenic for many years, now.
Also, it's important that network operators understand that
flap-dampening has been iatrogenic for many years, now.
wellllll, ...
randy
You referred to this incident as a "leak" in your message:
"a customer leaked a full table"
I was simply agreeing with you -- i.e., looked like a "leak", smelled
like a "leak" - let's call it a leak.
I'm optimistic that all the good folks focusing on this in their day
jobs, and expressly funded and resourced to do so, will eventually
recognize what I'm calling "leaks" is part of the routing security
problem.
-danny
Sure; I don't disagree, and I don't think that Randy does. But just
because we can't solve the whole problem, does that mean we shouldn't
solve any of it?
As Randy said, we can't even try for a strong technical solution
until we have a definition that's better than "I know it when I see it".
--Steve Bellovin, https://www.cs.columbia.edu/~smb
that is often the way things are argued in engineering circles.
the solution is imperfect therefore it is useless.
this philosophy is reflected in the shoddy state of networks today.
-Dan
Nope, we most certainly should decompose the problem into
addressable elements, that's core to engineering and operations.
However, simply because the currently envisaged solution
doesn't solve this problem doesn't mean we shouldn't
acknowledge it exists.
The IETF's BGP security threats document [1] "describes a threat
model for BGP path security", which constrains itself to the
carefully worded SIDR WG charter, which addresses route origin
authorization and AS_PATH "semantics" -- i.e., this "leak"
problem is expressly out of scope of a threats document
discussing BGP path security - eh?
How the heck we can talk about BGP path security and not
consider this incident a threat is beyond me, particularly when it
happens by accident all the time. How we can justify putting all
that BGPSEC and RPKI machinery in place and not address this
"leak" issue somewhere in the mix is, err.., telling.
Alas, I suspect we can all agree that experiments are good and
the market will ultimately decide.
-danny
[1] draft-ietf-sidr-bgpsec-threats-02