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