Re: [lisp] Restarting last call on LISP threats

Hello Ronald,

On 22 May 2014, at 22:57, Ronald Bonica <rbonica@juniper.net> 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...

> 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.

Damien Saucez 

>                                                                                               Ron
> 
> 
>> -----Original Message-----
>> From: Dino Farinacci [mailto:farinacci@gmail.com]
>> Sent: Wednesday, May 21, 2014 6:58 PM
>> To: Ronald Bonica
>> Cc: Roger Jorgensen; lisp@ietf.org
>> 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
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp