> > The discussion was IMHO too much focused on gleaning. LISP is made for a > large number of EID networks. If e.g. someone scans the address ranges of > an ISP and the PiTR(s) of the ISP have no forwarding entry then they need to > send a map-request - a task typically done in control plane. Punting packets > from data to control plane may saturate the punt channel for a time T, during > which a legitimate request may not be processed. [RPB] Agreed. The attack scenario that I describe in my previous message relies neither on gleening nor source address spoofing.
> > To be fair, even for a large number of EID networks (e.g. lots of /29) the > period T should not be more than several minutes (my guess, assuming 1k > lookup per second) and it would not affect already established flows, only > the establishment of new flows during the time T, assuming the (P)iTR can > hold all the map-cache entries. > [RPB] Also agreed. We should say something in a threats document about the relationship between period T and the size of memory available for the map-cache. > > Regards, Marc > > > > On Mon, 26 May 2014 15:34:31 -0400, Joel M. Halpern wrote: > > It sounds like the PxTRs you are using are already implementing > > sensible mitigations. But the base document does not actually call this > > out. > > > > On the base document, the ETR can do gleaning (and by some readings > > mgiht be being encouraged to do so). Because of the security threat > > from gleaning, and because the Etr wants to avoid the delay on > > returning traffic, nor use a false glean to direct returning traffic, > > there is text suggesting that the ETR would, immediately upon > > gleaning, check the information with the mapping system. > > > > That would mean that a packet flow to an ETR (which all nodes are, as > > you say, subject to) could become a significant load on the mapping > system. > > > > Making different choices about when to learn or verify entries changes > > that dramatically. But since the document does currently include the > > problematic behavior as legitimate, we need to document that it can > > cause problems. > > > > I am glad to hear that sensible implementations are already dealing > > with this well. > > > > Yours, > > Joel > > > > On 5/26/14, 3:28 PM, Paul Vinciguerra wrote: > >> 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 > >> [[email protected]] on behalf of Ronald Bonica > >> [[email protected]] 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:[email protected]] 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:[email protected]] *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 <[email protected] > >>>> <mailto:[email protected]>> 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:[email protected]] Sent: Wednesday, May 21, 2014 6:58 PM > >>>> To: Ronald Bonica Cc: Roger Jorgensen; [email protected] > >>>> <mailto:[email protected]> 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 > >>>> [email protected] <mailto:[email protected]> > >>>> https://www.ietf.org/mailman/listinfo/lisp > >>>> > >>>> > >>>> > >>>> _______________________________________________ lisp > mailing list > >>>> [email protected] https://www.ietf.org/mailman/listinfo/lisp > >>>> > >> > >> _______________________________________________ lisp mailing > list > >> [email protected] https://www.ietf.org/mailman/listinfo/lisp > >> > > > > _______________________________________________ > > lisp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
