Re: [lisp] Restarting last call on LISP threats

[Paul Vinciguerra <[e-mail]>]

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