Hi Joel, > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > Sent: Tuesday, September 20, 2011 10:25 AM > To: Luigi Iannone > Cc: Templin, Fred L; [email protected] > Subject: Re: [lisp] Source address spoofing by a node > pretending to be an ITR? > > 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.
That's correct. And, depending on the links on the path to the target a successful attack could truly clog some arteries. > 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. OK. The IRON family already has a solution which may or may not be adaptable for LISP. The IRON family also has a solution for MTU, which again may of may not be adaptable for LISP. Thanks - Fred [email protected] > 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
