Re: [lisp] Restarting last call on LISP threats

Ross Callon <rcallon@juniper.net> Wed, 18 June 2014 04:43 UTC

Return-Path: <rcallon@juniper.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 375421A0202 for <lisp@ietfa.amsl.com>; Tue, 17 Jun 2014 21:43:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 OFt1XskWbAik for <lisp@ietfa.amsl.com>; Tue, 17 Jun 2014 21:43:41 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523DC1A0172 for <lisp@ietf.org>; Tue, 17 Jun 2014 21:43:41 -0700 (PDT)
Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 18 Jun 2014 04:43:39 +0000
Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0954.000; Wed, 18 Jun 2014 04:43:38 +0000
From: Ross Callon <rcallon@juniper.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>, Ronald Bonica <rbonica@juniper.net>, Luigi Iannone <ggx@gigix.net>, Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [lisp] Restarting last call on LISP threats
Thread-Index: AQHPhM4EWF5k26Wu0Uq+sllpwWiB/5tqkxcAgAAEjYCAACWigIACpvUAgAAxObCAAAXAgIAADkgAgAACGoCABjg4AIAAB3yAgAAEWwCAAmYTUA==
Date: Wed, 18 Jun 2014 04:43:37 +0000
Message-ID: <20aa1d96f01541b4969eb27b9654ccfa@CO2PR05MB636.namprd05.prod.outlook.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>
In-Reply-To: <539F1582.3010406@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.12]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 02462830BE
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(13464003)(51704005)(189002)(43544003)(51444003)(479174003)(377454003)(199002)(24454002)(83322001)(1941001)(19580405001)(74662001)(19580395003)(74502001)(15975445006)(87936001)(76576001)(31966008)(50986999)(81342001)(21056001)(81542001)(99396002)(101416001)(76176999)(33646001)(83072002)(54356999)(77982001)(46102001)(85306003)(76482001)(20776003)(85852003)(74316001)(2656002)(93886003)(92566001)(86362001)(4396001)(79102001)(95666004)(64706001)(99286002)(80022001)(66066001)(105586002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB445; H:CO2PR05MB636.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rcallon@juniper.net;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/x4QS4YNHMrfbrwCzkmlh57XFWV4
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: Wed, 18 Jun 2014 04:43:44 -0000

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:lisp-bounces@ietf.org] 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: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