This would be great Fabio. Thanks. Ciao
L. > On 22 Oct 2016, at 02:19, Fabio Maino <[email protected]> wrote: > > 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: [email protected] <mailto:[email protected]> >>>>> >>>>> >>>>> Vina Ermagan >>>>> Cisco Systems >>>>> 170 Tasman Drive >>>>> San Jose, California 95134 >>>>> USA >>>>> >>>>> Email: [email protected] <mailto:[email protected]> >>>>> >>>>> >>>>> Albert Cabellos >>>>> Technical University of Catalonia >>>>> c/ Jordi Girona s/n >>>>> Barcelona 08034 >>>>> Spain >>>>> >>>>> Email: [email protected] <mailto:[email protected]> >>>>> >>>>> >>>>> Damien Saucez >>>>> INRIA >>>>> 2004 route des Lucioles - BP 93 >>>>> Sophia Antipolis >>>>> France >>>>> >>>>> Email: [email protected] <mailto:[email protected]> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Maino, et al. Expires April 6, 2017 [Page 19] >>> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
