North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: RIPE NCC publishes case study of hijack

  • From: Danny McPherson
  • Date: Fri Feb 29 14:59:07 2008

On Feb 29, 2008, at 11:49 AM, David Ulevitch wrote:

Of course... In fact, wouldn't it even providers benefit from having some logic that says "don't ever accept a more specific of a customer-announced prefix?"

Sure, that'd suck less, I guess, although then you have to punch holes for multi-homed customers, etc.., which is actually trivial if policy is generated automatically based on RPSL or the like and the policy is registered accordingly. But I still prefer explicit route policy where what an AS is permitted to announce is all that's permitted and any other prefixes are discarded. Any policy that allows lots of more specifics to be announced in case of route hijacking to me is like putting a band-aid on a headache.

Customers might not like that though... :-)

Right, it's breaks fail-over with multi-homing, in particular. As far as other more specifics for TE and the like, well, they're certainly welcome to register those prefixes such that they can be reflected in routing policies, but this would also ease announcements of unintentional more-specifics.

I don't consider this one of those 'YMMV' things.  Today, if
providers explicitly filter at all they filter customer routes based
on some IRR data or other internal database.  They may put a
few safety nets in place for bogon prefixes and certain prefix
length policies or ASNs, or perhaps not accept their own aggregate
or more specifics from peers.

However, they accept everything else from peers, which means
tomorrow, when this happens again, all they can do is get pissed
because some monkey on the other side of the world fat-fingered
a 2 instead of a 3, or forget to attached a no_advertise, no_export
or other explicit non-transit community to a blackhole route .. and
now some other site "that presumably matters" is offline, or half
reachable, or whatever...

Further, we can keep experiencing more extraneous route table
bloat because of folks advertising more specifics of their own
aggregates in order to minimize any impact a potential hijacking
might have to their own space......

Or, we could start implementing explicit inter-provider filtering.

Explicit policy on all inter-domain peers, customer or provider, based
on RIR allocations, IRR objects and RPSLish language, and work on
removing deployment barriers (e.g., stale IRR data, allocation
authentication, IRR update vulnerabilities, router configuration scale
and load issues, TTM for newly announced prefixes, etc..),  with
real deployment likely in an incremental bi-lateral manner between
ISPs that employ IRR data for customer route policy today and already
have tools to manage and deploy new policy.

I challenge providers to step up here, the onus is on you and nothing
else is going to make this problem go away.    There's tangible
incremental benefit to any provider that institutes such a policy, and
by it's very nature, the right ISPs will encourage other sites on the
Internet to begin employing IRRs and similar mechanisms, if for no
reason other than to enable propagation of their own legitimate routes
more quickly.