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. 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… 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
