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:
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" <terry.mander...@icann.org> 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

Reply via email to