North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
RE: NSPs filter?
> IMO, Commercial ISPs should never filter customer packets unless > specifically requested to do so by the customer, or in response to a > security/abuse incident. We already have BCP 38, which strongly recommends packet filtering on the customer-ISP edge. There are now two major vendors who have strict mode uRPF. This which covers 80% of the BCP 38 packet filtering on the customer-ISP edge. With a few BGP config tweaks, strict mode uRPF can cover a lot of the last 20% (all those multihomed customers). Q. What is wrong with BCP 38 filtering? We also have Loose Mode uRPF that can work on all the ISP edges. While this was originally done to allow source based remote-triggered black hole filtering, Loose Mode uRPF does do some sanity checking of the packets. It drops any packet whose source is not in the global route table. So it is an effective bogon, RFC 1918, and martin filter on the ISP-ISP edge. Q. What is wrong with filtering packets with source address that should not be out there floating on the Net? The only thing that has been holding up uRPF deployment has been ISP migrating to images that support uRPF (mostly done) and operational confidence in the feature (so the operators know it is not going to hose their network). Both of these are well on their way with more operators turning on uRPF (Strict or Loose mode). So it is really a matter of time before we have a lot of uRPF doing packet filtering on the ISP edges. But, what if you could "strict mode" packet filter on the ISP-ISP side? Lets say there was a dynamic uRPF filter that checked the source addresses against the eBGP routes coming into a link. In other words, if the source address from an ISP does not match the eBGP prefixes coming across from the peer, the packet would drop. So if some /8 prefixes are filtered on the eBGP side, they would get dropped on the ISP-ISP peering interface. For example, if I only send routes from AS X, then any packet whose source address is outside of AS X (say from AS Y) would not pass the uRPF check - resulting in a drop. Since this is based on the dynamics of the eBGP prefixes coming across the peering session, it would allow a "strict mode like" uRPF packet filtering on the ISP-ISP edge (with all the asymmetry found on the ISP-ISP edge). The question is whether this is something people would want as an option. A uRPF mode that would enforce a peering agreement with dynamic packet filtering (dynamic is based on the eBGP advertisements that get through the peering filter). Barry