Hello Fred, On 14 Sep 2011, at 17:18, Templin, Fred L wrote:
> 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? No, these attacks exist, can be very harmful but unfortunately, except with some cryptography, I do not see how we can protect the system against on-path attackers. > > 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. As far as I know the current Internet is not protected against on-path attackers. To protect against them you either need ipsec, SSL or even application specific tricks. 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." > >> 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? Damien Saucez > > 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
