Hi, On Sep 20, 2011, at 19:25 , Joel M. Halpern wrote:
> I believe his point is that > 1) We have a bunch of efforts to prevent spoofed source IP addresses (RLOCs) > in the net today. No tehy don't work perfectly, but we are working on > improving them. Assume for discussion they work. > 2) In the pwesence of LISP, under a variety of circumstances, it is possible > to get a packet with an apparently valid source RLOC (ITR IP address) but a > false Source EID. > 3) If this message is one which provokes a response, it can become an attack > on the spoofed inner EID. In particular, if the responses are noticeably > large than the requests, it becomes an amplifying reflection attack. > Yes I got the point. We have text in the threats draft for this. However, my point was that similar attacks can be carried out without LISP, so I think that on this side LISP is not opening any new security threat. Luigi > I believe we already have some text noting this. It is an unfortunate > consequence of the system. There are mechanisms that can be used to > ameliorate this, and I would hope that part of the experiment will be to > determine the relative costs and benefits of these mechanisms. > > Yours, > Joel > > On 9/20/2011 1:06 PM, Luigi Iannone wrote: >> 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] <mailto:[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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
