rfc9437xml2.original.xml   rfc9437.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!DOCTYPE rfc [
.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY RFC6835 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY zwsp "&#8203;">
.6835.xml"> <!ENTITY nbhy "&#8209;">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY wj "&#8288;">
.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC9300 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9300.xml">
<!ENTITY RFC9301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9301.xml">
<!ENTITY RFC9303 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9303.xml">
<!ENTITY I-D.ietf-lisp-eid-mobility SYSTEM "http://xml.resource.org/public/rfc/b
ibxml3/reference.I-D.ietf-lisp-eid-mobility.xml">
<!ENTITY I-D.haindl-lisp-gb-atn SYSTEM "http://xml.resource.org/public/rfc/bibxm
l3/reference.I-D.haindl-lisp-gb-atn.xml">
<!ENTITY I-D.moreno-lisp-uberlay SYSTEM "http://xml.resource.org/public/rfc/bibx
ml3/reference.I-D.moreno-lisp-uberlay.xml">
<!ENTITY I-D.boucadair-lisp-pubsub-flow-examples SYSTEM "http://xml.resource.org
/public/rfc/bibxml3/reference.I-D.boucadair-lisp-pubsub-flow-examples.xml">
<!ENTITY I-D.ietf-lisp-yang SYSTEM "http://xml.resource.org/public/rfc/bibxml3/r
eference.I-D.ietf-lisp-yang.xml">
]> ]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e., [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-lisp-pubsub-15" ipr="trust200902" consen
sus="true">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-lisp-pubsub-15" number="9437" ipr="tru st200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" s ymRefs="true" sortRefs="true" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="Pub/Sub Functionality for LISP">Publish/Subscribe Functionali
if the ty for the Locator/ID Separation Protocol (LISP)</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9437"/>
<title abbrev="LISP-PubSub">Publish/Subscribe Functionality for the Locator/
ID Separation Protocol (LISP)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez- Natal"> <author fullname="Alberto Rodriguez-Natal" initials="A." surname="Rodriguez- Natal">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Barcelona</city> <city>Barcelona</city>
<region></region> <region/>
<code></code> <code/>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone> <phone/>
<email>natal@cisco.com</email> <email>natal@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Vina Ermagan" initials="V." surname="Ermagan"> <author fullname="Vina Ermagan" initials="V." surname="Ermagan">
<organization>Google</organization> <organization>Google</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<region></region> <region/>
<code></code> <code/>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<phone></phone> <phone/>
<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." surname="Cabellos">
<organization>UPC/BarcelonaTech</organization> <organization>UPC/BarcelonaTech</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Barcelona</city> <city>Barcelona</city>
<region></region> <region/>
<code></code> <code/>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone></phone> <phone/>
<email>acabello@ac.upc.edu</email> <email>acabello@ac.upc.edu</email>
</address> </address>
</author> </author>
<author fullname="Sharon Barkai" initials="S." surname="Barkai"> <author fullname="Sharon Barkai" initials="S." surname="Barkai">
<organization>Nexar</organization> <organization>Nexar</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city></city> <city/>
<region></region> <region/>
<code></code> <code/>
<country></country> <country/>
</postal> </postal>
<phone></phone> <phone/>
<email>sharon.barkai@getnexar.com</email> <email>sharon.barkai@getnexar.com</email>
</address> </address>
</author> </author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<region></region> <region/>
<code></code> <code/>
<country>France</country> <country>France</country>
</postal> </postal>
<phone></phone> <phone/>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<date year="2023" month="July" />
<date year="2023" /> <area>rtg</area>
<workgroup>lisp</workgroup>
<area>Internet</area> <keyword>lisp</keyword>
<keyword>publish</keyword>
<workgroup>LISP Working Group</workgroup> <keyword>subscribe</keyword>
<keyword>subscription</keyword>
<keyword>lisp, publish, subscribe, subscription, sdn, nfv</keyword> <keyword>sdn</keyword>
<keyword>nfv</keyword>
<abstract> <abstract>
<t>This document specifies an extension to the request/reply based Locator <t>This document specifies an extension to the Locator/ID Separation
/ID Separation Protocol (LISP) control plane to enable Publish/Subscribe (PubSub Protocol (LISP) control plane to enable
) operation.</t> Publish/Subscribe (PubSub) operation.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t>The Locator/ID Separation Protocol (LISP) <xref target="RFC9300"></xref
> <xref target="RFC9301"></xref> splits IP addresses into two different namespac
es: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map an
d encapsulate (a.k.a., map-and-encap) approach that relies on (1) a Mapping Syst
em (basically a distributed database) that stores and disseminates EID-RLOC mapp
ings and on (2) LISP tunnel routers (xTRs) that encapsulate and decapsulate data
packets based on the content of those mappings.</t>
<t>Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers (RTRs)
/ Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC mapping information from
the Mapping System by means of an explicit request message. Section 6.1 of <xre
f target="RFC9301"></xref> indicates how Egress Tunnel Routers (ETRs) can tell I
TRs/RTRs/PITRs about mapping changes. This document presents a Publish/Subscribe
(PubSub) extension in which the Mapping System can notify ITRs/RTRs/PITRs about
mapping changes. When this mechanism is used, mapping changes can be notified f
aster and can be managed in the Mapping System versus the LISP sites.</t>
<t>In general, when an ITR/RTR/PITR wants to be notified for mapping chang
es for a given EID-Prefix, the following main steps occur:</t>
<t><list style="format (%d)">
<t>The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with the No
tification-Requested bit (N-bit) set and which also includes its xTR-ID and Site
-ID.</t>
<t>The Map-Request is forwarded to one of the Map-Servers that the EID-P
refix is registered to.</t>
<t>The Map-Server creates subscription state for the ITR/RTR/PITR on the
EID-Prefix.</t>
<t>The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm that
the subscription has been created and then waits for an acknowledgement of the
notification.</t>
<t>The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the succe
ssful receipt of the Map-Notify.</t>
<t>When there is a change in the mapping of the EID-Prefix, the Map-Serv
er sends a Map-Notify message to each ITR/RTR/PITR in the subscription list.</t>
<t>Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the received
Map-Notify.</t>
</list></t>
<t>The Locator/ID Separation Protocol (LISP) <xref target="RFC9300"
format="default"/> <xref target="RFC9301" format="default"/> splits IP
addresses into two different namespaces: Endpoint Identifiers (EIDs) and
Routing Locators (RLOCs). LISP uses a map and encapsulate (a.k.a.,
map-and-encap) approach that relies on (1) a Mapping System (basically a
distributed database) that stores and disseminates EID-RLOC mappings and
on (2) LISP Tunnel Routers (xTRs) that encapsulate and decapsulate data
packets based on the content of those mappings.</t>
<t>Ingress Tunnel Routers (ITRs), Re-encapsulating Tunnel Routers
(RTRs), and Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC mapping
information from the Mapping System by means of an explicit request
message. <xref target="RFC9301" sectionFormat="of" section="6.1"/>
indicates how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs
about mapping changes. This document presents a Publish/Subscribe
(PubSub) extension in which the Mapping System can notify
ITRs/RTRs/PITRs about mapping changes. When this mechanism is used,
mapping changes can be notified faster and can be managed in the Mapping
System versus the LISP sites.</t>
<t>In general, when an ITR/RTR/PITR wants to be notified for mapping
changes for a given EID-Prefix, the following main steps occur:</t>
<ol spacing="normal">
<li>The ITR/RTR/PITR builds a Map-Request for that EID-Prefix with the
Notification-Requested bit (N-bit) set and that also includes its
xTR-ID and Site-ID.</li>
<li>The Map-Request is forwarded to one of the Map-Servers that the
EID-Prefix is registered to.</li>
<li>The Map-Server creates subscription state for the ITR/RTR/PITR on
the EID-Prefix.</li>
<li>The Map-Server sends a Map-Notify to the ITR/RTR/PITR to confirm
that the subscription has been created and then waits for an
acknowledgement of the notification.</li>
<li>The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the
successful receipt of the Map-Notify.</li>
<li>When there is a change in the mapping of the EID-Prefix, the
Map-Server sends a Map-Notify message to each ITR/RTR/PITR in the
subscription list.</li>
<li>Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
received Map-Notify.</li>
</ol>
<t>This operation is repeated for all EID-Prefixes for which ITRs/RTRs/PIT Rs want to be notified. An ITR/RTR/PITR can set the N-bit for several EID-Prefix es within a single Map-Request. Please note that the steps above illustrate only the simplest scenario and that details for this and other scenarios are describ ed later in the document.</t> <t>This operation is repeated for all EID-Prefixes for which ITRs/RTRs/PIT Rs want to be notified. An ITR/RTR/PITR can set the N-bit for several EID-Prefix es within a single Map-Request. Please note that the steps above illustrate only the simplest scenario and that details for this and other scenarios are describ ed later in the document.</t>
<t>The reader may refer to <xref target="I-D.boucadair-lisp-pubsub-flow-ex
amples" format="default"/> for sample flows to illustrate the use of the PubSub
specification.</t>
<section anchor="app-scope" numbered="true" toc="default">
<name>Scope of Applicability</name>
<t>The reader may refer to <xref target="I-D.boucadair-lisp-pubsub-flow-ex <t>The PubSub procedure specified in this document is intended for use i
amples"></xref> for sample flows to illustrate the use of the PubSub specificati n contexts with controlled access to the Map-Server. How a deployment controls a
on.</t> ccess to a Map-Server is deployment specific and therefore out of the scope of t
his document. However, the Map-Resolvers and Map-Servers need to be configured w
<section anchor="app-scope" title="Scope of Applicability"> ith the required information to ensure at least the following:</t>
<ol spacing="normal">
<t>The PubSub procedure specified in this document is intended to be us <li>Map-Resolvers <bcp14>MUST</bcp14> verify that an xTR is allowed
ed in contexts with controlled access to the Map-Server. How a deployment contro to (1) set the N-bit to 1 and (2) use the xTR-ID, Site-ID, and
ls access to a Map-Server is deployment specific, and therefore out of the scope ITR-RLOCs included in a Map-Request.</li>
of this document. However, the Map-Resolvers and Map-Servers need to be configu <li>Map-Servers <bcp14>MUST</bcp14> only accept subscription
red with the required information to at least ensure the following:</t> requests from Map-Resolvers that verify Map-Requests as previously
described.</li>
<t><list style="format (%d)"> </ol>
<t>Map-Resolvers MUST verify that an xTR is allowed to (1) set the N-b
it to 1 and (2) use the xTR-ID, Site-ID, and ITR-RLOCs included in a Map-Request
.</t>
<t>Map-Servers MUST only accept subscription requests from Map-Resolve
rs that verify Map-Requests as previously described.</t>
</list></t>
</section> </section>
</section>
<section numbered="true" toc="default">
<name>Terminology and Requirements Notation</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>The document uses the terms defined in <xref target="RFC9300"
sectionFormat="of" section="3"/>. </t>
</section> </section>
<section title="Terminology and Requirements Notation"> <section anchor="assumptions" numbered="true" toc="default">
<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "S <name>Deployment Requirements</name>
HOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in <t>In addition to the general assumptions and expectations that <xref targ
this document are to be interpreted as described in BCP 14 <xref target="RFC211 et="RFC9301" format="default"/> makes for LISP deployments, this document impose
9"></xref> <xref target="RFC8174"></xref> when, and only when, they appear in al s the following deployment requirements: </t>
l capitals, as shown here.</t> <ol spacing="normal">
<li>A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
<t>The document uses the terms defined in Section 3 of <xref target="RFC9 assigned to each xTR.</li>
300"></xref>. </t> <li>Map-Servers are configured to proxy Map-Replying (i.e., they are
solicited to generate and send Map-Reply messages) for the mappings
</section> they are serving.</li>
<li>A security association (e.g., a PubSubKey) is required between the
<section anchor="assumptions" title="Deployment Requirements"> ITRs and the Map-Servers (see <xref target="association"
format="default"/>).</li>
<t>In addition to the general assumptions and expectations that <xref ta </ol>
rget="RFC9301"></xref> makes for LISP deployments, this document makes the follo <t>If a requirement is not met, a subscription cannot be established, and
wing deployment requirements: </t> the network will continue operating without this enhancement. The configuration
of xTR-IDs and Site-IDs is out of the scope of this document. The reader may ref
<t><list style="format (%d)"> er to <xref target="I-D.ietf-lisp-yang" format="default"/> for an example of how
<t>A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is assig these identifiers can be provisioned to LISP nodes.</t>
ned to each xTR.</t> </section>
<t>Map-Servers are configured to proxy Map-Replying (i.e., they are so <section anchor="map-request" numbered="true" toc="default">
licited to generate and send Map-Reply messages) for the mappings they are servi <name>Map-Request PubSub Additions</name>
ng.</t> <t><xref target="mrq-fig" format="default"/> shows the format of the updat
<t>A security association (e.g., a PubSubKey) is required between the ed Map-Request to support the PubSub functionality. In particular, this document
ITRs and the Map-Servers (see <xref target="association"></xref>).</t> associates a meaning with one of the reserved bits (see <xref target="IANA" for
</list></t> mat="default"/>). </t>
<figure anchor="mrq-fig">
<t>If a requirement is not met, a subscription cannot be established, an <name>Map-Request with I-bit, N-bit, xTR-ID, and Site-ID</name>
d the network will continue operating without this enhancement. The configuratio <artwork align="center" name="" type="" alt=""><![CDATA[
n of xTR-IDs and Site-IDs is out of the scope of this document. The reader may r
efer to <xref target="I-D.ietf-lisp-yang"></xref> for an example of how these id
entifiers can be provisioned to LISP nodes.</t>
</section>
<section anchor="map-request" title="Map-Request PubSub Additions">
<t><xref target="mrq-fig"></xref> shows the format of the updated Map-Re
quest to support the PubSub functionality. In particular, this document associat
es a meaning with one of the reserved bits (see <xref target="IANA"></xref>). </
t>
<t><figure align="center"
anchor="mrq-fig"
title="Map-Request with I-bit, N-bit, xTR-ID, and Site-ID">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count | |Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
skipping to change at line 252 skipping to change at line 230
| | | |
+ xTR-ID + + xTR-ID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Site-ID + + Site-ID +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The following is added to the Map-Request message defined in <xref
<t>The following is added to the Map-Request message defined in Sectio target="RFC9301" sectionFormat="of" section="5.2"/>:</t>
n 5.2 of <xref target="RFC9301"></xref>:</t> <dl newline="false" spacing="normal">
<dt>xTR-ID bit (I-bit):</dt>
<t><list style="hanging"> <dd>This bit is set to 1 to indicate that 128-bit xTR-ID and 64-bit
<t>xTR-ID bit (I-bit): This bit is set to 1 to indicate that 128-bit Site-ID fields are present in the Map-Request message. For PubSub
xTR-ID and 64-bit Site-ID fields are present in the Map-Request message. For Pu operation, an xTR <bcp14>MUST</bcp14> be configured with an xTR-ID and
bSub operation, an xTR MUST be configured with an xTR-ID and Site-ID, and it MUS Site-ID, and it <bcp14>MUST</bcp14> set the I-bit to 1 and include its
T set the I-bit to 1 and include its xTR-ID and Site-ID in the Map-Request messa xTR-ID and Site-ID in the Map-Request messages it generates. If the
ges it generates. If the I-bit is set, but the Site-ID and/or xTR-ID are not inc I-bit is set but the Site-ID and/or xTR-ID are not included, a
luded, a receiver can detect the error because, after processing that last EID-r receiver can detect the error because, after processing that last
ecord, there are no bytes left from processing the message. In this case, the re EID-Record, there are no bytes left from processing the message. In
ceiver SHOULD log a malformed Map-Request and MUST drop the message.</t> this case, the receiver <bcp14>SHOULD</bcp14> log a malformed
Map-Request and <bcp14>MUST</bcp14> drop the message.</dd>
<t>Notification-Requested bit (N-bit): The N-bit of an EID-Record is <dt>Notification-Requested bit (N-bit):</dt>
set to 1 to specify that the xTR wants to be notified of updates for that EID-P <dd>The N-bit of an EID-Record is set to 1 to specify that the xTR
refix.</t> wants to be notified of updates for that EID-Prefix.</dd>
<dt>xTR-ID field:</dt>
<t>xTR-ID field: If the I-bit is set, this field is added to the Map <dd>If the I-bit is set, this field is added to the Map-Request
-Request message as shown in <xref target="mrq-fig"></xref>, starting right afte message as shown in <xref target="mrq-fig" format="default"/>,
r the final Record in the message (or the Map-Reply Record, if present). The xTR starting right after the final Record in the message (or the Map-Reply
-ID is specified in Section 5.6 of <xref target="RFC9301"></xref>.</t> Record, if present). The xTR-ID is specified in <xref target="RFC9301"
sectionFormat="of" section="5.6"/>.</dd>
<t>Site-ID field: If the I-bit is set, this field is added to the Ma <dt>Site-ID field:</dt>
p-Request message as shown in <xref target="mrq-fig"></xref>, following the xTR- <dd>If the I-bit is set, this field is added to the Map-Request
ID field. The Site-ID is defined in Section 5.6 of <xref target="RFC9301"></xre message as shown in <xref target="mrq-fig" format="default"/>,
f>.</t> following the xTR-ID field. The Site-ID is defined in <xref
</list></t> target="RFC9301" sectionFormat="of" section="5.6"/>.</dd>
</dl>
</section> </section>
<section anchor="sub" numbered="true" toc="default">
<section anchor="sub" title="Mapping Request Subscribe Procedures"> <name>Mapping Request Subscribe Procedures</name>
<t> The xTR subscribes for changes to a given EID-Prefix by sending a
<t> The xTR subscribes for changes, to a given EID-Prefix, by sending Map-Request to the Mapping System with the N-bit set on the
a Map-Request to the Mapping System with the N-bit set on the EID-Record. The xT EID-Record. The xTR builds a Map-Request according to <xref
R builds a Map-Request according to Section 5.3 of <xref target="RFC9301"></xref target="RFC9301" sectionFormat="of" section="5.3"/> and also does the
> but also does the following: </t> following: </t>
<ol spacing="normal">
<t><list style="format (%d)"> <li>The xTR <bcp14>MUST</bcp14> set the I-bit to 1 and append its
xTR-ID and Site-ID to the Map-Request.</li>
<t>The xTR MUST set the I-bit to 1 and append its xTR-ID and Site-ID <li>The xTR <bcp14>MUST</bcp14> set the N-bit to 1 for the EID-Record
to the Map-Request.</t> to which the xTR wants to subscribe.</li>
<t>The xTR MUST set the N-bit to 1 for the EID-Record to which the x <li>If the xTR has a nonce associated with the EID-Prefix, it
TR wants to subscribe.</t> <bcp14>MUST</bcp14> use this nonce increased by one in the
<t>If the xTR has a nonce associated with the EID-Prefix, it MUST us Map-Request. Otherwise, it generates a nonce as described in <xref
e this nonce increased by one in the Map-Request. Otherwise, it generates a nonc target="RFC9301" sectionFormat="of" section="5.2"/>. It is
e following Section 5.2 of <xref target="RFC9301"></xref>. It is RECOMMENDED tha <bcp14>RECOMMENDED</bcp14> that the xTR use persistent storage to
t the xTR uses persistent storage to keep nonce state. If the xTR does not have keep nonce state. If the xTR does not have persistent storage and does
persistent storage and does not have a nonce associated with the EID-Prefix, it not have a nonce associated with the EID-Prefix, it
MUST reset the nonce by using the procedure described in <xref target="associati <bcp14>MUST</bcp14> reset the nonce by using the procedure described
on"></xref> to successfully create a new security association with the Map-Serve in <xref target="association" format="default"/> to successfully
r.</t> create a new security association with the Map-Server.</li>
</ol>
</list></t> <t>The Map-Request is forwarded to the appropriate Map-Server through the
Mapping System. This document does not assume that a Map-Server is pre-assigned
<t>The Map-Request is forwarded to the appropriate Map-Server through to handle the subscription state for a given xTR. The Map-Server that receives t
the Mapping System. This document does not assume that a Map-Server is pre-assig he Map-Request will be the Map-Server responsible for notifying that specific xT
ned to handle the subscription state for a given xTR. The Map-Server that receiv R about future mapping changes for the subscribed mapping records.</t>
es the Map-Request will be the Map-Server responsible for notifying that specifi <t>Upon receipt of the Map-Request, the Map-Server processes it as
c xTR about future mapping changes for the subscribed mapping records.</t> described in <xref target="RFC9301" sectionFormat="of"
section="8.3"/>. In addition, unless the xTR is using the procedure
<t>Upon receipt of the Map-Request, the Map-Server processes it as des described in <xref target="association" format="default"/> to create a
cribed in Section 8.3 of <xref target="RFC9301"></xref>. In addition, unless the new security association, the Map-Server <bcp14>MUST</bcp14> verify that
xTR is using the procedure described in <xref target="association"></xref> to c the nonce in the Map-Request is greater than the stored nonce (if any)
reate a new security association, the Map-Server MUST verify that the nonce in t associated with the xTR-ID (and EID-Prefix, when applicable). Otherwise,
he Map-Request is greater than the stored nonce (if any) associated with the xTR the Map-Server <bcp14>MUST</bcp14> silently drop the Map-Request message
-ID (and EID-Prefix, when applicable). Otherwise, the Map-Server MUST silently d and <bcp14>SHOULD</bcp14> log the event to record that a replay attack
rop the Map-Request message and SHOULD log the event to record that a replay att could have occurred. Furthermore, upon processing, for the EID-Record
ack could have occurred. Furthermore, upon processing, for the EID-Record that h that has the N-bit set to 1, the Map-Server proceeds to add the xTR-ID
as the N-bit set to 1, the Map-Server proceeds to add the xTR-ID contained in th contained in the Map-Request to the list of xTRs that have requested to
e Map-Request to the list of xTRs that have requested to be subscribed to that E be subscribed to that EID-Prefix. </t>
ID-Prefix. </t> <t>If an xTR-ID is successfully added to the list of subscribers for an
EID-Prefix, the Map-Server <bcp14>MUST</bcp14> extract the nonce and
<t>If an xTR-ID is successfully added to the list of subscribers for a ITR-RLOCs present in the Map-Request and store the association between
n EID-Prefix, the Map-Server MUST extract the nonce and ITR-RLOCs present in the the EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state that is already
Map-Request, and store the association between the EID-Prefix, xTR-ID, ITR-RLOC present regarding ITR-RLOCs and/or nonce for the same xTR-ID
s, and nonce. Any already present state regarding ITR-RLOCs and/or nonce for th <bcp14>MUST</bcp14> be overwritten. When the LISP deployment has a
e same xTR-ID MUST be overwritten. When the LISP deployment has a single Map-Ser single Map-Server, the Map-Server can be configured to keep a single
ver, the Map-Server can be configured to keep a single nonce per xTR-ID for all nonce per xTR-ID for all EID-Prefixes (when used, this option
EID-Prefixes (when used, this option MUST be enabled at the Map-Server and all x <bcp14>MUST</bcp14> be enabled at the Map-Server and all xTRs).</t>
TRs).</t>
<t>If the xTR-ID is added to the list, the Map-Server MUST send a Map-
Notify message back to the xTR to acknowledge the successful subscription. The M
ap-Server builds the Map-Notify according to Sections 5.5 and 5.7 of <xref targe
t="RFC9301"></xref> with the following considerations:</t>
<t><list style="format (%d)">
<t>The Map-Server MUST use the nonce from the Map-Request as the non
ce for the Map-Notify.</t>
<t>The Map-Server MUST use its security association with the xTR (<x
ref target="association"></xref>) to sign the authentication data of the Map-Not
ify. The xTR MUST use the security association to verify the received authentica
tion data. </t>
<t>The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs r
eceived in the Map-Request (which one is implementation specific).</t>
</list></t>
<t>As a reminder, the initial transmission and retransmission of Map-N
otify messages by a Map-Server follow the procedure specified in Section 5.7 of
<xref target="RFC9301"></xref>. Some state changes may trigger an overload that
would impact, e.g., the outbound capacity of a Map-Server. A similar problem may
be experienced when a large number of state entries are simultaneously updated.
To prevent such phenomena, Map-Servers SHOULD be configured with policies to co
ntrol the maximum number of subscriptions and also the pace of Map-Notify messag
es. For example, the Map-Server may be instructed to limit the resources that ar
e dedicated to unsolicited Map-Notify messages to a small fraction (e.g., less t
han 10%) of its overall processing and forwarding capacity. The exact details to
characterize such policies are deployment and implementation specific. Likewis
e, this document does not specify which notifications take precedence when these
policies are enforced.</t>
<t>When the xTR receives a Map-Notify with a nonce that matches one in
the list of outstanding Map-Request messages sent with an N-bit set, it knows t
hat the Map-Notify is to acknowledge a successful subscription. The xTR processe
s this Map-Notify, as described in Section 5.7 of <xref target="RFC9301"></xref>
, and MUST use the Map-Notify to populate its Map-Cache with the returned EID-Pr
efix and RLOC-set. As a reminder, following Section 5.7 of <xref target="RFC9301
"></xref>, the xTR has to send a Map-Notify-Ack back to the Map-Server. If the M
ap-Server does not receive the Map-Notify-Ack after exhausting the Map-Notify re
transmissions described in Section 5.7 of <xref target="RFC9301"></xref>, the Ma
p-Server can remove the subscription state. If the Map-Server removes the subscr
iption state, and absent explicit policy, it SHOULD notify the xTR by sending a
single Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0),
and ACT bits set to 5 "Drop/Auth-Failure". It is OPTIONAL for the xTR to update
its map-cache entry for the EID-Prefix (if any) based on this Map-Notify. This m
essage is specifically useful for cases where Map-Notifies are successfully rece
ived by an xTR but the corresponding Map-Notify-Acks were lost when forwarded to
the Map-Server. xTR implementations can use this signal to try to reinstall the
ir subscription state instead of maintaining stale mappings.</t>
<t>The subscription of an xTR-ID may fail for a number of reasons. For
example, it fails because of local configuration policies (such as accept and d
rop lists of subscribers), because the Map-Server has exhausted the resources to
dedicate to the subscription of that EID-Prefix (e.g., the number of subscriber
s excess the capacity of the Map-Server), or because the xTR tried but was not s
uccessful in establishing a new security association (<xref target="association"
></xref>).</t>
<t>If the subscription request fails, the Map-Server sends a Map-Reply
to the originator of the Map-Request, as described in Section 8.3 of <xref targ
et="RFC9301"></xref>, with the following considerations:</t>
<t><list style="symbols">
<t>If the subscription request fails due to policy (e.g. for explici
tly configured subscriptions, as described later in this section) the Map-Server
MUST respond to the Map-Request with a Negative Map-Reply (Loc-Count = 0 and Lo
c-AFI = 0) with ACT bits set to 4 "Drop/Policy-Denied".</t>
<t>If the subscription request fails due to authentication (e.g. whe
n a new security associationg is being established, as described in <xref target
="association"></xref>), the Map-Server MUST respond to the Map-Request with a N
egative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 5 "Drop/A
uth-Failure".</t>
<t>If the subscription request fails due to any other reason, the Ma
p-Server MUST follow Section 8.3 of <xref target="RFC9301"></xref> with no chang
es.</t>
</list></t>
<t>The xTR processes any (Negative) Map-Reply as specified in Section
8.1 of <xref target="RFC9301"></xref>, with the following considerations: if the
xTR receives a Negative Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" o
r 5 "Drop/Auth-Failure" as a response to a subscription request, it is OPTIONAL
for the xTR to update its map-cache entry for the EID-Prefix (if any) based on t
his Negative Map-Reply. If the subscription request fails (for whichever reason)
, it is up to the implementation of the xTR to try to subscribe again.</t>
<t>If the Map-Server receives a subscription request for an EID-Prefix
not present in the mapping database, it SHOULD follow the same logic described
in Section 8.4 of <xref target="RFC9301"></xref> and create a temporary subscrip
tion state for the xTR-ID to the least-specific prefix that both matches the ori
ginal query and does not match any EID-Prefix known to exist in the LISP-capable
infrastructure. Alternatively, the Map-Server can instead determine that such a
subscription request fails, and send a Negative Map-Reply following Section 8.3
of <xref target="RFC9301"></xref>. In both cases, the TTL of the temporary subs
cription state or the Negative Map-Reply SHOULD be configurable, with a value of
15-minutes being RECOMMENDED. </t>
<t>The subscription state can also be created explicitly by configurat
ion at the Map-Server (possible when a pre-shared security association exists, s
ee <xref target="security"></xref>) using a variety of means that are out of sco
pe. If at the time the explicit subscription is configured there is no nonce tha
t can be used for the explicit subscription state (e.g., from a different subscr
iption already established with the same xTR when a single nonce is kept per xTR
-ID), then both the xTR and Map-Server MUST be configured with the initial nonce
to use. It is RECOMMENDED to have a configuration option to enable (or disable)
the xTR to accept publication information for EID-Prefixes the xTR did not expl
icitly subscribe to. By default, the xTR is allowed to modify explicitly configu
red subscription state following the procedures described in this section, howev
er this MAY be disabled at the Map-Server via configuration. If the Map-Server i
s instructed to not allow xTRs to modify explicitly configured subscriptions, an
d an xTR tries to do so, this triggers a Negative Map-Reply with ACT bits set to
4 "Drop/Policy-Denied" as described earlier in this section.</t>
<t>The following specifies the procedure to remove a subscription: If
a valid Map-Request with the N-bit set to 1 only has one ITR-RLOC with AFI = 0 (
i.e., Unknown Address), the Map-Server MUST remove the subscription state for th
at xTR-ID (unless this is disabled via configuration, see previous paragraph). I
f the subscription state is removed, the Map-Server MUST send a Map-Notify to th
e source RLOC of the Map-Request. If the subscription removal fails due to confi
guration, this triggers a Negative Map-Reply with with ACT bits set to 4 "Drop/P
olicy-Denied" as described earlier in this section; the Map-Server sends the Neg
ative Map-Reply to the source RLOC of the Map-Request in this case. Removing sub
scription state at the Map-Server can lead to replay attacks. To soften this, th
e Map-Server SHOULD keep the last nonce seen per xTR-ID (and EID-Prefix, when ap
plicable). If the Map-Server does not keep last nonces seen, then the Map-Server
MUST require the xTRs to subscribe using the procedure described in <xref targe
t="association"></xref> to create a new security association with the Map-Server
.</t>
<t>If the Map-Server receives a Map-Request asking to remove a subscri
ption for an EID-Prefix without subscription state for that xTR-ID, but covered
by a less-specific EID-Prefix for which subscription state exists for the xTR-ID
, the Map-Server SHOULD stop publishing updates about this more-specific EID-Pre
fix to that xTR, until the xTR subscribes to the more-specific EID-Prefix. The s
ame considerations regarding authentication, integrity protection, and nonce che
cks described in this section and <xref target="security"></xref> for Map-Reques
ts used to update subscription state, apply for Map-Requests used to remove subs
cription state.</t>
<t>When an EID-Prefix is removed from the Map-Server (either when expl
icitly withdrawn or when its TTL expires), the Map-Server notifies its subscribe
rs (if any) via a Map-Notify with TTL equal 0.</t>
</section>
<section anchor="publish" title="Mapping Notification Publish Procedures
">
<t>The publish procedure is implemented via Map-Notify messages that t
he Map-Server sends to xTRs. The xTRs acknowledge the reception of Map-Notifies
via sending Map-Notify-Ack messages back to the Map-Server. The complete mechani
sm works as follows: </t>
<t> When a mapping stored in a Map-Server is updated (e.g., via a Map-
Register from an ETR), the Map-Server MUST notify the subscribers of that mappin
g via sending Map-Notify messages with the most updated mapping information. If
subscription state in the Map-Server exists for a less-specific EID-Prefix and a
more-specific EID-Prefix is updated, then the Map-Notify is sent with the more-
specific EID-Prefix mapping to the subscribers of the less-specific EID-Prefix m
apping. The Map-Notify message sent to each of the subscribers as a result of an
update event follows the encoding and logic defined in Section 5.7 of <xref tar
get="RFC9301"></xref> for Map-Notify, except for the following:</t>
<t><list style="format (%d)">
<t>The Map-Notify MUST be sent to one of the ITR-RLOCs associated wi
th the xTR-ID of the subscriber (which one is implementation specific). </t>
<t>The Map-Server increments the nonce by one every time it sends a
Map-Notify as publication to an xTR-ID for a particular EID-Prefix. </t>
<t>The Map-Server MUST use its security association with the xTR to
compute the authentication data of the Map-Notify.</t>
</list></t>
<t>When the xTR receives a Map-Notify with an EID not local to the xTR
, the xTR knows that the Map-Notify has been received to update an entry on its
Map-Cache. The xTR MUST keep track of the last nonce seen in a Map-Notify receiv
ed as a publication from the Map-Server for the EID-Prefix. When the LISP deploy
ment has a single Map-Server, the xTR can be configured to keep track of a singl
e nonce for all EID-Prefix (when used, this option MUST be enabled at the Map-Se
rver and all xTRs). If a Map-Notify received as a publication has a nonce value
that is not greater than the saved nonce, the xTR drops the Map-Notify message a
nd logs the fact a replay attack could have occurred. The same considerations di
scussed in Section 5.6 of <xref target="RFC9301"></xref> regarding Map-Register
nonces apply here for Map-Notify nonces.</t>
<t>The xTR processes the received Map-Notify as specified in Section 5
.7 of <xref target="RFC9301"></xref>, with the following considerations: The xTR
MUST use its security association with the Map-Server (<xref target="associatio
n"></xref>) to validate the authentication data on the Map-Notify. The xTR MUST
use the mapping information carried in the Map-Notify to update its internal Map
-Cache. If after following Section 5.7 of <xref target="RFC9301"></xref> regardi
ng retransmission of Map-Notify messages, the Map-Server has not received back t
he Map-Notify-Ack, it can try to send the Map-Notify to a different ITR-RLOC for
that xTR-ID. If the Map-Server tries all the ITR-RLOCs without receiving a resp
onse, it may stop trying to send the Map-Notify.</t>
</section>
<section anchor="security" title="Security Considerations">
<t>Generic security considerations related to LISP control messages ar
e discussed in Section 9 of <xref target="RFC9301"></xref>. </t>
<t>In the particular case of PubSub, cache poisoning via malicious Map
-Notify messages is avoided by the use of nonce and the security association bet
ween the ITRs and the Map-Servers.</t>
<t>It is RECOMMENDED to follow guidance from the last paragraph of Sec
tion 9 of <xref target="RFC9301"></xref> to ensure integrity protection of Map-R
equest messages (e.g., to prevent xTR-ID hijacking).</t>
<section anchor="association" title="Security Association between ITR
and Map-Server">
<t>Since Map-Notifies from the Map-Server to the ITR need to be auth
enticated, there is a need for a soft-state or hard-state security association (
e.g., a PubSubKey) between the ITRs and the Map-Servers. For some controlled dep
loyments, it might be possible to have a shared PubSubKey (or set of keys) betwe
en the ITRs and the Map-Servers. However, if pre-shared keys are not used in the
deployment, LISP-SEC <xref target="RFC9303"></xref> can be used as follows to c
reate a security association between the ITR and the Map-Server.</t>
<t>First, when the ITR is sending a Map-Request with the N-bit set f
ollowing <xref target="sub"></xref>, the ITR also performs the steps described i
n Section 6.4 of <xref target="RFC9303"></xref>. The ITR can then generate a Pub
SubKey by deriving a key from the One-Time Key (OTK) and Map-Request's nonce as
follows: PubSubKey = KDF(OTK + nonce), where KDF is the Key Derivation Function
indicated by the OTK Wrapping ID. If OTK Wrapping ID equals NULL-KEY-WRAP-128, t
hen the PubSubKey is the OTK. Note that as opposed to the pre-shared PubSubKey,
this generated PubSubKey is different per EID-Prefix to which an ITR subscribes
(since the ITR will use a different OTK per Map-Request).</t>
<t>When the Map-Server receives the Map-Request it follows the proce
dure specified in <xref target="sub"></xref> with the following considerations:
The Map-Server MUST verify that the OTK has not been used before. If the Map-Ser
ver verifies the OTK and cannot determine that the OTK has not been used before,
the subscription request fails due to authentication and this triggers a Negati
ve Map-Reply with ACT bits set to 5 "Drop/Auth-Failure", as described in <xref t
arget="sub"></xref>. The xTR might try again with a different OTK upon reception
of this Negative Map-Reply. Note that a Map-Server implementation might decide
to not keep full past OTKs and instead use some form of hash. In that case, hash
collisions are handled as if the OTK has been reused. Such an implementation ne
eds to balance the hash length with the rate of collisions expected for the part
icular deployment; this is implementation specific. If the Map-Server has to rep
ly with a Map-Reply for any other reason (e.g., if PubSub is not supported or a
subscription is not accepted), then it follows normal LISP-SEC procedure describ
ed in Section 5.7 of <xref target="RFC9303"></xref>. No PubSubKey, security asso
ciation, or subscription state is created when the Map-Server responds with any
Map-Reply message.</t>
<t>Otherwise, if the Map-Server has to reply with a Map-Notify (e.g.
, due to subscription accepted) to a received Map-Request, the following extra s
teps take place:
<list style="symbols">
<t>The Map-Server extracts the OTK and OTK Wrapping ID from the
LISP-SEC ECM Authentication Data.</t>
<t>The Map-Server generates a PubSubKey by deriving a key from t
he OTK as described before for the ITR. This is the same PubSubKey derived at th
e ITR which is used to establish a security association between the ITR and the
Map-Server.</t>
<t>The PubSubKey can now be used to sign and authenticate any Ma
p-Notify between the Map-Server and the ITR for the subscribed EID-Prefix. This
includes the Map-Notify sent as a confirmation to the subscription. When the ITR
wants to update the security association for that Map-Server and EID-Prefix, it
once again follows the procedure described in this section.</t>
</list></t>
<t>Note that if the Map-Server replies with a Map-Notify, none of th
e regular LISP-SEC steps regarding Map-Reply described in Section 5.7 of <xref t
arget="RFC9303"></xref> occur.</t>
</section>
<section anchor="ddos" title="DDoS Attack Mitigation">
<t>If PubSub is deployed under the scope of applicability defined in <
xref target="app-scope"></xref> only known nodes can participate on the PubSub d
eployment. DDoS attacks based on replayed messages by unknown nodes are avoided
by the use of nonce and the security association between the ITRs and the Map-Se
rvers. Misbehaving known nodes may send massive subscription requests which may
lead to exhausting the resources of a Map-Server. Furthermore, frequently changi
ng the state of a subscription may also be considered as an attack vector. To mi
tigate such issues, Section 5.3 of <xref target="RFC9301"></xref> discusses rate
-limiting Map-Requests and Section 5.7 of <xref target="RFC9301"></xref> discuss
es rate-limiting Map-Notifies. Note that when the Map-Notify rate-limit threshol
d is met for a particular xTR-ID, the Map-Server will discard additional subscri
ption requests from that xTR-ID and will fall back to <xref target="RFC9301"></x
ref> behavior when receiving a Map-Request from that xTR-ID (i.e., the Map-Serve
r will send a Map-Reply).</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests IANA to assign a new bit from the "LISP Cont
rol Plane Header Bits: Map-Request" sub-registry under the "Locator/ID Separatio
n Protocol (LISP) Parameters" registry available at <xref target="IANA-LISP"></x
ref>. The suggested position of this bit in the Map-Request message can be found
in <xref target="mrq-fig"></xref>.</t>
<texttable title="Additions to the Map-Request Header Bits Sub-Registr
y">
<ttcol align='left'>Spec Name</ttcol>
<ttcol align='left'>IANA Name</ttcol>
<ttcol align='left'>Bit Position</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>I</c><c>Map-Request-I</c><c>11</c><c>xTR-ID Bit</c><c>This-Docume
nt</c>
</texttable>
<t> This document also requests the creation of a new sub-registry ent
itled "LISP Control Plane Header Bits: Map-Request-Record" under the "Locator/ID
Separation Protocol (LISP) Parameters" registry available at <xref target="IANA
-LISP"></xref>.</t>
<t>The initial content of this sub-registry is shown in <xref target="
bits-table"></xref>:</t>
<texttable anchor="bits-table" title="Initial Content of LISP Control
Plane Header Bits: Map-Request-Record Sub-Registry">
<ttcol align='left'>Spec Name</ttcol>
<ttcol align='left'>IANA Name</ttcol>
<ttcol align='left'>Bit Position</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>N</c><c>Map-Request-N</c><c>1</c><c>Notification-Requested Bit</c
><c>This-Document</c>
</texttable>
<t>The remaining bits (i.e., Bit positions 2-8) are Unassigned.</t>
<t>The policy for allocating new bits from this sub-registry is Specif
ication Required (Section 4.6 of <xref target="RFC8126"></xref>). </t>
<t>Review requests are evaluated on the advice of one or more designat
ed experts. Criteria that should be applied by the designated experts include de
termining whether the proposed registration duplicates existing entries and whet
her the registration description is sufficiently detailed and fits the purpose o
f this registry. These criteria are considered in addition to those already prov
ided in Section 4.6 of <xref target="RFC8126"></xref> (e.g., the proposed regist
ration must be documented in a permanent and readily available public specificat
ion). The designated experts will either approve or deny the registration reques
t, communicating this decision to IANA. Denials should include an explanation an
d, if applicable, suggestions as to how to make the request successful. </t>
</section> <t>If the xTR-ID is added to the list, the Map-Server
<bcp14>MUST</bcp14> send a Map-Notify message back to the xTR to
acknowledge the successful subscription. The Map-Server builds the
Map-Notify according to Sections <xref target="RFC9301" section="5.5"
sectionFormat="bare"/> and <xref target="RFC9301" section="5.7"
sectionFormat="bare"/> of <xref target="RFC9301" format="default"/> with
the following considerations:</t>
<ol spacing="normal">
<li>The Map-Server <bcp14>MUST</bcp14> use the nonce from the
Map-Request as the nonce for the Map-Notify.</li>
<li>The Map-Server <bcp14>MUST</bcp14> use its security association
with the xTR (<xref target="association" format="default"/>) to sign
the authentication data of the Map-Notify. The xTR <bcp14>MUST</bcp14>
use the security association to verify the received authentication
data. </li>
<li>The Map-Server <bcp14>MUST</bcp14> send the Map-Notify to one of
the ITR-RLOCs received in the Map-Request (which one is
implementation specific).</li>
</ol>
</middle> <t>As a reminder, the initial transmission and retransmission of
Map-Notify messages by a Map-Server follow the procedure specified in
<xref target="RFC9301" sectionFormat="of" section="5.7"/>. Some state
changes may trigger an overload that would impact, e.g., the outbound
capacity of a Map-Server. A similar problem may be experienced when a
large number of state entries are simultaneously updated. To prevent
such phenomena, Map-Servers <bcp14>SHOULD</bcp14> be configured with
policies to control the maximum number of subscriptions and also the
pace of Map-Notify messages. For example, the Map-Server may be
instructed to limit the resources that are dedicated to unsolicited
Map-Notify messages to a small fraction (e.g., less than 10%) of its
overall processing and forwarding capacity. The exact details to
characterize such policies are deployment and implementation specific.
Likewise, this document does not specify which notifications take
precedence when these policies are enforced.</t>
<t>When the xTR receives a Map-Notify with a nonce that matches one in
the list of outstanding Map-Request messages sent with an N-bit set, it
knows that the Map-Notify is to acknowledge a successful
subscription. The xTR processes this Map-Notify, as described in <xref
target="RFC9301" sectionFormat="of" section="5.7"/> and
<bcp14>MUST</bcp14> use the Map-Notify to populate its Map-Cache with
the returned EID-Prefix and RLOC-set. As a reminder, following <xref
target="RFC9301" sectionFormat="of" section="5.7"/>, the xTR has to send
a Map-Notify-Ack back to the Map-Server. If the Map-Server does not
receive the Map-Notify-Ack after exhausting the Map-Notify
retransmissions described in <xref target="RFC9301" sectionFormat="of"
section="5.7"/>, the Map-Server can remove the subscription state. If
the Map-Server removes the subscription state, and absent explicit
policy, it <bcp14>SHOULD</bcp14> notify the xTR by sending a single
Map-Notify with the same nonce but with Loc-Count = 0 (and Loc-AFI = 0)
and ACT bits set to 5 "Drop/Auth-Failure". It is <bcp14>OPTIONAL</bcp14>
for the xTR to update its Map-Cache entry for the EID-Prefix (if any)
based on this Map-Notify. This message is specifically useful for cases
where Map-Notifies are successfully received by an xTR, but the
corresponding Map-Notify-Acks are lost when forwarded to the
Map-Server. xTR implementations can use this signal to try to reinstall
their subscription state instead of maintaining stale mappings.</t>
<t>The subscription of an xTR-ID may fail for a number of reasons. For
example, it fails because of local configuration policies (such as
accept and drop lists of subscribers), because the Map-Server has
exhausted the resources to dedicate to the subscription of that
EID-Prefix (e.g., the number of subscribers excess the capacity of the
Map-Server), or because the xTR was not successful tried but was not succe
ssful in
establishing a new security association (<xref target="association"
format="default"/>).</t>
<back> <t>If the subscription request fails, the Map-Server sends a Map-Reply
to the originator of the Map-Request, as described in <xref
target="RFC9301" sectionFormat="of" section="8.3"/>, with the following
considerations:</t>
<ul spacing="normal">
<li>If the subscription request fails due to policy (e.g., for
explicitly configured subscriptions, as described later in this
section), the Map-Server <bcp14>MUST</bcp14> respond to the Map-Request
with a Negative Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT
bits set to 4 "Drop/Policy-Denied".</li>
<li>If the subscription request fails due to authentication (e.g., when
a new security association is being established, as described in
<xref target="association" format="default"/>), the Map-Server
<bcp14>MUST</bcp14> respond to the Map-Request with a Negative
Map-Reply (Loc-Count = 0 and Loc-AFI = 0) with ACT bits set to 5
"Drop/Auth-Failure".</li>
<li>If the subscription request fails due to any other reason, the
Map-Server <bcp14>MUST</bcp14> follow <xref target="RFC9301"
sectionFormat="of" section="8.3"/> with no changes.</li>
</ul>
<references title="Normative References"> <t>The xTR processes any Map-Reply or Negative Map-Reply as specified in <
xref
target="RFC9301" sectionFormat="of" section="8.1"/>, with the following
considerations: if the xTR receives a Negative Map-Reply with ACT bits
set to 4 "Drop/Policy-Denied" or 5 "Drop/Auth-Failure" as a response to
a subscription request, it is <bcp14>OPTIONAL</bcp14> for the xTR to
update its Map-Cache entry for the EID-Prefix (if any). If the subscriptio
n request fails (for whichever
reason), it is up to the implementation of the xTR to try to subscribe
again.</t>
<t>If the Map-Server receives a subscription request for an EID-Prefix
not present in the mapping database, it <bcp14>SHOULD</bcp14> follow the
same logic described in <xref target="RFC9301" sectionFormat="of"
section="8.4"/> and create a temporary subscription state for the xTR-ID
to the least specific prefix that both matches the original query and
does not match any EID-Prefix known to exist in the LISP-capable
infrastructure. Alternatively, the Map-Server can determine that
such a subscription request fails and send a Negative Map-Reply
following <xref target="RFC9301" sectionFormat="of" section="8.3"/>. In
both cases, the TTL of the temporary subscription state or the Negative
Map-Reply <bcp14>SHOULD</bcp14> be configurable, with a value of
15 minutes being <bcp14>RECOMMENDED</bcp14>. </t>
<t>The subscription state can also be created explicitly by
configuration at the Map-Server (possible when a pre-shared security
association exists, see <xref target="security" format="default"/>)
using a variety of means that are outside the scope of this document.
If there is no nonce that can be
used for the explicit subscription state at the time the explicit
subscription is configured (e.g., from a different subscription
already established with the same xTR when a single nonce is kept per
xTR-ID), then both the xTR and Map-Server <bcp14>MUST</bcp14> be configured wi
th the initial nonce.
<bcp14>RECOMMENDED</bcp14> to have a configuration option to enable (or
disable) the xTR to accept publication information for EID-Prefixes that
the xTR did not explicitly subscribe to. By default, the xTR is allowed
to modify explicitly configured subscription state following the
procedures described in this section; however, this <bcp14>MAY</bcp14> be
disabled at the Map-Server via configuration. If the Map-Server is
instructed to not allow xTRs to modify explicitly configured
subscriptions, and an xTR tries to do so, this triggers a Negative
Map-Reply with ACT bits set to 4 "Drop/Policy-Denied" as described
earlier in this section.</t>
<t>The following specifies the procedure to remove a subscription:</t>
<ul spacing="normal">
<li>If a valid Map-Request with the N-bit set to 1 only has one
ITR-RLOC with AFI = 0 (i.e., Unknown Address), the Map-Server
<bcp14>MUST</bcp14> remove the subscription state for that xTR-ID
(unless this is disabled via configuration, see previous
paragraph).</li>
<li>If the subscription state is removed, the Map-Server
<bcp14>MUST</bcp14> send a Map-Notify to the source RLOC of the
Map-Request.</li>
<li><t>If the subscription removal fails due to configuration, this
triggers a Negative Map-Reply with ACT bits set to 4
"Drop/Policy-Denied" as described earlier in this section; the
Map-Server sends the Negative Map-Reply to the source RLOC of the
Map-Request in this case.</t></li>
<li><t>Removing subscription state at the Map-Server can lead to replay
attacks. To soften this, the Map-Server <bcp14>SHOULD</bcp14> keep the
last nonce seen per xTR-ID (and EID-Prefix, when applicable).</t></li>
<li>If the Map-Server does not keep the last nonces seen, then the
Map-Server <bcp14>MUST</bcp14> require the xTRs to subscribe using the
procedure described in <xref target="association" format="default"/>
to create a new security association with the Map-Server.</li></ul>
&RFC2119; <t>
If the Map-Server receives a Map-Request asking to remove a
subscription for an EID-Prefix without subscription state for th
at
xTR-ID and the EID-Prefix is covered by a less-specific EID-Pref
ix for which
subscription state exists for the xTR-ID, the Map-Server <bcp14>
SHOULD</bcp14> stop
publishing updates about this more-specific EID-Prefix to that x
TR
until the xTR subscribes to the more-specific EID-Prefix. The sa
me
considerations regarding authentication, integrity protection, and nonce
checks, which are described in this section and <xref target="security"
format="default"/> for Map-Requests used to update subscription state,
apply for Map-Requests used to remove subscription state.</t>
<t>When an EID-Prefix is removed from the Map-Server (either when
explicitly withdrawn or when its TTL expires), the Map-Server notifies
its subscribers (if any) via a Map-Notify with TTL equal to 0.</t>
</section>
<section anchor="publish" numbered="true" toc="default">
<name>Mapping Notification Publish Procedures</name>
<t>The publish procedure is implemented via Map-Notify messages that the
Map-Server sends to xTRs. The xTRs acknowledge the receipt of
Map-Notifies by sending Map-Notify-Ack messages back to the
Map-Server. The complete mechanism works as follows: </t>
<t> When a mapping stored in a Map-Server is updated (e.g., via a
Map-Register from an ETR), the Map-Server <bcp14>MUST</bcp14> notify the
subscribers of that mapping via sending Map-Notify messages with the
most up to date mapping information. If subscription state in the
Map-Server exists for a less-specific EID-Prefix and a more-specific
EID-Prefix is updated, then the Map-Notify is sent with the
more-specific EID-Prefix mapping to the subscribers of the less-specific
EID-Prefix mapping. The Map-Notify message sent to each of the
subscribers as a result of an update event follows the encoding and
logic defined in <xref target="RFC9301" sectionFormat="of"
section="5.7"/> for Map-Notify, except for the following:</t>
<ol spacing="normal">
<li>The Map-Notify <bcp14>MUST</bcp14> be sent to one of the ITR-RLOCs
associated with the xTR-ID of the subscriber (which one is
implementation specific). </li>
<li>The Map-Server increments the nonce by one every time it sends a
Map-Notify as publication to an xTR-ID for a particular
EID-Prefix. </li>
<li>The Map-Server <bcp14>MUST</bcp14> use its security association
with the xTR to compute the authentication data of the
Map-Notify.</li>
</ol>
&RFC8126; <t>When the xTR receives a Map-Notify with an EID that is not local to th
e xTR, the xTR knows that the Map-Notify is to update an entry on its Map-Cache.
The xTR <bcp14>MUST</bcp14> keep track of the last
nonce seen in a Map-Notify received as a publication from the Map-Server
for the EID-Prefix. When the LISP deployment has a single Map-Server,
the xTR can be configured to keep track of a single nonce for all
EID-Prefixes (when used, this option <bcp14>MUST</bcp14> be enabled at
the Map-Server and all xTRs). If a Map-Notify that is received as a
publication has a nonce value that is not greater than the saved nonce,
the xTR drops the Map-Notify message and logs the fact a replay attack
could have occurred. The same considerations discussed in <xref
target="RFC9301" sectionFormat="of" section="5.6"/> regarding
Map-Register nonces apply here for Map-Notify nonces.</t>
<t>The xTR processes the received Map-Notify as specified in <xref
target="RFC9301" sectionFormat="of" section="5.7"/>, with the following
considerations:</t>
<ul spacing="normal">
<li>The xTR <bcp14>MUST</bcp14> use its security association with the
Map-Server (<xref target="association" format="default"/>) to validate
the authentication data on the Map-Notify.</li>
<li>The xTR <bcp14>MUST</bcp14> use the mapping information carried
in the Map-Notify to update its internal Map-Cache.</li>
<li>If after following <xref target="RFC9301" sectionFormat="of"
section="5.7"/> regarding retransmission of Map-Notify messages, the
Map-Server has not received the Map-Notify-Ack, it can try
sending the Map-Notify to a different ITR-RLOC for that xTR-ID.</li>
<li>If the Map-Server tries all the ITR-RLOCs without receiving a
response, it may stop trying to send the
Map-Notify.</li></ul>
</section>
&RFC8174; <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>Generic security considerations related to LISP control messages are
discussed in <xref target="RFC9301" sectionFormat="of"
section="9"/>. </t>
<t>In the particular case of PubSub, cache poisoning via malicious
Map-Notify messages is avoided by the use of nonce and the security
association between the ITRs and the Map-Servers.</t>
<t>It is <bcp14>RECOMMENDED</bcp14> to follow guidance from the last
paragraph of <xref target="RFC9301" sectionFormat="of" section="9"/> to
ensure integrity protection of Map-Request messages (e.g., to prevent
xTR-ID hijacking).</t>
<section anchor="association" numbered="true" toc="default">
<name>Security Association between ITR and Map-Server</name>
<t>Since Map-Notifies from the Map-Server to the ITR need to be
authenticated, there is a need for a soft-state or hard-state security
association (e.g., a PubSubKey) between the ITRs and the
Map-Servers. For some controlled deployments, it might be possible to
have a shared PubSubKey (or set of keys) between the ITRs and the
Map-Servers. However, if pre-shared keys are not used in the
deployment, LISP Security (LISP-SEC) <xref
target="RFC9303" format="default"/> can be used as follows to create a
security association between the ITR and the Map-Server.</t>
<t>First, when the ITR is sending a Map-Request with the N-bit set
as described in <xref target="sub" format="default"/>, the ITR also perf
orms
the steps described in <xref target="RFC9303" sectionFormat="of"
section="6.4"/>. The ITR can then generate a PubSubKey by deriving a
key from the One-Time Key (OTK) and Map-Request's nonce as follows:
PubSubKey = KDF(OTK + nonce), where KDF is the Key Derivation Function
indicated by the OTK Wrapping ID. If the OTK Wrapping ID equals
NULL-KEY-WRAP-128, then the PubSubKey is the OTK. Note that, as opposed
to the pre-shared PubSubKey, this generated PubSubKey is different per
EID-Prefix to which an ITR subscribes (since the ITR will use a
different OTK per Map-Request).</t>
<t>When the Map-Server receives the Map-Request, it follows the
procedure specified in <xref target="sub" format="default"/> with the
following considerations: the Map-Server <bcp14>MUST</bcp14> verify
that the OTK has not been used before. If the Map-Server verifies the
OTK and cannot determine that the OTK has not been used before, the
subscription request fails due to authentication, which triggers a
Negative Map-Reply with ACT bits set to 5 "Drop/Auth-Failure", as
described in <xref target="sub" format="default"/>. The xTR might try
again with a different OTK upon receipt of this Negative
Map-Reply. Note that a Map-Server implementation may decide not to keep
track
of all past OTKs and instead use some form of hash. In that case,
hash collisions are handled as if the OTK has been reused. Such an
implementation needs to balance the hash length with the rate of
collisions expected for the particular deployment; this is
implementation specific. If the Map-Server has to reply with a
Map-Reply for any other reason (e.g., if PubSub is not supported or a
subscription is not accepted), then it follows the normal LISP-SEC
procedure described in <xref target="RFC9303" sectionFormat="of"
section="5.7"/>. No PubSubKey, security association, or subscription
state is created when the Map-Server responds with any Map-Reply
message.</t>
<t>Otherwise, if the Map-Server has to reply with a Map-Notify (e.g.,
due to the subscription being accepted) to a received Map-Request, the
following extra steps take place:
</t>
<ul spacing="normal">
<li>The Map-Server extracts the OTK and the OTK Wrapping ID from the
LISP-SEC Encapsulated Control Message (ECM) Authentication Data.</li>
<li>The Map-Server generates a PubSubKey by deriving a key from the
OTK, as described before for the ITR. This is the same PubSubKey
derived at the ITR that is used to establish a security association
between the ITR and the Map-Server.</li>
<li>The PubSubKey can now be used to sign and authenticate any
Map-Notify between the Map-Server and the ITR for the subscribed
EID-Prefix. This includes the Map-Notify sent as a confirmation to
the subscription. When the ITR wants to update the security
association for that Map-Server and EID-Prefix, it once again
follows the procedure described in this section.</li>
</ul>
<t>Note that if the Map-Server replies with a Map-Notify, none of the
regular LISP-SEC steps regarding Map-Reply described in <xref
target="RFC9303" sectionFormat="of" section="5.7"/> occur.</t>
</section>
<section anchor="ddos" numbered="true" toc="default">
<name>DDoS Attack Mitigation</name>
<t>If PubSub is deployed under the scope of applicability defined in
<xref target="app-scope" format="default"/>, only known nodes can
participate on the PubSub deployment. DDoS attacks based on replayed
messages by unknown nodes are avoided by the use of nonce and the
security association between the ITRs and the Map-Servers. Misbehaving
known nodes may send massive subscription requests, which may lead to
exhausting the resources of a Map-Server. Furthermore, frequently
changing the state of a subscription may also be considered as an
attack vector. To mitigate such issues, <xref target="RFC9301"
sectionFormat="of" section="5.3"/> discusses rate-limiting
Map-Requests, and <xref target="RFC9301" sectionFormat="of"
section="5.7"/> discusses rate-limiting Map-Notifies. Note that when
the Map-Notify rate-limit threshold is met for a particular xTR-ID,
the Map-Server will discard additional subscription requests from that
xTR-ID and will fall back to the behavior described in <xref
target="RFC9301" format="default"/> when receiving a Map-Request from
that xTR-ID (i.e., the Map-Server will send a Map-Reply).</t>
</section>
</section>
&RFC9300; <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has assigned the following new bit from the
"LISP Control Plane Header Bits: Map-Request" registry within the
"Locator/ID Separation Protocol (LISP) Parameters" group of registries <xr
ef target="IANA-LISP" format="default"/>:</t>
<table align="center">
<name>Addition to the Map-Request Header Bits Registry</name>
<thead>
<tr>
<th align="left">Spec Name</th>
<th align="left">IANA Name</th>
<th align="left">Bit Position</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">I</td>
<td align="left">Map-Request-I</td>
<td align="left">11</td>
<td align="left">xTR-ID Bit</td>
<td align="left">RFC 9437</td>
</tr>
</tbody>
</table>
<t>IANA has also created a new registry
entitled "LISP Control Plane Header Bits: Map-Request-Record" within the
"Locator/ID Separation Protocol (LISP) Parameters" group of registries <xr
ef target="IANA-LISP" format="default"/>.</t>
<t>The initial content of this registry is shown in <xref
target="bits-table" format="default"/>.</t>
<table anchor="bits-table" align="center">
<name>Initial Content of LISP Control Plane Header Bits:
Map-Request-Record Registry</name>
<thead>
<tr>
<th align="left">Spec Name</th>
<th align="left">IANA Name</th>
<th align="left">Bit Position</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">N</td>
<td align="left">Map-Request-N</td>
<td align="left">1</td>
<td align="left">Notification-Requested Bit</td>
<td align="left">RFC 9437</td>
</tr>
</tbody>
</table>
<t>The remaining bits (i.e., bit positions 2-8) are Unassigned.</t>
<t>The policy for allocating new bits in this registry is
"Specification Required" (<xref target="RFC8126" sectionFormat="of"
section="4.6"/>). </t>
&RFC9301; <t>Allocation requests are evaluated on the advice of one or more designated
experts.
Designated experts should consider whether the proposed registration duplicat
es
existing entries and whether the registration description is
sufficiently detailed and fits the purpose of this registry. These
criteria are to be considered in addition to those provided in
<xref target="RFC8126" sectionFormat="of" section="4.6"/> (e.g., the proposed
registration "must be
documented in a permanent and readily available public
specification"). The designated experts will either approve or
deny the registration request, and communicate their decision to
IANA. Denials should include an explanation and, if applicable,
suggestions as to how to make the request successful. </t>
</section>
&RFC9303; </middle>
<back>
</references> <displayreference target="I-D.ietf-lisp-eid-mobility" to="EID-MOBILITY"/>
<displayreference target="I-D.haindl-lisp-gb-atn" to="GB-ATN"/>
<displayreference target="I-D.moreno-lisp-uberlay" to="UBERLAY"/>
<displayreference target="I-D.boucadair-lisp-pubsub-flow-examples" to="FLOW-EXAM
PLES"/>
<displayreference target="I-D.ietf-lisp-yang" to="LISP-YANG"/>
<references title="Informative References"> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
300.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
303.xml"/>
</references>
<references>
<name>Informative References</name>
<reference anchor="IANA-LISP" target="https://www.iana.org/assignments <reference anchor="IANA-LISP" target="https://www.iana.org/assignments/l
/lisp-parameters/lisp-parameters.xhtml"> isp-parameters/">
<front> <front>
<title>Locator/ID Separation Protocol (LISP) Parameters</title> <title>Locator/ID Separation Protocol (LISP) Parameters</title>
<author fullname="IANA"> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
&RFC6835;
&I-D.ietf-lisp-eid-mobility;
&I-D.haindl-lisp-gb-atn;
&I-D.moreno-lisp-uberlay;
&I-D.boucadair-lisp-pubsub-flow-examples;
&I-D.ietf-lisp-yang;
</references>
<section anchor="deployment" title="Sample PubSub Deployment Experiences
">
<t>Some LISP production networks have been running different forms o
f PubSub for some time. The following subsections provide an inventory of some e
xperience lessons from these deployments.</t>
<section anchor="deploy-monitoring" title="PubSub as a Monitoring To
ol">
<t>Some LISP deployments are using PubSub as a way to monitor EI
D-Prefixes (particularly, EID-to-RLOC mappings). To that aim, some LISP implemen
tations have extended the LISP Internet Groper (lig) <xref target="RFC6835"></x
ref> tool to use PubSub. Such an extension is meant to support an interactive mo
de with lig, and request subscription for the EID of interest. If there are RLOC
changes, the Map-Server sends a notification and then the lig client displays t
hat change to the user. </t>
</section>
<section anchor="deploy-nmr" title="Mitigating Negative Map-Cache En
tries">
<t>Section 8.1 of <xref target="RFC9301"></xref> suggests two TT
L values for Negative Map-Replies: either 15-minute (if the EID-Prefix does not
exist) or 1-minute (if the prefix exists but has not been registered). While the
se values are based on the original operational experience of the LISP protocol
designers, negative cache entries have two unintended effects that were observed
in production.</t>
<t>First, if the xTR keeps receiving traffic for a negative EID
destination (i.e., an EID-Prefix with no RLOCs associated with it), it will try
to resolve the destination again once the cached state expires, even if the stat
e has not changed in the Map-Server. It was observed in production that this is
happening often in networks that have a significant amount of traffic addressed
for outside of the LISP network. This might result on excessive resolution signa
ling to keep retrieving the same state due to the cache expiring. PubSub is used
to relax TTL values and cache negative mapping entries for longer periods of ti
me, avoiding unnecessary refreshes of these forwarding entries, and drastically
reducing signaling in these scenarios. In general, a TTL-based schema is a “poll
ing mechanism” that leads to more signaling where PubSub provides an "event trig
gered mechanism" at the cost of state.</t>
<t>Second, if the state does indeed change in the Map-Server, up
dates based on TTL timeouts might prevent the cached state at the xTR from being
updated until the TTL expires. This behavior was observed during configuration
(or reconfiguration) periods on the network, where no-longer-negative EID-Prefix
es do not receive the traffic yet due to stale Map-Cache entries present in the
network. With the activation of PubSub, stale caches can be updated as soon as t
he state changes.</t>
</section>
<section anchor="deploy-mobility" title="Improved Mobility Latency "
>
<t>An improved convergence time was observed on the presence of
mobility events on LISP networks running PubSub as compared with running LISP <x
ref target="RFC9301"></xref>. As described in Section 4.1.2.1 of <xref target="I
-D.ietf-lisp-eid-mobility"></xref>, LISP can rely on data-driven Solicit-Map-Req
uests (SMRs) to ensure eventual network converge. Generally, PubSub offers faste
r convergence due to (1) no need to wait for a data triggered event and (2) less
signaling as compared with the SMR-based flow. Note that when a Map-Server runn
ing PubSub has to update a large number of subscribers at once (i.e., when a pop
ular mapping is updated) SMR based convergence may be faster for a small subset
of the subscribers (those receiving PubSub updates last). Deployment experience
reveals that data-driven SMRs and PubSub mechanisms complement each other and pr
ovide a fast and resilient network infrastructure in the presence of mobility ev
ents.</t>
<t>Furthermore, experience showed that not all LISP entities on
the network need to implement PubSub for the network to get the benefits. In sce
narios with significant traffic coming from outside of the LISP network, the exp
erience showed that enabling PubSub in the border routers significantly improves
mobility latency overall. Even if edge xTRs do not implement PubSub, and traffi
c is exchanged between EID-Prefixes at the edge, xTRs still converge based on da
ta-driven events and SMR-triggered updates.</t>
</section>
<section anchor="deploy-redistribution" title="Enhanced Reachability
with Dynamic Redistribution of Prefixes">
<t>There is a need to interconnect LISP networks with other netw
orks that might or might not run LISP. Some of those scenarios are similar to th
e ones described in <xref target="I-D.haindl-lisp-gb-atn"></xref> and <xref targ
et="I-D.moreno-lisp-uberlay"></xref>. When connecting LISP to other networks, th
e experience revealed that in many deployments the point of interaction with the
other domains is not the Mapping System but rather the border router of the LIS
P site. For those cases the border router needs to be aware of the LISP prefixes
to redistribute them to the other networks. Over the years different solutions
have been used.</t>
<t>First, Map-Servers were collocated with the border routers, b
ut this was hard to scale since border routers scale at a different pace than Ma
p-Servers. Second, decoupled Map-Servers and border routers were used with stati
c configuration of LISP entries on the border, which was problematic when modifi
cations were made. Third, a routing protocol (e.g., BGP) can be used to redistri
buted LISP prefixes from the Map-Servers to a border router, but this comes with
some implications, particularly the Map-Servers needs to implement an additiona
l protocol which consumes resources and needs to be properly configured. Therefo
re, once PubSub was available, deployments started to adapt it to enable border
routers to dynamically learn the prefixes they need to redistribute without the
need of extra protocols or extra configuration on the network. </t>
<t>In other words, PubSub can be used to discover EID-Prefixes s
o they can be imported into other routing domains that do not use LISP. Similarl
y, PubSub can also be used to discover when EID-Prefixes need to be withdrawn fr
om other routing domains. That is, in a typical deployment, a border router will
withdraw an EID-Prefix it has been announcing to external routing domains, if i
t receives a notification that the RLOC-set for that EID-Prefix is now empty.</t
>
</section>
<section anchor="deploy-service" title="Better Serviceability"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 835.xml"/>
<t>EID-to-RLOC mappings can have very long TTL, sometimes in the order of several hours. Upon the expiry of that TTL, the xTR checks if these en tries are being used and removes any entry that is not being used. The problem w ith very long Map-Cache TTL is that (in the absence of PubSub) if a mapping chan ges, but it is not being used, the cache remains but it is stale. This is due to no data traffic being sent to the old location to trigger an SMR based Map-Cach e update as described in Section 4.1.2.1 of <xref target="I-D.ietf-lisp-eid-mobi lity"></xref>. If the network operator runs a show command on a router to track the state of the Map-Cache, the router will display multiple entries waiting to expire but with stale RLOC information. This might be confusing for operators so metimes, particularly when they are debugging problems. With PubSub, the Map-Cac he is updated with the correct RLOC information, even when it is not being used or waiting to expire, and this helps with debugging.</t> <!-- [I-D.ietf-lisp-eid-mobility] IESG state I-D Exists. Updated to long version because Portoles's name is showing as Portoles-Comeras in short version, but dr aft shows only one last name. -->
</section> <reference anchor="I-D.ietf-lisp-eid-mobility" target="https://datatracker.ietf.
org/doc/html/draft-ietf-lisp-eid-mobility-11">
<front>
<title>
LISP L2/L3 EID Mobility Using a Unified Control Plane
</title>
<author initials="M." surname="Portoles" fullname="Marc Portoles">
<organization>Cisco Systems</organization>
</author>
<author initials="V." surname="Ashtaputre" fullname="Vrushali Ashtaputre">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Maino" fullname="Fabio Maino">
<organization>Cisco Systems</organization>
</author>
<author initials="V." surname="Moreno" fullname="Victor Moreno">
<organization>Google LLC</organization>
</author>
<author initials="D." surname="Farinacci" fullname="Dino Farinacci">
<organization>lispers.net</organization>
</author>
<date month="January" day="10" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lisp-eid-mobility-11"/>
</reference>
</section> <!-- [I-D.haindl-lisp-gb-atn] IESG state I-D Exists. Updated to long version be
<section numbered="false" anchor="Acknowledgments" title="Acknowledgment cause Portoles's name is
s" toc="default"> showing as Portoles-Comeras in short version, but draft shows only one last name
<t> We would like to thank Marc Portoles, Balaji Venkatachalapathy, Be . -->
rnhard Haindl, Luigi Iannone, and Padma Pillay-Esnault for their great suggestio
ns and help regarding this document. </t>
<t> Many thanks to Alvaro Retana for the careful AD review.</t> <reference anchor="I-D.haindl-lisp-gb-atn" target="https://datatracker.ietf.org/
doc/html/draft-haindl-lisp-gb-atn-09">
<front>
<title>
Ground-Based LISP for the Aeronautical Telecommunications Network
</title>
<author initials="B." surname="Haindl" fullname="Bernhard Haindl">
<organization>Frequentis</organization>
</author>
<author initials="M." surname="Lindner" fullname="Manfred Lindner">
<organization>Frequentis</organization>
</author>
<author initials="V." surname="Moreno" fullname="Victor Moreno">
<organization>Google</organization>
</author>
<author initials="M." surname="Portoles" fullname="Marc Portoles">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Maino" fullname="Fabio Maino">
<organization>Cisco Systems</organization>
</author>
<author initials="B." surname="Venkatachalapathy" fullname="Balaji Venkatachalap
athy">
<organization>Cisco Systems</organization>
</author>
<date month="March" day="27" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-haindl-lisp-gb-atn-09"/>
</reference>
<t>Thanks to Chris M. Lonvick for the security directorate review, Al Morton for the OPS-DIR review, Roni Even for the Gen-ART review, Mike McBride fo r the rtg-dir review, Magnus Westerlund for the tsv directorate review, and Shen g Jiang for the int-dir review.</t> <!-- [I-D.moreno-lisp-uberlay] IESG state Expired -->
<t> Thanks to John Scudder, Erik Kline, Lars Eggert, Warren Kumari, Ma rtin Duke, Murray Kucherawy, Éric Vyncke, Robert Wilton, Zaheduzzaman Sarker, an d Roman Danyliw for the IESG review.</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .moreno-lisp-uberlay.xml"/>
<t> This work was partly funded by the ANR LISP-Lab project #ANR-13-IN FR-009 (https://anr.fr/Projet-ANR-13-INFR-0009).</t> <!-- [I-D.boucadair-lisp-pubsub-flow-examples] IESG state I-D Exists -->
</section> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
<section numbered="false" title="Contributors" toc="default"> .boucadair-lisp-pubsub-flow-examples.xml"/>
<t><figure> <!-- [I-D.ietf-lisp-yang] IESG state I-D Exists. Updated to long version
<artwork><![CDATA[ because Albert Cabellos prefers that his last name be listed in future
RFCs as "Cabellos" - not "Cabellos-Aparicio". -->
Dino Farinacci <reference anchor="I-D.ietf-lisp-yang" target="https://datatracker.ietf.org/doc/
lispers.net html/draft-ietf-lisp-yang-19">
San Jose, CA <front>
USA <title>LISP YANG Model</title>
<author initials="V." surname="Ermagan" fullname="Vina Ermagan">
<organization>Google</organization>
</author>
<author initials="A." surname="Rodriguez-Natal" fullname="Alberto Rodriguez-Nata
l">
<organization>Cisco Systems</organization>
</author>
<author initials="F." surname="Coras" fullname="Florin Coras">
<organization>Cisco Systems</organization>
</author>
<author initials="C." surname="Moberg" fullname="Carl Moberg">
<organization>Avassa</organization>
</author>
<author initials="R." surname="Rahman" fullname="Reshad Rahman"> </author>
<author initials="A." surname="Cabellos" fullname="Albert Cabellos">
<organization>Technical University of Catalonia</organization>
</author>
<author initials="F." surname="Maino" fullname="Fabio Maino">
<organization>Cisco Systems</organization>
</author>
<date month="March" day="2" year="2023"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-lisp-yang-19"/>
</reference>
Email: farinacci@gmail.com </references>
</references>
Johnson Leong <section anchor="deployment" numbered="true" toc="default">
<name>Sample PubSub Deployment Experiences</name>
<t>Some LISP production networks have been running different forms of PubS
ub for some time. The following subsections provide an inventory of some experie
nce lessons from these deployments.</t>
<section anchor="deploy-monitoring" numbered="true" toc="default">
<name>PubSub as a Monitoring Tool</name>
<t>Some LISP deployments are using PubSub as a way to monitor
EID-Prefixes (particularly, EID-to-RLOC mappings). To that aim, some
LISP implementations have extended the LISP Internet Groper ('lig')
<xref target="RFC6835" format="default"/> tool to use PubSub. Such an
extension is meant to support an interactive mode with 'lig' and to
request subscription for the EID of interest. If there are RLOC
changes, the Map-Server sends a notification, and then the 'lig' client
displays that change to the user. </t>
</section>
<section anchor="deploy-nmr" numbered="true" toc="default">
<name>Mitigating Negative Map-Cache Entries</name>
<t><xref target="RFC9301" sectionFormat="of" section="8.1"/> suggests
two TTL values for Negative Map-Replies: either a 15-minute TTL (if
the EID-Prefix does not exist) or a 1-minute TTL (if the prefix exists
but has not been registered). While these values are based on the
original operational experience of the LISP protocol designers,
negative cache entries have two unintended effects that were observed
in production.</t>
<t>First, if the xTR keeps receiving traffic for a negative EID
destination (i.e., an EID-Prefix with no RLOCs associated with it), it
will try to resolve the destination again once the cached state
expires, even if the state has not changed in the Map-Server. It was
observed in production that this is happening often in networks that
have a significant amount of traffic addressed for outside of the LISP
network. This might result in excessive resolution signaling to keep
retrieving the same state due to the cache expiring. PubSub is used to
relax TTL values and cache negative mapping entries for longer periods
of time, avoiding unnecessary refreshes of these forwarding entries
and drastically reducing signaling in these scenarios. In general, a
TTL-based schema is a "polling mechanism" that leads to more signaling
where PubSub provides an "event-triggered mechanism" at the cost of
state.</t>
<t>Second, if the state does indeed change in the Map-Server, updates
based on TTL timeouts might prevent the cached state at the xTR from
being updated until the TTL expires. This behavior was observed during
configuration (or reconfiguration) periods on the network, where
EID-Prefixes that are no longer negative do not receive the traffic
yet, due to stale Map-Cache entries present in the network. With the
activation of PubSub, stale caches can be updated as soon as the state
changes.</t>
</section>
<section anchor="deploy-mobility" numbered="true" toc="default">
<name>Improved Mobility Latency</name>
Email: johnsonleong@gmail.com <t>An improved convergence time was observed on the presence of
mobility events on LISP networks running PubSub as compared with
running LISP <xref target="RFC9301" format="default"/>. As described
in Section 4.1.2.1 of <xref target="I-D.ietf-lisp-eid-mobility"
format="default"/>, LISP can rely on data-driven Solicit-Map-Requests
(SMRs) to ensure eventual network convergence. Generally, PubSub offers
faster convergence due to (1) no need to wait for a data-triggered
event and (2) less signaling as compared with the SMR-based flow. Note
that when a Map-Server running PubSub has to update a large number of
subscribers at once (i.e., when a popular mapping is updated),
SMR-based convergence may be faster for a small subset of the
subscribers (those receiving PubSub updates last). Deployment
experience reveals that data-driven SMRs and PubSub mechanisms
complement each other and provide a fast and resilient network
infrastructure in the presence of mobility events.</t>
<t>Furthermore, experience showed that not all LISP entities on the
network need to implement PubSub for the network to get the
benefits. In scenarios with significant traffic coming from outside of
the LISP network, the experience showed that enabling PubSub in the
border routers significantly improves mobility latency overall. Even
if edge xTRs do not implement PubSub, and traffic is exchanged between
EID-Prefixes at the edge, xTRs still converge based on data-driven
events and SMR-triggered updates.</t>
</section>
<section anchor="deploy-redistribution" numbered="true" toc="default">
<name>Enhanced Reachability with Dynamic Redistribution of
Prefixes</name>
<t>There is a need to interconnect LISP networks with other networks
that might or might not run LISP. Some of those scenarios are similar
to the ones described in <xref target="I-D.haindl-lisp-gb-atn"
format="default"/> and <xref target="I-D.moreno-lisp-uberlay"
format="default"/>. When connecting LISP to other networks, the
experience revealed that in many deployments the point of interaction
with the other domains is not the Mapping System but rather the border
router of the LISP site. For those cases, the border router needs to be
aware of the LISP prefixes to redistribute them to the other
networks. Over the years, different solutions have been used.</t>
<t>First, Map-Servers were collocated with the border routers, but
this was hard to scale since border routers scale at a different pace
than Map-Servers. Second, decoupled Map-Servers and border routers
were used with static configuration of LISP entries on the border,
which was problematic when modifications were made. Third, a routing
protocol (e.g., BGP) can be used to redistribute LISP prefixes from
the Map-Servers to a border router, but this comes with some
implications; in particular, the Map-Servers need to implement an
additional protocol, which consumes resources and needs to be properly
configured. Therefore, once PubSub was available, deployments started
to adapt it to enable border routers to dynamically learn the prefixes
they need to redistribute without a need for extra protocols or extra
configuration on the network.</t>
<t>In other words, PubSub can be used to discover EID-Prefixes so they
can be imported into other routing domains that do not use
LISP. Similarly, PubSub can also be used to discover when EID-Prefixes
need to be withdrawn from other routing domains. That is, in a typical
deployment, a border router will withdraw an EID-Prefix that it has
been announcing to external routing domains if it receives a
notification that the RLOC-set for that EID-Prefix is now empty.</t>
</section>
<section anchor="deploy-service" numbered="true" toc="default">
<name>Better Serviceability</name>
<t>EID-to-RLOC mappings can have a very long TTL, sometimes on the order
of several hours. Upon the expiry of that TTL, the xTR checks if these
entries are being used and removes any entry that is not being
used. The problem with a very long Map-Cache TTL is that (in the
absence of PubSub) if a mapping changes but is not being used,
the cache remains but is stale. This is due to no data traffic being sent to
the old location to trigger an SMR-based Map-Cache update as described
in Section 4.1.2.1 of <xref target="I-D.ietf-lisp-eid-mobility"
format="default"/>. If the network operator runs a show command on a
router to track the state of the Map-Cache, the router will display
multiple entries waiting to expire but with stale RLOC
information. This might be confusing for operators sometimes,
particularly when they are debugging problems. With PubSub, the
Map-Cache is updated with the correct RLOC information, even when it
is not being used or waiting to expire, which helps with
debugging.</t>
</section>
</section>
<section numbered="false" anchor="Acknowledgments" toc="default">
<name>Acknowledgments</name>
<t> We would like to thank <contact fullname="Marc Portoles"/>, <contact
fullname="Balaji Venkatachalapathy"/>, <contact fullname="Bernhard
Haindl"/>, <contact fullname="Luigi Iannone"/>, and <contact
fullname="Padma Pillay-Esnault"/> for their great suggestions and help
regarding this document. </t>
<t> Many thanks to <contact fullname="Alvaro Retana"/> for the careful
AD review.</t>
<t>Thanks to <contact fullname="Chris M. Lonvick"/> for the security
directorate review, <contact fullname="Al Morton"/> for the OPS-DIR
review, <contact fullname="Roni Even"/> for the Gen-ART review, <contact
fullname="Mike McBride"/> for the rtg-dir review, <contact
fullname="Magnus Westerlund"/> for the tsv directorate review, and
<contact fullname="Sheng Jiang"/> for the int-dir review.</t>
<t> Thanks to <contact fullname="John Scudder"/>, <contact
fullname="Erik Kline"/>, <contact fullname="Lars Eggert"/>, <contact
fullname="Warren Kumari"/>, <contact fullname="Martin Duke"/>, <contact
fullname="Murray Kucherawy"/>, <contact fullname="Éric Vyncke"/>,
<contact fullname="Robert Wilton"/>, <contact fullname="Zaheduzzaman
Sarker"/>, and <contact fullname="Roman Danyliw"/> for the IESG
review.</t>
<t> This work was partly funded by the ANR LISP-Lab project
#ANR-13-INFR-009 <eref target="https://anr.fr/Projet-ANR-13-INFR-0009"
brackets="angle"/>.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
Fabio Maino <contact fullname="Dino Farinacci">
Cisco <organization>lispers.net</organization>
San Jose, CA <address>
USA <postal>
<city>San Jose</city>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>farinacci@gmail.com</email>
</address>
</contact>
Email: fmaino@cisco.com <contact fullname="Johnson Leong">
<address>
<email>johnsonleong@gmail.com</email>
</address>
</contact>
Christian Jacquenet <contact fullname="Fabio Maino">
Orange <organization>Cisco</organization>
Rennes <address>
France <postal>
<city>San Jose</city>
<region>CA</region>
<country>United States of America</country>
</postal>
<email>fmaino@cisco.com</email>
</address>
</contact>
Email: christian.jacquenet@orange.com <contact fullname="Christian Jacquenet">
<organization>Orange</organization>
<address>
<postal>
<city>Rennes</city>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</contact>
Stefano Secci <contact fullname="Stefano Secci">
Cnam <organization>Cnam</organization>
France <address>
<postal>
<country>France</country>
</postal>
<email>stefano.secci@cnam.fr</email>
</address>
</contact>
Email: stefano.secci@cnam.fr </section>
]]></artwork> </back> </rfc>
</figure></t>
</section>
</back>
</rfc>
 End of changes. 68 change blocks. 
831 lines changed or deleted 968 lines changed or added

This html diff was produced by rfcdiff 1.48.