Hi Roland, Got it. Tnx. I thought that since the mapping is in the underlay, then existing underlay protections apply.. unless "outerlay" elements use the XTRs in order to indirectly attack the mapping service. I thought that's what you meant..
And that the problem of why this is not a trivial throttling is because the mapping itself is distributed so no one place can identify the XTR being leveraged for the attack. That's why I thought keeping an mapping internal lcaf/counter-Schema can help. But I think Joel is correct, and let's first phrase the problem. Thanks for the clarification. --szb On May 27, 2014, at 7:17 AM, "Ronald Bonica" <[email protected]> wrote: 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:[email protected]] > 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" <[email protected]> > 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:[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
