Re: [lisp] Restarting last call on LISP threats

Dino Farinacci <> Fri, 16 May 2014 18:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 512EC1A0354 for <>; Fri, 16 May 2014 11:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TN4AqfI0IoBt for <>; Fri, 16 May 2014 11:36:28 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDD5C1A0347 for <>; Fri, 16 May 2014 11:36:27 -0700 (PDT)
Received: by with SMTP id v1so4709340yhn.30 for <>; Fri, 16 May 2014 11:36:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vR3w6cQdPAvFTnqPae7U9pvnbhtbgTVVt549Rz0NruI=; b=QvS6kLEidXMVVpsymKxzVV3hbMAwYMUHmPAbwSBgrw8P9gsn1bcAGQmnWjEg4FUK8J egWzF6+U8bGtZX1/g4JdcZLLS/QzgNfMU0r2xvxOs4q2k18UYhBJEKPHtmi32jhwFntW u91qVIYOLZnhaHiiOYSxEle+1VTJa1tRMa8HGE70kxUsewJa0KElTgSUUxrYLXRBtn71 wXjH2VS0e+VRAPkt2YUmtvPWfCBuNlx9WUsTUY+8FlofGDHt5OzTddxoWZfzjr1ZKmcR i5gWXCqmGW7zqygIqJPyXcK9twceCZG2AZL8Kb1qI3IUq9QAiBlDMqIIBHPQHsSEaB3H B6uw==
X-Received: by with SMTP id k16mr6469485yhf.140.1400265379942; Fri, 16 May 2014 11:36:19 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id u5sm13009325yhg.25.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 16 May 2014 11:36:17 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 16 May 2014 11:36:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Ronald Bonica <>
X-Mailer: Apple Mail (2.1874)
Cc: Roger Jorgensen <>, "" <>
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: Fri, 16 May 2014 18:36:30 -0000

> 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

Determining "who" is rather nebulous. How can I trust this email is from you Ron? It's because I have ultra meta-data about you. That is, I know you can be versed in LISP so I am likely talking to another LISP spoofer that looks like Ron.

So if I am getting packets from an xTR that has a global locator that is your DSL router at your house, I would expect to see the inner source EID be from the mapping. I can tell that the EID->RLOC mapping is authenticated and validated by asking the mapping system, but if Roger managed to get packets to me with BOTH your EID and RLOC, then I really don't know if those packets are coming from Ron. 

Now how Roger does this will be an amazing feat because a lot of ISPs between Roger and me would be very broken.

> 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.

If you encrypt data to me, I cannot tell you are actually Roger or Ron. But the conversation between me and Roger (who is spoofing Ron) will be confidential.  ;-)

We either have total privacy or we have NSA intrusion.  ;-)  You can't have both so we should have the former.

> 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.

This is true. When a system receives an ARP-request it gleans the source information in there to minimize broadcast traffic for returned unicast traffic. That is a benefit willing to receive at a cost of knowing a LAN is secure and scoped (if that is really true, it is another story). So there is a value/risk tradeoff here.

> 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.

But will the entire path to any destination let him?

> 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. 

You can trust sources less if they ARE NOT in the mapping database. That is, if you are a LISP site, you have more tools be verify trust.


>                                                                                                           Ron
>> -----Original Message-----
>> From: Roger Jørgensen []
>> Sent: Wednesday, May 14, 2014 3:59 AM
>> To: Ronald Bonica
>> Cc: Ross Callon;
>> Subject: Re: [lisp] Restarting last call on LISP threats
>> On Tue, May 13, 2014 at 7:31 PM, Ronald Bonica <>
>> wrote:
>>> Hi Roger,
>>> Or asked more explicitly, can the level of security claimed by the threats
>> document be achieved without implementing the protocol extensions
>> described in lisp-sec and lisp-crypto?
>> I've been pondering on what to answer you since yesterday but think the
>> reply from Joel cover it well. However as an addon to Joel and partly reply to
>> your question, see more inline.
>> On Tue, May 13, 2014 at 11:56 PM, Joel M. Halpern <>
>> wrote:
>>> Ron, I am having trouble with the question.
>>> The threats document describes the threats as they exist today,
>>> without the adoption of either document that Roger pointed to.  Thus,
>>> I do not see any dependence.
>>> If there is a threat that is not well described in the base spec or
>>> this document, then we should add it.  We should add it even if there
>>> are proposals to remediate it.  But if there is a clear proposal of a
>>> missing threat, I missed it.
>> Your question made me question the purpose of the LISP threats draft -
>> should it cover potential problem with RFC6830 and include pointers to other
>> work that cover them? That will include we'll get a document that will be
>> updated over time and is that a good thing?
>> The other way to look at LISP threats document is to have it as a "review" of
>> RFC6830, point out weaknesses and discuss them but with no references to
>> other documents. It will be a upstream document that we can refer to from
>> like the two draft I mention.
>> I don't think LISP threat should point to the two draft I mention, but both
>> drafts should have a reference to LISP threat since this will be create a more
>> stable threat document.
>> Then Dino mention:
>> On Tue, May 13, 2014 at 7:47 PM, Dino Farinacci <>
>> wrote:
>> <snip>
>>> The main LISP spec (RFC6830) indicates if you want to trust the mapping
>> system you can use the gleaned information as soon as you receive it. And if
>> you don't trust the mapping system, you can send a "verifying Map-Request"
>> to the mapping system which results in a signed Map-Reply returned ala
>> draft-ietf-lisp-sec-06.
>> Is this covered in the document? I didn't see it but it's still early here...
>> --
>> Roger Jorgensen           | ROJO9-RIPE
>>          | - IPv6 is The Key!
>>   |
> _______________________________________________
> lisp mailing list