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

From: Terry Manderson <[email-masked]>
Date: Sun, 1 Dec 2013 18:02:11 -0800

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-masked]> 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

---

From: Albert Cabellos <[email-masked]>
Date: Wed, 04 Dec 2013 21:28:56 +0100

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.
Below you can find some comments:

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.

* 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.

* Section 4.3.2.2->RFC6830 already recommends rate-limiting Map-Requests,
hence there is a limit on the amplification attack.

* 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.

* 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).

Editorial, please consider them suggestions, at the end it is a matter
of taste of the writer/reader.

 > 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:
>> _______________________________________________
>> lisp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lisp

---

From: Damien Saucez <[email-masked]>
Date: Wed, 4 Dec 2013 22:40:54 +0100

Hello Albert,

> security threats of LISP on a public deployment. 

Thank you for the review Albert.

> Below you can find some comments:

My answers inline.

> 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

ok

> 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.

> 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.

> 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.

> Map-Server and the xTR (if operating in non-proxy mode).

I am not sure I understand your question here.

> of taste of the writer/reader.

ok, will take them into account according to other reviews.

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 05 Dec 2013 11:56:06 +0100

Hi,

On 04/12/2013 22:40, Damien Saucez wrote:

[snip]
> RFC6830, no reason is given about why rate limit, here it shows why
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.

> 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.

> 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.

Regards

Albert
>>> On 20/11/13 9:23 AM, "Terry Manderson"<[email-masked]>  wrote:
>>>
>>>> All,
>>>>
>> [email-masked] <mailto:[email-masked]>

---

From: Damien Saucez <[email-masked]>
Date: Fri, 6 Dec 2013 00:05:25 +0100

On 05 Dec 2013, at 11:56, Albert Cabellos <[email-masked]> wrote:

> 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.
> 
>>> 
> 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.

> In some cases the SMR-invoked Map-Request is sent through the Mapping System (RFC6830):
> 
> 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

---

From: Florin Coras <[email-masked]>
Date: Mon, 09 Dec 2013 15:12:28 +0100

Apologies for the belated reply. The paper Albert was referring to can 
be found at [1].

Florin

[1] <http://arxiv.org/abs/1312.1378>http://arxiv.org/pdf/1312.1378v2.pdf

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 09 Dec 2013 17:00:54 +0100

Hi,

On 06/12/2013 0:05, Damien Saucez wrote:

[snip]

>> 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.
>>
>

Ok thanks!

Albert