Re: [lisp] Restarting last call on LISP threats

[Luigi Iannone <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
>> 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:[e-mail]] 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 <[e-mail]> 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 <[e-mail]>
>>>> 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:[e-mail]] 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 <[e-mail]>
>> 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:[e-mail]]
>>>>>>>>>> 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
>>>>>>>>>> <[e-mail]>
>>>> 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:[e-mail]]
>>>>>>>>>>>> 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
>>>> <[e-mail]> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> lisp mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> lisp mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> lisp mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>>>