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

[Luigi Iannone <[e-mail]>]

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) <[e-mail]> 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" <[e-mail]> 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 ([e-mail])
>    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
>