Re: [lisp] Restarting last call on LISP threats

Dino Farinacci <farinacci@gmail.com> Tue, 10 June 2014 19:47 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 732B81A02B0 for <lisp@ietfa.amsl.com>; Tue, 10 Jun 2014 12:47:07 -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 jrXzt-5f5K8Q for <lisp@ietfa.amsl.com>; Tue, 10 Jun 2014 12:47:06 -0700 (PDT)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3673F1A02A6 for <lisp@ietf.org>; Tue, 10 Jun 2014 12:47:06 -0700 (PDT)
Received: by mail-pd0-f170.google.com with SMTP id g10so6447211pdj.1 for <lisp@ietf.org>; Tue, 10 Jun 2014 12:47:05 -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=MTQqPd/I2TJLTIfOkMpwMitisFmxuts7zj8oCraikAY=; b=HbtbRV35PdmKxS8PuiTd0KxrHo8a2BqqVXulg24w2YpEf1CDI0gCLAm5vKcyOytfgC F/ZrMEGrTvBUnSbvTZVaQsGQdZG5/xjtpmYqhqEwihGH2j1rqXrDCEWTSOFNidowCRle oPO/B+B8ASLuO6MvbwCqJOOq83hpUatDznSai0+Ci3DrFr33/LaMb6FDoW54DjTKjMgX rQOFoKaDt/gp8+xFrunXl5PEmA9xHP7rjOyKNiTulkm0GkLSKpYr6btMzkM/lKq1RhBb tQX8+OhJg3MxCFyQ+uj0wzVBVtlwSY74SsamjKBjZuIiIiwPvYmMq6epNn1IsbV/8Ow0 Hc6w==
X-Received: by 10.66.251.136 with SMTP id zk8mr7569820pac.137.1402429625894; Tue, 10 Jun 2014 12:47:05 -0700 (PDT)
Received: from [192.168.1.174] ([207.145.253.66]) by mx.google.com with ESMTPSA id gg3sm70962417pbc.34.2014.06.10.12.46.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 12:47:05 -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: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Tue, 10 Jun 2014 12:46:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4E18B802-939B-4332-B800-AA3F7BEC5661@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>
To: Ronald Bonica <rbonica@juniper.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/o7puARtregnry_v4ifW4uS4NmAQ
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, 10 Jun 2014 19:47:07 -0000

> - An ITR receives a hint indicating that the RLOC is down (either through a LISP data packet or an ICMP message)

How? The way you say does not give any such indication.

> The ITR will verify RLOC reachability (possibly by polling the RLOC). But until the ITR has receives a response

It needs to verify the mapping first. It needs to determine if the source-EID in the data packet is associated with the RLOC that was in the data packet from the mapping database system.

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

Verify the mapping, then cache it locally as "verified" and then RLOC-probe the best priority RLOCs so you can see if they are reachable. You can do this before encapsulating packets to the RLOCs or concurrently. Depending if your implementation wants to take a leap of faith.

> However, both behaviors have their drawbacks and could be vectors for attack.

You did not describe the problem well, so no conclusions should be made.  ;-)

Dino

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