Internet2 Network Security SIG

[John Kristoff <>]

On Tue, 26 Jul 2016 14:37:56 -0500
David Farmer 
<>
 wrote:

> Like I said I'm skeptical of this really being useful

I largely agree.  It might be useful for consistent measurement and
monitoring across networks, and perhaps for management in large
networks or IXes, but I find it largely uninteresting otherwise and am
not particularly motivated to make change unless a peer or upstream
does.

That it is transitive means as an edge network we'll probably be
preparing an import policy to ignore or reject them by default in case
someone leaks them to us.

Perhaps to this community, more important than discussing it's use is
to start communicating to networks that they should begin preparing
import policy changes to reject them by default, lest people shoot
their foot off.

...and if everyone does this, a reverse attack (or feature) of a sorts
is possible.  If I don't want you reaching my network I'll add the
black hole community to my prefixes, in anticipation of you dropping
them by default.  :-)

> A web-based interface for a participants to use for managing black
> hole
> > routes would be really nice to have.  These should automatically
> > expire after some period.  
> 
> This sounds interesting and maybe a more useful way to think about
> this, could you flesh this out a bit more.

I'm happy to help with this, but I'm not sure I can flesh it all out in
a mailing list post.  Here are a few random thoughts...

Rather than require black hole routes to originate with a BGP peering
session, just make a web interface. Arguably this is going to be far
easier, less error prone and maybe easier to get to out of band in
times of duress for anyone announcing routes.  I think for most of I2
members, the need is for them to be able to announce black hole routes
to I2 and have the traffic prevented from reaching them.  I don't think
we need to worry about relaying black holes all the way down to all
individual member networks.

Of course this must have some sort of authentication mechanism.  A new
contact/network portal may have to be built by the Internet2
community. This might not be trivial.  I have no idea what exists if
anything today.  Perhaps IRR/RIR data can be used to do some
verification of contacts to allowed black hole announcements.  REN-ISAC
may have some interest in this as they do some of this already when
they need to relay problems about specific R&E addresses. There is
certainly some synergy with them.

This starts to get a little tricky as soon as someone wants to make an
announcement for a downstream network.  Can they?  What if the
downstream has multiple upstreams, can any of them announce the black
hole?

Announcements could be made via the web interface in addition to a
traditional BGP advertisement, but it should also have an API interface
for those who would rather script something directly without involving
their peering router.   A web or API interface provides the sometimes
desirable separation of routing infrastructure management and black
hole management.

If announcements arrive via the web interface there should be an
expiration time when the route will be withdrawn  I used seven days with
UTRS, but as long as it is not infinite by default.

There should be a max-prefix limit for black hole routes per origin ASN.

Someone has to build and maintain this thing.  Fun project, but not a
one day and done project.

John