idnits 2.17.1 draft-ietf-lisp-sec-28.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2022) is 637 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 606, but not defined ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Downref: Normative reference to an Informational RFC: RFC 3394 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 6234 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Downref: Normative reference to an Informational RFC: RFC 7835 Summary: 6 errors (**), 0 flaws (~~), 2 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: January 2, 2023 Google 6 A. Cabellos 7 Universitat Politecnica de Catalunya 8 D. Saucez 9 Inria 10 July 1, 2022 12 LISP-Security (LISP-SEC) 13 draft-ietf-lisp-sec-28 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 the 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 January 2, 2023. 40 Copyright Notice 42 Copyright (c) 2022 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 59 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 60 4. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 61 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5 62 6. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 63 6.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 64 6.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 10 65 6.3. Map-Register LISP-SEC Extensions . . . . . . . . . . . . 11 66 6.4. ITR Processing: Generating a Map-Request . . . . . . . . 11 67 6.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 12 68 6.5.1. Unencrypted OTK . . . . . . . . . . . . . . . . . . . 14 69 6.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 70 6.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 71 6.7.1. Generating a LISP-SEC Protected Encapsulated Map- 72 Request . . . . . . . . . . . . . . . . . . . . . . . 16 73 6.7.2. Generating a Proxy Map-Reply . . . . . . . . . . . . 17 74 6.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . 22 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 . . . . . . . . . . . . . . . . 25 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 25 96 10.2. Informational References . . . . . . . . . . . . . . . . 27 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. The 115 LISP-SEC threat model, described in Section 4, is built on top of the 116 LISP threat model defined in [RFC7835], that includes a detailed 117 description of "overclaiming" attack. 119 This memo specifies LISP-SEC, a set of security mechanisms that 120 provides origin authentication, integrity and anti-replay protection 121 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 122 process. LISP-SEC also enables verification of authorization on EID- 123 prefix claims in Map-Reply messages, ensuring that the sender of a 124 Map-Reply that provides the location for a given EID-prefix is 125 entitled to do so according to the EID prefix registered in the 126 associated Map-Server. Map-Register/Map-Notify security, including 127 the right for a LISP entity to register an EID-prefix or to claim 128 presence at an RLOC, is out of the scope of LISP-SEC as those 129 protocols are protected by the security mechanisms specified in 130 [I-D.ietf-lisp-rfc6833bis]. However, LISP-SEC extends the Map- 131 Register message to allow an ITR to downgrade to non LISP-SEC Map- 132 Requests. Additional security considerations are described in 133 Section 6. 135 2. Requirements Notation 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 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 on-path attack can be mounted within the LISP Mapping 185 System. How the Mapping System is protected from on-path attacks 186 depends from the particular Mapping System used, and is out of the 187 scope of this memo. Furthermore, while LISP-SEC enables detection of 188 EID prefix overclaiming attacks, it assumes that Map-Servers can 189 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 on-path 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. 201 5. Protocol Operations 203 The goal of the security mechanisms defined in 204 [I-D.ietf-lisp-rfc6833bis] is to prevent unauthorized insertion of 205 mapping data by providing origin authentication and integrity 206 protection for the Map-Register, and by using the nonce to detect 207 unsolicited Map-Reply sent by off-path attackers. 209 LISP-SEC builds on top of the security mechanisms defined in to 210 address the threats described in Section 4 by leveraging the trust 211 relationships existing among the LISP entities 212 ([I-D.ietf-lisp-rfc6833bis]) participating in the exchange of the 213 Map-Request/Map-Reply messages. Those trust relationships (see also 214 Section 7 and [I-D.ietf-lisp-rfc6833bis]) 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 o 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 o 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 o The ETR uses the MS-OTK to compute an HMAC that protects the 233 integrity of the Map-Reply sent to the ITR. 235 o 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 encrypted 247 and included into the Encapsulated Control Message (ECM) that 248 contains the Map-Request sent to the Map-Resolver. 250 2. The Map-Resolver decapsulates the ECM message, decrypts the ITR- 251 OTK, if needed, and forwards through the Mapping System the 252 received Map-Request and the ITR-OTK, as part of a new ECM 253 message. The LISP Mapping System delivers the ECM to the 254 appropriate Map-Server, as identified by the EID destination 255 address of the Map-Request. 257 3. The Map-Server is configured with the location mappings and 258 policy information for the ETR responsible for the EID 259 destination address. Using this preconfigured information, the 260 Map-Server, after the decapsulation of the ECM message, finds the 261 longest match EID-prefix that covers the requested EID in the 262 received Map-Request. The Map-Server adds this EID-prefix, 263 together with an HMAC computed using the ITR-OTK, to a new 264 Encapsulated Control Message that contains the received Map- 265 Request. 267 4. The Map-Server derives a new OTK, the MS-OTK, by applying a Key 268 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is 269 included in the Encapsulated Control Message that the Map-Server 270 uses to forward the Map-Request to the ETR. 272 5. If the Map-Server is acting in proxy mode, as specified in 273 [I-D.ietf-lisp-rfc6833bis], the ETR is not involved in the 274 generation of the Map-Reply and steps 6 and 7 are skipped. In 275 this case the Map-Server generates the Map-Reply on behalf of the 276 ETR as described in Section 6.7.2. 278 6. The ETR, upon receiving the ECM encapsulated Map-Request from the 279 Map-Server, decrypts the MS-OTK, if needed, and originates a Map- 280 Reply that contains the EID-to-RLOC mapping information as 281 specified in [I-D.ietf-lisp-rfc6833bis]. 283 7. The ETR computes an HMAC over the Map-Reply, keyed with MS-OTK to 284 protect the integrity of the whole Map-Reply. The ETR also 285 copies the EID-prefix authorization data that the Map-Server 286 included in the ECM encapsulated Map-Request into the Map-Reply 287 message. The ETR then sends the complete Map-Reply message to 288 the requesting ITR. 290 8. The ITR, upon receiving the Map-Reply, uses the locally stored 291 ITR-OTK to verify the integrity of the EID-prefix authorization 292 data included in the Map-Reply by the Map-Server. The ITR 293 computes the MS-OTK by applying the same KDF (as specified in the 294 ECM encapsulated Map-Reply) used by the Map-Server, and verifies 295 the integrity of the Map-Reply. 297 6. LISP-SEC Control Messages Details 299 LISP-SEC metadata associated with a Map-Request is transported within 300 the Encapsulated Control Message that contains the Map-Request. 302 LISP-SEC metadata associated with the Map-Reply is transported within 303 the Map-Reply itself. 305 These specifications use Keyed-Hashing for Message Authentication 306 (HMAC) in various places (as described in the following). The HMAC 307 function AUTH-HMAC-SHA-256-128 [RFC6234] MUST be supported in LISP- 308 SEC implementations. LISP-SEC deployments SHOULD use AUTH-HMAC-SHA- 309 256-128 HMAC function, except when communicating with older 310 implementations using AUTH-HMAC-SHA-1-96 present in the same 311 deployment. [RFC2104]. 313 6.1. Encapsulated Control Message LISP-SEC Extensions 315 LISP-SEC uses the ECM defined in [I-D.ietf-lisp-rfc6833bis] with S 316 bit set to 1 to indicate that the LISP header includes Authentication 317 Data (AD). The format of the LISP-SEC ECM Authentication Data is 318 defined in Figure 1 . OTK-AD stands for One-Time Key Authentication 319 Data and EID-AD stands for EID Authentication Data. 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | ECM AD Type | Unassigned | Requested HMAC ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 326 | OTK Length | Key ID | OTK Wrap. ID | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 328 | One-Time-Key Preamble ... | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD 330 | ... One-Time-Key Preamble | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 332 ~ One-Time Key (128 bits) ~/ 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 334 | EID-AD Length | KDF ID | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 336 | Record Count |E| Unassigned | EID HMAC ID |EID-AD 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 338 | Unassigned | EID mask-len | EID-AFI | | | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 340 ~ EID-prefix ... ~ | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 342 ~ EID HMAC ~ | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 345 Figure 1: LISP-SEC ECM Authentication Data 347 ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 8. 349 Unassigned: Set to 0 on transmission and ignored on receipt. 351 Requested HMAC ID: The HMAC algorithm, that will be used to 352 protect the mappings, requested by the ITR. Permitted values are 353 registered in the LISP-SEC Authentication Data HMAC ID (see 354 Section 8.3). Refer to Section 6.4 for more details. 356 OTK Length: The length (in bytes) of the OTK Authentication Data 357 (OTK-AD), that contains the OTK Preamble and the OTK. 359 Key ID: The identifier of the pre-shared secret shared by an ITR 360 and the Map-Resolver, and by the Map-Server and an ETR. Per- 361 message keys are derived from the pre-shared secret to encrypt, 362 authenticate the origin and protect the integrity of the OTK. The 363 Key ID allows to rotate between multiple pre-shared secrets in a 364 non disruptive way. 366 OTK Wrapping ID (OTK Wrap. ID): The identifier of the key 367 derivation function and of the key wrapping algorithm used to 368 encrypt the One-Time-Key. Permitted values are registered in the 369 LISP-SEC Authentication Data Key Wrap ID (see Section 8.4). Refer 370 to Section 6.5 for more details. 372 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 373 the OTK is encrypted, this field MAY carry additional metadata 374 resulting from the key wrapping operation. When a 128-bit OTK is 375 sent unencrypted by a Map-Resolver, the OTK Preamble is set to 376 0x0000000000000000 (64 bits). See Section 6.5.1 for details. 378 One-Time-Key: the OTK wrapped as specified by OTK Wrapping ID. 379 See Section 6.5 for details. 381 EID-AD Length: length (in bytes) of the EID Authentication Data 382 (EID-AD). The ITR MUST set the EID-AD Length to 4 bytes, as it 383 only fills the KDF ID field, and all the remaining fields part of 384 the EID-AD are not present. An EID-AD MAY contain multiple EID- 385 records. Each EID-record is 4-byte long plus the length of the 386 AFI-encoded EID-prefix. 388 KDF ID: Identifier of the Key Derivation Function used to derive 389 the MS-OTK. Permitted values are registered in the LISP-SEC 390 Authentication Data Key Derivation Function ID (see Section 8.5). 391 Refer to Section 6.7 for more details. 393 Record Count: As defined in Section 5.2 of 394 [I-D.ietf-lisp-rfc6833bis]. 396 E: ETR-Cant-Sign bit. If this bit is set to 1, it signals to the 397 ITR that at least one of the ETRs authoritative for the EID 398 prefixes of this Map-Reply has not enabled LISP-SEC. Only a Map- 399 Server can set this bit. See Section 6.7 for more details. 401 Unassigned: Set to 0 on transmission and ignored on receipt. 403 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 404 integrity of the EID-AD. This field is filled by the Map-Server 405 that computed the EID-prefix HMAC. See Section 6.7.1 for more 406 details. 408 EID mask-len: As defined in Section 5.2 of 409 [I-D.ietf-lisp-rfc6833bis]. 411 EID-AFI: As defined in Section 5.2 of [I-D.ietf-lisp-rfc6833bis]. 413 EID-prefix: As defined in Section 5.2 of 414 [I-D.ietf-lisp-rfc6833bis]. 416 EID HMAC: HMAC of the EID-AD computed and inserted by a Map-Server 417 See Section 6.7.1 for more details. 419 6.2. Map-Reply LISP-SEC Extensions 421 LISP-SEC uses the Map-Reply defined in [I-D.ietf-lisp-rfc6833bis], 422 with Type set to 2, and S-bit set to 1 to indicate that the Map-Reply 423 message includes Authentication Data (AD). The format of the LISP- 424 SEC Map-Reply Authentication Data is defined in Figure 2. PKT-AD is 425 the Packet Authentication Data that covers the Map-Reply payload. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | MR AD Type | Unassigned | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 432 | EID-AD Length | KDF ID | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 434 | Record Count | Unassigned | EID HMAC ID |EID-AD 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 436 | Unassigned | EID mask-len | EID-AFI | | | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 438 ~ EID-prefix ... ~ | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 440 ~ EID HMAC ~ | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 442 | PKT-AD Length | PKT HMAC ID |\ 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 444 ~ PKT HMAC ~PKT-AD 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 447 Figure 2: LISP-SEC Map-Reply Authentication Data 449 MR AD Type: 1 (LISP-SEC Authentication Data). See Section 8. 451 EID-AD Length: length (in bytes) of the EID-AD (see Section 6.1). 453 KDF ID: Identifier of the Key Derivation Function used to derive 454 MS-OTK (see Section 6.1). 456 Record Count: The number of records in this Map-Reply message (see 457 Section 6.1). 459 Unassigned: Set to 0 on transmission and ignored on receipt. 461 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 462 integrity of the EID-AD (see Section 6.1). 464 EID mask-len: Mask length for EID-prefix (see Section 6.1). 466 EID-AFI: See Section 6.1. . 468 EID-prefix: See Section 6.1. 470 EID HMAC: See Section 6.1. 472 PKT-AD Length: length (in bytes) of the Packet Authentication Data 473 (PKT-AD). 475 PKT HMAC ID: Identifier of the HMAC algorithm used to protect the 476 integrity of the Map-Reply (see Section 6.5). 478 PKT HMAC: HMAC of the whole Map-Reply packet, so to protect its 479 integrity; including the LISP-SEC Authentication Data (from the 480 Map-Reply Type field to the PKT HMAC field), which allow message 481 authetification. 483 6.3. Map-Register LISP-SEC Extensions 485 The S bit in the Map-Register message (see 486 [I-D.ietf-lisp-rfc6833bis]) indicates to the Map-Server that the 487 registering ETR is LISP-SEC enabled. An ETR that supports LISP-SEC 488 MUST set the S bit in its Map-Register messages. 490 6.4. ITR Processing: Generating a Map-Request 492 Upon creating a Map-Request, the ITR generates a random ITR-OTK that 493 is stored locally, until the corresponding Map-Reply is received (see 494 Section 6.9), together with the nonce generated as specified in 495 [I-D.ietf-lisp-rfc6833bis]. 497 The ITR MAY use the KDF ID field to indicate the recommended KDF 498 algorithm, according to local policy. The Map-Server can overwrite 499 the KDF ID if it does not support the KDF ID recommended by the ITR 500 (see Section 6.7). A KDF value of NOPREF (0) may be used to specify 501 that the ITR has no preferred KDF ID. 503 ITR-OTK confidentiality and integrity protection MUST be provided in 504 the path between the ITR and the Map-Resolver. This can be achieved 505 either by encrypting the ITR-OTK with the pre-shared secret known to 506 the ITR and the Map-Resolver (see Section 6.5), or by enabling DTLS 507 [RFC9147] between the ITR and the Map-Resolver. 509 The Map-Request (as defined in [I-D.ietf-lisp-rfc6833bis]) MUST be 510 encapsulated as a LISP Control Message in an ECM, with the S-bit set 511 to 1, to indicate the presence of Authentication Data. Such a 512 message is also called "Protected Map-Request" in this memo. 514 The ITR-OTK is wrapped with the algorithm specified by the OTK 515 Wrapping ID field. See Section 6.5 for further details on OTK 516 encryption. If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is 517 selected, and no other encryption mechanism (e.g. DTLS) is enabled 518 in the path between the ITR and the Map-Resolver, the Map-Request 519 MUST be dropped, and an appropriate log action SHOULD be taken. 520 Implementations may include mechanisms (which are beyond the scope of 521 this document) to avoid log resource exhaustion attacks. 523 The Requested HMAC ID field contains the suggested HMAC algorithm to 524 be used by the Map-Server and the ETR to protect the integrity of the 525 ECM Authentication data and of the Map-Reply. A HMAC ID Value of 526 NONE (0), MAY be used to specify that the ITR has no preferred HMAC 527 ID. 529 The KDF ID field specifies the suggested key derivation function to 530 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE 531 (0) may be used to specify that the ITR has no preferred KDF ID. 533 The EID-AD length is set to 4 bytes, since the Authentication Data 534 does not contain EID-prefix Authentication Data, and the EID-AD 535 contains only the KDF ID field. 537 If the ITR is directly connected to a Mapping System, such as 538 LISP+ALT [RFC6836], it performs the functions of both the ITR and the 539 Map-Resolver, forwarding the Protected Map-Request as described in 540 Section 6.6. 542 The processing performed by Proxy ITRs (PITRs) is equivalent to the 543 processing of an ITR, hence the procedure described above applies. 545 6.5. Encrypting and Decrypting an OTK 547 MS-OTK confidentiality and integrity protection MUST be provided in 548 the path between the Map-Server and the ETR. This can be achieved 549 either by enabling DTLS between the Map-Server and the ETR or by 550 encrypting the MS-OTK with the pre-shared secret known to the Map- 551 Server and the ETR [I-D.ietf-lisp-rfc6833bis]. 553 Similarly, ITR-OTK confidentiality and integrity protection MUST be 554 provided in the path between the ITR and the Map-Resolver. This can 555 be achieved either by enabling DTLS between the Map-Server and the 556 ITR, or by encrypting the ITR-OTK with the pre-shared secret known to 557 the ITR and the Map-Resolver. The ITR/Map-Resolver pre-shared key is 558 similar to the Map-Server/ETR pre-shared key. 560 This section describes OTK processing in the ITR/Map-Resolver path, 561 as well as in the Map-Server/ETR path. 563 It's important to note that, to prevent ETR's overclaiming attacks, 564 the ITR/Map-Resolver pre-shared secret MUST be independent from the 565 Map-Server/ETR pre-shared secret. 567 The OTK is wrapped using the algorithm specified in the OTK Wrapping 568 ID field. This field identifies both the: 570 o Key Encryption Algorithm used to encrypt the wrapped OTK. 572 o Key Derivation Function used to derive a per-message encryption 573 key. 575 Implementations of this specification MUST support OTK Wrapping ID 576 AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF- 577 SHA256 Key Derivation Function specified in [RFC5869] to derive a 578 per-message encryption key (per-msg-key), as well as the AES-KEY- 579 WRAP-128 Key Wrap algorithm used to encrypt a 128-bit OTK, according 580 to [RFC3394]. 582 Implementations of this specification MUST support OTK Wrapping NULL- 583 KEY-WRAP-128. NULL-KEY-WRAP-128 is used to carry an unencrypted 584 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 585 bits). 587 The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF- 588 SHA256 is described below: 590 1. The KDF and Key Wrap algorithms are identified by the value of 591 the 'OTK Wrapping ID' field. The initial values are documented 592 in Table 5. 594 2. If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected 595 and DTLS is not enabled, the Map-Request MUST be dropped and an 596 appropriate log action SHOULD be taken. Implementations may 597 include mechanisms (which are beyond the scope of this document) 598 to avoid log resource exhaustion attacks. 600 3. The pre-shared secret used to derive the per-msg-key is 601 represented by PSK[Key ID], that is the pre-shared secret 602 identified by the 'Key ID'. 604 4. The 128-bits long per-message encryption key is computed as: 606 * per-msg-key = KDF( nonce + s + PSK[Key ID] ) 607 where the nonce is the value in the Nonce field of the Map- 608 Request, 's' is the string "OTK-Key-Wrap", and the operation'+' 609 just indicates string concatenation. 611 5. According to [RFC3394] the per-msg-key is used to wrap the OTK 612 with AES-KEY-WRAP-128. The AES Key Wrap Initialization Value 613 MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the 614 AES Key Wrap operation is 192-bit long. The most significant 615 64-bit are copied in the One-Time Key Preamble field, while the 616 128 less significant bits are copied in the One-Time Key field of 617 the LISP-SEC Authentication Data. 619 When decrypting an encrypted OTK the receiver MUST verify that the 620 Initialization Value resulting from the AES Key Wrap decryption 621 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 622 the receiver MUST discard the entire message. 624 6.5.1. Unencrypted OTK 626 However, when DTLS is enabled the OTK MAY be sent unencrypted as 627 transport layer security is providing confidentiality and integrity 628 protection. 630 When a 128-bit OTK is sent unencrypted the OTK Wrapping ID is set to 631 NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 632 (64 bits). 634 6.6. Map-Resolver Processing 636 Upon receiving a Protected Map-Request, the Map-Resolver decapsulates 637 the ECM message. The ITR-OTK, if encrypted, is decrypted as 638 specified in Section 6.5. 640 Protecting the confidentiality of the ITR-OTK and, in general, the 641 security of how the Map-Request is handed by the Map-Resolver to the 642 Map-Server, is specific to the particular Mapping System used, and 643 outside of the scope of this memo. 645 In Mapping Systems where the Map-Server is compliant with 646 [I-D.ietf-lisp-rfc6833bis], the Map-Resolver originates a new ECM 647 header with the S-bit set, that contains the unencrypted ITR-OTK, as 648 specified in Section 6.5, and the other data derived from the ECM 649 Authentication Data of the received encapsulated Map-Request. 651 The Map-Resolver then forwards to the Map-Server the received Map- 652 Request, encapsulated in the new ECM header that includes the newly 653 computed Authentication Data fields. 655 6.7. Map-Server Processing 657 Upon receiving a Protected Map-Request, the Map-Server processes it 658 according to the setting of the S-bit and the P-bit in the Map- 659 Register received from the ETRs authoritative for that prefix, as 660 described below. 662 While processing the Map-Request, the Map-Server can overwrite the 663 KDF ID field if it does not support the KDF ID recommended by the 664 ITR. Processing of the Map-Request MUST proceed in the order 665 described in the table below, applying the processing corresponding 666 to the first rule that matches the conditions indicated in the first 667 column: 669 +---------------------+---------------------------------------------+ 670 | Matching Condition | Processing | 671 +---------------------+---------------------------------------------+ 672 | 1. At least one of | The Map-Server MUST generate a LISP-SEC | 673 | the ETRs | protected Map-Reply as specified in | 674 | authoritative for | Section 6.7.2. The ETR-Cant-Sign E-bit in | 675 | the EID prefix | the EID Authentication Data (EID-AD) MUST | 676 | included in the | be set to 0. | 677 | Map-Request | | 678 | registered with the | | 679 | P-bit set to 1 | | 680 | | | 681 | 2. At least one of | The Map-Server MUST generate a LISP-SEC | 682 | the ETRs | protected Encapsulated Map-Request (as | 683 | authoritative for | specified in Section 6.7.1), to be sent to | 684 | the EID prefix | one of the authoritative ETRs that | 685 | included in the | registered with the S-bit set to 1 (and the | 686 | Map-Request | P-bit set to 0). If there is at least one | 687 | registered with the | ETR that registered with the S-bit set to | 688 | S-bit set to 1 | 0, the ETR-Cant-Sign E-bit of the EID-AD | 689 | | MUST be set to 1 to signal the ITR that a | 690 | | non LISP-SEC Map-Request might reach | 691 | | additional ETRs that have LISP-SEC | 692 | | disabled. | 693 | | | 694 | 3. All the ETRs | The Map-Server MUST send a Negative Map- | 695 | authoritative for | Reply protected with LISP-SEC, as described | 696 | the EID prefix | in Section 6.7.2. The ETR-Cant-Sign E-bit | 697 | included in the | MUST be set to 1 to signal the ITR that a | 698 | Map-Request | non LISP-SEC Map-Request might reach | 699 | registered with the | additional ETRs that have LISP-SEC | 700 | S-bit set to 0 | disabled. | 701 +---------------------+---------------------------------------------+ 703 Table 1: Map-Request Processing. 705 In this way the ITR that sent a LISP-SEC protected Map-Request always 706 receives a LISP-SEC protected Map-Reply. However, the ETR-Cant-Sign 707 E-bit set to 1 specifies that a non LISP-SEC Map-Request might reach 708 additional ETRs that have LISP-SEC disabled. This mechanism allows 709 the ITR to downgrade to non LISP-SEC requests, which does not protect 710 against threats described in Section 4. 712 6.7.1. Generating a LISP-SEC Protected Encapsulated Map-Request 714 The Map-Server decapsulates the ECM and generates a new ECM 715 Authentication Data. The Authentication Data includes the OTK-AD and 716 the EID-AD, that contains EID-prefix authorization information, that 717 are eventually received by the requesting ITR. 719 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from 720 the ITR-OTK received with the Map-Request. MS-OTK is derived 721 applying the key derivation function specified in the KDF ID field. 722 If the algorithm specified in the KDF ID field is not supported, the 723 Map-Server uses a different algorithm to derive the key and updates 724 the KDF ID field accordingly. 726 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 727 1, to indicate the presence of Authentication Data. 729 MS-OTK is wrapped with the algorithm specified by the OTK Wrapping ID 730 field. See Section 6.5 for further details on OTK encryption. If 731 the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled 732 in the path between the Map-Server and the ETR, the Map-Request MUST 733 be dropped and an appropriate log action SHOULD be taken. 735 The Map-Server includes in the EID-AD the longest match registered 736 EID-prefix for the destination EID, and an HMAC of this EID-prefix. 737 The HMAC is keyed with the ITR-OTK contained in the received ECM 738 Authentication Data, and the HMAC algorithm is chosen according to 739 the Requested HMAC ID field. If the Map-Server does not support this 740 algorithm, the Map-Server uses a different algorithm and specifies it 741 in the EID HMAC ID field. The scope of the HMAC operation MUST cover 742 the entire EID-AD, from the EID-AD Length field to the EID HMAC 743 field, which MUST be set to 0 before the computation. 745 The Map-Server then forwards the updated ECM encapsulated Map- 746 Request, that contains the OTK-AD, the EID-AD, and the received Map- 747 Request to an authoritative ETR as specified in 748 [I-D.ietf-lisp-rfc6833bis]. 750 6.7.2. Generating a Proxy Map-Reply 752 LISP-SEC proxy Map-Reply are generated according to 753 [I-D.ietf-lisp-rfc6833bis], with the Map-Reply S-bit set to 1. The 754 Map-Reply includes the Authentication Data that contains the EID-AD, 755 computed as specified in Section 6.7.1, as well as the PKT-AD 756 computed as specified in Section 6.8. 758 6.8. ETR Processing 760 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 761 the ETR decapsulates the ECM message. The OTK field, if encrypted, 762 is decrypted as specified in Section 6.5 to obtain the unencrypted 763 MS-OTK. 765 The ETR then generates a Map-Reply as specified in 766 [I-D.ietf-lisp-rfc6833bis] and includes the Authentication Data that 767 contains the EID-AD, as received in the encapsulated Map-Request, as 768 well as the PKT-AD. 770 The EID-AD is copied from the Authentication Data of the received 771 encapsulated Map-Request. 773 The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed 774 with the MS-OTK and computed using the HMAC algorithm specified in 775 the Requested HMAC ID field of the received encapsulated Map-Request. 776 If the ETR does not support the Requested HMAC ID, it uses a 777 different algorithm and updates the PKT HMAC ID field accordingly. 778 The HMAC operation MUST cover the entire Map-Reply, where the PKT 779 HMAC field MUST be set to 0 before the computation. 781 Finally the ETR sends the Map-Reply to the requesting ITR as 782 specified in [I-D.ietf-lisp-rfc6833bis]. 784 6.9. ITR Processing: Receiving a Map-Reply 786 In response to a Protected Map-Request, an ITR expects a Map-Reply 787 with the S-bit set to 1 including an EID-AD and a PKT-AD. The ITR 788 MUST discard the Map-Reply otherwise. 790 Upon receiving a Map-Reply, the ITR must verify the integrity of both 791 the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of 792 the integrity checks fails. After processing the Map-Reply, the ITR 793 MUST discard the pair associated to the Map-Reply 795 The integrity of the EID-AD is verified using the ITR-OTK (stored 796 locally for the duration of this exchange) to re-compute the HMAC of 797 the EID-AD using the algorithm specified in the EID HMAC ID field. 798 If the ITR did indicate a Requested HMAC ID in the Map-Request and 799 the PKT HAMC ID in the corresponding Map-Reply is different, or if 800 the ITR did not indicate a Requested HMAC ID in the Map-Request and 801 the PKT HMAC ID in the corresponding Map-Reply is not supported, then 802 the ITR MUST discard the Map-Reply and send, according to rate 803 limitation policies defined in [I-D.ietf-lisp-rfc6833bis], a new Map- 804 Request with a different Requested HMAC ID field, according to ITR's 805 local policy. The scope of the HMAC operation covers the entire EID- 806 AD, from the EID-AD Length field to the EID HMAC field. 808 ITR MUST set the EID HMAC ID field to 0 before computing the HMAC. 810 To verify the integrity of the PKT-AD, first the MS-OTK is derived 811 from the locally stored ITR-OTK using the algorithm specified in the 812 KDF ID field. This is because the PKT-AD is generated by the ETR 813 using the MS-OTK. If the ITR did indicate a recommended KDF ID in 814 the Map-Request and the KDF ID in the corresponding Map-Reply is 815 different, or if the ITR did not indicate a recommended KDF ID in the 816 Map-Request and the KDF ID in the corresponding Map-Reply is not 817 supported, then the ITR MUST discard the Map-Reply and send, 818 according to rate limitation policies defined in 819 [I-D.ietf-lisp-rfc6833bis], a new Map-Request with a different KDF 820 ID, according to ITR's local policy. The key derivation function 821 HKDF-SHA256 MUST be supported in LISP-SEC implementations. LISP-SEC 822 deployments SHOULD use the HKDF-SHA256 HKDF function, unless older 823 implementations using HKDF-SHA1-128 are present in the same 824 deployment. Without consistent configuration of involved entities, 825 extra delays may be experienced. However, since HKDF-SHA1-128 and 826 HKDF-SHA256 are supported, the process will eventually converge. 828 The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD 829 using the Algorithm specified in the PKT HMAC ID field. If the PKT 830 HMAC ID field does not match the Requested HMAC ID the ITR MUST 831 discard the Map-Reply and send, according to rate limitation policies 832 defined in [I-D.ietf-lisp-rfc6833bis], a new Map-Request with a 833 different Requested HMAC ID according to ITR's local policy or until 834 all HMAC IDs supported by the ITR have been attempted. When the PKT 835 HMAC ID field does not match the Requested HMAC ID it is not possible 836 to validate the Map-Reply. 838 Each individual Map-Reply EID-record is considered valid only if: (1) 839 both EID-AD and PKT-AD are valid, and (2) the intersection of the 840 EID-prefix in the Map-Reply EID-record with one of the EID-prefixes 841 contained in the EID-AD is not empty. After identifying the Map- 842 Reply record as valid, the ITR sets the EID-prefix in the Map-Reply 843 record to the value of the intersection set computed before, and adds 844 the Map-Reply EID-record to its EID-to-RLOC cache, as described in 845 [I-D.ietf-lisp-rfc6833bis]. An example of Map-Reply record 846 validation is provided in Section 6.9.1. 848 [I-D.ietf-lisp-rfc6833bis] allows ETRs to send Solicit-Map-Requests 849 (SMR) directly to the ITR. The corresponding SMR-invoked Map-Request 850 will be sent through the mapping system, hence, secured with the 851 specifications of this memo if in use. If an ITR accepts Map-Replies 852 piggybacked in Map-Requests and its content is not already present in 853 its EID-to-RLOC cache, it MUST send a Map-Request over the mapping 854 system in order to verify its content with a secured Map-Reply, 855 before using the content. 857 6.9.1. Map-Reply Record Validation 859 The payload of a Map-Reply may contain multiple EID-records. The 860 whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide 861 integrity protection and origin authentication to the EID-prefix 862 records claimed by the ETR. The Authentication Data field of a Map- 863 Reply may contain multiple EID-records in the EID-AD. The EID-AD is 864 signed by the Map-Server, with the EID HMAC, to provide integrity 865 protection and origin authentication to the EID-prefix records 866 inserted by the Map-Server. 868 Upon receiving a Map-Reply with the S-bit set, the ITR first checks 869 the validity of both the EID HMAC and of the PKT-AD HMAC. If either 870 one of the HMACs is not valid, a log action SHOULD be taken and the 871 Map-Reply MUST NOT be processed any further. Implementations may 872 include mechanisms (which are beyond the scope of this document) to 873 avoid log resource exhaustion attacks. If both HMACs are valid, the 874 ITR proceeds with validating each individual EID-record claimed by 875 the ETR by computing the intersection of each one of the EID-prefix 876 contained in the payload of the Map-Reply with each one of the EID- 877 prefixes contained in the EID-AD. An EID-record is valid only if at 878 least one of the intersections is not the empty set, otherwise, a log 879 action MUST be taken and the EID-record MUST be discarded. 880 Implementations may include mechanisms (which are beyond the scope of 881 this document) to avoid log resource exhaustion attacks. 883 For instance, the Map-Reply payload contains 3 mapping record EID- 884 prefixes: 886 2001:db8:102::/48 888 2001:db8:103::/48 890 2001:db8:200::/40 892 The EID-AD contains two EID-prefixes: 894 2001:db8:103::/48 896 2001:db8:203::/48 898 The EID-record with EID-prefix 2001:db8:102::/48 is not eligible to 899 be used by the ITR since it is not included in any of the EID-ADs 900 signed by the Map-Server. A log action MUST be taken and the EID- 901 record MUST be discarded. Implementations may include mechanisms 902 (which are beyond the scope of this document) to avoid log resource 903 exhaustion attacks. 905 The EID-record with EID-prefix 2001:db8:103::/48 is eligible to be 906 used by the ITR because it matches the second EID-prefix contained in 907 the EID-AD. 909 The EID-record with EID-prefix 2001:db8:200::/40 is not eligible to 910 be used by the ITR since it is not included in any of the EID-ADs 911 signed by the Map-Server. A log action MUST be taken and the EID- 912 record MUST be discarded. Implementations may include mechanisms 913 (which are beyond the scope of this document) to avoid log resource 914 exhaustion attacks. In this last example the ETR is trying to over 915 claim the EID-prefix 2001:db8:200::/40, but the Map-Server authorized 916 only 2001:db8:203::/48, hence the EID-record is discarded. 918 7. Security Considerations 920 This document extends the LISP Control-Plane defined in 921 [I-D.ietf-lisp-rfc6833bis], hence, its Security Considerations apply 922 as well to this document. 924 7.1. Mapping System Security 926 The LISP-SEC threat model described in Section 4, assumes that the 927 LISP Mapping System is working properly and delivers Map-Request 928 messages to a Map-Server that is authoritative for the requested EID. 930 It is assumed that the Mapping System ensures the confidentiality of 931 the OTK, and the integrity of the Map-Reply data. However, how the 932 LISP Mapping System is secured is out of the scope of this document. 934 Similarly, Map-Register security, including the right for a LISP 935 entity to register an EID-prefix or to claim presence at an RLOC, is 936 out of the scope of LISP-SEC. 938 7.2. Random Number Generation 940 The ITR-OTK MUST be generated by a properly seeded pseudo-random (or 941 strong random) source. See [RFC4086] for advice on generating 942 security-sensitive random data. 944 7.3. Map-Server and ETR Colocation 946 If the Map-Server and the ETR are colocated, LISP-SEC does not 947 provide protection from overclaiming attacks mounted by the ETR. 948 However, in this particular case, since the ETR is within the trust 949 boundaries of the Map-Server, ETR's overclaiming attacks are not 950 included in the threat model. 952 7.4. Deploying LISP-SEC 954 Those deploying LISP-SEC according to this memo, should carefully 955 weight how the LISP-SEC threat model applies to their particular use 956 case or deployment. If they decide to ignore a particular 957 recommendation, they should make sure the risk associated with the 958 corresponding threats is well understood. 960 As an example, in certain other deployments, attackers may be very 961 sophisticated, and force the deployers to enforce very strict 962 policies in term of HMAC algorithms accepted by an ITR. 964 Similar considerations apply to the entire LISP-SEC threat model, and 965 should guide the deployers and implementors whenever they encounter 966 the key word SHOULD across this memo. 968 7.5. Shared Keys Provisioning 970 Provisioning of the keys shared between ITR and Map-Resolver paris as 971 well as between ETR and Map-Server pairs should be performed via an 972 orchestration infrastructure and it is out of the scope of this memo. 973 It is recommended that both shared keys are refreshed at periodical 974 intervals to address key aging or attackers gaining unauthorized 975 access to the shared keys. Shared keys should be unpredictable 976 random values. 978 7.6. Replay Attacks 980 An attacker can capture a valid Map-Request and/or Map-Reply and 981 replay it, however once the ITR receives the original Map-Reply the 982 pair stored at the ITR will be discarded. If a 983 replayed Map-Reply arrives at the ITR, there is no 984 that matches the incoming Map-Reply and will be discarded. 986 In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR 987 will have to do a LISP-SEC computation. This is equivalent, in terms 988 of resources, to a valid LISP-SEC computation and, beyond a risk of 989 DoS attack, an attacker does not obtain any additional effect, since 990 the corresponding Map-Reply is discarded as previously explained. 992 7.7. Message Privacy 994 DTLS [RFC9147] SHOULD be used (conforming to [RFC7525]) to provide 995 communication privacy and to prevent eavesdropping, tampering, or 996 message forgery to the messages exchanged between the ITR, Map- 997 Resolver, Map-Server, and ETR, unless the OTK is encrypted in another 998 way, e.g. using a pre-shared secret. 1000 7.8. Denial of Service and Distributed Denial of Service Attacks 1002 LISP-SEC mitigates the risks of Denial of Service and Distributed 1003 Denial of Service attacks by protecting the integrity and 1004 authenticating the origin of the Map-Request/Map-Reply messages, and 1005 by preventing malicious ETRs from overclaiming EID prefixes that 1006 could re-direct traffic directed to a potentially large number of 1007 hosts. 1009 8. IANA Considerations 1011 IANA is requested to create the sub-registries listed in the 1012 following sections in the "Locator/ID Separation Protocol (LISP) 1013 Parameters" registry. 1015 For all of the sub-registries, new values beyond this document have 1016 to be assigned according to the "Specification Required" policy 1017 defined in [RFC8126]. Expert review should assess the security 1018 properties of newly added functions, so that encryption robustness is 1019 remains strong. For instance, at the time of this writing the use of 1020 SHA-256-based functions is considered to provide sufficient 1021 protection. Consultation with security experts may be needed. 1023 8.1. ECM AD Type Registry 1025 IANA is requested to create the "ECM Authentication Data Type" 1026 registry with values 0-255, for use in the ECM LISP-SEC Extensions 1027 Section 6.1. Initial allocation of this registry is shown in 1028 Table 2. 1030 +------------------+--------+------------+ 1031 | Name | Number | Defined in | 1032 +------------------+--------+------------+ 1033 | Reserved | 0 | This memo | 1034 | LISP-SEC-ECM-EXT | 1 | This memo | 1035 +------------------+--------+------------+ 1037 Table 2: ECM Authentication Data Types. 1039 Values 2-255 are unassigned. 1041 8.2. Map-Reply AD Type Registry 1043 IANA is requested to create the "Map-Reply Authentication Data Type" 1044 registry with values 0-255, for use in the Map-Reply LISP-SEC 1045 Extensions Section 6.2. Initial allocation of this registry is shown 1046 in Table 3. 1048 +-----------------+--------+------------+ 1049 | Name | Number | Defined in | 1050 +-----------------+--------+------------+ 1051 | Reserved | 0 | This memo | 1052 | LISP-SEC-MR-EXT | 1 | This memo | 1053 +-----------------+--------+------------+ 1055 Table 3: Map-Reply Authentication Data Types. 1057 Values 2-255 are unassigned. 1059 8.3. HMAC Functions 1061 IANA is requested to create the "LISP-SEC Preferred Authentication 1062 Data HMAC ID" registry with values 0-65535 for use as Requested HMAC 1063 ID, EID HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data. 1064 Initial allocation of this registry is shown in Table 4. 1066 +-----------------------+--------+------------+ 1067 | Name | Number | Defined in | 1068 +-----------------------+--------+------------+ 1069 | NOPREF | 0 | This memo | 1070 | AUTH-HMAC-SHA-1-96 | 1 | [RFC2104] | 1071 | AUTH-HMAC-SHA-256-128 | 2 | [RFC6234] | 1072 +-----------------------+--------+------------+ 1074 Table 4: LISP-SEC Authentication Data HMAC Functions. 1076 Values 3-65535 are unassigned. 1078 8.4. Key Wrap Functions 1080 IANA is requested to create the "LISP-SEC Authentication Data Key 1081 Wrap ID" registry with values 0-65535 for use as OTK key wrap 1082 algorithms ID in the LISP-SEC Authentication Data. Initial 1083 allocation of this registry is shown in Table 5. 1085 +------------------------------+--------+-----------+-----------+ 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] | 1091 +------------------------------+--------+-----------+-----------+ 1093 Table 5: LISP-SEC Authentication Data Key Wrap Functions. 1095 Values 3-65535 are unassigned. 1097 8.5. Key Derivation Functions 1099 IANA is requested to create the "LISP-SEC Authentication Data Key 1100 Derivation Function ID" registry with values 0-65535 for use as KDF 1101 ID. Initial allocation of this registry is shown in Table 6. 1103 +----------------+--------------+------------+ 1104 | Name | Number | Defined in | 1105 +----------------+--------------+------------+ 1106 | NOPREF | 0 | This memo | 1107 | HKDF-SHA1-128 | 1 | [RFC5869] | 1108 | HKDF-SHA256 | 2 | [RFC5869] | 1109 +----------------+--------------+------------+ 1111 Table 6: LISP-SEC Authentication Data Key Derivation Function ID. 1113 Values 2-65535 are unassigned. 1115 9. Acknowledgements 1117 The authors would like to acknowledge Luigi Iannone, Pere Monclus, 1118 Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis 1119 and Landon Curt Noll for their valuable suggestions provided during 1120 the preparation of this document. 1122 10. References 1124 10.1. Normative References 1126 [I-D.ietf-lisp-rfc6830bis] 1127 lispers.net, vaf.net Internet Consulting, 1-4-5.net, Cisco 1128 Systems, and UPC/BarcelonaTech, "The Locator/ID Separation 1129 Protocol (LISP)", draft-ietf-lisp-rfc6830bis-38 (work in 1130 progress), May 2022. 1132 [I-D.ietf-lisp-rfc6833bis] 1133 lispers.net, Cisco Systems, vaf.net Internet Consulting, 1134 and UPC/BarcelonaTech, "Locator/ID Separation Protocol 1135 (LISP) Control-Plane", draft-ietf-lisp-rfc6833bis-31 (work 1136 in progress), May 2022. 1138 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1139 Hashing for Message Authentication", RFC 2104, 1140 DOI 10.17487/RFC2104, February 1997, 1141 . 1143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1144 Requirement Levels", BCP 14, RFC 2119, 1145 DOI 10.17487/RFC2119, March 1997, 1146 . 1148 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 1149 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 1150 September 2002, . 1152 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1153 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1154 DOI 10.17487/RFC4868, May 2007, 1155 . 1157 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1158 Key Derivation Function (HKDF)", RFC 5869, 1159 DOI 10.17487/RFC5869, May 2010, 1160 . 1162 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 1163 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 1164 DOI 10.17487/RFC6234, May 2011, 1165 . 1167 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1168 "Recommendations for Secure Use of Transport Layer 1169 Security (TLS) and Datagram Transport Layer Security 1170 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1171 2015, . 1173 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1174 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1175 DOI 10.17487/RFC7835, April 2016, 1176 . 1178 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1179 Writing an IANA Considerations Section in RFCs", BCP 26, 1180 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1181 . 1183 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1184 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1185 May 2017, . 1187 [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1188 Datagram Transport Layer Security (DTLS) Protocol Version 1189 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, 1190 . 1192 10.2. Informational References 1194 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1195 "Randomness Requirements for Security", BCP 106, RFC 4086, 1196 DOI 10.17487/RFC4086, June 2005, 1197 . 1199 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1200 "Locator/ID Separation Protocol Alternative Logical 1201 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1202 January 2013, . 1204 Authors' Addresses 1206 Fabio Maino 1207 Cisco Systems 1208 170 Tasman Drive 1209 San Jose, California 95134 1210 USA 1212 Email: fmaino@cisco.com 1214 Vina Ermagan 1215 Google 1216 California 1217 USA 1219 Email: ermagan@gmail.com 1221 Albert Cabellos 1222 Universitat Politecnica de Catalunya 1223 c/ Jordi Girona s/n 1224 Barcelona 08034 1225 Spain 1227 Email: acabello@ac.upc.edu 1229 Damien Saucez 1230 Inria 1231 2004 route des Lucioles - BP 93 1232 Sophia Antipolis 1233 France 1235 Email: damien.saucez@inria.fr