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.
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.
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
