North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: NSPs filter?
- From: Barry Raveendran Greene
- Date: Mon Aug 05 12:06:44 2002
> 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
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