Re: [lisp] Restarting last call on LISP threats

Roger Jørgensen <> Mon, 26 May 2014 11:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 570111A00F4 for <>; Mon, 26 May 2014 04:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 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, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0iK6TJA2WgQC for <>; Mon, 26 May 2014 04:03:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 083C91A00DE for <>; Mon, 26 May 2014 04:03:47 -0700 (PDT)
Received: by with SMTP id y10so7642865wgg.1 for <>; Mon, 26 May 2014 04:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tf8+MFoHKc9YT0Xb2zWwk7aMf2LruCraX/XwU0qtWf4=; b=i4BiAeeJPwqx0rgEJnpn2oo1a00Kqkymb0VaCeRTt1BpoZiUrY8lAnzuT+OzFBPnaa 0K1C0WZKVC1F1vUVnZXqzSReeMwrGQ7JahYhwJ6vkpBjwgQI1F3ye1VWLA8G/+pqJolT R6YwfpLaKD87cwA49plDJirInpFNz9g71qJSJ3Uv3+t5A7W48EMBhVV672tKhwBdpOdN z0N0tHrX8nExtYicly64z2eNcJjAhYZVNHTv73v/T70yH7XSEnuf3NpNgLfFYhqXwuSW ChIKmg7E7jIO0gUXDESsf0dU1pwU1B+odFDaIy8kdGvtjtE1xhnpLyhxqlwL4E3ccVdM kpGg==
MIME-Version: 1.0
X-Received: by with SMTP id b5mr1975610wie.16.1401102224177; Mon, 26 May 2014 04:03:44 -0700 (PDT)
Received: by with HTTP; Mon, 26 May 2014 04:03:44 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Mon, 26 May 2014 13:03:44 +0200
Message-ID: <>
From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= <>
To: Ross Callon <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: LISP mailing list list <>
Subject: Re: [lisp] Restarting last call on LISP threats
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 May 2014 11:03:49 -0000

A general reply, we were on the way to getting into a head-to-head
discussion instead of being constructive. The last few email I read
moved away from that path.

I think we should discuss all threat, not just define them to be out of scope.

some comments:

On Fri, May 23, 2014 at 4:36 PM, Ross Callon <> wrote:
> Detailed comments below. To summarize, these details include three threats which are new to LISP and which are not adequately explained in the current threats document:
>  (1) The Control Plane Threat: LISP allows a dataplane DOS attack (lots of packets sent to overwhelm a site) to turn into a control plane attack (the router is forced to respond to the attack in the control plane, which is of course frequently multiple orders of magnitude slower than the data plane, particularly for very high speed routers).

Seems like we all disagree on how serious this is, how much harm it
can do. But it should be mention.

I think I remember an earlier discussion on a very similar topic that
just ended with people disagreeing and stopped discussing it.
This is probably a new topic, but where is the weakness really,
Mapping-System or on the xTR side? ...?
Could be that our ongoing discussion here might be because it's not
good enough explained?

>  (2) The Privacy Threat: LISP provides an attacker with a relatively easy way to determine the identity of large numbers of PE and/or CE routers (globally, if LISP is deployed on that level) .

I agree there are privacy threats.

LISP is no better or worse compared to current internet on privacy for
end-user, it's reveled one way or another somehow unless you encrypt
your data (HTTPs etc).
What LISP add to the pool is the possibility to collect the IP for
many end-sites with ease, xTR sides. Is that the same thing as what
you're describing?

>  (3) the Traffic Gleaning Threat: If an xTR gleans EID -> RLOC mappings from incoming packets, this provides an easy way for hackers to intercept traffic. I put this threat third because gleaning can be turned off, and thus this threat can be defeated simply by not gleaning EID -> RLOC mappings.

Isn't this the same as on-path and Man-in-the-middle attack? Or do you
describe something else?


Roger Jorgensen           | ROJO9-RIPE          | - IPv6 is The Key!   |