Re: [lisp] Restarting last call on LISP threats

[Sharon Barkai <[e-mail]>]

Hi Roland, Got it. Tnx.

 I thought that since the mapping is in the underlay, then existing underlay protections apply.. unless "outerlay" elements use the XTRs in order to indirectly attack the mapping service.
I thought that's what you meant.. 

And that the problem of why this is not a trivial throttling is because the mapping itself is distributed so no one place can identify the XTR being leveraged for the attack. That's why I thought keeping an mapping internal lcaf/counter-Schema can help.

But I think Joel is correct, and let's first phrase the problem.
Thanks for the clarification.

--szb

On May 27, 2014, at 7:17 AM, "Ronald Bonica" <[e-mail]> wrote:

Hi Sharon,

We may be talking about an XTR that is sick due to a bug or attack. We may also be talking about an attacker that isn't an XTR at all, just impersonating one.

                                                                             Ron


> -----Original Message-----
> From: Sharon [mailto:[e-mail]]
> Sent: Monday, May 26, 2014 12:06 PM
> To: Joel M. Halpern
> Cc: Ronald Bonica; Damien Saucez; Roger Jorgensen; LISP mailing list list
> Subject: Re: [lisp] Restarting last call on LISP threats
> 
> Joel, thanks for clearing.
> It was hard to follow.
> 
> If the challenge is for a distributed mapping system to keep track and protect
> itself from a "sick" xTR, sick because of a bug or an attack..
> Then perhaps we could maintain mapping lookup per sec counters per xTR in
> the mapping. It adds some overhead to the mapping, but doesn't slow down
> forwarding. Can be aggregated by map servers for efficiency.
> 
> --szb
> 
> On May 26, 2014, at 8:46 AM, "Joel M. Halpern" <[e-mail]>
> wrote:
> 
> 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.
> 
> It targeting an ITR, this would need to be from within ths cope the ITR serves.
> I believe that is discussed.
> 
> 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.
> 
> 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.  There are clealry a
> number of variations on this attack.  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.
> 
> Have I captured your request accurately?
> 
> 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