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

[Fabio Maino <[e-mail]>]

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]
>>>
>>
>