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" <jmh@joelhalpern.com> 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:damien.saucez@gmail.com]
> *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 <rbonica@juniper.net
> <mailto: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...
> 
> */[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:farinacci@gmail.com]
>        Sent: Wednesday, May 21, 2014 6:58 PM
>        To: Ronald Bonica
>        Cc: Roger Jorgensen; lisp@ietf.org <mailto: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 <mailto:lisp@ietf.org>
>    https://www.ietf.org/mailman/listinfo/lisp
> 
> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
> 

_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp