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

[Fabio Maino <[e-mail]>]

Thanks Joel,
sounds fair. I'll then add text that provides the rationale for this 
choice.


Fabio

On 10/21/16 4:35 PM, Joel M. Halpern wrote:
> The usual practice, although there are exceptions, is to indicate 
> along with the SHOULD the kinds of circumstances that would justify 
> not complying with that SHOULD while implementing (most of) the rest 
> of the RFC.
>
> Yours,
> Joel
>
> On 10/21/16 7:23 PM, Fabio Maino 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.
>>
>> 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.
>>
>>
>>
>>
>>
>> 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.
>>
>> 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.
>>
>>
>>
>>>
>>>> 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'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.
>>
>>
>>
>>>
>>>
>>>>    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.
>>
>>
>>
>>>
>>>>                      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.
>>
>> 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.
>>
>> "
>>
>>
>>
>>>
>>>>  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
>>
>>
>>>
>>>> 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).
>>
>> 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'?
>>
>>
>>
>>>
>>>
>>>>       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'
>>
>>
>>>
>>>
>>>>       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.
>>
>>> 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, so we point rather than copy. If we
>> address this in 6830bis, the problem will be solved.
>>
>>
>>>
>>>> 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.
>>
>>
>>>>  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'?
>>
>>>
>>> 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.
>>
>> "
>>
>>
>>>
>>>>    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...
>>
>> "
>>
>>>
>>>>    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.
>>
>> 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). The SHOULD leaves open the door to not discarding, according to
>> local policy.
>>
>>
>>
>>
>>>>    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.
>>
>>
>> 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.
>>>> 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
>>>> 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.
>>>> 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 ...
>>>> 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]
>>