Hi All, Some general comments, followed by a few more detailed/minor suggestions. Thanks to the authors for a very thorough analysis.
Best, Vina General Comments: - Abstract: Draft reads: "This document analyzes the threats against the security of the Locator/Identifier Separation Protocol (LISP) and proposes a set of recommendations to mitigate some of the identified security risks." Suggestion: This leaves the reader unclear about what the security state would be after following the recommendations by this draft. Adding a sentence such as the following is helpful: "By following the recommendations of this draft a LISP deployment can achieve a security level that is comparable to the existing Internet architecture." - 6.Control Plane Threats Section 6 talks about control plane threats. A reference to LISP-SEC in this section seems appropriate. The first 5-6 sections of the threat analysis draft were originally written before the LISP-SEC draft was introduced and adopted by the WG (and hence they were very much impact-full). It would be very helpful if the current version however points out the security properties LISP-SEC brings to LISP, for instance adding a sentence to 6.2 to this effect: "By enabling LISP-SEC Map-Reply based threats are alleviated.". - 5.2.1. EID-to-RLOC Cache Poisoning The draft is pointing out that the list of cache poisoning examples here are mostly enabled by (1) gleaning and (2) attacking the control plane. >From attacks listed in the control plane in section 6, (a) Map-Reply based attacks as well as (b) adding Map-Reply data to a Map-Request can lead to these cache poisoning attacks. From these, Map-Reply based attacks are alleviated by adopting LISP-SEC. It may be very helpful to bring this information out by adding a summary at the end of this subsection noting that: "By disabling gleaning and piggybacked Map-Replies, and enabling LISP-SEC, most (if not all) of the cache poisoning threats are mitigated." - 11. Suggested Recommendations Many of the recommendations here are regarding removing risky optimizations such as gleaning, piggybacked Map-Replies, etc. Depending on the security requirements of a specific LISP deployment, these risks may be acceptable. To clarify this, it may be helpful to add a paragraph in the beginning of this section to the following effect: "Different deployments of LISP may have different security requirements. The recommendations in this section mitigate the threats enumerated in this document." - 11. Suggested Recommendations - Last paragraph, page 27: Page 27 reads: "In [I-D.ietf-lisp], there is no mechanism that allows an xTR to verify the validity of the content a Map-Reply message that it receives. Besides the attacks discussed earlier in the document, a time-shifted attack where an attacker is able to modify the content of a Map-Reply message but then needs to move off-path could also create redirection attacks. The nonce only allows an xTR to verify that a Map-Reply responds to a previously sent Map-Request message. In order to allow verifying the validity and integrity of bindings between EID-Prefixes and their RLOCS solutions proposed in [I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be deployed. Having such kind of mechanisms would allow ITRs to ignore non-verified mappings, thus increasing security." I think the last sentence can be much stronger. Having LISP-SEC and lisp-mapping-security in place would alleviate all the threats raised in this paragraph. Detailed/minor comments: 1. Introduction Draft reads: "The document is composed of two main parts: the first discussing the LISP data plane; while the second discussing the LISP control-plane." Suggestion: A third, and important, part is the Recommendations part. 5.2.2. EID-to-RLOC Cache Overflow It may be very helpful if a summary paragraph is added pointing out that "Disabling gleaning and enabling LISP-SEC would protect against the threats enumerated in this section." 5.3 Last paragraph of this section is more of a suggestion/recommendation. Same for last paragraphs of section 7. I think it would be helpful in general if the recommendation information through-out the draft is called out , perhaps by adding a Mitigations/Recommendations label to the beginning of such paragraphs. 8. Threats with Malicious xTRs Draft reads: "The current LISP specification briefly discusses the overclaiming problem [I-D.ietf-lisp], but does not propose any specific solution to solve the problem. Nevertheless, [I-D.ietf-lisp-sec] proposes a solution to protect LISP against overclaiming attacks under the assumption that the mapping system can be trusted." The last sentence seems a little vague. I suggest changing it to something like this: " By enabling [I-D.ietf-lisp-sec] overclaiming attacks are mitigated under the assumption that the mapping system can be trusted." 10.1 Map-Server Page 24 reads: "Similarly to the previous case, a malicious ETR can register an invalid EID-prefix to attract Map-Requests or to redirect them to a target to mount a DoS attack. To avoid this kind of attack, the Map Server must check that the prefixes registered by an ETR belong to that ETR. One method could be to manually configure EID-prefix ranges that can be announced by ETRs." This is already done today and is explained in the Mapping System draft, right? Perhaps this paragraph can be removed. 10.2 Map-Resolver Page 25 reads: "A possible way to limit the above-described attacks is to introduce strong identification in the Map-Request/Map-Reply by using the Encapsulated Control Message with authentication enabled." Are you referring to LISP-SEC here? Calling it out may be helpful. 11. Suggested Recommendations Title of this section seems repetitive. "Security Recommendations" or just "Recommendations" may be better alternatives. 11. Page 27 reads: "In order to allow verifying the validity and integrity of bindings between EID-Prefixes and their RLOCS solutions proposed in [I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be deployed. Having such kind of mechanisms would allow ITRs to ignore non-verified mappings, thus increasing security." A minor technical question: is it ok to use "should" in "In order to allow verifying the validity and integrity of bindings between EID-Prefixes and their RLOCS solutions proposed in [I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be deployed. ", considering that [I-D.saucez-lisp-mapping-security] is an independent draft? Perhaps should is too strong, "could" may be a better choice here? _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
