3 ms·
I'd argue that the end networks really aren't the best place to be implementing this. If the big transit providers (Level3, NTT, etc) started enforcing it, it
by devicenull 11y ago
I'd argue that the end networks really aren't the best place to be implementing this. If the big transit providers (Level3, NTT, etc) started enforcing it, it would significantly reduce the effectiveness of spoofed traffic pretty much overnight.
- jsmthrowaway 11y agoIt might seem that way, but they can't scale that, as you might know. It's tougher for DFZ transit to do it because they must know, and programmatically configure, all downstream space to be whitelisted. Now you have a similar conversation to BGP filtering when downstream networks change space, and that's huge administrative overhead (which is why announcements are just trusted without filtering at the higher levels, to avoid this overhead for the larger AS). Your end network is a better place because you know your assigned space better, as well as how you number it; you might be holding half an /18 and not assigning it, whereas your peer would whitelist it all, for example. If the technicals of the Internet were programmatically available in a sane way (PeeringDB doesn't count here, since it just automates manual work), the Tier 1s could potentially automate against their downstream AS' space and enable your (mostly correct) point. However, we pretty much fly blind in this respect and rely on emails and ticketing and decentralized systems to manage the control plane of the Internet. Which honestly continues to shock me, even though it makes sense since the Internet is designed as "decentralized" despite being anything but in usage. Edit: While in the car, I realized that Paul Vixie's paper on this discusses the CPE source-filtering angle in great detail, which might illustrate my opinion a little better for you than I ever could: https://queue.acm.org/detail.cfm?id=2578510 https://queue.acm.org/detail.cfm?id=2578510