Hello,
On 26 Feb 2015, at 02:27, Ross Callon <[email protected]> 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:[email protected]]
> 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 <[email protected]> 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:[email protected]] 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 protected]
>> https://www.ietf.org/mailman/listinfo/lisp
>>
>> _______________________________________________
>> lisp mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lisp
>
> _______________________________________________
> lisp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
