Thanks! Ross
-----Original Message----- From: Damien Saucez [mailto:[email protected]] 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, 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
