Unwanted Traffic Removal Service (UTRS)

Thu Oct 9 20:58:05 UTC 2014

Hello,

Am 08.10.2014 um 16:42 schrieb Job Snijders:

>> If you think this is a terrible idea and want to express all that is
>> wrong with it, tell me that too, I can take it.

I support the RTBH idea. I also set up https://wiki.rtbh.me/ for this some
time ago and there is also a discuss mailing list where already 65 people are
subscribed. Currently there is not much discussion on the list, but you all
can change this ;-) Also there is no other content besides the mailing list in
the wiki right now. I have removed it because somebody thought that it may be
confusing for some people on the list as he wanted to use it for a general
RTBH discussion instead of my project. I will try to restore it in the next
days...

> Just like chicory, personally I don't like it. Yes, Cymru has build a
> reputation as clearing house for redistribution of security related
> information. But... (aside from any local safety net filter), it's quite
> a leap to allow a single entity to inject blackholes for any prefix.

What I do not like at this UTRS idea is that I cannot announce a prefix via
BGP. Somebody has to inject it for me. I would like to announce it in real
time and not with delay because of manual approval.

One problem that I also see here is that this single entity could be forced by
someone (eg. government) to blackhole some prefix. If this ever happens such a
project will have to be terminated.

> There are various flavors at the moment in terms of validation (please
> correct me if I am wrong): The Polish blackholing project only allows
> blackholes which fall within the set of prefixes which an ASN
> originates, the DE-CIX BS service accepts anything that is a subset of
> your AS-SET. 
> 
> Both approaches have their downsides: you can make any AS or AS-SET a
> member of your AS-SET and thereby gain a degree of control on the RTBH
> server, and for $500/year you can register any route-object you want in
> RADB.

Allowing ASN to blackhole a prefix based on AS sets is dangerous from my point
of view. In the RIPE database you can add any AS to your AS set without
verification. Ok, it doesn't make much difference because most IP transit
providers also filter on the AS set, but a worldwide announced /24 prefix is
much more visible than a /32 blackhole route that is only announced to the
participants.

My idea was that an ASN can only announce more specifics prefixes (not just
/32) from officially registered routes. Downstream ASN should also be able to
define their upstream ASN who may blackhole their prefixes if they do not set
up their own session to the RTBH route servers. Most IP transit providers have
an RTBH service for their customers that these downstream ASN could use.
Usually they do not offer such a service for peers. This is the useful part here.

We also had some DDoS attacks via IPv6. I think it's important to also have
such a service for IPv6. Starting with IPv4 is ok and better than nothing, but
IPv6 should not be on the roadmap for 2018 ;-)

> Might I suggest an alternative approach, without central validation or
> need for a clearing house:
> 
> IXPs could offer BGP or API triggered ACLs which are inserted into the
> peering fabric and only affect the participant's peering port(s). This
> way, any blackholing (either correctly applied or malicious) only
> affects the initator of that blackhole and nobody else. Advantages are
> that aclserver does not require peers to cooperate with each other and
> no validation is required.

Why is there no validation required when this is done by an IXP? "All peers
are my customers and I do trust them"? What about private peerings via PNIs?

Regards,

Chris
-- 
Individual Network Berlin e.V. : support at in-berlin.de : vorstand at in-berlin.de
Tel +49-30-45494343 ::: Fax +49-30-45494344 ::: Web https://www.in-berlin.de/
IN-Berlin e.V. : Christian Seitz (1. Vors.) : Lehrter Str. 53 :: 10557 Berlin
Amtsgericht Charlottenburg 95 - VR 15669 Nz ::::::: USt.Ident-Nr. DE188894648