> 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
This I agree with. I will go off and digest the rest. Thanks, 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
