> From: Jeff Wheeler <[email protected]>
> any subscriber access platform, must be able to deal with the threat
> of DoS attacks.
I definitely agree with this, and I've been pondering it a bit over the
last couple of days. (BTW, do you forsee this being an issue for IPv4 and
IPv6, or 'mostly' an IPv6 issue, because of the very large address space?)
Anyway, thinking about this 'DoS using packets with source-addresses
scattered throughout the address space' issue, and trying to thoroughly
characterize the issue, there seem to me at a high level to be two, maybe
three, ways this can be a problem for LISP (other than the sheer number of
packets, which is already an issue even in non-LISP configurations).
The first is problems with the cache (primarily through valid and useful
entries being displaced by 'useless' entries, although I suppose if one has a
cache which tries to retain all the mappings one can see, the growth in the
cache could also be a problem), the second is the volume of control traffic,
and the third is the volume of 'no-match' traffic (i.e. packets sent out from
the site to an ITR for which the ITR does not have a mapping) - depending of
course on how the ITR handles such packets (if it simply drops such packets,
that's not a big problem.) Did I miss one (at this level)?
To analyze the problems with the cache a little deeper, there are two parts
to the problem: negative cache entries (i.e. entries which say 'there is no
mapping for this range of the space') and positive entries which are not
'real' (as in, for places this site would normally communicate with, which
serve only to expand the size of the working set). The former can be handled
by limiting the cache size, and preferentially discarding and/or not
installing 'negative' entries when the cache is large (i.e. under DoS
attack). (This could cause a problem in the next stage - control traffic -
though, but I will talk about that later on.)
Non-'real' positive entries are somewhat harder to deal with, but there seem
to be some fairly simple strategies which can ameliorate the attack. For
example, one would be to segment the cache into two portions, the 'main'
cache and a 'rabbit garden' cache. Entries would only be promoted from the
second to the first after being used more than N times (where N is a small
integer, e.g. '2'). On a full cache, and needing to evict an older entry to
make room for a new one, the new cache entry would only turf entries from the
'rabbit garden' section. (Entries in the 'main' cache would only be removed
on timeout.) Clearly, a DoS attack will only thrash the 'rabbit garden'
portion of the cache, leaving the main cache unaffected.
The only difficulty comes when there is an attempt to communicate with a new
legitimate destination; the cache entry for that may get evicted before it
can be promoted to the 'main' cache. Unless the DoS attack is running quickly
enough to flush the entire 'rabbit garden' in less than one RTT for the new
destination (after which a second packet to that destination will promote the
entry to the 'main' cache), it should make it through. If not... actually,
now that I think about it, I have come at this from the wrong end, because if
one has the control traffic rate limited (as I think one must, see below),
_iff_ one can protect legitimate control requests (and I think one might be
able to - see below), then you can pretty much guarantee that the legitimate
mapping will be around long enough to be promoted.
The obvious approach on the control traffic, to prevent a flood of incoming
DoS traffic from creating a flood of control traffic, is to rate limit it
(e.g. increment a counter every time a mapping request is sent, and once the
counter has reached M, where M would be say 1,000, send no further mapping
requests - the counter is cleared once every second). (In fact, I think there
might already be a rate limitation on the generation of mapping requests?)
This will likely have a negative effect on real traffic from the site,
though, although I can imagine a variety of heuristics to try and select out
'real' traffic, and treat it preferentially. E.g. once the rate limit has
been reached, examine the packet, and if it is a TCP SYN (and not a SYN-ACK)
ignore the rate-limit - this is an outgoing TCP connection request, and
should be OK. Incoming real requests would still get drowned, but for many
sites, which are primarily consumers, and not providers, this would perhaps
be adequate. To protect incoming requests... hmmm, I'd want to go look and
see how large servers protect themselves now, see if there's something there
that can be copied.
Alternatively, one could, in the cache managment (above) retain negative
cache entries which are 'large', and use them to reduce the control traffic
that way (since each 'large' negative cache entry will soak up a chunk of the
DoS traffic).
At another level, one can take advantage of the fact that one has to 'bounce'
traffic off a machine inside the site to attack the ITR mapping mechanisms; if
one can 'harden' the host against such attacks, then you can kill the problem
that way.
I dunno, I'm not sure that this is an insoluble problem - _if_ one puts ones
mind to solving it. I agree that it is an important issue, though.
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
