RFC 9303

Locator/ID Separation Protocol Security (LISP-SEC)

📅 published October 2022, from ietf

Locator/ID Separation Protocol Security (LISP-SEC) 🎀

Okay bestie, let's get into RFC 9303 🦋. It's an IETF doc with the number 9303, and it's on the Standards Track (the official "this is a real spec" lane). It's dated October 2022, has ISSN 2070-1721, and was written by four people: F. Maino (Cisco Systems), V. Ermagan (Google, Inc.), A. Cabellos (Universitat Politecnica de Catalunya), and D. Saucez (Inria). The header doesn't list anything it obsoletes or updates, so there's nothing to cross-check there ✨.

Abstract ✨

This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that gives origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data that moves through the mapping lookup process. LISP-SEC also lets you verify authorization on EID-Prefix claims in Map-Reply messages 💅.

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9303.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents 🌸

1.  Introduction
2.  Requirements Notation
3.  Definitions of Terms
4.  LISP-SEC Threat Model
5.  Protocol Operations
6.  LISP-SEC Control Messages Details
  6.1.  Encapsulated Control Message LISP-SEC Extensions
  6.2.  Map-Reply LISP-SEC Extensions
  6.3.  Map-Register LISP-SEC Extensions
  6.4.  ITR Processing: Generating a Map-Request
  6.5.  Encrypting and Decrypting an OTK
    6.5.1.  Unencrypted OTK
  6.6.  Map-Resolver Processing
  6.7.  Map-Server Processing
    6.7.1.  Generating a LISP-SEC-Protected Encapsulated
            Map-Request
    6.7.2.  Generating a Proxy Map-Reply
  6.8.  ETR Processing
  6.9.  ITR Processing: Receiving a Map-Reply
    6.9.1.  Map-Reply Record Validation
7.  Security Considerations
  7.1.  Mapping System Security
  7.2.  Random Number Generation
  7.3.  Map-Server and ETR Colocation
  7.4.  Deploying LISP-SEC
  7.5.  Shared Keys Provisioning
  7.6.  Replay Attacks
  7.7.  Message Privacy
  7.8.  Denial-of-Service and Distributed Denial-of-Service Attacks
8.  IANA Considerations
  8.1.  ECM AD Type Registry
  8.2.  Map-Reply AD Types Registry
  8.3.  HMAC Functions
  8.4.  Key Wrap Functions
  8.5.  Key Derivation Functions
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ✨

The Locator/ID Separation Protocol (LISP) [RFC9300] [RFC9301] is a network-layer protocol that splits IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs) 🦋. EID-to-RLOC mappings live in a database and the LISP Mapping System, and you get them through the Map-Request/Map-Reply lookup process. Now here's the problem: if those mappings, carried in Map-Reply messages, get sent without integrity protection, an adversary can tamper with them and hijack the communication, impersonate the EID being requested, or launch Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) attacks 😭. And if the Map-Reply isn't authenticated, an adversarial LISP entity can overclaim an EID-Prefix and quietly redirect traffic 💀. The LISP-SEC threat model, described in Section 4, is built on top of the LISP threat model defined in [RFC7835], which includes a detailed description of an "overclaiming" attack.

This memo specifies LISP-SEC, a set of security mechanisms that gives origin authentication, integrity, and anti-replay protection to LISP's EID-to-RLOC mapping data carried through the mapping lookup process 🔥. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages. That means it makes sure the sender of a Map-Reply giving the location for a given EID-Prefix is actually entitled to do so, based on the EID-Prefix registered with the associated Map-Server. Map-Register/Map-Notify security is a different story. That covers the right for a LISP entity to register an EID-Prefix or to claim presence at an RLOC, and it's out of scope for LISP-SEC because those protocols are already protected by the mechanisms specified in [RFC9301] 🙈. LISP-SEC does extend the Map-Register message, though, so that an Ingress Tunnel Router (ITR) can downgrade to non-LISP-SEC Map-Requests. Additional security considerations are described in Section 7.

2. Requirements Notation 🎀

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lowercase versions of those words don't carry that special meaning, so read them as regular English 🧚.

3. Definitions of Terms 🌈

One-Time Key (OTK): An ephemeral, randomly generated key that must be used for a single Map-Request/Map-Reply exchange 🔑.

ITR One-Time Key (ITR-OTK): The One-Time Key generated at the Ingress Tunnel Router (ITR).

MS One-Time Key (MS-OTK): The One-Time Key generated at the Map-Server.

Authentication Data (AD): Metadata that's included either in a LISP Encapsulated Control Message (ECM) header, as defined in [RFC9301], or in a Map-Reply message. Its job is to support confidentiality, integrity protection, and verification of EID-Prefix authorization 💜.

OTK Authentication Data (OTK-AD): The part of ECM Authentication Data that holds a One-Time Key.

EID Authentication Data (EID-AD): The part of ECM and Map-Reply Authentication Data used to verify EID-Prefix authorization.

Packet Authentication Data (PKT-AD): The part of Map-Reply Authentication Data used to protect the integrity of the Map-Reply message.

For definitions of other terms, especially Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and Map-Resolver (MR), check out the LISP specification [RFC9301] 📖.

4. LISP-SEC Threat Model 👑

LISP-SEC addresses the control plane threats described in Sections 3.7 and 3.8 of [RFC7835]. Those threats target EID-to-RLOC mappings and include manipulation of Map-Request and Map-Reply messages, plus malicious ETR EID-Prefix overclaiming 😤. LISP-SEC makes two main assumptions. First, the LISP Mapping System is expected to deliver a Map-Request message to its intended destination ETR, as identified by the EID. Second, no on-path attack can be mounted within the LISP Mapping System. How the Mapping System is protected from on-path attacks depends on which Mapping System you're using, and that's out of scope for this memo. Also, while LISP-SEC enables detection of EID-Prefix overclaiming attacks, it assumes that Map-Servers can verify EID-Prefix authorization at registration time ✨.

According to the threat model in [RFC7835], LISP-SEC assumes that any kind of attack, including on-path attacks, can be mounted outside the boundaries of the LISP Mapping System 🕵️‍♀️. An on-path attacker outside the LISP Mapping System can, for example, hijack Map-Request and Map-Reply messages by spoofing the identity of a LISP node. Another on-path example is an overclaiming attack, where a malicious ETR overclaims the EID-Prefixes it's authoritative for. That lets the ETR maliciously redirect traffic, and yes, it's giving villain arc 😈.

5. Protocol Operations ✨

Okay bestie, the whole job of the security mechanisms in [RFC9301] is to stop unauthorized mapping data from getting inserted. They do that with origin authentication and integrity protection for the Map-Register, and they use the nonce to catch an unsolicited Map-Reply from an off-path attacker 🕵️‍♀️

LISP-SEC is built on top of that, and it's giving layered protection 🧁 It addresses the threats from Section 4 by using the trust relationships that already exist among the LISP entities [RFC9301] that take part in the Map-Request/Map-Reply exchange. Those trust relationships (see also Section 7 and [RFC9301]) are used to securely distribute a per-message One-Time Key (OTK), as described in Section 8.4. That key gives origin authentication, integrity, and anti-replay protection to the mapping data passed along during the mapping lookup, and it effectively shuts down overclaiming attacks 💅 Here's how the security parameters get processed during the Map-Request/Map-Reply exchange:

  • Per each Map-Request message, a new ITR-OTK is generated and stored at the ITR, and it gets securely transported to the Map-Server.
  • The Map-Server uses the ITR-OTK to compute a Hashed Message Authentication Code (HMAC) [RFC2104] that protects the integrity of the mapping data known to the Map-Server, which keeps overclaiming attacks away 🔒 The Map-Server also derives a brand new OTK, the MS-OTK, which is passed to the ETR by applying a Key Derivation Function (KDF) (e.g., [RFC5869]) to the ITR-OTK.
  • The ETR uses the MS-OTK to compute an HMAC that protects the integrity of the Map-Reply sent to the ITR.
  • Finally, the ITR uses the stored ITR-OTK to verify the integrity of the mapping data provided by both the Map-Server and the ETR, and to check that no overclaiming attacks were mounted along the path between the Map-Server and the ITR 👑

Section 6 has the full detailed breakdown of the LISP-SEC control messages and how they get processed 📜 Meanwhile, the rest of this section walks through the flow of LISP protocol operations at each entity in the Map-Request/Map-Reply exchange:

  1. The ITR, when it needs to transmit a Map-Request message, generates and stores an OTK (ITR-OTK). This ITR-OTK is encrypted and included in the Encapsulated Control Message (ECM) that contains the Map-Request sent to the Map-Resolver 🎀
  2. The Map-Resolver decapsulates the ECM, decrypts the ITR-OTK (if needed), and forwards the received Map-Request and the ITR-OTK through the Mapping System, as part of a new ECM. The LISP Mapping System then delivers the ECM to the appropriate Map-Server, as identified by the EID destination address of the Map-Request 🦋
  3. The Map-Server is configured with the location mappings and policy information for the ETR responsible for the EID destination address. Using that preconfigured information, the Map-Server, after decapsulating the ECM, finds the longest-match EID-Prefix that covers the requested EID in the received Map-Request. The Map-Server adds this EID-Prefix, together with an HMAC computed using the ITR-OTK, to a new ECM that contains the received Map-Request 🧚
  4. The Map-Server derives a new OTK, the MS-OTK, by applying a KDF to the ITR-OTK. This MS-OTK is included in the ECM that the Map-Server uses to forward the Map-Request to the ETR 🌸
  5. If the Map-Server is acting in proxy mode, as specified in [RFC9301], the ETR is not involved in generating the Map-Reply, so steps 6 and 7 get skipped. In this case, the Map-Server generates the Map-Reply on behalf of the ETR, as described in Section 6.7.2 🙈
  6. The ETR, upon receiving the ECM-Encapsulated Map-Request from the Map-Server, decrypts the MS-OTK (if needed), and originates a Map-Reply that contains the EID-to-RLOC mapping information as specified in [RFC9301] 💜
  7. The ETR computes an HMAC over the Map-Reply, keyed with the MS-OTK, to protect the integrity of the whole Map-Reply. The ETR also copies the EID-Prefix authorization data that the Map-Server included in the ECM-Encapsulated Map-Request into the Map-Reply message. Then the ETR sends the complete Map-Reply message to the requesting ITR 🫶
  8. The ITR, upon receiving the Map-Reply, uses the locally stored ITR-OTK to verify the integrity of the EID-Prefix authorization data that the Map-Server included in the Map-Reply. The ITR computes the MS-OTK by applying the same KDF (as specified in the ECM-Encapsulated Map-Reply) that the Map-Server used, and then verifies the integrity of the Map-Reply ✨

6. LISP-SEC Control Messages Details 🎀

LISP-SEC metadata that goes with a Map-Request gets transported inside the Encapsulated Control Message that contains that Map-Request 📦

LISP-SEC metadata that goes with the Map-Reply gets transported inside the Map-Reply itself 💌

These specs use an HMAC in various places (as described in the following). The HMAC function AUTH-HMAC-SHA-256-128 [RFC6234] MUST be supported in LISP-SEC implementations. LISP-SEC deployments SHOULD use the AUTH-HMAC-SHA-256-128 HMAC function, except when communicating with older implementations that only support AUTH-HMAC-SHA-1-96 [RFC2104] 🥹 Okay, that's the important part: AUTH-HMAC-SHA-256-128 is the one everyone has to support, and it's the one deployments should use, with the older-implementation exception.

6.1. Encapsulated Control Message LISP-SEC Extensions 🧩

LISP-SEC uses the ECM defined in [RFC9301] with the S-bit set to 1 to indicate that the LISP header includes Authentication Data (AD). The format of the LISP-SEC ECM AD is defined in Figure 1. OTK-AD stands for One-Time Key Authentication Data, and EID-AD stands for EID Authentication Data 🌈

  0                   1                   2                   3
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  ECM AD Type  |   Unassigned  |        Requested HMAC ID      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
 |              OTK Length       |     Key ID    | OTK Wrap. ID  | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 |                       One-Time-Key Preamble ...               | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD
 |                   ... One-Time-Key Preamble                   | |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 ~                      One-Time Key (128 bits)                  ~/
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |           EID-AD Length       |           KDF ID              |     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
 | Record Count  |E| Unassigned  |         EID HMAC ID           |EID-AD
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
 |  Unassigned   | EID mask-len  |           EID-AFI             | |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
 ~                          EID-Prefix ...                       ~ |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
 ~                            EID HMAC                           ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+

               Figure 1: LISP-SEC ECM Authentication Data

Here's what each field in there does 👀

  • ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 8.
  • Unassigned: Set to 0 on transmission and ignored on receipt.
  • Requested HMAC ID: The HMAC algorithm, which will be used to protect the mappings, requested by the ITR. Permitted values are registered in the LISP-SEC Authentication Data HMAC ID (see Section 8.3). Refer to Section 6.4 for more details.
  • OTK Length: The length (in bytes) of the OTK Authentication Data (OTK-AD), which contains the OTK Preamble and the OTK.
  • Key ID: The identifier of the pre-shared secret shared by an ITR and the Map-Resolver, and by the Map-Server and an ETR. Per-message keys are derived from the pre-shared secret to encrypt, authenticate the origin, and protect the integrity of the OTK. The Key ID allows rotation between multiple pre-shared secrets in a nondisruptive way 🔄
  • OTK Wrapping ID (OTK Wrap. ID): The identifier of the Key Derivation Function and of the key wrapping algorithm used to encrypt the One-Time-Key. Permitted values are registered in the LISP-SEC Authentication Data Key Wrap ID (see Section 8.4). Refer to Section 6.5 for more details.
  • One-Time-Key Preamble: Set to 0 if the OTK is not encrypted. When the OTK is encrypted, this field MAY carry additional metadata resulting from the key wrapping operation. When a 128-bit OTK is sent unencrypted by a Map-Resolver, the OTK Preamble is set to 0x0000000000000000 (64 bits). See Section 6.5.1 for details.
  • One-Time-Key: The OTK wrapped as specified by OTK Wrapping ID. See Section 6.5 for details.
  • EID-AD Length: Length (in bytes) of the EID Authentication Data (EID-AD). The ITR MUST set the EID-AD Length to 4 bytes, as it only fills the KDF ID field, and all the remaining fields part of the EID-AD are not present. An EID-AD MAY contain multiple EID-Records. Each EID-Record is 4 bytes long, plus the length of the AFI-encoded EID-Prefix 📏
  • KDF ID: Identifier of the Key Derivation Function used to derive the MS-OTK. Permitted values are registered in the LISP-SEC Authentication Data Key Derivation Function ID (see Section 8.5). Refer to Section 6.7 for more details.
  • Record Count: As defined in Section 5.2 of [RFC9301].
  • E: ETR-Cant-Sign bit. If this bit is set to 1, it signals to the ITR that at least one of the ETRs that is authoritative for the EID-Prefixes of this Map-Reply has not enabled LISP-SEC. Only a Map-Server can set this bit. See Section 6.7 for more details 🚩
  • Unassigned: Set to 0 on transmission and ignored on receipt.
  • EID HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the EID-AD. This field is filled by the Map-Server that computed the EID-Prefix HMAC. See Section 6.7.1 for more details.
  • EID mask-len: As defined in Section 5.2 of [RFC9301].
  • EID-AFI: As defined in Section 5.2 of [RFC9301].
  • EID-Prefix: As defined in Section 5.2 of [RFC9301].
  • EID HMAC: HMAC of the EID-AD computed and inserted by a Map-Server. See Section 6.7.1 for more details 🔐

6.2. Map-Reply LISP-SEC Extensions 💌

okay so LISP-SEC totally reuses the Map-Reply from [RFC9301] ✨, but it gets a glow-up: Type is set to 2 and the S-bit is set to 1, which basically means "hey, I come with Authentication Data (AD)! 💅" The layout of that LISP-SEC Map-Reply Authentication Data is in Figure 2. PKT-AD is the Packet Authentication Data that covers the Map-Reply payload, so it's giving full protection 🔒

  0                   1                   2                   3
  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  MR AD Type   |                Unassigned                     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |           EID-AD Length       |           KDF ID              |     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
 | Record Count  |   Unassigned  |         EID HMAC ID           |EID-AD
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
 |  Unassigned   | EID mask-len  |           EID-AFI             | |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
 ~                          EID-Prefix ...                       ~ |   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
 ~                            EID HMAC                           ~     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
 |         PKT-AD Length         |         PKT HMAC ID           |\
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
 ~                            PKT HMAC                           ~PKT-AD
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

            Figure 2: LISP-SEC Map-Reply Authentication Data

Here's the field tea, bestie ☕

  • MR AD Type: 1 (LISP-SEC Authentication Data). See Section 8. 🎀
  • EID-AD Length: Length (in bytes) of the EID-AD (see Section 6.1).
  • KDF ID: Identifier of the Key Derivation Function used to derive MS-OTK (see Section 6.1).
  • Record Count: The number of records in this Map-Reply message (see Section 6.1).
  • Unassigned: Set to 0 on transmission and ignored on receipt. 🫶
  • EID HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the EID-AD (see Section 6.1).
  • EID mask-len: Mask length for EID-Prefix (see Section 6.1).
  • EID-AFI: See Section 6.1.
  • EID-Prefix: See Section 6.1.
  • EID HMAC: See Section 6.1.
  • PKT-AD Length: Length (in bytes) of the Packet Authentication Data (PKT-AD).
  • PKT HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the Map-Reply (see Section 6.5). 🔥
  • PKT HMAC: HMAC of the whole Map-Reply packet to protect its integrity, including the LISP-SEC Authentication Data (from the 'Map-Reply Type' field to the 'PKT HMAC' field), which allow message authentication. this one is the main character 👑

6.3. Map-Register LISP-SEC Extensions 📝

The S-bit in the Map-Register message (see [RFC9301]) tells the Map-Server that the registering ETR is LISP-SEC enabled. An ETR that supports LISP-SEC MUST set the S-bit in its Map-Register messages. No cap, that's the whole vibe 💖

6.4. ITR Processing: Generating a Map-Request 🧚

okay so when an ITR creates a Map-Request, it generates a random ITR-OTK 🎲 and stores it locally until the matching Map-Reply shows up (see Section 6.9). It keeps that ITR-OTK together with the nonce made the usual way from [RFC9301] 🌸

The ITR MAY use the 'KDF ID' field to flag its recommended KDF algorithm based on local policy. The Map-Server can overwrite the KDF ID if it doesn't support the one the ITR recommended (see Section 6.7). A KDF value of NOPREF (0) may be used to say the ITR has no preferred KDF ID, so it's totally flexible 🦋

ITR-OTK confidentiality and integrity protection MUST be provided in the path between the ITR and the Map-Resolver. You can get that either by encrypting the ITR-OTK with the pre-shared secret the ITR and the Map-Resolver both know (see Section 6.5), or by turning on DTLS [RFC9147] between the ITR and the Map-Resolver. Pick your fighter 🥊

The Map-Request (as defined in [RFC9301]) MUST be encapsulated as a LISP Control Message in an ECM, with the S-bit set to 1, to show that Authentication Data is present. We call that a "Protected Map-Request" in this memo 🔐

The ITR-OTK gets wrapped with the algorithm named in the 'OTK Wrapping ID' field. Check Section 6.5 for the deets on OTK encryption. Now, if NULL-KEY-WRAP-128 (see Section 8.4) is picked, and no other encryption (like DTLS) is turned on in the path between the ITR and the Map-Resolver, the Map-Request MUST be dropped, and an appropriate log action SHOULD be taken. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. Protect your logs, babe 🚨

The 'Requested HMAC ID' field holds the suggested HMAC algorithm that the Map-Server and the ETR should use to protect the integrity of the ECM Authentication Data and of the Map-Reply. A HMAC ID value of NONE (0) MAY be used to say the ITR has no preferred HMAC ID 💅

The 'KDF ID' field gives the suggested Key Derivation Function for the Map-Server to use when deriving the MS-OTK. A KDF value of NONE (0) may be used to say the ITR has no preference ✨

The EID-AD Length is set to 4 bytes, because the Authentication Data doesn't include any EID-Prefix Authentication Data, and the EID-AD only contains the 'KDF ID' field. Small and efficient, iconic 🍓

If the ITR is directly connected to a Mapping System, like LISP+ALT [RFC6836], it does double duty as both the ITR and the Map-Resolver, forwarding the Protected Map-Request as described in Section 6.6. Multitasking queen 👑

PITRs (Proxy ITRs) do the same job as an ITR, so the procedure above applies to them too 🫶

6.5. Encrypting and Decrypting an OTK 🔐

MS-OTK confidentiality and integrity protection MUST be provided in the path between the Map-Server and the ETR. You can do that by enabling DTLS between the Map-Server and the ETR, or by encrypting the MS-OTK with the pre-shared secret the Map-Server and the ETR share [RFC9301]. 🦋

Similarly, ITR-OTK confidentiality and integrity protection MUST be provided in the path between the ITR and the Map-Resolver. You can do that by enabling DTLS between the Map-Server and the ITR, or by encrypting the ITR-OTK with the pre-shared secret the ITR and the Map-Resolver share. The ITR/Map-Resolver pre-shared key is kinda like the Map-Server/ETR pre-shared key, just a different secret 🌈

This section covers OTK processing in both the ITR/Map-Resolver path and the Map-Server/ETR path, so we're covering all the bases 💜

It's really important to note that, to prevent ETR's overclaiming attacks, the ITR/Map-Resolver pre-shared secret MUST be independent from the Map-Server/ETR pre-shared secret. Do NOT reuse the same secret, that's a whole disaster 💀

The OTK is wrapped using the algorithm named in the 'OTK Wrapping ID' field. This field identifies both:

  • Key Encryption Algorithm used to encrypt the wrapped OTK, and
  • Key Derivation Function used to derive a per-message encryption key.

Implementations of this specification MUST support the OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256. That one uses the HKDF-SHA256 Key Derivation Function from [RFC5869] to derive a per-message encryption key (per-msg-key), plus the AES-KEY-WRAP-128 key wrap algorithm from [RFC3394] to encrypt a 128-bit OTK. Lowkey the main one 🔥

Implementations of this specification MUST support OTK Wrapping NULL-KEY-WRAP-128. NULL-KEY-WRAP-128 carries an unencrypted 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 bits). It's the no-frills option 🙈

The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256 goes like this:

  1. The KDF and key wrap algorithms are identified by the value of the 'OTK Wrapping ID' field. The initial values are documented in Table 5. 📋
  2. If the NULL-KEY-WRAP-128 algorithm (see Section 8.4) is selected and DTLS is not enabled, the Map-Request MUST be dropped and an appropriate log action SHOULD be taken. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. 🚨
  3. The pre-shared secret used to derive the per-msg-key is represented by PSK[Key ID], which is the pre-shared secret identified by the 'Key ID'. 🗝️
  4. The 128-bit-long per-message encryption key is computed as:
per-msg-key = KDF( nonce + s + PSK[Key ID] )

where the nonce is the value in the 'Nonce' field of the Map-Request, 's' is the string "OTK-Key-Wrap", and the operation '+' just means string concatenation. ✨

  1. The per-msg-key is then used to wrap the OTK with AES-KEY-WRAP-128, as specified in Section 2.2.1 of [RFC3394]. The AES Key Wrap Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the AES key wrap operation is 192 bits long. The most significant 64 bits get copied into the 'One-Time Key Preamble' field, while the 128 least significant bits get copied into the 'One-Time Key' field of the LISP-SEC Authentication Data. Math is serving 🧮

When decrypting an encrypted OTK, the receiver MUST verify that the Initialization Value from the AES key wrap decryption operation is equal to 0xA6A6A6A6A6A6A6A6. If that check fails, the receiver MUST discard the entire message. No second chances 🙅‍♀️

6.5.1. Unencrypted OTK 🌸

However, when DTLS is enabled, the OTK MAY be sent unencrypted, since transport layer security is already handling confidentiality and integrity protection. Transport layer security has got you covered 🫶

When a 128-bit OTK is sent unencrypted, the OTK Wrapping ID is set to NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 (64 bits). Simple, clean, no drama 🍓

6.6. Map-Resolver Processing 🧭

Upon receiving a Protected Map-Request, the Map-Resolver decapsulates the ECM. If the ITR-OTK is encrypted, the Map-Resolver decrypts it as specified in Section 6.5. 🔓

How the ITR-OTK's confidentiality is protected, and generally how safely the Map-Resolver hands the Map-Request over to the Map-Server, depends on the particular Mapping System being used. That stuff is outside the scope of this memo, so it's not on us 🙃

In Mapping Systems where the Map-Server is compliant with [RFC9301], the Map-Resolver originates a new ECM header with the S-bit set. That header carries the unencrypted ITR-OTK, as specified in Section 6.5, plus the other data derived from the ECM Authentication Data of the received Encapsulated Map-Request. Glow-up energy ✨

The Map-Resolver then forwards the received Map-Request to the Map-Server, wrapped in that new ECM header, which includes the newly computed 'Authentication Data' fields. And that's the whole journey, bestie 🦋💖

6.7. Map-Server Processing ✨

okay so when a Protected Map-Request shows up, the Map-Server doesn't just vibe with it 💅 It checks the S-bit and the P-bit that the ETRs authoritative for that prefix set in their Map-Register, and then it decides what to do. here's the whole decision tree 🌸

While processing the Map-Request, the Map-Server can overwrite the KDF ID field if it doesn't support the KDF ID the ITR recommended 🔥 Processing of the Map-Request MUST proceed in the order described in the table below, and it applies the process for the first rule whose conditions match the first column:

    +=================+==============================================+
    | Matching        | Processing                                   |
    | Condition       |                                              |
    +=================+==============================================+
    | 1.  At least    | The Map-Server MUST generate a LISP-SEC-     |
    | one of the ETRs | protected Map-Reply, as specified in         |
    | authoritative   | Section 6.7.2.  The ETR-Cant-Sign E-bit in   |
    | for the EID-    | the EID Authentication Data (EID-AD) MUST be |
    | Prefix included | set to 0.                                    |
    | in the Map-     |                                              |
    | Request         |                                              |
    | registered with |                                              |
    | the P-bit set   |                                              |
    | to 1            |                                              |
    +-----------------+----------------------------------------------+
    | 2.  At least    | The Map-Server MUST generate a LISP-SEC-     |
    | one of the ETRs | protected Encapsulated Map-Request (as       |
    | authoritative   | specified in Section 6.7.1) to be sent to    |
    | for the EID-    | one of the authoritative ETRs that           |
    | Prefix included | registered with the S-bit set to 1 (and the  |
    | in the Map-     | P-bit set to 0).  If there is at least one   |
    | Request         | ETR that registered with the S-bit set to 0, |
    | registered with | the ETR-Cant-Sign E-bit of the EID-AD MUST   |
    | the S-bit set   | be set to 1 to signal the ITR that a non-    |
    | to 1            | LISP-SEC Map-Request might reach additional  |
    |                 | ETRs that have LISP-SEC disabled.            |
    +-----------------+----------------------------------------------+
    | 3.  All the     | The Map-Server MUST send a Negative Map-     |
    | ETRs            | Reply protected with LISP-SEC, as described  |
    | authoritative   | in Section 6.7.2.  The ETR-Cant-Sign E-bit   |
    | for the EID-    | MUST be set to 1 to signal the ITR that a    |
    | Prefix included | non-LISP-SEC Map-Request might reach         |
    | in the Map-     | additional ETRs that have LISP-SEC disabled. |
    | Request         |                                              |
    | registered with |                                              |
    | the S-bit set   |                                              |
    | to 0            |                                              |
    +-----------------+----------------------------------------------+

                 Table 1: Map-Request Processing

so the ITR that sent a LISP-SEC-protected Map-Request always gets a LISP-SEC-protected Map-Reply back 🫶 However, an ETR-Cant-Sign E-bit set to 1 is basically a heads-up that a non-LISP-SEC Map-Request might reach additional ETRs with LISP-SEC disabled 👀 This mechanism lets the ITR downgrade to non-LISP-SEC requests, and that does NOT protect against the threats described in Section 4.

⚠️ bestie, read that last bit twice. The downgrade path is a real gap, not a footnote 😭

6.7.1. Generating a LISP-SEC-Protected Encapsulated Map-Request

okay the Map-Server decapsulates the ECM and makes brand new ECM Authentication Data 🦋 That Authentication Data holds the OTK-AD and the EID-AD, and the EID-AD carries the EID-Prefix authorization info that the requesting ITR eventually gets.

The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from the ITR-OTK it got with the Map-Request. MS-OTK comes from whatever Key Derivation Function is named in the KDF ID field 🧚 If that algorithm isn't supported, the Map-Server uses a different one to derive the key and then updates the KDF ID field to match.

The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data 💜

MS-OTK gets wrapped with whatever algorithm the OTK Wrapping ID field names. See Section 6.5 for the full OTK encryption details 🎀 Now the spicy part: if the NULL-KEY-WRAP-128 algorithm is selected and DTLS is NOT enabled on the path between the Map-Server and the ETR, the Map-Request MUST be dropped, and an appropriate log action SHOULD be taken 💀

For the EID-AD, the Map-Server puts in the longest-match-registered EID-Prefix for the destination EID, plus an HMAC of that EID-Prefix ✨ The HMAC is keyed with the ITR-OTK from the received ECM Authentication Data, and the algorithm is picked by the Requested HMAC ID field. If the Map-Server doesn't support that algorithm, it uses a different one and says so in the EID HMAC ID field. The HMAC scope MUST cover the entire EID-AD, from the EID-AD Length field all the way to the EID HMAC field, and EID HMAC MUST be set to 0 before the computation 🔥

Last step: the Map-Server forwards the updated ECM-Encapsulated Map-Request, carrying the OTK-AD, the EID-AD, and the received Map-Request, to an authoritative ETR as specified in [RFC9301] 🌈

6.7.2. Generating a Proxy Map-Reply

A LISP-SEC proxy Map-Reply gets generated according to [RFC9301], with the Map-Reply S-bit set to 1 🌸 The Map-Reply's Authentication Data holds the EID-AD computed in Section 6.7.1, plus the PKT-AD computed in Section 6.8. main character energy, honestly 👑

6.8. ETR Processing

When an ECM-Encapsulated Map-Request with the S-bit set comes in, the ETR decapsulates the ECM 🍓 If the OTK field is encrypted, the ETR decrypts it as specified in Section 6.5 to get the unencrypted MS-OTK.

Then the ETR generates a Map-Reply as specified in [RFC9301] and includes the Authentication Data with the EID-AD (exactly as it arrived in the Encapsulated Map-Request) and the PKT-AD 🦋

The EID-AD gets copied straight from the Authentication Data of the received Encapsulated Map-Request, no edits 🫶

The PKT-AD is the HMAC of the whole Map-Reply packet, keyed with the MS-OTK and computed with the HMAC algorithm named in the Requested HMAC ID field of the received Encapsulated Map-Request 🔥 If the ETR doesn't support that Requested HMAC ID, it uses a different algorithm and updates the PKT HMAC ID field to match. The HMAC operation MUST cover the entire Map-Reply, and the PKT HMAC field MUST be set to 0 before the computation 💅

Finally, the ETR sends the Map-Reply to the requesting ITR as specified in [RFC9301] ✨

6.9. ITR Processing: Receiving a Map-Reply

So the ITR is waiting on a Protected Map-Request, and it expects a Map-Reply with the S-bit set to 1 that includes an EID-AD and a PKT-AD 👀 Anything else? The ITR MUST discard the Map-Reply, no debate 🙅‍♀️

When a Map-Reply lands, the ITR must verify the integrity of BOTH the EID-AD and the PKT-AD, and it MUST discard the Map-Reply if either integrity check fails 😭 After it's done processing, the ITR MUST discard the <nonce,ITR-OTK> pair tied to that Map-Reply. clean up your room, bestie 🧹

Checking the EID-AD: the ITR uses its locally stored ITR-OTK (kept around for the length of this exchange) to recompute the HMAC of the EID-AD with the algorithm named in the EID HMAC ID field 🦋 Here's where things can go sideways. If the ITR DID indicate a Requested HMAC ID in the Map-Request, and the PKT HAMC ID in the matching Map-Reply is different, OR the ITR did NOT indicate a Requested HMAC ID and the PKT HMAC ID in the matching Map-Reply isn't supported, then the ITR MUST discard the Map-Reply and send a new Map-Request with a different Requested HMAC ID field, following the rate-limitation policies in [RFC9301] and the ITR's local policy. The HMAC scope covers the entire EID-AD, from the EID-AD Length field to the EID HMAC field 🌈

ITR MUST set the EID HMAC ID field to 0 before computing the HMAC ✨

Now the PKT-AD. First, the MS-OTK gets derived from the locally stored ITR-OTK using the algorithm in the KDF ID field, because the ETR generated the PKT-AD using the MS-OTK 🧚 If the ITR DID recommend a KDF ID and the KDF ID in the Map-Reply is different, OR the ITR did NOT recommend one and the KDF ID in the Map-Reply isn't supported, then the ITR MUST discard the Map-Reply and send a new Map-Request with a different KDF ID, following the rate-limitation policies in [RFC9301] and its local policy. The Key Derivation Function HKDF-SHA256 MUST be supported in LISP-SEC implementations 💜 LISP-SEC deployments SHOULD use the HKDF-SHA256 HKDF function, unless older implementations using HKDF-SHA1-128 are present in the same deployment. Mixed configs can add extra delays, but since HKDF-SHA1-128 and HKDF-SHA256 are both supported, things will eventually converge 🌸

Then the derived MS-OTK recomputes the HMAC of the PKT-AD with the algorithm named in the PKT HMAC ID field 🔥 If PKT HMAC ID doesn't match the Requested HMAC ID, the ITR MUST discard the Map-Reply and send a new Map-Request with a different Requested HMAC ID, following rate-limitation policies in [RFC9301] and the ITR's local policy, or keep going until it has tried every HMAC ID it supports. When PKT HMAC ID doesn't match the Requested HMAC ID, the Map-Reply just can't be validated 💀

A Map-Reply EID-Record only counts as valid if (1) both the EID-AD and the PKT-AD are valid AND (2) the intersection of the Map-Reply EID-Record's EID-Prefix with one of the EID-Prefixes in the EID-AD isn't empty 🎀 Once a record is valid, the ITR sets its EID-Prefix to that intersection result and adds the record to its EID-to-RLOC Map-Cache, as described in [RFC9301]. There's an example of Map-Reply record validation in Section 6.9.1 🦋

[RFC9301] lets ETRs send Solicit-Map-Requests (SMRs) straight to the ITR 🫶 The SMR-invoked Map-Request goes through the Mapping System, so it gets secured by this memo's specs if they're in use. And if an ITR accepts Map-Replies piggybacked in Map-Requests and that content isn't already in its EID-to-RLOC Map-Cache, it MUST send a Map-Request over the Mapping System to verify the content with a secured Map-Reply before using it 🔐 no shortcuts, periodt 💅

6.9.1. Map-Reply Record Validation 🧚

Okay so a Map-Reply's payload can hold multiple EID-Records 📦. The whole Map-Reply gets signed by the ETR with the PKT HMAC 🔐, which gives integrity protection and origin authentication to the EID-Prefix records the ETR is claiming. Then the Authentication Data field can carry multiple EID-Records in the EID-AD, and the Map-Server signs that with the EID HMAC 💅. That covers integrity and origin authentication for the EID-Prefix records the Map-Server put in there. Two signatures, two different jobs, bestie 🫶.

When an ITR gets a Map-Reply with the S-bit set, it checks both the EID HMAC and the PKT-AD HMAC first 👀. If either one of them isn't valid, a log action SHOULD be taken and the Map-Reply MUST NOT be processed any further 💀. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.

If both HMACs are valid, the ITR moves on to checking each EID-Record the ETR claimed. It does this by computing the intersection of every EID-Prefix in the Map-Reply payload with every EID-Prefix in the EID-AD. An EID-Record is valid only if at least one of those intersections is not the empty set. Otherwise, a log action MUST be taken and the EID-Record MUST be discarded 🚫. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.

Let's walk through an example, because this is where it gets iconic ✨. Say the Map-Reply payload has 3 mapping record EID-Prefixes:

2001:db8:102::/48

2001:db8:103::/48

2001:db8:200::/40

And the EID-AD has two EID-Prefixes:

2001:db8:103::/48

2001:db8:203::/48

The first record, 2001:db8:102::/48, is not eligible for the ITR to use, since it isn't included in any of the EID-ADs signed by the Map-Server 🙅‍♀️. A log action MUST be taken, and the EID-Record MUST be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.

The record for 2001:db8:103::/48 is eligible to be used by the ITR, because it matches the second EID-Prefix in the EID-AD 🎀.

The record for 2001:db8:200::/40 is not eligible to be used by the ITR either, since it isn't included in any of the EID-ADs signed by the Map-Server. A log action MUST be taken and the EID-Record MUST be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. In this last example, the ETR is trying to overclaim 2001:db8:200::/40 😤, but the Map-Server only authorized 2001:db8:203::/48, so that record gets tossed.

7. Security Considerations 🛡️

This document extends the LISP control plane defined in [RFC9301], so its security considerations apply here too, no cap 🧢.

7.1. Mapping System Security

The LISP-SEC threat model described in Section 4 assumes that the LISP Mapping System is working properly and delivers Map-Request messages to a Map-Server that is authoritative for the requested EID.

It's assumed that the Mapping System keeps the OTK confidential and the Map-Reply data intact 🔒. However, how the LISP Mapping System is secured is out of scope for this document.

Similarly, Map-Register security is out of scope for LISP-SEC. That includes the right for a LISP entity to register an EID-Prefix or to claim presence at an RLOC 🌸.

7.2. Random Number Generation

The ITR-OTK MUST be generated by a properly seeded pseudo-random (or strong random) source. See [RFC4086] for advice on generating security-sensitive random data 🎲.

7.3. Map-Server and ETR Colocation

If the Map-Server and the ETR are colocated, LISP-SEC does not protect against overclaiming attacks mounted by the ETR 😬. However, in this case the ETR sits inside the trust boundaries of the Map-Server, so ETR overclaiming attacks aren't part of the threat model. Iykyk 🙈.

7.4. Deploying LISP-SEC

Anyone deploying LISP-SEC according to this memo should carefully weigh how the LISP-SEC threat model applies to their particular use case or deployment 🧐. If they decide to ignore a particular recommendation, they should make sure the risk tied to the corresponding threats is well understood.

For example, in some other deployments, attackers may be very sophisticated, and deployers may have to enforce really strict policies on which HMAC algorithms an ITR accepts 🔥.

The same considerations apply to the whole LISP-SEC threat model, and they should guide deployers and implementors whenever they run into the key word SHOULD across this memo 💜.

7.5. Shared Keys Provisioning

Provisioning of the keys shared between ITR and Map-Resolver pairs, and between ETR and Map-Server pairs, should be done via an orchestration infrastructure. That's out of scope for this memo ⭐. It is recommended that both shared keys be refreshed at periodic intervals, to deal with key aging or with attackers getting unauthorized access to the shared keys. Shared keys should be unpredictable random values 🎀.

7.6. Replay Attacks

An attacker can capture a valid Map-Request and/or Map-Reply and replay it. However, once the ITR receives the original Map-Reply, the <nonce,ITR-OTK> pair stored at the ITR gets discarded 🗑️. If a replayed Map-Reply shows up at the ITR, there's no matching <nonce,ITR-OTK> for it, so the replayed Map-Reply gets discarded too.

For a replayed Map-Request, the Map-Server, Map-Resolver, and ETR will have to do a LISP-SEC computation. In terms of resources, that's equivalent to a valid LISP-SEC computation. Beyond the risk of a DoS attack, an attacker gets no additional effect, since the corresponding Map-Reply is discarded as explained above 🙄.

7.7. Message Privacy

DTLS [RFC9147] SHOULD be used (conforming to [RFC7525]) to provide communication privacy and to prevent eavesdropping, tampering, or message forgery between the ITR, Map-Resolver, Map-Server, and ETR 🔐, unless the OTK is encrypted another way, e.g., using a pre-shared secret. DTLS has the responder be verified by the initiator, which enables an ITR to authenticate the Map-Resolver and the Map-Server to authenticate the responding ETR 🦋.

7.8. Denial-of-Service and Distributed Denial-of-Service Attacks

LISP-SEC mitigates DoS and DDoS risks in two ways. It protects the integrity of Map-Request/Map-Reply messages and authenticates where they come from. It also stops malicious ETRs from overclaiming EID-Prefixes that could redirect traffic meant for a potentially huge number of hosts 🚨. Main character protection, honestly 👑.

8. IANA Considerations 🌈

IANA has created the subregistries listed in the following sections in the "Locator/ID Separation Protocol (LISP) Parameters" registry 📋.

For all of the subregistries, new values are assigned according to the Specification Required policy defined in [RFC8126]. Expert Review should assess the security properties of newly added functions, so that encryption robustness stays strong. For instance, at the time of writing, SHA-256-based functions are considered to provide sufficient protection. Consultation with security experts may be needed 🧠.

8.1. ECM AD Type Registry

IANA has created the "LISP ECM Authentication Data Types" registry with values 0-255, for use in the ECM LISP-SEC extensions (see Section 6.1). Initial allocations are shown in Table 2.

              +==================+========+============+
              | Name             | Number | Defined in |
              +==================+========+============+
              | Reserved         |   0    | RFC 9303   |
              +------------------+--------+------------+
              | LISP-SEC-ECM-EXT |   1    | RFC 9303   |
              +------------------+--------+------------+

                Table 2: LISP ECM Authentication Data
                                Types

Values 2-255 are unassigned 🌸.

8.2. Map-Reply AD Types Registry

IANA has created the "LISP Map-Reply Authentication Data Types" registry with values 0-255, for use in the Map-Reply LISP-SEC extensions (see Section 6.2). Initial allocations are shown in Table 3.

               +=================+========+============+
               | Name            | Number | Defined in |
               +=================+========+============+
               | Reserved        |   0    | RFC 9303   |
               +-----------------+--------+------------+
               | LISP-SEC-MR-EXT |   1    | RFC 9303   |
               +-----------------+--------+------------+

                   Table 3: Map-Reply Authentication
                               Data Types

Values 2-255 are unassigned 🍓.

8.3. HMAC Functions

IANA is requested to create the "LISP-SEC Preferred Authentication Data HMAC IDs" registry with values 0-65535, for use as Requested HMAC IDs, EID HMAC IDs, and PKT HMAC IDs in the LISP-SEC Authentication Data. Initial allocations are shown in Table 4.

            +=======================+========+============+
            | Name                  | Number | Defined in |
            +=======================+========+============+
            | NOPREF                |   0    | RFC 9303   |
            +-----------------------+--------+------------+
            | AUTH-HMAC-SHA-1-96    |   1    | [RFC2104]  |
            +-----------------------+--------+------------+
            | AUTH-HMAC-SHA-256-128 |   2    | [RFC6234]  |
            +-----------------------+--------+------------+

               Table 4: LISP-SEC Preferred Authentication
                             Data HMAC IDs

Values 3-65535 are unassigned 🧚.

8.4. Key Wrap Functions

IANA has created the "LISP-SEC Authentication Data Key Wrap IDs" registry with values 0-65535, for use as OTK key wrap algorithm IDs in the LISP-SEC Authentication Data. Initial allocations are shown in Table 5.

+==============================+======+=========+=========+=========+
| Name                         |Number|Key Wrap |KDF      |Reference|
+==============================+======+=========+=========+=========+
| Reserved                     |  0   |None     |None     |RFC 9303 |
+------------------------------+------+---------+---------+---------+
| NULL-KEY-WRAP-128            |  1   |RFC 9303 |None     |RFC 9303 |
+------------------------------+------+---------+---------+---------+
| AES-KEY-WRAP-128+HKDF-SHA256 |  2   |[RFC3394]|[RFC4868]|RFC 9303 |
+------------------------------+------+---------+---------+---------+

           Table 5: LISP-SEC Authentication Data Key Wrap IDs

Values 3-65535 are unassigned 💖.

8.5. Key Derivation Functions 🔑

okay so IANA made a registry called "LISP-SEC Authentication Data Key Derivation Function IDs" 📋 It has values 0-65535, and each one is a KDF ID. The starter entries are in Table 6 below 💅

                  +===============+========+===========+
                  | Name          | Number | Reference |
                  +===============+========+===========+
                  | NOPREF        |   0    |  RFC 9303 |
                  +---------------+--------+-----------+
                  | HKDF-SHA1-128 |   1    | [RFC5869] |
                  +---------------+--------+-----------+
                  | HKDF-SHA256   |   2    | [RFC5869] |
                  +---------------+--------+-----------+

                     Table 6: LISP-SEC Authentication
                     Data Key Derivation Function IDs

Values 3-65535 are unassigned, so they're just sitting there waiting for their moment ✨🦋

9. References 📚

9.1. Normative References 🫶

Bestie, these are the references the spec leans on hard. Read them like homework you actually want to do 🤓

[RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
           Hashing for Message Authentication", RFC 2104,
           DOI 10.17487/RFC2104, February 1997,
           <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3394]  Schaad, J. and R. Housley, "Advanced Encryption Standard
           (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
           September 2002, <https://www.rfc-editor.org/info/rfc3394>.

[RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-
           384, and HMAC-SHA-512 with IPsec", RFC 4868,
           DOI 10.17487/RFC4868, May 2007,
           <https://www.rfc-editor.org/info/rfc4868>.

[RFC5869]  Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
           Key Derivation Function (HKDF)", RFC 5869,
           DOI 10.17487/RFC5869, May 2010,
           <https://www.rfc-editor.org/info/rfc5869>.

[RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
           (SHA and SHA-based HMAC and HKDF)", RFC 6234,
           DOI 10.17487/RFC6234, May 2011,
           <https://www.rfc-editor.org/info/rfc6234>.

[RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
           "Recommendations for Secure Use of Transport Layer
           Security (TLS) and Datagram Transport Layer Security
           (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
           2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC7835]  Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
           Separation Protocol (LISP) Threat Analysis", RFC 7835,
           DOI 10.17487/RFC7835, April 2016,
           <https://www.rfc-editor.org/info/rfc7835>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
           Datagram Transport Layer Security (DTLS) Protocol Version
           1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
           <https://www.rfc-editor.org/info/rfc9147>.

[RFC9300]  Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A.
           Cabellos, Ed., "The Locator/ID Separation Protocol
           (LISP)", RFC 9300, DOI 10.17487/RFC9300, October 2022,
           <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301]  Farinacci, D., Maino, F., Fuller, V., and A. Cabellos,
           Ed., "Locator/ID Separation Protocol (LISP) Control
           Plane", RFC 9301, DOI 10.17487/RFC9301, October 2022,
           <https://www.rfc-editor.org/info/rfc9301>.

9.2. Informative References 🌸

These ones are the extra reading. Good for context, not required for the main plot 💜

[RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
           "Randomness Requirements for Security", BCP 106, RFC 4086,
           DOI 10.17487/RFC4086, June 2005,
           <https://www.rfc-editor.org/info/rfc4086>.

[RFC6836]  Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
           "Locator/ID Separation Protocol Alternative Logical
           Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
           January 2013, <https://www.rfc-editor.org/info/rfc6836>.

Acknowledgments 🎀

The authors gave a huge shoutout to Luigi Iannone, Pere Monclus, Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis, and Landon Curt Noll 🫶 Their suggestions made this document so much better, and they're literally the reason it slays 👑

Authors' Addresses 💌

Fabio Maino
Cisco Systems
San Jose, CA
United States of America
Email: fmaino@cisco.com


Vina Ermagan
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: ermagan@gmail.com


Albert Cabellos
Universitat Politecnica de Catalunya
c/ Jordi Girona s/n
08034 Barcelona
Spain
Email: acabello@ac.upc.edu


Damien Saucez
Inria
2004 route des Lucioles - BP 93
Sophia Antipolis
France
Email: damien.saucez@inria.fr
📦 where this page comes from