Re: [lisp] Restarting last call on LISP threats

Roger Jørgensen <> Sat, 17 May 2014 20:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D0551A0216 for <>; Sat, 17 May 2014 13:37:00 -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 qLlnyvaeWKpy for <>; Sat, 17 May 2014 13:36:56 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 011781A0208 for <>; Sat, 17 May 2014 13:36:55 -0700 (PDT)
Received: by with SMTP id w62so3914328wes.2 for <>; Sat, 17 May 2014 13:36:54 -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=p/mXum9l81uwUC6KSDydwqOwb/L3CKSEF8lDZY0jlaI=; b=wFzJkt4x7pO8JTszYFrgOrcJh94fghe08tWlediCMBg9FEqNpB4gEoYbkpfeWMmsTH whdW0EX5lhgHJG8lZuQRmF8aY51vOvqYOLzLnjGDAgwH7kECvx24DVQESt2MMb54qdKt mJ2QYAv0Gqtb7fme0UlBvRXeXuUvpmQdHgsJTjmI1UAguKHJJY/hnfNlycKX5+Efd7FS WX887yGvj3PYu3OeCvyNVlbHKL/t8MZiZqJY4/WBXcB/P7/fEq6bDbBL/NLiB5eEk+Gt qY4pIOFBfd5XWvWE3CIcnnr+iKqS9HTUSFxoM5MyNl/Mq0GBkoPJmT54Ur5+FAqP8rPs M23Q==
MIME-Version: 1.0
X-Received: by with SMTP id lk2mr20685391wjc.33.1400359014394; Sat, 17 May 2014 13:36:54 -0700 (PDT)
Received: by with HTTP; Sat, 17 May 2014 13:36:54 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sat, 17 May 2014 22:36:54 +0200
Message-ID: <>
From: =?UTF-8?Q?Roger_J=C3=B8rgensen?= <>
To: Ronald Bonica <>
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: Sat, 17 May 2014 20:37:00 -0000

On Thu, May 15, 2014 at 11:02 PM, Ronald Bonica <> wrote:
> Roger,
> Having considered this, it appears that the LISP data plane can operate in trusted or untrusted mode. In the trusted mode, when one XTR receives a data-plane packet from another, it can trust control plane information that it might glean from the packet's outer IP header and LISP header. Such trust is based on the assumption that:
> - the sending XTR is who it claims to be
> - the sending XTR is not intentionally offering bad mapping information to the receiving XTR
> In trusted mode, the receiving XTR can glean control information from the data plane. However, in untrusted mode, the receiving XTR must not do so. Alternatively, it must send a verifying MAP-REQUEST to the mapping system.
> So far, all of this is covered nicely between RFC 6830 and the LISP threats document. However, we have yet to explore the threats associated with unsecured mode operation, where gleaned information cannot be used.
> For example, assume that two XTRs and an attacker are connected to the global Internet. The attacker is neither an XTR nor contained by a LISP site. The attacker is capable of spoofing its sources address.
> The attacker can launch a DoS attack against an XTRs control plan by sending a barrage of crafted packets to the victim XTR. Each crafted packet cause the victim XTR to send a verifying MAP-REQUEST to the mapping system.  The attack stream may be so large that it causes the victim XTR to exceed the rate limit for MAP-REQUEST messages.

Lots of other people that know LISP way better than I do have responded already.

Do I understand you correct that you think there is a hole in the
threat draft, or are you talking about another miss, that is what will
happen if the mapping-system fail to reply in time when encryption or
other form for verification of both ends (iTR and eTR) are used?


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