Subject: Re: [lisp] Progress on threats document

From: Ross Callon <[email-masked]>
Date: Sat, 14 Feb 2015 03:02:19 +0000

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...". 

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...". 

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 amplify the affect of the attack (ie serve a function similar to an amplification attack)." 

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)".

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. 

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. 

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].

Thanks, Ross

-----Original Message-----
From: lisp [mailto:[email-masked]] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/lisp

---

From: Damien Saucez <[email-masked]>
Date: Wed, 18 Feb 2015 10:06:22 +0100

Hello Ross,

Thank you for the feedback.

Answers and propositions inline.

On 14 Feb 2015, at 04:02, Ross Callon <[email-masked]> wrote:

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

> 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 L…

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

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

>   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

---

From: Ross Callon <[email-masked]>
Date: Thu, 26 Feb 2015 01:19:31 +0000

> Answers and propositions inline.

I have deleted items on which we have already reached agreement. Otherwise comments in-line. Also, I thought of a few other issues, but for readability I will mention them in a separate email which I will send a few minutes after this one. 

-----Original Message-----
<some items deleted here for which we are in agreement>

>> 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 amplify the affect of the attack (ie serve
>> a function similar to an amplification attack)." 

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

I think that this reads well and makes the point. 

<more deleted>

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

Okay. 

>> 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: 
>> 

> that can be retrieved with current control protocol. 

Yes, LISP does allow / cause identification of routers on borders (either CE or PE routers, which I think are correctly termed "ASBRs"). It does not, as far as I know, allow identification of other routers (such as provider core P routers, or routers that do not choose to implement/deploy LISP). BGP does already reveal the identification of some border routers. There is commonly abbreviation of some of the BGP information and not all of the border routers will be BGP speaking. My understanding is that there are many CE routers who might or might not run BGP with PE routers, but even if they do their identity does not get sent out in the broad Internet-wide routing updates (eg, because the CE router is advertising an address block that is in the Provider's PA space, so that it gets summarized before being spread widely). How about if we "adjust" the text that I proposed to read as follows (and noting that the first sentence here is from the current threats document): 

   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). Depending upon
   deployment details, LISP map replies might or might not provide finer
   grained and more detailed information than is available with 
   currently deployed routing and control protocols.  

Thanks, Ross

---

From: Ross Callon <[email-masked]>
Date: Thu, 26 Feb 2015 01:27:04 +0000

As promised in my last email, here are a few other comments on the threats document:

In section 3.1 (gleaning), the first four paragraphs talk about threats that can be defeated by simply turning off gleaning (if you don't glean, you don't accept incorrect information from spoofed incoming packets). However, the fifth paragraph talks about the impact on the control plane from the fact that a map request needs to be sent in response to incoming packets from unknown EIDs. This of course applies whether or not you are gleaning. Perhaps we should append to the fifth paragraph of 3.1 (the paragraph that starts "A gleaning attack does not only impact..."): 

   This issue occurs even if gleaning is turned off, since whether or not gleaning is used
   the xTR still needs to send a map request in response to incoming packets whose EID is
   not currently in the cache. 

Section 3.3, fourth paragraph (counting the bullet points as paragraphs, thus the paragraph starting "A cross-mode attacker..."), second sentence. This currently reads: 

   For instance
   if the mapping cached at the xTR is outdated, the xTR will send a
   Map-Request to retrieve the new mapping which can yield to a DoS
   attack (by excess of signalling traffic) or an amplification attack
   if the data-plane packet sent by the attacker is smaller than the
   control-plane packets sent in response to the attacker's packet.

Strictly speaking an amplification attack can occur if the data-plane packet sent by the attacker uses less resources than the control plane packets sent in response, regardless of the type of resource. Thus bandwidth is one form of resource (for which the current text is correct), and processing is another type of resource. I suppose that the bandwidth internal to a router between the data and control planes is another resource (which might not be used at all by most data plane packets). Thus it might be more correct to change this sentence slightly to read: 

   For instance
   if the mapping cached at the xTR is outdated, the xTR will send a
   Map-Request to retrieve the new mapping which can yield to a DoS
   attack (by excess of signalling traffic) or an amplification attack
   if the data-plane packet sent by the attacker is smaller, or otherwise
   uses fewer resources, than the
   control-plane packets sent in response to the attacker's packet.

Finally, this afternoon I was re-reading section 6.3 ("Routing Locator Reachability") of RFC 6830 (the LISP spec). Quite a bit of what might go wrong if this is attacked is already in the threats document. However, a thought occurred to me: If an attacker uses spoofed packets to fill up the xTR's cache, will the xTR subsequently use one of the techniques from section 6.3 to periodically check the liveness of the entries that have been added to its cache? If so, this would seem to amplify the effect of a cache-filling attack.  I am wondering whether section 3.1 should have a paragraph (one sentence long) added to the end which states something along the lines of: 

   If an xTR chooses to periodically check the liveness of entries in its cache 
   (as described in section 6.3 of [RFC6830]), then this may amplify the work 
   needed to deal with extra entries that an attacker has inserted into the 
   xTR's cache. 

Thanks, Ross

-----Original Message-----
From: Damien Saucez [mailto:[email-masked]] 
Sent: Wednesday, February 18, 2015 4:06 AM
To: Ross Callon
Cc: Luigi Iannone; LISP mailing list list; Olivier Bonaventure
Subject: Re: [lisp] Progress on threats document

Hello Ross,

> lify the affect of the attack (ie serve a function similar to an amplification attack)." 

Thank you,

Damien Saucez

---

From: Damien Saucez <[email-masked]>
Date: Thu, 26 Feb 2015 14:56:59 +0100

Hello,

>   currently deployed routing and control protocols.  

ok, we will integrate that.

Thank you for all your efforts!

Damien Saucez

---

From: Damien Saucez <[email-masked]>
Date: Thu, 26 Feb 2015 19:38:58 +0100

Hello,

>   not currently in the cache. 

added with the following sentence:

        This issue can occur even if 
        gleaning is turned off since whether or not gleaning is used the ITR 
        may need to send a Map-Request in response to incoming packets whose
        EID is not currently in the cache.

>   control-plane packets sent in response to the attacker's packet.
ok

>   needed to deal with extra entries that an attacker has inserted into the 

Good point, I renamed the section to "Routing Locator Reachability” and appended the following sentence:

        If an xTR chooses to periodically check with active probes the liveness
        of entries in its EID-to-RLOC cache (as described in section 6.3 of
        [RFC6830]), then this may amplify the attack that
        caused the insertion of entries being checked.                                                                             

Thanks

Damien Saucez

---

From: Ross Callon <[email-masked]>
Date: Thu, 26 Feb 2015 19:58:16 +0000

Thanks!

Ross

-----Original Message-----
From: Damien Saucez [mailto:[email-masked]] 
Sent: Thursday, February 26, 2015 1:39 PM
To: Ross Callon
Cc: Olivier Bonaventure; LISP mailing list list
Subject: Re: [lisp] Additional Points, RE: Progress on threats document

Hello,

ok

>   needed to deal with extra entries that an attacker has inserted into the 

Good point, I renamed the section to "Routing Locator Reachability" and appended the following sentence:

Thanks

Damien Saucez