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:
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 <iesg-secretary@xxxxxxxx>
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
ietf@xxxxxxxx
mailing lists by 2017-10-04. Exceptionally, comments may be
sent to iesg@xxxxxxxx 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
lisp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/lisp
|
