Re: [lisp] Restarting last call on LISP threats

"Darrel Lewis (darlewis)" <darlewis@cisco.com> Wed, 11 June 2014 22:28 UTC

Return-Path: <darlewis@cisco.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 881071B289B for <lisp@ietfa.amsl.com>; Wed, 11 Jun 2014 15:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 0Jwmx4yZkx9E for <lisp@ietfa.amsl.com>; Wed, 11 Jun 2014 15:28:42 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1774B1A02ED for <lisp@ietf.org>; Wed, 11 Jun 2014 15:28:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2867; q=dns/txt; s=iport; t=1402525722; x=1403735322; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DacJ2RA6N01UNcC6aQjIqVZ1DyQdNllH0WUi47AFI/s=; b=OMbRp1Sm4zJcvqyojkME/+kXa/OwZ18Ul9RZ+Al9eDu6nyI/+MKMvbbN a09R4WEENpLPu2j0afQP2ygreHQpCs/BBCbSw6CE76gYJoyE1o8MmJGPQ foDHtwWa5fd7T7RyIDUiwSOdzY/zVVBbF/jMgNSg5sWoCK7PD1hqxJB7i k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqcFAMLXmFOtJV2c/2dsb2JhbABagw1SWapPAQEBAQEBBQGRX4c8AYEJFnWEAwEBAQMBAQEBawsFBwQCAQgRBAEBAScHIQYLFAkIAgQOBYguAwkIDcooDYYTEwSFXIZagUslMwcGgyWBFgSYNYF5jVCFe4M8gW1C
X-IronPort-AV: E=Sophos;i="5.01,460,1400025600"; d="scan'208";a="52327829"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 11 Jun 2014 22:28:41 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s5BMSfwl018863 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jun 2014 22:28:41 GMT
Received: from xmb-rcd-x15.cisco.com ([169.254.5.249]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 11 Jun 2014 17:28:40 -0500
From: "Darrel Lewis (darlewis)" <darlewis@cisco.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Thread-Topic: [lisp] Restarting last call on LISP threats
Thread-Index: AQHPhcR+s8rmtoayqUOOlE1jvvjGFA==
Date: Wed, 11 Jun 2014 22:28:39 +0000
Message-ID: <3F96F55B-ED0A-436A-97F5-2196B81A1B91@cisco.com>
References: <d690563db20d4fca945b810a14f37090@CO1PR05MB442.namprd05.prod.outlook.com> <B3A9D234-A6A2-45DC-B8FA-623B3A86DCE8@gmail.com> <a7c188aabbfe41ef80645d2ee1d6df99@CO1PR05MB442.namprd05.prod.outlook.com> <53973DAE.4050000@joelhalpern.com>
In-Reply-To: <53973DAE.4050000@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.119.83]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <06C0B1794AC280489D20C5EBA6CFEE44@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/5QVraKCGH9XOafFln7VzwME8gVc
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, 11 Jun 2014 22:28:43 -0000

On Jun 10, 2014, at 10:17 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

> I think that the treat scopes for the two cases are different.  Gleaning new RLOCs is clearly a significant risk.
> Gleaning the liveness of an RLOC from the fact that it appears to be talking to you is a much lower risk.  With a much higher benefit.  I have no problem with noting that there is a risk, albeit somewhat complex.  But it should not be viewed in the same manner.  (All security is a matter of costs and benefits.)

And to add one more bit of detail here, gleaning the liveness of an RLOC who’s status bit has changed can be (and is in our IOS implementation) verified by a rate-limited RLOC Probe.

-Darrel

> 
> Yours,
> Joel
> 
> On 6/10/14, 1:06 PM, Ronald Bonica 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