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
