Hi Damien, > -----Original Message----- > From: Damien Saucez [mailto:[email protected]] > Sent: Wednesday, September 14, 2011 11:07 AM > To: Templin, Fred L > Cc: [email protected] > Subject: Re: [lisp] Source address spoofing by a node > pretending to be an ITR? > > Fred, > > You are totally right, obviously if you increase the number of > source addressees in a packet you increase the spoofing risk. > > In the threats draft, two different spoofing techniques are presented > (EID Spoofing and RLOC Spoofing). We then show the different > attacks that can be conducted with such spoofing.
Thanks for pointing out the threats document. In Section 4, it says: "We do not consider that LISP has to cope with [on-path] attackers.". Can you say more about that - for example, are you saying that on-path attacks will never happen, or that they can happen but are harmless and therfore not a matter for concern? I personally would prefer to not have to worry about on-path attacks, but I'm not sure that they can simply be ignored and pretend that they won't happen. 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? In any case, I'd be interested to know the rationale behind the Section 4 text. > 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? Thanks - Fred > Regards, > > Damien Saucez > > On 14 Sep 2011, at 10:15, Templin, Fred L wrote: > > > I have a question about source address spoofing by a > > node in the Internet pretending to be an ITR. The > > document says that the ETR: "MAY compare the inner > > header source EID address and the outer header source > > RLOC address with the mapping that exists in the > > mapping database". But a few questions arise from that. > > > > First, what if the ETR does not observe the MAY, and > > simply lets anonymous nodes pretend to be ITRs that > > send inner packets with spoofed EID source addresses? > > Those packets could result in a target node in the > > ETR's site sending replies to a victim node in the > > Internet. Is it OK to just let that happen? > > > > Second, what if the ETR does observe the MAY, but > > the ITR's RLOC source addresses change dynamically; > > perhaps due to > > > ity. Would the ETR be able to > > keep up with all of the RLOC address changes in real > > time? > > > > Third, I'm also wondering whether it is just end nodes > > that could pretend to be ITRs, or whether there is also > > a concern for middleboxes that can examine LISP exchanges > > and then pretend to be ITRs based on what they observe? > > > > I'm not trying to poke holes in the proposal; I'm just > > trying to understand if the LISP ITR/ETR relationship > > increases the attack surface for source address spoofing > > beyond the current state of affairs for the non-LISP > > Internet. Thanks in advance for any insights. > > > > Fred > > [email protected] > > _______________________________________________ > > lisp mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
