idnits 2.17.1 draft-ietf-lisp-sec-18.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 2, 2019) is 1752 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) == Missing Reference: 'Key ID' is mentioned on line 621, but not defined == Missing Reference: 'RFC6234' is mentioned on line 1075, but not defined == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-24 ** 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 ** 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 ** Downref: Normative reference to an Experimental RFC: RFC 8060 == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-26 Summary: 8 errors (**), 0 flaws (~~), 6 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 Cisco Systems 4 Intended status: Standards Track V. Ermagan 5 Expires: December 4, 2019 Google 6 A. Cabellos 7 Universitat Politecnica de Catalunya 8 D. Saucez 9 INRIA 10 June 2, 2019 12 LISP-Security (LISP-SEC) 13 draft-ietf-lisp-sec-18 15 Abstract 17 This memo specifies LISP-SEC, a set of security mechanisms that 18 provides origin authentication, integrity and anti-replay protection 19 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 20 process. LISP-SEC also enables verification of authorization on EID- 21 prefix claims in Map-Reply messages. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in BCP14 [RFC2119] 28 [RFC8174] when, and only when, they appear in all capitals, as shown 29 here. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 4, 2019. 48 Copyright Notice 50 Copyright (c) 2019 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 67 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 68 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5 69 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 70 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 71 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 10 72 5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 11 73 5.4. ITR Processing: Generating a Map-Request . . . . . . . . 12 74 5.4.1. PITR Processing . . . . . . . . . . . . . . . . . . . 12 75 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 12 76 5.5.1. Unencrypted OTK . . . . . . . . . . . . . . . . . . . 14 77 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 78 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 79 5.7.1. Generating a LISP-SEC Protected Encapsulated Map- 80 Request . . . . . . . . . . . . . . . . . . . . . . . 17 81 5.7.2. Generating a Proxy Map-Reply . . . . . . . . . . . . 18 82 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 18 83 5.9. ITR Processing: Receiving a Map-Reply . . . . . . . . . . 18 84 5.9.1. Map-Reply Record Validation . . . . . . . . . . . . . 20 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 21 87 6.2. Random Number Generation . . . . . . . . . . . . . . . . 21 88 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 21 89 6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 21 90 6.5. Shared Keys Provisioning . . . . . . . . . . . . . . . . 22 91 6.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 92 6.7. Message Privacy . . . . . . . . . . . . . . . . . . . . . 22 93 6.8. Denial of Service and Distributed Denial of Service 94 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 23 97 7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 23 98 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 24 99 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 24 100 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 25 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 104 9.2. Informative References . . . . . . . . . . . . . . . . . 27 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 107 1. Introduction 109 The Locator/ID Separation Protocol 110 [I-D.ietf-lisp-rfc6830bis],[I-D.ietf-lisp-rfc6833bis] is a network- 111 layer-based protocol that enables separation of IP addresses into two 112 new numbering spaces: Endpoint Identifiers (EIDs) and Routing 113 Locators (RLOCs). EID-to-RLOC mappings are stored in a database, the 114 LISP Mapping System, and made available via the Map-Request/Map-Reply 115 lookup process. If these EID-to-RLOC mappings, carried through Map- 116 Reply messages, are transmitted without integrity protection, an 117 adversary can manipulate them and hijack the communication, 118 impersonate the requested EID, or mount Denial of Service or 119 Distributed Denial of Service attacks. Also, if the Map-Reply 120 message is transported unauthenticated, an adversarial LISP entity 121 can overclaim an EID-prefix and maliciously redirect traffic directed 122 to a large number of hosts. The LISP-SEC threat model, described in 123 Section 3, is built on top of the LISP threat model defined in 124 [RFC7835], that includes a detailed description of "overclaiming" 125 attack. 127 This memo specifies LISP-SEC, a set of security mechanisms that 128 provides origin authentication, integrity and anti-replay protection 129 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 130 process. LISP-SEC also enables verification of authorization on EID- 131 prefix claims in Map-Reply messages, ensuring that the sender of a 132 Map-Reply that provides the location for a given EID-prefix is 133 entitled to do so according to the EID prefix registered in the 134 associated Map-Server. Map-Register/Map-Notify security, including 135 the right for a LISP entity to register an EID-prefix or to claim 136 presence at an RLOC, is out of the scope of LISP-SEC as those 137 protocols are protected by the security mechanisms specified in 138 [I-D.ietf-lisp-rfc6833bis]. However, LISP-SEC extends the Map- 139 Register message to allow an ITR to securely downgrade to non LISP- 140 SEC Map-Requests. Additional security considerations are described 141 in Section 6. 143 2. Definition of Terms 145 One-Time Key (OTK): An ephemeral randomly generated key that must 146 be used for a single Map-Request/Map-Reply exchange. 148 ITR One-Time Key (ITR-OTK): The One-Time Key generated at the 149 Ingress Tunnel Router (ITR). 151 MS One-Time Key (MS-OTK): The One-Time Key generated at the Map- 152 Server. 154 Authentication Data (AD): Metadata that is included either in a 155 LISP Encapsulated Control Message (ECM) header, as defined in 156 [I-D.ietf-lisp-rfc6833bis], or in a Map-Reply message to support 157 confidentiality, integrity protection, and verification of EID- 158 prefix authorization. 160 OTK Authentication Data (OTK-AD): The portion of ECM 161 Authentication Data that contains a One-Time Key. 163 EID Authentication Data (EID-AD): The portion of ECM and Map-Reply 164 Authentication Data used for verification of EID-prefix 165 authorization. 167 Packet Authentication Data (PKT-AD): The portion of Map-Reply 168 Authentication Data used to protect the integrity of the Map-Reply 169 message. 171 For definitions of other terms, notably Map-Request, Map-Reply, 172 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server 173 (MS), and Map-Resolver (MR) please consult the LISP specification 174 [I-D.ietf-lisp-rfc6833bis]. 176 3. LISP-SEC Threat Model 178 LISP-SEC addresses the control plane threats, described in section 179 3.7 and 3.8 of [RFC7835], that target EID-to-RLOC mappings, including 180 manipulations of Map-Request and Map-Reply messages, and malicious 181 ETR EID prefix overclaiming. LISP-SEC makes two main assumptions: 182 (1) the LISP mapping system is expected to deliver a Map-Request 183 message to their intended destination ETR as identified by the EID, 184 and (2) no man-in-the-middle (MITM) attack can be mounted within the 185 LISP Mapping System. How the Mapping System is protected from MITM 186 attacks depends from the particular Mapping Systems used, and is out 187 of the scope of this memo. Furthermore, while LISP-SEC enables 188 detection of EID prefix overclaiming attacks, it assumes that Map- 189 Servers can verify the EID prefix authorization at time of 190 registration. 192 According to the threat model described in [RFC7835] LISP-SEC assumes 193 that any kind of attack, including MITM attacks, can be mounted 194 outside of the boundaries of the LISP mapping system. An on-path 195 attacker, outside of the LISP mapping system can, for example, hijack 196 Map-Request and Map-Reply messages, spoofing the identity of a LISP 197 node. Another example of on-path attack, called overclaiming attack, 198 can be mounted by a malicious Egress Tunnel Router (ETR), by 199 overclaiming the EID-prefixes for which it is authoritative. In this 200 way the ETR can maliciously redirect traffic directed to a large 201 number of hosts. 203 4. Protocol Operations 205 The goal of the security mechanisms defined in 206 [I-D.ietf-lisp-rfc6833bis] is to prevent unauthorized insertion of 207 mapping data by providing origin authentication and integrity 208 protection for the Map-Register, and by using the nonce to detect 209 unsolicited Map-Reply sent by off-path attackers. 211 LISP-SEC builds on top of the security mechanisms defined in 212 [I-D.ietf-lisp-rfc6833bis] to address the threats described in 213 Section 3 by leveraging the trust relationships existing among the 214 LISP entities participating to the exchange of the Map-Request/Map- 215 Reply messages. Those trust relationships are used to securely 216 distribute, as described in Section 7.4, a per-message One-Time Key 217 (OTK) that provides origin authentication, integrity and anti-replay 218 protection to mapping data conveyed via the mapping lookup process, 219 and that effectively prevent overclaiming attacks. The processing of 220 security parameters during the Map-Request/Map-Reply exchange is as 221 follows: 223 o Per each Map-Request message a new ITR-OTK is generated and stored 224 at the ITR, and securely transported to the Map-Server. 226 o The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for 227 Message Authentication (HMAC) [RFC2104] that protects the 228 integrity of the mapping data known to the Map-Server to prevent 229 overclaiming attacks. The Map-Server also derives a new OTK, the 230 MS-OTK, that is passed to the ETR, by applying a Key Derivation 231 Function (KDF) (e.g. [RFC5869]) to the ITR-OTK. 233 o The ETR uses the MS-OTK to compute an HMAC that protects the 234 integrity of the Map-Reply sent to the ITR. 236 o Finally, the ITR uses the stored ITR-OTK to verify the integrity 237 of the mapping data provided by both the Map-Server and the ETR, 238 and to verify that no overclaiming attacks were mounted along the 239 path between the Map-Server and the ITR. 241 Section 5 provides the detailed description of the LISP-SEC control 242 messages and their processing, while the rest of this section 243 describes the flow of LISP protocol operations at each entity 244 involved in the Map-Request/Map-Reply exchange: 246 1. The ITR, upon needing to transmit a Map-Request message, 247 generates and stores an OTK (ITR-OTK). This ITR-OTK is included 248 into the Encapsulated Control Message (ECM) that contains the 249 Map-Request sent to the Map-Resolver. ITR-OTK confidentiality 250 and integrity protection MUST be provided in the path between the 251 ITR and the Map-Resolver. This can be achieved either by 252 encrypting the ITR-OTK with the pre-shared secret known to the 253 ITR and the Map-Resolver (as specified in Section 5.5), or by 254 enabling DTLS between the ITR and the Map-Resolver. 256 2. The Map-Resolver decapsulates the ECM message, decrypts the ITR- 257 OTK, if needed, and forwards through the Mapping System the 258 received Map-Request and the ITR-OTK, as part of a new ECM 259 message. The LISP Mapping System delivers the ECM to the 260 appropriate Map-Server, as identified by the EID destination 261 address of the Map-Request. As mentioned in Section 3, how the 262 Mapping System is protected from MITM attacks depends from the 263 particular Mapping Systems used, and is out of the scope of this 264 memo. 266 3. The Map-Server is configured with the location mappings and 267 policy information for the ETR responsible for the EID 268 destination address. Using this preconfigured information, the 269 Map-Server, after the decapsulation of the ECM message, finds the 270 longest match EID-prefix that covers the requested EID in the 271 received Map-Request. The Map-Server adds this EID-prefix, 272 together with an HMAC computed using the ITR-OTK, to a new 273 Encapsulated Control Message that contains the received Map- 274 Request. 276 4. The Map-Server derives a new OTK, the MS-OTK, by applying a Key 277 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is 278 included in the Encapsulated Control Message that the Map-Server 279 uses to forward the Map-Request to the ETR. MS-OTK 280 confidentiality and integrity protection MUST be provided in the 281 path between the Map-Server and the ETR. This can be achieved 282 either by encrypting the MS-OTK with the pre-shared secret known 283 to the Map-Server and the ETR (as specified in Section 5.5), or 284 by enabling DTLS between the Map-Server and the ETR. 286 5. If the Map-Server is acting in proxy mode, as specified in 287 [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the 288 generation of the Map-Reply and steps 6 and 7 are skipped. In 289 this case the Map-Server generates the Map-Reply on behalf of the 290 ETR as described in Section 5.7.2. 292 6. The ETR, upon receiving the ECM encapsulated Map-Request from the 293 Map-Server, decrypts the MS-OTK, if needed, and originates a Map- 294 Reply that contains the EID-to-RLOC mapping information as 295 specified in [I-D.ietf-lisp-rfc6833bis]. 297 7. The ETR computes an HMAC over the Map-Reply, keyed with MS-OTK to 298 protect the integrity of the whole Map-Reply. The ETR also 299 copies the EID-prefix authorization data that the Map-Server 300 included in the ECM encapsulated Map-Request into the Map-Reply 301 message. The ETR then sends the complete Map-Reply message to 302 the requesting ITR. 304 8. The ITR, upon receiving the Map-Reply, uses the locally stored 305 ITR-OTK to verify the integrity of the EID-prefix authorization 306 data included in the Map-Reply by the Map-Server. The ITR 307 computes the MS-OTK by applying the same KDF (as specified in the 308 ECM encapsulated Map-Reply) used by the Map-Server, and verifies 309 the integrity of the Map-Reply. If the integrity checks fail, 310 the Map-Reply MUST be discarded. Also, if the EID-prefixes 311 claimed by the ETR in the Map-Reply are not equal or more 312 specific than the EID-prefix authorization data inserted by the 313 Map-Server, the ITR MUST discard the Map-Reply. 315 5. LISP-SEC Control Messages Details 317 LISP-SEC metadata associated with a Map-Request is transported within 318 the Encapsulated Control Message that contains the Map-Request. 320 LISP-SEC metadata associated with the Map-Reply is transported within 321 the Map-Reply itself. 323 5.1. Encapsulated Control Message LISP-SEC Extensions 325 LISP-SEC uses the ECM defined in [I-D.ietf-lisp-rfc6833bis] with S 326 bit set to 1 to indicate that the LISP header includes Authentication 327 Data (AD). The format of the LISP-SEC ECM Authentication Data is 328 defined in Figure 1 . OTK-AD stands for One-Time Key Authentication 329 Data and EID-AD stands for EID Authentication Data. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | ECM AD Type |V| Unassigned | Requested HMAC ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 336 | OTK Length | Key ID | OTK Wrap. ID | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 338 | One-Time-Key Preamble ... | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD 340 | ... One-Time-Key Preamble | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 342 ~ One-Time Key (128 bits) ~/ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 344 | EID-AD Length | KDF ID | | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 346 | Record Count |E| Unassigned | EID HMAC ID |EID-AD 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 348 | Unassigned | EID mask-len | EID-AFI | | | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 350 ~ EID-prefix ... ~ | | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 352 ~ EID HMAC ~ | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 355 Figure 1: LISP-SEC ECM Authentication Data 357 ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 359 V: Key Version bit. This bit is toggled when the sender switches 360 to a new OTK wrapping key 362 Unassigned: Set to 0 on transmission and ignored on receipt. 364 Requested HMAC ID: The HMAC algorithm, that will be used to 365 protect the mappings, requested by the ITR. See Section 5.4 for 366 details, and Section 7.3 for HMAC IDs that MUST be supported. 368 OTK Length: The length (in bytes) of the OTK Authentication Data 369 (OTK-AD), that contains the OTK Preamble and the OTK. 371 Key ID: The identifier of the pre-shared secret shared by an ITR 372 and the Map-Resolver, and by the Map-Server and an ETR. Per- 373 message keys are derived from the pre-shared secret to encrypt, 374 authenticate the origin and protect the integrity of the OTK. The 375 Key ID allows to rotate between multiple pre-shared secrets in a 376 non disruptive way. 378 OTK Wrapping ID: The identifier of the key derivation function and 379 of the key wrapping algorithm used to encrypt the One-Time-Key. 380 See Section 5.5 for more details, and Section 7.4 for Wrapping IDs 381 that MUST be supported. 383 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 384 the OTK is encrypted, this field MAY carry additional metadata 385 resulting from the key wrapping operation. When a 128-bit OTK is 386 sent unencrypted by Map-Resolver, the OTK Preamble is set to 387 0x0000000000000000 (64 bits). See Section 5.5.1 for details. 389 One-Time-Key: the OTK wrapped as specified by OTK Wrapping ID. 390 See Section 5.5 for details. 392 EID-AD Length: length (in bytes) of the EID Authentication Data 393 (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only 394 fills the KDF ID field, and all the remaining fields part of the 395 EID-AD are not present. An EID-AD MAY contain multiple EID- 396 records. Each EID-record is 4-byte long plus the length of the 397 AFI-encoded EID-prefix. 399 KDF ID: Identifier of the Key Derivation Function used to derive 400 the MS-OTK. The ITR MAY use this field to indicate the 401 recommended KDF algorithm, according to local policy. The Map- 402 Server can overwrite the KDF ID if it does not support the KDF ID 403 recommended by the ITR. See Section 5.4 for more details, and 404 Section 7.5 for KDF IDs that MUST be supported. 406 Record Count: The number of records in this Map-Request message. 407 A record is comprised of the portion of the packet that is labeled 408 'Rec' above and occurs the number of times equal to Record Count. 410 E: ETR-Cant-Sign bit. This bit is set to 1 to signal to the ITR 411 that at least one of the ETRs authoritative for the EID prefixes 412 of this Map-Reply has not enabled LISP-SEC. This allows the ITR 413 to securely downgrade to non LISP-SEC requests, as specified in 414 Section 5.7, if so desired. 416 Unassigned: Set to 0 on transmission and ignored on receipt. 418 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 419 integrity of the EID-AD. This field is filled by Map-Server that 420 computed the EID-prefix HMAC. See Section 5.4 for more details, 421 and Section 7.3 for HMAC IDs that MUST be supported. 423 EID mask-len: Mask length for EID-prefix. 425 EID-AFI: Address family of EID-prefix according to [RFC5226] 426 EID-prefix: The Map-Server uses this field to specify the EID- 427 prefix that the destination ETR is authoritative for, and is the 428 longest match for the requested EID. 430 EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. 431 Before computing the HMAC operation the EID HMAC field MUST be set 432 to 0. The HMAC MUST cover the entire EID-AD. 434 5.2. Map-Reply LISP-SEC Extensions 436 LISP-SEC uses the Map-Reply defined in [I-D.ietf-lisp-rfc6833bis], 437 with Type set to 2, and S-bit set to 1 to indicate that the Map-Reply 438 message includes Authentication Data (AD). The format of the LISP- 439 SEC Map-Reply Authentication Data is defined in Figure 2. PKT-AD is 440 the Packet Authentication Data that covers the Map-Reply payload. 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | MR AD Type | Unassigned | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 447 | EID-AD Length | KDF ID | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 449 | Record Count | Unassigned | EID HMAC ID |EID-AD 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 451 | Unassigned | EID mask-len | EID-AFI | | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 453 ~ EID-prefix ... ~ | | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 455 ~ EID HMAC ~ | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 457 | PKT-AD Length | PKT HMAC ID |\ 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 459 ~ PKT HMAC ~PKT-AD 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 462 Figure 2: LISP-SEC Map-Reply Authentication Data 464 MR AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 466 EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY 467 contain multiple EID-records. Each EID-record is 4-byte long plus 468 the length of the AFI-encoded EID-prefix. 470 KDF ID: Identifier of the Key Derivation Function used to derive 471 MS-OTK. See Section 5.7 for more details, and Section 7.5 for KDF 472 IDs that MUST be supported. 474 Record Count: The number of records in this Map-Reply message. A 475 record is comprised of the portion of the packet that is labeled 476 'Rec' above and occurs the number of times equal to Record Count. 478 Unassigned: Set to 0 on transmission and ignored on receipt. 480 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 481 integrity of the EID-AD. See Section 5.7 for more details, and 482 Section 7.3 for HMAC IDs that MUST be supported. 484 EID mask-len: Mask length for EID-prefix. 486 EID-AFI: Address family of EID-prefix according to [RFC8060]. 488 EID-prefix: This field contains an EID-prefix that the destination 489 ETR is authoritative for, and is the longest match for the 490 requested EID. 492 EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. 493 Before computing the HMAC operation the EID HMAC field MUST be set 494 to 0. The HMAC covers the entire EID-AD. 496 PKT-AD Length: length (in bytes) of the Packet Authentication Data 497 (PKT-AD). 499 PKT HMAC ID: Identifier of the HMAC algorithm used to protect the 500 integrity of the Map-Reply. See Section 7.3 for HMAC IDs that 501 MUST be supported. 503 PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- 504 SEC Authentication Data. The scope of the authentication goes 505 from the Map-Reply Type field to the PKT HMAC field included. 506 Before computing the HMAC operation the PKT HMAC field MUST be set 507 to 0. See Section 5.8 for more details. 509 5.3. Map-Register LISP-SEC Extentions 511 This memo is allocating one of the bits marked as Unassigned in the 512 Map-Register message defined in [I-D.ietf-lisp-rfc6833bis]. More 513 precisely, the second bit after the Type field in a Map-Register 514 message is allocated as the S bit. The S bit indicates to the Map- 515 Server that the registering ETR is LISP-SEC enabled. An ETR that 516 supports LISP-SEC MUST set the S bit in its Map-Register messages. 518 5.4. ITR Processing: Generating a Map-Request 520 Upon creating a Map-Request, the ITR generates a random ITR-OTK that 521 is stored locally (until the corresponding Map-Reply is received), 522 together with the nonce generated as specified in 523 [I-D.ietf-lisp-rfc6833bis]. 525 ITR-OTK confidentiality and integrity protection MUST be provided in 526 the path between the ITR and the Map-Resolver. This can be achieved 527 either by encrypting the ITR-OTK with the pre-shared secret known to 528 the ITR and the Map-Resolver (see Section 5.5), or by enabling DTLS 529 between the ITR and the Map-Resolver. 531 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 532 1, to indicate the presence of Authentication Data. 534 ITR-OTK is wrapped with the algorithm specified by the OTK Wrapping 535 ID field. See Section 5.5 for further details on OTK encryption. If 536 the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled 537 in the path between the ITR and the Map-Resolver, the Map-Request 538 MUST be dropped and an appropiate log action SHOULD be taken. 540 The Requested HMAC ID field contains the suggested HMAC algorithm to 541 be used by the Map-Server and the ETR to protect the integrity of the 542 ECM Authentication data and of the Map-Reply. 544 The KDF ID field specifies the suggested key derivation function to 545 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE 546 (0), MAY be used to specify that the ITR has no preferred KDF ID. 548 The EID-AD length is set to 4 bytes, since the Authentication Data 549 does not contain EID-prefix Authentication Data, and the EID-AD 550 contains only the KDF ID field. 552 5.4.1. PITR Processing 554 The processing performed by a PITR is equivalent to the processing of 555 an ITR. However, if the PITR is directly connected to a Mapping 556 System such as LISP+ALT [RFC6836], the PITR performs the functions of 557 both the ITR and the Map-Resolver forwarding the Map-Request 558 encapsulated in an ECM header that includes the Authentication Data 559 fields as described in Section 5.6. 561 5.5. Encrypting and Decrypting an OTK 563 MS-OTK confidentiality and integrity protection MUST be provided in 564 the path between the Map-Server and the ETR. This can be achieved 565 either by enabling DTLS between the Map-Server and the ITR or by 566 encrypting the MS-OTK with the pre-shared secret known to the Map- 567 Server and the ETR [I-D.ietf-lisp-rfc6833bis]. 569 Similarly, ITR-OTK confidentiality and integrity protection MUST be 570 provided in the path between the ITR and the Map-Resolver. This can 571 be achieved either by enabling DTLS between the Map-Server and the 572 ITR, or by encrypting the ITR-OTK with the pre-shared secret known to 573 the ITR and the Map-Resolver. The ITR/Map-Resolver pre-shared key is 574 similar to the Map-Server/ETR pre-shared key. However, to prevent 575 ETR's overclaiming attacks, the ITR/Map-Resolver pre-shared secret 576 MUST have a different value than the Map-Server/ETR pre-shared 577 secret. 579 This section describes OTK processing in the ITR/Map-Resolver path, 580 as well as in the Map-Server/ETR path. 582 It's important to note that, to prevent ETR's overclaiming attacks, 583 the ITR/Map-Resolver pre-shared secret MUST be different from the 584 Map-Server/ETR pre-shared secret. 586 The OTK is wrapped using the algorithm specified in the OTK Wrapping 587 ID field. This field identifies both the: 589 o Key Encryption Algorithm used to encrypt the wrapped OTK, as well 590 as the 592 o Key Derivation Function used to derive a per-message encryption 593 key. 595 Implementations of this specification MUST support OTK Wrapping ID 596 AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF- 597 SHA256 Key Derivation Function specified in[RFC4868] to derive a per- 598 message encryption key (per-msg-key), as well as the AES-KEY-WRAP-128 599 Key Wrap algorithm used to encrypt a 128-bit OTK, according to 600 [RFC3394]. 602 The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF- 603 SHA256 is described below: 605 1. The KDF algorithm is identified by the field 'OTK Wrapping ID' 606 according to the table in Section Section 7.4. 608 2. The Key Wrap algorithm is identified by the field 'OTK Wrapping 609 ID' according to the table in Section Section 7.4. 611 3. If the NULL-KEY-WRAP-128 algorithm (defined in (Section 7.4)) is 612 selected and DTLS is not enabled, the Map-Request MUST be dropped 613 and an appropiate log action SHOULD be taken. 615 4. The pre-shared secret used to derive the per-msg-key is 616 represented by PSK[Key ID], that is the pre-shared secret 617 identified by the 'Key ID'. 619 5. The per-message encryption key key is computed as: 621 * per-msg-key = KDF( nonce + s + PSK[Key ID] ) 623 * where the nonce is the value in the Nonce field of the Map- 624 Request, and 626 * 's' is the string "OTK-Key-Wrap" 628 6. According to [RFC3394] the per-msg-key is used to wrap the OTK 629 with AES-KEY-WRAP-128. The AES Key Wrap Initialization Value 630 MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the 631 AES Key Wrap operation is 192-bit long. The most significant 632 64-bit are copied in the One-Time Key Preamble field, while the 633 128 less significant bits are copied in the One-Time Key field of 634 the LISP-SEC Authentication Data. 636 When decrypting an encrypted OTK the receiver MUST verify that the 637 Initialization Value resulting from the AES Key Wrap decryption 638 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 639 the receiver MUST discard the entire message. 641 5.5.1. Unencrypted OTK 643 MS-OTK confidentiality and integrity protection MUST be provided in 644 the path between the Map-Server and the ETR. Similarly, ITR-OTK 645 confidentiality and integrity protection MUST be provided in the path 646 between the ITR and the Map-Resolver. 648 However, when DTLS is enabled the OTK MAY be sent unencrypted as 649 transport layer security is providing confidentiality and integrity 650 protection. 652 When a 128-bit OTK is sent unencrypted the OTK Wrapping ID is set to 653 NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 654 (64 bits). 656 5.6. Map-Resolver Processing 658 Upon receiving an encapsulated Map-Request with the S-bit set, the 659 Map-Resolver decapsulates the ECM message. The ITR-OTK, if 660 encrypted, is decrypted as specified in Section 5.5. 662 Protecting the confidentiality of the ITR-OTK and, in general, the 663 security of how the Map-Request is handed by the Map-Resolver to the 664 Map-Server, is specific to the particular Mapping System used, and 665 outside of the scope of this memo. 667 In Mapping Systems where the Map-Server is compliant with 668 [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM 669 header with the S-bit set, that contains the unencrypted ITR-OTK, as 670 specified in Section 5.5, and the other data derived from the ECM 671 Authentication Data of the received encapsulated Map-Request. 673 The Map-Resolver then forwards to the Map-Server the received Map- 674 Request, encapsulated in the new ECM header that includes the newly 675 computed Authentication Data fields. 677 5.7. Map-Server Processing 679 Upon receiving an ECM encapsulated Map-Request with the S-bit set to 680 1, the Map-Server process the Map-Request according to the value of 681 the security-capable S-bit and of the proxy map-reply P-bit contained 682 in the Map-Register sent by the ETRs authoritative for that prefix 683 during registration. 685 Processing of the Map-Request MUST proceed in the order described in 686 the table below, applying the processing corresponding to the first 687 rule that matches the conditions indicated in the first column: 689 +----------------+--------------------------------------------------+ 690 | Matching | Processing | 691 | Condition | | 692 +----------------+--------------------------------------------------+ 693 | 1. At least | The Map-Server MUST generate a LISP-SEC | 694 | one of the | protected Map-Reply as specified in Section | 695 | ETRs | 5.7.2. The ETR-Cant-Sign E-bit in the EID | 696 | authoritative | Authentication Data (EID-AD) MUST be set to 0. | 697 | for the EID | | 698 | prefix | | 699 | included in | | 700 | the Map- | | 701 | Request | | 702 | registered | | 703 | with the P-bit | | 704 | set to 1 | | 705 | | | 706 | 2. At least | The Map-Server MUST generate a LISP-SEC | 707 | one of the | protected Encapsulated Map-Request (as specified | 708 | ETRs | in Section 5.7.1), to be sent to one of the | 709 | authoritative | authoritative ETRs that registered with the | 710 | for the EID | S-bit set to 1 (and the P-bit set to 0). If | 711 | prefix | there is at least one ETR that registered with | 712 | included in | the S-bit set to 0, the ETR-Cant-Sign E-bit of | 713 | the Map- | the EID-AD MUST be set to 1 to signal the ITR | 714 | Request | that a non LISP-SEC Map-Request might reach | 715 | registered | additional ETRs that have LISP-SEC disabled. | 716 | with the S-bit | | 717 | set to 1 | | 718 | | | 719 | 3. All the | The Map-Server MUST send a Negative Map-Reply | 720 | ETRs | protected with LISP-SEC, as described in Section | 721 | authoritative | 5.7.2. The ETR-Cant-Sign E-bit MUST be set to 1 | 722 | for the EID | to signal the ITR that a non LISP-SEC Map- | 723 | prefix | Request might reach additional ETRs that have | 724 | included in | LISP-SEC disabled. | 725 | the Map- | | 726 | Request | | 727 | registered | | 728 | with the S-bit | | 729 | set to 0 | | 730 +----------------+--------------------------------------------------+ 732 In this way the ITR that sent a LISP-SEC protected Map-Request always 733 receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign 734 E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach 735 additional ETRs that have LISP-SEC disabled. This mechanism allows 736 the ITR to securely downgrade to non LISP-SEC requests, if so 737 desired. 739 5.7.1. Generating a LISP-SEC Protected Encapsulated Map-Request 741 The Map-Server decapsulates the ECM and generates a new ECM 742 Authentication Data. The Authentication Data includes the OTK-AD and 743 the EID-AD, that contains EID-prefix authorization information, that 744 are eventually received by the requesting ITR. 746 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from 747 the ITR-OTK received with the Map-Request. MS-OTK is derived 748 applying the key derivation function specified in the KDF ID field. 749 If the algorithm specified in the KDF ID field is not supported, the 750 Map-Server uses a different algorithm to derive the key and updates 751 the KDF ID field accordingly. 753 MS-OTK confidentiality and integrity protection MUST be provided in 754 the path between the Map-Server and the ETR. This can be achieved 755 either by enabling DTLS between the Map-Server and the ETR, or by 756 encrypting the MS-OTK with the pre-shared secret known to the Map- 757 Server and the ETR. 759 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 760 1, to indicate the presence of Authentication Data. 762 MS-OTK is wrapped with the algorithm specified by the OTK Wrapping ID 763 field. See Section 5.5 for further details on OTK encryption. If 764 the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled 765 in the path between the Map-Server and the ETR, the Map-Request MUST 766 be dropped and an appropiate log action SHOULD be taken. 768 The Map-Server includes in the EID-AD the longest match registered 769 EID-prefix for the destination EID, and an HMAC of this EID-prefix. 770 The HMAC is keyed with the ITR-OTK contained in the received ECM 771 Authentication Data, and the HMAC algorithm is chosen according to 772 the Requested HMAC ID field. If The Map-Server does not support this 773 algorithm, the Map-Server uses a different algorithm and specifies it 774 in the EID HMAC ID field. The scope of the HMAC operation covers the 775 entire EID-AD, from the EID-AD Length field to the EID HMAC field, 776 which must be set to 0 before the computation. 778 The Map-Server then forwards the updated ECM encapsulated Map- 779 Request, that contains the OTK-AD, the EID-AD, and the received Map- 780 Request to an authoritative ETR as specified in 781 [I-D.ietf-lisp-rfc6833bis]. 783 5.7.2. Generating a Proxy Map-Reply 785 LISP-SEC proxy Map-Reply are generated according to 786 [I-D.ietf-lisp-rfc6833bis], with the Map-Replay S-bit set to 1. The 787 Map-Reply includes the Authentication Data that contains the EID-AD, 788 computed as specified in Section 5.7.1, as well as the PKT-AD 789 computed as specified in Section 5.8. 791 5.8. ETR Processing 793 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 794 the ETR decapsulates the ECM message. The OTK field, if encrypted, 795 is decrypted as specified in Section 5.5 to obtain the unencrypted 796 MS-OTK. 798 The ETR then generates a Map-Reply as specified in 799 [I-D.ietf-lisp-rfc6833bis] and includes the Authentication Data that 800 contains the EID-AD, as received in the encapsulated Map-Request, as 801 well as the PKT-AD. 803 The EID-AD is copied from the Authentication Data of the received 804 encapsulated Map-Request. 806 The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed 807 with the MS-OTK and computed using the HMAC algorithm specified in 808 the Requested HMAC ID field of the received encapsulated Map-Request. 809 If the ETR does not support the Requested HMAC ID, it uses a 810 different algorithm and updates the PKT HMAC ID field accordingly. 811 The scope of the HMAC operation covers the entire PKT-AD, from the 812 Map-Reply Type field to the PKT HMAC field, which must be set to 0 813 bendlfore the computation. 815 Finally the ETR sends the Map-Reply to the requesting ITR as 816 specified in [I-D.ietf-lisp-rfc6833bis]. 818 5.9. ITR Processing: Receiving a Map-Reply 820 In response to an encapsulated Map-Request that has the S-bit set, an 821 ITR MUST receive a Map-Reply with the S-bit set, that includes an 822 EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the 823 ITR MUST discard it. In response to an encapsulated Map-Request with 824 S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and 825 the ITR SHOULD discard the Map-Reply if the S-bit is set. 827 Upon receiving a Map-Reply, the ITR must verify the integrity of both 828 the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of 829 the integrity checks fails. After processing the Map-Reply, the ITR 830 must discard the pair associated to the Map-Reply 831 The integrity of the EID-AD is verified using the ITR-OTK (stored 832 locally for the duration of this exchange) to re-compute the HMAC of 833 the EID-AD using the algorithm specified in the EID HMAC ID field. 834 If the EID HMAC ID field does not match the Requested HMAC ID the ITR 835 SHOULD discard the Map-Reply and send, at the first opportunity it 836 needs to, a new Map-Request with a different Requested HMAC ID field, 837 according to ITR's local policy. The scope of the HMAC operation 838 covers the entire EID-AD, from the EID-AD Length field to the EID 839 HMAC field, which must be set to 0 before the computation of the 840 HMAC. 842 ITR MUST set the EID HMAC ID field to 0 before computing the HMAC. 844 To verify the integrity of the PKT-AD, first the MS-OTK is derived 845 from the locally stored ITR-OTK using the algorithm specified in the 846 KDF ID field. This is because the PKT-AD is generated by the ETR 847 using the MS-OTK. If the KDF ID in the Map-Reply does not match the 848 KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- 849 Reply and send, at the first opportunity it needs to, a new Map- 850 Request with a different KDF ID, according to ITR's local policy. 851 Without consistent configuration of involved entities, extra delays 852 may be experienced. However, since HKDF-SHA1-128 is specified as 853 mandatory to implement in Section 7.5, the process will eventually 854 converge. 856 The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD 857 using the Algorithm specified in the PKT HMAC ID field. If the PKT 858 HMAC ID field does not match the Requested HMAC ID the ITR SHOULD 859 discard the Map-Reply and send, at the first opportunity it needs to, 860 a new Map-Request with a different Requested HMAC ID according to 861 ITR's local policy or until all HMAC IDs supported by the ITR have 862 been attempted. 864 Each individual Map-Reply EID-record is considered valid only if: (1) 865 both EID-AD and PKT-AD are valid, and (2) the intersection of the 866 EID-prefix in the Map-Reply EID-record with one of the EID-prefixes 867 contained in the EID-AD is not empty. After identifying the Map- 868 Reply record as valid, the ITR sets the EID-prefix in the Map-Reply 869 record to the value of the intersection set computed before, and adds 870 the Map-Reply EID-record to its EID-to-RLOC cache, as described in 871 [I-D.ietf-lisp-rfc6833bis]. An example of Map-Reply record 872 validation is provided in Section 5.9.1. 874 The ITR SHOULD send SMR triggered Map-Requests over the mapping 875 system in order to receive a secure Map-Reply. If an ITR accepts 876 piggybacked Map-Replies, it SHOULD also send a Map-Request over the 877 mapping system in order to verify the piggybacked Map-Reply with a 878 secure Map-Reply. 880 5.9.1. Map-Reply Record Validation 882 The payload of a Map-Reply may contain multiple EID-records. The 883 whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide 884 integrity protection and origin authentication to the EID-prefix 885 records claimed by the ETR. The Authentication Data field of a Map- 886 Reply may contain multiple EID-records in the EID-AD. The EID-AD is 887 signed by the Map-Server, with the EID HMAC, to provide integrity 888 protection and origin authentication to the EID-prefix records 889 inserted by the Map-Server. 891 Upon receiving a Map-Reply with the S-bit set, the ITR first checks 892 the validity of both the EID HMAC and of the PKT-AD HMAC. If either 893 one of the HMACs is not valid, a log action MUST be taken and the 894 Map-Reply MUST NOT be processed any further. If both HMACs are 895 valid, the ITR proceeds with validating each individual EID-record 896 claimed by the ETR by computing the intersection of each one of the 897 EID-prefix contained in the payload of the Map-Reply with each one of 898 the EID-prefixes contained in the EID-AD. An EID-record is valid 899 only if at least one of the intersections is not the empty set. 901 For instance, the Map-Reply payload contains 3 mapping record EID- 902 prefixes: 904 2001:db8:102::/48 906 2001:db8:103::/48 908 2001:db8:200::/40 910 The EID-AD contains two EID-prefixes: 912 2001:db8:103::/48 914 2001:db8:203::/48 916 The EID-record with EID-prefix 2001:db8:102::/48 is not eligible to 917 be used by the ITR since it is not included in any of the EID-ADs 918 signed by the Map-Server. A log action MUST be taken. 920 The EID-record with EID-prefix 2001:db8:103::/48 is eligible to be 921 used by the ITR because it matches the second EID-prefix contained in 922 the EID-AD. 924 The EID-record with EID-prefix 2001:db8:200::/40 is not eligible to 925 be used by the ITR since it is not included in any of the EID-ADs 926 signed by the Map-Server. A log action MUST be taken. In this last 927 example the ETR is trying to over claim the EID-prefix 928 2001:db8:200::/40, but the Map-Server authorized only 929 2001:db8:203::/48, hence the EID-record is discarded. 931 6. Security Considerations 933 6.1. Mapping System Security 935 The LISP-SEC threat model described in Section 3, assumes that the 936 LISP Mapping System is working properly and eventually delivers Map- 937 Request messages to a Map-Server that is authoritative for the 938 requested EID. 940 It is assumed that the Mapping System ensures the confidentiality of 941 the OTK, and the integrity of the Map-Reply data. However, how the 942 LISP Mapping System is secured is out of the scope of this document. 944 Similarly, Map-Register security, including the right for a LISP 945 entity to register an EID-prefix or to claim presence at an RLOC, is 946 out of the scope of LISP-SEC. 948 6.2. Random Number Generation 950 The ITR-OTK MUST be generated by a properly seeded pseudo-random (or 951 strong random) source. See [RFC4086] for advice on generating 952 security-sensitive random data 954 6.3. Map-Server and ETR Colocation 956 If the Map-Server and the ETR are colocated, LISP-SEC does not 957 provide protection from overclaiming attacks mounted by the ETR. 958 However, in this particular case, since the ETR is within the trust 959 boundaries of the Map-Server, ETR's overclaiming attacks are not 960 included in the threat model. 962 6.4. Deploying LISP-SEC 964 This memo is written according to [RFC2119]. Specifically, the use 965 of the key word SHOULD "or the adjective 'RECOMMENDED', mean that 966 there may exist valid reasons in particular circumstances to ignore a 967 particular item, but the full implications must be understood and 968 carefully weighed before choosing a different course". 970 Those deploying LISP-SEC according to this memo, should carefully 971 weight how the LISP-SEC threat model applies to their particular use 972 case or deployment. If they decide to ignore a particular 973 recommendation, they should make sure the risk associated with the 974 corresponding threats is well understood. 976 As an example, in certain closed and controlled deployments, it is 977 possible that the threat associated with a MiTM between the xTR and 978 the Mapping System is very low, and after carfeul consideration it 979 may be decided to allow a NULL key wrapping algorithm while carrying 980 the OTKs between the xTR and the Mapping System. 982 As an example at the other end of the spectrum, in certain other 983 deployments, attackers may be very sophisticated, and force the 984 deployers to enforce very strict policies in term of HMAC algorithms 985 accepted by an ITR. 987 Similar considerations apply to the entire LISP-SEC threat model, and 988 should guide the deployers and implementors whenever they encounter 989 the key word SHOULD across this memo. 991 6.5. Shared Keys Provisioning 993 Provisioning of the keys shared between the ITR and the Map-Resolver 994 as well as between the ETR and the Map-Server should be performed via 995 an orchestration infrastructure and it is out of the scope of this 996 draft. It is recommended that both shared keys are refreshed at 997 periodical intervals to address key aging or attackers gaining 998 unauthorized access to the shared keys. Shared keys should be 999 unpredictable random values. 1001 6.6. Replay Attacks 1003 An attacker can capture a valid Map-Request and/or Map-Reply and 1004 replay it, however once the ITR receives the original Map-Reply the 1005 pair stored at the ITR will be discarded. If a 1006 replayed Map-Reply arrives at the ITR, there is no 1007 that matches the incoming Map-Reply and will be discarded. 1009 In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR 1010 will have to do a LISP-SEC computation. This is equivalent to a 1011 valid LISP-SEC computation and an attacker does not obtain any 1012 benefit. 1014 6.7. Message Privacy 1016 DTLS [RFC6347] SHOULD be used to provide communication privacy and to 1017 prevent eavesdropping, tampering, or message forgery to the messages 1018 exchanged between the ITR, Map-Resolver, Map-Server, and ETR. 1020 6.8. Denial of Service and Distributed Denial of Service Attacks 1022 LISP-SEC mitigates the risks of Denial of Service and Distributed 1023 Denial of Service attacks by protecting the integrity and 1024 authenticating the origin of the Map-Request/Map-Reply messages, and 1025 by preventing malicious ETRs from overclaiming EID prefixes that 1026 could re-direct traffic directed to a potentially large number of 1027 hosts. 1029 7. IANA Considerations 1031 7.1. ECM AD Type Registry 1033 IANA is requested to create the "ECM Authentication Data Type" 1034 registry with values 0-255, for use in the ECM LISP-SEC Extensions 1035 Section 5.1. The registry MUST be initially populated with the 1036 following values: 1038 Name Value Defined In 1039 ------------------------------------------------- 1040 Unassigned 0 This memo 1041 LISP-SEC-ECM-EXT 1 This memo 1043 HMAC Functions 1045 Values 2-255 are unassigned. They are to be assigned according to 1046 the "Specification Required" policy defined in [RFC5226]. 1048 7.2. Map-Reply AD Type Registry 1050 IANA is requested to create the "Map-Reply Authentication Data Type" 1051 registry with values 0-255, for use in the Map-Reply LISP-SEC 1052 Extensions Section 5.2. The registry MUST be initially populated 1053 with the following values: 1055 Name Value Defined In 1056 ------------------------------------------------- 1057 Unassigned 0 This memo 1058 LISP-SEC-MR-EXT 1 This memo 1060 HMAC Functions 1062 Values 2-255 are unassigned. They are to be assigned according to 1063 the "Specification Required" policy defined in [RFC5226]. 1065 7.3. HMAC Functions 1067 IANA is requested to create the "LISP-SEC Authentication Data HMAC 1068 ID" registry with values 0-65535 for use as Requested HMAC ID, EID 1069 HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data: 1071 Name Number Defined In 1072 ------------------------------------------------- 1073 NONE 0 This memo 1074 AUTH-HMAC-SHA-1-96 1 [RFC2104] 1075 AUTH-HMAC-SHA-256-128 2 [RFC6234] 1077 HMAC Functions 1079 Values 3-65535 are unassigned. They are to be assigned according to 1080 the "Specification Required" policy defined in [RFC5226]. 1082 AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be 1083 supported. 1085 7.4. Key Wrap Functions 1087 IANA is requested to create the "LISP-SEC Authentication Data Key 1088 Wrap ID" registry with values 0-65535 for use as OTK key wrap 1089 algorithms ID in the LISP-SEC Authentication Data: 1091 Name Number KEY WRAP KDF 1092 ----------------------------------------------------------------- 1093 Unassigned 0 None None 1094 NULL-KEY-WRAP-128 1 This memo None 1095 AES-KEY-WRAP-128+HKDF-SHA256 2 [RFC3394] [RFC4868] 1097 Key Wrap Functions 1099 Values 3-65535 are unassigned. They are to be assigned according to 1100 the "Specification Required" policy defined in [RFC5226]. 1102 NULL-KEY-WRAP-128, and AES-KEY-WRAP-128+HKDF-SHA256 MUST be 1103 supported. 1105 NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 1106 64-bit preamble set to 0x0000000000000000 (64 bits). 1108 7.5. Key Derivation Functions 1110 IANA is requested to create the "LISP-SEC Authentication Data Key 1111 Derivation Function ID" registry with values 0-65535 for use as KDF 1112 ID in the LISP-SEC Authentication Data: 1114 Name Number Defined In 1115 ------------------------------------------------- 1116 NONE 0 This memo 1117 HKDF-SHA1-128 1 [RFC5869] 1119 Key Derivation Functions 1121 Values 2-65535 are unassigned. They are to be assigned according to 1122 the "Specification Required" policy defined in [RFC5226]. 1124 HKDF-SHA1-128 MUST be supported 1126 8. Acknowledgements 1128 The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino 1129 Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt 1130 Noll for their valuable suggestions provided during the preparation 1131 of this document. 1133 9. References 1135 9.1. Normative References 1137 [I-D.ietf-lisp-rfc6833bis] 1138 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 1139 "Locator/ID Separation Protocol (LISP) Control-Plane", 1140 draft-ietf-lisp-rfc6833bis-24 (work in progress), February 1141 2019. 1143 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1144 Hashing for Message Authentication", RFC 2104, 1145 DOI 10.17487/RFC2104, February 1997, . 1148 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1149 Requirement Levels", BCP 14, RFC 2119, 1150 DOI 10.17487/RFC2119, March 1997, . 1153 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1154 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1155 September 2002, . 1157 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1158 "Randomness Requirements for Security", BCP 106, RFC 4086, 1159 DOI 10.17487/RFC4086, June 2005, . 1162 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1163 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1164 DOI 10.17487/RFC4868, May 2007, . 1167 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1168 IANA Considerations Section in RFCs", RFC 5226, 1169 DOI 10.17487/RFC5226, May 2008, . 1172 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1173 Key Derivation Function (HKDF)", RFC 5869, 1174 DOI 10.17487/RFC5869, May 2010, . 1177 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1178 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1179 January 2012, . 1181 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1182 "Locator/ID Separation Protocol Alternative Logical 1183 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1184 January 2013, . 1186 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1187 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1188 DOI 10.17487/RFC7835, April 2016, . 1191 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1192 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1193 February 2017, . 1195 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1196 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1197 May 2017, . 1199 9.2. Informative References 1201 [I-D.ietf-lisp-rfc6830bis] 1202 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1203 Cabellos-Aparicio, "The Locator/ID Separation Protocol 1204 (LISP)", draft-ietf-lisp-rfc6830bis-26 (work in progress), 1205 November 2018. 1207 Authors' Addresses 1209 Fabio Maino 1210 Cisco Systems 1211 170 Tasman Drive 1212 San Jose, California 95134 1213 USA 1215 Email: fmaino@cisco.com 1217 Vina Ermagan 1218 Google 1219 California 1220 USA 1222 Email: ermagan@gmail.com 1224 Albert Cabellos 1225 Universitat Politecnica de Catalunya 1226 c/ Jordi Girona s/n 1227 Barcelona 08034 1228 Spain 1230 Email: acabello@ac.upc.edu 1232 Damien Saucez 1233 INRIA 1234 2004 route des Lucioles - BP 93 1235 Sophia Antipolis 1236 France 1238 Email: damien.saucez@inria.fr