Re: [lisp] possible text for LISP threats

Dino Farinacci <> Fri, 13 June 2014 17:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E418A1B2993 for <>; Fri, 13 Jun 2014 10:54:47 -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 ov24ADG1aHpG for <>; Fri, 13 Jun 2014 10:54:46 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F07671B297B for <>; Fri, 13 Jun 2014 10:54:45 -0700 (PDT)
Received: by with SMTP id ma3so2106899pbc.1 for <>; Fri, 13 Jun 2014 10:54:45 -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=p6e4Aj6cdWTO2C49WCWg+6y6MYO68QeMuhCrWPLXsPM=; b=iExyP2wy4Vbggra6eB0ZbtmGLdd2NyM63pppq4Ajcb6TX9iv4/iUnWfloe+9XRV3EE PdOPhxACd7dXjg07z/JfesDYXryhn+2W0NOqs+8E5tC/gPEqZ/TLqTh8+LhLbWJnvH73 ZpxeJ1tSqJr4vUiGkJZZJAjfdhagL4owv5giQHTOqY2n5ek5JzUnczNFGvht1AmNMcTn K9jNzMXgfqZ03YRs8IstqZmsIh37nMnEG7f5bh2j6WZwXztxflMbCfwlDbm8/Ifbahmk rOvTMTg0cWyYpMYCIOgTyL6xuYpBfajOR6rulKyW/ZP540Zq5OtRQF4VPUpEivnrNKAC 5uqg==
X-Received: by with SMTP id nv3mr5143058pbb.128.1402682085612; Fri, 13 Jun 2014 10:54:45 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ei4sm4732448pbb.42.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 10:54:44 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Dino Farinacci <>
In-Reply-To: <>
Date: Fri, 13 Jun 2014 10:54:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Ross Callon <>
X-Mailer: Apple Mail (2.1878.2)
Cc: Damien Saucez <>, Luigi Iannone <>, LISP mailing list list <>
Subject: Re: [lisp] possible text for 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, 13 Jun 2014 17:54:48 -0000

> 5.2.4 Examples of DoS attacks
> Suppose that the attacker has a single system that he controls, and that his ISP does not check the source address of outgoing packets. Suppose gleaning is turned off (so that gleaning cannot be utilized in the attack): 

Ross you have to be much more precise in your language or no one will understand exactly what you are trying to get across. See my comments below.

For the above text, you shoudl say "all ISPs on the path do not do a source check".

> 1. Attacker could send a lot of packets to one address behind a particular xTR, each packet with a different 

You should state where the attacker is. In this case it is not at the LISP site where you refer to the xTR.

> source EID. This causes the xTR to do a mapping lookup for each one. This causes two problems in the xTR: (i) 

You need to say that the attacker is not necessarily at a LISP site but its source address will be used by the xTR FOR RETURN TRAFFIC. You need to make it clear if the mapping database should return a set of RLOCs or what is returned is a negative Map-Reply. I presume the former since you said the attacker uses a "source EID".

> control plane load (a simple data plane DOS has turned into a control plane DOS); (ii) potential exhaustion of

I think you should make it clear this is not unique to LISP. Because what you refer to as a data-plane DoS means that the hardware can drop packets, where as you know any packet that needs to go to the control plane would result the same way.

You don't want to mislead people to think LISP is worse in this case.

>  the cache. Optionally the attacker could use the same source RLOC for each, but this could in theory lead to 

If the cache is going to be exhausted you need to say that each source EID chosen will match a different EID-prefix in the mapping database causing distinct entries to be created. Otherwise, if all the source EIDs come out of a registered coarse prefix, then only one cach entry is used.

> the attacked xTR noticing and putting in a packet filter for that source RLOC, so that varying the source RLOC may make this attack more difficult to counter. 

You shouldn't say how the xTR would handle this or else, yes, it will get worse. Because if you choose a faulty solution, you will introduce more issues.

> 2. Attacker could send a lot of packets to many remote xTRs, one packet to each, all with the same source forged EID and source RLOC, with the source EID and source RLOC being that of the system that he really wants to attack. This causes each to do the same mapping lookup, which might overwhelm the mapping system serving the system under attack. 

This is written well and clear if (1) is written with more detail.

> 3. Attacker could send a large number of map requests to many remote xTRs, all with the same forged source EID and source RLOC, again with the source EID and source RLOC being that of the system that he really wants to attack. This causes each to send a map response to the system under attack. This again would be intended to overwhelm the control plane and cache of the system under attack. 

This is written well. Thanks.

> Suppose that the attacker controls a moderate sized BOTNET, consisting of a few thousand captive systems. He might install enough software on his BOT's to send a packet that looks like a LISP packet. In this case each of the attacks discussed above can be multiplied by having a wider range of systems participating in the attack.