Re: [lisp] Restarting last call on LISP threats

Damien Saucez <damien.saucez@gmail.com> Mon, 16 June 2014 17:18 UTC

Return-Path: <damien.saucez@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF31A000B for <lisp@ietfa.amsl.com>; Mon, 16 Jun 2014 10:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pA6c1t_1Bg9S for <lisp@ietfa.amsl.com>; Mon, 16 Jun 2014 10:18:51 -0700 (PDT)
Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C038D1A0113 for <lisp@ietf.org>; Mon, 16 Jun 2014 10:18:50 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id z12so5854674wgg.25 for <lisp@ietf.org>; Mon, 16 Jun 2014 10:18:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xSpuAc+nVVpPf71eUu1ME+o9mlEdMpwiiHfxRjG781I=; b=ZtiRwWy/8zjYH+EuruhucXklxnWxMClrYr1AisuwmfnB62SHD7Crry87zLhbqvhUDl xQWDjP92HHuxKQfli/I7gelz8MVN4SwCe5KhYFn9SCA5xwPE9hyZi39XpcXt6xrg0dcL Q76mr6w7xdJHvUo1H2GHiJrGwPqQjAWz/BAdCE0NIKIJnosUX4ijxWJK3VE0YNjdOZA8 q/pf+E3o3E3aqW1QqP1B1G19kS2Qhz8Ab83WQ9zVoryPLg1fo9j22Y2OoRa7PM/DxLZp 1Gn4fRl5QwBmBBVdw4mRPOFrRtt6VyuQRrgN1OTS6KAV+4YagLb8wunzn+xWCTtJoyRL 37CQ==
X-Received: by 10.194.91.144 with SMTP id ce16mr30112231wjb.18.1402939128018; Mon, 16 Jun 2014 10:18:48 -0700 (PDT)
Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id a1sm15815088wiy.15.2014.06.16.10.18.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 10:18:47 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Damien Saucez <damien.saucez@gmail.com>
In-Reply-To: <fbff111d0e3c49e881d50324817fc9e1@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Mon, 16 Jun 2014 19:18:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D4F04D1-43F4-4756-9941-F4499F2A1DA8@gmail.com>
References: <d690563db20d4fca945b810a14f37090@CO1PR05MB442.namprd05.prod.outlook.com> <B3A9D234-A6A2-45DC-B8FA-623B3A86DCE8@gmail.com> <a7c188aabbfe41ef80645d2ee1d6df99@CO1PR05MB442.namprd05.prod.outlook.com> <E0485205-9FCD-46FC-B852-06259334A47C@gmail.com> <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com> <A2225E25-FE9E-4F97-B86F-9C078BB6A312@gmail.com> <db040d02b9a3402c9e53e1ae6374b2bb@CO2PR05MB636.namprd05.prod.outlook.com> <BEA94770-F16C-449E-BA44-3FC8E5DE1292@gmail.com> <5399D22A.2040207@joelhalpern.com> <5CAAEAE6-AF3E-4E27-8D73-FA8A64520379@gmail.com> <DB53B8D4-8E0E-4DEF-BE7A-579FD679EB66@gigix.net> <8f3ee88f9b9649359d5222d324568e07@CO1PR05MB442.namprd05.prod.outlook.com> <539F1582.3010406@joelhalpern.com> <fbff111d0e3c49e881d50324817fc9e1@CO1PR05MB442.namprd05.prod.outlook.com>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/EHNipBrqouSXOBsnxN6C74mhKco
Cc: LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] Restarting last call on LISP threats
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jun 2014 17:18:53 -0000

Hello Ron,

If ever a mitigation introduces a new threat, it does not mean that
it is impossible to make threat categories.

Actually, if a threat can be put in one category, the threat on the
mitigation can correspond to another.  That does not weaken the
document.

So all what we need is to be able to construct a complete threat
categorisation.

Thank you,

Damien Saucez 


On 16 Jun 2014, at 18:39, Ronald Bonica <rbonica@juniper.net> 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:jmh@joelhalpern.com]
>> 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:lisp-bounces@ietf.org] 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 <farinacci@gmail.com> 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 <jmh@joelhalpern.com>
>>>> 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:lisp-bounces@ietf.org] 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 <rbonica@juniper.net>
>> 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:farinacci@gmail.com]
>>>>>>>>>> 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
>>>>>>>>>> <rbonica@juniper.net>
>>>> 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:farinacci@gmail.com]
>>>>>>>>>>>> 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
>>>> <rbonica@juniper.net> 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
>>>>>>>>> lisp@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> lisp mailing list
>>>>>>>> lisp@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> lisp mailing list
>>>>>>>> lisp@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> lisp mailing list
>>>>>>> lisp@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> lisp mailing list
>>>>> lisp@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>>> 
>>>> _______________________________________________
>>>> lisp mailing list
>>>> lisp@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp