Re: [lisp] Restarting last call on LISP threats

Ronald Bonica <> Thu, 22 May 2014 20:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B6D491A0305 for <>; Thu, 22 May 2014 13:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r4cF_mHFgMAj for <>; Thu, 22 May 2014 13:57:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 385CE1A02A9 for <>; Thu, 22 May 2014 13:57:20 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.944.11; Thu, 22 May 2014 20:57:16 +0000
Received: from ([]) by ([]) with mapi id 15.00.0944.000; Thu, 22 May 2014 20:57:15 +0000
From: Ronald Bonica <>
To: Dino Farinacci <>
Thread-Topic: [lisp] Restarting last call on LISP threats
Date: Thu, 22 May 2014 20:57:15 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-forefront-prvs: 021975AE46
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(428001)(51704005)(13464003)(199002)(189002)(377454003)(76576001)(87936001)(74502001)(77982001)(21056001)(19580395003)(19580405001)(83322001)(2656002)(4396001)(31966008)(81342001)(20776003)(81542001)(74662001)(80022001)(86362001)(92566001)(76482001)(85852003)(1411001)(83072002)(46102001)(33646001)(99396002)(101416001)(79102001)(64706001)(66066001)(74316001)(54356999)(50986999)(76176999)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR05MB443;; 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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Thu, 22 May 2014 20:57:22 -0000


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.

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.


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