Hello Vernon,
Well.. as soon as somebody presents us with "the real solution", we'll start
implementing. In the meantime, filtering is the best we know how to do.
...
I really wish "we" actually knew how to filter.
But maybe filtering is putting the cart before the horse.
I compare the recent problems with phone harassment. We can
install all sorts of doodads, but if we can identify the source
of the harassment we can bring charges against them.
From that analogy, I claim that the appropriate action is to
develop tracing systems that will help to identify a wrongdoer.
Here is a possible design.
- Create a router feature, able to be remotely activated, to keep
track of "suspicious" packets for a few seconds up to maybe a
couple dozen seconds. Suspicious packets might be SYNs, or
even packets with "incorrect" source addresses.
- If a violation is noticed, determine the interface on which a
bad packet was received, and send a request to that neighbor
along with appropriate credentials that can be checked.
- If, on the other hand, a neighbor sends a request for tracing
a problematic packet, check the credentials that accompany the
request and look at the stored data for that packet. If no
stored data exists, send back the bad news, and possibly enable
the pattern-matchine function to capture similarly featured
packets in case of future requests.
- If a neighbor's request refers to a stored packet, figure out
what interface the stored packet arrived on. If the packet
came from another neighbor, forward the request. Otherwise,
look for the malicious source internal to the domain.
The basic idea then would be to trace back bad packets that
conform to some typically innocent, but occasionally troublesome,
profiles. The profiles will become self-evident with experience,
and once people know they will be caught by this traceback
system they will think twice before spreading their crap around.
According to one knowledgeable source, this strategy is undesirable
because it would cause routers to maintain more state. But, I claim
that we have to maintain state to do any tracing, and I also claim
that we need to enable tracing in order to detect and identify
wrongdoers. Since the features should be activated by request
from trusted neighbors, in the usual case there should not be
any significant performance degradation. Clearly, such requests
have to be checked for authenticity.
So the costs boil down to more memory, more software, some
pattern-matching hardware, and maintaining security relationships
with your routing partners.
I think it's a very worthwhile tradeoff. Much better than mostly
ineffective measures that have big negative effects and small
positive effects, characteristics of ingress filtering as I
understand it.
Plus I don't like the attitude of blaming the victim without
giving the victim any tools with which to find the perpetrators.
Regards,
Charlie P.