Re: [lisp] LISP-SEC review (finally)

[Fabio Maino <[e-mail]>]

sounds good.

Fabio

On 10/26/16 2:14 AM, Luigi Iannone wrote:
> Hi Fabio,
>
> thanks.
>
> I you don’t mind I prefer that we converge first (see other reply).
> So that I have to check only one final update.
>
> ciao
>
> L.
>
>
>> On 26 Oct 2016, at 06:07, Fabio Maino <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Ciao Luigi,
>> here is the updated draft and the diff from -11.
>>
>>
>> Thanks,
>> Fabio
>>
>>
>> On 10/25/16 5:14 PM, Fabio Maino wrote:
>>> Hi Luigi,
>>> below are more replies skipping the ones we agreed already. Looks 
>>> like we are converging...
>>>
>>>
>>> wrt to 6830bis, I think we should not wait. I suspect the security 
>>> review of the document will take some time, so we can do some 
>>> progress in parallel to 6830bis.
>>>
>>> We will have to do a LISP-SECbis afterwards, but that should be simple.
>>>
>>> Please, see below.
>>>
>>>
>>>
>>>
>>> On 10/24/16 3:02 AM, Luigi Iannone wrote:
>>>> Hi Fabio,
>>>>
>>>> se my comment inline.
>>>> (I do not consider the points we agree and everything related to 
>>>> the “SHOULD” clarification)
>>>>
>>>> Thanks for your work
>>>>
>>>> Ciao
>>>>
>>>> L.
>>>>
>>>>
>>>>> On 22 Oct 2016, at 01:23, Fabio Maino <[e-mail] 
>>>>> <mailto:[e-mail]>> wrote:
>>>>>
>>>>> Ciao Luigi,
>>>>> below I have replied to each comment. I'm working to the updated 
>>>>> text, that I will send as soon as it is ready. ideally we might be 
>>>>> able to publish a new version before draft deadline.
>>>>
>>>> Excellent. Thanks
>>>>
>>>>>
>>>>> Just a note on the most recurring comment: SHOULD vs. MUST.
>>>>>
>>>>> The use of SHOULD across the document is according to RFC 2119:
>>>>>
>>>>>
>>>>>     SHOULD
>>>>>
>>>>>   This word, or the adjective "RECOMMENDED", mean that there
>>>>>     may exist valid reasons in particular circumstances to ignore a
>>>>>     particular item, but the full implications must be understood and
>>>>>     carefully weighed before choosing a different course.
>>>>>
>>>>>
>>>>> There are use cases where, carefully weighing the implications, 
>>>>> some of the security services of LISP-SEC can be turned-off. We 
>>>>> want to leave implementors the freedom to allow this flexibility.
>>>>>
>>>>> For example, in a DC deployment it may make sense to turn off OTK 
>>>>> decryption between XTR and MS/MR, as MiTM is very unlikely.
>>>>>
>>>>> Similarly, an ITR may decide to implement a loose policy on 
>>>>> accepting an AD authenticated with an algorithm different from the 
>>>>> preferred authentication algorithm expressed by the ITR. Using a 
>>>>> MUST would force support of a given authentication algorithm 
>>>>> across each and every MS and ETR, that might not be the case when 
>>>>> incrementally deploying LISP-SEC (or while upgrading routers).
>>>>>
>>>>> Using a MUST would prevent this flexibility, that we would like to 
>>>>> leave to the implementors.
>>>>>
>>>>>
>>>>>
>>>>
>>>> This is fixed as for the suggestion of Joel. Thanks.
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 10/19/16 8:06 AM, Luigi Iannone wrote:
>>>>>> Dear Authors of the LISP-SEC document,
>>>>>>
>>>>>> hereafter my review of the document.
>>>>>> This was long overdue, sorry for being so late.
>>>>>>
>>>>>> I really like the solution and the majority of my comments are 
>>>>>> just clarification questions.
>>>>>> Let me know if my comments are clear.
>>>>>>
>>>>>> ciao
>>>>>>
>>>>>> L.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> 1.  Introduction
>>>>>>>
>>>>>>>     The Locator/ID Separation Protocol [RFC6830] defines a set of
>>>>>>>     functions for routers to exchange information used to map from non-
>>>>>>>     routable Endpoint Identifiers (EIDs) to routable Routing Locators
>>>>>>>     (RLOCs).
>>>>>> I find the above sentence confusing. Wouldn’t be better to 
>>>>>> specify that we are talking about IP addresses?
>>>>>
>>>>> That's how LISP is described in RFC6830, section 1. If you start 
>>>>> using the term IP address then you need to qualify if you are 
>>>>> talking about Identity-IP or Locator-IP, so the sentence gets 
>>>>> complicated pretty quickly.
>>>>>
>>>>
>>>> Not really. The very first sentence of the abstract of 6830 states:
>>>>
>>>> This document describes a network-layer-based protocol that enables
>>>>     separation of IP addresses into two new numbering spaces: Endpoint
>>>>     Identifiers (EIDs) and Routing Locators (RLOCs).
>>>>
>>>>
>>>> So clearly speaks about IP address.
>>>> Furthermore “routable" en “non routable” is true only in the 
>>>> inter-domain point of view, because EID are locally routable.
>>>> Note that 6830 does not specify in the first sentence what is 
>>>> routable and what is not.
>>>
>>> ok, fixed with text from 6830.
>>>
>>>
>>>>
>>>>
>>>>> I would leave this one unchanged.
>>>>>>
>>>>>>> If these EID-to-RLOC mappings, carried through Map-Reply
>>>>>>>     messages, are transmitted without integrity protection, an adversary
>>>>>>>     can manipulate them and hijack the communication, impersonate the
>>>>>>>     requested EID, or mount Denial of Service or Distributed Denial of
>>>>>>>     Service attacks.  Also, if the Map-Reply message is transported
>>>>>>>     unauthenticated, an adversarial LISP entity can overclaim an EID-
>>>>>>>     prefix and maliciously redirect traffic directed to a large number of
>>>>>>>     hosts.  A detailed description of "overclaiming" attack is provided
>>>>>>>     in [RFC7835].
>>>>>>>
>>>>>>>     This memo specifies LISP-SEC, a set of security mechanisms that
>>>>>>>     provides origin authentication, integrity and anti-replay protection
>>>>>>>     to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
>>>>>>>     process.
>>>>>>
>>>>>> I would put s forward reference to section 3 stating that the 
>>>>>> reader will find details about the threat model.
>>>>>
>>>>> OK. We can replace the sentence
>>>>> A detailed description of "overclaiming" attack is provided
>>>>>     in [RFC7835]
>>>>>
>>>>> with
>>>>>
>>>>> The LISP-SEC threat model, described in Section 3, is built on top of the LISP threat model defined in RFC7835, that includes a detailed description of "overclaiming" attack.
>>>> OK
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> LISP-SEC also enables verification of authorization on EID-
>>>>>>>     prefix claims in Map-Reply messages, ensuring that the sender of a
>>>>>>>     Map-Reply that provides the location for a given EID-prefix is
>>>>>>>     entitled to do so according to the EID prefix registered in the
>>>>>>>     associated Map-Server.  Map-Register security, including the right
>>>>>>>     for a LISP entity to register an EID-prefix or to claim presence at
>>>>>>>     an RLOC, is out of the scope of LISP-SEC.  Additional security
>>>>>>>     considerations are described in Section 6.
>>>>>>>
>>>>>>> 2.  Definition of Terms
>>>>>>>
>>>>>>>        One-Time Key (OTK): An ephemeral randomly generated key that must
>>>>>>>        be used for a single Map-Request/Map-Reply exchange.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>           ITR-OTK: The One-Time Key generated at the ITR.
>>>>>>>
>>>>>>>           MS-OTK: The One-Time Key generated at the Map-Server.
>>>>>>
>>>>>> Why are you considering ITR-OTK and MS-OTK sub-terms?
>>>>>> I would elevate them at full terms, hence avoiding spacing and 
>>>>>> indentation.
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>>>        Encapsulated Control Message (ECM): A LISP control message that is
>>>>>>>        prepended with an additional LISP header.  ECM is used by ITRs to
>>>>>>>        send LISP control messages to a Map-Resolver, by Map-Resolvers to
>>>>>>>        forward LISP control messages to a Map-Server, and by Map-
>>>>>>>        Resolvers to forward LISP control messages to an ETR.
>>>>>>>
>>>>>> Why are you re-defining ECM?
>>>>>> You do not specify other packets, e.g., Map-Reply, so why ECM?
>>>>>> I would drop it.
>>>>>
>>>>> It is not defined in the Definitions section of 6830. One would 
>>>>> need to go through the body of 6830 to find it.
>>>>
>>>> I see your point. Just keep the text and add a ref to section 6.1.8 
>>>> of 6830. This will clarify that is something coming from a specific 
>>>> section of that document.
>>>
>>> I have dropped the definition, expanded the acronym ECM and referred 
>>> to the specific section.
>>>
>>> In this way we don't have to wait for 6830bis, but we refer to the 
>>> proper definition.
>>>
>>>>
>>>>
>>>>>
>>>>> I'll drop it, but we need to make sure that ECM gets into the 
>>>>> definition section of 6830bis.
>>>>>
>>>>> Albert: are you looking into that document? Can you take care of 
>>>>> this?
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>        Authentication Data (AD): Metadata that is included either in a
>>>>>>>        LISP ECM header or in a Map-Reply message to support
>>>>>>>        confidentiality, integrity protection, and verification of EID-
>>>>>>>        prefix authorization.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 3]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>           OTK-AD: The portion of ECM Authentication Data that contains a
>>>>>>>           One-Time Key.
>>>>>>>
>>>>>>>           EID-AD: The portion of ECM and Map-Reply Authentication Data
>>>>>>>           used for verification of EID-prefix authorization.
>>>>>>>
>>>>>>>           PKT-AD: The portion of Map-Reply Authentication Data used to
>>>>>>>           protect the integrity of the Map-Reply message.
>>>>>>
>>>>>>
>>>>>> Why are you considering OTK-AD, EID-AD, and PKT-AD sub-terms?
>>>>>> I would elevate them at full terms, hence avoiding spacing and 
>>>>>> indentation.
>>>>>>
>>>>> ok.
>>>>>
>>>>>>
>>>>>>>     For definitions of other terms, notably Map-Request, Map-Reply,
>>>>>>>     Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server
>>>>>>>     (MS), and Map-Resolver (MR) please consult the LISP specification
>>>>>>>     [RFC6830].
>>>>>>>
>>>>>>> 3.  LISP-SEC Threat Model
>>>>>>>
>>>>>>>     LISP-SEC addresses the control plane threats, described in [RFC7835],
>>>>>>>     that target EID-to-RLOC mappings, including manipulations of Map-
>>>>>>>     Request and Map-Reply messages, and malicious ETR EID prefix
>>>>>>>     overclaiming.  LISP-SEC makes two main assumptions: (1) the LISP
>>>>>>>     mapping system is expected to deliver a Map-Request message to their
>>>>>>>     intended destination ETR as identified by the EID, and (2) no man-in-
>>>>>>>     the-middle (MITM) attack can be mounted within the LISP Mapping
>>>>>>>     System.  Furthermore, while LISP-SEC enables detection of EID prefix
>>>>>>>     overclaiming attacks, it assumes that Map-Servers can verify the EID
>>>>>>>     prefix authorization at time of registration.
>>>>>> LISP-SEC does not require OTK confidentiality in the mapping 
>>>>>> system. This should be discussed here.
>>>>> we could add to the above
>>>>> "and (2) no man-in-
>>>>>     the-middle (MITM) attack can be mounted within the LISP Mapping
>>>>>     System."
>>>>>
>>>>> How the Mapping System is protected from MiTM attacks depends from the particular Mapping System used, and is out of the scope of this memo.
>>>>>
>>>>>
>>>>
>>>> That’s fine for me.
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>     According to the threat model described in [RFC7835] LISP-SEC assumes
>>>>>>>     that any kind of attack, including MITM attacks, can be mounted in
>>>>>>>     the access network, outside of the boundaries of the LISP mapping
>>>>>>>     system.  An on-path attacker, outside of the LISP mapping system can,
>>>>>>>     for example, hijack Map-Request and Map-Reply messages, spoofing the
>>>>>>>     identity of a LISP node.  Another example of on-path attack, called
>>>>>>>     overclaiming attack, can be mounted by a malicious Egress Tunnel
>>>>>>>     Router (ETR), by overclaiming the EID-prefixes for which it is
>>>>>>>     authoritative.  In this way the ETR can maliciously redirect traffic
>>>>>>>     directed to a large number of hosts.
>>>>>>>
>>>>>>> 4.  Protocol Operations
>>>>>>>
>>>>>>>     The goal of the security mechanisms defined in [RFC6830] is to
>>>>>>>     prevent unauthorized insertion of mapping data by providing origin
>>>>>>>     authentication and integrity protection for the Map-Registration, and
>>>>>>>     by using the nonce to detect unsolicited Map-Reply sent by off-path
>>>>>>>     attackers.
>>>>>>>
>>>>>>>     LISP-SEC builds on top of the security mechanisms defined in
>>>>>>>     [RFC6830] to address the threats described in Section 3 by leveraging
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 4]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     the trust relationships existing among the LISP entities
>>>>>>>     participating to the exchange of the Map-Request/Map-Reply messages.
>>>>>>>     Those trust relationships are used to securely distribute a One-Time
>>>>>>>     Key (OTK) that provides origin authentication, integrity and anti-
>>>>>>>     replay protection to mapping data conveyed via the mapping lookup
>>>>>>>     process, and that effectively prevent overclaiming attacks.  The
>>>>>>>     processing of security parameters during the Map-Request/Map-Reply
>>>>>>>     exchange is as follows:
>>>>>>>
>>>>>>>     o  The ITR-OTK is generated and stored at the ITR, and securely
>>>>>>>        transported to the Map-Server.
>>>>>>>
>>>>>>>     o  The Map-Server uses the ITR-OTK to compute an HMAC that protects
>>>>>> You did not define HMAC acronym. Please define and add a reference.
>>>>>
>>>>> ok.
>>>>>
>>>>>
>>>>>>
>>>>>>>        the integrity of the mapping data known to the Map-Server to
>>>>>>>        prevent overclaiming attacks.  The Map-Server also derives a new
>>>>>>>        OTK, the MS-OTK, that is passed to the ETR, by applying a Key
>>>>>>>        Derivation Function (KDF) to the ITR-OTK.
>>>>>>>
>>>>>>>     o  The ETR uses the MS-OTK to compute an HMAC that protects the
>>>>>>>        integrity of the Map-Reply sent to the ITR.
>>>>>>>
>>>>>>>     o  Finally, the ITR uses the stored ITR-OTK to verify the integrity
>>>>>>>        of the mapping data provided by both the Map-Server and the ETR,
>>>>>>>        and to verify that no overclaiming attacks were mounted along the
>>>>>>>        path between the Map-Server and the ITR.
>>>>>>>
>>>>>>>     Section 5 provides the detailed description of the LISP-SEC control
>>>>>>>     messages and their processing, while the rest of this section
>>>>>>>     describes the flow of protocol operations at each entity involved in
>>>>>>>     the Map-Request/Map-Reply exchange:
>>>>>>>
>>>>>>>     o  The ITR, upon needing to transmit a Map-Request message, generates
>>>>>>>        and stores an OTK (ITR-OTK).  This ITR-OTK is included into the
>>>>>>>        Encapsulated Control Message (ECM) that contains the Map-Request
>>>>>>>        sent to the Map-Resolver.  To provide confidentiality to the ITR-
>>>>>>>        OTK over the path between the ITR and its Map-Resolver, the ITR-
>>>>>>>        OTK SHOULD
>>>>>> Why not using “MUST”???
>>>>>> Are you suggesting that a different way to provide 
>>>>>> confidentiality can be used (e.g. a different shared key)???
>>>>>> If yes, please state so.
>>>>>>
>>>>>> Or are you suggesting that no encryption at all is used? But this 
>>>>>> means not providing confidentiality…
>>>>>> Can you clarify?
>>>>>>
>>>>>> (this very same comment will appear several time in this review)
>>>>>
>>>>> We don't want to make the use of pre-shared key *mandatory* to all 
>>>>> LISP deployments. There are deployments where the risk of MiTM 
>>>>> between the xTR and the MS/MR may not justify the cost of 
>>>>> provisioning a shared key (data centers, for example).
>>>>>
>>>>>
>>>>>>> be encrypted using a preconfigured key shared between
>>>>>>>        the ITR and the Map-Resolver, similar to the key shared between
>>>>>>>        the ETR and the Map-Server in order to secure ETR registration
>>>>>>>        [RFC6833].
>>>>>>>
>>>>>>>     o  The Map-Resolver decapsulates the ECM message, decrypts the ITR-
>>>>>>>        OTK, if needed, and forwards through the Mapping System the
>>>>>>>        received Map-Request and the ITR-OTK, as part of a new ECM
>>>>>>>        message.  As described in Section 5.6, the LISP Mapping System
>>>>>>>        delivers the ECM to the appropriate Map-Server, as identified by
>>>>>>>        the EID destination address of the Map-Request.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 5]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     o  The Map-Server is configured with the location mappings and policy
>>>>>>>        information for the ETR responsible for the EID destination
>>>>>>>        address.  Using this preconfigured information, the Map-Server,
>>>>>>>        after the decapsulation of the ECM message, finds the longest
>>>>>>>        match EID-prefix that covers the requested EID in the received
>>>>>>>        Map-Request.  The Map-Server adds this EID-prefix, together with
>>>>>>>        an HMAC computed using the ITR-OTK, to a new Encapsulated Control
>>>>>>>        Message that contains the received Map-Request.
>>>>>>>
>>>>>>>     o  The Map-Server derives a new OTK, the MS-OTK, by applying a Key
>>>>>>>        Derivation Function (KDF) to the ITR-OTK.  This MS-OTK is included
>>>>>>>        in the Encapsulated Control Message that the Map-Server uses to
>>>>>>>        forward the Map-Request to the ETR.  To provide MS-OTK
>>>>>>>        confidentiality over the path between the Map-Server and the ETR,
>>>>>>>        the MS-OTK should
>>>>>> This “should” should be a “SHOULD”  (sorry for the cacophony…)
>>>>>
>>>>> Ok.
>>>>>>
>>>>>> Why not using “MUST”???
>>>>>> Are you suggesting that a different way to provide 
>>>>>> confidentiality can be used (e.g. a different shared key)???
>>>>>> If yes, please state so.
>>>>>>
>>>>>> Or are you suggesting that no encryption at all is used? But this 
>>>>>> means not providing confidentiality…
>>>>>> Can you clarify?
>>>>>
>>>>> Same as above.
>>>>>
>>>>>>
>>>>>>> be encrypted using the key shared between the
>>>>>>>        ETR and the Map-Server in order to secure ETR registration
>>>>>>>        [RFC6833].
>>>>>>>
>>>>>>>     o  If the Map-Server is acting in proxy mode, as specified in
>>>>>>>        [RFC6830], the ETR is not involved in the generation of the Map-
>>>>>>>        Reply.  In this case the Map-Server generates the Map-Reply on
>>>>>>>        behalf of the ETR as described below.
>>>>>>>
>>>>>>>     o  The ETR, upon receiving the ECM encapsulated Map-Request from the
>>>>>>>        Map-Server, decrypts the MS-OTK, if needed, and originates a
>>>>>>>        standard Map-Reply that contains the EID-to-RLOC mapping
>>>>>>>        information as specified in [RFC6830].
>>>>>>>
>>>>>>>     o  The ETR computes an HMAC over this standard Map-Reply, keyed with
>>>>>>>        MS-OTK to protect the integrity of the whole Map-Reply.  The ETR
>>>>>>>        also copies the EID-prefix authorization data that the Map-Server
>>>>>>>        included in the ECM encapsulated Map-Request into the Map-Reply
>>>>>>>        message.  The ETR then sends this complete Map-Reply message to
>>>>>>>        the requesting ITR.
>>>>>>>
>>>>>>>     o  The ITR, upon receiving the Map-Reply, uses the locally stored
>>>>>>>        ITR-OTK to verify the integrity of the EID-prefix authorization
>>>>>>>        data included in the Map-Reply by the Map-Server.  The ITR
>>>>>>>        computes the MS-OTK by applying the same KDF used by the Map-
>>>>>>>        Server, and verifies the integrity of the Map-Reply.  If the
>>>>>>>        integrity checks fail, the Map-Reply MUST be discarded.  Also, if
>>>>>>>        the EID-prefixes claimed by the ETR in the Map-Reply are not equal
>>>>>>>        or more specific than the EID-prefix authorization data inserted
>>>>>>>        by the Map-Server, the ITR MUST discard the Map-Reply.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 6]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>> 5.  LISP-SEC Control Messages Details
>>>>>>>
>>>>>>>     LISP-SEC metadata associated with a Map-Request is transported within
>>>>>>>     the Encapsulated Control Message that contains the Map-Request.
>>>>>>>
>>>>>>>     LISP-SEC metadata associated with the Map-Reply is transported within
>>>>>>>     the Map-Reply itself.
>>>>>>>
>>>>>>> 5.1.  Encapsulated Control Message LISP-SEC Extensions
>>>>>>>
>>>>>>>     LISP-SEC uses the ECM (Encapsulated Control Message) defined in
>>>>>>>     [RFC6830] with Type set to 8, and S bit set to 1 to indicate that the
>>>>>>>     LISP header includes Authentication Data (AD).  The format of the
>>>>>>>     LISP-SEC ECM Authentication Data is defined in the following figure.
>>>>>>>     OTK-AD stands for One-Time Key Authentication Data and EID-AD stands
>>>>>>>     for EID Authentication Data.
>>>>>>>
>>>>>>>   0                   1                   2                   3
>>>>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>> |     AD Type   |V|  Reserved   |        Requested HMAC ID      |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
>>>>>>> |              OTK Length       |       OTK Encryption ID       | |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>>>>>>> |                       One-Time-Key Preamble ...               | |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTK-AD
>>>>>>> |                   ... One-Time-Key Preamble                   | |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>>>>>>> ~                      One-Time Key (128 bits)                  ~/
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
>>>>>>> |           EID-AD Length       |           KDF ID              |     |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
>>>>>>> | Record Count  |    Reserved   |         EID HMAC ID           |     EID-AD
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
>>>>>>> |   Reserved    | EID mask-len  |           EID-AFI             | |   |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
>>>>>>> ~                          EID-prefix ...                       ~ |   |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
>>>>>>> ~                            EID HMAC                           ~     |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <—+
>>>>>> I think that “rec” is mis-aligned and should be shifted one 
>>>>>> character upward.
>>>>>
>>>>> No. The row above is the portion of the header that specifies how 
>>>>> many records will follow. Rec shows one Rec item, in the array of 
>>>>> Records.  It is consistent with 6830.
>>>>>
>>>>>
>>>>
>>>> OK
>>>>
>>>>>
>>>>>>
>>>>>>>                       LISP-SEC ECM Authentication Data
>>>>>>>
>>>>>>>        AD Type: 1 (LISP-SEC Authentication Data)
>>>>>> This is the first document starting to allocate values to the "AD 
>>>>>> Type” value.
>>>>>> Why not asking IANA to create a registry??
>>>>>> (to be done in the IANA Considerations Section)
>>>>>
>>>>>
>>>>> Ok.
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>        V: Key Version bit.  This bit is toggled when the sender switches
>>>>>>>        to a new OTK wrapping key
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 7]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>        Reserved: Set to 0 on transmission and ignored on receipt.
>>>>>>>
>>>>>>>        Requested HMAC ID: The HMAC algorithm requested by the ITR.  See
>>>>>>>        Section 5.4 for details.
>>>>>>>
>>>>>>>        OTK Length: The length (in bytes) of the OTK Authentication Data
>>>>>>>        (OTK-AD), that contains the OTK Preamble and the OTK.
>>>>>>>
>>>>>>>        OTK Encryption ID: The identifier of the key wrapping algorithm
>>>>>>>        used to encrypt the One-Time-Key. When a 128-bit OTK is sent
>>>>>>>        unencrypted by the Map-Resolver, the OTK Encryption ID is set to
>>>>>>>        NULL_KEY_WRAP_128.  See Section 5.5 for more details.
>>>>>>>
>>>>>>>        One-Time-Key Preamble: set to 0 if the OTK is not encrypted.  When
>>>>>>>        the OTK is encrypted, this field may carry additional metadata
>>>>>>>        resulting from the key wrapping operation.  When a 128-bit OTK is
>>>>>>>        sent unencrypted by Map-Resolver, the OTK Preamble is set to
>>>>>>>        0x0000000000000000 (64 bits).  See Section 5.5 for details.
>>>>>>>
>>>>>>>        One-Time-Key: the OTK encrypted (or not) as specified by OTK
>>>>>>>        Encryption ID.  See Section 5.5 for details.
>>>>>>>
>>>>>>>        EID-AD Length: length (in bytes) of the EID Authentication Data
>>>>>>>        (EID-AD).  The ITR MUST set EID-AD Length to 4 bytes, as it only
>>>>>>>        fills the KDF ID field, and all the remaining fields part of the
>>>>>>>        EID-AD are not present.  An EID-AD MAY contain multiple EID-
>>>>>>>        records.  Each EID-record is 4-byte long plus the length of the
>>>>>>>        AFI-encoded EID-prefix.
>>>>>>>
>>>>>>>        KDF ID: Identifier of the Key Derivation Function used to derive
>>>>>>>        the MS-OTK.  The ITR SHOULD use this field to indicate the
>>>>>>>        recommended KDF algorithm, according to local policy.
>>>>>> I am not sure I understand the rationale of this “SHOULD”. If for 
>>>>>> any reason the ITR does not indicate the KDF ID what are the 
>>>>>> consequences?
>>>>>
>>>>> That should be a MAY, I believe,
>>>>>
>>>>> The ITR can specify "no preference" for KDF ID, using a value of 0.
>>>>
>>>> I think this is the unclear information: that the ITR can state “no 
>>>> preference” using value 0.
>>>> Would be good if you can state it more clearly.
>>>
>>> I've added text to clarify this.
>>>
>>>>
>>>>
>>>>>
>>>>> In the ITR processing section 5.4,  we should add to
>>>>>
>>>>> The KDF ID field, specifies the suggested key derivation function to
>>>>>     be used by the Map-Server to derive the MS-OTK.
>>>>>
>>>>> a text like: "A KDF ID value of 0 (NONE), MAY be used to specify 
>>>>> that the ITR has no preferred KDF ID".
>>>>>
>>>>>
>>>>>
>>>>>> Is the MS free to choose the algorithm? This should be clarified.
>>>>> This is specified in section 5.7.
>>>>>
>>>>> "
>>>>> The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from
>>>>>     the ITR-OTK received with the Map-Request.  MS-OTK is derived
>>>>>     applying the key derivation function specified in the KDF ID field.
>>>>>     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.
>>>>> "
>>>>>
>>>>>
>>>>
>>>> Since this paragraph does not use any 2119 language it actually 
>>>> mean that an MS can choose freely the  algorithm to use.
>>>> right?
>>>
>>> right. If the ITR does support that specific ID, the ITR may still 
>>> decide to use it.
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>   The Map-
>>>>>>>        Server can overwrite the KDF ID if it does not support the KDF ID
>>>>>>>        recommended by the ITR.
>>>>>> What happens if the MS will choose a KDF ID not supported by the ITR?
>>>>>> Can you clarify how to solve this situation or explain why this 
>>>>>> will never happen?
>>>>>
>>>>> This is specified in 5.4, ITR processing.
>>>>>
>>>>> "
>>>>> To verify the integrity of the PKT-AD, first the MS-OTK is derived
>>>>>     from the locally stored ITR-OTK using the algorithm specified in the
>>>>>     KDF ID field.  This is because the PKT-AD is generated by the ETR
>>>>>     using the MS-OTK.  If the KDF ID in the Map-Reply does not match the
>>>>>     KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
>>>>>     Reply and send, at the first opportunity it needs to, a new Map-
>>>>>     Request with a different KDF ID, according to ITR's local policy.
>>>>> "
>>>>>
>>>>>
>>>>> There are two typical use cases:
>>>>> - strict KDF ID policy: ITR specifiy a KDF ID, and will discard 
>>>>> map-reply with different KDF IDs. If local policy allows, another 
>>>>> map-request will be sent with a different KDF ID
>>>>> - loose KDF ID policy: ITR specify KDF ID = none, and will accept 
>>>>> map-reply with any KDF ID (if supported by ITR). If received KDF 
>>>>> is not supported the ITR shall drop the map-reply
>>>>>
>>>>
>>>> The above text does not reflect the policies you are describing. 
>>>> That “SHOULD” should be a “MAY” and your policies spelled out.
>>> I think we need to separate the recommendations for the two actions: 
>>> SHOULD drop and MAY resend.
>>>
>>> "
>>> , the ITR SHOULD discard the Map-
>>>     Reply. At the first opportunity it needs to, the ITR MAY send a new Map-
>>>     Request with a different KDF ID, according to ITR's local policy.
>>>
>>> What do you think?
>>>
>>>>
>>>> Also, what is the MS stubbornly insists in using an algorithm that 
>>>> the ITR does not support?
>>>
>>> The MS might not have alternatives, as it might only support one 
>>> algorithm.
>>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>>> See Section 5.4 for more details.
>>>>>>>
>>>>>>>        Record Count: The number of records in this Map-Request message.
>>>>>>>        A record is comprised of the portion of the packet that is labeled
>>>>>>>        'Rec' above and occurs the number of times equal to Record Count.
>>>>>>>
>>>>>>>        Reserved: Set to 0 on transmission and ignored on receipt.
>>>>>>>
>>>>>>>        EID HMAC ID: Identifier of the HMAC algorithm used to protect the
>>>>>>>        integrity of the EID-AD.  This field is filled by Map-Server that
>>>>>>>        computed the EID-prefix HMAC.  See Section 5.4 for more details.
>>>>>>>
>>>>>>>        EID mask-len: Mask length for EID-prefix.
>>>>>>>
>>>>>>>        EID-AFI: Address family of EID-prefix according to [RFC5226]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 8]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>        EID-prefix: The Map-Server uses this field to specify the EID-
>>>>>>>        prefix that the destination ETR is authoritative for, and is the
>>>>>>>        longest match for the requested EID.
>>>>>>>
>>>>>>>        EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server.
>>>>>>>        Before computing the HMAC operation the EID HMAC field MUST be set
>>>>>>>        to 0.  The HMAC covers the entire EID-AD.
>>>>>>>
>>>>>>> 5.2.  Map-Reply LISP-SEC Extensions
>>>>>>>
>>>>>>>     LISP-SEC uses the Map-Reply defined in [RFC6830], with Type set to 2,
>>>>>>>     and S bit set to 1 to indicate that the Map-Reply message includes
>>>>>>>     Authentication Data (AD).  The format of the LISP-SEC Map-Reply
>>>>>>>     Authentication Data is defined in the following figure.  PKT-AD is
>>>>>>>     the Packet Authentication Data that covers the Map-Reply payload.
>>>>>>>
>>>>>>>   0                   1                   2                   3
>>>>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>>> |    AD Type    |                 Reserved                      |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
>>>>>>> |           EID-AD Length       |           KDF ID              |     |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
>>>>>>> | Record Count  |    Reserved   |         EID HMAC ID           |     EID-AD
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
>>>>>>> |   Reserved    | EID mask-len  |           EID-AFI             | |   |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
>>>>>>> ~                          EID-prefix ...                       ~ |   |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
>>>>>>> ~                            EID HMAC                           ~     |
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
>>>>>>> |         PKT-AD Length         |         PKT HMAC ID           |\
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
>>>>>>> ~                            PKT HMAC                           ~ PKT-AD
>>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
>>>>>>>
>>>>>>>                    LISP-SEC Map-Reply Authentication Data
>>>>>>>
>>>>>>>        AD Type: 1 (LISP-SEC Authentication Data)
>>>>>> Shouldn’t this be a different value? This AD  format is different 
>>>>>> from the one described in section 5.1!
>>>>>> Another reason to ask IANA for a registry….
>>>>>
>>>>> One is the LISP-SEC authentication data that applies to the ECM 
>>>>> message (when S-bit = 1), the other is the LISP-SEC authentication 
>>>>> data that applies to the Map-Reply (when S-bit = 1).
>>>>>
>>>>> Those are extensions of two different messages (ECM and 
>>>>> map-reply), and they are both identified by an AD Type (that 
>>>>> happens to be set to value 1 for both).
>>>>
>>>> This is not clear in the current text.
>>>
>>> Right. I have updated the text to clarify it. Together with the IANA 
>>> disposition it should be clear now.
>>>
>>>
>>>>
>>>>>
>>>>> Yes, the AD type space is different so we will need two IANA 
>>>>> registries.
>>>>>
>>>>>
>>>>> Question for the co-auhtors: should we change the name to 'ECM AD 
>>>>> Type' and 'Map-Reply AD Type’?
>>>>
>>>> IMHO you have to, otherwise there will be always confusion….
>>>
>>> done.
>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>        EID-AD Length: length (in bytes) of the EID-AD.  An EID-AD MAY
>>>>>>>        contain multiple EID-records.  Each EID-record is 4-byte long plus
>>>>>>>        the length of the AFI-encoded EID-prefix.
>>>>>>>
>>>>>>>        KDF ID: Identifier of the Key Derivation Function used to derive
>>>>>>>        MS-OTK.  See Section 5.7 for more details.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                 [Page 9]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>        Record Count: The number of records in this Map-Reply message.  A
>>>>>>>        record is comprised of the portion of the packet that is labeled
>>>>>>>        'Rec' above and occurs the number of times equal to Record Count.
>>>>>>>
>>>>>>>        Reserved: Set to 0 on transmission and ignored on receipt.
>>>>>>>
>>>>>>>        EID HMAC ID: Identifier of the HMAC algorithm used to protect the
>>>>>>>        integrity of the EID-AD.  See Section 5.7 for more details.
>>>>>>>
>>>>>>>        EID mask-len: Mask length for EID-prefix.
>>>>>>>
>>>>>>>        EID-AFI: Address family of EID-prefix according to [RFC5226].
>>>>>>>
>>>>>>>        EID-prefix: This field contains an EID-prefix that the destination
>>>>>>>        ETR is authoritative for, and is the longest match for the
>>>>>>>        requested EID.
>>>>>>>
>>>>>>>        EID HMAC: HMAC of the EID-AD, as computed by the Map-Server.
>>>>>>>        Before computing the HMAC operation the EID HMAC field MUST be set
>>>>>>>        to 0.  The HMAC covers the entire EID-AD.
>>>>>>>
>>>>>>>        PKT-AD Length: length (in bytes) of the Packet Authentication Data
>>>>>>>        (PKT-AD).
>>>>>>>
>>>>>>>        PKT HMAC ID: Identifier of the HMAC algorithm used to protect the
>>>>>>>        integrity of the Map-reply Location Data.
>>>>>> “Location Data” is something nowhere defined. Can you clarify 
>>>>>> what do you mean?
>>>>>
>>>>> we can just remove 'Location Data’
>>>>
>>>> OK.
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>        PKT HMAC: 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.
>>>>>>>        Before computing the HMAC operation the PKT HMAC field MUST be set
>>>>>>>        to 0.  See Section 5.8 for more details.
>>>>>>>
>>>>>>> 5.3.  Map-Register LISP-SEC Extentions
>>>>>>>
>>>>>>>     The second bit after the Type field in a Map-Register message is
>>>>>>>     allocated as the S bit.
>>>>>> I would better explain that this document is allocating a bit 
>>>>>> marked as reserved in 6830.
>>>>>
>>>>> Ok. We will need to reflect this in 6830bis as well.
>>>>
>>>> Sure
>>>>
>>>>
>>>>>
>>>>>> Furthermore, at the cost of being redundant, I would put the 
>>>>>> packet format highlighting the position of the bit so that there 
>>>>>> is no confusion whatsoever.
>>>>>
>>>>> We wanted to  explicitly avoid to include the format of messages 
>>>>> when already defined in other documents,
>>>>
>>>> The S-bit is not defined in other documents. IMHO is important to 
>>>> have the visual aid of which exact bit your are talking about.
>>>>
>>> I've added text to clarify. I really prefer not to have the whole 
>>> picture, but just refer to it.
>>>
>>> Considering that 6830 will evolve into 6830bis, eventually (with the 
>>> next LISP-SEC) the reference will be updated in 6830bis.
>>>
>>>
>>>>> so we point rather than copy. If we address this in 6830bis, the 
>>>>> problem will be solved.
>>>>
>>>> You mentioned 6830bis several time, let me ask: Would you like to 
>>>> reference that document?
>>>> In this case we have to hold this back until we have at least a 
>>>> stable version of that document.
>>>> Then the RFC editor will hold this document back until that one is 
>>>> RFC, because of missing reference.
>>>> Or you keep it this way and later on you make a ST version.
>>>>
>>>> Either way is fine for me.
>>>
>>> I think we should move this draft forward, without waiting for 
>>> 6830bis. Considering that this is security I expect the review 
>>> process to last quite some time, so we can make progress without 
>>> waiting for 6830bis. Eventually even teh LISP-SEC RFC will be 
>>> updated, and all will be good.
>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>> The S bit indicates to the Map-Server that
>>>>>>>     the registering ETR is LISP-SEC enabled.  An ETR that supports LISP-
>>>>>>>     SEC MUST set the S bit in its Map-Register messages.
>>>>>>>
>>>>>>> 5.4.  ITR Processing
>>>>>>>
>>>>>>>     Upon creating a Map-Request, the ITR generates a random ITR-OTK that
>>>>>>>     is stored locally, together with the nonce generated as specified in
>>>>>>>     [RFC6830].
>>>>>>>
>>>>>>>     The Map-Request MUST be encapsulated in an ECM, with the S-bit set to
>>>>>>>     1, to indicate the presence of Authentication Data.  If the ITR and
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 10]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     the Map-Resolver are configured with a shared key,
>>>>>> In section 4 you seem to suggest that this is not the only way to 
>>>>>> protect the OTK (see my comment).
>>>>>> Here instead you suggest that a shared key is the only way.
>>>>>
>>>>>
>>>>> Right. Here it says what to do IF there is a shared key, that is 
>>>>> consistent with the SHOULD above.
>>>>
>>>> OK.
>>>>
>>>>>
>>>>>
>>>>>>>   the ITR-OTK
>>>>>>>     confidentiality SHOULD be protected by wrapping the ITR-OTK with the
>>>>>>>     algorithm specified by the OTK Encryption ID field.
>>>>>> Not clear what this “SHOULD” refers to.
>>>>>> IS the SHOULD related to the fact to encrypt the OTK? The ITR 
>>>>>> SHOULD encrypt.
>>>>>> Or the choice of the algorithm? The ITR SHOULD use the algorithm 
>>>>>> specified by the OTK Encryption ID?
>>>>>> The second case looks impossible since is the ITR is choosing the 
>>>>>> algorithm. May be the sentence can be rewritten.
>>>>>
>>>>> SHOULD refers to protecting the confidentiality of the ITR-OTK. 
>>>>> Maybe the 'by' should be replaced by 'with’?
>>>>
>>>> Just drop the “by”?
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> Similarly to previous comment: Why it is not a MUST?
>>>>> Same as other SHOULD.
>>>>>
>>>>>
>>>>>
>>>>>>>   See Section 5.5
>>>>>>>     for further details on OTK encryption.
>>>>>>>
>>>>>>>     The Requested HMAC ID field contains the suggested HMAC algorithm to
>>>>>>>     be used by the Map-Server and the ETR to protect the integrity of the
>>>>>>>     ECM Authentication data and of the Map-Reply.
>>>>>>>
>>>>>> What happens if the MS will choose a HMAC not supported by the 
>>>>>> ETR or the ITR?
>>>>>> Can you clarify how to solve this situation or explain why this 
>>>>>> will never happen?
>>>>>
>>>>> This is described 5 paragraphs below:
>>>>>
>>>>> "
>>>>> If the EID HMAC ID field does
>>>>>     not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply
>>>>>     and send, at the first opportunity it needs to, a new Map-Request
>>>>>     with a different Requested HMAC ID field, according to ITR's local
>>>>>     policy.
>>>>> "
>>>>>
>>>>
>>>> What about the ETR?
>>>
>>> It's specified in 5.8, the ETR makes the same processing as the MS.
>>>
>>> "If the ETR does not support the Requested HMAC ID, it uses a 
>>> different algorithm and updates the PKT HMAC ID field accordingly. "
>>>
>>> Also the ETR doesn't process the AD computed by the MS, it just 
>>> copies into the Map-Reply.
>>>
>>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>     The KDF ID field, specifies the suggested key derivation function to
>>>>>>>     be used by the Map-Server to derive the MS-OTK.
>>>>>>
>>>>>> What happens if the MS will choose a KDF ID not supported by the ITR?
>>>>>> Can you clarify how to solve this situation or explain why this 
>>>>>> will never happen?
>>>>>
>>>>> This is described a few paragraphs below:
>>>>> "
>>>>> If the KDF ID in the Map-Reply does not match the
>>>>>     KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
>>>>>     Reply and send, at the first opportunity it needs to, a new Map-
>>>>>     Request with a different KDF ID, according to ITR's...
>>>>> "
>>>>>
>>>>
>>>> This does not guarantee that the MS will reply with something the 
>>>> ITR understands….
>>>
>>> For some local ITR's policy it may not be guaranteed. It's a balance 
>>> between reachability and security that the ITR will have to choose.
>>>
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>>     The EID-AD length is set to 4 bytes, since the Authentication Data
>>>>>>>     does not contain EID-prefix Authentication Data, and the EID-AD
>>>>>>>     contains only the KDF ID field.
>>>>>>>
>>>>>>>     In response to an encapsulated Map-Request that has the S-bit set, an
>>>>>>>     ITR MUST receive a Map-Reply with the S-bit set, that includes an
>>>>>>>     EID-AD and a PKT-AD.  If the Map-Reply does not include both ADs, the
>>>>>>>     ITR MUST discard it.  In response to an encapsulated Map-Request with
>>>>>>>     S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
>>>>>>>     the ITR SHOULD discard the Map-Reply if the S-bit is set.
>>>>>> Why a “SHOULD”? If the Map-Request has S-bit=0 it mean that there 
>>>>>> is no AD, hence no OTK, how can the ITR decrypt the reply?????
>>>>>> It MUST discard…..
>>>>>
>>>>> If S-bit = 0 there's no Authentication Data. The Map-reply is in 
>>>>> clear, and can be read.
>>>>
>>>> I am not sure you understood my point.
>>>>
>>>> You send a Map-Request with S=0, hence unenbcrypted. How can you 
>>>> possible receive a Map-Reply with S=1?
>>>> How is it encrypted if the ITR did not provide any OTK?
>>>
>>> Misconfiguration, bugs? I was just trying to enumerate the behaviors 
>>> of the ITR. There's probably something wrong, and the map-reply 
>>> should be discarded. Still the mapping is readable, so an ITR 
>>> favoring reachability may decide to use the mapping.
>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> Here again the SHOULD leaves open to ITR local policy that can be 
>>>>> strict (drop anything not authenticated) or loose (accept 
>>>>> unauthenticated map-reply).
>>>>>
>>>>> There are use cases where LISP-SEC is not deployed everywhere, 
>>>>> where the ITR might have to use loose policy.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>     Upon receiving a Map-Reply, the ITR must verify the integrity of both
>>>>>>>     the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of
>>>>>>>     the integrity checks fails.
>>>>>>>
>>>>>>>     The integrity of the EID-AD is verified using the locally stored ITR-
>>>>>>>     OTK to re-compute the HMAC of the EID-AD using the algorithm
>>>>>>>     specified in the EID HMAC ID field.  If the EID HMAC ID field does
>>>>>>>     not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply
>>>>>> Why is this a SHOULD? If it supports the HMAC Algorithm why not 
>>>>>> decrypt? Shouldn’t this be a “MAY”, according to internal policy?
>>>>>
>>>>> because this could be used by an attacker to force weaker HMACs 
>>>>> (e.g. MD5).
>>>>
>>>> OK
>>>>
>>>>> The SHOULD leaves open the door to not discarding, according to 
>>>>> local policy.
>>>>>
>>>>>
>>>>
>>>> OK.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>>     and send, at the first opportunity it needs to, a new Map-Request
>>>>>>>     with a different Requested HMAC ID field, according to ITR's local
>>>>>>>     policy.  The ITR MUST set the EID HMAC ID field to 0 before computing
>>>>>>>     the HMAC.
>>>>>> Shouldn’t the MS do the same thing? Otherwise different values 
>>>>>> will be obtained. This is not specified in the MS functioning 
>>>>>> description.
>>>>>
>>>>> good catch. Actually it's a typo here, the EID HMAC field should 
>>>>> be set to 0 (that is consistent with section 5.7), not the EID 
>>>>> HMAC ID that should not be touched.
>>>>>
>>>>
>>>> OK
>>>>>
>>>>> The ITR MUST set the EID HMAC ID field to 0 before computing
>>>>>     the HMAC.
>>>>>
>>>>> should change to
>>>>>
>>>>> 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.
>>>>>>>     To verify the integrity of the PKT-AD, first the MS-OTK is derived
>>>>>>>     from the locally stored ITR-OTK using the algorithm specified in the
>>>>>>>     KDF ID field.  This is because the PKT-AD is generated by the ETR
>>>>>>>     using the MS-OTK.  If the KDF ID in the Map-Reply does not match the
>>>>>>>     KDF ID requested in the Map-Request, the ITR SHOULD discard the Map-
>>>>>>>     Reply and send, at the first opportunity it needs to, a new Map-
>>>>>>>     Request with a different KDF ID, according to ITR's local policy.
>>>>>>>     The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD
>>>>>>>     using the Algorithm specified in the PKT HMAC ID field.  If the PKT
>>>>>>>     HMAC ID field does not match the Requested HMAC ID the ITR SHOULD
>>>>>>>     discard the Map-Reply and send, at the first opportunity it needs to,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 11]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     a new Map-Request with a different Requested HMAC ID according to
>>>>>>>     ITR's local policy.
>>>>>>>
>>>>>>>     Each individual Map-Reply EID-record is considered valid only if: (1)
>>>>>>>     both EID-AD and PKT-AD are valid, and (2) the intersection of the
>>>>>>>     EID-prefix in the Map-Reply EID-record with one of the EID-prefixes
>>>>>>>     contained in the EID-AD is not empty.  After identifying the Map-
>>>>>>>     Reply record as valid, the ITR sets the EID-prefix in the Map-Reply
>>>>>>>     record to the value of the intersection set computed before, and adds
>>>>>>>     the Map-Reply EID-record to its EID-to-RLOC cache, as described in
>>>>>>>     [RFC6830].  An example of Map-Reply record validation is provided in
>>>>>>>     Section 5.4.1.
>>>>>>>
>>>>>>>     The ITR SHOULD send SMR triggered Map-Requests over the mapping
>>>>>>>     system in order to receive a secure Map-Reply.
>>>>>> I do not understand this “SHOULD”.  This has consequences in the 
>>>>>> choice how to react to SMR. This is a local policy.
>>>>>> _If_ the ITR wants to protect Map-Requests using LISP-SEC, than 
>>>>>> SMR triggered Map-Request MUST be sent through the mapping system.
>>>>
>>>>> so the _if_ is what makes that MUST a SHOULD... According to local 
>>>>> policy the ITR SHOULD send the SMR.
>>>>
>>>> I read the sentence in this way:
>>>>
>>>> In order to received a secure Map-Reply, the ITR MUST send SMR 
>>>> triggered Map-Requests over the mapping system.
>>>>
>>>> No?
>>>
>>> I see what you are saying. I'll rephrase as:
>>>
>>> If an ITR accepts piggybacked Map-Replies, it SHOULD also send a 
>>> Map-Request over the mapping system in order to verify the 
>>> piggybacked Map-Reply with a secure Map-Reply.
>>>
>>>
>>>
>>>
>>>>
>>>>>>> If an ITR accepts
>>>>>>>     piggybacked Map-Replies, it SHOULD also send a Map-Request over the
>>>>>>>     mapping system in order to securely verify the piggybacked Map-Reply.
>>>>>> Same as above.
>>>>>>> 5.4.1.  Map-Reply Record Validation
>>>>>>>
>>>>>>>     The payload of a Map-Reply may contain multiple EID-records.  The
>>>>>>>     whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide
>>>>>>>     integrity protection and origin authentication to the EID-prefix
>>>>>>>     records claimed by the ETR.  The Authentication Data field of a Map-
>>>>>>>     Reply may contain multiple EID-records in the EID-AD.  The EID-AD is
>>>>>>>     signed by the Map-Server, with the EID HMAC, to provide integrity
>>>>>>>     protection and origin authentication to the EID-prefix records
>>>>>>>     inserted by the Map-Server.
>>>>>>>
>>>>>>>     Upon receiving a Map-Reply with the S-bit set, the ITR first checks
>>>>>>>     the validity of both the EID HMAC and of the PKT-AD HMAC.  If either
>>>>>>>     one of the HMACs is not valid, a log message is issued and the Map-
>>>>>>>     Reply is not processed any further.
>>>>>> I think “log message" is too much implementation specific.
>>>>>> If there is a notification, and how this notification is done, is 
>>>>>> implementation specific IMHO.
>>>>> Ok. 'a log message is issued' will change to 'a log action should 
>>>>> be taken'. The point is that there could be an attack behind it, 
>>>>> and we want to record the event
>>>>
>>>> OK
>>>>
>>>>>>> If both HMACs are valid, the ITR
>>>>>>>     proceeds with validating each individual EID-record claimed by the
>>>>>>>     ETR by computing the intersection of each one of the EID-prefix
>>>>>>>     contained in the payload of the Map-Reply with each one of the EID-
>>>>>>>     prefixes contained in the EID-AD.  An EID-record is valid only if at
>>>>>>>     least one of the intersections is not the empty set.
>>>>>>>
>>>>>>>     For instance, the Map-Reply payload contains 3 mapping record EID-
>>>>>>>     prefixes:
>>>>>>>
>>>>>>>        1.1.1.0/24
>>>>>>>
>>>>>>>        1.1.2.0/24
>>>>>>>
>>>>>>>        1.2.0.0/16
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 12]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     The EID-AD contains two EID-prefixes:
>>>>>>>
>>>>>>>        1.1.2.0/24
>>>>>>>
>>>>>>>        1.2.3.0/24
>>>>>>>
>>>>>>>     The EID-record with EID-prefix 1.1.1.0/24 is not processed since it
>>>>>>>     is not included in any of the EID-ADs signed by the Map-Server.  A
>>>>>>>     log message is issued.
>>>>>> I think “log message" is too much implementation specific.
>>>>>> If there is a notification, and how this notification is done, is 
>>>>>> implementation specific IMHO.
>>>>> ok. Same as above.
>>>>>>>     The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache
>>>>>>>     because it matches the second EID-prefix contained in the EID-AD.
>>>>>>>
>>>>>>>     The EID-record with EID-prefix 1.2.0.0/16 is not processed since it
>>>>>>>     is not included in any of the EID-ADs signed by the Map-Server.  A
>>>>>>>     log message is issued.
>>>>>> I think “log message" is too much implementation specific.
>>>>>> If there is a notification, and how this notification is done, is 
>>>>>> implementation specific IMHO.
>>>>> ok. Same as above
>>>>>>>    In this last example the ETR is trying to
>>>>>>>     over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized
>>>>>>>     only 1.2.3.0/24, hence the EID-record is discarded.
>>>>>> Reading the example I am not sure I would follow this behaviour.
>>>>>> Only 1 record out of 3 is valid so why should I actually trust 
>>>>>> the ETR instead of throwing everything away?
>>>>>> Can you explain ???
>>>>> The other two records are validated by the MS, so there is no 
>>>>> reason to throw those away.
>>>>
>>>> Yes, but the ETR is still trying to cheat on the third one….
>>>> So the ETR may be compromised, why should I send traffic to him???
>>>
>>> ITR has flagged the security exception with the log entry, and some 
>>> local ITR policy will decide what to do (including stop 
>>> encapsulating to the ETR, if that's what is specified by the 
>>> policy).  At the LISP level LISP-SEC has done its job: verified 
>>> mapping  goes into the map-cache, overclaimed mapping is dropped.
>>>
>>>
>>>>
>>>>
>>>>>>> 5.4.2.  PITR Processing
>>>>>>>
>>>>>>>     The processing performed by a PITR is equivalent to the processing of
>>>>>>>     an ITR.  However, if the PITR is directly connected to the ALT,
>>>>>> This would be LISP+ALT. Pleas add a reference to 6836.
>>>>> ok.
>>>>>>> the
>>>>>>>     PITR performs the functions of both the ITR and the Map-Resolver
>>>>>>>     forwarding the Map-Request encapsulated in an ECM header that
>>>>>>>     includes the Authentication Data fields as described in Section 5.6.
>>>>>>>
>>>>>>> 5.5.  Encrypting and Decrypting an OTK
>>>>>>>
>>>>>>>     MS-OTK confidentiality is required in the path between the Map-Server
>>>>>>>     and the ETR, the MS-OTK SHOULD
>>>>>> If confidentiality is required why there is not a MUST?
>>>>> Same.
>>>>>>>   be encrypted using the preconfigured
>>>>>>>     key shared between the Map-Server and the ETR for the purpose of
>>>>>>>     securing ETR registration [RFC6833].  Similarly, if ITR-OTK
>>>>>>>     confidentiality is required in the path between the ITR and the Map-
>>>>>>>     Resolver, the ITR-OTK SHOULD
>>>>>> Again, if confidentiality is required why there is not a MUST?
>>>>> Same.
>>>>>>> be encrypted with a key shared between
>>>>>>>     the ITR and the Map-Resolver.
>>>>>>>
>>>>>>>     The OTK is encrypted using the algorithm specified in the OTK
>>>>>>>     Encryption ID field.  When the AES Key Wrap algorithm is used to
>>>>>>>     encrypt a 128-bit OTK, according to [RFC3339],
>>>>>> The correct RFC is 3394.
>>>>> ok.
>>>>>>>   the AES Key Wrap
>>>>>>>     Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits).
>>>>>>>     The output of the AES Key Wrap operation is 192-bit long.  The most
>>>>>>>     significant 64-bit are copied in the One-Time Key Preamble field,
>>>>>>>     while the 128 less significant bits are copied in the One-Time Key
>>>>>>>     field of the LISP-SEC Authentication Data.
>>>>>>>
>>>>>>>     When decrypting an encrypted OTK the receiver MUST verify that the
>>>>>>>     Initialization Value resulting from the AES Key Wrap decryption
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 13]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     operation is equal to 0xA6A6A6A6A6A6A6A6.  If this verification fails
>>>>>>>     the receiver MUST discard the entire message.
>>>>>>>
>>>>>>>     When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set
>>>>>>>     to NULL_KEY_WRAP_128, and the OTK Preamble is set to
>>>>>>>     0x0000000000000000 (64 bits).
>>>>>>>
>>>>>>> 5.6.  Map-Resolver Processing
>>>>>>>
>>>>>>>     Upon receiving an encapsulated Map-Request with the S-bit set, the
>>>>>>>     Map-Resolver decapsulates the ECM message.  The ITR-OTK, if
>>>>>>>     encrypted, is decrypted as specified in Section 5.5.
>>>>>>>
>>>>>>>     The Map-Resolver, as specified in [RFC6833], originates a new ECM
>>>>>>>     header with the S-bit set, that contains the unencrypted ITR-OTK, as
>>>>>>>     specified in Section 5.5, and the other data derived from the ECM
>>>>>>>     Authentication Data of the received encapsulated Map-Request.
>>>>>> Few points on this last paragraph:
>>>>>> - You assume that there is no need of confidentiality inside the 
>>>>>> Mapping System?
>>>>>> - Why not stating that encryption inside the mapping system is 
>>>>>> mapping system specify and out of scope of this document?
>>>>> ok. as it was pointed out above.
>>>>>> - Why are you assuming that all of the Mapping system will use 
>>>>>> ECM? Future Mapping system may use soemthos different. The 
>>>>>> important point is to ship the AD along.
>>>>> good point, and I agree with your suggestion to fix this below.
>>>>>>>     The Map-Resolver then forwards
>>>>>> to whom?
>>>>> ok. add 'to the Map-Server'
>>>>>>>   the received Map-Request, encapsulated
>>>>>>>     in the new ECM header that includes the newly computed Authentication
>>>>>>>     Data fields.
>>>>>> As for my comment of the previous paragraph I would be more 
>>>>>> generic stating that the MR will hand over the request to the 
>>>>>> mapping system.
>>>>>> You can still provide the example of DDT using ECM.
>>>>> right.
>>>>>>> 5.7.  Map-Server Processing
>>>>>>>
>>>>>>>     Upon receiving an ECM encapsulated Map-Request with the S-bit set,
>>>>>>>     the Map-Server process the Map-Request according to the value of the
>>>>>>>     S-bit contained in the Map-Register sent by the ETR during
>>>>>>>     registration.
>>>>>>>
>>>>>>>     If the S-bit contained in the Map-Register was clear the Map-Server
>>>>>>>     decapsulates the ECM and generates a new ECM encapsulated Map-Request
>>>>>>>     that does not contain an ECM Authentication Data, as specified in
>>>>>>>     [RFC6830].  The Map-Server does not perform any further LISP-SEC
>>>>>>>     processing.
>>>>>> This equivalent to not using LISP-SEC. Please specify that the 
>>>>>> Map-Reply will be not protected.
>>>>> ok.
>>>>>>>     If the S-bit contained in the Map-Register was set the Map-Server
>>>>>>>     decapsulates the ECM and generates a new ECM Authentication Data.
>>>>>>>     The Authentication Data includes the OTK-AD and the EID-AD, that
>>>>>>>     contains EID-prefix authorization information, that are ultimately
>>>>>>>     sent to the requesting ITR.
>>>>>>>
>>>>>>>     The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from
>>>>>>>     the ITR-OTK received with the Map-Request.  MS-OTK is derived
>>>>>>>     applying the key derivation function specified in the KDF ID field.
>>>>>>>     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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 14]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     The Map-Server and the ETR MUST be configured with a shared key for
>>>>>>>     mapping registration according to [RFC6833].  If MS-OTK
>>>>>>>     confidentiality is required, then the MS-OTK SHOULD be encrypted,
>>>>>> Again, if confidentiality is required why there is not a MUST?
>>>>> same as above.
>>>>>>>   by
>>>>>>>     wrapping the MS-OTK with the algorithm specified by the OTK
>>>>>>>     Encryption ID field as specified in Section 5.5.
>>>>>>>
>>>>>>>     The Map-Server includes in the EID-AD the longest match registered
>>>>>>>     EID-prefix for the destination EID, and an HMAC of this EID-prefix.
>>>>>>>     The HMAC is keyed with the ITR-OTK contained in the received ECM
>>>>>>>     Authentication Data, and the HMAC algorithm is chosen according to
>>>>>>>     the Requested HMAC ID field.  If The Map-Server does not support this
>>>>>>>     algorithm, the Map-Server uses a different algorithm and specifies it
>>>>>>>     in the EID HMAC ID field.  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.
>>>>>>>
>>>>>>>     The Map-Server then forwards the updated ECM encapsulated Map-
>>>>>>>     Request, that contains the OTK-AD, the EID-AD, and the received Map-
>>>>>>>     Request to an authoritative ETR as specified in [RFC6830].
>>>>>>>
>>>>>>> 5.7.1.  Map-Server Processing in Proxy mode
>>>>>>>
>>>>>>>     If the Map-Server is in proxy mode, it generates a Map-Reply, as
>>>>>>>     specified in [RFC6830], with the S-bit set to 1.  The Map-Reply
>>>>>>>     includes the Authentication Data that contains the EID-AD, computed
>>>>>>>     as specified in Section 5.7, as well as the PKT-AD computed as
>>>>>>>     specified in Section 5.8.
>>>>>>>
>>>>>>> 5.8.  ETR Processing
>>>>>>>
>>>>>>>     Upon receiving an ECM encapsulated Map-Request with the S-bit set,
>>>>>>>     the ETR decapsulates the ECM message.  The OTK field, if encrypted,
>>>>>>>     is decrypted as specified in Section 5.5 to obtain the unencrypted
>>>>>>>     MS-OTK.
>>>>>>>
>>>>>>>     The ETR then generates a Map-Reply as specified in [RFC6830] and
>>>>>>>     includes the Authentication Data that contains the EID-AD, as
>>>>>>>     received in the encapsulated Map-Request, as well as the PKT-AD.
>>>>>>>
>>>>>>>     The EID-AD is copied from the Authentication Data of the received
>>>>>>>     encapsulated Map-Request.
>>>>>>>
>>>>>>>     The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed
>>>>>>>     with the MS-OTK and computed using the HMAC algorithm specified in
>>>>>>>     the Requested HMAC ID field of the received encapsulated Map-Request.
>>>>>>>     If the ETR does not support the Requested HMAC ID, it uses a
>>>>>>>     different algorithm and updates the PKT HMAC ID field accordingly.
>>>>>>>     The scope of the HMAC operation covers the entire PKT-AD, from the
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 15]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     Map-Reply Type field to the PKT HMAC field, which must be set to 0
>>>>>>>     before the computation.
>>>>>>>
>>>>>>>     Finally the ETR sends the Map-Reply to the requesting ITR as
>>>>>>>     specified in [RFC6830].
>>>>>>>
>>>>>>> 6.  Security Considerations
>>>>>>>
>>>>>>> 6.1.  Mapping System Security
>>>>>>>
>>>>>>>     The LISP-SEC threat model described in Section 3, assumes that the
>>>>>>>     LISP Mapping System is working properly and eventually delivers Map-
>>>>>>>     Request messages to a Map-Server that is authoritative for the
>>>>>>>     requested EID.
>>>>>>>
>>>>>> As for a previous comment, can you elaborate if OTK 
>>>>>> confidentiality is required in the mapping system and what are 
>>>>>> the consequences?
>>>>> ok.
>>>>>>>     Map-Register security, including the right for a LISP entity to
>>>>>>>     register an EID-prefix or to claim presence at an RLOC, is out of the
>>>>>>>     scope of LISP-SEC.
>>>>>>>
>>>>>>> 6.2.  Random Number Generation
>>>>>>>
>>>>>>>     The ITR-OTK MUST be generated by a properly seeded pseudo-random (or
>>>>>>>     strong random) source.  See [RFC4086] for advice on generating
>>>>>>>     security-sensitive random data
>>>>>>>
>>>>>>> 6.3.  Map-Server and ETR Colocation
>>>>>>>
>>>>>>>     If the Map-Server and the ETR are colocated, LISP-SEC does not
>>>>>>>     provide protection from overclaiming attacks mounted by the ETR.
>>>>>>>     However, in this particular case, since the ETR is within the trust
>>>>>>>     boundaries of the Map-Server, ETR's overclaiming attacks are not
>>>>>>>     included in the threat model.
>>>>>>>
>>>>>>> 7.  IANA Considerations
>>>>>> This section is not conform to RFC 5226.
>>>>>> There right way to go is to ask IANA to create three new 
>>>>>> registries, for HMAC, Key Wrap, and Key Derivation functions.
>>>>>> Define what is the allocation process (in light of the size of 
>>>>>> the field FCFS should not cause any problem IMHO)
>>>>>> Then ask to populate the registries as already described.
>>>>> Ok, so each one of the sections 7.x will say: IANA is requested to 
>>>>> create a new <registry-name>  registry for use …
>>>>
>>>> There is slightly more text to add.
>>>
>>> right. I have added more. I'm almost ready to send a new rev.
>>>
>>>>
>>>>
>>>>>>> 7.1.  HMAC functions
>>>>>>>
>>>>>>>     The following HMAC ID values are defined by this memo for use as
>>>>>>>     Requested HMAC ID, EID HMAC ID, and PKT HMAC ID in the LISP-SEC
>>>>>>>     Authentication Data:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 16]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>               Name                     Number        Defined In
>>>>>>>               -------------------------------------------------
>>>>>>>               NONE                     0
>>>>>>>               AUTH-HMAC-SHA-1-96       1             [RFC2104]
>>>>>>>               AUTH-HMAC-SHA-256-128    2             [RFC4634]
>>>>>>>
>>>>>>>               values 2-65535 are reserved to IANA.
>>>>>>>
>>>>>>>                                HMAC Functions
>>>>>>>
>>>>>>>     AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 should be
>>>>>>>     supported.
>>>>>>>
>>>>>>> 7.2.  Key Wrap Functions
>>>>>>>
>>>>>>>     The following OTK Encryption ID values are defined by this memo for
>>>>>>>     use as OTK key wrap algorithms ID in the LISP-SEC Authentication
>>>>>>>     Data:
>>>>>>>
>>>>>>>               Name                     Number        Defined In
>>>>>>>               -------------------------------------------------
>>>>>>>               NULL-KEY-WRAP-128        1
>>>>>>>               AES-KEY-WRAP-128         2             [RFC3394]
>>>>>>>
>>>>>>>               values 0 and 3-65535 are reserved to IANA.
>>>>>>>
>>>>>>>                              Key Wrap Functions
>>>>>>>
>>>>>>>     NULL-KEY-WRAP-128, and AES-KEY-WRAP-128 MUST be supported.
>>>>>>>
>>>>>>>     NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a
>>>>>>>     64-bit preamble set to 0x0000000000000000 (64 bits).
>>>>>>>
>>>>>>> 7.3.  Key Derivation Functions
>>>>>>>
>>>>>>>     The following KDF ID values are defined by this memo for use as KDF
>>>>>>>     ID in the LISP-SEC Authentication Data:
>>>>>>>
>>>>>>>               Name                     Number        Defined In
>>>>>>>               -------------------------------------------------
>>>>>>>               NONE                     0
>>>>>>>               HKDF-SHA1-128            1             [RFC5869]
>>>>>>>
>>>>>>>               values 2-65535 are reserved to IANA.
>>>>>>>
>>>>>>>                           Key Derivation Functions
>>>>>>>
>>>>>>>     HKDF-SHA1-128 MUST be supported
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 17]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>> 8.  Acknowledgements
>>>>>>>
>>>>>>>     The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino
>>>>>>>     Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt
>>>>>>>     Noll for their valuable suggestions provided during the preparation
>>>>>>>     of this document.
>>>>>>>
>>>>>>> 9.  Normative References
>>>>>> Please Check your reference, this is the output if the nits tool:
>>>>>> Checking references for intended status: Experimental
>>>>>> ----------------------------------------------------------------------------
>>>>>>   == Missing Reference: 'RFC3339' is mentioned on line 602, but 
>>>>>> not defined
>>>>>>   == Missing Reference: 'RFC4634' is mentioned on line 752, but 
>>>>>> not defined
>>>>>>   ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234)
>>>>> ok.
>>>>>>>     [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
>>>>>>>                Hashing for Message Authentication", RFC 2104,
>>>>>>>                DOI 10.17487/RFC2104, February 1997,
>>>>>>>                <http://www.rfc-editor.org/info/rfc2104>.
>>>>>>>
>>>>>>>     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>>>>>>>                Requirement Levels", BCP 14, RFC 2119,
>>>>>>>                DOI 10.17487/RFC2119, March 1997,
>>>>>>>                <http://www.rfc-editor.org/info/rfc2119>.
>>>>>>>
>>>>>>>     [RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
>>>>>>>                (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
>>>>>>>                September 2002, <http://www.rfc-editor.org/info/rfc3394>.
>>>>>>>
>>>>>>>     [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
>>>>>>>                "Randomness Requirements for Security", BCP 106, RFC 4086,
>>>>>>>                DOI 10.17487/RFC4086, June 2005,
>>>>>>>                <http://www.rfc-editor.org/info/rfc4086>.
>>>>>>>
>>>>>>>     [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
>>>>>>>                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
>>>>>>>                DOI 10.17487/RFC5226, May 2008,
>>>>>>>                <http://www.rfc-editor.org/info/rfc5226>.
>>>>>>>
>>>>>>>     [RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
>>>>>>>                Key Derivation Function (HKDF)", RFC 5869,
>>>>>>>                DOI 10.17487/RFC5869, May 2010,
>>>>>>>                <http://www.rfc-editor.org/info/rfc5869>.
>>>>>>>
>>>>>>>     [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
>>>>>>>                Locator/ID Separation Protocol (LISP)", RFC 6830,
>>>>>>>                DOI 10.17487/RFC6830, January 2013,
>>>>>>>                <http://www.rfc-editor.org/info/rfc6830>.
>>>>>>>
>>>>>>>     [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
>>>>>>>                Protocol (LISP) Map-Server Interface", RFC 6833,
>>>>>>>                DOI 10.17487/RFC6833, January 2013,
>>>>>>>                <http://www.rfc-editor.org/info/rfc6833>.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 18]
>>>>>>> 
>>>>>>> Internet-Draft                  LISP-SEC                    October 2016
>>>>>>>
>>>>>>>
>>>>>>>     [RFC7835]  Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
>>>>>>>                Separation Protocol (LISP) Threat Analysis", RFC 7835,
>>>>>>>                DOI 10.17487/RFC7835, April 2016,
>>>>>>>                <http://www.rfc-editor.org/info/rfc7835>.
>>>>>>>
>>>>>>> Authors' Addresses
>>>>>>>
>>>>>>>     Fabio Maino
>>>>>>>     Cisco Systems
>>>>>>>     170 Tasman Drive
>>>>>>>     San Jose, California  95134
>>>>>>>     USA
>>>>>>>
>>>>>>>     Email:[e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>     Vina Ermagan
>>>>>>>     Cisco Systems
>>>>>>>     170 Tasman Drive
>>>>>>>     San Jose, California  95134
>>>>>>>     USA
>>>>>>>
>>>>>>>     Email:[e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>     Albert Cabellos
>>>>>>>     Technical University of Catalonia
>>>>>>>     c/ Jordi Girona s/n
>>>>>>>     Barcelona  08034
>>>>>>>     Spain
>>>>>>>
>>>>>>>     Email:[e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>     Damien Saucez
>>>>>>>     INRIA
>>>>>>>     2004 route des Lucioles - BP 93
>>>>>>>     Sophia Antipolis
>>>>>>>     France
>>>>>>>
>>>>>>>     Email:[e-mail] <mailto:[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Maino, et al.             Expires April 6, 2017                [Page 19]
>>>>>
>>>>
>>>
>>
>> <Diff_ draft-ietf-lisp-sec-11.txt - 
>> draft-ietf-lisp-sec-12a.txt.html><draft-ietf-lisp-sec-12a.txt>
>