Re: [lisp] Restarting last call on LISP threats

Roger Jørgensen <> Tue, 13 May 2014 07:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 52A461A0851 for <>; Tue, 13 May 2014 00:47:59 -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 6GC-qdEOD9-r for <>; Tue, 13 May 2014 00:47:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22a]) by (Postfix) with ESMTP id CDAF11A084A for <>; Tue, 13 May 2014 00:47:57 -0700 (PDT)
Received: by with SMTP id u57so8028575wes.1 for <>; Tue, 13 May 2014 00:47:51 -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=pY62u+dtq4pzYJuMHvLJ0bwoIKl3I15wka/nieleV2M=; b=yhAvi8uocqd/8AR0DBfGc0MwE2YlSmnMtFMMdy8jUA2lTLuwVhwBSFZi3nPmZtjY83 6pS9vLZc5sqJO5pQYGys/GiAcf+nya/Zsd5Mbq/iD+cx4YUZCTbXrFDJHkD6tdUWgUgB 1cJHdk+aHE4c0kTH/6TNKWKexrU9r3e6RO4VeBLY6U6sj5JOQ9davQxeaSguK6jSw+r3 0Lviz/Nv63MurkWsk84gnc91cnJurtg/QNSdyFM6D84vEUwlgDR36aFEndFxITCW2h18 BjBJEez3Pf4+LcGvkkQCzwVcHyQMMiPwxfk89dVo3tGt89ExaAxl2mQV+SYYwgjgBJQj TOPQ==
MIME-Version: 1.0
X-Received: by with SMTP id k4mr6396084wjn.49.1399967271189; Tue, 13 May 2014 00:47:51 -0700 (PDT)
Received: by with HTTP; Tue, 13 May 2014 00:47:51 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 13 May 2014 09:47:51 +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: "" <>
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: Tue, 13 May 2014 07:47:59 -0000

Hi Ross,

See inline,

On Mon, May 12, 2014 at 7:11 PM, Ross Callon <> wrote:
> Thanks Joel;
> I think that draft-ietf-lisp-threats-09.txt is a start towards a threats document, but that it has serious omissions and needs more work before being progressed. Here are some specific comments:
> Section 2 (On-path Attackers), first paragraph:
>    On-path attackers are attackers that are able to capture and modify
>    all the packets exchanged between an Ingress Tunnel Router (ITR) and
>    an Egress Tunnel Router (ETR).  To cope with such an attacker,
>    cryptographic techniques such as those used by IPSec ([RFC4301]) are
>    required.  As with IP, LISP relies on higher layer cryptography to
>    secure packet payloads from on path attacks, so this document does
>    not consider on-path attackers.
> To me an on-path attacker is one which is on the data path. Such an attacker might attack the contents of the data packet. In this case the paragraph seems mostly correct to me: You encrypt the contents if you don't want someone on the path to the destination to look at the contents. However, as is discussed later in the document, LISP allows systems which are not in the normal physical path, through a gleaning attack, to inject themselves into the data path. This could be applied to allow attacker's systems to inject themselves into the path of the key management protocol. This implies that a legitimate user could get keys supplied by an attacker, just as easily as it could get keys supplied by a legitimate Internet site. If you are proposing that end to end encryption is the solution to on path attackers then you need to understand the implications of LISP on the operation of the protocol needed for key management to support end to end encryption.

There exist two draft that are relevant to what you address.

You have
where the payload of a LISP encapsulated packet are encrypted. None of
the keys for encrypting/decrypting are stored in the mapping system
but is calculated by the xTR's involved.
Then you have
that attempts to secure the xTR to xTR relationship.


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