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
