Re: [lisp] Restarting last call on LISP threats

Damien Saucez <damien.saucez@gmail.com> Thu, 12 June 2014 12:07 UTC

Return-Path: <damien.saucez@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 9EA6C1B285B for <lisp@ietfa.amsl.com>; Thu, 12 Jun 2014 05:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 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, HELO_EQ_FR=0.35, SPF_PASS=-0.001] autolearn=no
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 09Zams9NLttz for <lisp@ietfa.amsl.com>; Thu, 12 Jun 2014 05:07:50 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8D151B2824 for <lisp@ietf.org>; Thu, 12 Jun 2014 05:07:49 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id bs8so2833245wib.15 for <lisp@ietf.org>; Thu, 12 Jun 2014 05:07:48 -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=DHWzbuDcYDq+U0D58g7R0Yfkfuiee32NWDX0l115Y3Y=; b=opafUXPndt6NhVtM6lWvpZ3X0cbOlf4uHHDfZgqtnVi4amXpfW5wlkBz4RHvYFN8L+ 4QaCa7/j6z3Spo+0EdcVMvKlLIQmNeRN8yEoTnSq08bRV+WfKqfpP3PCJx/avRt2dnu7 P+IIyx0xFXp5CzgLIKpprURRFg229dVDeQRNF1GITx9vJ615YPwOjgb8+b7xdbLWX4Re TuUaQeLK/t9ISeqwONVNlzy8ziwhMHMCXmkqgHA+amJrFdXUThXXbfyCABxBwwZGs7/k 2KLpkD8yt6Qf0q64+STufp+KVu5XgCqdQFmGjz2Lift7AuyInr/UAITZFqirexVB9oWT 9k5g==
X-Received: by 10.180.75.212 with SMTP id e20mr5894978wiw.5.1402574868270; Thu, 12 Jun 2014 05:07:48 -0700 (PDT)
Received: from faucon.inria.fr (faucon.inria.fr. [138.96.201.73]) by mx.google.com with ESMTPSA id rw4sm1240434wjb.44.2014.06.12.05.07.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 05:07:47 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Damien Saucez <damien.saucez@gmail.com>
In-Reply-To: <40ecc5d773874ecdbdc05763004acfa7@CO1PR05MB442.namprd05.prod.outlook.com>
Date: Thu, 12 Jun 2014 14:07:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A2225E25-FE9E-4F97-B86F-9C078BB6A312@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/utjGCsFOIVzu99FBtUdDMhurYKg
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 12:07:51 -0000

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