Re: [lisp] Restarting last call on LISP threats

[Marc Binderberger <[e-mail]>]

Hello Florin et al.,

interesting discussion and I think some aspects should continue to be 
discussed. But I start wondering: where is this thread heading? It doesn't 
seem to move forward with respect to the "last call" topic :-)

Florin, your reply seems to indicate that Ronald's scenario is a valid attack 
as you describe mitigation strategies. But is Ronald's scenario really _new_ 
with respect to the draft?  It seems to be covered by section 4.2/4.3.1.1 (?).

If the opinion is that Ron's scenario is not covered by the draft yet then do 
we need additional text in the draft?  Any proposal, Ron?


Myself I'm expecting from the draft that it provides an overview of the 
potential problems and some attack vectors to stimulate ideas. I do not 
assume that the level of details in the draft and the "relevance" of the 
attack correspond - what is relevant or not may depend on whom you ask. 


Thanks & Regards,
Marc



On Wed, 28 May 2014 07:50:35 +0200, Florin Coras wrote:
> Hi Ron,
> 
> It turns out that just doing a flat scan of the EID-prefix space, i.e., 
> using as source EID an IP in each existing EID-prefix, has the most 
> damaging consequences (see fig. 5 in [1]). This, if you contrast it with 
> the case when you try to craft packets whose replies (coming from 
> intra-domain sources) will always generate misses in the xTR under attack.
> 
> If the attack intensity (attack packet rate to legitimate traffic rate 
> ratio) is high, say above 0.01, you are right to assume that such an attack 
> could cripple an xTR and generate lots of misses. However, as we mention in 
> the paper, some simple solutions could be set in place to avoid this. For 
> instance:
> 
> 1) When the attack is detected (due to the higher than normal miss rate), 
> the most important entries in the cache, the most popular (say, Google, Fb, 
> Amazon ..) can be protected from eviction. Thereby, on the one hand, set up 
> flows won't have their entries evicted and on the other, this set of 
> entries will ensure that a very large part of the new outgoing flows will 
> cache hit.
> 
> 2) Just add more memory! Besides the TCAM in the xTR we could use a large 
> second level memory able to cache the whole EID address space.  
> Alternatively, you could imagine having an xTR per site, capable of holding 
> the whole EID address space, that could act as default for packets that 
> miss in all the other sub-provisioned xTRs.
> 
> [1] http://arxiv.org/pdf/1312.1378v2.pdf
> 
> Florin
> 
> 
> On 05/28/2014 12:45 AM, Ronald Bonica wrote:
>> Hi Paul,
>> 
>> The attack scenario that I envision is slightly different from the on that 
>> you describe below:
>> 
>> - LISP is widely deployed. Tens of thousands of XTRs are deployed 
>> world-wide. The mapping system data base contains hundreds of thousands of 
>> EID prefixes.
>> - The attack stream is large
>> - Each packet in the attack stream has a unique source LOC
>> - All packets in the attack stream have the same destination LOC. This LOC 
>> represents the XTR under attack.
>> - Each packet in the attack stream has a destination EID that will cause 
>> it to reach a valid destination (i.e., a destination that will respond). 
>> However, all packets in the attack stream don't have the same destination. 
>> The attack stream is spread out across multiple valid EID destinations to 
>> make it less detectable.
>> - Each packet in the attack stream has a carefully chosen source EID. It 
>> is chosen to maximize the ratio of attack packets to map-requests.
>> 
>> One attack stream attacks an XTR. Multiple simultaneous attacks against 
>> multiple XTRs can DoS the mapping system, itself.
>> 
>> A PxTR probably won't generate this attack stream. However, an attack tool 
>> might.
>> 
>> Hope this helps.
>> 
>>                                                              Ron
>> 
>>> -----Original Message-----
>>> From: Paul Vinciguerra [mailto:[e-mail]]
>>> Sent: Monday, May 26, 2014 3:28 PM
>>> To: Ronald Bonica; Joel M. Halpern; Damien Saucez
>>> Cc: Roger Jorgensen; LISP mailing list list
>>> Subject: RE: [lisp] Restarting last call on LISP threats
>>> 
>>> Every host on the Internet is subject to a DoS attack.  An xTR is no more 
>>> so.  I
>>> am also not clear on how a DoS attack on an xTR would create any more risk
>>> than an attack directly against the mapping system.
>>> 
>>> Joel describes Ronald's scenario of an attack where a large stream of 
>>> packets
>>> with different inner source addresses to an ETR.  I don't call this an 
>>> attack.  I
>>> call this our steady-state.  These would be the PxTR's we operate across 
>>> the
>>> US.  The PxTR's on the beta-network are no different.  We take in packets
>>> from anywhere.  This is a "Free" attacker if you will.  All that really 
>>> means is
>>> that you do not have to incur the computational cost of encapsulating the
>>> packet.
>>> 
>>> I would defer to Dino and others on the list, but I do not believe that 
>>> the ETR
>>> does a reverse lookup on every packet.  At least that is not the behavior 
>>> we
>>> observe.  What we see happen is that the packet is decapsulated and sent 
>>> to
>>> the destination.  If a valid destination host responds, then the ITR does 
>>> a
>>> map-request for the reply packet.  There is not a 1:1 relationship between
>>> the number of packets and the number of map-requests.
>>> 
>>> Map-replies for IP addresses return prefixes. These prefixes can cover 
>>> larger
>>> address spaces than the map-request and limit the number of future map-
>>> requests needed.
>>> 
>>> Can you provide more specific details on how you see the xTR rendering the
>>> mapping system unusable?
>>> 
>>> For what its worth, I still support the decision for last call and not to 
>>> place
>>> mitigations within the document.  Without knowing the specifics of a
>>> configuration and implementation, that just leads to a false sense of 
>>> security.
>>> 
>>> 
>>> ________________________________________
>>> From: lisp [[e-mail]] on behalf of Ronald Bonica
>>> [[e-mail]]
>>> Sent: Monday, May 26, 2014 11:57 AM
>>> To: Joel M. Halpern; Damien Saucez
>>> Cc: Roger Jorgensen; LISP mailing list list
>>> Subject: Re: [lisp] Restarting last call on LISP threats
>>> 
>>> Inline.....
>>> 
>>>> -----Original Message-----
>>>> From: Joel M. Halpern [mailto:[e-mail]]
>>>> Sent: Monday, May 26, 2014 11:47 AM
>>>> To: Ronald Bonica; Damien Saucez
>>>> Cc: Roger Jorgensen; LISP mailing list list
>>>> Subject: Re: [lisp] Restarting last call on LISP threats
>>>> 
>>>> Top posting to make sure I am understanding:
>>>> 
>>>> You asssert that any xTR is subject to a DoS attack.  And that such a
>>>> DoS attack can render the mapping system unusable.
>>> [RPB]
>>> Exactly!
>>> 
>>>> It targeting an ITR, this would need to be from within ths cope the ITR
>>> serves.
>>> [RPB]
>>> I don't understand this sentence. Please try again.
>>> 
>>>> I believe that is discussed.
>>> [RPB]
>>> Given that I don't understand the sentence above, I have no idea if this
>>> sentence is true.
>>> 
>>>> If I have connected the dots correctly, the attack you are
>>>> contemplating is sending a large stream of packets with different
>>>> inner source addresses to an ETR.  This would prompt the ETR to check
>>>> with the mapping system about each and every address.
>>> [RPB]
>>> Exactly!
>>> 
>>>> If I have understood this properly, while there are several very
>>>> effective mitigations, that does not change the basic message that
>>>> this is an attack, and as such ought to be described in the threats
>>> document.
>>> [RPB]
>>> Even if there are effective mitigations, the attack should be described.
>>> 
>>> However, I am not convinced that an effective mitigation exists.
>>> 
>>>>    There are clealry a number of variations on this attack.
>>> [RPB]
>>> True!
>>> 
>>>    For example, using
>>>> the same outer source address makes mitigation easier, while using
>>>> different outer source addresses either requires a bot-net or a large
>>>> unchecked BCP38 hole (and those can be used for MANY attacks on many
>>>> systems.)  Both presumably should be described.
>>> [RPB]
>>> Yes, both should be described.
>>> 
>>> Also, recall that large BCP38 holes exist in today's internet.
>>> 
>>>> Have I captured your request accurately?
>>> [RPB]
>>> Pretty much.
>>> 
>>> Thanks for taking the effort.
>>> 
>>>                      Ron
>>> 
>>>> Yours,
>>>> Joel
>>>> 
>>>> On 5/26/14, 1:06 AM, Ronald Bonica wrote:
>>>>> *From:*Damien Saucez [mailto:[e-mail]]
>>>>> *Sent:* Friday, May 23, 2014 9:07 AM
>>>>> *To:* Ronald Bonica
>>>>> *Cc:* Dino Farinacci; Roger Jorgensen; LISP mailing list list
>>>>> *Subject:* Re: [lisp] Restarting last call on LISP threats
>>>>> 
>>>>> Hello Ronald,
>>>>> 
>>>>> On 22 May 2014, at 22:57, Ronald Bonica <[e-mail]
>>>>> <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>      Dino,
>>>>> 
>>>>>      Today's Internet is not as fragile as you think. This mail 
>>>>> traversed
>>>>>      many routers between my house and yours. If those routers are
>>>>>      well-managed, there is nothing that I can do from my house that 
>>>>> will
>>>>>      cause any of those routers to consume control plane resources.
>>>>>      Therefore, there is nothing that I can do from my house that will
>>>>>      cause a DoS attack against those routers' control planes.
>>>>> 
>>>>> We tend to disagree with that, for example you have ICMP today...
>>>>> 
>>>>> */[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't make
>>>>> a very good routing protocol. That's why we don't use it for
>>>>> routing. By contrast, LISP map-request messages are susceptible to
>>>>> DoS attacks and they do carry routing information./*
>>>>> 
>>>>> 
>>>>> 
>>>>>      In LISP, separation between the forwarding and control plane is
>>>>>      lost. As a matter of course, forwarding plane activity causes
>>>>>      control plane activity. Since forwarding plane bandwidth exceeds
>>>>>      control plane bandwidth, DoS attacks against the control plane are
>>>>>      possible.
>>>>> 
>>>>>      In order to be complete, the threats document must describe the DoS
>>>>>      threat. It should also describe mitigations, if any exist.
>>>>> 
>>>>> DoS is already explained and the definition given:
>>>>> 
>>>>> " A Denial of Service (DoS) attack aims at disrupting a specific
>>>>> 
>>>>>      targeted service either by exhausting the resources of the
>>>>> victim up
>>>>> 
>>>>>      to the point that it is not able to provide a reliable service
>>>>> to
>>>>> 
>>>>>      legit traffic and/or systems or by exploiting vulnerabilities to
>>>>> make
>>>>> 
>>>>>      the targeted service unable to operate properly.
>>>>> 
>>>>> "
>>>>> 
>>>>> is covering the case you mention.
>>>>> 
>>>>> */[RPB] /*
>>>>> 
>>>>> */You might want to add the following details to section 5.2:/*
>>>>> 
>>>>> *//*
>>>>> 
>>>>> -A DoS attack can be launched by anybody who can send a packet to
>>>>> the XTR's LOC
>>>>> 
>>>>> -DoS attacks can render an XTR inoperable
>>>>> 
>>>>> -DDoS attacks can render the mapping system inoperable.
>>>>> 
>>>>> This is what differentiates LISP from today's routing system.
>>>>> 
>>>>>                                         Ron
>>>>> 
>>>>> Damien Saucez
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Ron
>>>>> 
>>>>> 
>>>>> 
>>>>>          -----Original Message-----
>>>>>          From: Dino Farinacci [mailto:[e-mail]]
>>>>>          Sent: Wednesday, May 21, 2014 6:58 PM
>>>>>          To: Ronald Bonica
>>>>>          Cc: Roger Jorgensen; [e-mail] <mailto:[e-mail]>
>>>>>          Subject: Re: [lisp] Restarting last call on LISP threats
>>>>> 
>>>>> 
>>>>>              The attacker sends a flow of crafted packets to the victim
>>>>>              XTR. Each packet
>>>>> 
>>>>>          is a well-formed LISP data packet. It contains:
>>>>> 
>>>>> 
>>>>>              - an outer IP header (LOC->LOC)
>>>>>              - a UDP header
>>>>>              - a LISP Header
>>>>>              - an IP header (EID->EID)
>>>>>              - payload
>>>>> 
>>>>> 
>>>>>          Just like a regular packet I can send to your home router 
>>>>> today.
>>>>>          So yes okay.
>>>>>          So let's continue. See comments below.
>>>>> 
>>>>> 
>>>>>              Each packet contains control plane information that is new
>>>>>              to the victim
>>>>> 
>>>>> 
>>>>>          Be more specific about what control information are in these
>>>>>          encapsulated
>>>>>          packets.
>>>>> 
>>>>> 
>>>>>              XTR. For example, the victim XTR has no mapping information
>>>>>              regarding
>>>>> 
>>>>>          either the source LOC or source EID prefix. Rather than 
>>>>> gleaning
>>>>>          this mapping
>>>>>          information from the crafted packet, the victim XTR sends a
>>>>>          verifying MAP-
>>>>>          REQUEST to the mapping system.
>>>>> 
>>>>> 
>>>>>              Assume that the attack flow is large (N packets per 
>>>>> second).
>>>>>              Assume also
>>>>> 
>>>>>          that the XTRs rate limit for MAP-REQUEST messages is less than 
>>>>> N
>>>>>          packets
>>>>>          per second. Has the attack not effectively DoS'd the victim 
>>>>> XTR?
>>>>> 
>>>>>          It caches the rate the rate the packets are coming in and
>>>>>          eventually stops
>>>>>          sending Map-Requests completely.
>>>>> 
>>>>>          It cannot stop the incoming rate of packets today just like a
>>>>>          roque BGP
>>>>>          attacker can send millions of packets per second to a peer
>>>>>          regardless if it
>>>>>          does or does not have the peer authentication key.
>>>>> 
>>>>> 
>>>>>              To make this attack work, every packet in the attack flow
>>>>>              may need to have
>>>>> 
>>>>>          a unique, spoofed, source LOC.
>>>>> 
>>>>>          An implementation can detect that after rate limiting 1000s of
>>>>>          such requests
>>>>>          are happening that it just stops operation.
>>>>> 
>>>>>          What if I sent a Juniper 20 million routes today?
>>>>> 
>>>>>          The Internet is very fragile and LISP IS NOT making it worse.
>>>>>          And in some
>>>>>          cases it is making it better with integrated techniques.
>>>>> 
>>>>>          Dino
>>>>> 
>>>>> 
>>>>>      _______________________________________________
>>>>>      lisp mailing list
>>>>>      [e-mail] <mailto:[e-mail]>
>>>>>      https://www.ietf.org/mailman/listinfo/lisp
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>