But Ross I would like to clarify further. There are many issues with data packet gleaning. I think there are far less with control-plane packet payload gleaning since there are many more LISP designed control-plane mechanisms that can be used OUTSIDE of the data path.
Dino On Jun 12, 2014, at 8:28 AM, Ross Callon <[email protected]> wrote: >> 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
