Re: [lisp] WGLC draft-ietf-lisp-threats-08

[Damien Saucez <[e-mail]>]

On 05 Dec 2013, at 11:56, Albert Cabellos <[e-mail]> 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" <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/lisp
>>> 
>>> _______________________________________________
>>> lisp mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>> 
>