Re: [lisp] Restarting last call on LISP threats

Dino Farinacci <farinacci@gmail.com> Thu, 12 June 2014 15:37 UTC

Return-Path: <farinacci@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 9407F1A0127 for <lisp@ietfa.amsl.com>; Thu, 12 Jun 2014 08:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 cZLHUpImKeFF for <lisp@ietfa.amsl.com>; Thu, 12 Jun 2014 08:37:38 -0700 (PDT)
Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00BEE1A0113 for <lisp@ietf.org>; Thu, 12 Jun 2014 08:37:37 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id r10so1075478pdi.18 for <lisp@ietf.org>; Thu, 12 Jun 2014 08:37:37 -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=/g1lmVPlWKHSiZ3Y5Ps2ke6cl18fstqOMMIn2WiRAO0=; b=rM79JQIzyLBz+DzwJKkTs+VpU41NZRxOfuCdmB7xK+jNv7Pj6mIfVmwIDUi/d3IRj8 lLdydeDvPRtXV2qCngUkBHBpksd1U+5M/y/5o2KDOE9JbAU/DuwGdjailT7SomnCiZjb I38FJqUL6+OLKVYgafRhCx8kSmZ+LYbHFVLDb8Hx5Sg0znbPKF3oDQtJfV5Oo4JoXd8i gDB8XFgktDgqRBp+i055y1fFPC2mmoxN12G6VgRZeRT669zNhGvj3R0m5yFXBPKUxzKU LzvLTUfEItSlSz+1qUA/zzPV3uHY4KrQqC0eaD3Iu1np1luz0uCT16ZVtpdwg4khB09E cSnA==
X-Received: by 10.68.229.36 with SMTP id sn4mr13420401pbc.51.1402587457688; Thu, 12 Jun 2014 08:37:37 -0700 (PDT)
Received: from dino-macbook.wp.comcast.net (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id kn1sm4377335pbd.13.2014.06.12.08.37.36 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 08:37:36 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <47dad9120b114679bb0ec56976f4baa9@CO2PR05MB636.namprd05.prod.outlook.com>
Date: Thu, 12 Jun 2014 08:37:35 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8C1750E-51A8-4C97-AB71-C0B19A6E4D46@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> <47dad9120b114679bb0ec56976f4baa9@CO2PR05MB636.namprd05.prod.outlook.com>
To: Ross Callon <rcallon@juniper.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/yDydfyPiOxUSw41WnS9lmE3clms
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: Thu, 12 Jun 2014 15:37:39 -0000

But Ross I would like to clarify further. There are many issues with data packet gleaning. I think there are far less with control-plane packet payload gleaning since there are many more LISP designed control-plane mechanisms that can be used OUTSIDE of the data path.

Dino

On Jun 12, 2014, at 8:28 AM, Ross Callon <rcallon@juniper.net> wrote:

>> 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
> 
> This I agree with. I will go off and digest the rest.
> 
> Thanks, 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
>