Re: [lisp] AD Review of draft-ietf-lisp-sec-25

Alvaro Retana <aretana.ietf@gmail.com> Tue, 24 May 2022 15:52 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EBAC19D46C; Tue, 24 May 2022 08:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOH75KyTQS24; Tue, 24 May 2022 08:52:44 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EA9C19D46A; Tue, 24 May 2022 08:52:44 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id p5-20020a1c2905000000b003970dd5404dso1679980wmp.0; Tue, 24 May 2022 08:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nNPAPBBtcwdyeDEH3sgOdqsKMZLt0gsFmVbSm92dnIc=; b=UmMc26qJCdvUxGjqEP8GB8RT61tzobrDBgi/FI6Mjc+sreshJZPV3bApJOTBnfOjXA 27kSSQ2EOP4g5/EIR0Sc8O9qjQ9LtQYkMk7a6Z61Dhg+7QpjCvAAX0lSOnCQUKwfqC5b /b1GogL/WqzPuhx+JUkyt/VcV+GvnImIpuHqg9BL3LXPymFhv46SBKpehiPq70mImKF1 11+PnbNUHVD4fpdey7vnuLtMQuzmE18vnApNQswYKCFCsBimFrmJGIluubhQXfXE1Oo4 0XGkTJvD8R1TULU0ffD4XneoT4cK2wxSSH3bBSggc51FbSXQfeQqiq6eRjCgFLp1tQ3n yRKw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=nNPAPBBtcwdyeDEH3sgOdqsKMZLt0gsFmVbSm92dnIc=; b=7cwaiCzanmtFwji0dC7zIBSVTWDkc1xRA32zwlh4lCCfVueU0DeHvGAO8JJjL2MvfW mfFvmP7GZmE6ju661Jw6VjUpdFfcQaynisGYKBK6YaiSDHxTDGtdJSKSX21bySqtaUP3 XwiYjqETCX+deDyv7yG6cND1dEWGJ9HlMDsN80C3s3GLHAoSyyRT6LZzwSbNEgk10pE2 aWEVDR1tZaMTt7R16bpy7WXgig1ENXLhioFw+Fa3gnBitvR6K8jsLV9S14Df8UxY8BGY Mnn3CmAF8V1QYRTnmwuANMqM0LIxulHEVDv0ZvP7MPiEp57yJFkLuOpj5Bt/7c1+wY6O J6iQ==
X-Gm-Message-State: AOAM5302Cq7E5glrMraQoGK6GPXgmrLlj4pVR89VxSHyDEm1bZZXl2O1 JM/AkGXfpoJTRvVVv08eYRz/Q2tbnZtSU4VkZdY=
X-Google-Smtp-Source: ABdhPJxuw70fIeM8qK1vfqFWvRyhcbp+XucocKCfcnHtD0yeoy1BhWBq5O1BHHFzttu5t80IAYlpoFrr0SRFsrEOYbA=
X-Received: by 2002:a05:600c:1492:b0:397:4afc:cc76 with SMTP id c18-20020a05600c149200b003974afccc76mr4309021wmh.124.1653407562058; Tue, 24 May 2022 08:52:42 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 24 May 2022 11:52:41 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <40D8B1AC-8BEA-493E-9AC7-CC809114A29B@gigix.net>
References: <CAMMESszR8Sz9vArweC7W3WYHC45wkKGPhZTqaRVMb6d0hwWwRA@mail.gmail.com> <CAMMESsyj-3sRyMfOieqqid1JFuBJG5v5px9cMz0FWvbVgOA03Q@mail.gmail.com> <EDCC413C-57ED-4D2C-BCE8-95C7C45AA39F@cisco.com> <40D8B1AC-8BEA-493E-9AC7-CC809114A29B@gigix.net>
MIME-Version: 1.0
Date: Tue, 24 May 2022 11:52:41 -0400
Message-ID: <CAMMESszi852=iWhcgRoBmQRAi-Bkbfw3iB7e=mptsPruxuXTfw@mail.gmail.com>
To: Luigi Iannone <ggx@gigix.net>, "Fabio Maino (fmaino)" <fmaino@cisco.com>
Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "draft-ietf-lisp-sec@ietf.org" <draft-ietf-lisp-sec@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000067d32505dfc3f207"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/xCL9vThjvA9xL2W6Yc2GEAKNPFY>
Subject: Re: [lisp] AD Review of draft-ietf-lisp-sec-25
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2022 15:52:48 -0000

Hi!

Any progress?

We don’t have a lot of wiggle room left if we want to get this document
approved by July.

Alvaro.

On May 3, 2022 at 2:55:36 AM, Luigi Iannone (ggx@gigix.net) wrote:

Hi,

Yes, indeed. I am helping Damien in going through the review.
I am currently on vacation, but I am positive we can converge next week and
send out an update.

Ciao

L.



> On 28 Apr 2022, at 18:30, Fabio Maino (fmaino) <fmaino@cisco.com> wrote:
>
> Thanks Alvaro,
> I believe Damien and Luigi are already taking a first pass.
>
> After a quick review between the authors, we should be able to return it
back to you.
>
> Fabio
>
> On 4/28/22, 9:17 AM, "Alvaro Retana" <aretana.ietf@gmail.com> wrote:
>
> Hi!
>
> I'm just moving this message up in people's mailer to make sure everyone
> saw it.
>
> If you’re already working in it, sorry for the interruption.
>
> Alvaro.
>
> On April 21, 2022 at 3:27:18 PM, Alvaro Retana (aretana.ietf@gmail.com)
> wrote:
>
>
> Dear authors:
>
> Thank you for the work on this document!
>
> I put detailed comments inline below.
>
> As we have a constrained timeline for this document, I would like to
start
> the IETF Last-Call in no more than a couple of weeks. I don't think my
> comments will be hard to address. In fact, there are comments that I
> repeat in different sections, and some overlap.
>
> Please reply inline to this message to expedite my review of any updates.
> Also, if you think talking would clear things up faster, feel free to
find
> time on my calendar: https://doodle.com/mm/alvaroretana/book-a-time
>
> Thanks!
>
> Alvaro.
>
>
> [Line numbers from idnits.]
>
> ...
> 15 Abstract
>
> 17 This memo specifies LISP-SEC, a set of security mechanisms that
> 18 provides origin authentication, integrity and anti-replay protection
> 19 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
> 20 process. LISP-SEC also enables verification of authorization on EID-
> 21 prefix claims in Map-Reply messages.
>
> [nit] s/via mapping lookup process/via the mapping lookup process/g
>
>
> ...
> 100 1. Introduction
> ...
> 120 This memo specifies LISP-SEC, a set of security mechanisms that
> 121 provides origin authentication, integrity and anti-replay protection
> 122 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
> 123 process. LISP-SEC also enables verification of authorization on EID-
> 124 prefix claims in Map-Reply messages, ensuring that the sender of a
> 125 Map-Reply that provides the location for a given EID-prefix is
> 126 entitled to do so according to the EID prefix registered in the
> 127 associated Map-Server. Map-Register/Map-Notify security, including
> 128 the right for a LISP entity to register an EID-prefix or to claim
> 129 presence at an RLOC, is out of the scope of LISP-SEC as those
> 130 protocols are protected by the security mechanisms specified in
> 131 [I-D.ietf-lisp-rfc6833bis]. However, LISP-SEC extends the Map-
> 132 Register message to allow an ITR to securely downgrade to non LISP-
> 133 SEC Map-Requests. Additional security considerations are described
> 134 in Section 6.
>
> [major] "securely downgrade to non LISP-SEC Map-Requests"
>
> To "securely downgrade" to no security doesn't sound right to me. See
more
> comments in §6.7.
>
>
> ...
> 176 4. LISP-SEC Threat Model
>
> 178 LISP-SEC addresses the control plane threats, described in section
> 179 3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including
> 180 manipulations of Map-Request and Map-Reply messages, and malicious
> 181 ETR EID prefix overclaiming. LISP-SEC makes two main assumptions:
> 182 (1) the LISP mapping system is expected to deliver a Map-Request
> 183 message to their intended destination ETR as identified by the EID,
> 184 and (2) no man-in-the-middle (MITM) attack can be mounted within the
> 185 LISP Mapping System. How the Mapping System is protected from MITM
> 186 attacks depends from the particular Mapping System used, and is out
> 187 of the scope of this memo. Furthermore, while LISP-SEC enables
> 188 detection of EID prefix overclaiming attacks, it assumes that Map-
> 189 Servers can verify the EID prefix authorization at registration time.
>
> [] As part of the efforts to make the language in IETF documents more
> inclusive, consider using "on-path attack" instead of MITM. This term in
> already in use in some parts of this document.
>
> https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
>
>
> ...
> 202 5. Protocol Operations
> ...
> 210 LISP-SEC builds on top of the security mechanisms defined in
> 211 [I-D.ietf-lisp-rfc6833bis] to address the threats described in
> 212 Section 4 by leveraging the trust relationships existing among the
> 213 LISP entities participating to the exchange of the Map-Request/Map-
> 214 Reply messages. Those trust relationships are used to securely
> 215 distribute, as described in Section 8.4, a per-message One-Time Key
> 216 (OTK) that provides origin authentication, integrity and anti-replay
> 217 protection to mapping data conveyed via the mapping lookup process,
> 218 and that effectively prevent overclaiming attacks. The processing of
> 219 security parameters during the Map-Request/Map-Reply exchange is as
> 220 follows:
>
> [nit] s/participating to/participating in
>
>
> ...
> 245 1. The ITR, upon needing to transmit a Map-Request message,
> 246 generates and stores an OTK (ITR-OTK). This ITR-OTK is included
> 247 into the Encapsulated Control Message (ECM) that contains the
> 248 Map-Request sent to the Map-Resolver. ITR-OTK confidentiality
> 249 and integrity protection MUST be provided in the path between the
> 250 ITR and the Map-Resolver. This can be achieved either by
> 251 encrypting the ITR-OTK with the pre-shared secret known to the
> 252 ITR and the Map-Resolver (as specified in Section 6.5), or by
> 253 enabling DTLS between the ITR and the Map-Resolver.
>
> [major] "protection MUST be provided"
>
> Please specify things only once. In this case, because this section just
> "describes the flow", there's no need to specify anything in it, or go
into
> some of the details. The protection part is properly covered later in the
> document and is not necessary to be called out at this point.
>
>
> 255 2. The Map-Resolver decapsulates the ECM message, decrypts the ITR-
> 256 OTK, if needed, and forwards through the Mapping System the
> 257 received Map-Request and the ITR-OTK, as part of a new ECM
> 258 message. The LISP Mapping System delivers the ECM to the
> 259 appropriate Map-Server, as identified by the EID destination
> 260 address of the Map-Request. As mentioned in Section 4, how the
> 261 Mapping System is protected from MITM attacks depends from the
> 262 particular Mapping Systems used, and is out of the scope of this
> 263 memo.
>
> [minor] Anything "as mentioned in" can be left out of this description to
> avoid duplication.
>
>
> ...
> 275 4. The Map-Server derives a new OTK, the MS-OTK, by applying a Key
> 276 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is
> 277 included in the Encapsulated Control Message that the Map-Server
> 278 uses to forward the Map-Request to the ETR. MS-OTK
> 279 confidentiality and integrity protection MUST be provided in the
> 280 path between the Map-Server and the ETR. This can be achieved
> 281 either by encrypting the MS-OTK with the pre-shared secret known
> 282 to the Map-Server and the ETR (as specified in Section 6.5), or
> 283 by enabling DTLS between the Map-Server and the ETR.
>
> [major] "protection MUST be provided": Same comment as above: no need for
> this part here.
>
>
> ...
> 303 8. The ITR, upon receiving the Map-Reply, uses the locally stored
> 304 ITR-OTK to verify the integrity of the EID-prefix authorization
> 305 data included in the Map-Reply by the Map-Server. The ITR
> 306 computes the MS-OTK by applying the same KDF (as specified in the
> 307 ECM encapsulated Map-Reply) used by the Map-Server, and verifies
> 308 the integrity of the Map-Reply. If the integrity checks fail,
> 309 the Map-Reply MUST be discarded. Also, if the EID-prefixes
> 310 claimed by the ETR in the Map-Reply are not equal or more
> 311 specific than the EID-prefix authorization data inserted by the
> 312 Map-Server, the ITR MUST discard the Map-Reply.
>
> [major] "...MUST..."
>
> These details are not needed here.
>
>
> ...
> 322 6.1. Encapsulated Control Message LISP-SEC Extensions
> ...
> 358 V: Key Version bit. This bit is toggled when the sender switches
> 359 to a new OTK wrapping key
>
> [] I don't understand how this works. If the OTK doesn't change then this
> bit's value shouldn't change, is that it?
>
> [major - If so..] If so, what should a receiver do if the V bit didn't
> change but the OTK did? What if the OTK didn't change, but the V bit did?
>
>
> ...
> 363 Requested HMAC ID: The HMAC algorithm, that will be used to
> 364 protect the mappings, requested by the ITR. See Section 6.4 for
> 365 details, and Section 8.3 for HMAC IDs that MUST be supported.
>
> [major] §8.3 says this:
>
> AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be
> supported.
>
> However, (1) it is not good practice to include specifications in the
IANA
> Considerations section (only instructions to IANA should be included
> there), and, (2) the MUST/SHOULD combination doesn't match the MUST used
> here.
>
> Instead, please move the text (above + references to rfc2104/rfc6234)
from
> §8.3 to §6.4, and eliminate the reference to §8.3.
>
> Note that similar text is used in multiple places. Please update all.
>
>
> ...
> 377 OTK Wrapping ID: The identifier of the key derivation function and
> 378 of the key wrapping algorithm used to encrypt the One-Time-Key.
> 379 See Section 6.5 for more details, and Section 8.4 for Wrapping IDs
> 380 that MUST be supported.
>
> [minor] The figure uses ("OTK Wrap. ID"). I know that's just an
> abbreviation, but please include it here for completeness:
>
> s/OTK Wrapping ID:/OTK Wrapping ID (OTK Wrap. ID):
>
>
> [major] "and Section 8.4 for Wrapping IDs that MUST be supported."
>
> Same comment as above: please move the text from §8.4 to §6.5.
>
> BTW, §6.5 already has come text about requiring
> AES-KEY-WRAP-128+HKDF-SHA256, but not NULL-KEY-WRAP-128: this last
> algorithm is mentioned, but the text doesn't require it.
>
> Also, AES-KEY-WRAP-128 (without "+HKDF-SHA256") is mentioned separately,
> but not listed in the table in §8.4.
>
>
> 382 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When
> 383 the OTK is encrypted, this field MAY carry additional metadata
> 384 resulting from the key wrapping operation. When a 128-bit OTK is
> 385 sent unencrypted by Map-Resolver, the OTK Preamble is set to
> 386 0x0000000000000000 (64 bits). See Section 6.5.1 for details.
>
> [nit] s/by Map-Resolver/by a Map-Resolver
>
>
> ...
> 391 EID-AD Length: length (in bytes) of the EID Authentication Data
> 392 (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only
> 393 fills the KDF ID field, and all the remaining fields part of the
> 394 EID-AD are not present. An EID-AD MAY contain multiple EID-
> 395 records. Each EID-record is 4-byte long plus the length of the
> 396 AFI-encoded EID-prefix.
>
> [nit] s/set EID-AD Length/set the EID-AD Length
>
>
> [major] "ITR MUST set EID-AD Length to 4 bytes"
>
> What should the receiver do if the length is set to anything else?
>
> For messages not originated by the ITR, the length has to be more then 4.
> In fact, it has to be 12 + the length of EID-prefix (multiple may be
> present) + length of EID HMAC. What should a receiver do if the length is
> not appropriate?
>
> I don't remember seeing anything in rfc6833bis about error handling or
what
> to do about mismatched lengths in general. Did I miss it?
>
>
> 398 KDF ID: Identifier of the Key Derivation Function used to derive
> 399 the MS-OTK. The ITR MAY use this field to indicate the
> 400 recommended KDF algorithm, according to local policy. The Map-
> 401 Server can overwrite the KDF ID if it does not support the KDF ID
> 402 recommended by the ITR. See Section 5.4 for more details, and
> 403 Section 8.5 for KDF IDs that MUST be supported.
>
> [major] "Map-Server can overwrite the KDF ID if it does not support the
KDF
> ID recommended by the ITR"
>
> Specify things only once. The text in §6.7.1 is similar. See comments
> there.
>
>
> [minor] s/5.4/6.4/g
> §5.4 doesn't exist.
>
>
> [major] "Section 8.5 for KDF IDs that MUST be supported"
>
> Same comment as above: please move the text from §8.5 to §6.4.
>
>
> 405 Record Count: The number of records in this Map-Request message.
> 406 A record is comprised of the portion of the packet that is labeled
> 407 'Rec' above and occurs the number of times equal to Record Count.
>
> [major] Should there at least be one, or is it ok if the value is 0? If
at
> least one, what should a receiver do if no records are included?
>
>
> 409 E: ETR-Cant-Sign bit. This bit is set to 1 to signal to the ITR
> 410 that at least one of the ETRs authoritative for the EID prefixes
> 411 of this Map-Reply has not enabled LISP-SEC. This allows the ITR
> 412 to securely downgrade to non LISP-SEC requests, as specified in
> 413 Section 6.7, if so desired.
>
> [major] If I understand correctly, this bit should only ever be set by a
> Map-Server. Are there other cases where setting it would be valid?
>
> If this bit is set other than by a Map-Server, what should the receiver
do.
>
> Assuming my understanding is correct, please say something here about the
> Map-Server being the only one that can set the bit. §6.7 is about
> Map-Server processing, but the fact that it can set the bit doesn't
> explicitly preclude other from doing so.
>
>
> [minor] s/This allows the ITR to securely downgrade to non LISP-SEC
> requests, as specified in Section 6.7, if so desired./See Section 6.7 for
> more details.
>
>
> ...
> 417 EID HMAC ID: Identifier of the HMAC algorithm used to protect the
> 418 integrity of the EID-AD. This field is filled by Map-Server that
> 419 computed the EID-prefix HMAC. See Section 5.4 for more details,
> 420 and Section 8.3 for HMAC IDs that MUST be supported.
>
> [nit] s/by Map-Server/by the Map-Server
>
>
> [major] "Section 8.3 for HMAC IDs that MUST be supported"
>
> Same comment as above: please move the text from §8.3 to §6.4.
>
>
> 422 EID mask-len: Mask length for EID-prefix.
>
> 424 EID-AFI: Address family of EID-prefix according to [AFN].
>
> 426 EID-prefix: The Map-Server uses this field to specify the EID-
> 427 prefix that the destination ETR is authoritative for, and is the
> 428 longest match for the requested EID.
>
> [major] These 3 fields, which are part of the "Rec", are the same as what
> is specified in §5.2/rfc6833bis. But the descriptions are different, and
> the EID-AFI names doesn't match EID-Prefix-AFI. Please point at the
> definitions in rfc6833bis:
>
> EID mask-len: As defined in §5.2/rfc6833bis.
> ...
>
>
> 430 EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server.
> 431 Before computing the HMAC operation the EID HMAC field MUST be set
> 432 to 0. The HMAC MUST cover the entire EID-AD.
>
> [major] s/by Map-Server/by a Map-Server
>
>
> [major] "Before computing the HMAC operation the EID HMAC field MUST be
set
> to 0. The HMAC MUST cover the entire EID-AD."
>
> §6.7.1 describes the same operation, but without using Normative
language:
>
> The scope of the HMAC operation covers the entire EID-AD, from the
> EID-AD Length field to the EID HMAC field, which must be set to 0
> before the computation.
>
> Please specify things only once! It seems to me that it may be more
> appropriate to include the specification in §6.7.1 (Generating a LISP-SEC
> Protected Encapsulated Map-Request).
>
>
> 434 6.2. Map-Reply LISP-SEC Extensions
> ...
> 464 MR AD Type: 1 (LISP-SEC Authentication Data). See Section 8.
>
> [] Just wondering... Why are separate registries used for ECM AD Type and
> MR AD Type? Are you expecting so many extensions that a single space
won't
> be enough?
>
>
> 466 EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY
> 467 contain multiple EID-records. Each EID-record is 4-byte long plus
> 468 the length of the AFI-encoded EID-prefix.
>
> [] It looks like you're mostly redefining the same fields as in the last
> section, at least for the EID-AD and Rec. Please point at the definitions
> there instead of redefining again here. If there are
exceptions/variations
> that are east to call out then just mention those here.
>
> Otherwise, the comments from the last section apply here too.
>
>
> 470 KDF ID: Identifier of the Key Derivation Function used to derive
> 471 MS-OTK. See Section 6.7 for more details, and Section 8.5 for KDF
> 472 IDs that MUST be supported.
>
> [minor] §6.7 doesn't talk about the KFD ID.
>
>
> ...
> 480 EID HMAC ID: Identifier of the HMAC algorithm used to protect the
> 481 integrity of the EID-AD. See Section 6.7 for more details, and
> 482 Section 8.3 for HMAC IDs that MUST be supported.
>
> [minor] §6.7 doesn't talk about the EID HMAC ID.
>
>
> 484 EID mask-len: Mask length for EID-prefix.
>
> 486 EID-AFI: Address family of EID-prefix according to [RFC8060].
>
> 488 EID-prefix: This field contains an EID-prefix that the destination
> 489 ETR is authoritative for, and is the longest match for the
> 490 requested EID.
>
> [major] Same comment as in §6.1: These 3 fields, which are part of the
> "Rec", are the same as what is specified in §5.2/rfc6833bis.
>
>
> ...
> 499 PKT HMAC ID: Identifier of the HMAC algorithm used to protect the
> 500 integrity of the Map-Reply. See Section 8.3 for HMAC IDs that
> 501 MUST be supported.
>
> [major] As mentioned before, please take Normative specifications out of
> the IANA section and move it somewhere more appropriate.
>
>
> 503 PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP-
> 504 SEC Authentication Data. The scope of the authentication goes
> 505 from the Map-Reply Type field to the PKT HMAC field included.
> 506 Before computing the HMAC operation the PKT HMAC field MUST be set
> 507 to 0. See Section 6.8 for more details.
>
> [major] These two sentences don't seem to say the same thing:
>
> HMAC of the whole Map-Reply packet, including the LISP-SEC
> Authentication Data. The scope of the authentication goes
> from the Map-Reply Type field to the PKT HMAC field included.
>
> Does it include the Map-Reply (first sentence) or just the data defined
in
> this document (second sentence)? The description in §6.8 is slightly
> clearer, but not by much:
>
> The PKT-AD contains the HMAC of the whole Map-Reply packet...
> The scope of the HMAC operation covers the entire PKT-AD, from the
> Map-Reply Type field to the PKT HMAC field...
>
> It would be better if the specification was made only once. A pointer to
> §6.8 should be enough here.
>
>
> [major] "Before computing the HMAC operation the PKT HMAC field MUST be
set
> to 0."
>
> §6.8 describes the same operation, but without using Normative language:
> "...to the PKT HMAC field, which must be set to 0 before the
computation."
>
> Please specify things only once! It seems to me that it may be more
> appropriate to include the specification in §6.8.
>
>
> 509 6.3. Map-Register LISP-SEC Extentions
>
> [] This section is not needed -- see below.
>
> 511 This memo is allocating one of the bits marked as Unassigned in the
> 512 Map-Register message defined in [I-D.ietf-lisp-rfc6833bis]. More
> 513 precisely, the second bit after the Type field in a Map-Register
> 514 message is allocated as the S bit. The S bit indicates to the Map-
> 515 Server that the registering ETR is LISP-SEC enabled. An ETR that
> 516 supports LISP-SEC MUST set the S bit in its Map-Register messages.
>
> [major] The S-bit is already allocated and defined in rfc6833bis, so the
> first two sentences are not needed.
>
>
> [major] rfc6833bis is not as explicit as the last two sentences, but it
> seems to me that it already covers them. This is from §5.6/rfc6833bis
> (Map-Register Message Format):
>
> S: This is the security-capable bit. When set, the procedures from
> [I-D.ietf-lisp-sec] are supported.
>
> This text doesn't explicitly require the ETR to set the bit. If you want
> to make that explicit, then we should update the text in rfc633bis.
>
>
> 518 6.4. ITR Processing: Generating a Map-Request
>
> 520 Upon creating a Map-Request, the ITR generates a random ITR-OTK that
> 521 is stored locally (until the corresponding Map-Reply is received),
> 522 together with the nonce generated as specified in
> 523 [I-D.ietf-lisp-rfc6833bis].
>
> [minor] "until the corresponding Map-Reply is received"
>
> Please include a forward reference to §6.9.
>
>
> ...
> 531 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to
> 532 1, to indicate the presence of Authentication Data.
>
> [major] "Map-Request MUST be encapsulated in an ECM"
>
> This part is confusing to me -- along with the many parts that talk about
> an "encapsulated Map-Request".
>
> What do you mean by an "encapsulated Map-Request"? I see 3 options:
>
> (1) The ECM Authentication Data (from Figure 1) carried in the ECM
> (§5.8/rfc6833bis) with the S-bit set. This is what I've been assuming
> because §6.1 talks about it being a Map-Request when it describes the
> Record Count.
>
> If so, at minimum, the text is confusing because the content of the ECM
> Authentication Data is different from the Map-Request from
§5.2/rfc6833bis,
> but the names are the same. Also, the functionality from rfc6833bis is
> different.
>
>
> (2) A Map-Request (§5.2/rfc6833bis) encapsulated as the LCM in the ECM as
> described in §5.8/rfc6833bis. In this case, setting the S-bit, as
required
> above would indicate that the ECM Authentication Data (from Figure 1)
would
> also be there.
>
> If so, this document is not clear about the interaction between the two
> Map-Requests. Should the Records match, what if they don't, etc..?
>
>
> (3) A Map-Request (§5.2/rfc6833bis) encapsulated as the LCM in the ECM as
> described in §5.8/rfc6833bis. The S-bit is not set.
>
> I don't think this interpretation makes sense because then it wouldn't be
> protected at all.
>
>
> Please clarify here, and update the descriptions elsewhere as needed.
>
>
> 534 ITR-OTK is wrapped with the algorithm specified by the OTK Wrapping
> 535 ID field. See Section 6.5 for further details on OTK encryption. If
> 536 the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled
> 537 in the path between the ITR and the Map-Resolver, the Map-Request
> 538 MUST be dropped and an appropriate log action SHOULD be taken.
>
> [nit] s/ITR-OTK/The ITR-OTK
>
>
> 540 The Requested HMAC ID field contains the suggested HMAC algorithm to
> 541 be used by the Map-Server and the ETR to protect the integrity of the
> 542 ECM Authentication data and of the Map-Reply. A HMAC ID Value of
> 543 NONE (0), MAY be used to specify that the ITR has no preferred HMAC
> 544 ID.
>
> [nit] s/NONE (0), MAY/NONE (0) MAY
>
>
> 546 The KDF ID field specifies the suggested key derivation function to
> 547 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE
> 548 (0), MAY be used to specify that the ITR has no preferred KDF ID.
>
> [major] s/Value of NONE (0), MAY be used/Value of NONE (0) may be used
>
> Even though it is optional to use 0, the optional use of the KDF ID field
> by the ITR was already specified in §6.1, so this is just a statement of
> fact.
>
>
> ...
> 554 6.4.1. PITR Processing
>
> [minor] Please expand PITR on first use.
>
>
> 556 The processing performed by a PITR is equivalent to the processing of
> 557 an ITR. However, if the PITR is directly connected to a Mapping
> 558 System such as LISP+ALT [RFC6836], the PITR performs the functions of
> 559 both the ITR and the Map-Resolver forwarding the Map-Request
> 560 encapsulated in an ECM header that includes the Authentication Data
> 561 fields as described in Section 6.6.
>
> [?] This description of a PITR having multiple colocated functionality is
> not specific to the PITR, right? Also, the description is not specific to
> LISP+ALT, the same would happen with any Mapping System, right? It seems
> to me that this section is not needed.
>
>
> 563 6.5. Encrypting and Decrypting an OTK
> ...
> 594 Implementations of this specification MUST support OTK Wrapping ID
> 595 AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF-
> 596 SHA256 Key Derivation Function specified in[RFC4868] to derive a per-
> 597 message encryption key (per-msg-key), as well as the AES-KEY-WRAP-128
> 598 Key Wrap algorithm used to encrypt a 128-bit OTK, according to
> 599 [RFC3394].
>
> [nit] s/in[RFC4868]/in [RFC4868]
>
>
> 601 The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF-
> 602 SHA256 is described below:
>
> 604 1. The KDF algorithm is identified by the field 'OTK Wrapping ID'
> 605 according to the table in Section 8.4.
>
> 607 2. The Key Wrap algorithm is identified by the field 'OTK Wrapping
> 608 ID' according to the table in Section 8.4.
>
> [minor] Can we merge these two steps? Also, given that other algorithms
> may be defined later, let's separate the process from the table itself.
>
> Suggestion>
> The KDF and Key Wrap algorithms are identified by the value of
> the 'OTK Wrapping ID' field. The initial values are documented
> in Table #x.
>
>
> 610 3. If the NULL-KEY-WRAP-128 algorithm (defined in (Section 8.4)) is
> 611 selected and DTLS is not enabled, the Map-Request MUST be dropped
> 612 and an appropriate log action SHOULD be taken.
>
> [minor] s/8.4/6.5
>
>
> ...
> 640 6.5.1. Unencrypted OTK
>
> 642 MS-OTK confidentiality and integrity protection MUST be provided in
> 643 the path between the Map-Server and the ETR. Similarly, ITR-OTK
> 644 confidentiality and integrity protection MUST be provided in the path
> 645 between the ITR and the Map-Resolver.
>
> [major] This same specification is also present in §6.5. Please specify
> the bahavior only once.
>
>
> ...
> 676 6.7. Map-Server Processing
>
> 678 Upon receiving an ECM encapsulated Map-Request with the S-bit set to
> 679 1, the Map-Server process the Map-Request according to the value of
> 680 the security-capable S-bit and of the proxy map-reply P-bit contained
> 681 in the Map-Register sent by the ETRs authoritative for that prefix
> 682 during registration.
>
> [minor] This is a long sentence...my first read got me confused about
what
> was meant by "the value of the security-capable S-bit" if it had just
been
> pointed that it is set to 1.
>
> Please come up with a shortcut for "ECM encapsulated Map-Request with the
> S-bit set to 1". Refer back to the comments on §6.4. Suggestion: "secure
> Map-Request".
>
> Suggestion>
> Upon receiving a "secure Map-Request", the Map-Server precesses
> it according to the setting of the S and P-bits in the Map-Register
> received from the authoritative ETRs for the corresponding prefix,
> as described below.
>
>
> ...
> 731 In this way the ITR that sent a LISP-SEC protected Map-Request always
> 732 receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign
> 733 E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach
> 734 additional ETRs that have LISP-SEC disabled. This mechanism allows
> 735 the ITR to securely downgrade to non LISP-SEC requests, if so
> 736 desired.
>
> [major] "This mechanism allows the ITR to securely downgrade to non
> LISP-SEC requests, if so desired."
>
> Besides the fact that "securely downgrade to non LISP-SEC" sounds like a
> contradiction, the "if so desired" part leaves the operation up in the
> air. When/why would an ITR desire to disable security? What are the use
> cases where it may be ok? What are the risks that should be considered?
>
> As I see it, downgrading is risky because it can open the door to
> overclaiming, which list-sec closes (rfc6833bis). IOW, a rogue ETR can
> decide not to set the S-bit (even if it did support lisp-sec) and
eliminate
> its benefits. rfc6833bis also says this:
>
> 3. LISP-SEC [I-D.ietf-lisp-sec] MUST be implemented. Network
> operators should carefully weight how the LISP-SEC threat model
> applies to their particular use case or deployment. If they
> decide to ignore a particular recommendation, they should make
> sure the risk associated with the corresponding threats is well
> understood.
>
>
> Please add a "Deployment/Operational Considerations" section to help
> operators in making the decision above, particularly about when an ITR
may
> desire to downgrade. Please include (as appropriate) information as
> described in §2/rfc5706.
>
> FWIW, I see the E-bit as useful as a transition mechanism: while not all
> the ETRs may have been upgraded then it seems ok to downgrade to maintain
> the operation of the network. However, I'm having a hard time seeing the
> value afterwards.
>
>
> 738 6.7.1. Generating a LISP-SEC Protected Encapsulated Map-Request
> ...
> 745 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from
> 746 the ITR-OTK received with the Map-Request. MS-OTK is derived
> 747 applying the key derivation function specified in the KDF ID field.
> 748 If the algorithm specified in the KDF ID field is not supported, the
> 749 Map-Server uses a different algorithm to derive the key and updates
> 750 the KDF ID field accordingly.
>
> [major]
>
> If the algorithm specified in the KDF ID field is not supported, the
> Map-Server uses a different algorithm to derive the key and updates
> the KDF ID field accordingly.
>
> See the comment below (after line 775) about the future existence of
> multiple required/recommended algorithms.
>
>
> 752 MS-OTK confidentiality and integrity protection MUST be provided in
> 753 the path between the Map-Server and the ETR. This can be achieved
> 754 either by enabling DTLS between the Map-Server and the ETR, or by
> 755 encrypting the MS-OTK with the pre-shared secret known to the Map-
> 756 Server and the ETR.
>
> [major] This is specified in §6.5. Please specify behaviors only once
>