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