Re: [lisp] Restarting last call on LISP threats

["Joel M. Halpern" <[e-mail]>]

Both of course.
We as a working group agreed to separate the document tasks.  One 
document is to understand the threats, and others (because it is a 
continuing task) to address them.

Yours,
Joel

On 6/18/14, 12:43 AM, Ross Callon wrote:
> 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:[e-mail]] 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:[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
>>
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp
>