Hello Albert, On 04 Dec 2013, at 21:28, Albert Cabellos <[email protected]> wrote:
> Hi > > I went through the document in detail and IMHO it is well structured and > more importantly, it provides a complete and meticulous analysis of the > security threats of LISP on a public deployment. Thank you for the review Albert. > Below you can find some comments: > My answers inline. > Regards > > Albert > > > * Section 4.2->In addition to the attacks described in this section > end-hosts behind an ITR could use the data-plane to overflow the ITR's > Map-Cache by sending packets to non-popular EID prefixes (pretty much as > a scan attack but with a different goal). In this scenario the xTR may > evict entries from the map-cache that are popular (and in-use) and disrupt > the normal > operation of the network by forcing flows to miss. Florin will send a paper > describing and analyzing > in detail the attack and its impact on cache performance. > ok > * Section 4.3.2.1-->RFC6830 states (referring to LSB): > > "These bits are used as > a hint to convey up/down router status and not path reachability > status. The LSBs can be verified by use of one of the Locator > reachability algorithms described inSection 6.3 > <http://tools.ietf.org/html/rfc6830#section-6.3>." > > To which extent this is a security threat? xTRs will not blindly trust LSB. > > actually it is not a MUST not even a SHOULD in RFC6830 so it is important to emphasis on the risk. > * Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests, > hence there is a limit on the amplification attack. > I think the analysis is complementary to the recommendation. In RFC6830, no reason is given about why rate limit, here it shows why this is recommended. > > * Section 4.3.2.3->I´m having a hard time understanding this attack, > even under attack, the ETR will reply with the "real nonce", at least > once. Probably I´m missing something. > > sure but if an attacker floods with random nonce, then when the node will answer with the real nonce, it will already have been changed to another one sent by the attacker. > * Section 4.4.1-> In some cases the SMR-invoked Map-Request is sent > through the mapping system (not directly to the source RLOC), in this > case the attack is still effective and involves the Mapping System, the > Map-Server and the xTR (if operating in non-proxy mode). > I am not sure I understand your question here. > Editorial, please consider them suggestions, at the end it is a matter > of taste of the writer/reader. ok, will take them into account according to other reviews. > > 1. Introduction > > > > The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. > > specified instead of defined? > > > The present document assesses the security level and identifies > > security threats in the LISP specification if LISP is deployed in the > > Internet (i.e., a public non-trustable environment). As a result of > > the performed analysis, the document discusses the severity of the > > threats and proposes recommendations to reach the same level of > > security in LISP than in Internet today (e.g., without LISP). > > "(i.e., without LISP)" (not e.g.,) I understand that the authors are not > referring to an example. > > > This document does not consider all the possible uses of LISP as > > discussed in [RFC6830]. The document focuses on LISP unicast, > > including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and > > LISP Map-Versioning [RFC6834]. The reading of these documents is a > > prerequisite for understanding the present document. > > Several deployment scenarios are discussed in > draft-ietf-lisp-deployment, please consider citing it and discussing if > the use-cases described in the deployment draft are covered by this > analysis. > > > SA is an off-path attacker that is able to send spoofed packets, > > i.e., packets with a different source IP address than its > > assigned IP address. SA stands for Spoofing Attacker. > > SA attackers need access to the RLOC space, it might make sense to state > this here. > > > 4.3.1.2. Threats concerning Interworking > > > > [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow > > Edit "and" instead of "And" > > On 02/12/2013 3:02, Terry Manderson wrote: >> I would just like to highlight that the end of this LC draws near. >> >> Without review, this document cannot move forward. >> >> Cheers >> Terry >> >> On 20/11/13 9:23 AM, "Terry Manderson" <[email protected]> wrote: >> >>> All, >>> >>> As requested in Vancouver, the authors of draft-ietf-lisp-threats-08 have >>> requested a work group last call. >>> >>> Here starts a 14 day last call for this document, the last call will end >>> on >>> Wednesday 4th December 2013. >>> >>> You will find its text here: >>> http://tools.ietf.org/html/draft-ietf-lisp-threats-08 >>> >>> Please review this WG item and provide any last comments. >>> >>> Cheers >>> Terry >>> >>> >>> _______________________________________________ >>> 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
