Re: [lisp] Progress on threats document

Damien Saucez <> Wed, 18 February 2015 09:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E77951A6FFF for <>; Wed, 18 Feb 2015 01:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.26
X-Spam-Status: No, score=-4.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MANGLED_AMPLFY=2.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jrZDrCigZoVZ for <>; Wed, 18 Feb 2015 01:06:40 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3BDE01A702C for <>; Wed, 18 Feb 2015 01:06:40 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,595,1418079600"; d="scan'208";a="100447327"
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 18 Feb 2015 10:06:23 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Damien Saucez <>
In-Reply-To: <>
Date: Wed, 18 Feb 2015 10:06:22 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Ross Callon <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: Olivier Bonaventure <>, LISP mailing list list <>
Subject: Re: [lisp] Progress on threats document
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: Wed, 18 Feb 2015 09:06:44 -0000

Hello Ross,

Thank you for the feedback.

Answers and propositions inline.

On 14 Feb 2015, at 04:02, Ross Callon <> wrote:

> As requested, here are my comments on the current threats document. Generally thanks for the work, I think that this is much improved from the previous versions. However, there is still IMHO some work needed. 
> First a couple of minor grammatical issues: Section 1, second paragraph, the grammatical construction is not parallel. In listing the three parts, "the first defines...", "the second describing...", "The third discussing...". I think that this should be either "the first defining...", "the second describing..", etc. Alternately this could "the first defines...", "the second describes...”. 

Good point, thanks, we will fix this in the new version.

> Second minor grammatical issue, in many places the documents starts sentences with "To succeed their attacks, <something> attackers...". I think that on the most part this should read something more like "In order for their attacks to succeed, <something> attackers...”. 
Indeed it sounds better, thanks, we will fix this in the new version.

> Section 2.1.4: This section correctly mentions that it is possible for an attacker to operate in the data plane to mount attacks targeting the control plane (or vice versa). However, the implication of this, in terms of the difference in speeds of the two planes, is not discussed anywhere. I am not sure where this should be discussed, but this is a sufficiently important issue that it should be discussed somewhere. I have wondered whether this should be mentioned here, or in section 2.2.9 (since this could be thought of as a form of amplification attack). Perhaps the most straightforward way to fix this would to be append to the second paragraph of section 2.1.4 a couple of additional sentences that state: "In some cases, particularly in very high performance routers, the data plane may operate faster, and potentially several orders of magnitude faster, relative to the control plane. Launching an attack in the data plane that is targeted at the control plane may therefore greatly amp
> lify the affect of the attack (ie serve a function similar to an amplification attack).” 

What about adding this to the end of section 2.2.9?

In some cases, the data-plane can be several order of magnitude faster than the control-plane at processing packets. This difference can be exploited to overload the control-plane via the data-plane without overloading the data-plane.

> Section 3.8 first paragraph, second sentence. This currently reads "If an ETR does not accept Map-Reply messages with an invalid nonce, the risk of attack is limited given the size of the nonce (64 bits)". This is true for off-path attackers. However, an on-path attacker can see the nonce (and noting that the document is already clear that where gleaning allows a formerly off-path attacker to insert themselves into the data path then they have become by definition an on-path attacker). I think that this sentence should read "If an ETR does not accept Map-Reply messages with an invalid nonce, the risk of an off-path attack is limited given the size of the nonce (64 bits)”.

Thanks we will replace the sentence with your suggestion.

> Section 3.9, fourth paragraph. This currently reads:
>   A compromised ETR can also de-aggregate its EID prefix in order to
>   register more EID prefixes than necessary to its Map Servers (see
>   Section 3.7 for the impact of de-aggregation of prefixes by an
>   attacker).
> I think that it might be worth mentioning: De-aggregation could occur as part of an intentional attack, but could also occur as an unintended side effect of normal operation if over time too many LISP sites advertise relatively de-aggregated or very fine grained mappings. 

While technically the point you are making is correct, this document is only about security and is therefore preferable to focus on attacks.

> Section 4, "Note on privacy". Second paragraph. This currently reads: 
>   Note, however, that like public deployments of any other control
>   plane protocol, in an Internet deployment mappings are public and
>   hence provide information about the infrastructure and reachability
>   of LISP sites (i.e., the addresses of the edge routers).
> The amount of information made available with LISP, particularly in map replies, is finer grained than what is available with current routing protocols. Certainly with current protocols ping could in principle give fine grained information (if I trace route across my ISP, and if they let me do it, then I would find out the IP addresses of routers), but it is largely turned off just for this reason. I think that it would be more accurate to say: 
>   Like public deployments of any other control
>   plane protocols, in an Internet deployment mappings are public and
>   hence provide information about the infrastructure and reachability
>   of LISP sites (i.e., the addresses of the edge routers). LISP map 
>   replies may however provide finer grained and more detailed
>   information to a wider set of Internet sites than is available with 
>   currently control protocols. 

The sentence you are proposing is not completely correct. 
LISP does not provide fine grained information about the infrastructure. 
LISP only allows to clearly identify ASBRs that are running LISP functions.
Furthermore, being smart with BGP already allows you to infer business 
relationship between ASes, this is a kind of very precise information 
that can be retrieved with current control protocol.  

> Section 6 (security considerations), second paragraph: 
>   The purpose of this document is not to provide recommendations to
>   protect against attacks, however most of threats can be prevented
>   with careful deployment and configuration (e.g., filter) and also by
>   applying the general rules in security that consist in activating
>   only features that are necessary in the deployment and verifying the
>   validity of the information obtained from third parties.  More
>   detailed recommendations are given in [Saucez13].
> Given that this document does not provide recommendations to protect against attacks, it seems premature to conclude that "most of the attacks can be prevented with careful deployment and configuration". If detailed recommendations are in a different document, then that other document might be the right place to conclude whether or not "most of the threats can be prevented". Also, of course protecting against most of the threats is very different from protecting against all of the threats.  I would therefore shorten this paragraph to just: 
>   The purpose of this document is not to provide recommendations to
>   protect against attacks. More detailed recommendations for preventing 
>   or mitigating these threats are given in [Saucez13].

Actually this is part of the next steps (after end of February), to write the mitigation part of the document. This text will hence be changed accordingly.

Thank you,

Damien Saucez 

> Thanks, Ross
> -----Original Message-----
> From: lisp [] On Behalf Of Luigi Iannone
> Sent: Monday, January 12, 2015 9:48 AM
> To: LISP mailing list list
> Cc: Damien Saucez; Olivier Bonaventure
> Subject: [lisp] Progress on threats document
> Hi All,
> back in Toronto the WG agreed to organise the threats document in two main parts: 
> 1- threat analysis 
> 2- threats mitigation
> there was also agreement to try to finalise the first part before tackling the second one.
> To this end, this would be the right time to review the current document and send any comment/feedback to the authors.
> Having such review by the end of February at latest would give sufficient time to have a new document with the first part done and a newly proposed second part before the meeting in Dallas.
> Please speak up before the end of February if you have any comment, otherwise authors will consider the first part as done.
> ciao
> Luigi
> _______________________________________________
> lisp mailing list
> _______________________________________________
> lisp mailing list