>> Could you describe precisely the attack you have in mind? The only >> think I can see is relying on the birthday paradox but that is a >> completely different story. > > If an attacker is on-path it could see the nonce's (assuming that the LISP > header is not encrypted, regardless of whether the data packet is encrypted). > This could be an issue if the attacker is physically on-path.
The source EID is encrypted so it can only see a cleartext source RLOC and can't associated it with anything. When we merge lisp-cryto logic with echo-noncing, one has to determine if an xTR should participate in echo-noncing if the payload is not decrypted properly. That is, if I get a echoed nonce back from an attacker for a nonce I know I have sent and set the E-bit, and I cannot decrypt the payload that comes from the attacker, then I don't believe any NEW reachability information about the RLOC. > This could also be an issue for attackers which are physically off-path if > gleaning is used, since an attacker could use a gleaning attack to > temporarily insert itself on-path, which in turn would allow it to see the > nonce. So by now we know there are many issues with gleaning. So we should document them and say they shouldn't be used for the general global Internet use-case. Dino > > Ross > > -----Original Message----- > From: lisp [mailto:[email protected]] On Behalf Of Damien Saucez > Sent: Thursday, June 12, 2014 8:08 AM > To: Ronald Bonica > Cc: LISP mailing list list > Subject: Re: [lisp] Restarting last call on LISP threats > > Hello, > > I am not sure I understand exactly what you are proposing. How can a > LISP router decide that a RLOC is done by simply receiving an ICMP > packet from an attacker (except with LSB that is discussed in Sec > 4.3.2.1. )? All the other techniques are triggered by the LISP > router and are protected by the nonce. > > Could you describe precisely the attack you have in mind? The only > think I can see is relying on the birthday paradox but that is a > completely different story. > > Damien Saucez > > On 10 Jun 2014, at 21:37, Ronald Bonica <[email protected]> wrote: > >> Dino, >> >> Exactly! So, assume the following: >> >> - LISP is deployed on the global Internet >> - An RLOC is mapped to some number of EID prefixes >> - For a subset of those EID prefixes, the above mentioned RLOC is preferred >> - An ITR receives a hint indicating that the RLOC is down (either through a >> LISP data packet or an ICMP message) >> >> The ITR will verify RLOC reachability (possibly by polling the RLOC). But >> until the ITR has receives a response to its poll, how should it behave? >> Should it continue sending traffic though the above mentioned RLOC? Or >> should it begin to send traffic through another RLOC, if one exists? I don't >> see a normative recommendation. >> >> However, both behaviors have their drawbacks and could be vectors for attack. >> >> >> Ron >> >> >>> -----Original Message----- >>> From: Dino Farinacci [mailto:[email protected]] >>> Sent: Tuesday, June 10, 2014 1:23 PM >>> To: Ronald Bonica >>> Cc: LISP mailing list list >>> Subject: Re: [lisp] Restarting last call on LISP threats >>> >>> As I keep saying Ron, you need to verify anything you intend to glean. The >>> spec says the gleaning is "a hint" and not gospel. >>> >>> Dino >>> >>> On Jun 10, 2014, at 10:06 AM, Ronald Bonica <[email protected]> wrote: >>> >>>> Hi Dino, >>>> >>>> Given that the LISP data packet or ICMP packet may be from an attacker, is >>> it even safe to glean that? I think not. >>>> >>>> >>>> Ron >>>> >>>> >>>>> -----Original Message----- >>>>> From: Dino Farinacci [mailto:[email protected]] >>>>> Sent: Tuesday, June 10, 2014 1:04 PM >>>>> To: Ronald Bonica >>>>> Cc: LISP mailing list list >>>>> Subject: Re: [lisp] Restarting last call on LISP threats >>>>> >>>>> >>>>> On Jun 10, 2014, at 9:57 AM, Ronald Bonica <[email protected]> wrote: >>>>> >>>>>> Earlier in this thread, we agreed that when LISP is deployed on the >>>>>> global >>>>> Internet, mapping information cannot be gleaned safely from incoming >>>>> LISP data packets. Following that train of thought, when LISP is >>>>> deployed on the global Internet, is it safe to glean routing locator >>>>> reachability information from incoming LISP data packets as described >>>>> in RFC 6830, Section 6.3, bullet 1. If not, I think that we need to >>>>> mention >>> this in the threats document. >>>>> >>>>> What you can glean is that the source RLOC is up, but you cannot >>>>> glean your path to it is reachable. >>>>> >>>>>> Given that ICMP packets are easily spoofed, when LISP is deployed on >>>>>> the >>>>> global Internet, is it safe to glean routing locator reachability >>>>> information from incoming ICMP packets as described in RFC 6830, >>>>> Section 6.3, bullet 2 and bullet 4. If not, I think that we need to >>>>> mention this in the threats document. >>>>> >>>>> What you can glean is that the source RLOC is up, but you cannot >>>>> glean your path to it is reachable. >>>>> >>>>> Dino >>>>> >>>> >> >> _______________________________________________ >> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
