Re: [lisp] [Ila] Securing pull-based ID/LOC caches
Hi Tom Thank you very much for your feedback, please see inline: On Fri, Mar 23, 2018 at 12:46 PM, Tom Herbert wrote: > On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos > 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. > Agreed, as we point in the short paper alternative LISP deployment models are possible [draft-rodrigueznatal-ila-lisp-00] if the assumptions described in the paper do not hold. >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. > > We consider it a reasonable assumption, particularly for data-center and 5G scenarios. > 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. > > The paper focuses on source IP addresses but it can be trivially adapted to identify users using any information in the packet headers or from the network infrastructure. 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. > The threshold determines what is and what is not an attacker, if they are below T then this means that they are not overflowing the control-plane channel. In other words, T is related to the maximum throughput of this channel. > > 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. > > In my view this is orthogonal. You pick T (the threshold) so that it determines the maximum throughput of your control-plane channel. If they are below T then you have enough resources to accommodate all control-plane messages. 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. > Yes, but LFU-A or ARC mechanisms require attackers to generate as much traffic to unpopular destinations as the popular destinations are receiving. If this happens in your network this roughly means that you have more traffic from attackers than from legitimate users. Then what is the 'legitimate traffic'? Either you fix your network or you serve what your users want. We have seen over and over that traffic is a long-tail distribution, some destinations are very popular while many other destinations are not popular. The same applies to the pages accessed by a computer program, etc. This is the underlying reason why caches are so prevalent in computer science. With long-tail distributions they are very efficient in terms of resource consumption. >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 sen
Re: [lisp] [Ila] Securing pull-based ID/LOC caches
I believe we have to spec out how CMS could work in more detail and try different fields of the IP header for input to different hash functions to see if the needle (good actors) can get through the haystack (bad actors). But agree if bad actors are spoofing good actors there is no way to tell. Many of us have been thinking about how to use Proof of Work mechanisms so if a bad actor had to do more work to send a packet it could slow down the DoS attack. But just early thoughts. Dino > On Mar 23, 2018, at 11:46 AM, Tom Herbert wrote: > > On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos > 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 >> i...@ietf.org >> https://www.ietf.org/mailman/listinfo/ila >> > > ___ > ila mailing list > i...@ietf.org > https://www.ietf.org/mailman/listinfo/ila ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] [Ila] Securing pull-based ID/LOC caches
On Thu, Mar 22, 2018 at 9:13 AM, Albert Cabellos 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 > i...@ietf.org > https://www.ietf.org/mailman/listinfo/ila > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] New name for upcoming LISP -OAM- document
HI all, We think that we can move on as planned. The new document will be named "Considerations on LISP Mobility, Deployment and Traceroute”. Since the text is coming from existing docs authorship will be preserved. Albert is the appointed editor and will hold the pen. Because the text has been already thoroughly reviewed in the past we expect to make rapid progress with this document. Ciao Joel & Luigi > On 19 Mar 2018, at 16:25, Luigi Iannone wrote: > > Hi All, > > during today f2f meeting concern has been expressed about the name to use for > the document that will collect what is neither data-plane nor control-plane. > > The name OAM was found not accurate because the document will not cover all > of what is normally in a OAM document. > > The suggested name is “LISP Mobility, Deployment and Traceroute > considerations”. > > The chairs would like to hear from the mailing list if there is any objection > or you have a better name to suggest. > > Please send an email by the end of the week. > > Thanks > > Jole and Luigi ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
