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