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) <[email protected]> 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" <[email protected]> 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 ([email protected]) > 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 > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
