Subject: Re: [lisp] Last Call: <draft-ietf-lisp-sec-13.txt> (LISP-Security (LISP-SEC)) to Experimental RFC

From: Dino Farinacci <[email-masked]>
Date: Wed, 20 Sep 2017 12:08:06 -0700

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 <[email-masked]> 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-masked] mailing lists by 2017-10-04. Exceptionally, comments may be
> sent to [email-masked] 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-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Fabio Maino <[email-masked]>
Date: Wed, 20 Sep 2017 23:12:56 -0700

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:
> (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).
>
>> On Sep 20, 2017, at 10:54 AM, The IESG <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>
>> [email-masked] <mailto:[email-masked]> mailing lists by 2017-10-04. 
>> Exceptionally, comments may be
>> sent to [email-masked] <mailto:[email-masked]> instead. In either case, 
>> please retain the beginning of

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 22 Sep 2017 21:57:21 -0700

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-masked]> 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
> 
>

---

From: Fabio Maino <[email-masked]>
Date: Sun, 24 Sep 2017 20:12:20 -0700

Thanks Dino, we will update the text accordingly.

Fabio