Luigi, I really, really hate trying to annotate things when people turn them into html instead of leaving them as plaintext. But since you insist:
________________________________ From: Luigi Iannone [mailto:[email protected]] Sent: Tuesday, September 20, 2011 12:31 AM To: Templin, Fred L Cc: Damien Saucez; [email protected] Subject: Re: [lisp] Source address spoofing by a node pretending to be an ITR? Hi Fred, On Sep 19, 2011, at 23:22 , Templin, Fred L wrote: [snip] The hidden idea behind the threat draft is "if we do not manage to make a system more secured than the current Internet, at least we must have a system that is not less secure." That's why I said: "But, perhaps a case can be made that on-path attacks are no more a matter for concern for LISP than they are for the non-LISP public Internet?". Still, if an off-path attacker can spoof the EID source address even if it cannot spoof the RLOC source address, the end result is a system that is less secure than the current Internet - right? Can you explain why? I would say the contrary. If an attacker cannot spoof RLOC it means that the DFZ is more robust - right? Ingress filtering can prevent the spoofing of an RLOC, but not necessarily the spoofing of an EID. If a middlebox produces packets that have correct RLOCs but incorrect EIDs, and if the ETR accepts them, then a reflection attack is enabled. One "funny" attack is by spoofing at the same time the EID and the RLOC. Without cryptography, there is no perfect solution to avoid spoofing. Your example with dynamic RLOC is interesting. If everything goes well, you should never have a TTL longer than the RLOC lease time. However, in the case the RLOC changes before the expiration, you will need SMR or version change implying the retrieval of the new mapping. But in this particular case, you also have a security threat that is a DoS... Do you see a clear way past these and other threats? Will it be the case that LISP and its ilk will be hard to secure and thus difficult to deploy? I think that by taking care of how LISP is deployed and how the features are used, it is possible to achieve the same level of security than today. Doing more is possible, but I am not sure that people are ready to have to deal with cryptography. For example, if you want to protect against spoofing, you can sign the packets (or part of) but then you need a way to know the key used to sign. Do you really want to go to that direction? Do I really want to go in the direction of requiring cryptography? I can't answer that unless you first tell me the intended domain of applicability. I don't think I have yet seen a use case analysis of the various scenarios where LISP xTRs and mapping systems would be deployed and used. There seems to be an unspoken assumption of deployment "in the public Internet", but what about Enterprise networks? What about MANETs? What about aviation networks? What about tactical military networks? What about cellular networks? What about home networks? That is the purpose of the deployment document. http://tools.ietf.org/html/draft-ietf-lisp-deployment-01 >From a brief look, that document appears to have quite a ways to go until it considers a wider variety of use cases such as we have addressed in RANGERS. The document also seems to carefully step around the MTU issue, as if it were a booby trap to be always on guard for. IRON (with SEAL) *solves* the MTU issue so that there is no longer any need to worry about it. Until LISP truly addresses the MTU issue (including accounting for the common case of operators misconfiguring link MTUs) all LISP-related documents will have to carefully dance around it. Fred [email protected]<mailto:[email protected]> Luigi
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
