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