If people agree with this, we could add text to reflect this extra check. Dino
On Jul 24, 2011, at 11:14 AM, Dino Farinacci wrote: > 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
