idnits 2.17.1 draft-ietf-lisp-sec-17.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 29, 2018) is 1968 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-22 ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Experimental RFC: RFC 6836 ** Downref: Normative reference to an Informational RFC: RFC 7835 Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Maino 3 Internet-Draft V. Ermagan 4 Intended status: Standards Track Cisco Systems 5 Expires: June 2, 2019 A. Cabellos 6 Universitat Politecnica de Catalunya 7 D. Saucez 8 INRIA 9 November 29, 2018 11 LISP-Security (LISP-SEC) 12 draft-ietf-lisp-sec-17 14 Abstract 16 This memo specifies LISP-SEC, a set of security mechanisms that 17 provides origin authentication, integrity and anti-replay protection 18 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 19 process. LISP-SEC also enables verification of authorization on EID- 20 prefix claims in Map-Reply messages. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 2, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 64 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 65 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5 66 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 67 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 68 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 69 5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 11 70 5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . 11 71 5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 13 72 5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 14 73 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14 74 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15 75 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 76 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16 77 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17 80 6.2. Random Number Generation . . . . . . . . . . . . . . . . 17 81 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 82 6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 18 83 6.5. Shared Keys Provisioning . . . . . . . . . . . . . . . . 18 84 6.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 18 85 6.7. Message Privacy . . . . . . . . . . . . . . . . . . . . . 19 86 6.8. Denial of Service and Distributed Denial of Service 87 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19 90 7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19 91 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 20 92 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20 93 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 21 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 95 9. Normative References . . . . . . . . . . . . . . . . . . . . 21 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 98 1. Introduction 100 The Locator/ID Separation Protocol 101 [I-D.ietf-lisp-rfc6830bis],[I-D.ietf-lisp-rfc6833bis] is a network- 102 layer-based protocol that enables separation of IP addresses into two 103 new numbering spaces: Endpoint Identifiers (EIDs) and Routing 104 Locators (RLOCs). EID-to-RLOC mappings are stored in a database, the 105 LISP Mapping System, and made available via the Map-Request/Map-Reply 106 lookup process. If these EID-to-RLOC mappings, carried through Map- 107 Reply messages, are transmitted without integrity protection, an 108 adversary can manipulate them and hijack the communication, 109 impersonate the requested EID, or mount Denial of Service or 110 Distributed Denial of Service attacks. Also, if the Map-Reply 111 message is transported unauthenticated, an adversarial LISP entity 112 can overclaim an EID-prefix and maliciously redirect traffic directed 113 to a large number of hosts. The LISP-SEC threat model, described in 114 Section 3, is built on top of the LISP threat model defined in 115 [RFC7835], that includes a detailed description of "overclaiming" 116 attack. 118 This memo specifies LISP-SEC, a set of security mechanisms that 119 provides origin authentication, integrity and anti-replay protection 120 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 121 process. LISP-SEC also enables verification of authorization on EID- 122 prefix claims in Map-Reply messages, ensuring that the sender of a 123 Map-Reply that provides the location for a given EID-prefix is 124 entitled to do so according to the EID prefix registered in the 125 associated Map-Server. Map-Register security, including the right 126 for a LISP entity to register an EID-prefix or to claim presence at 127 an RLOC, is out of the scope of LISP-SEC. Additional security 128 considerations are described in Section 6. 130 2. Definition of Terms 132 One-Time Key (OTK): An ephemeral randomly generated key that must 133 be used for a single Map-Request/Map-Reply exchange. 135 ITR One-Time Key (ITR-OTK): The One-Time Key generated at the ITR. 137 MS One-Time Key (MS-OTK): The One-Time Key generated at the Map- 138 Server. 140 Authentication Data (AD): Metadata that is included either in a 141 LISP Encapsulated Control Message (ECM) header, as defined in 142 Section 6.1.8 of [I-D.ietf-lisp-rfc6833bis], or in a Map-Reply 143 message to support confidentiality, integrity protection, and 144 verification of EID-prefix authorization. 146 OTK Authentication Data (OTK-AD): The portion of ECM 147 Authentication Data that contains a One-Time Key. 149 EID Authentication Data (EID-AD): The portion of ECM and Map-Reply 150 Authentication Data used for verification of EID-prefix 151 authorization. 153 Packet Authentication Data (PKT-AD): The portion of Map-Reply 154 Authentication Data used to protect the integrity of the Map-Reply 155 message. 157 For definitions of other terms, notably Map-Request, Map-Reply, 158 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server 159 (MS), and Map-Resolver (MR) please consult the LISP specification 160 [I-D.ietf-lisp-rfc6833bis]. 162 3. LISP-SEC Threat Model 164 LISP-SEC addresses the control plane threats, described in section 165 3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including 166 manipulations of Map-Request and Map-Reply messages, and malicious 167 ETR EID prefix overclaiming. LISP-SEC makes two main assumptions: 168 (1) the LISP mapping system is expected to deliver a Map-Request 169 message to their intended destination ETR as identified by the EID, 170 and (2) no man-in-the-middle (MITM) attack can be mounted within the 171 LISP Mapping System. How the Mapping System is protected from MITM 172 attacks depends from the particular Mapping Systems used, and is out 173 of the scope of this memo. Furthermore, while LISP-SEC enables 174 detection of EID prefix overclaiming attacks, it assumes that Map- 175 Servers can verify the EID prefix authorization at time of 176 registration. 178 According to the threat model described in [RFC7835] LISP-SEC assumes 179 that any kind of attack, including MITM attacks, can be mounted in 180 the access network, outside of the boundaries of the LISP mapping 181 system. An on-path attacker, outside of the LISP mapping system can, 182 for example, hijack Map-Request and Map-Reply messages, spoofing the 183 identity of a LISP node. Another example of on-path attack, called 184 overclaiming attack, can be mounted by a malicious Egress Tunnel 185 Router (ETR), by overclaiming the EID-prefixes for which it is 186 authoritative. In this way the ETR can maliciously redirect traffic 187 directed to a large number of hosts. 189 4. Protocol Operations 191 The goal of the security mechanisms defined in 192 [I-D.ietf-lisp-rfc6833bis] is to prevent unauthorized insertion of 193 mapping data by providing origin authentication and integrity 194 protection for the Map-Registration, and by using the nonce to detect 195 unsolicited Map-Reply sent by off-path attackers. 197 LISP-SEC builds on top of the security mechanisms defined in 198 [I-D.ietf-lisp-rfc6833bis] to address the threats described in 199 Section 3 by leveraging the trust relationships existing among the 200 LISP entities participating to the exchange of the Map-Request/Map- 201 Reply messages. Those trust relationships are used to securely 202 distribute a One-Time Key (OTK) that provides origin authentication, 203 integrity and anti-replay protection to mapping data conveyed via the 204 mapping lookup process, and that effectively prevent overclaiming 205 attacks. The processing of security parameters during the Map- 206 Request/Map-Reply exchange is as follows: 208 o The ITR-OTK is generated and stored at the ITR, and securely 209 transported to the Map-Server. 211 o The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for 212 Message Authentication (HMAC) [RFC2104] that protects the 213 integrity of the mapping data known to the Map-Server to prevent 214 overclaiming attacks. The Map-Server also derives a new OTK, the 215 MS-OTK, that is passed to the ETR, by applying a Key Derivation 216 Function (KDF) to the ITR-OTK. 218 o The ETR uses the MS-OTK to compute an HMAC that protects the 219 integrity of the Map-Reply sent to the ITR. 221 o Finally, the ITR uses the stored ITR-OTK to verify the integrity 222 of the mapping data provided by both the Map-Server and the ETR, 223 and to verify that no overclaiming attacks were mounted along the 224 path between the Map-Server and the ITR. 226 Section 5 provides the detailed description of the LISP-SEC control 227 messages and their processing, while the rest of this section 228 describes the flow of protocol operations at each entity involved in 229 the Map-Request/Map-Reply exchange: 231 o The ITR, upon needing to transmit a Map-Request message, generates 232 and stores an OTK (ITR-OTK). This ITR-OTK is included into the 233 Encapsulated Control Message (ECM) that contains the Map-Request 234 sent to the Map-Resolver. To provide confidentiality to the ITR- 235 OTK over the path between the ITR and its Map-Resolver, the ITR- 236 OTK SHOULD be encrypted using a preconfigured key shared between 237 the ITR and the Map-Resolver, similar to the key shared between 238 the ETR and the Map-Server in order to secure ETR registration 239 [I-D.ietf-lisp-rfc6833bis]. 241 o The Map-Resolver decapsulates the ECM message, decrypts the ITR- 242 OTK, if needed, and forwards through the Mapping System the 243 received Map-Request and the ITR-OTK, as part of a new ECM 244 message. As described in Section 5.6, the LISP Mapping System 245 delivers the ECM to the appropriate Map-Server, as identified by 246 the EID destination address of the Map-Request. 248 o The Map-Server is configured with the location mappings and policy 249 information for the ETR responsible for the EID destination 250 address. Using this preconfigured information, the Map-Server, 251 after the decapsulation of the ECM message, finds the longest 252 match EID-prefix that covers the requested EID in the received 253 Map-Request. The Map-Server adds this EID-prefix, together with 254 an HMAC computed using the ITR-OTK, to a new Encapsulated Control 255 Message that contains the received Map-Request. 257 o The Map-Server derives a new OTK, the MS-OTK, by applying a Key 258 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included 259 in the Encapsulated Control Message that the Map-Server uses to 260 forward the Map-Request to the ETR. To provide MS-OTK 261 confidentiality over the path between the Map-Server and the ETR, 262 the MS-OTK SHOULD be encrypted using the key shared between the 263 ETR and the Map-Server in order to secure ETR registration 264 [I-D.ietf-lisp-rfc6833bis]. 266 o If the Map-Server is acting in proxy mode, as specified in 267 [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the 268 generation of the Map-Reply. In this case the Map-Server 269 generates the Map-Reply on behalf of the ETR as described below. 271 o The ETR, upon receiving the ECM encapsulated Map-Request from the 272 Map-Server, decrypts the MS-OTK, if needed, and originates a 273 standard Map-Reply that contains the EID-to-RLOC mapping 274 information as specified in [I-D.ietf-lisp-rfc6833bis]. 276 o The ETR computes an HMAC over this standard Map-Reply, keyed with 277 MS-OTK to protect the integrity of the whole Map-Reply. The ETR 278 also copies the EID-prefix authorization data that the Map-Server 279 included in the ECM encapsulated Map-Request into the Map-Reply 280 message. The ETR then sends this complete Map-Reply message to 281 the requesting ITR. 283 o The ITR, upon receiving the Map-Reply, uses the locally stored 284 ITR-OTK to verify the integrity of the EID-prefix authorization 285 data included in the Map-Reply by the Map-Server. The ITR 286 computes the MS-OTK by applying the same KDF used by the Map- 287 Server, and verifies the integrity of the Map-Reply. If the 288 integrity checks fail, the Map-Reply MUST be discarded. Also, if 289 the EID-prefixes claimed by the ETR in the Map-Reply are not equal 290 or more specific than the EID-prefix authorization data inserted 291 by the Map-Server, the ITR MUST discard the Map-Reply. 293 5. LISP-SEC Control Messages Details 295 LISP-SEC metadata associated with a Map-Request is transported within 296 the Encapsulated Control Message that contains the Map-Request. 298 LISP-SEC metadata associated with the Map-Reply is transported within 299 the Map-Reply itself. 301 5.1. Encapsulated Control Message LISP-SEC Extensions 303 LISP-SEC uses the ECM (Encapsulated Control Message) defined in 304 [I-D.ietf-lisp-rfc6833bis] with Type set to 8, and S bit set to 1 to 305 indicate that the LISP header includes Authentication Data (AD). The 306 format of the LISP-SEC ECM Authentication Data is defined in the 307 following figure. OTK-AD stands for One-Time Key Authentication Data 308 and EID-AD stands for EID Authentication Data. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | ECM AD Type |V| Reserved | Requested HMAC ID | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 315 | OTK Length | OTK Encryption ID | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 317 | One-Time-Key Preamble ... | | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD 319 | ... One-Time-Key Preamble | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 321 ~ One-Time Key (128 bits) ~/ 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 323 | EID-AD Length | KDF ID | | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 325 | Record Count | Reserved | EID HMAC ID |EID-AD 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 327 | Reserved | EID mask-len | EID-AFI | | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 329 ~ EID-prefix ... ~ | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 331 ~ EID HMAC ~ | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 334 LISP-SEC ECM Authentication Data 336 ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 338 V: Key Version bit. This bit is toggled when the sender switches 339 to a new OTK wrapping key 341 Reserved: Set to 0 on transmission and ignored on receipt. 343 Requested HMAC ID: The HMAC algorithm requested by the ITR. See 344 Section 5.4 for details. 346 OTK Length: The length (in bytes) of the OTK Authentication Data 347 (OTK-AD), that contains the OTK Preamble and the OTK. 349 OTK Encryption ID: The identifier of the key wrapping algorithm 350 used to encrypt the One-Time-Key. When a 128-bit OTK is sent 351 unencrypted by the Map-Resolver, the OTK Encryption ID is set to 352 NULL_KEY_WRAP_128. See Section 5.5 for more details. 354 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 355 the OTK is encrypted, this field MAY carry additional metadata 356 resulting from the key wrapping operation. When a 128-bit OTK is 357 sent unencrypted by Map-Resolver, the OTK Preamble is set to 358 0x0000000000000000 (64 bits). See Section 5.5 for details. 360 One-Time-Key: the OTK encrypted (or not) as specified by OTK 361 Encryption ID. See Section 5.5 for details. 363 EID-AD Length: length (in bytes) of the EID Authentication Data 364 (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only 365 fills the KDF ID field, and all the remaining fields part of the 366 EID-AD are not present. An EID-AD MAY contain multiple EID- 367 records. Each EID-record is 4-byte long plus the length of the 368 AFI-encoded EID-prefix. 370 KDF ID: Identifier of the Key Derivation Function used to derive 371 the MS-OTK. The ITR MAY use this field to indicate the 372 recommended KDF algorithm, according to local policy. The Map- 373 Server can overwrite the KDF ID if it does not support the KDF ID 374 recommended by the ITR. See Section 5.4 for more details. 376 Record Count: The number of records in this Map-Request message. 377 A record is comprised of the portion of the packet that is labeled 378 'Rec' above and occurs the number of times equal to Record Count. 380 Reserved: Set to 0 on transmission and ignored on receipt. 382 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 383 integrity of the EID-AD. This field is filled by Map-Server that 384 computed the EID-prefix HMAC. See Section 5.4 for more details. 386 EID mask-len: Mask length for EID-prefix. 388 EID-AFI: Address family of EID-prefix according to [RFC5226] 390 EID-prefix: The Map-Server uses this field to specify the EID- 391 prefix that the destination ETR is authoritative for, and is the 392 longest match for the requested EID. 394 EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. 395 Before computing the HMAC operation the EID HMAC field MUST be set 396 to 0. The HMAC covers the entire EID-AD. 398 5.2. Map-Reply LISP-SEC Extensions 400 LISP-SEC uses the Map-Reply defined in [I-D.ietf-lisp-rfc6833bis], 401 with Type set to 2, and S bit set to 1 to indicate that the Map-Reply 402 message includes Authentication Data (AD). The format of the LISP- 403 SEC Map-Reply Authentication Data is defined in the following figure. 405 PKT-AD is the Packet Authentication Data that covers the Map-Reply 406 payload. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | MR AD Type | Reserved | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 413 | EID-AD Length | KDF ID | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 415 | Record Count | Reserved | EID HMAC ID |EID-AD 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 417 | Reserved | EID mask-len | EID-AFI | | | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 419 ~ EID-prefix ... ~ | | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 421 ~ EID HMAC ~ | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 423 | PKT-AD Length | PKT HMAC ID |\ 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 425 ~ PKT HMAC ~PKT-AD 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 428 LISP-SEC Map-Reply Authentication Data 430 MR AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 432 EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY 433 contain multiple EID-records. Each EID-record is 4-byte long plus 434 the length of the AFI-encoded EID-prefix. 436 KDF ID: Identifier of the Key Derivation Function used to derive 437 MS-OTK. See Section 5.7 for more details. 439 Record Count: The number of records in this Map-Reply message. A 440 record is comprised of the portion of the packet that is labeled 441 'Rec' above and occurs the number of times equal to Record Count. 443 Reserved: Set to 0 on transmission and ignored on receipt. 445 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 446 integrity of the EID-AD. See Section 5.7 for more details. 448 EID mask-len: Mask length for EID-prefix. 450 EID-AFI: Address family of EID-prefix according to [RFC5226]. 452 EID-prefix: This field contains an EID-prefix that the destination 453 ETR is authoritative for, and is the longest match for the 454 requested EID. 456 EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. 457 Before computing the HMAC operation the EID HMAC field MUST be set 458 to 0. The HMAC covers the entire EID-AD. 460 PKT-AD Length: length (in bytes) of the Packet Authentication Data 461 (PKT-AD). 463 PKT HMAC ID: Identifier of the HMAC algorithm used to protect the 464 integrity of the Map-reply. 466 PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- 467 SEC Authentication Data. The scope of the authentication goes 468 from the Map-Reply Type field to the PKT HMAC field included. 469 Before computing the HMAC operation the PKT HMAC field MUST be set 470 to 0. See Section 5.8 for more details. 472 5.3. Map-Register LISP-SEC Extentions 474 This memo is allocating one of the bits marked as Reserved in the 475 Map-Register message defined in Section 6.1.6 of 476 [I-D.ietf-lisp-rfc6833bis]. More precisely, the second bit after the 477 Type field in a Map-Register message is allocated as the S bit. The 478 S bit indicates to the Map-Server that the registering ETR is LISP- 479 SEC enabled. An ETR that supports LISP-SEC MUST set the S bit in its 480 Map-Register messages. 482 5.4. ITR Processing 484 Upon creating a Map-Request, the ITR generates a random ITR-OTK that 485 is stored locally, together with the nonce generated as specified in 486 [I-D.ietf-lisp-rfc6833bis]. 488 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 489 1, to indicate the presence of Authentication Data. If the ITR and 490 the Map-Resolver are configured with a shared key, the ITR-OTK 491 confidentiality SHOULD be protected by wrapping the ITR-OTK with the 492 algorithm specified by the OTK Encryption ID field. See Section 5.5 493 for further details on OTK encryption. 495 The Requested HMAC ID field contains the suggested HMAC algorithm to 496 be used by the Map-Server and the ETR to protect the integrity of the 497 ECM Authentication data and of the Map-Reply. 499 The KDF ID field specifies the suggested key derivation function to 500 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE 501 (0), MAY be used to specify that the ITR has no preferred KDF ID. 503 The EID-AD length is set to 4 bytes, since the Authentication Data 504 does not contain EID-prefix Authentication Data, and the EID-AD 505 contains only the KDF ID field. 507 In response to an encapsulated Map-Request that has the S-bit set, an 508 ITR MUST receive a Map-Reply with the S-bit set, that includes an 509 EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the 510 ITR MUST discard it. In response to an encapsulated Map-Request with 511 S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and 512 the ITR SHOULD discard the Map-Reply if the S-bit is set. 514 Upon receiving a Map-Reply, the ITR must verify the integrity of both 515 the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of 516 the integrity checks fails. After processing the Map-Reply, the ITR 517 must discard the pair associated to the Map-Reply 519 The integrity of the EID-AD is verified using the locally stored ITR- 520 OTK to re-compute the HMAC of the EID-AD using the algorithm 521 specified in the EID HMAC ID field. If the EID HMAC ID field does 522 not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply 523 and send, at the first opportunity it needs to, a new Map-Request 524 with a different Requested HMAC ID field, according to ITR's local 525 policy. The scope of the HMAC operation covers the entire EID-AD, 526 from the EID-AD Length field to the EID HMAC field, which must be set 527 to 0 before the computation of the HMAC. 529 ITR MUST set the EID HMAC ID field to 0 before computing the HMAC. 531 To verify the integrity of the PKT-AD, first the MS-OTK is derived 532 from the locally stored ITR-OTK using the algorithm specified in the 533 KDF ID field. This is because the PKT-AD is generated by the ETR 534 using the MS-OTK. If the KDF ID in the Map-Reply does not match the 535 KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- 536 Reply and send, at the first opportunity it needs to, a new Map- 537 Request with a different KDF ID, according to ITR's local policy. 539 The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD 540 using the Algorithm specified in the PKT HMAC ID field. If the PKT 541 HMAC ID field does not match the Requested HMAC ID the ITR SHOULD 542 discard the Map-Reply and send, at the first opportunity it needs to, 543 a new Map-Request with a different Requested HMAC ID according to 544 ITR's local policy or until all HMAC IDs supported by the ITR have 545 been attempted. 547 Each individual Map-Reply EID-record is considered valid only if: (1) 548 both EID-AD and PKT-AD are valid, and (2) the intersection of the 549 EID-prefix in the Map-Reply EID-record with one of the EID-prefixes 550 contained in the EID-AD is not empty. After identifying the Map- 551 Reply record as valid, the ITR sets the EID-prefix in the Map-Reply 552 record to the value of the intersection set computed before, and adds 553 the Map-Reply EID-record to its EID-to-RLOC cache, as described in 554 [I-D.ietf-lisp-rfc6833bis]. An example of Map-Reply record 555 validation is provided in Section 5.4.1. 557 The ITR SHOULD send SMR triggered Map-Requests over the mapping 558 system in order to receive a secure Map-Reply. If an ITR accepts 559 piggybacked Map-Replies, it SHOULD also send a Map-Request over the 560 mapping system in order to verify the piggybacked Map-Reply with a 561 secure Map-Reply. 563 5.4.1. Map-Reply Record Validation 565 The payload of a Map-Reply may contain multiple EID-records. The 566 whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide 567 integrity protection and origin authentication to the EID-prefix 568 records claimed by the ETR. The Authentication Data field of a Map- 569 Reply may contain multiple EID-records in the EID-AD. The EID-AD is 570 signed by the Map-Server, with the EID HMAC, to provide integrity 571 protection and origin authentication to the EID-prefix records 572 inserted by the Map-Server. 574 Upon receiving a Map-Reply with the S-bit set, the ITR first checks 575 the validity of both the EID HMAC and of the PKT-AD HMAC. If either 576 one of the HMACs is not valid, a log action MUST be taken and the 577 Map-Reply MUST NOT be processed any further. If both HMACs are 578 valid, the ITR proceeds with validating each individual EID-record 579 claimed by the ETR by computing the intersection of each one of the 580 EID-prefix contained in the payload of the Map-Reply with each one of 581 the EID-prefixes contained in the EID-AD. An EID-record is valid 582 only if at least one of the intersections is not the empty set. 584 For instance, the Map-Reply payload contains 3 mapping record EID- 585 prefixes: 587 2001:db8:0102::/48 589 2001:db8:0103::/48 591 2001:db8:0200::/40 593 The EID-AD contains two EID-prefixes: 595 2001:db8:0103::/48 597 2001:db8:0203::/48 599 The EID-record with EID-prefix 2001:db8:0102::/48 is not eligible to 600 be used by the ITR since it is not included in any of the EID-ADs 601 signed by the Map-Server. A log action MUST be taken. 603 The EID-record with EID-prefix 2001:db8:0103::/48 is eligible to be 604 used by the ITR because it matches the second EID-prefix contained in 605 the EID-AD. 607 The EID-record with EID-prefix 2001:db8:0200::/40 is not eligible to 608 be used by the ITR since it is not included in any of the EID-ADs 609 signed by the Map-Server. A log action MUST be taken. In this last 610 example the ETR is trying to over claim the EID-prefix 611 2001:db8:0200::/40, but the Map-Server authorized only 612 2001:db8:0203::/48, hence the EID-record is discarded. 614 5.4.2. PITR Processing 616 The processing performed by a PITR is equivalent to the processing of 617 an ITR. However, if the PITR is directly connected to a Mapping 618 System such as LISP+ALT [RFC6836], the PITR performs the functions of 619 both the ITR and the Map-Resolver forwarding the Map-Request 620 encapsulated in an ECM header that includes the Authentication Data 621 fields as described in Section 5.6. 623 5.5. Encrypting and Decrypting an OTK 625 MS-OTK confidentiality is required in the path between the Map-Server 626 and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured 627 key shared between the Map-Server and the ETR for the purpose of 628 securing ETR registration [I-D.ietf-lisp-rfc6833bis]. Similarly, if 629 ITR-OTK confidentiality is required in the path between the ITR and 630 the Map-Resolver, the ITR-OTK SHOULD be encrypted with a key shared 631 between the ITR and the Map-Resolver. 633 The OTK is encrypted using the algorithm specified in the OTK 634 Encryption ID field. When the AES Key Wrap algorithm is used to 635 encrypt a 128-bit OTK, according to [RFC3394], the AES Key Wrap 636 Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). 637 The output of the AES Key Wrap operation is 192-bit long. The most 638 significant 64-bit are copied in the One-Time Key Preamble field, 639 while the 128 less significant bits are copied in the One-Time Key 640 field of the LISP-SEC Authentication Data. 642 When decrypting an encrypted OTK the receiver MUST verify that the 643 Initialization Value resulting from the AES Key Wrap decryption 644 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 645 the receiver MUST discard the entire message. 647 When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set 648 to NULL_KEY_WRAP_128, and the OTK Preamble is set to 649 0x0000000000000000 (64 bits). 651 5.6. Map-Resolver Processing 653 Upon receiving an encapsulated Map-Request with the S-bit set, the 654 Map-Resolver decapsulates the ECM message. The ITR-OTK, if 655 encrypted, is decrypted as specified in Section 5.5. 657 Protecting the confidentiality of the ITR-OTK and, in general, the 658 security of how the Map-Request is handed by the Map-Resolver to the 659 Map-Server, is specific to the particular Mapping System used, and 660 outside of the scope of this memo. 662 In Mapping Systems where the Map-Server is compliant with 663 [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM 664 header with the S-bit set, that contains the unencrypted ITR-OTK, as 665 specified in Section 5.5, and the other data derived from the ECM 666 Authentication Data of the received encapsulated Map-Request. 668 The Map-Resolver then forwards to the Map-Server the received Map- 669 Request, encapsulated in the new ECM header that includes the newly 670 computed Authentication Data fields. 672 5.7. Map-Server Processing 674 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 675 the Map-Server process the Map-Request according to the value of the 676 S-bit contained in the Map-Register sent by the ETR during 677 registration. 679 If the S-bit contained in the Map-Register was clear the Map-Server 680 decapsulates the ECM and generates a new ECM encapsulated Map-Request 681 that does not contain an ECM Authentication Data, as specified in 682 [I-D.ietf-lisp-rfc6833bis]. The Map-Server does not perform any 683 further LISP-SEC processing, and the Map-Reply will not be protected. 685 If the S-bit contained in the Map-Register was set the Map-Server 686 decapsulates the ECM and generates a new ECM Authentication Data. 687 The Authentication Data includes the OTK-AD and the EID-AD, that 688 contains EID-prefix authorization information, that are ultimately 689 sent to the requesting ITR. 691 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from 692 the ITR-OTK received with the Map-Request. MS-OTK is derived 693 applying the key derivation function specified in the KDF ID field. 694 If the algorithm specified in the KDF ID field is not supported, the 695 Map-Server uses a different algorithm to derive the key and updates 696 the KDF ID field accordingly. 698 The Map-Server and the ETR MUST be configured with a shared key for 699 mapping registration according to [I-D.ietf-lisp-rfc6833bis]. If MS- 700 OTK confidentiality is required, then the MS-OTK SHOULD be encrypted, 701 by wrapping the MS-OTK with the algorithm specified by the OTK 702 Encryption ID field as specified in Section 5.5. 704 The Map-Server includes in the EID-AD the longest match registered 705 EID-prefix for the destination EID, and an HMAC of this EID-prefix. 706 The HMAC is keyed with the ITR-OTK contained in the received ECM 707 Authentication Data, and the HMAC algorithm is chosen according to 708 the Requested HMAC ID field. If The Map-Server does not support this 709 algorithm, the Map-Server uses a different algorithm and specifies it 710 in the EID HMAC ID field. The scope of the HMAC operation covers the 711 entire EID-AD, from the EID-AD Length field to the EID HMAC field, 712 which must be set to 0 before the computation. 714 The Map-Server then forwards the updated ECM encapsulated Map- 715 Request, that contains the OTK-AD, the EID-AD, and the received Map- 716 Request to an authoritative ETR as specified in 717 [I-D.ietf-lisp-rfc6833bis]. 719 5.7.1. Map-Server Processing in Proxy mode 721 If the Map-Server is in proxy mode, it generates a Map-Reply, as 722 specified in [I-D.ietf-lisp-rfc6833bis], with the S-bit set to 1. 723 The Map-Reply includes the Authentication Data that contains the EID- 724 AD, computed as specified in Section 5.7, as well as the PKT-AD 725 computed as specified in Section 5.8. 727 5.8. ETR Processing 729 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 730 the ETR decapsulates the ECM message. The OTK field, if encrypted, 731 is decrypted as specified in Section 5.5 to obtain the unencrypted 732 MS-OTK. 734 The ETR then generates a Map-Reply as specified in 735 [I-D.ietf-lisp-rfc6833bis] and includes the Authentication Data that 736 contains the EID-AD, as received in the encapsulated Map-Request, as 737 well as the PKT-AD. 739 The EID-AD is copied from the Authentication Data of the received 740 encapsulated Map-Request. 742 The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed 743 with the MS-OTK and computed using the HMAC algorithm specified in 744 the Requested HMAC ID field of the received encapsulated Map-Request. 745 If the ETR does not support the Requested HMAC ID, it uses a 746 different algorithm and updates the PKT HMAC ID field accordingly. 747 The scope of the HMAC operation covers the entire PKT-AD, from the 748 Map-Reply Type field to the PKT HMAC field, which must be set to 0 749 before the computation. 751 Finally the ETR sends the Map-Reply to the requesting ITR as 752 specified in [I-D.ietf-lisp-rfc6833bis]. 754 6. Security Considerations 756 6.1. Mapping System Security 758 The LISP-SEC threat model described in Section 3, assumes that the 759 LISP Mapping System is working properly and eventually delivers Map- 760 Request messages to a Map-Server that is authoritative for the 761 requested EID. 763 It is assumed that the Mapping System ensures the confidentiality of 764 the OTK, and the integrity of the Map-Reply data. However, how the 765 LISP Mapping System is secured is out of the scope of this document. 767 Similarly, Map-Register security, including the right for a LISP 768 entity to register an EID-prefix or to claim presence at an RLOC, is 769 out of the scope of LISP-SEC. 771 6.2. Random Number Generation 773 The ITR-OTK MUST be generated by a properly seeded pseudo-random (or 774 strong random) source. See [RFC4086] for advice on generating 775 security-sensitive random data 777 6.3. Map-Server and ETR Colocation 779 If the Map-Server and the ETR are colocated, LISP-SEC does not 780 provide protection from overclaiming attacks mounted by the ETR. 781 However, in this particular case, since the ETR is within the trust 782 boundaries of the Map-Server, ETR's overclaiming attacks are not 783 included in the threat model. 785 6.4. Deploying LISP-SEC 787 This memo is written according to [RFC2119]. Specifically, the use 788 of the key word SHOULD "or the adjective 'RECOMMENDED', mean that 789 there may exist valid reasons in particular circumstances to ignore a 790 particular item, but the full implications must be understood and 791 carefully weighed before choosing a different course". 793 Those deploying LISP-SEC according to this memo, should carefully 794 weight how the LISP-SEC threat model applies to their particular use 795 case or deployment. If they decide to ignore a particular 796 recommendation, they should make sure the risk associated with the 797 corresponding threats is well understood. 799 As an example, in certain closed and controlled deployments, it is 800 possible that the threat associated with a MiTM between the xTR and 801 the Mapping System is very low, and after carfeul consideration it 802 may be decided to allow a NULL key wrapping algorithm while carrying 803 the OTKs between the xTR and the Mapping System. 805 As an example at the other end of the spectrum, in certain other 806 deployments, attackers may be very sophisticated, and force the 807 deployers to enforce very strict policies in term of HMAC algorithms 808 accepted by an ITR. 810 Similar considerations apply to the entire LISP-SEC threat model, and 811 should guide the deployers and implementors whenever they encounter 812 the key word SHOULD across this memo. 814 6.5. Shared Keys Provisioning 816 Provisioning of the keys shared between the ITR and the Map-Resolver 817 as well as between the ETR and the Map-Server should be performed via 818 an orchestration infrastructure and it is out of the scope of this 819 draft. It is recommended that both shared keys are refreshed at 820 periodical intervals to address key aging or attackers gaining 821 unauthorized access to the shared keys. Shared keys should be 822 unpredictable random values. 824 6.6. Replay Attacks 826 An attacker can capture a valid Map-Request and/or Map-Reply and 827 replay it, however once the ITR receives the original Map-Reply the 828 pair stored at the ITR will be discarded. If a 829 replayed Map-Reply arrives at the ITR, there is no 830 that matches the incoming Map-Reply and will be discarded. 832 In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR 833 will have to do a LISP-SEC computation. This is equivalent to a 834 valid LISP-SEC computation and an attacker does not obtain any 835 benefit. 837 6.7. Message Privacy 839 DTLS [RFC6347] SHOULD be used to provide communication privacy and to 840 prevent eavesdropping, tampering, or message forgery to the messages 841 exchanged between the ITR, Map-Resolver, Map-Server, and ETR. 843 6.8. Denial of Service and Distributed Denial of Service Attacks 845 LISP-SEC mitigates the risks of Denial of Service and Distributed 846 Denial of Service attacks by protecting the integrity and 847 authenticating the origin of the Map-Request/Map-Reply messages, and 848 by preventing malicious ETRs from overclaiming EID prefixes that 849 could re-direct traffic directed to a potentially large number of 850 hosts. 852 7. IANA Considerations 854 7.1. ECM AD Type Registry 856 IANA is requested to create the "ECM Authentication Data Type" 857 registry with values 0-255, for use in the ECM LISP-SEC Extensions 858 Section 5.1. The registry MUST be initially populated with the 859 following values: 861 Name Value Defined In 862 ------------------------------------------------- 863 Reserved 0 This memo 864 LISP-SEC-ECM-EXT 1 This memo 866 HMAC Functions 868 Values 2-255 are unassigned. They are to be assigned according to 869 the "Specification Required" policy defined in [RFC5226]. 871 7.2. Map-Reply AD Type Registry 873 IANA is requested to create the "Map-Reply Authentication Data Type" 874 registry with values 0-255, for use in the Map-Reply LISP-SEC 875 Extensions Section 5.2. The registry MUST be initially populated 876 with the following values: 878 Name Value Defined In 879 ------------------------------------------------- 880 Reserved 0 This memo 881 LISP-SEC-MR-EXT 1 This memo 883 HMAC Functions 885 Values 2-255 are unassigned. They are to be assigned according to 886 the "Specification Required" policy defined in [RFC5226]. 888 7.3. HMAC Functions 890 IANA is requested to create the "LISP-SEC Authentication Data HMAC 891 ID" registry with values 0-65535 for use as Requested HMAC ID, EID 892 HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data: 894 Name Number Defined In 895 ------------------------------------------------- 896 NONE 0 This memo 897 AUTH-HMAC-SHA-1-96 1 [RFC2104] 898 AUTH-HMAC-SHA-256-128 2 [RFC6234] 900 HMAC Functions 902 Values 3-65535 are unassigned. They are to be assigned according to 903 the "Specification Required" policy defined in [RFC5226]. 905 AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be 906 supported. 908 7.4. Key Wrap Functions 910 IANA is requested to create the "LISP-SEC Authentication Data Key 911 Wrap ID" registry with values 0-65535 for use as OTK key wrap 912 algorithms ID in the LISP-SEC Authentication Data: 914 Name Number Defined In 915 ------------------------------------------------- 916 Reserved 0 This memo 917 NULL-KEY-WRAP-128 1 This memo 918 AES-KEY-WRAP-128 2 [RFC3394] 920 Key Wrap Functions 922 Values 3-65535 are unassigned. They are to be assigned according to 923 the "Specification Required" policy defined in [RFC5226]. 925 NULL-KEY-WRAP-128, and AES-KEY-WRAP-128 MUST be supported. 927 NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 928 64-bit preamble set to 0x0000000000000000 (64 bits). 930 7.5. Key Derivation Functions 932 IANA is requested to create the "LISP-SEC Authentication Data Key 933 Derivation Function ID" registry with values 0-65535 for use as KDF 934 ID in the LISP-SEC Authentication Data: 936 Name Number Defined In 937 ------------------------------------------------- 938 NONE 0 This memo 939 HKDF-SHA1-128 1 [RFC5869] 941 Key Derivation Functions 943 Values 2-65535 are unassigned. They are to be assigned according to 944 the "Specification Required" policy defined in [RFC5226]. 946 HKDF-SHA1-128 MUST be supported 948 8. Acknowledgements 950 The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino 951 Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt 952 Noll for their valuable suggestions provided during the preparation 953 of this document. 955 9. Normative References 957 [I-D.ietf-lisp-rfc6830bis] 958 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 959 Cabellos-Aparicio, "The Locator/ID Separation Protocol 960 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 961 November 2018. 963 [I-D.ietf-lisp-rfc6833bis] 964 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 965 "Locator/ID Separation Protocol (LISP) Control-Plane", 966 draft-ietf-lisp-rfc6833bis-22 (work in progress), November 967 2018. 969 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 970 Hashing for Message Authentication", RFC 2104, 971 DOI 10.17487/RFC2104, February 1997, . 974 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 975 Requirement Levels", BCP 14, RFC 2119, 976 DOI 10.17487/RFC2119, March 1997, . 979 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 980 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 981 September 2002, . 983 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 984 "Randomness Requirements for Security", BCP 106, RFC 4086, 985 DOI 10.17487/RFC4086, June 2005, . 988 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 989 IANA Considerations Section in RFCs", RFC 5226, 990 DOI 10.17487/RFC5226, May 2008, . 993 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 994 Key Derivation Function (HKDF)", RFC 5869, 995 DOI 10.17487/RFC5869, May 2010, . 998 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 999 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1000 DOI 10.17487/RFC6234, May 2011, . 1003 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1004 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1005 January 2012, . 1007 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1008 "Locator/ID Separation Protocol Alternative Logical 1009 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1010 January 2013, . 1012 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1013 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1014 DOI 10.17487/RFC7835, April 2016, . 1017 Authors' Addresses 1019 Fabio Maino 1020 Cisco Systems 1021 170 Tasman Drive 1022 San Jose, California 95134 1023 USA 1025 Email: fmaino@cisco.com 1027 Vina Ermagan 1028 Cisco Systems 1029 170 Tasman Drive 1030 San Jose, California 95134 1031 USA 1033 Email: vermagan@cisco.com 1035 Albert Cabellos 1036 Universitat Politecnica de Catalunya 1037 c/ Jordi Girona s/n 1038 Barcelona 08034 1039 Spain 1041 Email: acabello@ac.upc.edu 1043 Damien Saucez 1044 INRIA 1045 2004 route des Lucioles - BP 93 1046 Sophia Antipolis 1047 France 1049 Email: damien.saucez@inria.fr