Global Blackhole Service

Fri Feb 13 17:18:00 UTC 2009

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

@jack: sorry for duplicate ... pressed reply instead of reply-all ;)

Jack Bates schrieb:
> Valdis.Kletnieks at vt.edu wrote:
> Presumably, the route server would have to have the same guidelines as
> issued by service providers. ie, /32 networks injected should come from
> authenticated feeds and fall within the netblock range owned by the
> injector. So one extra set of ACL's for each injector to upkeep. I
> believe what is being suggested is just one step beyond what many
> providers give to BGP customers to extend blackholes out.

Exactly that's the way I intended. I know that it's a not to small thing to
maintain such a system, we are running it successfully for years with both,
downstream-bgp-customers and upstreams. Even with quiet a small number of
downstreams there are several changes each month (new IP-Space, drop-off of PI
moved away from the customer ...), but I think it would be a manageable thing
to keep it up2date when preparing some automatism. E.g. a automated
prefix-list-generator requesting the authorization (e.g. automated mail with
link including authorization-hash) for blackholing at the AS-Owner before
accepting prefixes ...

>
>> Oh, and cleaning up an entry in a timely fashion is also important,
>> otherwise
>> an attacker can launch a DDoS, get the target into the feed, and walk
>> away...
>
> This also would be decided by the injecting provider. More of a "Hey,
> one of my IPs is being DDOS'd, please drop traffic to it to protect the
> rest of my network." The downside to widespread use, is that it makes
> tracking the problem on the other side of the blocks near impossible. In
> all cases, once a blackhole is initiated anywhere, the DDOS has been
> successful.

Well, for that single IP the DDoS was sucessfull, but looking at the issue I
had yesterday, it's to protect other customers also getting into trouble due
to this DoS. The complete rack had 1GBit-Uplink, which is normally absolutely
sufficient for 20 servers. Well one single server was under attack, but 19
other "innocent" customers were not reachable. And, the even bigger problem
was, the AMSIX-Port of one of my upstreams was "filled to death" due to this
DoS and therefore several thousand customers had enormous packetloss due to
one single destination-ip. Therefore it's to decide what to prefer, one single
customer dead or thousands of angry customers. And I know that I prefer to
protect my own backbone under these circumstances.

> We use automatic community changes to accept /32 blackholes
> from customers, verify them, then send them on to peers that also
> support /32 blackholes with appropriate communities.

That's what we currently also do and until now we never had any problem with this.

BR
Jens
>
>
> Jack
>
>
> Jack
>

- --
===================================================================

Jens Ott
Leiter Network Management

Tel: +49 22 33 - 612 - 3501
Fax: +49 22 33 - 612 - 53501

E-Mail: j.ott at plusserver.de
GPG-Fingerprint: 808A EADF C476 FABE 2366  8402 31FD 328C C2CA 7D7A

PlusServer AG
Daimlerstraße 9-11
50354 Hürth

Germany

HRB 58428 / Amtsgericht Köln, USt-ID DE216 740 823
Vorstand: Jochen Berger, Frank Gross, Jan Osthues, Thomas Strohe
Aufsichtsratsvorsitz: Claudius Schmalschläger

===================================================================

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmVq0gACgkQMf0yjMLKfXqq+QCfW7FzEeXE8MsN3DJQcn8B/ezE
EIwAoJttNgusWNFu+ebOswIBw0g6734w
=5x5v
-----END PGP SIGNATURE-----