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?
Stephen
I would filter only if the root server operator is complaining about
it...not to say I would do nothing; I would most definitely give the
customer a call and strongly advise them to set up a local resolver,
citing the volume of redundant traffic they're paying for...
-C
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
One would hope that, unless there is a complaint, you wouldn't be invading
their private to look at their traffic in the first place.
If a root server operator complained about it, I'd say thats reasonable
grounds to filter it and contact the customer, the same as if they had a
compromised box spewing out DoS.
Filtering piddly stuff like this without consultation is usually unwelcome
at best, and a disruption at worst. It is also a serious investment of
time and acl resources which could be better spent somewhere else. And
lastly, it sets a bad precedent for what ISPs "can" do to proactively
filter. After all, if we "can" do this, why can't we also filter illegal
MP3 exchanges too.
Or you could be a good neighbor and have your DNS answer NXDOMAIN for
the RFC1918 zones and stop the traffic before it left your network.
If you have clients that are using RFC1918 and YOUR NS's then don't
let those packets out. Give a NXDOMAIN answer back towards them
and save us all.
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)
Watch that Good Thing (tm) Martha Stewart might have something to say
about that:):).
Or set up an AS112 server, let the customer win2k boxes send updates and
then *accept*those*updates*. Watch badly configured networks go bellyup
when the updates are served out again and then over-written.
*evil grin*