Re: [lisp] Restarting last call on LISP threats

Dino Farinacci <> Fri, 23 May 2014 13:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A54D81A01C0 for <>; Fri, 23 May 2014 06:30:09 -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 o4PCLUGOC3yO for <>; Fri, 23 May 2014 06:30:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BC69E1A01AF for <>; Fri, 23 May 2014 06:30:02 -0700 (PDT)
Received: by with SMTP id m20so8044266qcx.40 for <>; Fri, 23 May 2014 06:30:00 -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=1G5JfrVGe+MwszB/ZQqDfZS/njaVxIeBqn3Dn5leqTM=; b=RVBzcA97zttPu4EKbe2X+kRmE03K55S8lu+f8mDLfZhcvg1kJb31M6SCN13KN1iLeu WuNuwYqeW2BjJpadoK3X5rKcqX5AbSe9Ytq21BpNf27k8yNIZDjDkWZDZ66FarBOpiNT tyZg8cIvqJu78HPu7DHKhY0Blu1h+6Pk/VJ3N/xOqi6lgjXFac+UNJuhFoH+XKC0mB2A YcTHlMFk3hMeac9vF1xxhsdObD0aAprBo8See1PnWghQEfmRbPYUxHB0zyyJiVwPWcG/ wnXFZA1RxZ4o7R3sfnRFwzBFj+wFiaC0kYiEPYIJTkuCkzMg3ht6H8r2UWvV6nYdcfer tntw==
X-Received: by with SMTP id kb3mr6816508qcb.6.1400851800691; Fri, 23 May 2014 06:30:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id j88sm1937628qgf.39.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 06:29:59 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 23 May 2014 06:29:57 -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, 23 May 2014 13:30:09 -0000

> Dino,
> Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. 

Ron, I know for a fact, it is fragile. I know most of the code that runs the Internet. And you said yourself that uRPF is not used in many places, so that, in and of itself, makes it fragile for spoofing.

> If those routers are well-managed, there is nothing that I can do from my house that will cause any of those routers to consume control plane resources. Therefore, there is nothing that I can do from my house that will cause a DoS attack against those routers' control planes.

My example, I wanted to take you out, not the PE router at AT&T that could take out all customers attached to that PE. Which has happned before by bad vendor code. LOL. So I don't have to play there. 

But I can use up all your resources at your house so your kids can get their homework assignments done on time.

It happens to me all the time at Starbucks when 15 people are watching videos and all I want is some decent response in my emacs window.  ;-)  That is not a DoS, in this case but normal usage. So DoSing something is as simple as bringing up an innocent applicaiton and lauching UDP streams to your home router.

> In LISP, separation between the forwarding and control plane is lost. As a matter of course, forwarding plane 

That is not true. And in most cases, when xTRs are behind NATs, there is NEVER a map-cache miss. I assume you are referring to that when you claim there is lost separation. If not, please clarify.

> activity causes control plane activity. Since forwarding plane bandwidth exceeds control plane bandwidth, DoS attacks against the control plane are possible.

Yes, for every protocol we have invented. But like I said, there are better ways to solve this with LISP. If you look at all the drafts in totality, you will see we have a decent toolbox of solutions that COULD fight this traditional problem.

You are merely (and continually) looking ONLY at the map-cache miss problem.

> In order to be complete, the threats document must describe the DoS threat. It should also describe mitigations, if any exist.

I agree with that. No one is arguing your point or Ross point. But rather than just documenting what they are, we want to fix them. So that is were we should put our attention. So let's have all of us work together and identify the problems and brainstorm about fixes. 

Rather than just saying what is wrong.