> 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
