Hi Luigi, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Luigi Iannone > Sent: Thursday, September 22, 2011 1:19 AM > To: [email protected] > Subject: Re: [lisp] Source address spoofing by a node > pretending to be an ITR? > > 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.
Yes it is; it allows off-path attackers to circumvent ingress filtering of the inner address even if they cannot circumvent ingress filtering of the outer address. Fred [email protected] > 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 > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
