Hi Ron, I tend to agree with Joel on the fact that to class attacks we do not need the mitigations.
Yet, I agree that if a possible mitigation for a threat can introduce another threat then this induced threat should be document. ciao Luigi On 16 Jun 2014, at 18:39, Ronald Bonica <[email protected]> wrote: > Joel, > > IMHO, there is a very distinct need. > > As we have seen previously in this email thread, some mitigations introduce > new threats. For example, the ITR's self-imposed rate limit on map requests > mitigates one threat and introduces another. > > If we don't discuss mitigations at all, we sweep a very important fact under > the carpet. > > > > Ron > >> -----Original Message----- >> From: Joel M. Halpern [mailto:[email protected]] >> 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
