North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: NSPs filter?
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 [email protected] > > clue++; | http://puck.nether.net/~jared/ My statements are only mine. >
|