Re: [Ila] Securing pull-based ID/LOC caches

[Tom Herbert <[e-mail]>]

On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos
<[e-mail]> wrote:
> Hi all
>
> I am attaching a short paper describing a solution for control-plane
> denial-of-service & overflowing attacks against pull-based ID/LOC caches.
> The solution is based on implementing a per-source rate-limiter at the xTR
> using an efficient Count-Min Sketch structure.
>
Hi Albert,

Thank you for forwarding the paper. It is an interesting read!

I have a few comments:

>From the paper: "In LISP the mapping from the overlay namespaces can
be done using two mechanisms."

I believe a third mechanism is exists in secure redirects. This is
akin to ICMP redirects where a network router informs a sender that
there is a better path. This is sort of a hybrid of the pull and push
models.

>From the paper: "It is worth noting that this solution assumes that
spoofing source addresses is not possible inside the LISP site". That
is a big assumption and I'm not sure it will be generally true.

Even if if spoofing is enabled, trying to identify bad guys by source
address is still precarious. Consider that there could be complex
downstream networks of LISP that are possibly behind NAT, delegated
prefixes, VMs sharing common server IP address, etc.

You might also want to consider the possibility of a distributed
denial of service attack where the attacker uses many system to attack
a cache where no individual systems sends a high enough rate of
packets to trip the rate limiting threshold. I imagine the code for an
attack on cache is pretty trivial-- little more than a simple loop
sending UDP packets to random destinations. This could very easily be
hidden in some downloaded app.

>From the paper: "Attackers generate (randomly) between 2 and 3 orders
of magnitude more control-plane messages than legitimate users.
Specifically, attackers generate a uniform random number in the range
of 1k-10k, legitimate users a range in 1-10 and the threshold T is set
to 1k"

The job of an attacker is blend in so that their traffic is
indistinguishable from users. If they know they know what the
thresholds are that raise suspicion then they'll adjust their attack
to avoid hitting the thresholds! In this case, for instance, they
could try a DDOS to avoid detection.

Caches also have other attack vectors. For instance, if an attacker
knows they hash algorithm and the cache scheme, they might be able to
launch and attack to prevent service to specific destinations by
targeting the hash buckets of the destination. This sort of attack
comes up a lot in traffic steering which is why all those schemes
requiring randomizing the hash key and occasionally rekeying.

>From the paper: "The main design rationale behind the proposed
solution is to detect and push-back attackers by rate-limiting them in
aggregating points"

Unless the identification of attackers is perfect (which again is what
attackers are working to prevent), at some point legitimate users will
get swept up in this and they will be subject to the same rate
limiting. In that case, what is the effect on them? For instance, are
they completely blocked sending packets for some period of time? How
would this situation be resolved?

Thanks,
Tom

> Albert
>
> _______________________________________________
> ila mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ila
>