> o Making sure source IP address spoofing isn't as easily done as
> it is now. Also an easy one, right? :wink:

I agree, and this is what we have done. The earlier post (from someone else)
was asking about how to filter *outbound* directed broadcasts, and I didn't
understand how this could be done. A number of my NANOG colleagues have
adamantly agreed that it can't!

You probably can't, however the point H�vard was making
is that if you deny people the opportunity to spoof the
origin of their packets, you deny people the ability to
engage in long-term denials-of-service of this nature,
and you increase the liklihood of catching the individual

These two things will tend to reduce the number of
Smurf and other attacks.

> o Lastly, I think that better tools are needed to track this
> sort of attacks back to their source (?).

That would be very difficult, effectively requiring the ability to query
routers and ask if they are seeing packets bound for a specific address. I'd
love to see some tools that would help us do that, however!

H�vard mentioned work going on to do RPF checking.
A feature that looked for "out of profile" RPF-failed
traffic but that did not drop RPF-failed traffic in general
would be a useful debugging tool.

Out-of-profile traffic ought to include any large amount
of traffic over a sustained period. More cleverly,
if the traffic is not TCP traffic or if it is TCP traffic
but does not appear to react to induced early packet loss
(i.e., you drop a packet deliberately and wait for the
sender to react with a retransmit and a decrease in sending
bandwidth) and it fails the RPF test, ring alarm bells
and optionally drop the traffic altogether.

RPF, btw, is "reverse path forwarding", which comes from
the wonderful world of multicast lingo. Essentially when
you do any type of flooding you ant to make sure you don't
forward the flooded traffic back in the direction from which
you heard it in the first place. In the world of unicast
it is a short-hand way of saying that you check to make
sure that a particular packet came from the direction
in which you route traffic destined for that packet's
source address.