On 05 Dec 2013, at 11:56, Albert Cabellos <[email protected]> wrote:
> Hi, > > On 04/12/2013 22:40, Damien Saucez wrote: > > [snip] >>> * 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. >> > I agree, but the text seems to suggest that the amplification attack scales > linearly and it is bounded to the maximum bandwidth (in control messages per > second) of the attacker, this is not true. The attack is bounded by the > rate-limit set at the xTR. > >>> >>> * 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. >> > > Right, thanks. What about recommending that each nonce should be used at > least once? So that a nonce can´t be overwritten if it has not been used. > Isn't that the definition of a nonce? I don't see how it helps. Imagine - Legit sends Nonce1 - Bad guy sends Nonce2 with spoof address of Legit - Nonce1 arrives, but it is too late, it has been overridden by Nonce2 already so the return with Nonce1is just ignored. >>> * 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. >> > > I´m referring to this paragraph: > > " The Map-Request message may also contain the SMR bit. Upon reception > of a Map-Request message with the SMR bit, an ETR must return to the > source of the Map-Request message a Map-Request message to retrieve > the corresponding mapping. This raises similar problems as the RLOC > record P bit discussed above except that as the Map-Request messages > are smaller than Map-Reply messages, the risk of amplification > attacks is reduced. " > > In some cases the SMR-invoked Map-Request is sent through the Mapping System > (RFC6830): > > " If the source Locator is the only > Locator in the cached Locator-Set, the remote ITR SHOULD send a > Map-Request to the database mapping system just in case the > single Locator has changed and may no longer be reachable to > accept the Map-Request." > So my point is that the attack is similar (true) but in some cases the > amplification attack is through the Mapping System. Again the attack is > bounded by the rate-limit set the xTR. In my view this should be also stated. ok, we could say so Damien Saucez > > Regards > > Albert >> >>> 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
