<?xmlversion="1.0" encoding="US-ASCII"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="3"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>version='1.0' encoding='utf-8'?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-lisp-sec-29"ipr="trust200902">indexInclude="true" ipr="trust200902" number="9303" prepTime="2022-10-19T14:23:12" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en"> <link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-sec-29" rel="prev"/> <link href="https://dx.doi.org/10.17487/rfc9303" rel="alternate"/> <link href="urn:issn:2070-1721" rel="alternate"/> <front> <titleabbrev="LISP-SEC">LISP-Securityabbrev="LISP-SEC">Locator/ID Separation Protocol Security (LISP-SEC)</title> <seriesInfo name="RFC" value="9303" stream="IETF"/> <author fullname="Fabio Maino"initials="F.M"initials="F" surname="Maino"><organization>Cisco<organization showOnFrontPage="true">Cisco Systems</organization> <address> <postal><street>170 Tasman Drive</street><street/> <city>San Jose</city><code>95134</code> <region>California</region> <country>USA</country><code/> <region>CA</region> <country>United States of America</country> </postal> <email>fmaino@cisco.com</email> </address> </author> <author fullname="Vina Ermagan"initials="V.E"initials="V" surname="Ermagan"><organization>Google</organization><organization showOnFrontPage="true">Google, Inc.</organization> <address> <postal><street/> <city/> <code/> <region>California</region> <country>USA</country><street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>United States of America</country> </postal> <email>ermagan@gmail.com</email> </address> </author> <author fullname="Albert Cabellos"initials="A.C"initials="A" surname="Cabellos"><organization>Universitat<organization showOnFrontPage="true">Universitat Politecnica de Catalunya</organization> <address> <postal> <street>c/ Jordi Girona s/n</street> <city>Barcelona</city> <code>08034</code> <region/> <country>Spain</country> </postal> <email>acabello@ac.upc.edu</email> </address> </author> <author fullname="Damien Saucez"initials="D.S"initials="D" surname="Saucez"><organization>Inria</organization><organization showOnFrontPage="true">Inria</organization> <address> <postal> <street>2004 route des Lucioles - BP 93</street> <city>Sophia Antipolis</city> <code/> <region/> <country>France</country> </postal> <email>damien.saucez@inria.fr</email> </address> </author> <date/> <area>Internet</area> <workgroup>Network Working Group</workgroup> <keyword>LISP; deployment</keyword> <abstract> <t>Thismonth="10" year="2022"/> <area>rtg</area> <workgroup>lisp</workgroup> <keyword>LISP</keyword> <keyword>deployment</keyword> <abstract pn="section-abstract"> <t indent="0" pn="section-abstract-1">This memo specifiesLISP-SEC,Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication,integrityintegrity, and anti-replay protection to the LISP'sEID-to-RLOCEndpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization onEID-prefixEID-Prefix claims in Map-Reply messages.</t> </abstract> <boilerplate> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1"> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name> <t indent="0" pn="section-boilerplate.1-1"> This is an Internet Standards Track document. </t> <t indent="0" pn="section-boilerplate.1-2"> 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. </t> <t indent="0" pn="section-boilerplate.1-3"> Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at <eref target="https://www.rfc-editor.org/info/rfc9303" brackets="none"/>. </t> </section> <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2"> <name slugifiedName="name-copyright-notice">Copyright Notice</name> <t indent="0" pn="section-boilerplate.2-1"> Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. </t> <t indent="0" pn="section-boilerplate.2-2"> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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. </t> </section> </boilerplate> <toc> <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1"> <name slugifiedName="name-table-of-contents">Table of Contents</name> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1"> <li pn="section-toc.1-1.1"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t> </li> <li pn="section-toc.1-1.2"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-notation">Requirements Notation</xref></t> </li> <li pn="section-toc.1-1.3"> <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-definitions-of-terms">Definitions of Terms</xref></t> </li> <li pn="section-toc.1-1.4"> <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-lisp-sec-threat-model">LISP-SEC Threat Model</xref></t> </li> <li pn="section-toc.1-1.5"> <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-operations">Protocol Operations</xref></t> </li> <li pn="section-toc.1-1.6"> <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-lisp-sec-control-messages-d">LISP-SEC Control Messages Details</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2"> <li pn="section-toc.1-1.6.2.1"> <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-encapsulated-control-messag">Encapsulated Control Message LISP-SEC Extensions</xref></t> </li> <li pn="section-toc.1-1.6.2.2"> <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-reply-lisp-sec-extensio">Map-Reply LISP-SEC Extensions</xref></t> </li> <li pn="section-toc.1-1.6.2.3"> <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-register-lisp-sec-exten">Map-Register LISP-SEC Extensions</xref></t> </li> <li pn="section-toc.1-1.6.2.4"> <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-itr-processing-generating-a">ITR Processing: Generating a Map-Request</xref></t> </li> <li pn="section-toc.1-1.6.2.5"> <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-encrypting-and-decrypting-a">Encrypting and Decrypting an OTK</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.5.2"> <li pn="section-toc.1-1.6.2.5.2.1"> <t indent="0" pn="section-toc.1-1.6.2.5.2.1.1"><xref derivedContent="6.5.1" format="counter" sectionFormat="of" target="section-6.5.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-unencrypted-otk">Unencrypted OTK</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.6.2.6"> <t indent="0" pn="section-toc.1-1.6.2.6.1"><xref derivedContent="6.6" format="counter" sectionFormat="of" target="section-6.6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-resolver-processing">Map-Resolver Processing</xref></t> </li> <li pn="section-toc.1-1.6.2.7"> <t indent="0" pn="section-toc.1-1.6.2.7.1"><xref derivedContent="6.7" format="counter" sectionFormat="of" target="section-6.7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-server-processing">Map-Server Processing</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.7.2"> <li pn="section-toc.1-1.6.2.7.2.1"> <t indent="0" pn="section-toc.1-1.6.2.7.2.1.1"><xref derivedContent="6.7.1" format="counter" sectionFormat="of" target="section-6.7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-a-lisp-sec-prote">Generating a LISP-SEC-Protected Encapsulated Map-Request</xref></t> </li> <li pn="section-toc.1-1.6.2.7.2.2"> <t indent="0" pn="section-toc.1-1.6.2.7.2.2.1"><xref derivedContent="6.7.2" format="counter" sectionFormat="of" target="section-6.7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-generating-a-proxy-map-repl">Generating a Proxy Map-Reply</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.6.2.8"> <t indent="0" pn="section-toc.1-1.6.2.8.1"><xref derivedContent="6.8" format="counter" sectionFormat="of" target="section-6.8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-etr-processing">ETR Processing</xref></t> </li> <li pn="section-toc.1-1.6.2.9"> <t indent="0" pn="section-toc.1-1.6.2.9.1"><xref derivedContent="6.9" format="counter" sectionFormat="of" target="section-6.9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-itr-processing-receiving-a-">ITR Processing: Receiving a Map-Reply</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.9.2"> <li pn="section-toc.1-1.6.2.9.2.1"> <t indent="0" pn="section-toc.1-1.6.2.9.2.1.1"><xref derivedContent="6.9.1" format="counter" sectionFormat="of" target="section-6.9.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-reply-record-validation">Map-Reply Record Validation</xref></t> </li> </ul> </li> </ul> </li> <li pn="section-toc.1-1.7"> <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2"> <li pn="section-toc.1-1.7.2.1"> <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-mapping-system-security">Mapping System Security</xref></t> </li> <li pn="section-toc.1-1.7.2.2"> <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-random-number-generation">Random Number Generation</xref></t> </li> <li pn="section-toc.1-1.7.2.3"> <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-server-and-etr-colocati">Map-Server and ETR Colocation</xref></t> </li> <li pn="section-toc.1-1.7.2.4"> <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-deploying-lisp-sec">Deploying LISP-SEC</xref></t> </li> <li pn="section-toc.1-1.7.2.5"> <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-shared-keys-provisioning">Shared Keys Provisioning</xref></t> </li> <li pn="section-toc.1-1.7.2.6"> <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-replay-attacks">Replay Attacks</xref></t> </li> <li pn="section-toc.1-1.7.2.7"> <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-message-privacy">Message Privacy</xref></t> </li> <li pn="section-toc.1-1.7.2.8"> <t indent="0" pn="section-toc.1-1.7.2.8.1"><xref derivedContent="7.8" format="counter" sectionFormat="of" target="section-7.8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-denial-of-service-and-distr">Denial-of-Service and Distributed Denial-of-Service Attacks</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.8"> <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.8.2"> <li pn="section-toc.1-1.8.2.1"> <t indent="0" pn="section-toc.1-1.8.2.1.1"><xref derivedContent="8.1" format="counter" sectionFormat="of" target="section-8.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-ecm-ad-type-registry">ECM AD Type Registry</xref></t> </li> <li pn="section-toc.1-1.8.2.2"> <t indent="0" pn="section-toc.1-1.8.2.2.1"><xref derivedContent="8.2" format="counter" sectionFormat="of" target="section-8.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-map-reply-ad-types-registry">Map-Reply AD Types Registry</xref></t> </li> <li pn="section-toc.1-1.8.2.3"> <t indent="0" pn="section-toc.1-1.8.2.3.1"><xref derivedContent="8.3" format="counter" sectionFormat="of" target="section-8.3"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-hmac-functions">HMAC Functions</xref></t> </li> <li pn="section-toc.1-1.8.2.4"> <t indent="0" pn="section-toc.1-1.8.2.4.1"><xref derivedContent="8.4" format="counter" sectionFormat="of" target="section-8.4"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-key-wrap-functions">Key Wrap Functions</xref></t> </li> <li pn="section-toc.1-1.8.2.5"> <t indent="0" pn="section-toc.1-1.8.2.5.1"><xref derivedContent="8.5" format="counter" sectionFormat="of" target="section-8.5"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-key-derivation-functions">Key Derivation Functions</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.9"> <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t> <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2"> <li pn="section-toc.1-1.9.2.1"> <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t> </li> <li pn="section-toc.1-1.9.2.2"> <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t> </li> </ul> </li> <li pn="section-toc.1-1.10"> <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t> </li> <li pn="section-toc.1-1.11"> <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t> </li> </ul> </section> </toc> </front> <middle> <section anchor="intro"title="Introduction"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-1"> <name slugifiedName="name-introduction">Introduction</name> <t indent="0" pn="section-1-1">The Locator/ID Separation Protocol (LISP) <xreftarget="I-D.ietf-lisp-rfc6830bis"/>,<xref target="I-D.ietf-lisp-rfc6833bis"/>target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC9300"/> <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> is a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). EID-to-RLOC mappings are stored in adatabase,database and the LISP Mapping System, and they are made available via the Map-Request/Map-Reply lookup process. If these EID-to-RLOC mappings, carried through Map-Reply messages, are transmitted without integrity protection, an adversary can manipulate them and hijack the communication, impersonate the requested EID, or mountDenial of ServiceDenial-of-Service (DoS) or DistributedDenial of ServiceDenial-of-Service (DDoS) attacks. Also, if the Map-Reply message is transported unauthenticated, an adversarial LISP entity can overclaim anEID-prefixEID-Prefix and maliciously redirect traffic. The LISP-SEC threat model, described in <xreftarget="threat-model"/>,target="threat-model" format="default" sectionFormat="of" derivedContent="Section 4"/>, is built on top of the LISP threat model defined in <xreftarget="RFC7835"/>, thattarget="RFC7835" format="default" sectionFormat="of" derivedContent="RFC7835"/>, which includes a detailed description of an "overclaiming" attack.</t><t>This<t indent="0" pn="section-1-2">This memo specifies LISP-SEC, a set of security mechanisms that provides origin authentication,integrityintegrity, and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization onEID-prefixEID-Prefix claims in Map-Reply messages, ensuring that the sender of a Map-Reply that provides the location for a givenEID-prefixEID-Prefix is entitled to do so according to theEID prefixEID-Prefix registered in the associated Map-Server. Map-Register/Map-Notify security, including the right for a LISP entity to register anEID-prefixEID-Prefix or to claim presence at an RLOC, is out of the scope ofLISP-SECLISP-SEC, as those protocols are protected by the security mechanisms specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>. However, LISP-SEC extends the Map-Register message to allow anITRIngress Tunnel Router (ITR) to downgrade tonon LISP-SECnon-LISP-SEC Map-Requests. Additional security considerations are described inSection 6.</t><xref target="security" format="default" sectionFormat="of" derivedContent="Section 7"/>.</t> </section> <sectiontitle="Requirements Notation"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-2"> <name slugifiedName="name-requirements-notation">Requirements Notation</name> <t indent="0" pn="section-2-1">The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xreftarget="RFC2119"/> <xref target="RFC8174"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section><!-- Requirements Notation --><section anchor="terms"title="Definition of Terms"> <t><list style="empty"> <t>One-Timenumbered="true" toc="include" removeInRFC="false" pn="section-3"> <name slugifiedName="name-definitions-of-terms">Definitions of Terms</name> <dl newline="false" indent="3" spacing="normal" pn="section-3-1"> <dt pn="section-3-1.1">One-Time Key(OTK): An(OTK):</dt> <dd pn="section-3-1.2">An ephemeral randomly generated key that must be used for a single Map-Request/Map-Replyexchange.</t> <t>ITRexchange.</dd> <dt pn="section-3-1.3">ITR One-Time Key(ITR-OTK): The(ITR-OTK):</dt> <dd pn="section-3-1.4">The One-Time Key generated at the Ingress Tunnel Router(ITR).</t> <t>MS(ITR).</dd> <dt pn="section-3-1.5">MS One-Time Key(MS-OTK): The(MS-OTK):</dt> <dd pn="section-3-1.6">The One-Time Key generated at theMap-Server.</t> <t>AuthenticationMap-Server.</dd> <dt pn="section-3-1.7">Authentication Data(AD): Metadata(AD):</dt> <dd pn="section-3-1.8">Metadata that is included either in a LISP Encapsulated Control Message (ECM)header,header as defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, or in a Map-Reply message to support confidentiality, integrity protection, and verification ofEID-prefix authorization.</t> <t>OTKEID-Prefix authorization.</dd> <dt pn="section-3-1.9">OTK Authentication Data(OTK-AD): The(OTK-AD):</dt> <dd pn="section-3-1.10">The portion of ECM Authentication Data that contains a One-TimeKey.</t> <t>EIDKey.</dd> <dt pn="section-3-1.11">EID Authentication Data(EID-AD): The(EID-AD):</dt> <dd pn="section-3-1.12">The portion of ECM and Map-Reply Authentication Data used for verification ofEID-prefix authorization.</t> <t>PacketEID-Prefix authorization.</dd> <dt pn="section-3-1.13">Packet Authentication Data(PKT-AD): The(PKT-AD):</dt> <dd pn="section-3-1.14">The portion of Map-Reply Authentication Data used to protect the integrity of the Map-Replymessage.</t> <t/> </list>Formessage.</dd> </dl> <t indent="0" pn="section-3-2">For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), and Map-Resolver(MR)(MR), please consult the LISP specification <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t>target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t> </section> <section anchor="threat-model"title="LISP-SECnumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-lisp-sec-threat-model">LISP-SEC ThreatModel"> <t>LISP-SECModel</name> <t indent="0" pn="section-4-1">LISP-SEC addresses the control plane threats, described insection 3.7 and 3.8 ofSections <xreftarget="RFC7835"/>,target="RFC7835" section="3.7" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7835#section-3.7" derivedContent="RFC7835"/> and <xref target="RFC7835" section="3.8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7835#section-3.8" derivedContent="RFC7835"/> of <xref target="RFC7835" format="default" sectionFormat="of" derivedContent="RFC7835"/>, that target EID-to-RLOC mappings, including manipulations of Map-Request and Map-Replymessages,messages and malicious ETREID prefixEID-Prefix overclaiming. LISP-SEC makes two main assumptions: (1) the LISPmapping systemMapping System is expected to deliver a Map-Request message to their intended destination ETR as identified by the EID, and (2) no on-path attack can be mounted within the LISP Mapping System. How the Mapping System is protected from on-path attacks dependsfromon the particular Mapping Systemused,used and is out of the scope of this memo. Furthermore, while LISP-SEC enables detection ofEID prefixEID-Prefix overclaiming attacks, it assumes that Map-Servers can verify theEID prefixEID-Prefix authorization at registration time. </t><t>According<t indent="0" pn="section-4-2">According to the threat model described in <xreftarget="RFC7835"/>target="RFC7835" format="default" sectionFormat="of" derivedContent="RFC7835"/>, LISP-SEC assumes that any kind of attack, including on-path attacks, can be mounted outside of the boundaries of the LISPmapping system.Mapping System. An on-pathattacker,attacker outside of the LISPmapping systemMapping System can, for example, hijack Map-Request and Map-Reply messages, spoofing the identity of a LISP node. Another example of an on-path attack, called an overclaiming attack, can be mounted by a maliciousEgress Tunnel Router (ETR),ETR by overclaiming theEID-prefixesEID-Prefixes for which it is authoritative. In thiswayway, the ETR can maliciously redirect traffic.</t> </section> <section anchor="operations"title="Protocol Operations"> <t>Thenumbered="true" toc="include" removeInRFC="false" pn="section-5"> <name slugifiedName="name-protocol-operations">Protocol Operations</name> <t indent="0" pn="section-5-1">The goal of the security mechanisms defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> is to prevent unauthorized insertion of mapping data by providing origin authentication and integrity protection for theMap-Register,Map-Register and by using the nonce to detect an unsolicited Map-Reply sent by off-path attackers.</t><t>LISP-SEC<t indent="0" pn="section-5-2">LISP-SEC builds on top of the security mechanisms defined in <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> to address the threats described in <xreftarget="threat-model"/>target="threat-model" format="default" sectionFormat="of" derivedContent="Section 4"/> by leveraging the trust relationships existing among the LISP entities(<xref target="I-D.ietf-lisp-rfc6833bis"/>)<xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> participating in the exchange of the Map-Request/Map-Reply messages. Those trust relationships (see also <xreftarget="security"/>target="security" format="default" sectionFormat="of" derivedContent="Section 7"/> and <xreftarget="I-D.ietf-lisp-rfc6833bis"/>)target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>) are used to securely distribute, as described in <xreftarget="wrap"/>,target="wrap" format="default" sectionFormat="of" derivedContent="Section 8.4"/>, a per-message One-Time Key (OTK) that provides origin authentication,integrityintegrity, and anti-replay protection to mapping data conveyed via the mapping lookupprocess,process and that effectivelypreventprevents overclaiming attacks. The processing of security parameters during the Map-Request/Map-Reply exchange is as follows:</t><t><list style="symbols"> <t>Per<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-3"> <li pn="section-5-3.1">Per each Map-Requestmessagemessage, a new ITR-OTK is generated and stored at theITR,ITR and is securely transported to theMap-Server.</t> <t>TheMap-Server.</li> <li pn="section-5-3.2">The Map-Server uses the ITR-OTK to compute aKeyed-Hashing forHashed Message Authentication Code (HMAC) <xreftarget="RFC2104"/>target="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/> that protects the integrity of the mapping data known to the Map-Server to prevent overclaiming attacks. The Map-Server also derives a new OTK, the MS-OTK, that is passed to theETR,ETR by applying a Key Derivation Function (KDF)(e.g.(e.g., <xreftarget="RFC5869"/>)target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/>) to theITR-OTK.</t> <t>TheITR-OTK.</li> <li pn="section-5-3.3">The ETR uses the MS-OTK to compute an HMAC that protects the integrity of the Map-Reply sent to theITR.</t> <t>Finally,ITR.</li> <li pn="section-5-3.4">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 verify that no overclaiming attacks were mounted along the path between the Map-Server and theITR.</t> </list></t> <t><xref target="encap"/>ITR.</li> </ul> <t indent="0" pn="section-5-4"><xref target="encap" format="default" sectionFormat="of" derivedContent="Section 6"/> provides the detailed description of the LISP-SEC control messages and their processing, while the rest of this section describes the flow of LISP protocol operations at each entity involved in the Map-Request/Map-Reply exchange:</t><t><list style="numbers"> <t>The<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-5"> <li pn="section-5-5.1" derivedCounter="1.">The ITR, upon needing to transmit a Map-Request message, generates and stores an OTK (ITR-OTK). This ITR-OTK is encrypted and included into the Encapsulated Control Message (ECM) that contains the Map-Request sent to the Map-Resolver.</t> <t>The</li> <li pn="section-5-5.2" derivedCounter="2.">The Map-Resolver decapsulates theECM message,ECM, decrypts theITR-OTK, if needed,ITR-OTK (if needed), and forwards through the Mapping System the received Map-Request and the ITR-OTK, as part of a newECM message.ECM. The LISP Mapping System delivers the ECM to the appropriate Map-Server, as identified by the EID destination address of the Map-Request.</t> <t>The</li> <li pn="section-5-5.3" derivedCounter="3.">The Map-Server is configured with the location mappings and policy information for the ETR responsible for the EID destination address. Using this preconfigured information, the Map-Server, after the decapsulation of theECM message,ECM, finds thelongest match EID-prefixlongest-match EID-Prefix that covers the requested EID in the received Map-Request. The Map-Server adds thisEID-prefix,EID-Prefix, together with an HMAC computed using the ITR-OTK, to a newEncapsulated Control MessageECM that contains the receivedMap-Request.</t> <t>TheMap-Request.</li> <li pn="section-5-5.4" derivedCounter="4.">The Map-Server derives a new OTK, the MS-OTK, by applying aKey Derivation Function (KDF)KDF to the ITR-OTK. This MS-OTK is included in theEncapsulated Control MessageECM that the Map-Server uses to forward the Map-Request to the ETR.</t> <t>If</li> <li pn="section-5-5.5" derivedCounter="5.">If the Map-Server is acting in proxy mode, as specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, the ETR is not involved in the generation of the Map-Reply and steps 6 and 7 are skipped. In thiscasecase, the Map-Server generates the Map-Reply on behalf of theETRETR, as described in <xreftarget="proxy"/>.</t> <t>Thetarget="proxy" format="default" sectionFormat="of" derivedContent="Section 6.7.2"/>.</li> <li pn="section-5-5.6" derivedCounter="6.">The ETR, upon receiving theECM encapsulatedECM-Encapsulated Map-Request from the Map-Server, decrypts theMS-OTK, if needed,MS-OTK (if needed), and originates a Map-Reply that contains the EID-to-RLOC mapping information as specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t> <t>Thetarget="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</li> <li pn="section-5-5.7" derivedCounter="7.">The ETR computes an HMAC over the Map-Reply, keyed with MS-OTK to protect the integrity of the whole Map-Reply. The ETR also copies theEID-prefixEID-Prefix authorization data that the Map-Server included in theECM encapsulatedECM-Encapsulated Map-Request into the Map-Reply message. The ETR then sends the complete Map-Reply message to the requestingITR.</t> <t>TheITR.</li> <li pn="section-5-5.8" derivedCounter="8.">The ITR, upon receiving the Map-Reply, uses the locally stored ITR-OTK to verify the integrity of theEID-prefixEID-Prefix authorization data included in the Map-Reply by the Map-Server. The ITR computes the MS-OTK by applying the same KDF (as specified in theECM encapsulatedECM-Encapsulated Map-Reply) used by theMap-Server,Map-Server and verifies the integrity of the Map-Reply.</t> </list></t></li> </ol> </section> <section anchor="encap"title="LISP-SECnumbered="true" toc="include" removeInRFC="false" pn="section-6"> <name slugifiedName="name-lisp-sec-control-messages-d">LISP-SEC Control MessagesDetails"> <t>LISP-SECDetails</name> <t indent="0" pn="section-6-1">LISP-SEC metadata associated with a Map-Request is transported within the Encapsulated Control Message that contains the Map-Request.</t><t>LISP-SEC<t indent="0" pn="section-6-2">LISP-SEC metadata associated with the Map-Reply is transported within the Map-Reply itself.</t><t>These<t indent="0" pn="section-6-3">These specifications useKeyed-Hashing for Message Authentication (HMAC)an HMAC in various places (as described in the following). The HMAC function AUTH-HMAC-SHA-256-128 <xreftarget="RFC6234"/> MUSTtarget="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/> <bcp14>MUST</bcp14> be supported in LISP-SEC implementations. LISP-SEC deploymentsSHOULD<bcp14>SHOULD</bcp14> use the AUTH-HMAC-SHA-256-128 HMAC function, except when communicating with older implementations that only support AUTH-HMAC-SHA-1-96 <xreftarget="RFC2104"/>.target="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/>. </t> <section anchor="ECM_extensions"title="Encapsulatednumbered="true" toc="include" removeInRFC="false" pn="section-6.1"> <name slugifiedName="name-encapsulated-control-messag">Encapsulated Control Message LISP-SECExtensions"> <t>LISP-SECExtensions</name> <t indent="0" pn="section-6.1-1">LISP-SEC uses the ECM defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> withS bitthe S-bit set to 1 to indicate that the LISP header includes Authentication Data (AD). The format of the LISP-SEC ECMAuthentication DataAD is defined in <xreftarget="fig-AD"/> .target="fig-AD" format="default" sectionFormat="of" derivedContent="Figure 1"/>. OTK-AD stands for One-Time Key Authentication Data and EID-AD stands for EID Authentication Data.</t> <figurealign="center"anchor="fig-AD"title="LISP-SECalign="left" suppress-title="false" pn="figure-1"> <name slugifiedName="name-lisp-sec-ecm-authentication">LISP-SEC ECM AuthenticationData">Data</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt="" pn="section-6.1-2.1"> 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-prefixEID-Prefix ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | ~ EID HMAC ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<---+ ]]></artwork><---+ </artwork> </figure><t><list style="empty"> <t>ECM<dl newline="false" indent="3" spacing="normal" pn="section-6.1-3"> <dt pn="section-6.1-3.1">ECM ADType: 1Type:</dt> <dd pn="section-6.1-3.2">1 (LISP-SEC Authentication Data). See <xreftarget="IANA"/>.</t> <t>Unassigned: Settarget="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>.</dd> <dt pn="section-6.1-3.3">Unassigned:</dt> <dd pn="section-6.1-3.4">Set to 0 on transmission and ignored onreceipt.</t> <t>Requested HMAC ID: Thereceipt.</dd> <dt pn="section-6.1-3.5">Requested HMAC ID:</dt> <dd pn="section-6.1-3.6">The HMAC algorithm,thatwhich will be used to protect the mappings, requested by the ITR. Permitted values are registered in the LISP-SEC Authentication Data HMAC ID (see <xreftarget="HMAC"/>).target="HMAC" format="default" sectionFormat="of" derivedContent="Section 8.3"/>). Refer to <xreftarget="itr"/>target="itr" format="default" sectionFormat="of" derivedContent="Section 6.4"/> for moredetails. </t> <t>OTK Length: Thedetails.</dd> <dt pn="section-6.1-3.7">OTK Length:</dt> <dd pn="section-6.1-3.8">The length (in bytes) of the OTK Authentication Data (OTK-AD),thatwhich contains the OTK Preamble and theOTK.</t> <t>Key ID: TheOTK.</dd> <dt pn="section-6.1-3.9">Key ID:</dt> <dd pn="section-6.1-3.10">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 theoriginorigin, and protect the integrity of the OTK. The Key ID allows to rotate between multiple pre-shared secrets in anon disruptive way.</t> <t>OTKnondisruptive way.</dd> <dt pn="section-6.1-3.11">OTK Wrapping ID (OTKWrap. ID): TheWrap. ID):</dt> <dd pn="section-6.1-3.12">The identifier of thekey derivation functionKey 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 <xreftarget="wrap"/>).target="wrap" format="default" sectionFormat="of" derivedContent="Section 8.4"/>). Refer to <xreftarget="encryption"/>target="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/> for more details.</t> <t>One-Time-Key Preamble: set</dd> <dt pn="section-6.1-3.13">One-Time-Key Preamble:</dt> <dd pn="section-6.1-3.14">Set to 0 if the OTK is not encrypted. When the OTK is encrypted, this fieldMAY<bcp14>MAY</bcp14> 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 <xreftarget="null"/> for details.</t> <t>One-Time-Key: thetarget="null" format="default" sectionFormat="of" derivedContent="Section 6.5.1"/> for details.</dd> <dt pn="section-6.1-3.15">One-Time-Key:</dt> <dd pn="section-6.1-3.16">The OTK wrapped as specified by OTK Wrapping ID. See <xreftarget="encryption"/> for details.</t> <t>EID-AD Length: lengthtarget="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/> for details.</dd> <dt pn="section-6.1-3.17">EID-AD Length:</dt> <dd pn="section-6.1-3.18">Length (in bytes) of the EID Authentication Data (EID-AD). The ITRMUST<bcp14>MUST</bcp14> set the EID-AD Length to 4 bytes, as it only fills theKDF ID'KDF ID' field, and all the remaining fields part of the EID-AD are not present. An EID-ADMAY<bcp14>MAY</bcp14> contain multipleEID-records.EID-Records. EachEID-recordEID-Record is4-byte long4 bytes long, plus the length of the AFI-encodedEID-prefix.</t> <t>KDF ID: IdentifierEID-Prefix.</dd> <dt pn="section-6.1-3.19">KDF ID:</dt> <dd pn="section-6.1-3.20">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 <xreftarget="kdf"/>).target="kdf" format="default" sectionFormat="of" derivedContent="Section 8.5"/>). Refer to <xreftarget="map-server"/>target="map-server" format="default" sectionFormat="of" derivedContent="Section 6.7"/> for more details.</t> <t>Record Count: As</dd> <dt pn="section-6.1-3.21">Record Count:</dt> <dd pn="section-6.1-3.22">As defined inSection 5.2 of<xreftarget="I-D.ietf-lisp-rfc6833bis"/>. </t> <t>E: ETR-Cant-Signtarget="RFC9301" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.2" derivedContent="RFC9301"/>. </dd> <dt pn="section-6.1-3.23">E:</dt> <dd pn="section-6.1-3.24">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 theEID prefixesEID-Prefixes of this Map-Reply has not enabled LISP-SEC. Only a Map-Server can set this bit. See <xreftarget="map-server"/>target="map-server" format="default" sectionFormat="of" derivedContent="Section 6.7"/> for moredetails.</t> <t>Unassigned: Setdetails.</dd> <dt pn="section-6.1-3.25">Unassigned:</dt> <dd pn="section-6.1-3.26">Set to 0 on transmission and ignored onreceipt.</t> <t>EID HMAC ID: Identifierreceipt.</dd> <dt pn="section-6.1-3.27">EID HMAC ID:</dt> <dd pn="section-6.1-3.28">Identifier of the HMAC algorithm used to protect the integrity of the EID-AD. This field is filled by the Map-Server that computed theEID-prefixEID-Prefix HMAC. See <xreftarget="EID-AD"/>target="EID-AD" format="default" sectionFormat="of" derivedContent="Section 6.7.1"/> for more details.</t> <t>EID mask-len: As</dd> <dt pn="section-6.1-3.29">EID mask-len:</dt> <dd pn="section-6.1-3.30">As defined inSection 5.2 of<xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t> <t>EID-AFI: Astarget="RFC9301" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.2" derivedContent="RFC9301"/>.</dd> <dt pn="section-6.1-3.31">EID-AFI:</dt> <dd pn="section-6.1-3.32">As defined inSection 5.2 of<xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t> <t>EID-prefix: Astarget="RFC9301" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.2" derivedContent="RFC9301"/>.</dd> <dt pn="section-6.1-3.33">EID-Prefix:</dt> <dd pn="section-6.1-3.34">As defined inSection 5.2 of<xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t> <t>EID HMAC: HMACtarget="RFC9301" section="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9301#section-5.2" derivedContent="RFC9301"/>.</dd> <dt pn="section-6.1-3.35">EID HMAC:</dt> <dd pn="section-6.1-3.36">HMAC of the EID-AD computed and inserted by aMap-ServerMap-Server. See <xreftarget="EID-AD"/>target="EID-AD" format="default" sectionFormat="of" derivedContent="Section 6.7.1"/> for more details.</t> </list></t></dd> </dl> </section> <section anchor="MR_extensions"title="Map-Reply LISP-SEC Extensions"> <t>LISP-SECnumbered="true" toc="include" removeInRFC="false" pn="section-6.2"> <name slugifiedName="name-map-reply-lisp-sec-extensio">Map-Reply LISP-SEC Extensions</name> <t indent="0" pn="section-6.2-1">LISP-SEC uses the Map-Reply defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, with Type set to2,2 and S-bit set to 1 to indicate that the Map-Reply message includes Authentication Data (AD). The format of the LISP-SEC Map-Reply Authentication Data is defined in <xreftarget="map-reply-AD"/>.target="map-reply-AD" format="default" sectionFormat="of" derivedContent="Figure 2"/>. PKT-AD is the Packet Authentication Data that covers the Map-Reply payload.</t> <figurealign="center"anchor="map-reply-AD"title="LISP-SECalign="left" suppress-title="false" pn="figure-2"> <name slugifiedName="name-lisp-sec-map-reply-authenti">LISP-SEC Map-Reply AuthenticationData">Data</name> <artworkalign="center"><![CDATA[align="center" name="" type="" alt="" pn="section-6.2-2.1"> 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-prefixEID-Prefix ... ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | ~ EID HMAC ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<---+<---+ | PKT-AD Length | PKT HMAC ID |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ PKT HMAC ~PKT-AD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/]]></artwork></artwork> </figure><t><list style="empty"> <t>MR<dl newline="false" indent="3" spacing="normal" pn="section-6.2-3"> <dt pn="section-6.2-3.1">MR ADType: 1Type:</dt> <dd pn="section-6.2-3.2">1 (LISP-SEC Authentication Data). See <xreftarget="IANA"/>.</t> <t>EID-AD Length: lengthtarget="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>.</dd> <dt pn="section-6.2-3.3">EID-AD Length:</dt> <dd pn="section-6.2-3.4">Length (in bytes) of the EID-AD (see <xreftarget="ECM_extensions"/>). </t> <t>KDF ID: Identifiertarget="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>). </dd> <dt pn="section-6.2-3.5">KDF ID:</dt> <dd pn="section-6.2-3.6">Identifier of the Key Derivation Function used to derive MS-OTK (see <xreftarget="ECM_extensions"/>). </t> <t>Record Count: Thetarget="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).</dd> <dt pn="section-6.2-3.7">Record Count:</dt> <dd pn="section-6.2-3.8">The number of records in this Map-Reply message (see <xreftarget="ECM_extensions"/>).</t> <t>Unassigned: Settarget="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).</dd> <dt pn="section-6.2-3.9">Unassigned:</dt> <dd pn="section-6.2-3.10">Set to 0 on transmission and ignored onreceipt.</t> <t>EID HMAC ID: Identifierreceipt.</dd> <dt pn="section-6.2-3.11">EID HMAC ID:</dt> <dd pn="section-6.2-3.12">Identifier of the HMAC algorithm used to protect the integrity of the EID-AD (see <xreftarget="ECM_extensions"/>). </t> <t>EID mask-len: Masktarget="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>). </dd> <dt pn="section-6.2-3.13">EID mask-len:</dt> <dd pn="section-6.2-3.14">Mask length forEID-prefixEID-Prefix (see <xreftarget="ECM_extensions"/>).</t> <t>EID-AFI: See <xref target="ECM_extensions"/>. </t> <t>EID-prefix: See <xref target="ECM_extensions"/>. </t> <t>EID HMAC: See <xref target="ECM_extensions"/>. </t> <t>PKT-AD Length: lengthtarget="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>).</dd> <dt pn="section-6.2-3.15">EID-AFI:</dt> <dd pn="section-6.2-3.16">See <xref target="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>. </dd> <dt pn="section-6.2-3.17">EID-Prefix:</dt> <dd pn="section-6.2-3.18">See <xref target="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>. </dd> <dt pn="section-6.2-3.19">EID HMAC:</dt> <dd pn="section-6.2-3.20">See <xref target="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>. </dd> <dt pn="section-6.2-3.21">PKT-AD Length:</dt> <dd pn="section-6.2-3.22">Length (in bytes) of the Packet Authentication Data(PKT-AD).</t> <t>PKT HMAC ID: Identifier(PKT-AD).</dd> <dt pn="section-6.2-3.23">PKT HMAC ID:</dt> <dd pn="section-6.2-3.24">Identifier of the HMAC algorithm used to protect the integrity of the Map-Reply (see <xreftarget="encryption"/>). </t> <t>PKT HMAC: HMACtarget="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/>).</dd> <dt pn="section-6.2-3.25">PKT HMAC:</dt> <dd pn="section-6.2-3.26">HMAC of the whole Map-Replypacket, sopacket to protect itsintegrity;integrity, including the LISP-SEC Authentication Data (from theMap-Reply Type'Map-Reply Type' field to thePKT HMAC'PKT HMAC' field), which allow messageauthetification. </t> </list></t>authentication.</dd> </dl> </section> <sectiontitle="Map-Register LISP-SEC Extensions"> <t>The S bitnumbered="true" toc="include" removeInRFC="false" pn="section-6.3"> <name slugifiedName="name-map-register-lisp-sec-exten">Map-Register LISP-SEC Extensions</name> <t indent="0" pn="section-6.3-1">The S-bit in the Map-Register message (see <xreftarget="I-D.ietf-lisp-rfc6833bis"/>)target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>) indicates to the Map-Server that the registering ETR is LISP-SEC enabled. An ETR that supports LISP-SECMUST<bcp14>MUST</bcp14> set theS bitS-bit in its Map-Register messages.</t> </section> <section anchor="itr"title="ITRnumbered="true" toc="include" removeInRFC="false" pn="section-6.4"> <name slugifiedName="name-itr-processing-generating-a">ITR Processing: Generating aMap-Request"> <t>UponMap-Request</name> <t indent="0" pn="section-6.4-1">Upon creating a Map-Request, the ITR generates a random ITR-OTK that is stored locally, until the corresponding Map-Reply is received (see <xreftarget="itr-receive"/>),target="itr-receive" format="default" sectionFormat="of" derivedContent="Section 6.9"/>), together with the nonce generated as specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t> <t>Thetarget="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t> <t indent="0" pn="section-6.4-2">The ITRMAY<bcp14>MAY</bcp14> use theKDF ID'KDF ID' field to indicate the recommended KDFalgorithm,algorithm according to local policy. The Map-Server can overwrite the KDF ID if it does not support the KDF ID recommended by the ITR (see <xreftarget="map-server"/>).target="map-server" format="default" sectionFormat="of" derivedContent="Section 6.7"/>). A KDF value of NOPREF (0) may be used to specify that the ITR has no preferred KDF ID. </t><t>ITR-OTK<t indent="0" pn="section-6.4-3">ITR-OTK confidentiality and integrity protectionMUST<bcp14>MUST</bcp14> be provided in the path between the ITR and the Map-Resolver. This can be achieved either by encrypting the ITR-OTK with the pre-shared secret known to the ITR and the Map-Resolver (see <xreftarget="encryption"/>),target="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/>) or by enabling DTLS <xreftarget="RFC9147"/>target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> between the ITR and the Map-Resolver.</t><t>The<t indent="0" pn="section-6.4-4">The Map-Request (as defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>) MUSTtarget="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>) <bcp14>MUST</bcp14> be encapsulated as a LISP Control Message in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data. Such a message is also called a "Protected Map-Request" in this memo.</t><t>The<t indent="0" pn="section-6.4-5">The ITR-OTK is wrapped with the algorithm specified by theOTK'OTK WrappingIDID' field. See <xreftarget="encryption"/>target="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/> for further details on OTK encryption. If the NULL-KEY-WRAP-128 algorithm (see <xreftarget="wrap"/>)target="wrap" format="default" sectionFormat="of" derivedContent="Section 8.4"/>) is selected, and no other encryption mechanism(e.g.(e.g., DTLS) is enabled in the path between the ITR and the Map-Resolver, the Map-RequestMUST<bcp14>MUST</bcp14> be dropped, and an appropriate log actionSHOULD<bcp14>SHOULD</bcp14> be taken. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.</t><t>The Requested<t indent="0" pn="section-6.4-6">The 'Requested HMACIDID' field contains the suggested HMAC algorithm to be used by the Map-Server and the ETR to protect the integrity of the ECM AuthenticationdataData and of the Map-Reply. A HMAC IDValuevalue of NONE(0), MAY(0) <bcp14>MAY</bcp14> be used to specify that the ITR has no preferred HMAC ID. </t><t>The KDF ID<t indent="0" pn="section-6.4-7">The 'KDF ID' field specifies the suggestedkey derivation functionKey Derivation Function to be used by the Map-Server to derive the MS-OTK. A KDFValuevalue of NONE (0) may be used to specify that the ITR has no preferred KDF ID.</t><t>The<t indent="0" pn="section-6.4-8">The EID-ADlengthLength is set to 4 bytes, since the Authentication Data does not containEID-prefixEID-Prefix Authentication Data, and the EID-AD contains only theKDF ID'KDF ID' field.</t><t>If<t indent="0" pn="section-6.4-9">If the ITR is directly connected to a Mapping System, such as LISP+ALT <xreftarget="RFC6836"/>,target="RFC6836" format="default" sectionFormat="of" derivedContent="RFC6836"/>, it performs the functions of both the ITR and the Map-Resolver, forwarding the Protected Map-Request as described in <xreftarget="map-resolver"/>.</t> <t>Thetarget="map-resolver" format="default" sectionFormat="of" derivedContent="Section 6.6"/>.</t> <t indent="0" pn="section-6.4-10">The processing performed by Proxy ITRs (PITRs) is equivalent to the processing of anITR, henceITR; hence, the procedure described above applies. </t> </section> <section anchor="encryption"title="Encryptingnumbered="true" toc="include" removeInRFC="false" pn="section-6.5"> <name slugifiedName="name-encrypting-and-decrypting-a">Encrypting and Decrypting anOTK "> <t>MS-OTKOTK</name> <t indent="0" pn="section-6.5-1">MS-OTK confidentiality and integrity protectionMUST<bcp14>MUST</bcp14> be provided in the path between the Map-Server and the ETR. This can be achieved either by enabling DTLS between the Map-Server and the ETR or by encrypting the MS-OTK with the pre-shared secret known to the Map-Server and the ETR <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t> <t>Similarly,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t> <t indent="0" pn="section-6.5-2">Similarly, ITR-OTK confidentiality and integrity protectionMUST<bcp14>MUST</bcp14> be provided in the path between the ITR and the Map-Resolver. This can be achieved either by enabling DTLS between the Map-Server and theITR,ITR or by encrypting the ITR-OTK with the pre-shared secret known to the ITR and the Map-Resolver. The ITR/Map-Resolver pre-shared key is similar to the Map-Server/ETR pre-shared key.</t><t>This<t indent="0" pn="section-6.5-3">This section describes OTK processing in the ITR/Map-Resolver path, as well as in the Map-Server/ETR path.</t><t>It's<t indent="0" pn="section-6.5-4">It's important to note that, to prevent ETR's overclaiming attacks, the ITR/Map-Resolver pre-shared secretMUST<bcp14>MUST</bcp14> be independent from the Map-Server/ETR pre-shared secret.</t><t>The<t indent="0" pn="section-6.5-5">The OTK is wrapped using the algorithm specified in theOTK'OTK WrappingIDID' field. This field identifies both the:</t><t><list style="symbols"> <t>Key<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.5-6"> <li pn="section-6.5-6.1">Key Encryption Algorithm used to encrypt the wrappedOTK.</t> <t>KeyOTK and</li> <li pn="section-6.5-6.2">Key Derivation Function used to derive a per-message encryptionkey.</t> </list>key.</li> </ul> <t indent="0" pn="section-6.5-7"> Implementations of this specificationMUST<bcp14>MUST</bcp14> support the OTK Wrapping IDAES-KEY-WRAP-128+HKDF-SHA256 thatAES-KEY-WRAP-128+HKDF-SHA256, which specifies the use of the HKDF-SHA256 Key Derivation Function specified in <xreftarget="RFC5869"/>target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/> to derive a per-message encryption key (per-msg-key), as well as the AES-KEY-WRAP-128Key Wrapkey wrap algorithm used to encrypt a 128-bit OTK, according to <xreftarget="RFC3394"/>.</t> <t>Implementationstarget="RFC3394" format="default" sectionFormat="of" derivedContent="RFC3394"/>.</t> <t indent="0" pn="section-6.5-8">Implementations of this specificationMUST<bcp14>MUST</bcp14> support OTK Wrapping NULL-KEY-WRAP-128. NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 bits).</t><t>The<t indent="0" pn="section-6.5-9">The key wrapping process for OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256 is described below:<list style="numbers"> <t>The</t> <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.5-10"> <li pn="section-6.5-10.1" derivedCounter="1.">The KDF andKey Wrapkey wrap algorithms are identified by the value of the 'OTK Wrapping ID' field. The initial values are documented in <xreftarget="tableKWF"/>.</t> <t>Iftarget="tableKWF" format="default" sectionFormat="of" derivedContent="Table 5"/>.</li> <li pn="section-6.5-10.2" derivedCounter="2.">If the NULL-KEY-WRAP-128 algorithm (see <xreftarget="wrap"/>)target="wrap" format="default" sectionFormat="of" derivedContent="Section 8.4"/>) is selected and DTLS is not enabled, the Map-RequestMUST<bcp14>MUST</bcp14> be dropped and an appropriate log actionSHOULD<bcp14>SHOULD</bcp14> be taken. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustionattacks.</t> <t>Theattacks.</li> <li pn="section-6.5-10.3" derivedCounter="3.">The pre-shared secret used to derive the per-msg-key is represented by PSK[Key ID],thatwhich is the pre-shared secret identified by the 'KeyID'.</t> <t>The 128-bits longID'.</li> <li pn="section-6.5-10.4" derivedCounter="4."> <t indent="0" pn="section-6.5-10.4.1">The 128-bit-long per-message encryption key is computedas: <list style="symbols"> <t>per-msg-keyas:</t> <t indent="3" pn="section-6.5-10.4.2">per-msg-key = KDF( nonce + s + PSK[Key ID] )</t></list> where<t indent="0" pn="section-6.5-10.4.3">where the nonce is the value in theNonce'Nonce' field of the Map-Request, 's' is the string "OTK-Key-Wrap", and the operation'+' just indicates stringconcatenation. </t> <t>According to <xref target="RFC3394"/> theconcatenation.</t> </li> <li pn="section-6.5-10.5" derivedCounter="5.">The per-msg-key is then used to wrap the OTK withAES-KEY-WRAP-128.AES-KEY-WRAP-128, as specified in <xref target="RFC3394" format="default" sectionFormat="of" section="2.2.1" derivedLink="https://rfc-editor.org/rfc/rfc3394#section-2.2.1" derivedContent="RFC3394"/>. The AES Key Wrap Initialization ValueMUST<bcp14>MUST</bcp14> be set to 0xA6A6A6A6A6A6A6A6 (64 bits). The output of the AESKey Wrapkey wrap operation is192-bit192 bits long. The most significant64-bit64 bits are copied in theOne-Time'One-Time KeyPreamblePreamble' field, while the 128lessleast significant bits are copied in theOne-Time Key'One-Time Key' field of the LISP-SEC AuthenticationData.</t> </list></t> <t>WhenData.</li> </ol> <t indent="0" pn="section-6.5-11">When decrypting an encryptedOTKOTK, the receiverMUST<bcp14>MUST</bcp14> verify that the Initialization Value resulting from the AESKey Wrapkey wrap decryption operation is equal to 0xA6A6A6A6A6A6A6A6. If this verificationfailsfails, the receiverMUST<bcp14>MUST</bcp14> discard the entire message.</t> <section anchor="null"title="Unencrypted OTK"> <t>However,numbered="true" toc="include" removeInRFC="false" pn="section-6.5.1"> <name slugifiedName="name-unencrypted-otk">Unencrypted OTK</name> <t indent="0" pn="section-6.5.1-1">However, when DTLS isenabledenabled, the OTKMAY<bcp14>MAY</bcp14> be sent unencrypted as transport layer security is providing confidentiality and integrity protection.</t><t>When<t indent="0" pn="section-6.5.1-2">When a 128-bit OTK is sentunencryptedunencrypted, the OTK Wrapping ID is set to NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 (64 bits).</t> </section> </section> <section anchor="map-resolver"title="Map-Resolver Processing"> <t>Uponnumbered="true" toc="include" removeInRFC="false" pn="section-6.6"> <name slugifiedName="name-map-resolver-processing">Map-Resolver Processing</name> <t indent="0" pn="section-6.6-1">Upon receiving a Protected Map-Request, the Map-Resolver decapsulates theECM message.ECM. The ITR-OTK, if encrypted, is decrypted as specified in <xreftarget="encryption"/>.</t> <t>Protectingtarget="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/>.</t> <t indent="0" pn="section-6.6-2">Protecting the confidentiality of the ITR-OTK and, in general, the security of how the Map-Request is handed by the Map-Resolver to theMap-Server,Map-Server is specific to the particular Mapping Systemused,used and is outside of the scope of this memo.</t><t>In<t indent="0" pn="section-6.6-3">In Mapping Systems where the Map-Server is compliant with <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, the Map-Resolver originates a new ECM header with the S-bit set,thatwhich contains the unencrypted ITR-OTK, as specified in <xreftarget="encryption"/>,target="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/>, and the other data derived from the ECM Authentication Data of the receivedencapsulatedEncapsulated Map-Request.</t><t>The<t indent="0" pn="section-6.6-4">The Map-Resolver then forwards to the Map-Server the received Map-Request, which is encapsulated in the new ECM header that includes the newly computedAuthentication Data'Authentication Data' fields.</t> </section> <section anchor="map-server"title="Map-Server Processing"> <t>Uponnumbered="true" toc="include" removeInRFC="false" pn="section-6.7"> <name slugifiedName="name-map-server-processing">Map-Server Processing</name> <t indent="0" pn="section-6.7-1">Upon receiving a Protected Map-Request, the Map-Server processes it according to the setting of the S-bit and the P-bit in the Map-Register received from the ETRs authoritative for that prefix, as described below.</t><t>While<t indent="0" pn="section-6.7-2">While processing the Map-Request, the Map-Server can overwrite theKDF ID'KDF ID' field if it does not support the KDF ID recommended by the ITR. Processing of the Map-RequestMUST<bcp14>MUST</bcp14> proceed in the order described in the table below, applying theprocessingprocess corresponding to the first rule that matches the conditions indicated in the first column:</t><texttable<table anchor="tableMRP"title="Map-Request Processing."> <ttcol width="30%">Matching Condition</ttcol> <ttcol align="left">Processing</ttcol> <c>1.align="center" pn="table-1"> <name slugifiedName="name-map-request-processing">Map-Request Processing</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Matching Condition</th> <th align="left" colspan="1" rowspan="1">Processing</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">1. At least one of the ETRs authoritative for theEID prefixEID-Prefix included in the Map-Request registered with the P-bit set to1 </c> <c>The1</td> <td align="left" colspan="1" rowspan="1">The Map-ServerMUST<bcp14>MUST</bcp14> generate aLISP-SEC protected Map-ReplyLISP-SEC-protected Map-Reply, as specified in <xreftarget="proxy"/>.target="proxy" format="default" sectionFormat="of" derivedContent="Section 6.7.2"/>. The ETR-Cant-Sign E-bit in the EID Authentication Data (EID-AD)MUST<bcp14>MUST</bcp14> be set to0. </c> <c/> <c/> <c>2.0.</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">2. At least one of the ETRs authoritative for theEID prefixEID-Prefix included in the Map-Request registered with the S-bit set to1</c> <c>The1</td> <td align="left" colspan="1" rowspan="1">The Map-ServerMUST<bcp14>MUST</bcp14> generate aLISP-SEC protectedLISP-SEC-protected Encapsulated Map-Request (as specified in <xreftarget="EID-AD"/>),target="EID-AD" format="default" sectionFormat="of" derivedContent="Section 6.7.1"/>) to be sent to one of the authoritative ETRs that registered with the S-bit set to 1 (and the P-bit set to 0). If there is at least one ETR that registered with the S-bit set to 0, the ETR-Cant-Sign E-bit of the EID-ADMUST<bcp14>MUST</bcp14> be set to 1 to signal the ITR that anon LISP-SECnon-LISP-SEC Map-Request might reach additional ETRs that have LISP-SECdisabled.</c> <c/> <c/> <c>3.disabled.</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">3. All the ETRs authoritative for theEID prefixEID-Prefix included in the Map-Request registered with the S-bit set to0</c> <c>The0</td> <td align="left" colspan="1" rowspan="1">The Map-ServerMUST<bcp14>MUST</bcp14> send a Negative Map-Reply protected with LISP-SEC, as described in <xreftarget="proxy"/>.target="proxy" format="default" sectionFormat="of" derivedContent="Section 6.7.2"/>. The ETR-Cant-Sign E-bitMUST<bcp14>MUST</bcp14> be set to 1 to signal the ITR that anon LISP-SECnon-LISP-SEC Map-Request might reach additional ETRs that have LISP-SECdisabled.</c> </texttable> <t>Indisabled.</td> </tr> </tbody> </table> <t indent="0" pn="section-6.7-4">In thiswayway, the ITR that sent aLISP-SEC protectedLISP-SEC-protected Map-Request always receives aLISP-SEC protectedLISP-SEC-protected Map-Reply. However, the ETR-Cant-Sign E-bit set to 1 specifies that anon LISP-SECnon-LISP-SEC Map-Request might reach additional ETRs that have LISP-SEC disabled. This mechanism allows the ITR to downgrade tonon LISP-SECnon-LISP-SEC requests, which does not protect against threats described in <xreftarget="threat-model"/>.</t>target="threat-model" format="default" sectionFormat="of" derivedContent="Section 4"/>.</t> <section anchor="EID-AD"title="Generatingnumbered="true" toc="include" removeInRFC="false" pn="section-6.7.1"> <name slugifiedName="name-generating-a-lisp-sec-prote">Generating aLISP-SEC ProtectedLISP-SEC-Protected EncapsulatedMap-Request"> <t>TheMap-Request</name> <t indent="0" pn="section-6.7.1-1">The Map-Server decapsulates the ECM and generatesanew ECM Authentication Data. The Authentication Data includes the OTK-AD and the EID-AD,thatwhich containsEID-prefixEID-Prefix authorizationinformation,information that are eventually received by the requesting ITR.</t><t>The<t indent="0" pn="section-6.7.1-2">The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from the ITR-OTK received with the Map-Request. MS-OTK is derived by applying thekey derivation functionKey Derivation Function specified in theKDF ID'KDF ID' field. If the algorithm specified in theKDF ID'KDF ID' field is not supported, the Map-Server uses a different algorithm to derive the key and updates theKDF ID'KDF ID' field accordingly.</t><t>The<t indent="0" pn="section-6.7.1-3">The Map-RequestMUST<bcp14>MUST</bcp14> be encapsulated in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data.</t><t>MS-OTK<t indent="0" pn="section-6.7.1-4">MS-OTK is wrapped with the algorithm specified by theOTK'OTK WrappingIDID' field. See <xreftarget="encryption"/>target="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/> for further details on OTK encryption. If the NULL-KEY-WRAP-128 algorithm is selected and DTLS is not enabled in the path between the Map-Server and the ETR, the Map-RequestMUST<bcp14>MUST</bcp14> be dropped and an appropriate log actionSHOULD<bcp14>SHOULD</bcp14> be taken.</t><t>The<t indent="0" pn="section-6.7.1-5">In the EID-AD, the Map-Server includes in the EID-AD thelongest match registered EID-prefixlongest-match-registered EID-Prefix for the destinationEID,EID and an HMAC of thisEID-prefix.EID-Prefix. The HMAC is keyed with the ITR-OTK contained in the received ECM Authentication Data, and the HMAC algorithm is chosen according to theRequested'Requested HMACIDID' field. If the Map-Server does not support this algorithm, the Map-Server uses a different algorithm and specifies it in theEID'EID HMACIDID' field. The scope of the HMAC operationMUST<bcp14>MUST</bcp14> cover the entire EID-AD, from theEID-AD Length'EID-AD Length' field to theEID HMAC'EID HMAC' field, whichMUST<bcp14>MUST</bcp14> be set to 0 before the computation.</t><t>The<t indent="0" pn="section-6.7.1-6">The Map-Server then forwards the updatedECM encapsulatedECM-Encapsulated Map-Request,thatwhich contains the OTK-AD, the EID-AD, and the received Map-Request to an authoritative ETR as specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t>target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t> </section> <section anchor="proxy"title="Generatingnumbered="true" toc="include" removeInRFC="false" pn="section-6.7.2"> <name slugifiedName="name-generating-a-proxy-map-repl">Generating a ProxyMap-Reply"> <t>LISP-SECMap-Reply</name> <t indent="0" pn="section-6.7.2-1">A LISP-SEC proxy Map-Replyareis generated according to <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, with the Map-Reply S-bit set to 1. The Map-Reply includes the Authentication Data that contains theEID-AD,EID-AD computed as specified in <xreftarget="EID-AD"/>,target="EID-AD" format="default" sectionFormat="of" derivedContent="Section 6.7.1"/>, as well as the PKT-AD computed as specified in <xreftarget="etr"/>.</t>target="etr" format="default" sectionFormat="of" derivedContent="Section 6.8"/>.</t> </section> </section> <section anchor="etr"title="ETR Processing"> <t>Uponnumbered="true" toc="include" removeInRFC="false" pn="section-6.8"> <name slugifiedName="name-etr-processing">ETR Processing</name> <t indent="0" pn="section-6.8-1">Upon receiving anECM encapsulatedECM-Encapsulated Map-Request with the S-bit set, the ETR decapsulates theECM message.ECM. TheOTK'OTK' field, if encrypted, is decrypted as specified in <xreftarget="encryption"/>target="encryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/> to obtain the unencrypted MS-OTK.</t><t>The<t indent="0" pn="section-6.8-2">The ETR then generates a Map-Reply as specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> and includes the Authentication Data that contains the EID-AD, as received in theencapsulatedEncapsulated Map-Request, as well as the PKT-AD.</t><t>The<t indent="0" pn="section-6.8-3">The EID-AD is copied from the Authentication Data of the receivedencapsulatedEncapsulated Map-Request.</t><t>The<t indent="0" pn="section-6.8-4">The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed with the MS-OTK and computed using the HMAC algorithm specified in theRequested'Requested HMACIDID' field of the receivedencapsulatedEncapsulated Map-Request. If the ETR does not support the Requested HMAC ID, it uses a different algorithm and updates thePKT'PKT HMACIDID' field accordingly. The HMAC operationMUST<bcp14>MUST</bcp14> cover the entire Map-Reply, where thePKT HMAC'PKT HMAC' fieldMUST<bcp14>MUST</bcp14> be set to 0 before the computation. </t><t>Finally<t indent="0" pn="section-6.8-5">Finally, the ETR sends the Map-Reply to the requesting ITR as specified in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.</t>target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t> </section> <section anchor="itr-receive"title="ITRnumbered="true" toc="include" removeInRFC="false" pn="section-6.9"> <name slugifiedName="name-itr-processing-receiving-a-">ITR Processing: Receiving aMap-Reply"> <t>InMap-Reply</name> <t indent="0" pn="section-6.9-1">In response to a Protected Map-Request, an ITR expects a Map-Reply with the S-bit set to11, including an EID-AD and a PKT-AD. The ITRMUST<bcp14>MUST</bcp14> discard the Map-Reply otherwise. </t><t>Upon<t indent="0" pn="section-6.9-2">Upon receiving a Map-Reply, the ITR must verify the integrity of both the EID-AD and thePKT-AD,PKT-AD andMUST<bcp14>MUST</bcp14> discard the Map-Reply if one of the integrity checks fails. After processing the Map-Reply, the ITRMUST<bcp14>MUST</bcp14> discard the <nonce,ITR-OTK> pair associated to theMap-Reply</t> <t>TheMap-Reply.</t> <t indent="0" pn="section-6.9-3">The integrity of the EID-AD is verified using the ITR-OTK (stored locally for the duration of this exchange) tore-computerecompute the HMAC of the EID-AD using the algorithm specified in theEID'EID HMACIDID' field. If the ITR did indicate a Requested HMAC ID in the Map-Request and the PKT HAMC ID in the corresponding Map-Reply is different, or if the ITR did not indicate a Requested HMAC ID in the Map-Request and the PKT HMAC ID in the corresponding Map-Reply is not supported, then the ITRMUST<bcp14>MUST</bcp14> discard the Map-Reply and send, according torate limitationrate-limitation policies defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, a new Map-Request with a differentRequested'Requested HMACIDID' field, according to ITR's local policy. The scope of the HMAC operation covers the entire EID-AD, from theEID-AD Length'EID-AD Length' field to theEID HMAC'EID HMAC' field.</t><t>ITR MUST<t indent="0" pn="section-6.9-4">ITR <bcp14>MUST</bcp14> set theEID'EID HMACIDID' field to 0 before computing the HMAC.</t><t>To<t indent="0" pn="section-6.9-5">To verify the integrity of the PKT-AD, first the MS-OTK is derived from the locally stored ITR-OTK using the algorithm specified in theKDF ID'KDF ID' field. This is because the PKT-AD is generated by the ETR using the MS-OTK. If the ITR did indicate a recommended KDF ID in the Map-Request and the KDF ID in the corresponding Map-Reply isdifferent,different or if the ITR did not indicate a recommended KDF ID in the Map-Request and the KDF ID in the corresponding Map-Reply is not supported, then the ITRMUST<bcp14>MUST</bcp14> discard the Map-Reply and send, according torate limitationrate-limitation policies defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, a new Map-Request with a different KDF ID, according to ITR's local policy. Thekey derivation functionKey Derivation Function HKDF-SHA256MUST<bcp14>MUST</bcp14> be supported in LISP-SEC implementations. LISP-SEC deploymentsSHOULD<bcp14>SHOULD</bcp14> use the HKDF-SHA256 HKDF function, unless older implementations using HKDF-SHA1-128 are present in the same deployment. Without consistent configuration of involved entities, extra delays may be experienced. However, since HKDF-SHA1-128 and HKDF-SHA256 are supported, the process will eventually converge. </t><t>The<t indent="0" pn="section-6.9-6">The derived MS-OTK is then used tore-computerecompute the HMAC of the PKT-AD using theAlgorithmalgorithm specified in thePKT'PKT HMACIDID' field. If thePKT'PKT HMACIDID' field does not match the Requested HMACIDID, the ITRMUST<bcp14>MUST</bcp14> discard the Map-Reply and send, according torate limitationrate-limitation policies defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, a new Map-Request with a different Requested HMACIDID, according to ITR's local policy or until all HMAC IDs supported by the ITR have been attempted. When thePKT'PKT HMACIDID' field does not match the Requested HMACIDID, it is not possible to validate the Map-Reply.</t><t>Each<t indent="0" pn="section-6.9-7">Each individual Map-ReplyEID-recordEID-Record is considered valid only if: (1) both EID-AD and PKT-AD arevalid,valid and (2) the intersection of theEID-prefixEID-Prefix in the Map-ReplyEID-recordEID-Record with one of theEID-prefixesEID-Prefixes contained in the EID-AD is not empty. After identifying the Map-Reply record as valid, the ITR sets theEID-prefixEID-Prefix in the Map-Reply record to the value of the intersection set computedbefore,before and adds the Map-ReplyEID-recordEID-Record to its EID-to-RLOCcache,Map-Cache, as described in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>.target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>. An example of Map-Reply record validation is provided in <xreftarget="validation"/>.</t> <t><xref target="I-D.ietf-lisp-rfc6833bis"/>target="validation" format="default" sectionFormat="of" derivedContent="Section 6.9.1"/>.</t> <t indent="0" pn="section-6.9-8"><xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/> allows ETRs to send Solicit-Map-Requests(SMR)(SMRs) directly to the ITR. The corresponding SMR-invoked Map-Request will be sent through themapping system,Mapping System, hence, secured with the specifications of this memo if in use. If an ITR accepts Map-Replies piggybacked in Map-Requests and its content is not already present in its EID-to-RLOCcache,Map-Cache, itMUST<bcp14>MUST</bcp14> send a Map-Request over themapping systemMapping System in order to verify its content with a securedMap-Reply,Map-Reply before using the content.</t><t/><section anchor="validation"title="Map-Replynumbered="true" toc="include" removeInRFC="false" pn="section-6.9.1"> <name slugifiedName="name-map-reply-record-validation">Map-Reply RecordValidation"> <t>TheValidation</name> <t indent="0" pn="section-6.9.1-1">The payload of a Map-Reply may contain multipleEID-records.EID-Records. The whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide integrity protection and origin authentication to theEID-prefixEID-Prefix records claimed by the ETR. TheAuthentication Data'Authentication Data' field of a Map-Reply may contain multipleEID-recordsEID-Records in the EID-AD. The EID-AD is signed by the Map-Server, with the EID HMAC, to provide integrity protection and origin authentication to theEID-prefixEID-Prefix records inserted by the Map-Server.</t><t>Upon<t indent="0" pn="section-6.9.1-2">Upon receiving a Map-Reply with the S-bit set, the ITR first checks the validity of both the EID HMAC and of the PKT-AD HMAC. If either one of the HMACs is not valid, a log actionSHOULD<bcp14>SHOULD</bcp14> be taken and the Map-ReplyMUST NOT<bcp14>MUST NOT</bcp14> 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 proceeds with validating each individualEID-recordEID-Record claimed by the ETR by computing the intersection of each one of theEID-prefixEID-Prefixes contained in the payload of theMap-ReplyMap-Reply, with each one of theEID-prefixesEID-Prefixes contained in the EID-AD. AnEID-recordEID-Record is valid only if at least one of the intersections is not the emptyset,set; otherwise, a log actionMUST<bcp14>MUST</bcp14> be taken and theEID-record MUSTEID-Record <bcp14>MUST</bcp14> be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks.</t><t>For<t indent="0" pn="section-6.9.1-3">For instance, the Map-Reply payload contains 3 mapping recordEID-prefixes: <list style="empty"> <t>2001:db8:102::/48</t> <t>2001:db8:103::/48</t> <t>2001:db8:200::/40</t> </list>EID-Prefixes: </t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.9.1-4"> <li pn="section-6.9.1-4.1">2001:db8:102::/48</li> <li pn="section-6.9.1-4.2">2001:db8:103::/48</li> <li pn="section-6.9.1-4.3">2001:db8:200::/40</li> </ul> <t indent="0" pn="section-6.9.1-5"> The EID-AD contains twoEID-prefixes: <list style="empty"> <t>2001:db8:103::/48</t> <t>2001:db8:203::/48</t> </list>EID-Prefixes: </t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-6.9.1-6"> <li pn="section-6.9.1-6.1">2001:db8:103::/48</li> <li pn="section-6.9.1-6.2">2001:db8:203::/48</li> </ul> <t indent="0" pn="section-6.9.1-7"> TheEID-recordEID-Record withEID-prefixEID-Prefix 2001:db8:102::/48 is not eligible to be used by theITRITR, since it is not included in any of the EID-ADs signed by the Map-Server. A log actionMUST<bcp14>MUST</bcp14> betakentaken, and theEID-record MUSTEID-Record <bcp14>MUST</bcp14> be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. </t><t>The EID-record<t indent="0" pn="section-6.9.1-8">The EID-Record withEID-prefixEID-Prefix 2001:db8:103::/48 is eligible to be used by the ITR because it matches the secondEID-prefixEID-Prefix contained in the EID-AD.</t><t>The EID-record<t indent="0" pn="section-6.9.1-9">The EID-Record withEID-prefixEID-Prefix 2001:db8:200::/40 is not eligible to be used by theITRITR, since it is not included in any of the EID-ADs signed by the Map-Server. A log actionMUST<bcp14>MUST</bcp14> be taken and theEID-record MUSTEID-Record <bcp14>MUST</bcp14> be discarded. Implementations may include mechanisms (which are beyond the scope of this document) to avoid log resource exhaustion attacks. In this lastexampleexample, the ETR is trying to over claim theEID-prefixEID-Prefix 2001:db8:200::/40, but the Map-Server authorized only2001:db8:203::/48, hence2001:db8:203::/48; hence, theEID-recordEID-Record is discarded.</t> </section> </section> </section> <section anchor="security"title="Security Considerations"> <t>Thisnumbered="true" toc="include" removeInRFC="false" pn="section-7"> <name slugifiedName="name-security-considerations">Security Considerations</name> <t indent="0" pn="section-7-1">This document extends the LISPControl-Planecontrol plane defined in <xreftarget="I-D.ietf-lisp-rfc6833bis"/>,target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>; hence, itsSecurity Considerationssecurity considerations applyas wellto thisdocument.document as well. </t> <section anchor="mapping-system"title="Mappingnumbered="true" toc="include" removeInRFC="false" pn="section-7.1"> <name slugifiedName="name-mapping-system-security">Mapping SystemSecurity"> <t>TheSecurity</name> <t indent="0" pn="section-7.1-1">The LISP-SEC threat model described in <xreftarget="threat-model"/>,target="threat-model" format="default" sectionFormat="of" derivedContent="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.</t><t>It<t indent="0" pn="section-7.1-2">It is assumed that the Mapping System ensures the confidentiality of theOTK,OTK and the integrity of the Map-Reply data. However, how the LISP Mapping System is secured is out of the scope of this document.</t><t>Similarly,<t indent="0" pn="section-7.1-3">Similarly, Map-Register security, including the right for a LISP entity to register anEID-prefixEID-Prefix or to claim presence at an RLOC, is out of the scope of LISP-SEC.</t> </section> <section anchor="random"title="Randomnumbered="true" toc="include" removeInRFC="false" pn="section-7.2"> <name slugifiedName="name-random-number-generation">Random NumberGeneration"> <t>TheGeneration</name> <t indent="0" pn="section-7.2-1">The ITR-OTKMUST<bcp14>MUST</bcp14> be generated by a properly seeded pseudo-random (or strong random) source. See <xreftarget="RFC4086"/>target="RFC4086" format="default" sectionFormat="of" derivedContent="RFC4086"/> for advice on generating security-sensitive random data.</t> </section> <section anchor="colocation"title="Map-Servernumbered="true" toc="include" removeInRFC="false" pn="section-7.3"> <name slugifiedName="name-map-server-and-etr-colocati">Map-Server and ETRColocation"> <t>IfColocation</name> <t indent="0" pn="section-7.3-1">If the Map-Server and the ETR are colocated, LISP-SEC does not provide protection from overclaiming attacks mounted by the ETR. However, in this particular case, since the ETR is within the trust boundaries of the Map-Server, ETR's overclaiming attacks are not included in the threat model.</t> </section> <section anchor="deploying"title="Deploying LISP-SEC"> <t>Thosenumbered="true" toc="include" removeInRFC="false" pn="section-7.4"> <name slugifiedName="name-deploying-lisp-sec">Deploying LISP-SEC</name> <t indent="0" pn="section-7.4-1">Those deploying LISP-SEC according to thismemo,memo should carefullyweightweigh 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 associated with the corresponding threats is well understood.</t><t>As<t indent="0" pn="section-7.4-2">As an example, in certain other deployments, attackers may be verysophisticated,sophisticated and force the deployers to enforce very strict policies intermterms of HMAC algorithms accepted by an ITR.</t><t>Similar<t indent="0" pn="section-7.4-3">Similar considerations apply to the entire LISP-SEC threatmodel,model and should guide the deployers and implementors whenever they encounter the key wordSHOULD<bcp14>SHOULD</bcp14> across this memo.</t> </section> <section anchor="provisioning"title="Sharednumbered="true" toc="include" removeInRFC="false" pn="section-7.5"> <name slugifiedName="name-shared-keys-provisioning">Shared KeysProvisioning"> <t>ProvisioningProvisioning</name> <t indent="0" pn="section-7.5-1">Provisioning of the keys shared between ITR and Map-Resolverparispairs as well as between ETR and Map-Server pairs should be performed via an orchestrationinfrastructureinfrastructure, anditis out of the scope of this memo. It is recommended that both shared keysarebe refreshed at periodical intervals to address key aging or attackers gaining unauthorized access to the shared keys. Shared keys should be unpredictable random values.</t> </section> <section anchor="reply"title="Replay Attacks"> <t>Annumbered="true" toc="include" removeInRFC="false" pn="section-7.6"> <name slugifiedName="name-replay-attacks">Replay Attacks</name> <t indent="0" pn="section-7.6-1">An attacker can capture a valid Map-Request and/or Map-Reply and replayit, howeverit; however, once the ITR receives the originalMap-ReplyMap-Reply, the <nonce,ITR-OTK> pair stored at the ITR will be discarded. If a replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK> that matches the incoming Map-Reply and the replayed Map-Reply will be discarded.</t><t>In<t indent="0" pn="section-7.6-2">In the case of a replayed Map-Request, the Map-Server,Map-ResolverMap-Resolver, and ETR will have to do a LISP-SEC computation. This is equivalent, in terms of resources, to a valid LISP-SEC computation and, beyond a risk of DoS attack, an attacker does not obtain any additional effect, since the corresponding Map-Reply is discarded as previously explained.</t> </section> <section anchor="DTLS"title="Message Privacy"> <t>DTLS <xref target="RFC9147"/> SHOULDnumbered="true" toc="include" removeInRFC="false" pn="section-7.7"> <name slugifiedName="name-message-privacy">Message Privacy</name> <t indent="0" pn="section-7.7-1">DTLS <xref target="RFC9147" format="default" sectionFormat="of" derivedContent="RFC9147"/> <bcp14>SHOULD</bcp14> be used (conforming to <xreftarget="RFC7525"/>)target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/>) to provide communication privacy and to prevent eavesdropping, tampering, or message forgery to the messages exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless the OTK is encrypted in another way,e.g.e.g., using a pre-shared secret. DTLS has the responder be verified by the initiator, which enables an ITR toautheticateauthenticate theMap-Resolver,Map-Resolver and the Map-Server to authenticate the responding ETR.</t> </section> <section anchor="dos"title="Denial of Servicenumbered="true" toc="include" removeInRFC="false" pn="section-7.8"> <name slugifiedName="name-denial-of-service-and-distr">Denial-of-Service and DistributedDenial of Service Attacks"> <t>LISP-SECDenial-of-Service Attacks</name> <t indent="0" pn="section-7.8-1">LISP-SEC mitigates the risks ofDenial of ServiceDoS andDistributed Denial of ServiceDDoS attacks by protecting the integrity and authenticating the origin of the Map-Request/Map-Replymessages,messages and by preventing malicious ETRs from overclaimingEID prefixesEID-Prefixes that couldre-directredirect traffic directed to a potentially large number of hosts.</t> </section> </section> <section anchor="IANA"title="IANA Considerations"> <t>IANA is requested to createnumbered="true" toc="include" removeInRFC="false" pn="section-8"> <name slugifiedName="name-iana-considerations">IANA Considerations</name> <t indent="0" pn="section-8-1">IANA has created thesub-registriessubregistries listed in the following sections in the "Locator/ID Separation Protocol (LISP) Parameters" registry. </t><t><t indent="0" pn="section-8-2"> For all of thesub-registries,subregistries, new valuesbeyond this document have to beare assigned according to the"Specification Required"Specification Required policy defined in <xreftarget="RFC8126"/>.target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. ExpertreviewReview should assess the security properties of newly addedfunctions,functions so that encryption robustnessisremains strong. For instance, at the time of thiswritingwriting, the use of SHA-256-based functions is considered to provide sufficient protection. Consultation with security experts may be needed. </t> <section anchor="ECM-AD-Type"title="ECMnumbered="true" toc="include" removeInRFC="false" pn="section-8.1"> <name slugifiedName="name-ecm-ad-type-registry">ECM AD TypeRegistry"> <t>IANA is requested to createRegistry</name> <t indent="0" pn="section-8.1-1">IANA has created the"ECM"LISP ECM Authentication DataType"Types" registry with values0-255,0-255 for use in the ECM LISP-SECExtensionsextensions (see <xreftarget="ECM_extensions"/>.target="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.1"/>). Initialallocation of this registry isallocations are shown in <xreftarget="tableEADT"/>.target="tableEADT" format="default" sectionFormat="of" derivedContent="Table 2"/>. </t><texttable<table anchor="tableEADT"title="ECMalign="center" pn="table-2"> <name slugifiedName="name-lisp-ecm-authentication-dat">LISP ECM Authentication DataTypes."> <ttcol align="left">Name</ttcol> <ttcol align="center">Number</ttcol> <ttcol align="left">Defined in</ttcol> <c>Reserved</c><c>0</c><c>This memo</c> <c>LISP-SEC-ECM-EXT</c><c>1</c><c>This memo</c> </texttable> <t>ValuesTypes</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Number</th> <th align="left" colspan="1" rowspan="1">Defined in</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">Reserved</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">LISP-SEC-ECM-EXT</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> </tbody> </table> <t indent="0" pn="section-8.1-3">Values 2-255 are unassigned. </t> </section> <section anchor="MR-AD-Type"title="Map-Replynumbered="true" toc="include" removeInRFC="false" pn="section-8.2"> <name slugifiedName="name-map-reply-ad-types-registry">Map-Reply ADType Registry"> <t>IANA is requested to createTypes Registry</name> <t indent="0" pn="section-8.2-1">IANA has created the"Map-Reply"LISP Map-Reply Authentication DataType"Types" registry with values0-255,0-255 for use in the Map-Reply LISP-SECExtensionsextensions (see <xreftarget="MR_extensions"/>.target="MR_extensions" format="default" sectionFormat="of" derivedContent="Section 6.2"/>). Initialallocation of this registry isallocations are shown in <xreftarget="tableADT"/>.target="tableADT" format="default" sectionFormat="of" derivedContent="Table 3"/>. </t><texttable<table anchor="tableADT"title="Map-Replyalign="center" pn="table-3"> <name slugifiedName="name-map-reply-authentication-da">Map-Reply Authentication DataTypes."> <ttcol align="left">Name</ttcol> <ttcol align="center">Number</ttcol> <ttcol align="left">Defined in</ttcol> <c>Reserved</c><c>0</c><c>This memo</c> <c>LISP-SEC-MR-EXT</c><c>1</c><c>This memo</c> </texttable> <t>ValuesTypes</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Number</th> <th align="left" colspan="1" rowspan="1">Defined in</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">Reserved</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">LISP-SEC-MR-EXT</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> </tbody> </table> <t indent="0" pn="section-8.2-3">Values 2-255 are unassigned. </t> </section> <section anchor="HMAC"title="HMAC Functions"> <t>IANAnumbered="true" toc="include" removeInRFC="false" pn="section-8.3"> <name slugifiedName="name-hmac-functions">HMAC Functions</name> <t indent="0" pn="section-8.3-1">IANA is requested to create the "LISP-SEC Preferred Authentication Data HMACID"IDs" registry with values 0-65535 for use as Requested HMACID,IDs, EID HMACID,IDs, and PKT HMACIDIDs in the LISP-SEC Authentication Data. Initialallocation of this registry isallocations are shown in <xreftarget="tableHMACF"/>.target="tableHMACF" format="default" sectionFormat="of" derivedContent="Table 4"/>. </t><texttable<table anchor="tableHMACF"title="LISP-SECalign="center" pn="table-4"> <name slugifiedName="name-lisp-sec-preferred-authenti">LISP-SEC Preferred Authentication Data HMACFunctions."> <ttcol align="left">Name</ttcol> <ttcol align="center">Number</ttcol> <ttcol align="left">Defined in</ttcol> <c>NOPREF</c><c>0</c><c>This memo</c> <c>AUTH-HMAC-SHA-1-96</c><c>1</c><c><xref target="RFC2104"/></c> <c>AUTH-HMAC-SHA-256-128</c><c>2</c><c><xref target="RFC6234"/></c> </texttable> <t>ValuesIDs</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Number</th> <th align="left" colspan="1" rowspan="1">Defined in</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">NOPREF</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">AUTH-HMAC-SHA-1-96</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1"> <xref target="RFC2104" format="default" sectionFormat="of" derivedContent="RFC2104"/></td> </tr> <tr> <td align="left" colspan="1" rowspan="1">AUTH-HMAC-SHA-256-128</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="left" colspan="1" rowspan="1"> <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6234"/></td> </tr> </tbody> </table> <t indent="0" pn="section-8.3-3">Values 3-65535 are unassigned.</t> </section> <section anchor="wrap"title="Keynumbered="true" toc="include" removeInRFC="false" pn="section-8.4"> <name slugifiedName="name-key-wrap-functions">Key WrapFunctions"> <t>IANA is requested to createFunctions</name> <t indent="0" pn="section-8.4-1">IANA has created the "LISP-SEC Authentication Data Key WrapID"IDs" registry with values 0-65535 for use as OTK key wrapalgorithms IDalgorithm IDs in the LISP-SEC Authentication Data. Initialallocation of this registry isallocations are shown in <xreftarget="tableKWF"/>.</t> <texttabletarget="tableKWF" format="default" sectionFormat="of" derivedContent="Table 5"/>.</t> <table anchor="tableKWF"title="LISP-SECalign="center" pn="table-5"> <name slugifiedName="name-lisp-sec-authentication-dat">LISP-SEC Authentication Data Key WrapFunctions."> <ttcol align="left">Name</ttcol> <ttcol align="center">Number</ttcol> <ttcol align="left">KEY WRAP</ttcol> <ttcol align="left">KDF</ttcol> <c>Reserved</c><c>0</c><c>None</c><c>None</c> <c>NULL-KEY-WRAP-128</c><c>1</c><c>This memo</c><c>None</c> <c>AES-KEY-WRAP-128+HKDF-SHA256</c><c>2</c><c><xref target="RFC3394"/></c><c><xref target="RFC4868"/></c> </texttable> <t/> <t>ValuesIDs</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Number</th> <th align="left" colspan="1" rowspan="1">Key Wrap</th> <th align="left" colspan="1" rowspan="1">KDF</th> <th align="left" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">Reserved</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="left" colspan="1" rowspan="1">None</td> <td align="left" colspan="1" rowspan="1">None</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">NULL-KEY-WRAP-128</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> <td align="left" colspan="1" rowspan="1">None</td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">AES-KEY-WRAP-128+HKDF-SHA256</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="left" colspan="1" rowspan="1"> <xref target="RFC3394" format="default" sectionFormat="of" derivedContent="RFC3394"/></td> <td align="left" colspan="1" rowspan="1"> <xref target="RFC4868" format="default" sectionFormat="of" derivedContent="RFC4868"/></td> <td align="left" colspan="1" rowspan="1">RFC 9303</td> </tr> </tbody> </table> <t indent="0" pn="section-8.4-3">Values 3-65535 are unassigned. </t> </section> <section anchor="kdf"title="Keynumbered="true" toc="include" removeInRFC="false" pn="section-8.5"> <name slugifiedName="name-key-derivation-functions">Key DerivationFunctions"> <t>IANA is requested to createFunctions</name> <t indent="0" pn="section-8.5-1">IANA has created the "LISP-SEC Authentication Data Key Derivation FunctionID"IDs" registry with values 0-65535 for use as KDFID.IDs. Initialallocation of this registry isallocations are shown in <xreftarget="tableKDF"/>.</t> <texttabletarget="tableKDF" format="default" sectionFormat="of" derivedContent="Table 6"/>.</t> <table anchor="tableKDF"title="LISP-SECalign="center" pn="table-6"> <name slugifiedName="name-lisp-sec-authentication-data">LISP-SEC Authentication Data Key Derivation FunctionID."> <ttcol width="20%" align="left">Name</ttcol> <ttcol width="20%" align="center">Number</ttcol> <ttcol align="center">Defined in</ttcol> <c>NOPREF</c><c>0</c><c>This memo</c> <c>HKDF-SHA1-128 </c><c>1</c><c><xref target="RFC5869"/></c> <c>HKDF-SHA256 </c><c>2</c><c><xref target="RFC5869"/></c> </texttable> <t>Values 2-65535IDs</name> <thead> <tr> <th align="left" colspan="1" rowspan="1">Name</th> <th align="center" colspan="1" rowspan="1">Number</th> <th align="center" colspan="1" rowspan="1">Reference</th> </tr> </thead> <tbody> <tr> <td align="left" colspan="1" rowspan="1">NOPREF</td> <td align="center" colspan="1" rowspan="1">0</td> <td align="center" colspan="1" rowspan="1">RFC 9303</td> </tr> <tr> <td align="left" colspan="1" rowspan="1">HKDF-SHA1-128</td> <td align="center" colspan="1" rowspan="1">1</td> <td align="center" colspan="1" rowspan="1"> <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/></td> </tr> <tr> <td align="left" colspan="1" rowspan="1">HKDF-SHA256</td> <td align="center" colspan="1" rowspan="1">2</td> <td align="center" colspan="1" rowspan="1"> <xref target="RFC5869" format="default" sectionFormat="of" derivedContent="RFC5869"/></td> </tr> </tbody> </table> <t indent="0" pn="section-8.5-3">Values 3-65535 are unassigned. </t> </section> </section> </middle> <back> <references pn="section-9"> <name slugifiedName="name-references">References</name> <references pn="section-9.1"> <name slugifiedName="name-normative-references">Normative References</name> <reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2104" quoteTitle="true" derivedAnchor="RFC2104"> <front> <title>HMAC: Keyed-Hashing for Message Authentication</title> <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/> <author fullname="M. Bellare" initials="M." surname="Bellare"/> <author fullname="R. Canetti" initials="R." surname="Canetti"/> <date month="February" year="1997"/> <abstract> <t indent="0">This document describes HMAC, a mechanism for message authentication using cryptographic hash functions. HMAC can be used with any iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a secret shared key. The cryptographic strength of HMAC depends on the properties of the underlying hash function. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind</t> </abstract> </front> <seriesInfo name="RFC" value="2104"/> <seriesInfo name="DOI" value="10.17487/RFC2104"/> </reference> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <abstract> <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="2119"/> <seriesInfo name="DOI" value="10.17487/RFC2119"/> </reference> <reference anchor="RFC3394" target="https://www.rfc-editor.org/info/rfc3394" quoteTitle="true" derivedAnchor="RFC3394"> <front> <title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title> <author fullname="J. Schaad" initials="J." surname="Schaad"/> <author fullname="R. Housley" initials="R." surname="Housley"/> <date month="September" year="2002"/> </front> <seriesInfo name="RFC" value="3394"/> <seriesInfo name="DOI" value="10.17487/RFC3394"/> </reference> <reference anchor="RFC4868" target="https://www.rfc-editor.org/info/rfc4868" quoteTitle="true" derivedAnchor="RFC4868"> <front> <title>Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec</title> <author fullname="S. Kelly" initials="S." surname="Kelly"/> <author fullname="S. Frankel" initials="S." surname="Frankel"/> <date month="May" year="2007"/> <abstract> <t indent="0">This specification describes the use of Hashed Message Authentication Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512 algorithms in IPsec. These algorithms may be used as the basis for data origin authentication and integrity verification mechanisms for the Authentication Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated output lengths are specified for the authentication-related variants, with the corresponding algorithms designated as HMAC-SHA-256-128, HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF-HMAC-SHA-512. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4868"/> <seriesInfo name="DOI" value="10.17487/RFC4868"/> </reference> <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869" quoteTitle="true" derivedAnchor="RFC5869"> <front> <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title> <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/> <author fullname="P. Eronen" initials="P." surname="Eronen"/> <date month="May" year="2010"/> <abstract> <t indent="0">This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used as a building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="5869"/> <seriesInfo name="DOI" value="10.17487/RFC5869"/> </reference> <reference anchor="RFC6234" target="https://www.rfc-editor.org/info/rfc6234" quoteTitle="true" derivedAnchor="RFC6234"> <front> <title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="T. Hansen" initials="T." surname="Hansen"/> <date month="May" year="2011"/> <abstract> <t indent="0">Federal Information Processing Standard, FIPS</t> </abstract> </front> <seriesInfo name="RFC" value="6234"/> <seriesInfo name="DOI" value="10.17487/RFC6234"/> </reference> <reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7525" quoteTitle="true" derivedAnchor="RFC7525"> <front> <title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title> <author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/> <author fullname="R. Holz" initials="R." surname="Holz"/> <author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre"/> <date month="May" year="2015"/> <abstract> <t indent="0">Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t> </abstract> </front> <seriesInfo name="BCP" value="195"/> <seriesInfo name="RFC" value="7525"/> <seriesInfo name="DOI" value="10.17487/RFC7525"/> </reference> <reference anchor="RFC7835" target="https://www.rfc-editor.org/info/rfc7835" quoteTitle="true" derivedAnchor="RFC7835"> <front> <title>Locator/ID Separation Protocol (LISP) Threat Analysis</title> <author fullname="D. Saucez" initials="D." surname="Saucez"/> <author fullname="L. Iannone" initials="L." surname="Iannone"/> <author fullname="O. Bonaventure" initials="O." surname="Bonaventure"/> <date month="April" year="2016"/> <abstract> <t indent="0">This document provides a threat analysis of the Locator/ID Separation Protocol (LISP).</t> </abstract> </front> <seriesInfo name="RFC" value="7835"/> <seriesInfo name="DOI" value="10.17487/RFC7835"/> </reference> <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126"> <front> <title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <author fullname="M. Cotton" initials="M." surname="Cotton"/> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <date month="June" year="2017"/> <abstract> <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t> <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t> <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t> </abstract> </front> <seriesInfo name="BCP" value="26"/> <seriesInfo name="RFC" value="8126"/> <seriesInfo name="DOI" value="10.17487/RFC8126"/> </reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <abstract> <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t> </abstract> </front> <seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/RFC8174"/> </reference> <reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9147" quoteTitle="true" derivedAnchor="RFC9147"> <front> <title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/> <author fullname="N. Modadugu" initials="N." surname="Modadugu"/> <date month="April" year="2022"/> <abstract> <t indent="0">This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t indent="0">The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t> <t indent="0">This document obsoletes RFC 6347.</t> </abstract> </front> <seriesInfo name="RFC" value="9147"/> <seriesInfo name="DOI" value="10.17487/RFC9147"/> </reference> <reference anchor="RFC9300" target="https://www.rfc-editor.org/info/rfc9300" quoteTitle="true" derivedAnchor="RFC9300"> <front> <title>The Locator/ID Separation Protocol (LISP)</title> <author initials="D" surname="Farinacci" fullname="Dino Farinacci"> <organization showOnFrontPage="true"/> </author> <author initials="V" surname="Fuller" fullname="Vince Fuller"> <organization showOnFrontPage="true"/> </author> <author initials="D" surname="Meyer" fullname="David Meyer"> <organization showOnFrontPage="true"/> </author> <author initials="D" surname="Lewis" fullname="Darrel Lewis"> <organization showOnFrontPage="true"/> </author> <author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2022" month="October"/> </front> <seriesInfo name="RFC" value="9300"/> <seriesInfo name="DOI" value="10.17487/RFC9300"/> </reference> <reference anchor="RFC9301" target="https://www.rfc-editor.org/info/rfc9301" quoteTitle="true" derivedAnchor="RFC9301"> <front> <title>Locator/ID Separation Protocol (LISP) Control Plane</title> <author initials="D" surname="Farinacci" fullname="Dino Farinacci"> <organization showOnFrontPage="true"/> </author> <author initials="F" surname="Maino" fullname="Fabio Maino"> <organization showOnFrontPage="true"/> </author> <author initials="V" surname="Fuller" fullname="Vince Fuller"> <organization showOnFrontPage="true"/> </author> <author initials="A" surname="Cabellos" fullname="Albert Cabellos" role="editor"> <organization showOnFrontPage="true"/> </author> <date year="2022" month="October"/> </front> <seriesInfo name="RFC" value="9301"/> <seriesInfo name="DOI" value="10.17487/RFC9301"/> </reference> </references> <references pn="section-9.2"> <name slugifiedName="name-informative-references">Informative References</name> <reference anchor="RFC4086" target="https://www.rfc-editor.org/info/rfc4086" quoteTitle="true" derivedAnchor="RFC4086"> <front> <title>Randomness Requirements for Security</title> <author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3rd"/> <author fullname="J. Schiller" initials="J." surname="Schiller"/> <author fullname="S. Crocker" initials="S." surname="Crocker"/> <date month="June" year="2005"/> <abstract> <t indent="0">Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t> <t indent="0">Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t> </abstract> </front> <seriesInfo name="BCP" value="106"/> <seriesInfo name="RFC" value="4086"/> <seriesInfo name="DOI" value="10.17487/RFC4086"/> </reference> <reference anchor="RFC6836" target="https://www.rfc-editor.org/info/rfc6836" quoteTitle="true" derivedAnchor="RFC6836"> <front> <title>Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)</title> <author fullname="V. Fuller" initials="V." surname="Fuller"/> <author fullname="D. Farinacci" initials="D." surname="Farinacci"/> <author fullname="D. Meyer" initials="D." surname="Meyer"/> <author fullname="D. Lewis" initials="D." surname="Lewis"/> <date month="January" year="2013"/> <abstract> <t indent="0">This document describes a simple distributed index system to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds the mapping information for a particular Endpoint Identifier (EID). The MR can then query that ETR to obtain the actual mapping information, which consists of a list of Routing Locators (RLOCs) for the EID. Termed the Alternative Logical Topology (ALT), the index is built as an overlay network on the public Internet using the Border Gateway Protocol (BGP) and Generic Routing Encapsulation (GRE). This document defines an Experimental Protocol for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="6836"/> <seriesInfo name="DOI" value="10.17487/RFC6836"/> </reference> </references> </references> <sectionanchor="Acknowledgements" title="Acknowledgements"> <t>Theanchor="Acknowledgments" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a"> <name slugifiedName="name-acknowledgments">Acknowledgments</name> <t indent="0" pn="section-appendix.a-1">The authors would like to acknowledgeLuigi Iannone, Pere Monclus, Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis<contact fullname="Luigi Iannone"/>, <contact fullname="Pere Monclus"/>, <contact fullname="Dave Meyer"/>, <contact fullname="Dino Farinacci"/>, <contact fullname="Brian Weis"/>, <contact fullname="David McGrew"/>, <contact fullname="Darrel Lewis"/>, andLandon<contact fullname="Landon CurtNollNoll"/> for their valuable suggestions provided during the preparation of this document.</t> </section></middle> <back> <references title="Normative References"> <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-rfc6833bis.xml'?> <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-rfc6830bis.xml'?> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.8126"?> <?rfc include="reference.RFC.4868"?> <?rfc include="reference.RFC.9147"?> <?rfc include="reference.RFC.8174"?> <?rfc include="reference.RFC.7835"?> <?rfc include="reference.RFC.6234"?> <?rfc include="reference.RFC.5869"?> <?rfc include="reference.RFC.3394"?> <?rfc include="reference.RFC.2104"?> <?rfc include="reference.RFC.7525"?> </references> <references title="Informational References"> <?rfc include="reference.RFC.4086"?> <?rfc include="reference.RFC.6836"?> </references><section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b"> <name slugifiedName="name-authors-addresses">Authors' Addresses</name> <author fullname="Fabio Maino" initials="F" surname="Maino"> <organization showOnFrontPage="true">Cisco Systems</organization> <address> <postal> <street/> <city>San Jose</city> <code/> <region>CA</region> <country>United States of America</country> </postal> <email>fmaino@cisco.com</email> </address> </author> <author fullname="Vina Ermagan" initials="V" surname="Ermagan"> <organization showOnFrontPage="true">Google, Inc.</organization> <address> <postal> <street>1600 Amphitheatre Parkway</street> <city>Mountain View</city> <region>CA</region> <code>94043</code> <country>United States of America</country> </postal> <email>ermagan@gmail.com</email> </address> </author> <author fullname="Albert Cabellos" initials="A" surname="Cabellos"> <organization showOnFrontPage="true">Universitat Politecnica de Catalunya</organization> <address> <postal> <street>c/ Jordi Girona s/n</street> <city>Barcelona</city> <code>08034</code> <region/> <country>Spain</country> </postal> <email>acabello@ac.upc.edu</email> </address> </author> <author fullname="Damien Saucez" initials="D" surname="Saucez"> <organization showOnFrontPage="true">Inria</organization> <address> <postal> <street>2004 route des Lucioles - BP 93</street> <city>Sophia Antipolis</city> <code/> <region/> <country>France</country> </postal> <email>damien.saucez@inria.fr</email> </address> </author> </section> </back> </rfc>