Unwanted Traffic Removal Service (UTRS)

Job Snijders job at instituut.net
Thu Oct 9 21:19:05 UTC 2014


Hi Christian,

On Thu, Oct 09, 2014 at 10:58:05PM +0200, Christian Seitz wrote:
> <snip> 
> 
> 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?

Validation is not required because the requester can only affect his or
her own peering ports. Conceptually the IXP participant sets an ACL,
just not on their own ingress routerport but on the egress port just
across the crossconnect, this prevents congestion of said crossconnect.

Modern switching/routing equipment used in IXPs can do far more then
mere L2 switching. Lots of chipsets these days allow you to apply
combined layer-3 + layer-2 ACLs, an example would be "Discard traffic if
(destination IP is A && destination MAC is B)".

The blackhole route is announced to a special network component which I
dub the "ACL Server". The ACL Server is operated by the IXP (exabgp +
customizations?). The ACL Server takes the prefix and associated origin
(origin is a static lookup table based on source IP or ASN, IXPs know
who their members are) and then inserts a layer3+layer2 ACL into their
switching fabric.

If the IXP, on every ingress port, have a ACL that says "drop traffic to
this IP if the dest MAC address corresponds with the originator of the
ACL request", the ddos traffic doesn't even hit the IXPs backbone, and
only affects the peering participant who requested the ACL to be
inserted. 

So the blackhole route only lives inside the IXP's switching fabric so
to speak, as an ACL only applicable to the participant itself.

Regarding implementation: some IXPs might have to screenscrape/expect to
apply ACLs on their switches with clogin, others will just convert the
announcement and insert flowspec or sdn rules in the fabric. It is the
IXP's job to sanitize the ACL trigger in such a way that it only applies
to the peering ports of the participant requesting it.

I hope this clarifies a bit.

Kind regards,

Job



More information about the NANOG mailing list