NSPs filter?

Scott Granados scott at graphidelix.net
Tue Aug 6 02:01:26 UTC 2002


Watch that Good Thing (tm) Martha Stewart might have something to say 
about that:):).
On Mon, 5 Aug 2002, John M. Brown wrote:

> 
> But keep in mind that there is a difference between IP Header
> Source being RFC-1918, and the payload having a query for 
> something in RFC-1918 space.
> 
> Yes, dropping packets that you have no valid return path for is not
> bad.
> 
> Dropping queries from your network asking for things in RFC-1918 space
> is also good thing (tm)
> 
> 
> On Mon, Aug 05, 2002 at 11:06:50AM -0400, Jared Mauch wrote:
> > 
> > On Sun, Aug 04, 2002 at 09:15:26PM -0700, Stephen Stuart wrote:
> > > > 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.
> > > 
> > > Let's say the customer operates some big enterprise network, runs
> > > their infrastructure in RFC1918 space ("for security," hah), and spews
> > > a couple kilobits of DNS query from that RFC1918 space toward the root
> > > nameservers. Assume that either pride or ignorance will prevent the
> > > customer from ever asking you to filter what you know to be garbage
> > > traffic. Does your rule to "never filter customer packets" mean you're
> > > going to sit and watch those packets go by?
> > > 
> > > If yes, why?
> > 
> > 	Everyone should turn on either the equivalent of
> > the Cisco 'ip verify unicast source reachable-via any' on their
> > peer/upstream interfaces as well as to internal and bgp customer
> > interfaces that may not be able to be checked with a stricter rpf.
> > 
> > 	This will drop packets from people that you have no return
> > path for in the cef path.  I know other vendors either have or should
> > have this feature.  While it will not stem a true DoS based on real
> > ip addresses, zombies, whatnot.. it will stop all the rfc1918 headed
> > towards the roots or other space that is not in the global routing table.
> > 
> > 	if your vendor doesn't have such a knob, i do suggest asking
> > them :)
> > 
> > 	i've seen a lot of traffic get dropped by using such a
> > check on interfaces.  it is not a large amount compared to
> > the overall packets but does reduce what you end up transporting
> > and customer support queries about why 10.* is sending them packets.
> > 
> > 	- jared
> > 
> > -- 
> > Jared Mauch  | pgp key available via finger from jared at puck.nether.net
> > clue++;      | http://puck.nether.net/~jared/  My statements are only mine.
> 




More information about the NANOG mailing list