How about a simpler solution where an ITR at a site does not accept any UDP 4341 packets? So when a host that wants to spoof a source-EID with a valid RLOC in the outer header (so the uRPF check succeeds), can be caught by an non-compromised ITR.
Routers today can do this by uRPFing solely on the EIDs and since the RLOC belongs to the ITR itself, anyone at the site originated a packet with that RLOC will uRPF fail. Dino On Jul 24, 2011, at 1:32 AM, Patrick Frejborg wrote: > On Fri, Jul 22, 2011 at 7:04 PM, Dino Farinacci <[email protected]> wrote: >> Also, we do have data-plane gleaning in an ETR specified in the spec. So the >> packet could be accepted in an ETR, source-EID and RLOC gleaned, and when >> the SYN-ACK is returned, the map-cache can be verified. That way, you put >> the mapping database lookup in the place where it is already being done for >> other reasons. >> >> This is a tough problem. We will probably discuss this next week. Luigi has >> an agenda slot to discuss LISP related security threats. >> > > Dino, > I don't know if this is an appropriate moment to step forward and say > that this issue can be mitigated if you give up one of the LISP > principles, i.e. no changes to endpoint stacks. If LISP also supports > upgraded stacks then the enterprise have a choice - live with the risk > of a potential DoS attack or mitigate it for the most important > services by upgrading the stack at some endpoints. Of course, both > endpoints of a session needs to be upgraded to mitigate the attack. > By going after the stack we also gain a bunch of new incentives that > enterprises should be interested in. > Have a look at RFC 6306 but the new architecture that I'm thinking of > is best described in > http://www.cs.princeton.edu/research/techreps/TR-885-10 > LISP is the first important step towards this kind of architecture - > thus I don't want to lose it. > > Patrick _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
