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