Re: [lisp] Restarting last call on LISP threats

Luigi Iannone <ggx@gigix.net> Tue, 17 June 2014 08:43 UTC

Return-Path: <ggx@gigix.net>
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 790671A0329 for <lisp@ietfa.amsl.com>; Tue, 17 Jun 2014 01:43:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 c43mtZC6oMYT for <lisp@ietfa.amsl.com>; Tue, 17 Jun 2014 01:43:37 -0700 (PDT)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A4A1A0327 for <lisp@ietf.org>; Tue, 17 Jun 2014 01:43:37 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id cc10so6486407wib.1 for <lisp@ietf.org>; Tue, 17 Jun 2014 01:43:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=jvyZ4t0VD4/fCBrjsp59CgvGz6oR3OD2oJSyWyC2spA=; b=C2SGdf6R5ihJbC2kDLWoUGcIjTJXsqh02S989Xn2G0h+m4RsAxOQ0M0zqsffhDOdSD nzwTnK2n5HxPsCCWyo1adc3l/nWqs+lpwqnjWUcLvSLUlPYcKoHioB8Fs+9+/9fLe1/O uwUzt//YbYBClCiKCDuZv/X4ulXz7Fp4cGOp3XOyPm7/F6QUb/mVaZzYOF+Mpgoy9uHo zLeTFqAUv4UDNfa61u+2sBC3GC5Wt/DSNhQcIY8B3Y/mZ+zm+MXDULEZObWls/thmw6q y2HjQabnGmvd+YKwiqiJtP6UWpYgZn9bfLIK119s1SzMtyteaRW+3u0XmuLRjbvyIA26 wLaw==
X-Gm-Message-State: ALoCoQmE/Vvzi5pxwlzhv2CsoG7VRtFQYmNf6DNxp++sAIRQjsOZF0J7RWXOTPfP8zcsojHQWtmE
X-Received: by 10.180.90.141 with SMTP id bw13mr34276487wib.23.1402994615699; Tue, 17 Jun 2014 01:43:35 -0700 (PDT)
Received: from ?IPv6:2001:660:330f:a4:5dd0:712c:105e:e755? ([2001:660:330f:a4:5dd0:712c:105e:e755]) by mx.google.com with ESMTPSA id h3sm22277465wjz.48.2014.06.17.01.43.34 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Jun 2014 01:43:34 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <fbff111d0e3c49e881d50324817fc9e1@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Tue, 17 Jun 2014 10:43:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EF2C75D-5C59-433E-B869-8E677666B8C1@gigix.net>
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/FF2LaJYV0DDMNrDRdoSiAiqo5-k
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: Tue, 17 Jun 2014 08:43:40 -0000

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 <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
>>>