Locator/ID Separation Protocol Security (LISP-SEC)
Extracted elements (29)
LISP-SEC uses two independent pre-shared secrets—one between ITR/Map-Resolver and one between Map-Server/ETR—so that a malicious ETR that knows only the MS/ETR secret cannot forge or manipulate the EID-AD computed by the Map-Server using the ITR-OTK, thereby preventing overclaiming attacks.
Map-Register/Map-Notify security is explicitly out of scope for LISP-SEC because those exchanges are already protected by the security mechanisms in RFC 9301. LISP-SEC focuses solely on the Map-Request/Map-Reply lookup path, where RFC 9301 nonce protection is insufficient against on-path overclaiming attacks.
The per-message OTK derivation chain (ITR-OTK → MS-OTK via KDF) enables the ITR to independently verify both the Map-Server's EID-Prefix authorization (via EID-AD signed with ITR-OTK) and the ETR's Map-Reply integrity (via PKT-AD signed with MS-OTK), using only the single locally stored ITR-OTK.
If the Map-Server does not support the KDF ID recommended by the ITR, it may overwrite the KDF ID field and use a different supported algorithm. Similarly, if the ETR does not support the Requested HMAC ID, it uses a different algorithm and updates the PKT HMAC ID field.
When an ITR specifies a Requested HMAC ID in its Map-Request but the Map-Reply returns a different PKT HMAC ID, the ITR MUST discard the Map-Reply and send a new Map-Request with a different Requested HMAC ID; this negotiation repeats until a mutually supported algorithm is found or all supported IDs are exhausted.
After processing a Map-Reply, the ITR MUST discard the <nonce, ITR-OTK> pair associated with that exchange, preventing replay attacks by ensuring a replayed Map-Reply finds no matching OTK.
An ETR that supports LISP-SEC MUST set the S-bit in its Map-Register messages to signal to the Map-Server that it is LISP-SEC enabled.
If the NULL-KEY-WRAP-128 algorithm is selected and no DTLS (or other encryption mechanism) is enabled between the ITR and the Map-Resolver, the Map-Request MUST be dropped and an appropriate log action SHOULD be taken.
Implementations MUST support OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256, which uses HKDF-SHA256 to derive a per-message encryption key and AES-KEY-WRAP-128 (per RFC 3394) to encrypt the 128-bit OTK. Implementations MUST also support NULL-KEY-WRAP-128 for unencrypted OTK transport.
ITR-OTK confidentiality and integrity MUST be provided in the path between the ITR and the Map-Resolver, either by encrypting the ITR-OTK with the ITR/Map-Resolver pre-shared secret or by enabling DTLS between the ITR and Map-Resolver.
MS-OTK confidentiality and integrity MUST be provided in the path between the Map-Server and the ETR, either via DTLS or by encrypting the MS-OTK with the Map-Server/ETR pre-shared secret.
The AES Key Wrap Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits) when wrapping the OTK. When decrypting, the receiver MUST verify this value and MUST discard the entire message if verification fails.
The HMAC function AUTH-HMAC-SHA-256-128 MUST be supported in all LISP-SEC implementations. Deployments SHOULD use AUTH-HMAC-SHA-256-128, except when communicating with older implementations that only support AUTH-HMAC-SHA-1-96.
The HMAC scope for EID-AD integrity MUST cover the entire EID-AD from the 'EID-AD Length' field to the 'EID HMAC' field (set to 0 before computation); the HMAC scope for PKT-AD MUST cover the entire Map-Reply with 'PKT HMAC' set to 0 before computation.
The ITR MUST verify the integrity of both the EID-AD and PKT-AD and MUST discard the Map-Reply if either integrity check fails. Each EID-Record is valid only if its EID-Prefix intersects with at least one EID-Prefix in the EID-AD; overclaiming records MUST be discarded.
The ITR-OTK MUST be generated by a properly seeded pseudo-random or strong random source per RFC 4086. A new ITR-OTK must be generated for each Map-Request and used for only a single Map-Request/Map-Reply exchange.
The Key Derivation Function HKDF-SHA256 MUST be supported in LISP-SEC implementations. Deployments SHOULD use HKDF-SHA256 unless older implementations using HKDF-SHA1-128 are present.
The Map-Request MUST be encapsulated as a LISP ECM with the S-bit set to 1 to indicate the presence of Authentication Data (a 'Protected Map-Request'). The ITR MUST discard any Map-Reply received without the S-bit set in response to a Protected Map-Request.
To prevent ETR overclaiming attacks, the ITR/Map-Resolver pre-shared secret MUST be independent from the Map-Server/ETR pre-shared secret.
LISP-SEC uses a per-exchange One-Time Key (OTK) scheme: the ITR generates an ITR-OTK, the Map-Server derives an MS-OTK from it via a KDF, and the ETR uses the MS-OTK to HMAC-protect the Map-Reply. This two-layer key derivation ensures the Map-Server can authorize the EID-Prefix while the ETR independently authenticates the Map-Reply payload.
The ETR-Cant-Sign E-bit in the EID Authentication Data, when set to 1 by the Map-Server, signals to the ITR that at least one authoritative ETR for the requested EID-Prefix has not enabled LISP-SEC. This allows the ITR to decide whether to downgrade to a non-LISP-SEC Map-Request.
IANA created five new subregistries in 'Locator/ID Separation Protocol (LISP) Parameters': (1) LISP ECM Authentication Data Types (0–255, value 1 = LISP-SEC-ECM-EXT), (2) LISP Map-Reply Authentication Data Types (0–255, value 1 = LISP-SEC-MR-EXT), (3) LISP-SEC Preferred Authentication Data HMAC IDs (0–65535), (4) LISP-SEC Authentication Data Key Wrap IDs (0–65535), and (5) LISP-SEC Authentication Data Key Derivation Function IDs (0–65535). All use Specification Required policy.
DTLS (RFC 9147, conforming to RFC 7525) SHOULD be used for all communication between ITR, Map-Resolver, Map-Server, and ETR to provide privacy and prevent eavesdropping, tampering, or message forgery unless the OTK is encrypted via a pre-shared secret.
If the Map-Server and ETR are colocated, LISP-SEC does not protect against overclaiming attacks mounted by the ETR, as the ETR is within the Map-Server's trust boundary. Deployments relying on this protection must ensure Map-Server and ETR separation.
Replay attack protection relies on the ITR discarding the <nonce, ITR-OTK> pair after processing the original Map-Reply. A replayed Map-Reply will find no matching OTK and be dropped. A replayed Map-Request forces LISP-SEC computation at Map-Server/ETR but yields no useful result to the attacker since the corresponding Map-Reply is discarded.
Shared keys between ITR/Map-Resolver and between Map-Server/ETR should be provisioned via an orchestration infrastructure, refreshed at periodic intervals to address key aging, and must be unpredictable random values. Key provisioning is out of scope for LISP-SEC.
Map-Server processing follows a priority-ordered table: (1) if any ETR registered with P-bit=1, generate a LISP-SEC proxy Map-Reply with E-bit=0; (2) if any ETR registered with S-bit=1 and P-bit=0, forward a LISP-SEC Encapsulated Map-Request to an S-bit ETR, setting E-bit=1 if any ETR has S-bit=0; (3) if all ETRs registered with S-bit=0, send a Negative Map-Reply with E-bit=1.
The LISP-SEC ECM Authentication Data consists of a fixed header with ECM AD Type (8 bits), Requested HMAC ID (16 bits), followed by OTK-AD containing OTK Length (16 bits), Key ID (8 bits), OTK Wrapping ID (8 bits), One-Time-Key Preamble (64 bits), and One-Time Key (128 bits), then EID-AD containing EID-AD Length, KDF ID, Record Count, E-bit, EID HMAC ID, per-record EID mask-len/AFI/Prefix, and EID HMAC.
The LISP-SEC Map-Reply Authentication Data contains MR AD Type (8 bits), EID-AD (with EID-AD Length, KDF ID, Record Count, EID HMAC ID, per-record EID mask-len/AFI/Prefix, and EID HMAC), and PKT-AD (PKT-AD Length, PKT HMAC ID, PKT HMAC covering the entire Map-Reply packet).