Thanks Dino, we will update the text accordingly.
Fabio
On 9/22/17 9:57 PM, Dino Farinacci wrote:
The text looks good. I would just suggest on editorial change, substitute
“Let’s consider” with “Consider”.
Thanks,
Dino
On Sep 20, 2017, at 11:12 PM, Fabio Maino <[email protected]> wrote:
Hi Dino,
thanks for the comments.
Here is the edited text:
6. Replay Attacks
Replay attacks against LISP-SEC can be mounted by either (1) re-sending a valid
Map-Reply to the ITR, or (2) re-sending a valid Map-Request to the
Map-Resolver, Map-Server, or ETR.
In order to understand LISP-SEC protection from replay attacks it's important to note
that an ITR, upon receiving a valid Map-Reply, MUST discard the <nonce,ITR-OTK>
pair stored at the ITR that corresponds to the nonce in the received valid Map-Reply.
Let's consider first the case when the replay attack is mounted replaying a Map-Reply. The
ITR, upon receiving the replayed Map-Reply, will try to match the Map-Reply's nonce with
the list of stored <nonce,ITR-OTK> pairs. Since the <nonce,ITR-OTK> pair was
removed when the valid Map-Reply arrived at the ITR, the replayed Map-Reply will be
discarded defeating the replay attack.
Let's consider now the case when the replay attack is mounted replaying a Map-Request
message to either a Map-Resolver, a Map-Server, or an ETR. The replayed Map-Request message
will be processed as any other Map-Request message by the Map-Resolver, Map-Server, and
ETR, and will generate a replayed Map-Reply that eventually reaches the ITR. However, the
ITR upon receiving the replayed Map-Reply, will try to match the Map-Reply's nonce with the
list of stored <nonce,ITR-OTK> pairs. Since the <nonce,ITR-OTK> pair was
removed when the valid Map-Reply arrived at the ITR, the replayed Map-Reply will be
discarded defeating the replay attack.
Please also note that point (3) is not really an issue, as a valid message and
a replayed message are indistinguishable by definition. Whichever arrives first
is the valid message, and all the subsequent ones are replay attacks.
Fabio
On 9/20/17 12:08 PM, Dino Farinacci wrote:
I have a comment on this newly added paragraph:
<PastedGraphic-72.png>
I don’t think it reads clearly. Here are my comments:
(1) First sentence, I think you mean “replay it” versus “reply it”.
(2) You should talk separately of a replayed Map-Request and then a replayed
Map-Reply. Combining it makes it confusing on which case the ITR discards a
Map-Reply. Because a Map-Reply is not responded to by a replayed Map-Reply so
it can only mean a replayed Map-Reqeust.
(3) And if the replayed Map-Reply returns to the ITR BEFORE the one from the
non-attacker, it cannot tell if the Map-Reply was from a non-attacker or an
attacker. So you need to explain what happens in both cases (where the simple
case is already in the text above).
(4) What is a “LISP-SEC computation”? That needs to be made more clear.
Please clarify this section. It needs it.
Dino
On Sep 20, 2017, at 10:54 AM, The IESG <[email protected]> wrote:
The IESG has received a request from the Locator/ID Separation Protocol WG
(lisp) to consider the following document: - 'LISP-Security (LISP-SEC)'
<draft-ietf-lisp-sec-13.txt> as Experimental RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email protected] mailing lists by 2017-10-04. Exceptionally, comments may be
sent to [email protected] instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.
Abstract
This memo specifies LISP-SEC, a set of security mechanisms that
provides origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
process. LISP-SEC also enables verification of authorization on EID-
prefix claims in Map-Reply messages.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/
IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/ballot/
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
