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

[Albert Cabellos]

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.




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.



Ok thanks!

Albert
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Florin Coras]

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


Florin

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

On 12/04/2013 09:28 PM, Albert Cabellos 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.
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.


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Damien Saucez]

On 05 Dec 2013, at 11:56, Albert Cabellos  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" 

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

[Albert Cabellos]

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.



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


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"  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 li

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

[Damien Saucez]

Hello Albert,

On 04 Dec 2013, at 21:28, Albert Cabellos  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 
> ."
> 
> 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"  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

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

[Albert Cabellos]

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

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:

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"  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
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp


___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Terry Manderson]

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


smime.p7s
Description: S/MIME cryptographic signature
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp