Re: [lisp] possible text for LISP threats

Dino Farinacci <farinacci@gmail.com> Fri, 13 June 2014 19:36 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 D856E1B2A06 for <lisp@ietfa.amsl.com>; Fri, 13 Jun 2014 12:36:33 -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 LElPvMrIEMNY for <lisp@ietfa.amsl.com>; Fri, 13 Jun 2014 12:36:32 -0700 (PDT)
Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E161B29EC for <lisp@ietf.org>; Fri, 13 Jun 2014 12:36:32 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id lf10so2448497pab.30 for <lisp@ietf.org>; Fri, 13 Jun 2014 12:36:32 -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=RTPrVIOo8pMvat0CviohBRSMxky4Lo/BhbaJTn77vpk=; b=zyJajeaUM8tTijjTDrWZ7T4LpN9H/Y25rhRsn9SKoXuQxfOEljvcIVP0z932EajDCl pzxEik9BBnuLyq8eV/z5vDNOmKdQ1jM9RY72r15kQn0NNGWjQUcuVNPJ+dWyJWpWGHTx BbHlAJmz2qdJP1+UUnJPa3GJmnoWXYx6hGNrrKW3xd6w+7Zg8ny0HBzY7pAB886fAzrr 9mReva3nBwNcXUPMPkLzfHtC/Zz5BJuYUIaDmn75LDtIclyAO+tMtKi4S3h7Aev5MnDI 7rRbjA1Gkc8FYKJQqCET3DFAcTVKQu6NkEASLL0kNSjfgTazve7HvRrJdjo8tgBMpUVQ NoKg==
X-Received: by 10.66.146.105 with SMTP id tb9mr5697425pab.157.1402688191912; Fri, 13 Jun 2014 12:36:31 -0700 (PDT)
Received: from [192.168.1.174] ([207.145.253.66]) by mx.google.com with ESMTPSA id kq10sm5005464pbc.90.2014.06.13.12.36.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 12:36:30 -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: <68c3feb199e840908a8516ee7dc9f357@CO2PR05MB636.namprd05.prod.outlook.com>
Date: Fri, 13 Jun 2014 12:36:27 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D4B9BE9F-13A6-43F6-AC99-C8089AF7B153@gmail.com>
References: <898c27d33fdd452499848408c9eac47f@CO2PR05MB636.namprd05.prod.outlook.com> <EF2B2675-0E43-4ECC-A1D4-2C5B18F875B0@gmail.com> <68c3feb199e840908a8516ee7dc9f357@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/vcFlTBTwDheMxyHIjqaFshmGUPQ
Cc: Damien Saucez <damien.saucez@inria.fr>, Luigi Iannone <luigi.iannone@telecom-paristech.fr>, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] possible text for 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: Fri, 13 Jun 2014 19:36:34 -0000

> For the host to which the attack packets are destined, I don't think that LISP is worse in this case. However, it is not the effect on a host that I am concerned about. If the xTR serving that host in this case is either a CE router or a PE router, then this is a lot worse for the xTR, since the attack packets cause a reaction in its control plane. Of course if the effect of the attack is to fill the cache, then again LISP is worse since "non-LISP Internet operation" doesn't have a cache. I understand that we are not planning to describe solutions in this text, but if rate limiting of map requests is considered to be normal practice, I wonder if it would be worth mentioning that rate limiting could prevent overload of the xTR's control plane, but that in this case the attack could prevent map requests in support of legitimate users. 

I beg to differ, because what you refer to a cache makes assumptions that it is finite size. A BGP RIB is finite size as well. And even a legit BGP peer can fill up a finite size RIB.

So it is my claim that LISP is no worse.

> the attacked xTR noticing and putting in a packet filter for that source RLOC,
>>> so that varying the source RLOC may make this attack more difficult to counter. 
>> 
>> You shouldn't say how the xTR would handle this or else, yes, it will get worse.
>> Because if you choose a faulty solution, you will introduce more issues.
> 
> I am fine with dropping the sentence stating "Optionally the attacker could use the same source RLOC for each, but this could in theory lead to the attacked xTR noticing and putting in a packet filter for that source RLOC, 

I wouldn't put in a packet filter or else the real RLOC is denied service by the attacked xTR itself.

> so that varying the source RLOC may make this attack more difficult to counter". However, I do wonder, what would happen if a single attacker sent a large number of packets which look like LISP packets with the same RLOC for all (perhaps the legitimate RLOC of the attacker) but with different EID's, each EID chosen from a different EID block. Would the xTR receiving all of these incoming packets send a map request for each EID? 

This is what Ron brought up.

> This could be a way to get around source IP address checks (where they are deployed), since the source RLOC would be correct and legitimate. 

Right, understand.

It all comes down to the (source-EID, source-RLOC)-tuple needs to be authenticated to be the legitimate source.

Dino