smurf, the MCI-developed tracing tools (was Re: Bogus announcement)

Sun Dec 28 18:43:44 UTC 1997

Karl wrote:
> in response to what I wrote:
> > One of the better respected of them, told me that their philosophy
> > was to deliver all packets to me regardless of the source/type.
> > This corker, is the type of logic one can apparently come up with
> > when ones routers at Pensaulken are near fall-over. 
> > This upstream did install the filter, after escalation, fortunately.
> 
> You don't want to filter ICMPs.  What you want to filter is ANYTHING which
> came from an invalid source address *at your entrance* from your customer
> connections.

I agree with you that requiring source addresses to be
within their approriate ranges will render this and other problems
virtually solved. However, I believe that it has to be implemented in so
many places that while it is being done we will need icmp echo-reply
filtering as an interim keep-the-links-running measure.
The difficulty is in the wide range of network administrator skills running
a large range of commercial, university and isp networks.

> 
> Now, for backbone<>backbone connections, this is impossible - granted.
> 
> But for end-user<>backbone connections, it is not only not impossible, it is
> virtually a REQUIREMENT.

sure thing Karl, but its a virtual requirement that zillions of nets are 
ignoring, and getting 99.99 percent compliance will take serious time, if
it is even doable. Without very high compliance the smurfkids will have
readily available, low-bandwidth launch points that are the devil to
trace. We need interim solutions, and icmp-echo-reply filtering is
what we've got, *if* the backbones will continue to provide it.

> > The current cost of per link filtering is apparently causing the
> > backbone networks major grief. 
> 
> That's because people are doing it on the packet TYPE.  If you filter on the
> source *address*, at the ingres point to your network, it causes much less
> pain.

agreed, but icmp-echo-reply filtering is still needed in the meantime.

karl talks about spoof limiting here:
> This is NOT difficult to do, nor is it expensive.  Until it becomes a
> standard part of end-user connections this problem is going to remain
> extremely difficult to trace.

agreed.

Ken Leland