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

[John Scudder via Datatracker <[e-mail]>]

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.

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

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).

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.

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.

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?

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.

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.

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.

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".

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.

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?

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?

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?

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?

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.