rfc9303xml2.original.xml   rfc9303.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<?rfc toc="yes"?> nsus="true" docName="draft-ietf-lisp-sec-29" indexInclude="true" ipr="trust20090
<?rfc tocompact="yes"?> 2" number="9303" prepTime="2022-10-19T14:23:12" scripts="Common,Latin" sortRefs=
<?rfc tocdepth="3"?> "true" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:l
<?rfc tocindent="yes"?> ang="en">
<?rfc symrefs="yes"?> <link href="https://datatracker.ietf.org/doc/draft-ietf-lisp-sec-29" rel="prev
<?rfc sortrefs="yes"?> "/>
<?rfc comments="yes"?> <link href="https://dx.doi.org/10.17487/rfc9303" rel="alternate"/>
<?rfc inline="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-lisp-sec-29" ipr="trust200902">
<front> <front>
<title abbrev="LISP-SEC">LISP-Security (LISP-SEC)</title> <title abbrev="LISP-SEC">Locator/ID Separation Protocol Security (LISP-SEC)<
/title>
<author fullname="Fabio Maino" initials="F.M" surname="Maino"> <seriesInfo name="RFC" value="9303" stream="IETF"/>
<organization>Cisco Systems</organization> <author fullname="Fabio Maino" initials="F" surname="Maino">
<organization showOnFrontPage="true">Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street>170 Tasman Drive</street> <street/>
<city>San Jose</city> <city>San Jose</city>
<code/>
<code>95134</code> <region>CA</region>
<country>United States of America</country>
<region>California</region>
<country>USA</country>
</postal> </postal>
<email>fmaino@cisco.com</email> <email>fmaino@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Vina Ermagan" initials="V" surname="Ermagan">
<author fullname="Vina Ermagan" initials="V.E" surname="Ermagan"> <organization showOnFrontPage="true">Google, Inc.</organization>
<organization>Google</organization>
<address> <address>
<postal> <postal>
<street/> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<city/> <region>CA</region>
<code>94043</code>
<code/> <country>United States of America</country>
<region>California</region>
<country>USA</country>
</postal> </postal>
<email>ermagan@gmail.com</email> <email>ermagan@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Albert Cabellos" initials="A" surname="Cabellos">
<author fullname="Albert Cabellos" initials="A.C" surname="Cabellos"> <organization showOnFrontPage="true">Universitat Politecnica de Catalunya<
<organization>Universitat Politecnica de Catalunya</organization> /organization>
<address> <address>
<postal> <postal>
<street>c/ Jordi Girona s/n</street> <street>c/ Jordi Girona s/n</street>
<city>Barcelona</city> <city>Barcelona</city>
<code>08034</code> <code>08034</code>
<region/> <region/>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>acabello@ac.upc.edu</email> <email>acabello@ac.upc.edu</email>
</address> </address>
</author> </author>
<author fullname="Damien Saucez" initials="D" surname="Saucez">
<author fullname="Damien Saucez" initials="D.S" surname="Saucez"> <organization showOnFrontPage="true">Inria</organization>
<organization>Inria</organization>
<address> <address>
<postal> <postal>
<street>2004 route des Lucioles - BP 93</street> <street>2004 route des Lucioles - BP 93</street>
<city>Sophia Antipolis</city> <city>Sophia Antipolis</city>
<code/> <code/>
<region/> <region/>
<country>France</country> <country>France</country>
</postal> </postal>
<email>damien.saucez@inria.fr</email> <email>damien.saucez@inria.fr</email>
</address> </address>
</author> </author>
<date month="10" year="2022"/>
<date /> <area>rtg</area>
<workgroup>lisp</workgroup>
<area>Internet</area> <keyword>LISP</keyword>
<keyword>deployment</keyword>
<workgroup>Network Working Group</workgroup> <abstract pn="section-abstract">
<t indent="0" pn="section-abstract-1">This memo specifies Locator/ID Separ
<keyword>LISP; deployment</keyword> ation Protocol Security (LISP-SEC), a set of security mechanisms
that provides origin authentication, integrity, and anti-replay protection
<abstract> to the
<t>This memo specifies LISP-SEC, a set of security mechanisms that LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed
provides origin authentication, integrity and anti-replay protection to via the mapping lookup process.
LISP's EID-to-RLOC mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims
LISP-SEC also enables verification of authorization on EID-prefix claims
in Map-Reply messages.</t> in Map-Reply messages.</t>
</abstract> </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="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" 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" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="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 der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-requirements-n
otation">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 der
ivedContent="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" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-lisp-sec-threat-model">LISP-SEC Th
reat Model</xref></t>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-operations">Protocol Oper
ations</xref></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="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="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-encapsulated-control-m
essag">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 derived
Content="" format="title" sectionFormat="of" target="name-map-reply-lisp-sec-ext
ensio">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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-itr-processing-generat
ing-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 derived
Content="" format="title" sectionFormat="of" target="name-encrypting-and-decrypt
ing-a">Encrypting and Decrypting an OTK</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="6.5.1" format="counter" sectionFormat="of" target="section-6.5.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-unencrypte
d-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 derived
Content="" format="title" sectionFormat="of" target="name-map-resolver-processin
g">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 derived
Content="" format="title" sectionFormat="of" target="name-map-server-processing"
>Map-Server Processing</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="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</xre
f></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 derived
Content="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 derived
Content="" format="title" sectionFormat="of" target="name-etr-processing">ETR Pr
ocessing</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 derived
Content="" format="title" sectionFormat="of" target="name-itr-processing-receivi
ng-a-">ITR Processing: Receiving a Map-Reply</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-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 derived
Content="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" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" format="title" sectionFormat="of" target="name-mapping-system-securit
y">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 derived
Content="" format="title" sectionFormat="of" target="name-random-number-generati
on">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 derived
Content="" format="title" sectionFormat="of" target="name-map-server-and-etr-col
ocati">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 derived
Content="" format="title" sectionFormat="of" target="name-deploying-lisp-sec">De
ploying 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 derived
Content="" format="title" sectionFormat="of" target="name-shared-keys-provisioni
ng">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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-message-privacy">Messa
ge 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 derived
Content="" 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" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" format="title" sectionFormat="of" target="name-map-reply-ad-types-reg
istry">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 derived
Content="" format="title" sectionFormat="of" target="name-hmac-functions">HMAC F
unctions</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 derived
Content="" format="title" sectionFormat="of" target="name-key-wrap-functions">Ke
y 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 derived
Content="" format="title" sectionFormat="of" target="name-key-derivation-functio
ns">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" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-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 derived
Content="" 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 derived
Content="" 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="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn
<t>The Locator/ID Separation Protocol <xref ="section-1">
target="I-D.ietf-lisp-rfc6830bis"/>,<xref <name slugifiedName="name-introduction">Introduction</name>
target="I-D.ietf-lisp-rfc6833bis"/> is a network-layer-based protocol <t indent="0" pn="section-1-1">The Locator/ID Separation Protocol (LISP) <
xref target="RFC9300" format="default" sectionFormat="of" derivedContent="RFC930
0"/> <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: that enables separation of IP addresses into two new numbering spaces:
Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). EID-to-RLOC Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). EID-to-RLOC
mappings are stored in a database, the LISP Mapping System, and made mappings are stored in a database and the LISP Mapping System, and they ar e made
available via the Map-Request/Map-Reply lookup process. If these available via the Map-Request/Map-Reply lookup process. If these
EID-to-RLOC mappings, carried through Map-Reply messages, are EID-to-RLOC mappings, carried through Map-Reply messages, are
transmitted without integrity protection, an adversary can manipulate transmitted without integrity protection, an adversary can manipulate
them and hijack the communication, impersonate the requested EID, or them and hijack the communication, impersonate the requested EID, or
mount Denial of Service or Distributed Denial of Service attacks. Also, mount Denial-of-Service (DoS) or Distributed Denial-of-Service (DDoS) atta cks. Also,
if the Map-Reply message is transported unauthenticated, an adversarial if the Map-Reply message is transported unauthenticated, an adversarial
LISP entity can overclaim an EID-prefix and maliciously redirect traffic. LISP entity can overclaim an EID-Prefix and maliciously redirect traffic.
The LISP-SEC threat model, The LISP-SEC threat model,
described in <xref target="threat-model"/>, is built on top of the LISP described in <xref target="threat-model" format="default" sectionFormat="o
threat model defined in <xref target="RFC7835"/>, that includes a f" derivedContent="Section 4"/>, is built on top of the LISP
detailed description of "overclaiming" attack.</t> threat model defined in <xref target="RFC7835" format="default" sectionFor
mat="of" derivedContent="RFC7835"/>, which includes a
<t>This memo specifies LISP-SEC, a set of security mechanisms that detailed description of an "overclaiming" attack.</t>
provides origin authentication, integrity and anti-replay protection to <t indent="0" pn="section-1-2">This memo specifies LISP-SEC, a set of secu
LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. rity mechanisms that
LISP-SEC also enables verification of authorization on EID-prefix claims provides origin authentication, integrity, 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 on EID-Prefix claims
in Map-Reply messages, ensuring that the sender of a Map-Reply that in Map-Reply messages, ensuring that the sender of a Map-Reply that
provides the location for a given EID-prefix is entitled to do so provides the location for a given EID-Prefix is entitled to do so
according to the EID prefix registered in the associated Map-Server. according to the EID-Prefix registered in the associated Map-Server.
Map-Register/Map-Notify security, including the right for a LISP entity Map-Register/Map-Notify security, including the right for a LISP entity
to register an EID-prefix or to claim presence at an RLOC, is out of the to register an EID-Prefix or to claim presence at an RLOC, is out of the
scope of LISP-SEC as those protocols are protected by the security scope of LISP-SEC, as those protocols are protected by the security
mechanisms specified in <xref target="I-D.ietf-lisp-rfc6833bis"/>. mechanisms specified in <xref target="RFC9301" format="default" sectionFor
However, LISP-SEC extends the Map-Register message to allow an ITR to mat="of" derivedContent="RFC9301"/>.
downgrade to non LISP-SEC Map-Requests. Additional security However, LISP-SEC extends the Map-Register message to allow an Ingress Tun
considerations are described in Section 6.</t> nel
Router (ITR) to
downgrade to non-LISP-SEC Map-Requests. Additional security
considerations are described in <xref target="security" format="default" s
ectionFormat="of" derivedContent="Section 7"/>.</t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-2">
<section title="Requirements Notation"> <name slugifiedName="name-requirements-notation">Requirements Notation</na
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", me>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
"OPTIONAL" in this document are to be interpreted as described in BCP 14 4>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</b
cp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
"<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as describe
d in BCP 14
<xref target="RFC2119" format="default" sectionFormat="of" derivedContent="R
FC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedCont
ent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here. appear in all capitals, as shown here.
</t> </t>
</section> <!-- Requirements Notation --> </section>
<section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="terms" title="Definition of Terms"> ="section-3">
<t><list style="empty"> <name slugifiedName="name-definitions-of-terms">Definitions of Terms</name
<t>One-Time Key (OTK): An ephemeral randomly generated key that must >
be used for a single Map-Request/Map-Reply exchange.</t> <dl newline="false" indent="3" spacing="normal" pn="section-3-1">
<dt pn="section-3-1.1">One-Time Key (OTK):</dt>
<t>ITR One-Time Key (ITR-OTK): The One-Time Key generated at the <dd pn="section-3-1.2">An ephemeral randomly generated key that must
Ingress Tunnel Router (ITR).</t> be used for a single Map-Request/Map-Reply exchange.</dd>
<dt pn="section-3-1.3">ITR One-Time Key (ITR-OTK):</dt>
<t>MS One-Time Key (MS-OTK): The One-Time Key generated at the <dd pn="section-3-1.4">The One-Time Key generated at the
Map-Server.</t> Ingress Tunnel Router (ITR).</dd>
<dt pn="section-3-1.5">MS One-Time Key (MS-OTK):</dt>
<t>Authentication Data (AD): Metadata that is included either in a <dd pn="section-3-1.6">The One-Time Key generated at the
LISP Encapsulated Control Message (ECM) header, as defined in <xref Map-Server.</dd>
target="I-D.ietf-lisp-rfc6833bis"/>, or in a Map-Reply message to <dt pn="section-3-1.7">Authentication Data (AD):</dt>
<dd pn="section-3-1.8">Metadata that is included either in a
LISP Encapsulated Control Message (ECM) header as defined in <xref tar
get="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, or
in a Map-Reply message to
support confidentiality, integrity protection, and verification of support confidentiality, integrity protection, and verification of
EID-prefix authorization.</t> EID-Prefix authorization.</dd>
<dt pn="section-3-1.9">OTK Authentication Data (OTK-AD):</dt>
<t>OTK Authentication Data (OTK-AD): The portion of ECM <dd pn="section-3-1.10">The portion of ECM
Authentication Data that contains a One-Time Key.</t> Authentication Data that contains a One-Time Key.</dd>
<dt pn="section-3-1.11">EID Authentication Data (EID-AD):</dt>
<t>EID Authentication Data (EID-AD): The portion of ECM and <dd pn="section-3-1.12">The portion of ECM and
Map-Reply Authentication Data used for verification of EID-prefix Map-Reply Authentication Data used for verification of EID-Prefix
authorization.</t> authorization.</dd>
<dt pn="section-3-1.13">Packet Authentication Data (PKT-AD):</dt>
<t>Packet Authentication Data (PKT-AD): The portion of Map-Reply <dd pn="section-3-1.14">The portion of Map-Reply
Authentication Data used to protect the integrity of the Map-Reply Authentication Data used to protect the integrity of the Map-Reply
message.</t> message.</dd>
</dl>
<t/> <t indent="0" pn="section-3-2">For definitions of other terms, notably Map
</list>For definitions of other terms, notably Map-Request, Map-Reply, -Request, Map-Reply,
Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server
(MS), and Map-Resolver (MR) please consult the LISP specification <xref (MS), and Map-Resolver (MR), please consult the LISP specification <xref t
target="I-D.ietf-lisp-rfc6833bis"/>.</t> arget="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.<
/t>
</section> </section>
<section anchor="threat-model" numbered="true" toc="include" removeInRFC="fa
<section anchor="threat-model" title="LISP-SEC Threat Model"> lse" pn="section-4">
<t>LISP-SEC addresses the control plane threats, described in section <name slugifiedName="name-lisp-sec-threat-model">LISP-SEC Threat Model</na
3.7 and 3.8 of <xref target="RFC7835"/>, that target EID-to-RLOC me>
mappings, including manipulations of Map-Request and Map-Reply messages, <t indent="0" pn="section-4-1">LISP-SEC addresses the control plane threat
and malicious ETR EID prefix overclaiming. LISP-SEC makes two main s, described in Sections
assumptions: (1) the LISP mapping system is expected to deliver a <xref target="RFC7835" section="3.7" sectionFormat="bare" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc7835#section-3.7" derivedContent="RF
C7835"/> and
<xref target="RFC7835" section="3.8" sectionFormat="bare" format="default"
derivedLink="https://rfc-editor.org/rfc/rfc7835#section-3.8" derivedContent="RF
C7835"/> of <xref target="RFC7835" format="default" sectionFormat="of" derivedCo
ntent="RFC7835"/>, that target EID-to-RLOC
mappings, including manipulations of Map-Request and Map-Reply messages
and malicious ETR EID-Prefix overclaiming. LISP-SEC makes two main
assumptions: (1) the LISP Mapping System is expected to deliver a
Map-Request message to their intended destination ETR as identified by Map-Request message to their intended destination ETR as identified by
the EID, and (2) no on-path attack can be mounted the EID, and (2) no on-path attack can be mounted
within the LISP Mapping System. How the Mapping System is protected from within the LISP Mapping System. How the Mapping System is protected from
on-path attacks depends from the particular Mapping System used, and is on-path attacks depends on the particular Mapping System used and is
out of the scope of this memo. Furthermore, while LISP-SEC enables out of the scope of this memo. Furthermore, while LISP-SEC enables
detection of EID prefix overclaiming attacks, it assumes that detection of EID-Prefix overclaiming attacks, it assumes that
Map-Servers can verify the EID prefix authorization at registration time. Map-Servers can verify the EID-Prefix authorization at registration time.
</t> </t>
<t indent="0" pn="section-4-2">According to the threat model described in
<t>According to the threat model described in <xref target="RFC7835"/> <xref target="RFC7835" format="default" sectionFormat="of" derivedContent="RFC78
35"/>,
LISP-SEC assumes that any kind of attack, including on-path attacks, can b e LISP-SEC assumes that any kind of attack, including on-path attacks, can b e
mounted outside of the boundaries of the LISP mapping system. An on-path mounted outside of the boundaries of the LISP Mapping System. An on-path
attacker, outside of the LISP mapping system can, for example, hijack attacker outside of the LISP Mapping System can, for example, hijack
Map-Request and Map-Reply messages, spoofing the identity of a LISP Map-Request and Map-Reply messages, spoofing the identity of a LISP
node. Another example of on-path attack, called overclaiming attack, can node. Another example of an on-path attack, called an overclaiming attack,
be mounted by a malicious Egress Tunnel Router (ETR), by overclaiming can
the EID-prefixes for which it is authoritative. In this way the ETR can be mounted by a malicious ETR by overclaiming
the EID-Prefixes for which it is authoritative. In this way, the ETR can
maliciously redirect traffic.</t> maliciously redirect traffic.</t>
</section> </section>
<section anchor="operations" numbered="true" toc="include" removeInRFC="fals
<section anchor="operations" title="Protocol Operations"> e" pn="section-5">
<t>The goal of the security mechanisms defined in <xref <name slugifiedName="name-protocol-operations">Protocol Operations</name>
target="I-D.ietf-lisp-rfc6833bis"/> is to prevent unauthorized insertion <t indent="0" pn="section-5-1">The goal of the security mechanisms defined
in <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="R
FC9301"/> is to prevent unauthorized insertion
of mapping data by providing origin authentication and integrity of mapping data by providing origin authentication and integrity
protection for the Map-Register, and by using the nonce to detect protection for the Map-Register and by using the nonce to detect an
unsolicited Map-Reply sent by off-path attackers.</t> unsolicited Map-Reply sent by off-path attackers.</t>
<t indent="0" pn="section-5-2">LISP-SEC builds on top of the security mech
<t>LISP-SEC builds on top of the security mechanisms defined in to address anisms defined in <xref target="RFC9301" format="default" sectionFormat="of" der
the threats described in ivedContent="RFC9301"/> to address the threats described in
<xref target="threat-model"/> by leveraging the trust relationships <xref target="threat-model" format="default" sectionFormat="of" derivedCon
existing among the LISP entities (<xref target="I-D.ietf-lisp-rfc6833bis"/ tent="Section 4"/> by leveraging the trust relationships
>) participating in the exchange of the Map-Request/Map-Reply messages. existing among the LISP entities <xref target="RFC9301" format="default" s
Those trust relationships (see also <xref target="security"/> and <xref ta ectionFormat="of" derivedContent="RFC9301"/> participating in the exchange of th
rget="I-D.ietf-lisp-rfc6833bis"/>) are used to securely distribute, as described e Map-Request/Map-Reply messages.
in <xref target="wrap"/>, a per-message One-Time Key (OTK) that provides origin Those trust relationships (see also <xref target="security" format="defaul
authentication, integrity and anti-replay protection to mapping data conveyed v t" sectionFormat="of" derivedContent="Section 7"/> and <xref target="RFC9301" fo
ia the rmat="default" sectionFormat="of" derivedContent="RFC9301"/>) are used to secure
mapping lookup process, and that effectively prevent overclaiming ly distribute, as described in <xref target="wrap" format="default" sectionForma
t="of" derivedContent="Section 8.4"/>, a per-message One-Time Key (OTK) that pro
vides origin authentication, integrity, and anti-replay protection to mapping da
ta conveyed via the
mapping lookup process and that effectively prevents overclaiming
attacks. The processing of security parameters during the attacks. The processing of security parameters during the
Map-Request/Map-Reply exchange is as follows:</t> Map-Request/Map-Reply exchange is as follows:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5-3
<t><list style="symbols"> ">
<t>Per each Map-Request message a new ITR-OTK is generated and <li pn="section-5-3.1">Per each Map-Request message, a new ITR-OTK is ge
stored at the ITR, and securely transported to the Map-Server.</t> nerated and
stored at the ITR and is securely transported to the Map-Server.</li>
<t>The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for <li pn="section-5-3.2">The Map-Server uses the ITR-OTK to compute a Hash
Message Authentication (HMAC) <xref target="RFC2104"/> that protects ed Message Authentication Code (HMAC) <xref target="RFC2104" format="default" se
ctionFormat="of" derivedContent="RFC2104"/> that protects
the integrity of the mapping data known to the Map-Server to prevent the integrity of the mapping data known to the Map-Server to prevent
overclaiming attacks. The Map-Server also derives a new OTK, the overclaiming attacks. The Map-Server also derives a new OTK, the
MS-OTK, that is passed to the ETR, by applying a Key Derivation MS-OTK, that is passed to the ETR by applying a Key Derivation
Function (KDF) (e.g. <xref target="RFC5869"/>) to the ITR-OTK.</t> Function (KDF) (e.g., <xref target="RFC5869" format="default" sectionF
ormat="of" derivedContent="RFC5869"/>) to the ITR-OTK.</li>
<t>The ETR uses the MS-OTK to compute an HMAC that protects the <li pn="section-5-3.3">The ETR uses the MS-OTK to compute an HMAC that p
integrity of the Map-Reply sent to the ITR.</t> rotects the
integrity of the Map-Reply sent to the ITR.</li>
<t>Finally, the ITR uses the stored ITR-OTK to verify the integrity <li pn="section-5-3.4">Finally, the ITR uses the stored ITR-OTK to verif
y the integrity
of the mapping data provided by both the Map-Server and the ETR, and 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 to verify that no overclaiming attacks were mounted along the path
between the Map-Server and the ITR.</t> between the Map-Server and the ITR.</li>
</list></t> </ul>
<t indent="0" pn="section-5-4"><xref target="encap" format="default" secti
<t><xref target="encap"/> provides the detailed description of the onFormat="of" derivedContent="Section 6"/> provides the detailed description of
the
LISP-SEC control messages and their processing, while the rest of this LISP-SEC control messages and their processing, while the rest of this
section describes the flow of LISP protocol operations at each entity section describes the flow of LISP protocol operations at each entity
involved in the Map-Request/Map-Reply exchange:</t> involved in the Map-Request/Map-Reply exchange:</t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-5-5"
<t><list style="numbers"> >
<t>The ITR, upon needing to transmit a Map-Request message, <li pn="section-5-5.1" derivedCounter="1.">The ITR, upon needing to trans
generates and stores an OTK (ITR-OTK). This ITR-OTK is encrypted and i mit a Map-Request message,
ncluded into the Encapsulated Control Message (ECM) that contains the Map-Reques generates and stores an OTK (ITR-OTK). This ITR-OTK is encrypted and
t sent to the Map-Resolver. </t> included into the Encapsulated Control Message (ECM) that contains the
Map-Request sent to the Map-Resolver. </li>
<t>The Map-Resolver decapsulates the ECM message, decrypts the <li pn="section-5-5.2" derivedCounter="2.">The Map-Resolver decapsulates
ITR-OTK, if needed, and forwards through the Mapping System the the ECM, decrypts the
received Map-Request and the ITR-OTK, as part of a new ECM message. ITR-OTK (if needed), and forwards through the Mapping System the
received Map-Request and the ITR-OTK, as part of a new ECM.
The LISP Mapping System delivers the ECM to the appropriate The LISP Mapping System delivers the ECM to the appropriate
Map-Server, as identified by the EID destination address of the Map-Server, as identified by the EID destination address of the
Map-Request. </t> Map-Request. </li>
<li pn="section-5-5.3" derivedCounter="3.">The Map-Server is configured
<t>The Map-Server is configured with the location mappings and with the location mappings and
policy information for the ETR responsible for the EID destination policy information for the ETR responsible for the EID destination
address. Using this preconfigured information, the Map-Server, after address. Using this preconfigured information, the Map-Server, after
the decapsulation of the ECM message, finds the longest match the decapsulation of the ECM, finds the longest-match
EID-prefix that covers the requested EID in the received EID-Prefix that covers the requested EID in the received
Map-Request. The Map-Server adds this EID-prefix, together with an Map-Request. The Map-Server adds this EID-Prefix, together with an
HMAC computed using the ITR-OTK, to a new Encapsulated Control HMAC computed using the ITR-OTK, to a new ECM
Message that contains the received Map-Request.</t> that contains the received Map-Request.</li>
<li pn="section-5-5.4" derivedCounter="4.">The Map-Server derives a new
<t>The Map-Server derives a new OTK, the MS-OTK, by applying a Key OTK, the MS-OTK, by applying a KDF to the ITR-OTK. This MS-OTK is included in
Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included in the ECM that the Map-Server uses to forward
the Encapsulated Control Message that the Map-Server uses to forward the Map-Request to the ETR. </li>
the Map-Request to the ETR. </t> <li pn="section-5-5.5" derivedCounter="5.">If the Map-Server is acting i
n proxy mode, as specified in <xref target="RFC9301" format="default" sectionFor
<t>If the Map-Server is acting in proxy mode, as specified in <xref mat="of" derivedContent="RFC9301"/>, the ETR is not involved in the
target="I-D.ietf-lisp-rfc6833bis"/>, the ETR is not involved in the
generation of the Map-Reply and steps 6 and 7 are skipped. In this generation of the Map-Reply and steps 6 and 7 are skipped. In this
case the Map-Server generates the Map-Reply on behalf of the ETR as case, the Map-Server generates the Map-Reply on behalf of the ETR, as
described in <xref target="proxy"/>.</t> described in <xref target="proxy" format="default" sectionFormat="of"
derivedContent="Section 6.7.2"/>.</li>
<t>The ETR, upon receiving the ECM encapsulated Map-Request from the <li pn="section-5-5.6" derivedCounter="6.">The ETR, upon receiving the E
Map-Server, decrypts the MS-OTK, if needed, and originates a CM-Encapsulated Map-Request from the
Map-Server, decrypts the MS-OTK (if needed), and originates a
Map-Reply that contains the EID-to-RLOC mapping information as Map-Reply that contains the EID-to-RLOC mapping information as
specified in <xref target="I-D.ietf-lisp-rfc6833bis"/>.</t> specified in <xref target="RFC9301" format="default" sectionFormat="of
" derivedContent="RFC9301"/>.</li>
<t>The ETR computes an HMAC over the Map-Reply, keyed with MS-OTK to <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 protect the integrity of the whole Map-Reply. The ETR also copies
the EID-prefix authorization data that the Map-Server included in the EID-Prefix authorization data that the Map-Server included in
the ECM encapsulated Map-Request into the Map-Reply message. The ETR the ECM-Encapsulated Map-Request into the Map-Reply message. The ETR
then sends the complete Map-Reply message to the requesting ITR.</t> then sends the complete Map-Reply message to the requesting ITR.</li>
<li pn="section-5-5.8" derivedCounter="8.">The ITR, upon receiving the M
<t>The ITR, upon receiving the Map-Reply, uses the locally stored ap-Reply, uses the locally stored
ITR-OTK to verify the integrity of the EID-prefix authorization data ITR-OTK to verify the integrity of the EID-Prefix authorization data
included in the Map-Reply by the Map-Server. The ITR computes the included in the Map-Reply by the Map-Server. The ITR computes the
MS-OTK by applying the same KDF (as specified in the ECM MS-OTK by applying the same KDF (as specified in the ECM-Encapsulated
encapsulated Map-Reply) used by the Map-Server, and verifies the Map-Reply) used by the Map-Server and verifies the
integrity of the Map-Reply. </t> integrity of the Map-Reply. </li>
</list></t> </ol>
</section> </section>
<section anchor="encap" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="encap" title="LISP-SEC Control Messages Details"> ="section-6">
<t>LISP-SEC metadata associated with a Map-Request is transported within <name slugifiedName="name-lisp-sec-control-messages-d">LISP-SEC Control Me
ssages Details</name>
<t indent="0" pn="section-6-1">LISP-SEC metadata associated with a Map-Req
uest is transported within
the Encapsulated Control Message that contains the Map-Request.</t> the Encapsulated Control Message that contains the Map-Request.</t>
<t indent="0" pn="section-6-2">LISP-SEC metadata associated with the Map-R
<t>LISP-SEC metadata associated with the Map-Reply is transported within eply is transported within
the Map-Reply itself.</t> the Map-Reply itself.</t>
<t indent="0" pn="section-6-3">These specifications use an HMAC in various
<t>These specifications use Keyed-Hashing for Message Authentication (HMAC places (as described in the following). The HMAC function AUTH-HMAC-SHA-256-128
) in various places (as described in the following). The HMAC function AUTH-HMAC <xref target="RFC6234" format="default" sectionFormat="of" derivedContent="RFC6
-SHA-256-128 <xref target="RFC6234"/> MUST be supported in LISP-SEC implementati 234"/> <bcp14>MUST</bcp14> be supported in LISP-SEC implementations. LISP-SEC de
ons. LISP-SEC deployments SHOULD use AUTH-HMAC-SHA-256-128 HMAC function, except ployments <bcp14>SHOULD</bcp14> use the AUTH-HMAC-SHA-256-128 HMAC function, exc
when communicating with older implementations that only support AUTH-HMAC-SHA-1 ept when communicating with older implementations that only support AUTH-HMAC-SH
-96 <xref target="RFC2104"/>. </t> A-1-96 <xref target="RFC2104" format="default" sectionFormat="of" derivedContent
="RFC2104"/>. </t>
<section anchor="ECM_extensions" <section anchor="ECM_extensions" numbered="true" toc="include" removeInRFC
title="Encapsulated Control Message LISP-SEC Extensions"> ="false" pn="section-6.1">
<t>LISP-SEC uses the ECM defined in <xref <name slugifiedName="name-encapsulated-control-messag">Encapsulated Cont
target="I-D.ietf-lisp-rfc6833bis"/> with S bit set to 1 to indicate rol Message LISP-SEC Extensions</name>
<t indent="0" pn="section-6.1-1">LISP-SEC uses the ECM defined in <xref
target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>
with the S-bit set to 1 to indicate
that the LISP header includes Authentication Data (AD). The format of that the LISP header includes Authentication Data (AD). The format of
the LISP-SEC ECM Authentication Data is defined in <xref the LISP-SEC ECM AD is defined in <xref target="fig-AD" format="default"
target="fig-AD"/> . OTK-AD stands for One-Time Key Authentication Data sectionFormat="of" derivedContent="Figure 1"/>. OTK-AD stands for One-Time Key
Authentication Data
and EID-AD stands for EID Authentication Data.</t> and EID-AD stands for EID Authentication Data.</t>
<figure anchor="fig-AD" align="left" suppress-title="false" pn="figure-1
<figure align="center" anchor="fig-AD" ">
title="LISP-SEC ECM Authentication Data"> <name slugifiedName="name-lisp-sec-ecm-authentication">LISP-SEC ECM Au
<artwork align="center"><![CDATA[ thentication Data</name>
<artwork align="center" name="" type="" alt="" pn="section-6.1-2.1">
0 1 2 3 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 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 | | ECM AD Type | Unassigned | Requested HMAC ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| OTK Length | Key ID | OTK Wrap. ID | | | OTK Length | Key ID | OTK Wrap. ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| One-Time-Key Preamble ... | | | One-Time-Key Preamble ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD
| ... One-Time-Key Preamble | | | ... One-Time-Key Preamble | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ One-Time Key (128 bits) ~/ ~ One-Time Key (128 bits) ~/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ &lt;---+
| EID-AD Length | KDF ID | | | EID-AD Length | KDF ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Record Count |E| Unassigned | EID HMAC ID |EID-AD | Record Count |E| Unassigned | EID HMAC ID |EID-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |
| Unassigned | EID mask-len | EID-AFI | | | | Unassigned | EID mask-len | EID-AFI | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
~ EID-prefix ... ~ | | ~ EID-Prefix ... ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |
~ EID HMAC ~ | ~ EID HMAC ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ &lt;---+
]]></artwork> </artwork>
</figure> </figure>
<dl newline="false" indent="3" spacing="normal" pn="section-6.1-3">
<t><list style="empty"> <dt pn="section-6.1-3.1">ECM AD Type:</dt>
<t>ECM AD Type: 1 (LISP-SEC Authentication Data). See <xref <dd pn="section-6.1-3.2">1 (LISP-SEC Authentication Data). See <xref t
target="IANA"/>.</t> arget="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>.</
dd>
<t>Unassigned: Set to 0 on transmission and ignored on <dt pn="section-6.1-3.3">Unassigned:</dt>
receipt.</t> <dd pn="section-6.1-3.4">Set to 0 on transmission and ignored on
receipt.</dd>
<t>Requested HMAC ID: The HMAC algorithm, that will be used to <dt pn="section-6.1-3.5">Requested HMAC ID:</dt>
protect the mappings, requested by the ITR. Permitted values are reg <dd pn="section-6.1-3.6">The HMAC algorithm, which will be used to
istered in the LISP-SEC Authentication Data HMAC ID (see <xref target="HMAC"/>). protect the mappings, requested by the ITR. Permitted values are
Refer to <xref target="itr"/> for more details. registered in the LISP-SEC Authentication Data HMAC ID (see <xref targe
</t> t="HMAC" format="default" sectionFormat="of" derivedContent="Section 8.3"/>). Re
fer to <xref target="itr" format="default" sectionFormat="of" derivedContent="Se
<t>OTK Length: The length (in bytes) of the OTK Authentication ction 6.4"/> for more details.</dd>
Data (OTK-AD), that contains the OTK Preamble and the OTK.</t> <dt pn="section-6.1-3.7">OTK Length:</dt>
<dd pn="section-6.1-3.8">The length (in bytes) of the OTK Authenticati
<t>Key ID: The identifier of the pre-shared secret shared by an on
ITR and the Map-Resolver, and by the Map-Server and an ETR. Data (OTK-AD), which contains the OTK Preamble and the OTK.</dd>
Per-message keys are derived from the pre-shared secret to <dt pn="section-6.1-3.9">Key ID:</dt>
encrypt, authenticate the origin and protect the integrity of the <dd pn="section-6.1-3.10">The identifier of the pre-shared secret shar
OTK. The Key ID allows to rotate between multiple pre-shared ed by an
secrets in a non disruptive way.</t> ITR and the Map-Resolver, and by the Map-Server and an ETR.
Per-message keys are derived from the pre-shared secret to
<t>OTK Wrapping ID (OTK Wrap. ID): The identifier of the key derivat encrypt, authenticate the origin, and protect the integrity of the
ion function OTK. The Key ID allows to rotate between multiple pre-shared
and of the key wrapping algorithm used to encrypt the secrets in a nondisruptive way.</dd>
One-Time-Key. Permitted values are registered in the LISP-SEC Authen <dt pn="section-6.1-3.11">OTK Wrapping ID (OTK Wrap. ID):</dt>
tication Data Key Wrap ID (see <xref target="wrap"/>). Refer to <xref target="en <dd pn="section-6.1-3.12">The identifier of the Key Derivation Functio
cryption"/> for more details. </t> n
and of the key wrapping algorithm used to encrypt the
<t>One-Time-Key Preamble: set to 0 if the OTK is not encrypted. One-Time-Key. Permitted values are registered in the LISP-SEC
When the OTK is encrypted, this field MAY carry additional Authentication Data Key Wrap ID (see <xref target="wrap" format="defaul
metadata resulting from the key wrapping operation. When a 128-bit t" sectionFormat="of" derivedContent="Section 8.4"/>). Refer to <xref target="en
OTK is sent unencrypted by a Map-Resolver, the OTK Preamble is set cryption" format="default" sectionFormat="of" derivedContent="Section 6.5"/> for
to 0x0000000000000000 (64 bits). See <xref target="null"/> for more details. </dd>
details.</t> <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.
<t>One-Time-Key: the OTK wrapped as specified by OTK Wrapping ID. When the OTK is encrypted, this field <bcp14>MAY</bcp14> carry additio
See <xref target="encryption"/> for details.</t> nal
metadata resulting from the key wrapping operation. When a 128-bit
<t>EID-AD Length: length (in bytes) of the EID Authentication Data OTK is sent unencrypted by a Map-Resolver, the OTK Preamble is set
(EID-AD). The ITR MUST set the EID-AD Length to 4 bytes, as it only to 0x0000000000000000 (64 bits). See <xref target="null" format="defau
fills the KDF ID field, and all the remaining fields part of the lt" sectionFormat="of" derivedContent="Section 6.5.1"/> for details.</dd>
EID-AD are not present. An EID-AD MAY contain multiple <dt pn="section-6.1-3.15">One-Time-Key:</dt>
EID-records. Each EID-record is 4-byte long plus the length of the <dd pn="section-6.1-3.16">The OTK wrapped as specified by OTK Wrapping
AFI-encoded EID-prefix.</t> ID.
See <xref target="encryption" format="default" sectionFormat="of" deri
<t>KDF ID: Identifier of the Key Derivation Function used to vedContent="Section 6.5"/> for details.</dd>
derive the MS-OTK. Permitted values are registered in the LISP-SEC A <dt pn="section-6.1-3.17">EID-AD Length:</dt>
uthentication Data Key Derivation Function ID (see <xref target="kdf"/>). Refer <dd pn="section-6.1-3.18">Length (in bytes) of the EID Authentication
to <xref target="map-server"/> for more details. </t> Data
(EID-AD). The ITR <bcp14>MUST</bcp14> set the EID-AD Length to 4 bytes
<t>Record Count: As defined in Section 5.2 of <xref ,
target="I-D.ietf-lisp-rfc6833bis"/>. </t> as it only
fills the 'KDF ID' field, and all the remaining fields part of the
<t>E: ETR-Cant-Sign bit. If this bit is set to 1, it signals to the EID-AD are not present. An EID-AD <bcp14>MAY</bcp14> contain multiple
ITR EID-Records. Each EID-Record is 4 bytes long, plus the length of the
that at least one of the ETRs authoritative for the EID prefixes AFI-encoded EID-Prefix.</dd>
of this Map-Reply has not enabled LISP-SEC. Only a Map-Server can se <dt pn="section-6.1-3.19">KDF ID:</dt>
t this bit. See <xref <dd pn="section-6.1-3.20">Identifier of the Key Derivation Function us
target="map-server"/> for more details.</t> ed to
derive the MS-OTK. Permitted values are registered in the LISP-SEC
<t>Unassigned: Set to 0 on transmission and ignored on Authentication Data Key Derivation Function ID (see <xref target="kdf"
receipt.</t> format="default" sectionFormat="of" derivedContent="Section 8.5"/>). Refer to <x
ref target="map-server" format="default" sectionFormat="of" derivedContent="Sect
<t>EID HMAC ID: Identifier of the HMAC algorithm used to protect ion 6.7"/> for more details. </dd>
the integrity of the EID-AD. This field is filled by the Map-Server <dt pn="section-6.1-3.21">Record Count:</dt>
that computed the EID-prefix HMAC. See <xref target="EID-AD"/> for m <dd pn="section-6.1-3.22">As defined in <xref target="RFC9301" section
ore details. </t> ="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/r
fc/rfc9301#section-5.2" derivedContent="RFC9301"/>. </dd>
<t>EID mask-len: As defined in Section 5.2 of <xref <dt pn="section-6.1-3.23">E:</dt>
target="I-D.ietf-lisp-rfc6833bis"/>.</t> <dd pn="section-6.1-3.24">ETR-Cant-Sign bit. If this bit is set to 1,
it signals to the ITR
<t>EID-AFI: As defined in Section 5.2 of <xref that at least one of the ETRs that is authoritative for the EID-Prefix
target="I-D.ietf-lisp-rfc6833bis"/>.</t> es
of this Map-Reply has not enabled LISP-SEC. Only a Map-Server can set
<t>EID-prefix: As defined in Section 5.2 of <xref this bit. See <xref target="map-server" format="default" sectionFormat=
target="I-D.ietf-lisp-rfc6833bis"/>.</t> "of" derivedContent="Section 6.7"/> for more
details.</dd>
<t>EID HMAC: HMAC of the EID-AD computed and inserted by a <dt pn="section-6.1-3.25">Unassigned:</dt>
Map-Server See <xref target="EID-AD"/> for more details. <dd pn="section-6.1-3.26">Set to 0 on transmission and ignored on
</t> receipt.</dd>
</list></t> <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 pro
tect
the integrity of the EID-AD. This field is filled by the Map-Server
that computed the EID-Prefix HMAC. See <xref target="EID-AD" format="d
efault" sectionFormat="of" derivedContent="Section 6.7.1"/> for more details. </
dd>
<dt pn="section-6.1-3.29">EID mask-len:</dt>
<dd pn="section-6.1-3.30">As defined in <xref target="RFC9301" section
="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/r
fc/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 in <xref target="RFC9301" section
="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/r
fc/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 in <xref target="RFC9301" section
="5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/r
fc/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
a
Map-Server. See <xref target="EID-AD" format="default" sectionFormat="
of" derivedContent="Section 6.7.1"/> for more details.
</dd>
</dl>
</section> </section>
<section anchor="MR_extensions" numbered="true" toc="include" removeInRFC=
<section anchor="MR_extensions" title="Map-Reply LISP-SEC Extensions"> "false" pn="section-6.2">
<t>LISP-SEC uses the Map-Reply defined in <xref <name slugifiedName="name-map-reply-lisp-sec-extensio">Map-Reply LISP-SE
target="I-D.ietf-lisp-rfc6833bis"/>, with Type set to 2, and S-bit set C Extensions</name>
<t indent="0" pn="section-6.2-1">LISP-SEC uses the Map-Reply defined in
<xref target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC93
01"/>, with Type set to 2 and S-bit set
to 1 to indicate that the Map-Reply message includes Authentication to 1 to indicate that the Map-Reply message includes Authentication
Data (AD). The format of the LISP-SEC Map-Reply Authentication Data is Data (AD). The format of the LISP-SEC Map-Reply Authentication Data is
defined in <xref target="map-reply-AD"/>. PKT-AD is the Packet defined in <xref target="map-reply-AD" format="default" sectionFormat="o f" derivedContent="Figure 2"/>. PKT-AD is the Packet
Authentication Data that covers the Map-Reply payload.</t> Authentication Data that covers the Map-Reply payload.</t>
<figure anchor="map-reply-AD" align="left" suppress-title="false" pn="fi
<figure align="center" anchor="map-reply-AD" gure-2">
title="LISP-SEC Map-Reply Authentication Data"> <name slugifiedName="name-lisp-sec-map-reply-authenti">LISP-SEC Map-Re
<artwork align="center"><![CDATA[ 0 1 ply Authentication Data</name>
2 3 <artwork 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 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 | | MR AD Type | Unassigned |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ &lt;---+
| EID-AD Length | KDF ID | | | EID-AD Length | KDF ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Record Count | Unassigned | EID HMAC ID |EID-AD | Record Count | Unassigned | EID HMAC ID |EID-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ |
| Unassigned | EID mask-len | EID-AFI | | | | Unassigned | EID mask-len | EID-AFI | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
~ EID-prefix ... ~ | | ~ EID-Prefix ... ~ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ |
~ EID HMAC ~ | ~ EID HMAC ~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ &lt;---+
| PKT-AD Length | PKT HMAC ID |\ | PKT-AD Length | PKT HMAC ID |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ PKT HMAC ~PKT-AD ~ PKT HMAC ~PKT-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
]]></artwork> </artwork>
</figure> </figure>
<dl newline="false" indent="3" spacing="normal" pn="section-6.2-3">
<t><list style="empty"> <dt pn="section-6.2-3.1">MR AD Type:</dt>
<t>MR AD Type: 1 (LISP-SEC Authentication Data). See <xref <dd pn="section-6.2-3.2">1 (LISP-SEC Authentication Data). See <xref t
target="IANA"/>.</t> arget="IANA" format="default" sectionFormat="of" derivedContent="Section 8"/>.</
dd>
<t>EID-AD Length: length (in bytes) of the EID-AD (see <xref target= <dt pn="section-6.2-3.3">EID-AD Length:</dt>
"ECM_extensions"/>). </t> <dd pn="section-6.2-3.4">Length (in bytes) of the EID-AD (see <xref ta
rget="ECM_extensions" format="default" sectionFormat="of" derivedContent="Sectio
<t>KDF ID: Identifier of the Key Derivation Function used to n 6.1"/>). </dd>
derive MS-OTK (see <xref target="ECM_extensions"/>). <dt pn="section-6.2-3.5">KDF ID:</dt>
</t> <dd pn="section-6.2-3.6">Identifier of the Key Derivation Function use
d to
<t>Record Count: The number of records in this Map-Reply message (se derive MS-OTK (see <xref target="ECM_extensions" format="default" sect
e <xref target="ECM_extensions"/>).</t> ionFormat="of" derivedContent="Section 6.1"/>).</dd>
<dt pn="section-6.2-3.7">Record Count:</dt>
<t>Unassigned: Set to 0 on transmission and ignored on <dd pn="section-6.2-3.8">The number of records in this Map-Reply messa
receipt.</t> ge (see <xref target="ECM_extensions" format="default" sectionFormat="of" derive
dContent="Section 6.1"/>).</dd>
<t>EID HMAC ID: Identifier of the HMAC algorithm used to protect <dt pn="section-6.2-3.9">Unassigned:</dt>
the integrity of the EID-AD (see <xref target="ECM_extensions"/>). < <dd pn="section-6.2-3.10">Set to 0 on transmission and ignored on rece
/t> ipt.</dd>
<dt pn="section-6.2-3.11">EID HMAC ID:</dt>
<t>EID mask-len: Mask length for EID-prefix (see <xref target="ECM_e <dd pn="section-6.2-3.12">Identifier of the HMAC algorithm used to pro
xtensions"/>).</t> tect
the integrity of the EID-AD (see <xref target="ECM_extensions" format=
<t>EID-AFI: See <xref target="ECM_extensions"/>. </t> "default" sectionFormat="of" derivedContent="Section 6.1"/>). </dd>
<dt pn="section-6.2-3.13">EID mask-len:</dt>
<t>EID-prefix: See <xref target="ECM_extensions"/>. </t> <dd pn="section-6.2-3.14">Mask length for EID-Prefix (see <xref target
="ECM_extensions" format="default" sectionFormat="of" derivedContent="Section 6.
<t>EID HMAC: See <xref target="ECM_extensions"/>. </t> 1"/>).</dd>
<dt pn="section-6.2-3.15">EID-AFI:</dt>
<t>PKT-AD Length: length (in bytes) of the Packet Authentication <dd pn="section-6.2-3.16">See <xref target="ECM_extensions" format="de
Data (PKT-AD).</t> fault" sectionFormat="of" derivedContent="Section 6.1"/>. </dd>
<dt pn="section-6.2-3.17">EID-Prefix:</dt>
<t>PKT HMAC ID: Identifier of the HMAC algorithm used to protect <dd pn="section-6.2-3.18">See <xref target="ECM_extensions" format="de
the integrity of the Map-Reply (see <xref target="encryption"/>). fault" sectionFormat="of" derivedContent="Section 6.1"/>. </dd>
</t> <dt pn="section-6.2-3.19">EID HMAC:</dt>
<dd pn="section-6.2-3.20">See <xref target="ECM_extensions" format="de
<t>PKT HMAC: HMAC of the whole Map-Reply packet, so to protect its i fault" sectionFormat="of" derivedContent="Section 6.1"/>. </dd>
ntegrity; including the LISP-SEC Authentication Data (from the Map-Reply Type fi <dt pn="section-6.2-3.21">PKT-AD Length:</dt>
eld to the PKT HMAC field), which allow message authetification. </t> <dd pn="section-6.2-3.22">Length (in bytes) of the Packet Authenticati
</list></t> on
Data (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 pro
tect
the integrity of the Map-Reply (see <xref target="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-Reply packet to protec
t its integrity,
including the LISP-SEC Authentication Data (from the 'Map-Reply Type'
field to the 'PKT HMAC' field), which allow message authentication.</dd
>
</dl>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-6.3
<section title="Map-Register LISP-SEC Extensions"> ">
<name slugifiedName="name-map-register-lisp-sec-exten">Map-Register LISP
<t>The S bit in the Map-Register message (see <xref target="I-D.ietf-lis -SEC Extensions</name>
p-rfc6833bis"/>) indicates to the Map-Server that the registering ETR is LISP-SE <t indent="0" pn="section-6.3-1">The S-bit in the Map-Register message (
C enabled. An ETR that supports LISP-SEC MUST set the S bit in its Map-Register see <xref target="RFC9301" format="default" sectionFormat="of" derivedContent="R
messages.</t> FC9301"/>) indicates to the Map-Server that the registering ETR is LISP-SEC enab
led. An ETR that supports LISP-SEC <bcp14>MUST</bcp14> set the S-bit in its Map-
Register messages.</t>
</section> </section>
<section anchor="itr" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="itr" title="ITR Processing: Generating a Map-Request"> ="section-6.4">
<t>Upon creating a Map-Request, the ITR generates a random ITR-OTK <name slugifiedName="name-itr-processing-generating-a">ITR Processing: G
enerating a Map-Request</name>
<t indent="0" pn="section-6.4-1">Upon creating a Map-Request, the ITR ge
nerates a random ITR-OTK
that is stored locally, until the corresponding Map-Reply is that is stored locally, until the corresponding Map-Reply is
received (see <xref target="itr-receive"/>), together with the nonce gen received (see <xref target="itr-receive" format="default" sectionFormat=
erated as specified in <xref "of" derivedContent="Section 6.9"/>), together with the nonce generated as speci
target="I-D.ietf-lisp-rfc6833bis"/>.</t> fied in <xref target="RFC9301" format="default" sectionFormat="of" derivedConten
t="RFC9301"/>.</t>
<t>The ITR MAY use the KDF ID field to indicate the recommended KDF algo <t indent="0" pn="section-6.4-2">The ITR <bcp14>MAY</bcp14> use the 'KDF
rithm, according to local policy. The Map-Server can overwrite the KDF ID if it ID' field to indicate the recommended KDF algorithm according to local policy.
does not support the KDF ID recommended by the ITR (see <xref target="map-server The Map-Server can overwrite the KDF ID if it does not support the KDF ID recomm
"/>). A KDF value of NOPREF (0) may be used to specify that the ITR has no prefe ended by the ITR (see <xref target="map-server" format="default" sectionFormat="
rred KDF ID. of" derivedContent="Section 6.7"/>). A KDF value of NOPREF (0) may be used to sp
ecify that the ITR has no preferred KDF ID.
</t> </t>
<t indent="0" pn="section-6.4-3">ITR-OTK confidentiality and integrity p
<t>ITR-OTK confidentiality and integrity protection MUST be provided rotection <bcp14>MUST</bcp14> be provided
in the path between the ITR and the Map-Resolver. This can be achieved 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 either by encrypting the ITR-OTK with the pre-shared secret known to
the ITR and the Map-Resolver (see <xref target="encryption"/>), or by the ITR and the Map-Resolver (see <xref target="encryption" format="defa
enabling DTLS <xref target="RFC9147"/> between the ITR and the Map-Resol ult" sectionFormat="of" derivedContent="Section 6.5"/>) or by
ver.</t> enabling DTLS <xref target="RFC9147" format="default" sectionFormat="of"
derivedContent="RFC9147"/> between the ITR and the Map-Resolver.</t>
<t>The Map-Request (as defined in <xref target="I-D.ietf-lisp-rfc6833bis <t indent="0" pn="section-6.4-4">The Map-Request (as defined in <xref ta
"/>) MUST be encapsulated as a LISP Control Message in an ECM, with the S-bit se rget="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>) <
t to 1, to indicate the presence of Authentication Data. Such a message is also bcp14>MUST</bcp14> be encapsulated as a LISP Control Message in an ECM, with the
called "Protected Map-Request" in this memo.</t> 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 ITR-OTK is wrapped with the algorithm specified by the OTK Wrappi <t indent="0" pn="section-6.4-5">The ITR-OTK is wrapped with the algorit
ng hm specified by the 'OTK Wrapping
ID field. See <xref target="encryption"/> for further details on OTK ID' field. See <xref target="encryption" format="default" sectionFormat=
encryption. If the NULL-KEY-WRAP-128 algorithm (see <xref target="wrap"/ "of" derivedContent="Section 6.5"/> for further details on OTK
>) is selected, and no other encryption mechanism (e.g. DTLS) is enabled in the encryption. If the NULL-KEY-WRAP-128 algorithm (see <xref target="wrap"
path between the ITR and the Map-Resolver, the Map-Request MUST be dropped, and format="default" sectionFormat="of" derivedContent="Section 8.4"/>) is selected,
an appropriate log action SHOULD be taken. Implementations may include mechanism and no other encryption mechanism (e.g., DTLS) is enabled in the path between t
s (which are beyond the scope of this document) to avoid log resource exhaustion he ITR and the Map-Resolver, the Map-Request <bcp14>MUST</bcp14> be dropped, and
attacks.</t> an appropriate log action <bcp14>SHOULD</bcp14> be taken. Implementations may i
nclude mechanisms (which are beyond the scope of this document) to avoid log res
<t>The Requested HMAC ID field contains the suggested HMAC algorithm ource exhaustion attacks.</t>
<t indent="0" pn="section-6.4-6">The 'Requested HMAC ID' field contains
the suggested HMAC algorithm
to be used by the Map-Server and the ETR to protect the integrity of to be used by the Map-Server and the ETR to protect the integrity of
the ECM Authentication data and of the Map-Reply. A HMAC ID Value of the ECM Authentication Data and of the Map-Reply. A HMAC ID value of
NONE (0), MAY be used to specify that the ITR has no preferred HMAC ID. NONE (0) <bcp14>MAY</bcp14> be used to specify that the ITR has no prefe
rred HMAC ID.
</t> </t>
<t indent="0" pn="section-6.4-7">The 'KDF ID' field specifies the sugges
<t>The KDF ID field specifies the suggested key derivation function to ted Key Derivation Function to
be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE be used by the Map-Server to derive the MS-OTK. A KDF value of NONE
(0) may be used to specify that the ITR has no preferred KDF ID.</t> (0) may be used to specify that the ITR has no preferred KDF ID.</t>
<t indent="0" pn="section-6.4-8">The EID-AD Length is set to 4 bytes, si
<t>The EID-AD length is set to 4 bytes, since the Authentication Data nce the Authentication Data
does not contain EID-prefix Authentication Data, and the EID-AD does not contain EID-Prefix Authentication Data, and the EID-AD
contains only the KDF ID field.</t> contains only the 'KDF ID' field.</t>
<t indent="0" pn="section-6.4-9">If the ITR is directly connected to a M
<t>If the ITR is directly connected to a Mapping System, such as LISP+ apping System, such as LISP+ALT <xref target="RFC6836" format="default" sectionF
ALT <xref target="RFC6836"/>, it performs the functions of both the ITR and the ormat="of" derivedContent="RFC6836"/>, it performs the functions of both the ITR
Map-Resolver, forwarding the Protected Map-Request as described in <xref target= and the Map-Resolver, forwarding the Protected Map-Request as described in <xre
"map-resolver"/>.</t> f target="map-resolver" format="default" sectionFormat="of" derivedContent="Sect
ion 6.6"/>.</t>
<t>The processing performed by Proxy ITRs (PITRs) is equivalent to the <t indent="0" pn="section-6.4-10">The processing performed by Proxy ITRs
processing of an ITR, hence the procedure described above applies. (PITRs) is equivalent to the
</t> processing of an ITR; hence, the procedure described above applies.
</t>
</section> </section>
<section anchor="encryption" numbered="true" toc="include" removeInRFC="fa
<section anchor="encryption" title="Encrypting and Decrypting an OTK "> lse" pn="section-6.5">
<t>MS-OTK confidentiality and integrity protection MUST be provided in <name slugifiedName="name-encrypting-and-decrypting-a">Encrypting and De
crypting an OTK</name>
<t indent="0" pn="section-6.5-1">MS-OTK confidentiality and integrity pr
otection <bcp14>MUST</bcp14> be provided in
the path between the Map-Server and the ETR. This can be achieved 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 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 encrypting the MS-OTK with the pre-shared secret known to the
Map-Server and the ETR <xref target="I-D.ietf-lisp-rfc6833bis"/>.</t> Map-Server and the ETR <xref target="RFC9301" format="default" sectionFo
rmat="of" derivedContent="RFC9301"/>.</t>
<t>Similarly, ITR-OTK confidentiality and integrity protection MUST be <t indent="0" pn="section-6.5-2">Similarly, ITR-OTK confidentiality and
integrity protection <bcp14>MUST</bcp14> be
provided in the path between the ITR and the Map-Resolver. This can 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 the ITR, achieved either by enabling DTLS between the Map-Server and the ITR
or by encrypting the ITR-OTK with the pre-shared secret known to the 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 ITR and the Map-Resolver. The ITR/Map-Resolver pre-shared key is
similar to the Map-Server/ETR pre-shared key.</t> similar to the Map-Server/ETR pre-shared key.</t>
<t indent="0" pn="section-6.5-3">This section describes OTK processing i
<t>This section describes OTK processing in the ITR/Map-Resolver path, n the ITR/Map-Resolver path,
as well as in the Map-Server/ETR path.</t> as well as in the Map-Server/ETR path.</t>
<t indent="0" pn="section-6.5-4">It's important to note that, to prevent
<t>It's important to note that, to prevent ETR's overclaiming attacks, ETR's overclaiming attacks,
the ITR/Map-Resolver pre-shared secret MUST be independent from the the ITR/Map-Resolver pre-shared secret <bcp14>MUST</bcp14> be independen
t from the
Map-Server/ETR pre-shared secret.</t> Map-Server/ETR pre-shared secret.</t>
<t indent="0" pn="section-6.5-5">The OTK is wrapped using the algorithm
<t>The OTK is wrapped using the algorithm specified in the OTK specified in the 'OTK
Wrapping ID field. This field identifies both the:</t> Wrapping ID' field. This field identifies both the:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6
<t><list style="symbols"> .5-6">
<t>Key Encryption Algorithm used to encrypt the wrapped OTK.</t> <li pn="section-6.5-6.1">Key Encryption Algorithm used to encrypt the
wrapped OTK and</li>
<t>Key Derivation Function used to derive a per-message encryption <li pn="section-6.5-6.2">Key Derivation Function used to derive a per-
key.</t> message encryption
</list> key.</li>
Implementations of this specification MUST support OTK </ul>
Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the <t indent="0" pn="section-6.5-7">
HKDF-SHA256 Key Derivation Function specified in <xref Implementations of this specification <bcp14>MUST</bcp14> support the
target="RFC5869"/> to derive a per-message encryption key OTK
(per-msg-key), as well as the AES-KEY-WRAP-128 Key Wrap algorithm used Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256, which specifies the use of t
to encrypt a 128-bit OTK, according to <xref target="RFC3394"/>.</t> he
HKDF-SHA256 Key Derivation Function specified in <xref target="RFC5869
<t>Implementations of this specification MUST support OTK " format="default" sectionFormat="of" derivedContent="RFC5869"/> to derive a per
-message encryption key
(per-msg-key), as well as the AES-KEY-WRAP-128 key wrap algorithm used
to encrypt a 128-bit OTK, according to <xref target="RFC3394" format="
default" sectionFormat="of" derivedContent="RFC3394"/>.</t>
<t indent="0" pn="section-6.5-8">Implementations of this specification <
bcp14>MUST</bcp14> support OTK
Wrapping NULL-KEY-WRAP-128. NULL-KEY-WRAP-128 is used to carry an unen crypted 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 bits). </t> Wrapping NULL-KEY-WRAP-128. NULL-KEY-WRAP-128 is used to carry an unen crypted 128-bit OTK, with a 64-bit preamble set to 0x0000000000000000 (64 bits). </t>
<t indent="0" pn="section-6.5-9">The key wrapping process for OTK Wrappi
<t>The key wrapping process for OTK Wrapping ID ng ID
AES-KEY-WRAP-128+HKDF-SHA256 is described below: AES-KEY-WRAP-128+HKDF-SHA256 is described below:
<list style="numbers"> </t>
<ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-6.
<t>The KDF and Key Wrap algorithms are identified by the value of th 5-10">
e 'OTK Wrapping ID' field. The initial values are documented in <xref target="ta <li pn="section-6.5-10.1" derivedCounter="1.">The KDF and key wrap algo
bleKWF"/>.</t> rithms are identified by the value of the 'OTK Wrapping ID' field. The initial v
alues are documented in <xref target="tableKWF" format="default" sectionFormat="
<t>If the NULL-KEY-WRAP-128 algorithm (see <xref target="wrap"/>) is of" derivedContent="Table 5"/>.</li>
selected and DTLS is not enabled, the Map-Request <li pn="section-6.5-10.2" derivedCounter="2.">If the NULL-KEY-WRAP-128
MUST be dropped and an appropriate log action SHOULD be taken. Imple algorithm (see <xref target="wrap" format="default" sectionFormat="of" derivedC
mentations may include mechanisms (which are beyond the scope of this document) ontent="Section 8.4"/>) is selected and DTLS is not enabled, the Map-Request
to avoid log resource exhaustion attacks.</t> <bcp14>MUST</bcp14> be dropped and an appropriate log action <bcp14>
SHOULD</bcp14> be taken. Implementations may include mechanisms (which are beyon
<t>The pre-shared secret used to derive the per-msg-key is d the scope of this document) to avoid log resource exhaustion attacks.</li>
represented by PSK[Key ID], that is the pre-shared secret <li pn="section-6.5-10.3" derivedCounter="3.">The pre-shared secret us
identified by the 'Key ID'.</t> ed to derive the per-msg-key is
represented by PSK[Key ID], which is the pre-shared secret
<t>The 128-bits long per-message encryption key is computed as: identified by the 'Key ID'.</li>
<list style="symbols"> <li pn="section-6.5-10.4" derivedCounter="4.">
<t>per-msg-key = KDF( nonce + s + PSK[Key ID] )</t> <t indent="0" pn="section-6.5-10.4.1">The 128-bit-long per-message e
</list> ncryption key is computed as:</t>
<t indent="3" pn="section-6.5-10.4.2">per-msg-key = KDF( nonce + s +
where the nonce is the value in the Nonce field of the PSK[Key ID] )</t>
Map-Request, 's' is the string "OTK-Key-Wrap", and the operation <t indent="0" pn="section-6.5-10.4.3">where the nonce is the value i
'+' just indicates string concatenation. n the 'Nonce' field of the
</t> Map-Request, 's' is the string "OTK-Key-Wrap", and the operation'+'
just indicates string concatenation.</t>
<t>According to <xref target="RFC3394"/> the per-msg-key is used </li>
to wrap the OTK with AES-KEY-WRAP-128. The AES Key Wrap <li pn="section-6.5-10.5" derivedCounter="5.">The per-msg-key is then
Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). used to wrap the OTK with AES-KEY-WRAP-128, as specified in <xref target="RFC339
The output of the AES Key Wrap operation is 192-bit long. The most 4" format="default" sectionFormat="of" section="2.2.1" derivedLink="https://rfc-
significant 64-bit are copied in the One-Time Key Preamble field, editor.org/rfc/rfc3394#section-2.2.1" derivedContent="RFC3394"/>. The AES Key Wr
while the 128 less significant bits are copied in the One-Time Key ap
field of the LISP-SEC Authentication Data.</t> Initialization Value <bcp14>MUST</bcp14> be set to 0xA6A6A6A6A6A6A6A
</list></t> 6 (64 bits).
The output of the AES key wrap operation is 192 bits long.
<t>When decrypting an encrypted OTK the receiver MUST verify that the The most significant 64 bits
Initialization Value resulting from the AES Key Wrap decryption are copied in the 'One-Time Key Preamble' field, while the 128
operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails least significant bits are copied in the 'One-Time Key' field of
the receiver MUST discard the entire message.</t> the LISP-SEC Authentication Data.</li>
</ol>
<section anchor="null" title="Unencrypted OTK"> <t indent="0" pn="section-6.5-11">When decrypting an encrypted OTK, the
receiver <bcp14>MUST</bcp14> verify that the
<t>However, when DTLS is enabled the OTK MAY be sent unencrypted as Initialization Value resulting from the AES key wrap decryption
operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails,
the receiver <bcp14>MUST</bcp14> discard the entire message.</t>
<section anchor="null" 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 is enabled, the
OTK <bcp14>MAY</bcp14> be sent unencrypted as
transport layer security is providing confidentiality and integrity transport layer security is providing confidentiality and integrity
protection.</t> protection.</t>
<t indent="0" pn="section-6.5.1-2">When a 128-bit OTK is sent unencryp
<t>When a 128-bit OTK is sent unencrypted the OTK Wrapping ID is set ted, the OTK Wrapping ID is set
to NULL_KEY_WRAP_128, and the OTK Preamble is set to to NULL_KEY_WRAP_128, and the OTK Preamble is set to
0x0000000000000000 (64 bits).</t> 0x0000000000000000 (64 bits).</t>
</section> </section>
</section> </section>
<section anchor="map-resolver" numbered="true" toc="include" removeInRFC="
<section anchor="map-resolver" title="Map-Resolver Processing"> false" pn="section-6.6">
<t>Upon receiving a Protected Map-Request, the Map-Resolver decapsulates <name slugifiedName="name-map-resolver-processing">Map-Resolver Processi
the ECM message. The ITR-OTK, if encrypted, ng</name>
is decrypted as specified in <xref target="encryption"/>.</t> <t indent="0" pn="section-6.6-1">Upon receiving a Protected Map-Request,
the Map-Resolver decapsulates the ECM. The ITR-OTK, if encrypted,
<t>Protecting the confidentiality of the ITR-OTK and, in general, the is decrypted as specified in <xref target="encryption" format="default"
sectionFormat="of" derivedContent="Section 6.5"/>.</t>
<t indent="0" pn="section-6.6-2">Protecting the confidentiality of the I
TR-OTK and, in general, the
security of how the Map-Request is handed by the Map-Resolver to the security of how the Map-Request is handed by the Map-Resolver to the
Map-Server, is specific to the particular Mapping System used, and Map-Server is specific to the particular Mapping System used and is
outside of the scope of this memo.</t> outside of the scope of this memo.</t>
<t indent="0" pn="section-6.6-3">In Mapping Systems where the Map-Server
<t>In Mapping Systems where the Map-Server is compliant with <xref is compliant with <xref target="RFC9301" format="default" sectionFormat="of" de
target="I-D.ietf-lisp-rfc6833bis"/>, the Map-Resolver originates a new rivedContent="RFC9301"/>, the Map-Resolver originates a new
ECM header with the S-bit set, that contains the unencrypted ITR-OTK, ECM header with the S-bit set, which contains the unencrypted ITR-OTK,
as specified in <xref target="encryption"/>, and the other data as specified in <xref target="encryption" format="default" sectionFormat
derived from the ECM Authentication Data of the received encapsulated ="of" derivedContent="Section 6.5"/>, and the other data
derived from the ECM Authentication Data of the received Encapsulated
Map-Request.</t> Map-Request.</t>
<t indent="0" pn="section-6.6-4">The Map-Resolver then forwards to the M
<t>The Map-Resolver then forwards to the Map-Server the received ap-Server the received
Map-Request, encapsulated in the new ECM header that includes the Map-Request, which is encapsulated in the new ECM header that includes t
newly computed Authentication Data fields.</t> he
newly computed 'Authentication Data' fields.</t>
</section> </section>
<section anchor="map-server" numbered="true" toc="include" removeInRFC="fa
<section anchor="map-server" title="Map-Server Processing"> lse" pn="section-6.7">
<t>Upon receiving a Protected Map-Request, the Map-Server processes it a <name slugifiedName="name-map-server-processing">Map-Server Processing</
ccording to the setting of the S-bit and the P-bit in the Map-Register received name>
from the ETRs authoritative for that prefix, as described below.</t> <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
<t>While processing the Map-Request, the Map-Server can overwrite the KD in the Map-Register received from the ETRs authoritative for that prefix, as de
F ID field if it does not support the KDF ID recommended by the ITR. scribed below.</t>
Processing of the Map-Request MUST proceed in the order described <t indent="0" pn="section-6.7-2">While processing the Map-Request, the M
in the table below, applying the processing corresponding to the first ap-Server can overwrite the 'KDF ID' field if it does not support the KDF ID rec
ommended by the ITR.
Processing of the Map-Request <bcp14>MUST</bcp14> proceed in the order d
escribed
in the table below, applying the process corresponding to the first
rule that matches the conditions indicated in the first column:</t> rule that matches the conditions indicated in the first column:</t>
<table anchor="tableMRP" align="center" pn="table-1">
<texttable anchor="tableMRP" title="Map-Request Processing."> <name slugifiedName="name-map-request-processing">Map-Request Processi
<ttcol width="30%">Matching Condition</ttcol> ng</name>
<ttcol align="left">Processing</ttcol> <thead>
<c>1. At least one of the ETRs authoritative for the EID prefix <tr>
included in the Map-Request registered with the P-bit set to 1 <th align="left" colspan="1" rowspan="1">Matching Condition</th>
</c> <th align="left" colspan="1" rowspan="1">Processing</th>
<c>The Map-Server MUST generate a LISP-SEC protected Map-Reply as </tr>
specified in <xref target="proxy"/>. The ETR-Cant-Sign E-bit in the </thead>
EID Authentication Data (EID-AD) MUST be set to 0. <tbody>
</c> <tr>
<c/> <td align="left" colspan="1" rowspan="1">1. At least one of the ET
<c/> Rs authoritative for the
<c>2. At least one of the ETRs authoritative for the EID prefix EID-Prefix included in the Map-Request registered with the P-bit se
included in the Map-Request registered with the S-bit set to 1</c> t
<c>The Map-Server MUST generate a LISP-SEC protected Encapsulated to 1</td>
Map-Request (as specified in <xref target="EID-AD"/>), to be sent to <td align="left" colspan="1" rowspan="1">The Map-Server <bcp14>MUS
one of the authoritative ETRs that registered with the S-bit set to T</bcp14> generate a
1 (and the P-bit set to 0). If there is at least one ETR that LISP-SEC-protected Map-Reply, as
registered with the S-bit set to 0, the ETR-Cant-Sign E-bit of the specified in <xref target="proxy" format="default" sectionFormat="
EID-AD MUST be set to 1 to signal the ITR that a non LISP-SEC of" derivedContent="Section 6.7.2"/>. The
Map-Request might reach additional ETRs that have LISP-SEC ETR-Cant-Sign E-bit in the
disabled.</c> EID Authentication Data (EID-AD) <bcp14>MUST</bcp14> be set to 0.<
<c/> /td>
<c/> </tr>
<c>3. All the ETRs authoritative for the EID prefix included in the <tr>
Map-Request registered with the S-bit set to 0</c> <td align="left" colspan="1" rowspan="1">2. At least one of the ET
<c>The Map-Server MUST send a Negative Map-Reply protected with Rs authoritative for the
LISP-SEC, as described in <xref target="proxy"/>. The ETR-Cant-Sign EID-Prefix included in the Map-Request registered with the S-bit se
E-bit MUST be set to 1 to signal the ITR that a non LISP-SEC t
Map-Request might reach additional ETRs that have LISP-SEC to 1</td>
disabled.</c> <td align="left" colspan="1" rowspan="1">The Map-Server <bcp14>MUS
</texttable> T</bcp14> generate a
LISP-SEC-protected Encapsulated
<t>In this way the ITR that sent a LISP-SEC protected Map-Request Map-Request (as specified in <xref target="EID-AD" format="default
always receives a LISP-SEC protected Map-Reply. However, the " sectionFormat="of" derivedContent="Section 6.7.1"/>) to be sent to
ETR-Cant-Sign E-bit set to 1 specifies that a non LISP-SEC Map-Request one of the authoritative ETRs that registered with the S-bit set t
o
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-AD <bcp14>MUST</bcp14> be set to 1 to signal the ITR that a no
n-LISP-SEC
Map-Request might reach additional ETRs that have LISP-SEC
disabled.</td>
</tr>
<tr>
<td align="left" colspan="1" rowspan="1">3. All the ETRs authorita
tive for the EID-Prefix
included in the
Map-Request registered with the S-bit set to 0</td>
<td align="left" colspan="1" rowspan="1">The Map-Server <bcp14>MUS
T</bcp14> send a Negative
Map-Reply protected with
LISP-SEC, as described in <xref target="proxy" format="default" se
ctionFormat="of" derivedContent="Section 6.7.2"/>.
The ETR-Cant-Sign
E-bit <bcp14>MUST</bcp14> be set to 1 to signal the ITR that a non
-LISP-SEC
Map-Request might reach additional ETRs that have LISP-SEC
disabled.</td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-6.7-4">In this way, the ITR that sent a LISP-S
EC-protected Map-Request
always receives a LISP-SEC-protected Map-Reply. However, the
ETR-Cant-Sign E-bit set to 1 specifies that a non-LISP-SEC Map-Request
might reach additional ETRs that have LISP-SEC disabled. This might reach additional ETRs that have LISP-SEC disabled. This
mechanism allows the ITR to downgrade to non LISP-SEC mechanism allows the ITR to downgrade to non-LISP-SEC
requests, which does not protect against threats described in <xref targ requests, which does not protect against threats described in <xref targ
et="threat-model"/>.</t> et="threat-model" format="default" sectionFormat="of" derivedContent="Section 4"
/>.</t>
<section anchor="EID-AD" <section anchor="EID-AD" numbered="true" toc="include" removeInRFC="fals
title="Generating a LISP-SEC Protected Encapsulated Map-Request e" pn="section-6.7.1">
"> <name slugifiedName="name-generating-a-lisp-sec-prote">Generating a LI
<t>The Map-Server decapsulates the ECM and generates a new ECM SP-SEC-Protected Encapsulated Map-Request</name>
<t indent="0" pn="section-6.7.1-1">The Map-Server decapsulates the ECM
and generates new ECM
Authentication Data. The Authentication Data includes the OTK-AD and Authentication Data. The Authentication Data includes the OTK-AD and
the EID-AD, that contains EID-prefix authorization information, that the EID-AD, which contains EID-Prefix authorization information that
are eventually received by the requesting ITR.</t> are eventually received by the requesting ITR.</t>
<t indent="0" pn="section-6.7.1-2">The Map-Server updates the OTK-AD b
<t>The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) y deriving a new OTK (MS-OTK)
from the ITR-OTK received with the Map-Request. MS-OTK is derived from the ITR-OTK received with the Map-Request. MS-OTK is derived by
applying the key derivation function specified in the KDF ID field. applying the Key Derivation Function specified in the 'KDF ID' field.
If the algorithm specified in the KDF ID field is not supported, the If the algorithm specified in the 'KDF ID' field is not supported, the
Map-Server uses a different algorithm to derive the key and updates Map-Server uses a different algorithm to derive the key and updates
the KDF ID field accordingly.</t> the 'KDF ID' field accordingly.</t>
<t indent="0" pn="section-6.7.1-3">The Map-Request <bcp14>MUST</bcp14>
<t>The Map-Request MUST be encapsulated in an ECM, with the S-bit be encapsulated in an ECM, with the S-bit
set to 1, to indicate the presence of Authentication Data.</t> set to 1, to indicate the presence of Authentication Data.</t>
<t indent="0" pn="section-6.7.1-4">MS-OTK is wrapped with the algorith
<t>MS-OTK is wrapped with the algorithm specified by the OTK m specified by the 'OTK
Wrapping ID field. See <xref target="encryption"/> for further Wrapping ID' field. See <xref target="encryption" format="default" sec
tionFormat="of" derivedContent="Section 6.5"/> for further
details on OTK encryption. If the NULL-KEY-WRAP-128 algorithm is 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 selected and DTLS is not enabled in the path between the Map-Server
and the ETR, the Map-Request MUST be dropped and an appropriate log and the ETR, the Map-Request <bcp14>MUST</bcp14> be dropped and an app
action SHOULD be taken.</t> ropriate log
action <bcp14>SHOULD</bcp14> be taken.</t>
<t>The Map-Server includes in the EID-AD the longest match <t indent="0" pn="section-6.7.1-5">In the EID-AD, the Map-Server inclu
registered EID-prefix for the destination EID, and an HMAC of this des in the EID-AD the longest-match-registered
EID-prefix. The HMAC is keyed with the ITR-OTK contained in the EID-Prefix for the destination EID and an HMAC of this
EID-Prefix. The HMAC is keyed with the ITR-OTK contained in the
received ECM Authentication Data, and the HMAC algorithm is chosen received ECM Authentication Data, and the HMAC algorithm is chosen
according to the Requested HMAC ID field. If the Map-Server does not according to the 'Requested HMAC ID' field. If the Map-Server does not
support this algorithm, the Map-Server uses a different algorithm support this algorithm, the Map-Server uses a different algorithm
and specifies it in the EID HMAC ID field. The scope of the HMAC and specifies it in the 'EID HMAC ID' field. The scope of the HMAC
operation MUST cover the entire EID-AD, from the EID-AD Length field t operation <bcp14>MUST</bcp14> cover the entire EID-AD, from the 'EID-A
o the EID HMAC field, which MUST be set to 0 before the D Length' field to the 'EID HMAC' field, which <bcp14>MUST</bcp14> be set to 0 b
efore the
computation.</t> computation.</t>
<t indent="0" pn="section-6.7.1-6">The Map-Server then forwards the up
<t>The Map-Server then forwards the updated ECM encapsulated dated ECM-Encapsulated
Map-Request, that contains the OTK-AD, the EID-AD, and the received Map-Request, which contains the OTK-AD, the EID-AD, and the received
Map-Request to an authoritative ETR as specified in <xref Map-Request to an authoritative ETR as specified in <xref target="RFC9
target="I-D.ietf-lisp-rfc6833bis"/>.</t> 301" format="default" sectionFormat="of" derivedContent="RFC9301"/>.</t>
</section> </section>
<section anchor="proxy" numbered="true" toc="include" removeInRFC="false
<section anchor="proxy" title="Generating a Proxy Map-Reply"> " pn="section-6.7.2">
<t>LISP-SEC proxy Map-Reply are generated according to <xref <name slugifiedName="name-generating-a-proxy-map-repl">Generating a Pr
target="I-D.ietf-lisp-rfc6833bis"/>, with the Map-Reply S-bit set oxy Map-Reply</name>
<t indent="0" pn="section-6.7.2-1">A LISP-SEC proxy Map-Reply is gener
ated according to <xref target="RFC9301" format="default" sectionFormat="of" der
ivedContent="RFC9301"/>, with the Map-Reply S-bit set
to 1. The Map-Reply includes the Authentication Data that contains to 1. The Map-Reply includes the Authentication Data that contains
the EID-AD, computed as specified in <xref target="EID-AD"/>, as the EID-AD computed as specified in <xref target="EID-AD" format="defa
well as the PKT-AD computed as specified in <xref ult" sectionFormat="of" derivedContent="Section 6.7.1"/>, as
target="etr"/>.</t> well as the PKT-AD computed as specified in <xref target="etr" format=
"default" sectionFormat="of" derivedContent="Section 6.8"/>.</t>
</section> </section>
</section> </section>
<section anchor="etr" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="etr" title="ETR Processing"> ="section-6.8">
<t>Upon receiving an ECM encapsulated Map-Request with the S-bit set, <name slugifiedName="name-etr-processing">ETR Processing</name>
the ETR decapsulates the ECM message. The OTK field, if encrypted, is <t indent="0" pn="section-6.8-1">Upon receiving an ECM-Encapsulated Map-
decrypted as specified in <xref target="encryption"/> to obtain the Request with the S-bit set,
the ETR decapsulates the ECM. The 'OTK' field, if encrypted, is
decrypted as specified in <xref target="encryption" format="default" sec
tionFormat="of" derivedContent="Section 6.5"/> to obtain the
unencrypted MS-OTK.</t> unencrypted MS-OTK.</t>
<t indent="0" pn="section-6.8-2">The ETR then generates a Map-Reply as s
<t>The ETR then generates a Map-Reply as specified in <xref pecified in <xref target="RFC9301" format="default" sectionFormat="of" derivedCo
target="I-D.ietf-lisp-rfc6833bis"/> and includes the Authentication ntent="RFC9301"/> and includes the Authentication
Data that contains the EID-AD, as received in the encapsulated Data that contains the EID-AD, as received in the Encapsulated
Map-Request, as well as the PKT-AD.</t> Map-Request, as well as the PKT-AD.</t>
<t indent="0" pn="section-6.8-3">The EID-AD is copied from the Authentic
<t>The EID-AD is copied from the Authentication Data of the received ation Data of the received
encapsulated Map-Request.</t> Encapsulated Map-Request.</t>
<t indent="0" pn="section-6.8-4">The PKT-AD contains the HMAC of the who
<t>The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed le Map-Reply packet, keyed
with the MS-OTK and computed using the HMAC algorithm specified in the with the MS-OTK and computed using the HMAC algorithm specified in the
Requested HMAC ID field of the received encapsulated Map-Request. 'Requested HMAC ID' field of the received Encapsulated Map-Request.
If the ETR does not support the Requested HMAC ID, it uses a different a If the ETR does not support the Requested HMAC ID, it uses a different a
lgorithm and updates the PKT HMAC ID field accordingly. lgorithm and updates the 'PKT HMAC ID' field accordingly.
The HMAC operation MUST cover the entire Map-Reply, where the PKT HMAC f The HMAC operation <bcp14>MUST</bcp14> cover the entire Map-Reply, where
ield MUST be set to 0 before the computation. the 'PKT HMAC' field <bcp14>MUST</bcp14> be set to 0 before the computation.
</t> </t>
<t indent="0" pn="section-6.8-5">Finally, the ETR sends the Map-Reply to
<t>Finally the ETR sends the Map-Reply to the requesting ITR as the requesting ITR as
specified in <xref target="I-D.ietf-lisp-rfc6833bis"/>.</t> specified in <xref target="RFC9301" format="default" sectionFormat="of"
derivedContent="RFC9301"/>.</t>
</section> </section>
<section anchor="itr-receive" numbered="true" toc="include" removeInRFC="f
<section anchor="itr-receive" alse" pn="section-6.9">
title="ITR Processing: Receiving a Map-Reply"> <name slugifiedName="name-itr-processing-receiving-a-">ITR Processing: R
<t>In response to a Protected Map-Request, an ITR expects a Map-Reply wi eceiving a Map-Reply</name>
th the S-bit set to 1 including an EID-AD and a PKT-AD. The ITR MUST discard th <t indent="0" pn="section-6.9-1">In response to a Protected Map-Request,
e Map-Reply otherwise. an ITR expects a Map-Reply with the S-bit set to 1, including an EID-AD and a P
KT-AD. The ITR <bcp14>MUST</bcp14> discard the Map-Reply otherwise.
</t> </t>
<t indent="0" pn="section-6.9-2">Upon receiving a Map-Reply, the ITR mus
<t>Upon receiving a Map-Reply, the ITR must verify the integrity of t verify the integrity of
both the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one both the EID-AD and the PKT-AD and <bcp14>MUST</bcp14> discard the Map-R
eply if one
of the integrity checks fails. After processing the Map-Reply, the ITR of the integrity checks fails. After processing the Map-Reply, the ITR
MUST discard the &lt;nonce,ITR-OTK&gt; pair associated to the <bcp14>MUST</bcp14> discard the &lt;nonce,ITR-OTK&gt; pair associated to
Map-Reply</t> the
Map-Reply.</t>
<t>The integrity of the EID-AD is verified using the ITR-OTK (stored <t indent="0" pn="section-6.9-3">The integrity of the EID-AD is verified
locally for the duration of this exchange) to re-compute the HMAC of using the ITR-OTK (stored
the EID-AD using the algorithm specified in the EID HMAC ID field. locally for the duration of this exchange) to recompute the HMAC of
If the ITR did indicate a Requested HMAC ID in the Map-Request and the P the EID-AD using the algorithm specified in the 'EID HMAC ID' field.
KT HAMC ID in the corresponding Map-Reply is different, or if the ITR did not in If the ITR did indicate a Requested HMAC ID in the Map-Request and the P
dicate a Requested HMAC ID in the Map-Request and the PKT HMAC ID in the corresp KT HAMC ID in the corresponding Map-Reply is different, or if the ITR did not in
onding Map-Reply is not supported, then the ITR MUST discard the Map-Reply and s dicate a Requested HMAC ID in the Map-Request and the PKT HMAC ID in the corresp
end, according to rate limitation policies defined in <xref onding Map-Reply is not supported, then the ITR <bcp14>MUST</bcp14> discard the
target="I-D.ietf-lisp-rfc6833bis"/>, a new Map-Request with a different Map-Reply and send, according to rate-limitation policies defined in <xref targe
Requested HMAC ID field, according to ITR's local policy. The scope of the HMAC t="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, a ne
operation covers the entire EID-AD, from the EID-AD Length field to the EID HMAC w Map-Request with a different 'Requested HMAC ID' field, according to ITR's loc
field.</t> al policy. The scope of the HMAC operation covers the entire EID-AD, from the 'E
ID-AD Length' field to the 'EID HMAC' field.</t>
<t>ITR MUST set the EID HMAC ID field to 0 before computing the <t indent="0" pn="section-6.9-4">ITR <bcp14>MUST</bcp14> set the 'EID HM
AC ID' field to 0 before computing the
HMAC.</t> HMAC.</t>
<t indent="0" pn="section-6.9-5">To verify the integrity of the PKT-AD,
<t>To verify the integrity of the PKT-AD, first the MS-OTK is derived first the MS-OTK is derived
from the locally stored ITR-OTK using the algorithm specified in the from the locally stored ITR-OTK using the algorithm specified in the
KDF ID field. 'KDF ID' field.
This is because the PKT-AD is generated by the ETR using 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-Requ the MS-OTK. If the ITR did indicate a recommended KDF ID in the Map-Requ
est and the KDF ID in the corresponding Map-Reply is different, or if the ITR di est and the KDF ID in the corresponding Map-Reply is different or if the ITR did
d not indicate a recommended KDF ID in the Map-Request and the KDF ID in the cor not indicate a recommended KDF ID in the Map-Request and the KDF ID in the corr
responding Map-Reply is not supported, then the ITR MUST discard the Map-Reply a esponding Map-Reply is not supported, then the ITR <bcp14>MUST</bcp14> discard t
nd he Map-Reply and
send, according to rate limitation policies defined in <xref send, according to rate-limitation policies defined in <xref target="RFC
target="I-D.ietf-lisp-rfc6833bis"/>, a new Map-Request with a 9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>, a new Map-
Request with a
different KDF ID, according to ITR's local policy. different KDF ID, according to ITR's local policy.
The key derivation function HKDF-SHA256 MUST be supported in LISP-SEC im plementations. LISP-SEC deployments SHOULD use the HKDF-SHA256 HKDF function, un less older implementations using HKDF-SHA1-128 are present in the same deploymen t. The Key Derivation Function HKDF-SHA256 <bcp14>MUST</bcp14> be supported in LISP-SEC implementations. LISP-SEC deployments <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. 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. However, since HKDF-SHA1-128 and HKDF-SHA256 are supported, the process will eventually converge.
</t> </t>
<t indent="0" pn="section-6.9-6">The derived MS-OTK is then used to reco
<t>The derived MS-OTK is then used to re-compute the HMAC of the mpute the HMAC of the
PKT-AD using the Algorithm specified in the PKT HMAC ID field. If the PKT-AD using the algorithm specified in the 'PKT HMAC ID' field. If the
PKT HMAC ID field does not match the Requested HMAC ID the ITR MUST 'PKT HMAC ID' field does not match the Requested HMAC ID, the ITR <bcp14
discard the Map-Reply and send, according to rate limitation policies de >MUST</bcp14>
fined in <xref target="I-D.ietf-lisp-rfc6833bis"/>, discard the Map-Reply and send, according to rate-limitation policies de
a new Map-Request with a different Requested HMAC ID according to fined in <xref target="RFC9301" format="default" sectionFormat="of" derivedConte
nt="RFC9301"/>,
a new Map-Request with a different Requested HMAC ID, according to
ITR's local policy or until all HMAC IDs supported by the ITR have ITR's local policy or until all HMAC IDs supported by the ITR have
been attempted. When the PKT HMAC ID field does not match the Requested been attempted. When the 'PKT HMAC ID' field does not match the Requeste
HMAC ID it is not possible to validate the Map-Reply.</t> d HMAC ID, it is not possible to validate the Map-Reply.</t>
<t indent="0" pn="section-6.9-7">Each individual Map-Reply EID-Record is
<t>Each individual Map-Reply EID-record is considered valid only if: considered valid only if:
(1) both EID-AD and PKT-AD are valid, and (2) the intersection of the (1) both EID-AD and PKT-AD are valid and (2) the intersection of the
EID-prefix in the Map-Reply EID-record with one of the EID-prefixes EID-Prefix in the Map-Reply EID-Record with one of the EID-Prefixes
contained in the EID-AD is not empty. After identifying the Map-Reply contained in the EID-AD is not empty. After identifying the Map-Reply
record as valid, the ITR sets the EID-prefix in the Map-Reply record record as valid, the ITR sets the EID-Prefix in the Map-Reply record
to the value of the intersection set computed before, and adds the to the value of the intersection set computed before and adds the
Map-Reply EID-record to its EID-to-RLOC cache, as described in <xref Map-Reply EID-Record to its EID-to-RLOC Map-Cache, as described in <xref
target="I-D.ietf-lisp-rfc6833bis"/>. An example of Map-Reply record target="RFC9301" format="default" sectionFormat="of" derivedContent="RFC9301"/>
validation is provided in <xref target="validation"/>.</t> . An example of Map-Reply record
validation is provided in <xref target="validation" format="default" sec
<t><xref target="I-D.ietf-lisp-rfc6833bis"/> allows ETRs to send tionFormat="of" derivedContent="Section 6.9.1"/>.</t>
Solicit-Map-Requests (SMR) directly to the ITR. The corresponding SMR-in <t indent="0" pn="section-6.9-8"><xref target="RFC9301" format="default"
voked Map-Request will be sent through the mapping system, hence, secured with t sectionFormat="of" derivedContent="RFC9301"/> allows ETRs to send
he specifications of this memo if in use. Solicit-Map-Requests (SMRs) directly to the ITR. The corresponding SMR-i
If an ITR accepts Map-Replies piggybacked in Map-Requests and its conten nvoked Map-Request will be sent through the Mapping System, hence, secured with
t is not already present in its EID-to-RLOC cache, it MUST send a Map-Request ov the specifications of this memo if in use.
er the mapping system in order to verify its content with a secured Map-Reply, b If an ITR accepts Map-Replies piggybacked in Map-Requests and its conten
efore using the content.</t> t is not already present in its EID-to-RLOC Map-Cache, it <bcp14>MUST</bcp14> se
nd a Map-Request over the Mapping System in order to verify its content with a s
<t/> ecured Map-Reply before using the content.</t>
<section anchor="validation" numbered="true" toc="include" removeInRFC="
<section anchor="validation" title="Map-Reply Record Validation"> false" pn="section-6.9.1">
<t>The payload of a Map-Reply may contain multiple EID-records. The <name slugifiedName="name-map-reply-record-validation">Map-Reply Recor
d Validation</name>
<t indent="0" pn="section-6.9.1-1">The payload of a Map-Reply may cont
ain multiple EID-Records. The
whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide
integrity protection and origin authentication to the EID-prefix integrity protection and origin authentication to the EID-Prefix
records claimed by the ETR. The Authentication Data field of a records claimed by the ETR. The 'Authentication Data' field of a
Map-Reply may contain multiple EID-records in the EID-AD. The EID-AD Map-Reply may contain multiple EID-Records in the EID-AD. The EID-AD
is signed by the Map-Server, with the EID HMAC, to provide integrity is signed by the Map-Server, with the EID HMAC, to provide integrity
protection and origin authentication to the EID-prefix records protection and origin authentication to the EID-Prefix records
inserted by the Map-Server.</t> inserted by the Map-Server.</t>
<t indent="0" pn="section-6.9.1-2">Upon receiving a Map-Reply with the
<t>Upon receiving a Map-Reply with the S-bit set, the ITR first S-bit set, the ITR first
checks the validity of both the EID HMAC and of the PKT-AD HMAC. If 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 action SHOULD be taken and either one of the HMACs is not valid, a log action <bcp14>SHOULD</bcp1
the Map-Reply MUST NOT be processed any further. Implementations may i 4> be taken and
nclude mechanisms (which are beyond the scope of this document) to avoid log res the Map-Reply <bcp14>MUST NOT</bcp14> be processed any further. Implem
ource exhaustion attacks. If both HMACs are entations may include mechanisms (which are beyond the scope of this document) t
valid, the ITR proceeds with validating each individual EID-record o avoid log resource exhaustion attacks. If both HMACs are
valid, the ITR proceeds with validating each individual EID-Record
claimed by the ETR by computing the intersection of each one of the claimed by the ETR by computing the intersection of each one of the
EID-prefix contained in the payload of the Map-Reply with each one EID-Prefixes contained in the payload of the Map-Reply, with each one
of the EID-prefixes contained in the EID-AD. An EID-record is valid of the EID-Prefixes contained in the EID-AD. An EID-Record is valid
only if at least one of the intersections is not the empty set, otherw only if at least one of the intersections is not the empty set; otherw
ise, a log action MUST be taken and the EID-record MUST be discarded. Implementa ise, a log action <bcp14>MUST</bcp14> be taken and the EID-Record <bcp14>MUST</b
tions may include mechanisms (which are beyond the scope of this document) to av cp14> be discarded. Implementations may include mechanisms (which are beyond the
oid log resource exhaustion attacks.</t> scope of this document) to avoid log resource exhaustion attacks.</t>
<t indent="0" pn="section-6.9.1-3">For instance, the Map-Reply payload
<t>For instance, the Map-Reply payload contains 3 mapping record contains 3 mapping record
EID-prefixes: EID-Prefixes:
<list style="empty"> </t>
<t>2001:db8:102::/48</t> <ul empty="true" spacing="normal" bare="false" indent="3" pn="section-
6.9.1-4">
<t>2001:db8:103::/48</t> <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>
<t>2001:db8:200::/40</t> <li pn="section-6.9.1-4.3">2001:db8:200::/40</li>
</list> </ul>
The EID-AD contains two EID-prefixes: <t indent="0" pn="section-6.9.1-5">
<list style="empty"> The EID-AD contains two EID-Prefixes:
<t>2001:db8:103::/48</t> </t>
<ul empty="true" spacing="normal" bare="false" indent="3" pn="section-
<t>2001:db8:203::/48</t> 6.9.1-6">
</list> <li pn="section-6.9.1-6.1">2001:db8:103::/48</li>
The EID-record with EID-prefix 2001:db8:102::/48 is not <li pn="section-6.9.1-6.2">2001:db8:203::/48</li>
eligible to be used by the ITR since it is not included in any of </ul>
the EID-ADs signed by the Map-Server. A log action MUST be taken and t <t indent="0" pn="section-6.9.1-7">
he EID-record MUST be The EID-Record with EID-Prefix 2001:db8:102::/48 is not
eligible to be used by the ITR, since it is not included in any of
the EID-ADs signed by the Map-Server. A log action <bcp14>MUST</bcp14>
be taken, and the EID-Record <bcp14>MUST</bcp14> be
discarded. Implementations may include mechanisms (which are beyond th e scope of this document) to avoid log resource exhaustion attacks. </t> discarded. Implementations may include mechanisms (which are beyond th e scope of this document) to avoid log resource exhaustion attacks. </t>
<t indent="0" pn="section-6.9.1-8">The EID-Record with EID-Prefix 2001
<t>The EID-record with EID-prefix 2001:db8:103::/48 is eligible to :db8:103::/48 is eligible to
be used by the ITR because it matches the second EID-prefix be used by the ITR because it matches the second EID-Prefix
contained in the EID-AD.</t> contained in the EID-AD.</t>
<t indent="0" pn="section-6.9.1-9">The EID-Record with EID-Prefix 2001
<t>The EID-record with EID-prefix 2001:db8:200::/40 is not eligible :db8:200::/40 is not eligible
to be used by the ITR since it is not included in any of the EID-ADs to be used by the ITR, since it is not included in any of the EID-ADs
signed by the Map-Server. A log action MUST be taken and the EID-recor signed by the Map-Server. A log action <bcp14>MUST</bcp14> be taken an
d MUST be d the EID-Record <bcp14>MUST</bcp14> be
discarded. Implementations may include mechanisms (which are beyond th discarded. Implementations may include mechanisms (which are beyond th
e scope of this document) to avoid log resource exhaustion attacks. In this last e scope of this document) to avoid log resource exhaustion attacks. In this last
example the ETR is trying to over claim the EID-prefix 2001:db8:200::/40, but t example, the ETR is trying to over claim the EID-Prefix 2001:db8:200::/40, but
he Map-Server authorized only the Map-Server authorized only
2001:db8:203::/48, hence the EID-record is discarded.</t> 2001:db8:203::/48; hence, the EID-Record is discarded.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="include" removeInRFC="false"
<section anchor="security" title="Security Considerations"> pn="section-7">
<name slugifiedName="name-security-considerations">Security Considerations
<t>This document extends the LISP Control-Plane defined in <xref </name>
target="I-D.ietf-lisp-rfc6833bis"/>, hence, its Security Considerations ap <t indent="0" pn="section-7-1">This document extends the LISP control plan
ply as well to this document. e defined in <xref target="RFC9301" format="default" sectionFormat="of" derivedC
ontent="RFC9301"/>; hence, its security considerations apply to this document a
s well.
</t> </t>
<section anchor="mapping-system" numbered="true" toc="include" removeInRFC
<section anchor="mapping-system" title="Mapping System Security"> ="false" pn="section-7.1">
<t>The LISP-SEC threat model described in <xref <name slugifiedName="name-mapping-system-security">Mapping System Securi
target="threat-model"/>, assumes that the LISP Mapping System is ty</name>
<t indent="0" pn="section-7.1-1">The LISP-SEC threat model described in
<xref 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 working properly and delivers Map-Request messages to a
Map-Server that is authoritative for the requested EID.</t> Map-Server that is authoritative for the requested EID.</t>
<t indent="0" pn="section-7.1-2">It is assumed that the Mapping System e
<t>It is assumed that the Mapping System ensures the confidentiality nsures the confidentiality
of the OTK, and the integrity of the Map-Reply data. However, how the of the OTK and the integrity of the Map-Reply data. However, how the
LISP Mapping System is secured is out of the scope of this LISP Mapping System is secured is out of the scope of this
document.</t> document.</t>
<t indent="0" pn="section-7.1-3">Similarly, Map-Register security, inclu
<t>Similarly, Map-Register security, including the right for a LISP ding the right for a LISP
entity to register an EID-prefix or to claim presence at an RLOC, is entity to register an EID-Prefix or to claim presence at an RLOC, is
out of the scope of LISP-SEC.</t> out of the scope of LISP-SEC.</t>
</section> </section>
<section anchor="random" numbered="true" toc="include" removeInRFC="false"
<section anchor="random" title="Random Number Generation"> pn="section-7.2">
<t>The ITR-OTK MUST be generated by a properly seeded pseudo-random <name slugifiedName="name-random-number-generation">Random Number Genera
(or strong random) source. See <xref target="RFC4086"/> for advice on tion</name>
<t indent="0" pn="section-7.2-1">The ITR-OTK <bcp14>MUST</bcp14> be gene
rated by a properly seeded pseudo-random
(or strong random) source. See <xref target="RFC4086" format="default" s
ectionFormat="of" derivedContent="RFC4086"/> for advice on
generating security-sensitive random data.</t> generating security-sensitive random data.</t>
</section> </section>
<section anchor="colocation" numbered="true" toc="include" removeInRFC="fa
<section anchor="colocation" title="Map-Server and ETR Colocation"> lse" pn="section-7.3">
<t>If the Map-Server and the ETR are colocated, LISP-SEC does not <name slugifiedName="name-map-server-and-etr-colocati">Map-Server and ET
R Colocation</name>
<t indent="0" pn="section-7.3-1">If the Map-Server and the ETR are coloc
ated, LISP-SEC does not
provide protection from overclaiming attacks mounted by the ETR. provide protection from overclaiming attacks mounted by the ETR.
However, in this particular case, since the ETR is within the trust However, in this particular case, since the ETR is within the trust
boundaries of the Map-Server, ETR's overclaiming attacks are not boundaries of the Map-Server, ETR's overclaiming attacks are not
included in the threat model.</t> included in the threat model.</t>
</section> </section>
<section anchor="deploying" numbered="true" toc="include" removeInRFC="fal
<section anchor="deploying" title="Deploying LISP-SEC"> se" pn="section-7.4">
<name slugifiedName="name-deploying-lisp-sec">Deploying LISP-SEC</name>
<t>Those deploying LISP-SEC according to this memo, should carefully <t indent="0" pn="section-7.4-1">Those deploying LISP-SEC according to t
weight how the LISP-SEC threat model applies to their particular use his memo should carefully
weigh how the LISP-SEC threat model applies to their particular use
case or deployment. If they decide to ignore a particular case or deployment. If they decide to ignore a particular
recommendation, they should make sure the risk associated with the corre sponding threats is well understood.</t> recommendation, they should make sure the risk associated with the corre sponding threats is well understood.</t>
<t indent="0" pn="section-7.4-2">As an example, in certain other
<t>As an example, in certain other deployments, attackers may be very sophisticated and force the
deployments, attackers may be very sophisticated, and force the deployers to enforce very strict policies in terms of HMAC algorithms
deployers to enforce very strict policies in term of HMAC algorithms
accepted by an ITR.</t> accepted by an ITR.</t>
<t indent="0" pn="section-7.4-3">Similar considerations apply to the ent
<t>Similar considerations apply to the entire LISP-SEC threat model, ire LISP-SEC threat model
and should guide the deployers and implementors whenever they and should guide the deployers and implementors whenever they
encounter the key word SHOULD across this memo.</t> encounter the key word <bcp14>SHOULD</bcp14> across this memo.</t>
</section> </section>
<section anchor="provisioning" numbered="true" toc="include" removeInRFC="
<section anchor="provisioning" title="Shared Keys Provisioning"> false" pn="section-7.5">
<t>Provisioning of the keys shared between ITR and <name slugifiedName="name-shared-keys-provisioning">Shared Keys Provisio
Map-Resolver paris as well as between ETR and Map-Server pairs should be ning</name>
performed via an orchestration infrastructure and it is out of the scope of thi <t indent="0" pn="section-7.5-1">Provisioning of the keys shared between
s memo. It is recommended that both shared keys are refreshed at periodical inte ITR and
rvals to address key aging or attackers gaining unauthorized access to the share Map-Resolver pairs as well as between ETR and Map-Server pairs should be
d keys. Shared keys should be unpredictable random values.</t> performed via an orchestration infrastructure, and is out of the scope of this
memo. It is recommended that both shared keys be refreshed at periodical interva
ls to address key aging or attackers gaining unauthorized access to the shared k
eys. Shared keys should be unpredictable random values.</t>
</section> </section>
<section anchor="reply" numbered="true" toc="include" removeInRFC="false"
<section anchor="reply" title="Replay Attacks"> pn="section-7.6">
<t>An attacker can capture a valid Map-Request and/or Map-Reply and <name slugifiedName="name-replay-attacks">Replay Attacks</name>
replay it, however once the ITR receives the original Map-Reply the <t indent="0" pn="section-7.6-1">An attacker can capture a valid Map-Req
&lt;nonce,ITR-OTK&gt; pair stored at the ITR will be discarded. If a uest and/or Map-Reply and
replayed Map-Reply arrives at the ITR, there is no replay it; however, once the ITR receives the original Map-Reply, the
&lt;nonce,ITR-OTK&gt; that matches the incoming Map-Reply and will be &lt;nonce,ITR-OTK&gt; pair stored at the ITR will be discarded.
discarded.</t> If a replayed Map-Reply arrives at the ITR, there is no &lt;nonce,ITR
-OTK&gt;
<t>In case of replayed Map-Request, the Map-Server, Map-Resolver and that matches the incoming Map-Reply and the replayed Map-Reply will be
discarded.</t>
<t indent="0" pn="section-7.6-2">In the case of a replayed Map-Request,
the Map-Server, Map-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> 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>
<section anchor="DTLS" numbered="true" toc="include" removeInRFC="false" p
<section anchor="DTLS" title="Message Privacy"> n="section-7.7">
<t>DTLS <xref target="RFC9147"/> SHOULD be used (conforming to <xref tar <name slugifiedName="name-message-privacy">Message Privacy</name>
get="RFC7525"/>) to provide communication privacy and to prevent eavesdropping, <t indent="0" pn="section-7.7-1">DTLS <xref target="RFC9147" format="def
tampering, or message forgery to the messages exchanged between the ITR, Map-Res ault" sectionFormat="of" derivedContent="RFC9147"/> <bcp14>SHOULD</bcp14> be use
olver, Map-Server, and ETR, unless the OTK is encrypted in another way, e.g. usi d (conforming to <xref target="RFC7525" format="default" sectionFormat="of" deri
ng a pre-shared secret. DTLS has the responder be verified by the initiator, wh vedContent="RFC7525"/>) to provide communication privacy and to prevent eavesdro
ich enables an ITR to autheticate the Map-Resolver, and the Map-Server to authen pping, tampering, or message forgery to the messages exchanged between the ITR,
ticate the responding ETR.</t> Map-Resolver, Map-Server, and ETR, unless the OTK is encrypted in another way, e
.g., using a pre-shared secret. DTLS has the responder be verified by the initi
ator, which enables an ITR to authenticate the Map-Resolver and the Map-Server t
o authenticate the responding ETR.</t>
</section> </section>
<section anchor="dos" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="dos" ="section-7.8">
title="Denial of Service and Distributed Denial of Service Attack <name slugifiedName="name-denial-of-service-and-distr">Denial-of-Service
s"> and Distributed Denial-of-Service Attacks</name>
<t>LISP-SEC mitigates the risks of Denial of Service and Distributed <t indent="0" pn="section-7.8-1">LISP-SEC mitigates the risks of DoS and
Denial of Service attacks by protecting the integrity and DDoS attacks by protecting the integrity and
authenticating the origin of the Map-Request/Map-Reply messages, and authenticating the origin of the Map-Request/Map-Reply messages and
by preventing malicious ETRs from overclaiming EID prefixes that could by preventing malicious ETRs from overclaiming EID-Prefixes that could
re-direct traffic directed to a potentially large number of hosts.</t> redirect traffic directed to a potentially large number of hosts.</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn=
<section anchor="IANA" title="IANA Considerations"> "section-8">
<name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t>IANA is requested to create the sub-registries listed in the following <t indent="0" pn="section-8-1">IANA has created the subregistries listed i
sections in the "Locator/ID Separation Protocol (LISP) Parameters" registry. n the following sections in the "Locator/ID Separation Protocol (LISP) Parameter
s" registry.
</t> </t>
<t indent="0" pn="section-8-2"> For all of the subregistries, new values a
<t> For all of the sub-registries, new values beyond this document have to re assigned according to the Specification Required policy defined in <xref targ
be assigned according to the "Specification Required" policy defined in <xref et="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>. Exp
target="RFC8126"/>. Expert review should assess the security properties of newly ert Review should assess the security properties of newly added functions so tha
added functions, so that encryption robustness is remains strong. For instance, t encryption robustness remains strong. For instance, at the time of this writin
at the time of this writing the use of SHA-256-based functions is considered to g, the use of SHA-256-based functions is considered to provide sufficient protec
provide sufficient protection. Consultation with security experts may be needed tion. Consultation with security experts may be needed.
.
</t> </t>
<section anchor="ECM-AD-Type" numbered="true" toc="include" removeInRFC="f
<section anchor="ECM-AD-Type" title="ECM AD Type Registry"> alse" pn="section-8.1">
<t>IANA is requested to create the "ECM Authentication Data Type" <name slugifiedName="name-ecm-ad-type-registry">ECM AD Type Registry</na
registry with values 0-255, for use in the ECM LISP-SEC Extensions me>
<xref target="ECM_extensions"/>. Initial allocation of this registry is <t indent="0" pn="section-8.1-1">IANA has created the "LISP ECM Authenti
shown in <xref target="tableEADT"/>. cation Data Types"
registry with values 0-255 for use in the ECM LISP-SEC extensions
(see <xref target="ECM_extensions" format="default" sectionFormat="of" d
erivedContent="Section 6.1"/>). Initial allocations are shown in <xref target="t
ableEADT" format="default" sectionFormat="of" derivedContent="Table 2"/>.
</t> </t>
<table anchor="tableEADT" align="center" pn="table-2">
<texttable anchor="tableEADT" title="ECM Authentication Data Types."> <name slugifiedName="name-lisp-ecm-authentication-dat">LISP ECM Authen
<ttcol align="left">Name</ttcol> tication Data Types</name>
<ttcol align="center">Number</ttcol> <thead>
<ttcol align="left">Defined in</ttcol> <tr>
<c>Reserved</c><c>0</c><c>This memo</c> <th align="left" colspan="1" rowspan="1">Name</th>
<c>LISP-SEC-ECM-EXT</c><c>1</c><c>This memo</c> <th align="center" colspan="1" rowspan="1">Number</th>
</texttable> <th align="left" colspan="1" rowspan="1">Defined in</th>
</tr>
<t>Values 2-255 are unassigned. </t> </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>
<section anchor="MR-AD-Type" numbered="true" toc="include" removeInRFC="fa
<section anchor="MR-AD-Type" title="Map-Reply AD Type Registry"> lse" pn="section-8.2">
<t>IANA is requested to create the "Map-Reply Authentication Data <name slugifiedName="name-map-reply-ad-types-registry">Map-Reply AD Type
Type" registry with values 0-255, for use in the Map-Reply LISP-SEC s Registry</name>
Extensions <xref target="MR_extensions"/>. Initial allocation of this r <t indent="0" pn="section-8.2-1">IANA has created the "LISP Map-Reply Au
egistry is shown in <xref target="tableADT"/>. thentication Data
Types" registry with values 0-255 for use in the Map-Reply LISP-SEC
extensions (see <xref target="MR_extensions" format="default" sectionFor
mat="of" derivedContent="Section 6.2"/>). Initial allocations are shown in <xref
target="tableADT" format="default" sectionFormat="of" derivedContent="Table 3"/
>.
</t> </t>
<table anchor="tableADT" align="center" pn="table-3">
<texttable anchor="tableADT" title="Map-Reply Authentication Data <name slugifiedName="name-map-reply-authentication-da">Map-Reply Authe
Types."> ntication Data Types</name>
<ttcol align="left">Name</ttcol> <thead>
<ttcol align="center">Number</ttcol> <tr>
<ttcol align="left">Defined in</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<c>Reserved</c><c>0</c><c>This memo</c> <th align="center" colspan="1" rowspan="1">Number</th>
<c>LISP-SEC-MR-EXT</c><c>1</c><c>This memo</c> <th align="left" colspan="1" rowspan="1">Defined in</th>
</texttable> </tr>
</thead>
<t>Values 2-255 are unassigned. </t> <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>
<section anchor="HMAC" numbered="true" toc="include" removeInRFC="false" p
<section anchor="HMAC" title="HMAC Functions"> n="section-8.3">
<t>IANA is requested to create the "LISP-SEC Preferred Authentication Da <name slugifiedName="name-hmac-functions">HMAC Functions</name>
ta HMAC ID" registry with values 0-65535 for use as Requested HMAC ID, EID HMAC <t indent="0" pn="section-8.3-1">IANA is requested to create the "LISP-S
ID, and PKT HMAC ID in the LISP-SEC Authentication Data. Initial allocation of t EC Preferred Authentication Data HMAC IDs" registry with values 0-65535 for use
his registry is shown in <xref target="tableHMACF"/>. as Requested HMAC IDs, EID HMAC IDs, and PKT HMAC IDs in the LISP-SEC Authentica
tion Data. Initial allocations are shown in <xref target="tableHMACF" format="de
fault" sectionFormat="of" derivedContent="Table 4"/>.
</t> </t>
<table anchor="tableHMACF" align="center" pn="table-4">
<texttable anchor="tableHMACF" title="LISP-SEC Authentication Data HMAC <name slugifiedName="name-lisp-sec-preferred-authenti">LISP-SEC Prefer
Functions."> red Authentication Data HMAC IDs</name>
<ttcol align="left">Name</ttcol> <thead>
<ttcol align="center">Number</ttcol> <tr>
<ttcol align="left">Defined in</ttcol> <th align="left" colspan="1" rowspan="1">Name</th>
<c>NOPREF</c><c>0</c><c>This memo</c> <th align="center" colspan="1" rowspan="1">Number</th>
<c>AUTH-HMAC-SHA-1-96</c><c>1</c><c><xref target="RFC2104"/></c> <th align="left" colspan="1" rowspan="1">Defined in</th>
<c>AUTH-HMAC-SHA-256-128</c><c>2</c><c><xref target="RFC6234"/></c> </tr>
</texttable> </thead>
<tbody>
<t>Values 3-65535 are unassigned.</t> <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" deriv
edContent="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" deriv
edContent="RFC6234"/></td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-8.3-3">Values 3-65535 are unassigned.</t>
</section> </section>
<section anchor="wrap" numbered="true" toc="include" removeInRFC="false" p
<section anchor="wrap" title="Key Wrap Functions"> n="section-8.4">
<t>IANA is requested to create the "LISP-SEC Authentication Data Key <name slugifiedName="name-key-wrap-functions">Key Wrap Functions</name>
Wrap ID" registry with values 0-65535 for use as OTK key wrap <t indent="0" pn="section-8.4-1">IANA has created the "LISP-SEC Authenti
algorithms ID in the LISP-SEC Authentication Data. Initial allocation of cation Data Key
this registry is shown in <xref target="tableKWF"/>.</t> Wrap IDs" registry with values 0-65535 for use as OTK key wrap
algorithm IDs in the LISP-SEC Authentication Data. Initial allocations a
<texttable anchor="tableKWF" title="LISP-SEC Authentication Data Key re shown in <xref target="tableKWF" format="default" sectionFormat="of" derivedC
Wrap Functions."> ontent="Table 5"/>.</t>
<ttcol align="left">Name</ttcol> <table anchor="tableKWF" align="center" pn="table-5">
<ttcol align="center">Number</ttcol> <name slugifiedName="name-lisp-sec-authentication-dat">LISP-SEC Authen
<ttcol align="left">KEY WRAP</ttcol> tication Data Key Wrap IDs</name>
<ttcol align="left">KDF</ttcol> <thead>
<c>Reserved</c><c>0</c><c>None</c><c>None</c> <tr>
<c>NULL-KEY-WRAP-128</c><c>1</c><c>This memo</c><c>None</c> <th align="left" colspan="1" rowspan="1">Name</th>
<c>AES-KEY-WRAP-128+HKDF-SHA256</c><c>2</c><c><xref target="RFC3394" <th align="center" colspan="1" rowspan="1">Number</th>
/></c><c><xref target="RFC4868"/></c> <th align="left" colspan="1" rowspan="1">Key Wrap</th>
</texttable> <th align="left" colspan="1" rowspan="1">KDF</th>
<th align="left" colspan="1" rowspan="1">Reference</th>
<t/> </tr>
</thead>
<t>Values 3-65535 are unassigned. </t> <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-SHA
256</td>
<td align="center" colspan="1" rowspan="1">2</td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC3394" format="default" sectionFormat="of" deriv
edContent="RFC3394"/></td>
<td align="left" colspan="1" rowspan="1">
<xref target="RFC4868" format="default" sectionFormat="of" deriv
edContent="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>
<section anchor="kdf" numbered="true" toc="include" removeInRFC="false" pn
<section anchor="kdf" title="Key Derivation Functions"> ="section-8.5">
<t>IANA is requested to create the "LISP-SEC Authentication Data Key <name slugifiedName="name-key-derivation-functions">Key Derivation Funct
Derivation Function ID" registry with values 0-65535 for use as KDF ID. ions</name>
Initial allocation of this registry is shown in <xref target="tableKDF"/ <t indent="0" pn="section-8.5-1">IANA has created the "LISP-SEC Authenti
>.</t> cation Data Key
Derivation Function IDs" registry with values 0-65535 for use as KDF IDs
<texttable anchor="tableKDF" title="LISP-SEC Authentication Data Key .
Derivation Function ID."> Initial allocations are shown in <xref target="tableKDF" format="default
<ttcol width="20%" align="left">Name</ttcol> " sectionFormat="of" derivedContent="Table 6"/>.</t>
<ttcol width="20%" align="center">Number</ttcol> <table anchor="tableKDF" align="center" pn="table-6">
<ttcol align="center">Defined in</ttcol> <name slugifiedName="name-lisp-sec-authentication-data">LISP-SEC Authe
<c>NOPREF</c><c>0</c><c>This memo</c> ntication Data Key Derivation Function IDs</name>
<c>HKDF-SHA1-128 </c><c>1</c><c><xref target="RFC5869"/></c> <thead>
<c>HKDF-SHA256 </c><c>2</c><c><xref target="RFC5869"/></c> <tr>
</texttable> <th align="left" colspan="1" rowspan="1">Name</th>
<t>Values 2-65535 are unassigned. </t> <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" deriv
edContent="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" deriv
edContent="RFC5869"/></td>
</tr>
</tbody>
</table>
<t indent="0" pn="section-8.5-3">Values 3-65535 are unassigned. </t>
</section> </section>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to acknowledge Luigi Iannone, Pere Monclus, Dave
Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt N
oll for their valuable suggestions provided during the preparation of this docum
ent.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references pn="section-9">
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ie <name slugifiedName="name-references">References</name>
tf-lisp-rfc6833bis.xml'?> <references pn="section-9.1">
<name slugifiedName="name-normative-references">Normative References</na
<?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf me>
-lisp-rfc6830bis.xml'?> <reference anchor="RFC2104" target="https://www.rfc-editor.org/info/rfc2
104" quoteTitle="true" derivedAnchor="RFC2104">
<?rfc include="reference.RFC.2119"?> <front>
<title>HMAC: Keyed-Hashing for Message Authentication</title>
<?rfc include="reference.RFC.8126"?> <author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="M. Bellare" initials="M." surname="Bellare"/>
<?rfc include="reference.RFC.4868"?> <author fullname="R. Canetti" initials="R." surname="Canetti"/>
<date month="February" year="1997"/>
<?rfc include="reference.RFC.9147"?> <abstract>
<t indent="0">This document describes HMAC, a mechanism for messag
<?rfc include="reference.RFC.8174"?> e authentication using cryptographic hash functions. HMAC can be used with any
iterative cryptographic hash function, e.g., MD5, SHA-1, in combination with a s
<?rfc include="reference.RFC.7835"?> ecret shared key. The cryptographic strength of HMAC depends on the properties
of the underlying hash function. This memo provides information for the Interne
<?rfc include="reference.RFC.6234"?> t community. This memo does not specify an Internet standard of any kind</t>
</abstract>
<?rfc include="reference.RFC.5869"?> </front>
<seriesInfo name="RFC" value="2104"/>
<?rfc include="reference.RFC.3394"?> <seriesInfo name="DOI" value="10.17487/RFC2104"/>
</reference>
<?rfc include="reference.RFC.2104"?> <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<?rfc include="reference.RFC.7525"?> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
</references> le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<references title="Informational References"> <date month="March" year="1997"/>
<abstract>
<?rfc include="reference.RFC.4086"?> <t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
<?rfc include="reference.RFC.6836"?> pitalized. This document defines these words as they should be interpreted in I
ETF documents. This document specifies an Internet Best Current Practices for t
he 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/rfc3
394" 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/rfc4
868" 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 Messa
ge 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 ori
gin authentication and integrity verification mechanisms for the Authentication
Header (AH), Encapsulating Security Payload (ESP), Internet Key Exchange Protoco
l (IKE), and IKEv2 protocols, and also as Pseudo-Random Functions (PRFs) for IKE
and IKEv2. Truncated output lengths are specified for the authentication-relat
ed variants, with the corresponding algorithms designated as HMAC-SHA-256-128, H
MAC-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/rfc5
869" 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 Auth
entication Code (HMAC)-based key derivation function (HKDF), which can be used a
s a building block in various protocols and applications. The key derivation fu
nction (KDF) is intended to support a wide range of applications and requirement
s, and is conservative in its use of cryptographic hash functions. This documen
t is not an Internet Standards Track specification; it is published for informat
ional 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/rfc6
234" 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 3
rd"/>
<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/rfc7
525" quoteTitle="true" derivedAnchor="RFC7525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) 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 Transpor
t Layer Security (DTLS) are widely used to protect data exchanged over applicati
on protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few ye
ars, several serious attacks on TLS have emerged, including attacks on its most
commonly used cipher suites and their modes of operation. This document provide
s recommendations for improving the security of deployed services that use TLS a
nd 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/rfc7
835" 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 Loca
tor/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/rfc8
126" 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 t
hat use constants to identify various protocol parameters. To ensure that the va
lues in these fields do not have conflicting uses and to promote interoperabilit
y, 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, g
uidance 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. Th
is document defines a framework for the documentation of these guidelines by spe
cification authors, in order to assure that the provided guidance for the IANA C
onsiderations is clear and addresses the various issues that are likely in the o
peration of a registry.</t>
<t indent="0">This is the third edition of this document; it obsol
etes 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/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<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 clar
ifying that only UPPERCASE usage of the key words have the defined special meani
ngs.</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/rfc9
147" 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 applicat
ions to communicate over the Internet in a way that is designed to prevent eaves
dropping, tampering, and message forgery.</t>
<t indent="0">The DTLS 1.3 protocol is based on the Transport Laye
r Security (TLS) 1.3 protocol and provides equivalent security guarantees with t
he 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/rfc9
300" 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" r
ole="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/rfc9
301" 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" r
ole="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/rfc4
086" quoteTitle="true" derivedAnchor="RFC4086">
<front>
<title>Randomness Requirements for Security</title>
<author fullname="D. Eastlake 3rd" initials="D." surname="Eastlake 3
rd"/>
<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 a
lgorithms that foil pattern analysis attempts. However, the security of these sy
stems is dependent on generating secret quantities for passwords, cryptographic
keys, and similar quantities. The use of pseudo-random processes to generate sec
ret quantities can result in pseudo-security. A sophisticated attacker may find
it easier to reproduce the environment that produced the secret quantities and t
o 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 pi
tfalls in using poor entropy sources or traditional pseudo-random number generat
ion techniques for generating such quantities. It recommends the use of truly ra
ndom hardware techniques and shows that the existing hardware on many systems ca
n be used for this purpose. It provides suggestions to ameliorate the problem wh
en 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 Interne
t 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/rfc6
836" 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 s
ystem to be used by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Route
r (ITR) or Map-Resolver (MR) to find the Egress Tunnel Router (ETR) that holds t
he mapping information for a particular Endpoint Identifier (EID). The MR can t
hen 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 T
opology (ALT), the index is built as an overlay network on the public Internet u
sing 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> </references>
<section anchor="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 acknowle
dge <contact fullname="Luigi Iannone"/>, <contact fullname="Pere Monclus"/>, <co
ntact fullname="Dave Meyer"/>, <contact fullname="Dino Farinacci"/>, <contact fu
llname="Brian Weis"/>, <contact fullname="David McGrew"/>, <contact fullname="Da
rrel Lewis"/>, and <contact fullname="Landon Curt Noll"/> for their valuable sug
gestions provided during the preparation of this document.</t>
</section>
<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 Cataluny
a</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> </back>
</rfc> </rfc>
 End of changes. 154 change blocks. 
1010 lines changed or deleted 1970 lines changed or added

This html diff was produced by rfcdiff 1.48.