Is the goal to actually understand whether LISP would be secure if deployed operationally on Internet-wide scale, or is the goal to satisfy some checklist issue in order to complete the work?
Ross -----Original Message----- From: lisp [mailto:[email protected]] On Behalf Of Joel M. Halpern Sent: Monday, June 16, 2014 12:04 PM To: Ronald Bonica; Luigi Iannone; Dino Farinacci Cc: LISP mailing list list Subject: Re: [lisp] Restarting last call on LISP threats Personally, I don't see any need to analyse mitigations to discuss classes of attacks. Yours, Joel On 6/16/14, 11:48 AM, Ronald Bonica wrote: > Ciao Luigi, > > If only it were that easy! In the threats document, we have two choices: > > - enumerate every attack that we can imagine > - document abstractions that describe broad classes of threats > > If we enumerate every attack, we will never finish. Therefore, we are forced > to document attack classes. IMHO, two attacks can be grouped together into a > class if both of the following conditions are true: > > - the attacks exploit the same features of the protocol > - the attacks can be addressed using the same mitigation > > If we don't understand mitigations, how will we ever group attacks into > classes? > > > Ron > >> -----Original Message----- >> From: lisp [mailto:[email protected]] On Behalf Of Luigi Iannone >> Sent: Monday, June 16, 2014 11:22 AM >> To: Dino Farinacci >> Cc: LISP mailing list list >> Subject: Re: [lisp] Restarting last call on LISP threats >> >> Hi Dino, >> >> fair point. I guess that Joel's point was on the fact that this specific >> thread >> should focus on the LISP threats document. >> >> Obviously this mailing list is the place where all technical discussions >> about >> LISP can take place. >> >> We should just fork the discussion. >> >> So to clearly separate what is related to the threats document and what are >> new proposals to alleviate some threats. >> >> ciao >> >> Luigi >> >> >> >> On 12 Jun 2014, at 18:23, Dino Farinacci <[email protected]> wrote: >> >>> I agree we should be focused Joel. >>> >>> But where else should we have open discussions about LISP? >>> >>> This mailing list membership is unique in that we have multiple vendors, >> operators, and users all in one place. Wouldn't that make for better >> protocols? >>> >>> Yes we have business to take care of but let's not stifle ideas and >> openness. Do you agree? >>> >>> Dino >>> >>> On Jun 12, 2014, at 9:15 AM, Joel M. Halpern <[email protected]> >> wrote: >>> >>>> I will repeat myself. >>>> Can we PLEASE not get into debating how we would solve the weakness >> in the protocol as documented. >>>> >>>> The question focus on is whether the protocol as specified has the >> behavior described, and if so does it result in the weakness described. >>>> If it does, that should be described in the threats document. >>>> if not, then it should not be so described. >>>> >>>> The presence, absence, validity, or possibility of solutions in other >> documents, operational practices, or people's heads, are not the topic for >> the WG at this time. >>>> >>>> PLEASE stay on topic, or we will never get our current work done. >>>> Which means that peoples wonderful ideas on how to do more or better >> will never get publsihed. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/12/14, 11:24 AM, Dino Farinacci wrote: >>>>> >>>>>>> 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 >>>>> >>> >>> _______________________________________________ >>> 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 _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
