Re: [lisp] John Scudder's No Objection on draft-ietf-lisp-sec-26: (with COMMENT)

[Luigi Iannone <[e-mail]>]

Hi John,

A few answers inline.

> On 15 Jun 2022, at 19:08, John Scudder via Datatracker <[e-mail]> wrote:
> 
> John Scudder has entered the following ballot position for
> draft-ietf-lisp-sec-26: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I generally found this a well-written and pleasant to read document. Thanks for
> the conversation around my earlier DISCUSS. I have a number of additional
> questions, comments, and suggestions, below.
> 
> 1. In §6.4,
> 
>   The ITR MAY use the KDF ID field to indicate the recommended KDF
>   algorithm, according to local policy.
> 
> I guess the use of MAY is there because the ITR could also put 0 in that field
> which we are later told (five paragraphs down) means "no preference" (and not
> literally no KDF at all, as a plain reading of the string "NONE" in Table 6
> would imply).
> 
> A few questions and suggestions arise from this:
> 
> a. If the ITR puts 0 in that field, and the Map-Server updates it, how should
> this text in §6.9 be interpreted?
> 
>                      If the KDF ID in the Map-Reply does not match the
>   KDF ID requested in the Map-Request, the ITR MUST discard the Map-
>   Reply
> 
> I guess the ITR didn't "request" any particular KDF ID when it sent 0, so I
> guess I can disregard the text I've quoted -- but it's not very clear.
> Certainly a plain field comparison without special-casing 0 would fail this
> test. I think there should be some update to clarify this case.
> 
> b. But what happens if the Map-Server puts in a KDF ID for a KDF the ITR
> doesn't support, even if the ITR did send 0? I presume that even though the ITR
> said "no preference" it still can't process the packet, so it has to discard
> the Map-Reply just as if it had gotten back a genuinely non-matching KDF ID. If
> this is so, I think there should be some update to clarify.
> 

They are both good points. The text can be clarified in the following way:

  If the ITR did indicate a preferred KDF ID in the Map-Request and the KDF ID 
  in the corresponding Map-Reply is different, or if the ITR did not indicate a 
  preferred KDF ID in the Map-Request and the KDF ID in the corresponding    
  Map-Reply is not supported, then the ITR MUST discard the Map-
  Reply

Would this be sufficiently clear?


> c. It seems like the string "No Preference" would be better than "NONE" in
> Table 6, similar for Table 4.

What about NOPREF? 

> 
> Similar comments apply to "The Requested HMAC ID field contains the suggested
> HMAC algorithm" (§6.4) and "If the EID HMAC ID field does not match the
> Requested HMAC ID" (§6.9).

Following the same line as in the previous case the text can be updated as:

 If the ITR did indicate a Requested HMAC ID in the Map-Request and the PKT HAMC ID 
  in the corresponding Map-Reply is different, or if the ITR did not indicate a 
  Requested HMAC ID in the Map-Request and the PKT HMAC ID in the corresponding    
  Map-Reply is not supported, then the ITR MUST discard the Map-
  Reply and send….

Would that work?

> 
> 2. Related to the previous, in Section 6.4, there are two fairly widely
> separated paragraphs:
> 
>   The ITR MAY use the KDF ID field to indicate the recommended KDF
>   algorithm, according to local policy.  The Map-Server can overwrite
>   the KDF ID if it does not support the KDF ID recommended by the ITR
>   (see Section 6.7).
> 
> And
> 
>   The KDF ID field specifies the suggested key derivation function to
>   be used by the Map-Server to derive the MS-OTK.  A KDF Value of NONE
>   (0) may be used to specify that the ITR has no preferred KDF ID.
> 
> I think it would be better if these were combined, as they seem to be redundant
> and in any case cover the same subject.

Looks reasonable. What about:

The ITR MAY use the KDF ID field to indicate the recommended KDF algorithm, 
according to local policy. The Map-Server can overwrite the KDF ID if it does not 
support the KDF ID recommended by the ITR (see Section6.7). A KDF value of 
NOPREF (0) may be used to specify that the ITR has no preferred KDF ID.


> 
> 3. For each of the fields whose value is taken from an IANA registry, I think
> it would be helpful to reference the registry where the field is defined, for
> example in Section 6.1,
> 
>      KDF ID: Identifier of the Key Derivation Function used to derive
>      the MS-OTK.  Refer to Section 6.7 for more details.
> 
> Could be
> 
>      KDF ID: Identifier of the Key Derivation Function used to derive
>      the MS-OTK.  Permitted values are registered in the Key
>      Derivation Function registry (see Section 8.5). Refer to
>      Section 6.7 for more details.

Yes, this makes things more precise.


> 
> Similarly for all five registries defined here and their respective fields.
> 
> 4. In §6.5,
> 
>   It's important to note that, to prevent ETR's overclaiming attacks,
>   the ITR/Map-Resolver pre-shared secret MUST be different from the
>   Map-Server/ETR pre-shared secret.
> 
> This is a bit picky, but wouldn’t “independent from” be more accurate? Strictly
> speaking to guarantee that it be different, they’d have to collude (to check
> for uniqueness), which is exactly what you want to prevent, right?

What a catch! Absolutely correct.


> 
> 5. In §6.9, this paragraph is problematic in a few ways,
> 
>   In response to an encapsulated Map-Request that has the S-bit set, an
>   ITR MUST receive a Map-Reply with the S-bit set, that includes an
>   EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
>   ITR MUST discard it.  In response to a Protected Map-Request, an ITR
>   expects a Map-Reply with the S-bit set to 1 including an EID-AD and a
>   PKT-AD.  The ITR MUST discard the Map-Reply otherwise.
> 
> The MUST in the second line is misused -- you aren't telling the ITR what it
> MUST do, you're expressing an expectation that if the other entities are
> forming their messages per-spec, the Map-Reply will be formed as you state. You
> already have more actionable language later in the paragraph to cover this
> case, the "MUST discard" part.

Actually this is an editorial mistake. The second sentence is a reformulation of the first one (actually suggested by Alvaro), it is just that the  first sentence has not been deleted….

> 
> Beyond that, the paragraph is redundant, it says everything twice. If you throw
> away the redundant text, I think the problem I'm complaining of goes away, for
> example you could cut it down to:
> 
>   In response to a Protected Map-Request, an ITR
>   expects a Map-Reply with the S-bit set to 1 including an EID-AD and a
>   PKT-AD.  The ITR MUST discard the Map-Reply otherwise.

Indeed.

> 
> 6. In §6.9, the phrase "the first opportunity it needs to" is used several
> times, for example,
> 
>   If the EID HMAC ID field does not match the Requested HMAC ID the ITR
>   MUST discard the Map-Reply and send, at the first opportunity it
>   needs to, a new Map-Request with a different Requested HMAC ID field,
>   according to ITR's local policy.
> 
> I don't understand the "needs to" part, I suspect there is some nuance going on
> here, of trying to shoehorn LISP-SEC into the control plane in some
> backward-compatible way, but if so the chosen language is too subtle to be
> unambiguous.
> 

AFAICT this is very bad wording for the fact that there is rate limitation policies to respect.

The text should be “according to rate limitation policies defined in [I-D.ietf-lisp-rfc6833bis]"



> To try to work through some of the possibilities --
> 
> - Leaving out the entire clause "at the first opportunity it needs to" would be
> clear. It would mean that the ITR is supposed to retry right away. Which seems
> fine, but is probably not what you're going for (else why have that clause at
> all).
> 
> - Leaving out the words "it needs to" would be the same as the above.
> 
> - So, maybe what's being said here is something like, "we expect that an event
> on the ITR will trigger it to retry anyway, and we're just piggybacking onto
> that event"?
> 
> If that's right, I guess what the ITR is expected to do is something like:
> 
> - When it needs to look up a given EID, launch a Map-Request.
> - If it gets back a Map-Reply with a different HMAC ID or KDF ID from what it
> sent (except, maybe not in the case where it sent 0, see my earlier question),
> do something like keep a notation in a local cache, that says "next time you
> send a Map-Request for this EID, try this other KDF ID". - Presumably in the
> mean time it might have dropped some packets destined to that EID, depending on
> other details of the deployment. - At some point it needs to look up that EID
> again (maybe because it has another packet to deliver) and before launching a
> new Map-Request it consults its cache and says "aha, I need to use a HMAC
> ID/KDF ID other than my default one".
> 
> The fact that I'm guessing about all this suggests that the spec may not be
> clear enough on these points. (Or that I'm not reading carefully enough, of
> course, in which case please point me to the parts I've missed that make it
> clear.)
> 
> 7. Nit, §6.9,
> 
>   [I-D.ietf-lisp-rfc6833bis] allows ETRs to send Solicited-Map-Requests
> 
> Should be "Solicit", not "Solicited".
> 

Indeed.


> 8. In §6.9,
> 
>                                           If an ITR accepts Map-Replies
>   piggybacked in Map-Requests and its content is not already present in
>   its EID-to-RLOC cache, it MUST send a Map-Request over the mapping
>   system in order to verify its content with a secured Map-Reply.
> 
> Does this mean,
> 
> a. The piggybacked Map-Reply will be put into use immediately by the ITR, but a
> verification will be initiated with a secured Map-Reply? How long is the
> piggybacked one to be used? What happens if the secured transaction never
> completes? If this is the intention, it needs to be clarified and probably also
> discussed in the Security Considerations, because it's not hard to imagine an
> attacker abusing it. Or is it,
> 
> b. The piggybacked Map-Reply is not permitted to be used until it has been
> verified by a secured Map-Reply? It would be considerably less problematic in
> terms of security analysis (it's functionally almost the same as the operation
> of LISP-SEC without piggybacked replies) but less optimal of course.
> 
> In either case the spec needs to be clarified.

It is the second case. Text can be modified as:

 If an ITR accepts Map-Replies
  piggybacked in Map-Requests and its content is not already present in
  its EID-to-RLOC cache, it MUST send a Map-Request over the mapping
  system in order to verify its content with a secured Map-Reply, before using the content.

Do you consider this sufficient or should be expressed differently?


> 
> 9. There are four places in §6.9.1 where you say "a log action MUST be taken".
> I wonder if these unintentionally open a resource exhaustion attack vector,
> since an attacker might be able to cause an ITR to log like crazy, and logging
> is often an expensive operation. I guess it depends on just how nuanced you
> expect the implementor to be in construing what a "log action" is -- if I
> decide to construe "log action" to implicitly include "with rate limiting" then
> that's potentially fine, but if I'm a naive implementor and just syslog every
> time the spec tells me to take a log action, I may be setting myself up as a
> soft target.
> 
> Maybe SHOULD instead of MUST would be a middle ground?

What about:

A log action SHOULD be taken. Implementations may include mechanisms 
(Which are beyond the scope of this document) to avoid log resource exhaustion attacks. 



> 
> 10. By the way, none of the "Receiving a Map-Reply" text talks about other
> checks. For example, before doing any of the checks specified in §6.9 one might
> imagine an implementation would first confirm it's even expecting this
> Map-Reply (presumably looking for a matching unfulfilled Map-Request), and
> throw it away if not. I briefly looked to see if that's in rfc6833bis but
> without success. Is the assumption that the checks in §6.9 are performed after
> other checks that are specified in the base control plane?
> 

OTK and Nonce are used for such verification.
Nonce as method to detect unsolicited Map-Reply is already defined in 6833bis.
Section 6.4 state that the OTK is used together with the nonce for the same purpose. 


> 11. In §7.6, Replay Attacks, you say
> 
>   In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR
>   will have to do a LISP-SEC computation.  This is equivalent, in terms
>   of resources, to a valid LISP-SEC computation and an attacker does
>   not obtain any benefit, since the corresponding Map-Reply is
>   discarded as previously explained.
> 
> How does the attaker "not obtain any benefit"? Suppose the benefit the attacker
> is trying to obtain, is to DoS the mapping system or ETR -- aren't they able to
> use these replayed Map-Requests to force these entities to do work?
> 

I do agree. May be changing the text as:

This is equivalent, in terms
  of resources, to a valid LISP-SEC computation and, beyond a risk of DoS attack, 
  an attacker does not obtain any additional effect, 
  since the corresponding Map-Reply is discarded as previously explained.


> 12. In §7.7 you say
> 
>   DTLS [RFC9147] SHOULD be used to provide communication privacy and to
>   prevent eavesdropping, tampering, or message forgery to the messages
>   exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless
>   the OTK is encrypted in another way, e.g. using a pre-shared secret.
> 
> Elsewhere in the spec this is a MUST, for example §6.5:
> 
>   2.  If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected
>       and DTLS is not enabled, the Map-Request MUST be dropped and an
>       appropriate log action SHOULD be taken.
> 
> Probably in §7.7 you should similarly say MUST, then?

May be is the other way around:

In §7.7 you SHOULD use DTLS unless something else is used to encrypt the OTK
In §6.5 says that you drop the packet if DTLS is not used and LISP encryption is not used, but you can actually protect the packet with something else.
§6.5 should be:

2.  If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected
      and no other encryption mechanism (e.g. DTLS) is enabled, the Map-Request MUST be dropped and an
      appropriate log action SHOULD be taken.

Better?

> 
> 13. There are many Specification Required registries that don't have guidance
> to designated experts, as requested by RFC 8126 §4.5 (which is referenced by
> RFC 8126 §4.6, which says Specification Required is just a fancy version of
> Expert Review). Likewise there's no field for change controller. Please
> consider adding these.

You mean adding the experts name directly in the document?
Isn’t sufficient that IANA put their name in the registry? Also because they may change in time.
RFC8126 states:

For registries created by RFCs in the IETF stream,
   change control for the registry lies by default with the IETF, via
   the IESG.  The same is true for value registrations made in IETF-
   stream RFCs.

I interpret as there is no real need to specify something different from the default. 
But if you think that would better this can be done at the beginning of the section.


Thanks 

Ciao

L.


> 
> 
>