Re: [lisp] Restarting last call on LISP threats

[Ronald Bonica <[e-mail]>]

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