Filtering ICMP (Was Re: SMURF amplifier block list)

Tue Apr 21 18:38:13 UTC 1998

Okay, so it's clear that we need to come up with some sort of sol'n
to these kinds of problems.

Here's my two cents:

Don't block all of ICMP.  Block pings and traceroutes if you think that
it's going to make your life better, but please don't break anything else.

We need a low-pain protocol to allow provider NOCs to check out a
few salient things on their upstream provider's/peers routers --
e.g. which interface a particular spoofed packet is coming from, the IP
address of the remote-side interface, etc., etc., all the way back
to the source.  This would allow provider NOCs to track this stuff
down themselves.  No more 6 hour phone calls to people with various
degrees of clue/time/energy for a problem that may only occur for
15 minutes at a time, every 4 hours.

It wouldn't be hard to jimmy this protocol (in case people care) such that
you would ONLY be able to track back to a particular NOC's router if all
of the inbetween-routers had "signed off" on the fact that what you're looking
for (specific dst/src or packet type) had actually SHOWN UP on them as well.
It wouldn't have to continuously check this -- just check once and PK-encrypt
the timestamp into the signature on the authentication packet.  Various
timeouts could be configured by individual NOCs.  (Yes, each NOC could have
its own PK value -- but there would only have to be one per AS).

Before everyone gets all hot and bothered about the suggestion that I'm
making -- I'm not talking about arbitrary packet sniffing -- I'm talking
about sniffing HEADERS on packets whose dst address (or packet type or 
whatever everyone agrees is significant) is inside the domain of the dst 
provider.  Not a big deal.  I really don't think that it's that
much to give up -- hell, digex already allows me to dump their entire BGP
table anytime I want -- i'm just talking about some very minimal tracking
ability.

Some companies, such as sprint, who may have hundreds of customers plugged
into a single router, may not want to do this.  But frankly, without this,
we're all dependent upon the clue/time/energy of some guy who's busy doing
his own thing, and we aren't guaranteed timely and accurate information.

Actually, now that I think of it, you could almost jimmy this out of a
few hours of PGP-wrapped SNMP-calling perl scripts listening to some
fixed socket at some fixed (and published) IP address of each network
provider.  No reason to dick with the router code if no need to.

What say ye?  

steve