But maybe filtering is putting the cart before the horse.
I believe in general we have been having a discussion about
operational practices, not really about theoretical ideas
of what we might be able to do twelve to eighteen months
out.
But discussing those theoretical things is good too, but I think
it's important to make clear what the scope of any
particular message in this thread here is, otherwise
confusion runs rampant.
Incidently, while we're here, you might look at Stefan Savage's paper
"http://www.cs.washington.edu/homes/savage/traceback.html";, which kc
pointed NANOG at yesterday. I describe it as "having each router
probabilitically mark transit IP packets with a router-specific
locational referent in the ip_id field."
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.
That is a lot of suspicious packets. Is a packet to a random UDP port
"suspicious"? If not, then this scheme is mostly useless against our
most recent series of attacks. If it is suspicious, then the attackers
will switch to TCP packets -- are those suspicious too? Are all
packets suspicious?
- 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.
This generates more traffic in the network for each of these; when the
problem is traffic flooding, as it has been most recently, this may be
unwise.
What would a credential check involve? Where would these
credentials be issued from and how-validated?
- 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.
This suggests some sort of AI, or at least relatively clever
heuristics. My brain says "research problem--IRTF--bye!" Perhaps
that's unfair?
- 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.
Where look for is "send a message to an operator"? How does this work
across multiple routing domains (e.g. provider boundaries)?
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.
It appears to imply state on the order of 1 unit for each packet the
router transits. That's an immense amount of 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.
Yes, tracing requires state. How to distribute or limit that state is
the essessence of most of the discussion of tracing schemes. Marking
packets puts the state inside them. Only collecting state on some
kinds of flows or in response to some trigger also limits the state.
So the costs boil down to more memory, more software, some
pattern-matching hardware, and maintaining security relationships
with your routing partners.
Sure.
I think that doing anything other than what already has been done that
might loosely fit your description is likely to be terribly
unpractical and feels like a research problem.
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.
Ingress filtering is something we can do today, and has a very small
negative effect -- it limits the ability of some people who use the
network in non-traditional ways (half-tunneled setups, etc.), and
those people can simply request a broader ingress filter; I haven't
seen an example of how that fails, except when the people doing
the ingress filtering refuse, and that's not a problem with ingress
filtering, but instead a problem of politics.
--jhawk