Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <> Mon, 26 May 2014 05:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2FB3A1A047B for <>; Sun, 25 May 2014 22:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oy6v_x9Kzu7N for <>; Sun, 25 May 2014 22:06:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EFEA31A047A for <>; Sun, 25 May 2014 22:06:21 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.949.11; Mon, 26 May 2014 05:06:16 +0000
Received: from ([]) by ([]) with mapi id 15.00.0949.001; Mon, 26 May 2014 05:06:16 +0000
From: Ronald Bonica <>
To: Damien Saucez <>
Thread-Topic: [lisp] Restarting last call on LISP threats
Date: Mon, 26 May 2014 05:06:16 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 02234DBFF6
x-forefront-antispam-report: SFV:NSPM; SFS:(428001)(377454003)(13464003)(24454002)(199002)(189002)(33646001)(76576001)(21056001)(4396001)(15975445006)(77982001)(31966008)(74662001)(74502001)(81542001)(81342001)(76482001)(74316001)(46102001)(54356999)(76176999)(87936001)(83072002)(92566001)(16236675002)(79102001)(19580395003)(19625215002)(83322001)(85852003)(50986999)(19580405001)(20776003)(64706001)(99396002)(2656002)(99286001)(101416001)(86362001)(19300405004)(66066001)(15202345003)(80022001)(24736002)(19607625008); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB442;; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
Content-Type: multipart/alternative; boundary="_000_dd849ce0cca749c885c5b8a1e989f758CO1PR05MB442namprd05pro_"
MIME-Version: 1.0
Cc: Roger Jorgensen <>, 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 05:06:25 -0000

From: Damien Saucez []
Sent: Friday, May 23, 2014 9:07 AM
To: Ronald Bonica
Cc: Dino Farinacci; Roger Jorgensen; LISP mailing list list
Subject: Re: [lisp] Restarting last call on LISP threats

Hello Ronald,

On 22 May 2014, at 22:57, Ronald Bonica <<>> wrote:


Today's Internet is not as fragile as you think. This mail traversed many routers between my house and yours. 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.
We tend to disagree with that, for example you have ICMP today...
[RPB] Because ICMP is susceptible to DoS attacks, it wouldn't make a very good routing protocol. That's why we don't use it for routing. By contrast, LISP map-request messages are susceptible to DoS attacks and they do carry routing information.

In LISP, separation between the forwarding and control plane is lost. As a matter of course, forwarding plane activity causes control plane activity. Since forwarding plane bandwidth exceeds control plane bandwidth, DoS attacks against the control plane are possible.

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

DoS is already explained and the definition given:

" A Denial of Service (DoS) attack aims at disrupting a specific

   targeted service either by exhausting the resources of the victim up

   to the point that it is not able to provide a reliable service to

   legit traffic and/or systems or by exploiting vulnerabilities to make

   the targeted service unable to operate properly.

is covering the case you mention.
You might want to add the following details to section 5.2:

-          A DoS attack can be launched by anybody who can send a packet to the XTR's LOC

-          DoS attacks can render an XTR inoperable

-          DDoS attacks can render the mapping system inoperable.

This is what differentiates LISP from today's routing system.


Damien Saucez


-----Original Message-----
From: Dino Farinacci []
Sent: Wednesday, May 21, 2014 6:58 PM
To: Ronald Bonica
Cc: Roger Jorgensen;<>
Subject: Re: [lisp] Restarting last call on LISP threats

The attacker sends a flow of crafted packets to the victim XTR. Each packet
is a well-formed LISP data packet. It contains:

- an outer IP header (LOC->LOC)
- a UDP header
- a LISP Header
- an IP header (EID->EID)
- payload

Just like a regular packet I can send to your home router today. So yes okay.
So let's continue. See comments below.

Each packet contains control plane information that is new to the victim

Be more specific about what control information are in these encapsulated

XTR. For example, the victim XTR has no mapping information regarding
either the source LOC or source EID prefix. Rather than gleaning this mapping
information from the crafted packet, the victim XTR sends a verifying MAP-
REQUEST to the mapping system.

Assume that the attack flow is large (N packets per second). Assume also
that the XTRs rate limit for MAP-REQUEST messages is less than N packets
per second. Has the attack not effectively DoS'd the victim XTR?

It caches the rate the rate the packets are coming in and eventually stops
sending Map-Requests completely.

It cannot stop the incoming rate of packets today just like a roque BGP
attacker can send millions of packets per second to a peer regardless if it
does or does not have the peer authentication key.

To make this attack work, every packet in the attack flow may need to have
a unique, spoofed, source LOC.

An implementation can detect that after rate limiting 1000s of such requests
are happening that it just stops operation.

What if I sent a Juniper 20 million routes today?

The Internet is very fragile and LISP IS NOT making it worse. And in some
cases it is making it better with integrated techniques.


lisp mailing list<>