Re: [lisp] Additional Points, RE: Progress on threats document

[Damien Saucez <[e-mail]>]

Hello,

On 26 Feb 2015, at 02:27, Ross Callon <[e-mail]> wrote:

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

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.

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

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

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 

> Thanks, Ross
> 
> -----Original Message-----
> From: Damien Saucez [mailto:[e-mail]] 
> 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,
> 
> Thank you for the feedback.
> 
> Answers and propositions inline.
> 
> On 14 Feb 2015, at 04:02, Ross Callon <[e-mail]> 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 a
> mp
>> 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 [mailto:[e-mail]] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
> 
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp