Hi Fred, thanks for the effort….
About your middle box example, why this example is different any other reflection attack? The middle box must be somewhere in the network so that its traffic is not filtered due to the use of a specific source RLOC. But in that case you do not need LISP to carry out a reflection attack. Hence LISP does not introduce any security hole. Or I misunderstand something? Luigi On Sep 20, 2011, at 17:21 , Templin, Fred L wrote: > 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] > > Luigi >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
