Hello Ronald,
On 22 May 2014, at 22:57, Ronald Bonica <[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... > 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. 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] >> 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] > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
