idnits 2.17.1 draft-ietf-lisp-sec-24.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 (8 December 2021) is 863 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 620, but not defined == Missing Reference: 'RFC6234' is mentioned on line 1072, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AFN' == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 ** 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-36 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F.M. Maino 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track V.E. Ermagan 5 Expires: 11 June 2022 Google 6 A.C. Cabellos 7 Universitat Politecnica de Catalunya 8 D.S. Saucez 9 Inria 10 8 December 2021 12 LISP-Security (LISP-SEC) 13 draft-ietf-lisp-sec-24 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 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 11 June 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 59 4. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 60 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5 61 6. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 62 6.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 63 6.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 10 64 6.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 11 65 6.4. ITR Processing: Generating a Map-Request . . . . . . . . 12 66 6.4.1. PITR Processing . . . . . . . . . . . . . . . . . . . 12 67 6.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 13 68 6.5.1. Unencrypted OTK . . . . . . . . . . . . . . . . . . . 14 69 6.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15 70 6.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 71 6.7.1. Generating a LISP-SEC Protected Encapsulated 72 Map-Request . . . . . . . . . . . . . . . . . . . . . 17 73 6.7.2. Generating a Proxy Map-Reply . . . . . . . . . . . . 18 74 6.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 18 75 6.9. ITR Processing: Receiving a Map-Reply . . . . . . . . . . 18 76 6.9.1. Map-Reply Record Validation . . . . . . . . . . . . . 20 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 78 7.1. Mapping System Security . . . . . . . . . . . . . . . . . 21 79 7.2. Random Number Generation . . . . . . . . . . . . . . . . 21 80 7.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 21 81 7.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 22 82 7.5. Shared Keys Provisioning . . . . . . . . . . . . . . . . 22 83 7.6. Replay Attacks . . . . . . . . . . . . . . . . . . . . . 22 84 7.7. Message Privacy . . . . . . . . . . . . . . . . . . . . . 23 85 7.8. Denial of Service and Distributed Denial of Service 86 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 88 8.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 23 89 8.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 23 90 8.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 24 91 8.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 24 92 8.5. Key Derivation Functions . . . . . . . . . . . . . . . . 24 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 96 10.2. Informative References . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 100 1. Introduction 102 The Locator/ID Separation Protocol 103 [I-D.ietf-lisp-rfc6830bis],[I-D.ietf-lisp-rfc6833bis] is a network- 104 layer-based protocol that enables separation of IP addresses into two 105 new numbering spaces: Endpoint Identifiers (EIDs) and Routing 106 Locators (RLOCs). EID-to-RLOC mappings are stored in a database, the 107 LISP Mapping System, and made available via the Map-Request/Map-Reply 108 lookup process. If these EID-to-RLOC mappings, carried through Map- 109 Reply messages, are transmitted without integrity protection, an 110 adversary can manipulate them and hijack the communication, 111 impersonate the requested EID, or mount Denial of Service or 112 Distributed Denial of Service attacks. Also, if the Map-Reply 113 message is transported unauthenticated, an adversarial LISP entity 114 can overclaim an EID-prefix and maliciously redirect traffic directed 115 to a large number of hosts. The LISP-SEC threat model, described in 116 Section 4, is built on top of the LISP threat model defined in 117 [RFC7835], that includes a detailed description of "overclaiming" 118 attack. 120 This memo specifies LISP-SEC, a set of security mechanisms that 121 provides origin authentication, integrity and anti-replay protection 122 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 123 process. LISP-SEC also enables verification of authorization on EID- 124 prefix claims in Map-Reply messages, ensuring that the sender of a 125 Map-Reply that provides the location for a given EID-prefix is 126 entitled to do so according to the EID prefix registered in the 127 associated Map-Server. Map-Register/Map-Notify security, including 128 the right for a LISP entity to register an EID-prefix or to claim 129 presence at an RLOC, is out of the scope of LISP-SEC as those 130 protocols are protected by the security mechanisms specified in 131 [I-D.ietf-lisp-rfc6833bis]. However, LISP-SEC extends the Map- 132 Register message to allow an ITR to securely downgrade to non LISP- 133 SEC Map-Requests. Additional security considerations are described 134 in Section 6. 136 2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in BCP14 [RFC2119] 141 [RFC8174] when, and only when, they appear in all capitals, as shown 142 here. 144 3. 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 4. 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 System 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 registration time. 191 According to the threat model described in [RFC7835] LISP-SEC assumes 192 that any kind of attack, including MITM attacks, can be mounted 193 outside of the boundaries of the LISP mapping system. An on-path 194 attacker, outside of the LISP mapping system can, for example, hijack 195 Map-Request and Map-Reply messages, spoofing the identity of a LISP 196 node. Another example of on-path attack, called overclaiming attack, 197 can be mounted by a malicious Egress Tunnel Router (ETR), by 198 overclaiming the EID-prefixes for which it is authoritative. In this 199 way the ETR can maliciously redirect traffic directed to a large 200 number of hosts. 202 5. Protocol Operations 204 The goal of the security mechanisms defined in 205 [I-D.ietf-lisp-rfc6833bis] is to prevent unauthorized insertion of 206 mapping data by providing origin authentication and integrity 207 protection for the Map-Register, and by using the nonce to detect 208 unsolicited Map-Reply sent by off-path attackers. 210 LISP-SEC builds on top of the security mechanisms defined in 211 [I-D.ietf-lisp-rfc6833bis] to address the threats described in 212 Section 4 by leveraging the trust relationships existing among the 213 LISP entities participating to the exchange of the Map-Request/Map- 214 Reply messages. Those trust relationships are used to securely 215 distribute, as described in Section 8.4, a per-message One-Time Key 216 (OTK) that provides origin authentication, integrity and anti-replay 217 protection to mapping data conveyed via the mapping lookup process, 218 and that effectively prevent overclaiming attacks. The processing of 219 security parameters during the Map-Request/Map-Reply exchange is as 220 follows: 222 * Per each Map-Request message a new ITR-OTK is generated and stored 223 at the ITR, and securely transported to the Map-Server. 225 * The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for 226 Message Authentication (HMAC) [RFC2104] that protects the 227 integrity of the mapping data known to the Map-Server to prevent 228 overclaiming attacks. The Map-Server also derives a new OTK, the 229 MS-OTK, that is passed to the ETR, by applying a Key Derivation 230 Function (KDF) (e.g. [RFC5869]) to the ITR-OTK. 232 * The ETR uses the MS-OTK to compute an HMAC that protects the 233 integrity of the Map-Reply sent to the ITR. 235 * Finally, the ITR uses the stored ITR-OTK to verify the integrity 236 of the mapping data provided by both the Map-Server and the ETR, 237 and to verify that no overclaiming attacks were mounted along the 238 path between the Map-Server and the ITR. 240 Section 6 provides the detailed description of the LISP-SEC control 241 messages and their processing, while the rest of this section 242 describes the flow of LISP protocol operations at each entity 243 involved in the Map-Request/Map-Reply exchange: 245 1. The ITR, upon needing to transmit a Map-Request message, 246 generates and stores an OTK (ITR-OTK). This ITR-OTK is included 247 into the Encapsulated Control Message (ECM) that contains the 248 Map-Request sent to the Map-Resolver. ITR-OTK confidentiality 249 and integrity protection MUST be provided in the path between the 250 ITR and the Map-Resolver. This can be achieved either by 251 encrypting the ITR-OTK with the pre-shared secret known to the 252 ITR and the Map-Resolver (as specified in Section 6.5), or by 253 enabling DTLS between the ITR and the Map-Resolver. 255 2. The Map-Resolver decapsulates the ECM message, decrypts the ITR- 256 OTK, if needed, and forwards through the Mapping System the 257 received Map-Request and the ITR-OTK, as part of a new ECM 258 message. The LISP Mapping System delivers the ECM to the 259 appropriate Map-Server, as identified by the EID destination 260 address of the Map-Request. As mentioned in Section 4, how the 261 Mapping System is protected from MITM attacks depends from the 262 particular Mapping Systems used, and is out of the scope of this 263 memo. 265 3. The Map-Server is configured with the location mappings and 266 policy information for the ETR responsible for the EID 267 destination address. Using this preconfigured information, the 268 Map-Server, after the decapsulation of the ECM message, finds the 269 longest match EID-prefix that covers the requested EID in the 270 received Map-Request. The Map-Server adds this EID-prefix, 271 together with an HMAC computed using the ITR-OTK, to a new 272 Encapsulated Control Message that contains the received Map- 273 Request. 275 4. The Map-Server derives a new OTK, the MS-OTK, by applying a Key 276 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is 277 included in the Encapsulated Control Message that the Map-Server 278 uses to forward the Map-Request to the ETR. MS-OTK 279 confidentiality and integrity protection MUST be provided in the 280 path between the Map-Server and the ETR. This can be achieved 281 either by encrypting the MS-OTK with the pre-shared secret known 282 to the Map-Server and the ETR (as specified in Section 6.5), or 283 by enabling DTLS between the Map-Server and the ETR. 285 5. If the Map-Server is acting in proxy mode, as specified in 286 [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the 287 generation of the Map-Reply and steps 6 and 7 are skipped. In 288 this case the Map-Server generates the Map-Reply on behalf of the 289 ETR as described in Section 6.7.2. 291 6. The ETR, upon receiving the ECM encapsulated Map-Request from the 292 Map-Server, decrypts the MS-OTK, if needed, and originates a Map- 293 Reply that contains the EID-to-RLOC mapping information as 294 specified in [I-D.ietf-lisp-rfc6833bis]. 296 7. The ETR computes an HMAC over the Map-Reply, keyed with MS-OTK to 297 protect the integrity of the whole Map-Reply. The ETR also 298 copies the EID-prefix authorization data that the Map-Server 299 included in the ECM encapsulated Map-Request into the Map-Reply 300 message. The ETR then sends the complete Map-Reply message to 301 the requesting ITR. 303 8. The ITR, upon receiving the Map-Reply, uses the locally stored 304 ITR-OTK to verify the integrity of the EID-prefix authorization 305 data included in the Map-Reply by the Map-Server. The ITR 306 computes the MS-OTK by applying the same KDF (as specified in the 307 ECM encapsulated Map-Reply) used by the Map-Server, and verifies 308 the integrity of the Map-Reply. If the integrity checks fail, 309 the Map-Reply MUST be discarded. Also, if the EID-prefixes 310 claimed by the ETR in the Map-Reply are not equal or more 311 specific than the EID-prefix authorization data inserted by the 312 Map-Server, the ITR MUST discard the Map-Reply. 314 6. LISP-SEC Control Messages Details 316 LISP-SEC metadata associated with a Map-Request is transported within 317 the Encapsulated Control Message that contains the Map-Request. 319 LISP-SEC metadata associated with the Map-Reply is transported within 320 the Map-Reply itself. 322 6.1. Encapsulated Control Message LISP-SEC Extensions 324 LISP-SEC uses the ECM defined in [I-D.ietf-lisp-rfc6833bis] with S 325 bit set to 1 to indicate that the LISP header includes Authentication 326 Data (AD). The format of the LISP-SEC ECM Authentication Data is 327 defined in Figure 1 . OTK-AD stands for One-Time Key Authentication 328 Data and EID-AD stands for EID Authentication Data. 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ECM AD Type |V| Unassigned | Requested HMAC ID | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 335 | OTK Length | Key ID | OTK Wrap. ID | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 337 | One-Time-Key Preamble ... | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD 339 | ... One-Time-Key Preamble | | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 341 ~ One-Time Key (128 bits) ~/ 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 343 | EID-AD Length | KDF ID | | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 345 | Record Count |E| Unassigned | EID HMAC ID |EID-AD 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 347 | Unassigned | EID mask-len | EID-AFI | | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 349 ~ EID-prefix ... ~ | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 351 ~ EID HMAC ~ | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 354 Figure 1: LISP-SEC ECM Authentication Data 356 ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 8. 358 V: Key Version bit. This bit is toggled when the sender switches 359 to a new OTK wrapping key 361 Unassigned: Set to 0 on transmission and ignored on receipt. 363 Requested HMAC ID: The HMAC algorithm, that will be used to 364 protect the mappings, requested by the ITR. See Section 6.4 for 365 details, and Section 8.3 for HMAC IDs that MUST be supported. 367 OTK Length: The length (in bytes) of the OTK Authentication Data 368 (OTK-AD), that contains the OTK Preamble and the OTK. 370 Key ID: The identifier of the pre-shared secret shared by an ITR 371 and the Map-Resolver, and by the Map-Server and an ETR. Per- 372 message keys are derived from the pre-shared secret to encrypt, 373 authenticate the origin and protect the integrity of the OTK. The 374 Key ID allows to rotate between multiple pre-shared secrets in a 375 non disruptive way. 377 OTK Wrapping ID: The identifier of the key derivation function and 378 of the key wrapping algorithm used to encrypt the One-Time-Key. 379 See Section 6.5 for more details, and Section 8.4 for Wrapping IDs 380 that MUST be supported. 382 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 383 the OTK is encrypted, this field MAY carry additional metadata 384 resulting from the key wrapping operation. When a 128-bit OTK is 385 sent unencrypted by Map-Resolver, the OTK Preamble is set to 386 0x0000000000000000 (64 bits). See Section 6.5.1 for details. 388 One-Time-Key: the OTK wrapped as specified by OTK Wrapping ID. 389 See Section 6.5 for details. 391 EID-AD Length: length (in bytes) of the EID Authentication Data 392 (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only 393 fills the KDF ID field, and all the remaining fields part of the 394 EID-AD are not present. An EID-AD MAY contain multiple EID- 395 records. Each EID-record is 4-byte long plus the length of the 396 AFI-encoded EID-prefix. 398 KDF ID: Identifier of the Key Derivation Function used to derive 399 the MS-OTK. The ITR MAY use this field to indicate the 400 recommended KDF algorithm, according to local policy. The Map- 401 Server can overwrite the KDF ID if it does not support the KDF ID 402 recommended by the ITR. See Section 5.4 for more details, and 403 Section 8.5 for KDF IDs that MUST be supported. 405 Record Count: The number of records in this Map-Request message. 406 A record is comprised of the portion of the packet that is labeled 407 'Rec' above and occurs the number of times equal to Record Count. 409 E: ETR-Cant-Sign bit. This bit is set to 1 to signal to the ITR 410 that at least one of the ETRs authoritative for the EID prefixes 411 of this Map-Reply has not enabled LISP-SEC. This allows the ITR 412 to securely downgrade to non LISP-SEC requests, as specified in 413 Section 6.7, if so desired. 415 Unassigned: Set to 0 on transmission and ignored on receipt. 417 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 418 integrity of the EID-AD. This field is filled by Map-Server that 419 computed the EID-prefix HMAC. See Section 5.4 for more details, 420 and Section 8.3 for HMAC IDs that MUST be supported. 422 EID mask-len: Mask length for EID-prefix. 424 EID-AFI: Address family of EID-prefix according to [AFN]. 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 6.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 8. 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 6.7 for more details, and Section 8.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 6.7 for more details, and 482 Section 8.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 8.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 6.8 for more details. 509 6.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 6.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 6.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 6.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 appropriate 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. A HMAC ID Value of 543 NONE (0), MAY be used to specify that the ITR has no preferred HMAC 544 ID. 546 The KDF ID field specifies the suggested key derivation function to 547 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE 548 (0), MAY be used to specify that the ITR has no preferred KDF ID. 550 The EID-AD length is set to 4 bytes, since the Authentication Data 551 does not contain EID-prefix Authentication Data, and the EID-AD 552 contains only the KDF ID field. 554 6.4.1. PITR Processing 556 The processing performed by a PITR is equivalent to the processing of 557 an ITR. However, if the PITR is directly connected to a Mapping 558 System such as LISP+ALT [RFC6836], the PITR performs the functions of 559 both the ITR and the Map-Resolver forwarding the Map-Request 560 encapsulated in an ECM header that includes the Authentication Data 561 fields as described in Section 6.6. 563 6.5. Encrypting and Decrypting an OTK 565 MS-OTK confidentiality and integrity protection MUST be provided in 566 the path between the Map-Server and the ETR. This can be achieved 567 either by enabling DTLS between the Map-Server and the ETR or by 568 encrypting the MS-OTK with the pre-shared secret known to the Map- 569 Server and the ETR [I-D.ietf-lisp-rfc6833bis]. 571 Similarly, ITR-OTK confidentiality and integrity protection MUST be 572 provided in the path between the ITR and the Map-Resolver. This can 573 be achieved either by enabling DTLS between the Map-Server and the 574 ITR, or by encrypting the ITR-OTK with the pre-shared secret known to 575 the ITR and the Map-Resolver. The ITR/Map-Resolver pre-shared key is 576 similar to the Map-Server/ETR pre-shared key. 578 This section describes OTK processing in the ITR/Map-Resolver path, 579 as well as in the Map-Server/ETR path. 581 It's important to note that, to prevent ETR's overclaiming attacks, 582 the ITR/Map-Resolver pre-shared secret MUST be different from the 583 Map-Server/ETR pre-shared secret. 585 The OTK is wrapped using the algorithm specified in the OTK Wrapping 586 ID field. This field identifies both the: 588 * Key Encryption Algorithm used to encrypt the wrapped OTK, as well 589 as the 591 * Key Derivation Function used to derive a per-message encryption 592 key. 594 Implementations of this specification MUST support OTK Wrapping ID 595 AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF- 596 SHA256 Key Derivation Function specified in[RFC4868] to derive a per- 597 message encryption key (per-msg-key), as well as the AES-KEY-WRAP-128 598 Key Wrap algorithm used to encrypt a 128-bit OTK, according to 599 [RFC3394]. 601 The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF- 602 SHA256 is described below: 604 1. The KDF algorithm is identified by the field 'OTK Wrapping ID' 605 according to the table in Section 8.4. 607 2. The Key Wrap algorithm is identified by the field 'OTK Wrapping 608 ID' according to the table in Section 8.4. 610 3. If the NULL-KEY-WRAP-128 algorithm (defined in (Section 8.4)) is 611 selected and DTLS is not enabled, the Map-Request MUST be dropped 612 and an appropriate log action SHOULD be taken. 614 4. The pre-shared secret used to derive the per-msg-key is 615 represented by PSK[Key ID], that is the pre-shared secret 616 identified by the 'Key ID'. 618 5. The per-message encryption key is computed as: 620 * per-msg-key = KDF( nonce + s + PSK[Key ID] ) 622 * where the nonce is the value in the Nonce field of the Map- 623 Request, and 625 * 's' is the string "OTK-Key-Wrap" 627 6. According to [RFC3394] the per-msg-key is used to wrap the OTK 628 with AES-KEY-WRAP-128. The AES Key Wrap Initialization Value 629 MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the 630 AES Key Wrap operation is 192-bit long. The most significant 631 64-bit are copied in the One-Time Key Preamble field, while the 632 128 less significant bits are copied in the One-Time Key field of 633 the LISP-SEC Authentication Data. 635 When decrypting an encrypted OTK the receiver MUST verify that the 636 Initialization Value resulting from the AES Key Wrap decryption 637 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 638 the receiver MUST discard the entire message. 640 6.5.1. Unencrypted OTK 642 MS-OTK confidentiality and integrity protection MUST be provided in 643 the path between the Map-Server and the ETR. Similarly, ITR-OTK 644 confidentiality and integrity protection MUST be provided in the path 645 between the ITR and the Map-Resolver. 647 However, when DTLS is enabled the OTK MAY be sent unencrypted as 648 transport layer security is providing confidentiality and integrity 649 protection. 651 When a 128-bit OTK is sent unencrypted the OTK Wrapping ID is set to 652 NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 653 (64 bits). 655 6.6. Map-Resolver Processing 657 Upon receiving an encapsulated Map-Request with the S-bit set, the 658 Map-Resolver decapsulates the ECM message. The ITR-OTK, if 659 encrypted, is decrypted as specified in Section 6.5. 661 Protecting the confidentiality of the ITR-OTK and, in general, the 662 security of how the Map-Request is handed by the Map-Resolver to the 663 Map-Server, is specific to the particular Mapping System used, and 664 outside of the scope of this memo. 666 In Mapping Systems where the Map-Server is compliant with 667 [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM 668 header with the S-bit set, that contains the unencrypted ITR-OTK, as 669 specified in Section 6.5, and the other data derived from the ECM 670 Authentication Data of the received encapsulated Map-Request. 672 The Map-Resolver then forwards to the Map-Server the received Map- 673 Request, encapsulated in the new ECM header that includes the newly 674 computed Authentication Data fields. 676 6.7. Map-Server Processing 678 Upon receiving an ECM encapsulated Map-Request with the S-bit set to 679 1, the Map-Server process the Map-Request according to the value of 680 the security-capable S-bit and of the proxy map-reply P-bit contained 681 in the Map-Register sent by the ETRs authoritative for that prefix 682 during registration. 684 Processing of the Map-Request MUST proceed in the order described in 685 the table below, applying the processing corresponding to the first 686 rule that matches the conditions indicated in the first column: 688 +=================+==============================================+ 689 | Matching | Processing | 690 | Condition | | 691 +=================+==============================================+ 692 | 1. At least | The Map-Server MUST generate a LISP-SEC | 693 | one of the ETRs | protected Map-Reply as specified in | 694 | authoritative | Section 6.7.2. The ETR-Cant-Sign E-bit in | 695 | for the EID | the EID Authentication Data (EID-AD) MUST be | 696 | prefix included | set to 0. | 697 | in the Map- | | 698 | Request | | 699 | registered with | | 700 | the P-bit set | | 701 | to 1 | | 702 +-----------------+----------------------------------------------+ 703 +-----------------+----------------------------------------------+ 704 | 2. At least | The Map-Server MUST generate a LISP-SEC | 705 | one of the ETRs | protected Encapsulated Map-Request (as | 706 | authoritative | specified in Section 6.7.1), to be sent to | 707 | for the EID | one of the authoritative ETRs that | 708 | prefix included | registered with the S-bit set to 1 (and the | 709 | in the Map- | P-bit set to 0). If there is at least one | 710 | Request | ETR that registered with the S-bit set to 0, | 711 | registered with | the ETR-Cant-Sign E-bit of the EID-AD MUST | 712 | the S-bit set | be set to 1 to signal the ITR that a non | 713 | to 1 | LISP-SEC Map-Request might reach additional | 714 | | ETRs that have LISP-SEC disabled. | 715 +-----------------+----------------------------------------------+ 716 +-----------------+----------------------------------------------+ 717 | 3. All the | The Map-Server MUST send a Negative Map- | 718 | ETRs | Reply protected with LISP-SEC, as described | 719 | authoritative | in Section 6.7.2. The ETR-Cant-Sign E-bit | 720 | for the EID | MUST be set to 1 to signal the ITR that a | 721 | prefix included | non LISP-SEC Map-Request might reach | 722 | in the Map- | additional ETRs that have LISP-SEC disabled. | 723 | Request | | 724 | registered with | | 725 | the S-bit set | | 726 | to 0 | | 727 +-----------------+----------------------------------------------+ 729 Table 1 731 In this way the ITR that sent a LISP-SEC protected Map-Request always 732 receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign 733 E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach 734 additional ETRs that have LISP-SEC disabled. This mechanism allows 735 the ITR to securely downgrade to non LISP-SEC requests, if so 736 desired. 738 6.7.1. Generating a LISP-SEC Protected Encapsulated Map-Request 740 The Map-Server decapsulates the ECM and generates a new ECM 741 Authentication Data. The Authentication Data includes the OTK-AD and 742 the EID-AD, that contains EID-prefix authorization information, that 743 are eventually received by the requesting ITR. 745 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from 746 the ITR-OTK received with the Map-Request. MS-OTK is derived 747 applying the key derivation function specified in the KDF ID field. 748 If the algorithm specified in the KDF ID field is not supported, the 749 Map-Server uses a different algorithm to derive the key and updates 750 the KDF ID field accordingly. 752 MS-OTK confidentiality and integrity protection MUST be provided in 753 the path between the Map-Server and the ETR. This can be achieved 754 either by enabling DTLS between the Map-Server and the ETR, or by 755 encrypting the MS-OTK with the pre-shared secret known to the Map- 756 Server and the ETR. 758 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 759 1, to indicate the presence of Authentication Data. 761 MS-OTK is wrapped with the algorithm specified by the OTK Wrapping ID 762 field. See Section 6.5 for further details on OTK encryption. If 763 the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled 764 in the path between the Map-Server and the ETR, the Map-Request MUST 765 be dropped and an appropriate log action SHOULD be taken. 767 The Map-Server includes in the EID-AD the longest match registered 768 EID-prefix for the destination EID, and an HMAC of this EID-prefix. 769 The HMAC is keyed with the ITR-OTK contained in the received ECM 770 Authentication Data, and the HMAC algorithm is chosen according to 771 the Requested HMAC ID field. If the Map-Server does not support this 772 algorithm, the Map-Server uses a different algorithm and specifies it 773 in the EID HMAC ID field. The scope of the HMAC operation covers the 774 entire EID-AD, from the EID-AD Length field to the EID HMAC field, 775 which must be set to 0 before the computation. 777 The Map-Server then forwards the updated ECM encapsulated Map- 778 Request, that contains the OTK-AD, the EID-AD, and the received Map- 779 Request to an authoritative ETR as specified in 780 [I-D.ietf-lisp-rfc6833bis]. 782 6.7.2. Generating a Proxy Map-Reply 784 LISP-SEC proxy Map-Reply are generated according to 785 [I-D.ietf-lisp-rfc6833bis], with the Map-Reply S-bit set to 1. The 786 Map-Reply includes the Authentication Data that contains the EID-AD, 787 computed as specified in Section 6.7.1, as well as the PKT-AD 788 computed as specified in Section 6.8. 790 6.8. ETR Processing 792 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 793 the ETR decapsulates the ECM message. The OTK field, if encrypted, 794 is decrypted as specified in Section 6.5 to obtain the unencrypted 795 MS-OTK. 797 The ETR then generates a Map-Reply as specified in 798 [I-D.ietf-lisp-rfc6833bis] and includes the Authentication Data that 799 contains the EID-AD, as received in the encapsulated Map-Request, as 800 well as the PKT-AD. 802 The EID-AD is copied from the Authentication Data of the received 803 encapsulated Map-Request. 805 The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed 806 with the MS-OTK and computed using the HMAC algorithm specified in 807 the Requested HMAC ID field of the received encapsulated Map-Request. 808 If the ETR does not support the Requested HMAC ID, it uses a 809 different algorithm and updates the PKT HMAC ID field accordingly. 810 The scope of the HMAC operation covers the entire PKT-AD, from the 811 Map-Reply Type field to the PKT HMAC field, which must be set to 0 812 before the computation. 814 Finally the ETR sends the Map-Reply to the requesting ITR as 815 specified in [I-D.ietf-lisp-rfc6833bis]. 817 6.9. ITR Processing: Receiving a Map-Reply 819 In response to an encapsulated Map-Request that has the S-bit set, an 820 ITR MUST receive a Map-Reply with the S-bit set, that includes an 821 EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the 822 ITR MUST discard it. In response to an encapsulated Map-Request with 823 S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and 824 the ITR SHOULD discard the Map-Reply if the S-bit is set. 826 Upon receiving a Map-Reply, the ITR must verify the integrity of both 827 the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of 828 the integrity checks fails. After processing the Map-Reply, the ITR 829 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. 841 ITR MUST set the EID HMAC ID field to 0 before computing the HMAC. 843 To verify the integrity of the PKT-AD, first the MS-OTK is derived 844 from the locally stored ITR-OTK using the algorithm specified in the 845 KDF ID field. This is because the PKT-AD is generated by the ETR 846 using the MS-OTK. If the KDF ID in the Map-Reply does not match the 847 KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- 848 Reply and send, at the first opportunity it needs to, a new Map- 849 Request with a different KDF ID, according to ITR's local policy. 850 Without consistent configuration of involved entities, extra delays 851 may be experienced. However, since HKDF-SHA1-128 is specified as 852 mandatory to implement in Section 8.5, the process will eventually 853 converge. 855 The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD 856 using the Algorithm specified in the PKT HMAC ID field. If the PKT 857 HMAC ID field does not match the Requested HMAC ID the ITR SHOULD 858 discard the Map-Reply and send, at the first opportunity it needs to, 859 a new Map-Request with a different Requested HMAC ID according to 860 ITR's local policy or until all HMAC IDs supported by the ITR have 861 been attempted. 863 Each individual Map-Reply EID-record is considered valid only if: (1) 864 both EID-AD and PKT-AD are valid, and (2) the intersection of the 865 EID-prefix in the Map-Reply EID-record with one of the EID-prefixes 866 contained in the EID-AD is not empty. After identifying the Map- 867 Reply record as valid, the ITR sets the EID-prefix in the Map-Reply 868 record to the value of the intersection set computed before, and adds 869 the Map-Reply EID-record to its EID-to-RLOC cache, as described in 870 [I-D.ietf-lisp-rfc6833bis]. An example of Map-Reply record 871 validation is provided in Section 6.9.1. 873 [I-D.ietf-lisp-rfc6833bis] allows ITRs to send solicited Map-Requests 874 directly to the ETRs that send the SMR message in the first place. 875 However, in order to receive a secure Map-Reply, ITRs SHOULD send SMR 876 triggered Map-Requests over the mapping system using the 877 specifications of this memo. If an ITR accepts piggybacked Map- 878 Replies, it SHOULD also send a Map-Request over the mapping system in 879 order to verify the piggybacked Map-Reply with a secure Map-Reply. 881 6.9.1. Map-Reply Record Validation 883 The payload of a Map-Reply may contain multiple EID-records. The 884 whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide 885 integrity protection and origin authentication to the EID-prefix 886 records claimed by the ETR. The Authentication Data field of a Map- 887 Reply may contain multiple EID-records in the EID-AD. The EID-AD is 888 signed by the Map-Server, with the EID HMAC, to provide integrity 889 protection and origin authentication to the EID-prefix records 890 inserted by the Map-Server. 892 Upon receiving a Map-Reply with the S-bit set, the ITR first checks 893 the validity of both the EID HMAC and of the PKT-AD HMAC. If either 894 one of the HMACs is not valid, a log action MUST be taken and the 895 Map-Reply MUST NOT be processed any further. If both HMACs are 896 valid, the ITR proceeds with validating each individual EID-record 897 claimed by the ETR by computing the intersection of each one of the 898 EID-prefix contained in the payload of the Map-Reply with each one of 899 the EID-prefixes contained in the EID-AD. An EID-record is valid 900 only if at least one of the intersections is not the empty set. 902 For instance, the Map-Reply payload contains 3 mapping record EID- 903 prefixes: 905 2001:db8:102::/48 907 2001:db8:103::/48 909 2001:db8:200::/40 911 The EID-AD contains two EID-prefixes: 913 2001:db8:103::/48 915 2001:db8:203::/48 917 The EID-record with EID-prefix 2001:db8:102::/48 is not eligible to 918 be used by the ITR since it is not included in any of the EID-ADs 919 signed by the Map-Server. A log action MUST be taken. 921 The EID-record with EID-prefix 2001:db8:103::/48 is eligible to be 922 used by the ITR because it matches the second EID-prefix contained in 923 the EID-AD. 925 The EID-record with EID-prefix 2001:db8:200::/40 is not eligible to 926 be used by the ITR since it is not included in any of the EID-ADs 927 signed by the Map-Server. A log action MUST be taken. In this last 928 example the ETR is trying to over claim the EID-prefix 929 2001:db8:200::/40, but the Map-Server authorized only 930 2001:db8:203::/48, hence the EID-record is discarded. 932 7. Security Considerations 934 7.1. Mapping System Security 936 The LISP-SEC threat model described in Section 4, assumes that the 937 LISP Mapping System is working properly and eventually delivers Map- 938 Request messages to a Map-Server that is authoritative for the 939 requested EID. 941 It is assumed that the Mapping System ensures the confidentiality of 942 the OTK, and the integrity of the Map-Reply data. However, how the 943 LISP Mapping System is secured is out of the scope of this document. 945 Similarly, Map-Register security, including the right for a LISP 946 entity to register an EID-prefix or to claim presence at an RLOC, is 947 out of the scope of LISP-SEC. 949 7.2. Random Number Generation 951 The ITR-OTK MUST be generated by a properly seeded pseudo-random (or 952 strong random) source. See [RFC4086] for advice on generating 953 security-sensitive random data 955 7.3. Map-Server and ETR Colocation 957 If the Map-Server and the ETR are colocated, LISP-SEC does not 958 provide protection from overclaiming attacks mounted by the ETR. 959 However, in this particular case, since the ETR is within the trust 960 boundaries of the Map-Server, ETR's overclaiming attacks are not 961 included in the threat model. 963 7.4. Deploying LISP-SEC 965 This memo is written according to [RFC2119]. Specifically, the use 966 of the key word SHOULD "or the adjective 'RECOMMENDED', mean that 967 there may exist valid reasons in particular circumstances to ignore a 968 particular item, but the full implications must be understood and 969 carefully weighed before choosing a different course". 971 Those deploying LISP-SEC according to this memo, should carefully 972 weight how the LISP-SEC threat model applies to their particular use 973 case or deployment. If they decide to ignore a particular 974 recommendation, they should make sure the risk associated with the 975 corresponding threats is well understood. 977 As an example, in certain closed and controlled deployments, it is 978 possible that the threat associated with a MITM between the xTR and 979 the Mapping System is very low, and after carfeul consideration it 980 may be decided to allow a NULL key wrapping algorithm while carrying 981 the OTKs between the xTR and the Mapping System. 983 As an example at the other end of the spectrum, in certain other 984 deployments, attackers may be very sophisticated, and force the 985 deployers to enforce very strict policies in term of HMAC algorithms 986 accepted by an ITR. 988 Similar considerations apply to the entire LISP-SEC threat model, and 989 should guide the deployers and implementors whenever they encounter 990 the key word SHOULD across this memo. 992 7.5. Shared Keys Provisioning 994 Provisioning of the keys shared between the ITR and the Map-Resolver 995 as well as between the ETR and the Map-Server should be performed via 996 an orchestration infrastructure and it is out of the scope of this 997 memo. It is recommended that both shared keys are refreshed at 998 periodical intervals to address key aging or attackers gaining 999 unauthorized access to the shared keys. Shared keys should be 1000 unpredictable random values. 1002 7.6. Replay Attacks 1004 An attacker can capture a valid Map-Request and/or Map-Reply and 1005 replay it, however once the ITR receives the original Map-Reply the 1006 pair stored at the ITR will be discarded. If a 1007 replayed Map-Reply arrives at the ITR, there is no 1008 that matches the incoming Map-Reply and will be discarded. 1010 In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR 1011 will have to do a LISP-SEC computation. This is equivalent to a 1012 valid LISP-SEC computation and an attacker does not obtain any 1013 benefit. 1015 7.7. Message Privacy 1017 DTLS [RFC6347] SHOULD be used to provide communication privacy and to 1018 prevent eavesdropping, tampering, or message forgery to the messages 1019 exchanged between the ITR, Map-Resolver, Map-Server, and ETR. 1021 7.8. Denial of Service and Distributed Denial of Service Attacks 1023 LISP-SEC mitigates the risks of Denial of Service and Distributed 1024 Denial of Service attacks by protecting the integrity and 1025 authenticating the origin of the Map-Request/Map-Reply messages, and 1026 by preventing malicious ETRs from overclaiming EID prefixes that 1027 could re-direct traffic directed to a potentially large number of 1028 hosts. 1030 8. IANA Considerations 1032 8.1. ECM AD Type Registry 1034 IANA is requested to create the "ECM Authentication Data Type" 1035 registry with values 0-255, for use in the ECM LISP-SEC Extensions 1036 Section 6.1. The registry MUST be initially populated with the 1037 following values: 1039 Name Value Defined In 1040 ------------------------------------------------- 1041 Reserved 0 This memo 1042 LISP-SEC-ECM-EXT 1 This memo 1044 Values 2-255 are unassigned. They are to be assigned according to 1045 the "Specification Required" policy defined in [RFC5226]. 1047 8.2. Map-Reply AD Type Registry 1049 IANA is requested to create the "Map-Reply Authentication Data Type" 1050 registry with values 0-255, for use in the Map-Reply LISP-SEC 1051 Extensions Section 6.2. The registry MUST be initially populated 1052 with the following values: 1054 Name Value Defined In 1055 ------------------------------------------------- 1056 Reserved 0 This memo 1057 LISP-SEC-MR-EXT 1 This memo 1059 Values 2-255 are unassigned. They are to be assigned according to 1060 the "Specification Required" policy defined in [RFC5226]. 1062 8.3. HMAC Functions 1064 IANA is requested to create the "LISP-SEC Authentication Data HMAC 1065 ID" registry with values 0-65535 for use as Requested HMAC ID, EID 1066 HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data: 1068 Name Number Defined In 1069 ------------------------------------------------- 1070 NONE 0 This memo 1071 AUTH-HMAC-SHA-1-96 1 [RFC2104] 1072 AUTH-HMAC-SHA-256-128 2 [RFC6234] 1074 Values 3-65535 are unassigned. They are to be assigned according to 1075 the "Specification Required" policy defined in [RFC5226]. 1077 AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be 1078 supported. 1080 8.4. Key Wrap Functions 1082 IANA is requested to create the "LISP-SEC Authentication Data Key 1083 Wrap ID" registry with values 0-65535 for use as OTK key wrap 1084 algorithms ID in the LISP-SEC Authentication Data: 1086 Name Number KEY WRAP KDF 1087 ----------------------------------------------------------------- 1088 Reserved 0 None None 1089 NULL-KEY-WRAP-128 1 This memo None 1090 AES-KEY-WRAP-128+HKDF-SHA256 2 [RFC3394] [RFC4868] 1092 Values 3-65535 are unassigned. They are to be assigned according to 1093 the "Specification Required" policy defined in [RFC5226]. 1095 NULL-KEY-WRAP-128, and AES-KEY-WRAP-128+HKDF-SHA256 MUST be 1096 supported. 1098 NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 1099 64-bit preamble set to 0x0000000000000000 (64 bits). 1101 8.5. Key Derivation Functions 1103 IANA is requested to create the "LISP-SEC Authentication Data Key 1104 Derivation Function ID" registry with values 0-65535 for use as KDF 1105 ID in the LISP-SEC Authentication Data: 1107 Name Number Defined In 1108 ------------------------------------------------- 1109 NONE 0 This memo 1110 HKDF-SHA1-128 1 [RFC5869] 1112 Values 2-65535 are unassigned. They are to be assigned according to 1113 the "Specification Required" policy defined in [RFC5226]. 1115 HKDF-SHA1-128 MUST be supported 1117 9. Acknowledgements 1119 The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino 1120 Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt 1121 Noll for their valuable suggestions provided during the preparation 1122 of this document. 1124 10. References 1126 10.1. Normative References 1128 [AFN] IANA - Internet Assigned Numbers Authority, "Address 1129 Family Numbers", 2021, 1130 . 1132 [I-D.ietf-lisp-rfc6833bis] 1133 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 1134 "Locator/ID Separation Protocol (LISP) Control-Plane", 1135 Work in Progress, Internet-Draft, draft-ietf-lisp- 1136 rfc6833bis-30, 18 November 2020, 1137 . 1140 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1141 Hashing for Message Authentication", RFC 2104, 1142 DOI 10.17487/RFC2104, February 1997, 1143 . 1145 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1146 Requirement Levels", BCP 14, RFC 2119, 1147 DOI 10.17487/RFC2119, March 1997, 1148 . 1150 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1151 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1152 September 2002, . 1154 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1155 "Randomness Requirements for Security", BCP 106, RFC 4086, 1156 DOI 10.17487/RFC4086, June 2005, 1157 . 1159 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1160 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1161 DOI 10.17487/RFC4868, May 2007, 1162 . 1164 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1165 IANA Considerations Section in RFCs", RFC 5226, 1166 DOI 10.17487/RFC5226, May 2008, 1167 . 1169 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1170 Key Derivation Function (HKDF)", RFC 5869, 1171 DOI 10.17487/RFC5869, May 2010, 1172 . 1174 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1175 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1176 January 2012, . 1178 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1179 "Locator/ID Separation Protocol Alternative Logical 1180 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1181 January 2013, . 1183 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1184 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1185 DOI 10.17487/RFC7835, April 2016, 1186 . 1188 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1189 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1190 February 2017, . 1192 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1193 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1194 May 2017, . 1196 10.2. Informative References 1198 [I-D.ietf-lisp-rfc6830bis] 1199 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 1200 Cabellos, "The Locator/ID Separation Protocol (LISP)", 1201 Work in Progress, Internet-Draft, draft-ietf-lisp- 1202 rfc6830bis-36, 18 November 2020, 1203 . 1206 Authors' Addresses 1208 Fabio Maino 1209 Cisco Systems 1210 170 Tasman Drive 1211 San Jose, California 95134 1212 United States of America 1214 Email: fmaino@cisco.com 1216 Vina Ermagan 1217 Google 1218 California 1219 United States of America 1221 Email: ermagan@gmail.com 1223 Albert Cabellos 1224 Universitat Politecnica de Catalunya 1225 c/ Jordi Girona s/n 1226 08034 Barcelona 1227 Spain 1229 Email: acabello@ac.upc.edu 1231 Damien Saucez 1232 Inria 1233 2004 route des Lucioles - BP 93 1234 Sophia Antipolis 1235 France 1237 Email: damien.saucez@inria.fr