DoS tracking service
Jeremy Porter
jerry at freeside.fc.net
Wed Apr 22 20:04:55 UTC 1998
Just forwarding this for a friend.
------- Forwarded Message
Date: Wed, 22 Apr 1998 11:16:48 -0700
From: "Steve Uurtamo" <uurtamo at AZStarNet.com>
To: jerry at fc.net
Subject: Re: Filtering ICMP (Was Re: SMURF amplifier block list)
> 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 lookin
g
> 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
------- End of Forwarded Message
More information about the NANOG
mailing list