Publish/Subscribe Functionality for the Locator/ID Separation Protocol (LISP)CiscoBarcelonaSpainnatal@cisco.comGoogleUnited States of Americaermagan@gmail.comUPC/BarcelonaTechBarcelonaSpainacabello@ac.upc.eduNexarsharon.barkai@getnexar.comOrangeRennesFrancemohamed.boucadair@orange.com
rtg
lisplisppublishsubscribesubscriptionsdnnfvThis document specifies an extension to the Locator/ID Separation
Protocol (LISP) control plane to enable
Publish/Subscribe (PubSub) operation.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Scope of Applicability
. Terminology and Requirements Notation
. Deployment Requirements
. Map-Request PubSub Additions
. Mapping Request Subscribe Procedures
. Mapping Notification Publish Procedures
. Security Considerations
. Security Association between ITR and Map-Server
. DDoS Attack Mitigation
. IANA Considerations
. References
. Normative References
. Informative References
. Sample PubSub Deployment Experiences
. PubSub as a Monitoring Tool
. Mitigating Negative Map-Cache Entries
. Improved Mobility Latency
. Enhanced Reachability with Dynamic Redistribution of
Prefixes
. Better Serviceability
Acknowledgments
Contributors
Authors' Addresses
IntroductionThe Locator/ID Separation Protocol (LISP) 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.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.
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.In general, when an ITR/RTR/PITR wants to be notified for mapping
changes for a given EID-Prefix, the following main steps occur:
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.
The Map-Request is forwarded to one of the Map-Servers that the
EID-Prefix is registered to.
The Map-Server creates subscription state for the ITR/RTR/PITR on
the EID-Prefix.
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.
The ITR/RTR/PITR sends back a Map-Notify-Ack to acknowledge the
successful receipt of the Map-Notify.
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.
Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the
received Map-Notify.
This operation is repeated for all EID-Prefixes for which ITRs/RTRs/PITRs want to be notified. An ITR/RTR/PITR can set the N-bit for several EID-Prefixes 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 described later in the document.The reader may refer to for sample flows to illustrate the use of the PubSub specification.Scope of ApplicabilityThe PubSub procedure specified in this document is intended for use in contexts with controlled access to the Map-Server. How a deployment controls access to a Map-Server is deployment specific and therefore out of the scope of this document. However, the Map-Resolvers and Map-Servers need to be configured with the required information to ensure at least the following:
Map-Resolvers MUST verify that an xTR is allowed
to (1) set the N-bit to 1 and (2) use the xTR-ID, Site-ID, and
ITR-RLOCs included in a Map-Request.
Map-Servers MUST only accept subscription
requests from Map-Resolvers that verify Map-Requests as previously
described.
Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
The document uses the terms defined in . Deployment RequirementsIn addition to the general assumptions and expectations that makes for LISP deployments, this document imposes the following deployment requirements:
A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
assigned to each xTR.
Map-Servers are configured to proxy Map-Replying (i.e., they are
solicited to generate and send Map-Reply messages) for the mappings
they are serving.
A security association (e.g., a PubSubKey) is required between the
ITRs and the Map-Servers (see ).
If a requirement is not met, a subscription cannot be established, and 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 refer to for an example of how these identifiers can be provisioned to LISP nodes.Map-Request PubSub Additions shows the format of the updated Map-Request to support the PubSub functionality. In particular, this document associates a meaning with one of the reserved bits (see ). Map-Request with I-bit, N-bit, xTR-ID, and Site-ID
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |N| Reserved | EID mask-len | EID-Prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-Prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ xTR-ID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Site-ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following is added to the Map-Request message defined in :
xTR-ID bit (I-bit):
This bit is set to 1 to indicate that 128-bit xTR-ID and 64-bit
Site-ID fields are present in the Map-Request message. For PubSub
operation, an xTR MUST be configured with an xTR-ID and
Site-ID, and it MUST set the I-bit to 1 and include its
xTR-ID and Site-ID in the Map-Request messages it generates. If the
I-bit is set but the Site-ID and/or xTR-ID are not included, a
receiver can detect the error because, after processing that last
EID-Record, there are no bytes left from processing the message. In
this case, the receiver SHOULD log a malformed
Map-Request and MUST drop the message.
Notification-Requested bit (N-bit):
The N-bit of an EID-Record is set to 1 to specify that the xTR
wants to be notified of updates for that EID-Prefix.
xTR-ID field:
If the I-bit is set, this field is added to the Map-Request
message as shown in ,
starting right after the final Record in the message (or the Map-Reply
Record, if present). The xTR-ID is specified in .
Site-ID field:
If the I-bit is set, this field is added to the Map-Request
message as shown in ,
following the xTR-ID field. The Site-ID is defined in .
Mapping Request Subscribe Procedures The xTR subscribes for changes to a given EID-Prefix by sending a
Map-Request to the Mapping System with the N-bit set on the
EID-Record. The xTR builds a Map-Request according to and also does the
following:
The xTR MUST set the I-bit to 1 and append its
xTR-ID and Site-ID to the Map-Request.
The xTR MUST set the N-bit to 1 for the EID-Record
to which the xTR wants to subscribe.
If the xTR has a nonce associated with the EID-Prefix, it
MUST use this nonce increased by one in the
Map-Request. Otherwise, it generates a nonce as described in . It is
RECOMMENDED that the xTR use persistent storage to
keep nonce state. If the xTR does not have persistent storage and does
not have a nonce associated with the EID-Prefix, it
MUST reset the nonce by using the procedure described
in to successfully
create a new security association with the Map-Server.
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 to handle the subscription state for a given xTR. The Map-Server that receives the Map-Request will be the Map-Server responsible for notifying that specific xTR about future mapping changes for the subscribed mapping records.Upon receipt of the Map-Request, the Map-Server processes it as
described in . In addition, unless the xTR is using the procedure
described in to create a
new security association, the Map-Server MUST verify that
the nonce in the Map-Request is greater than the stored nonce (if any)
associated with the xTR-ID (and EID-Prefix, when applicable). Otherwise,
the Map-Server MUST silently drop the Map-Request message
and SHOULD log the event to record that a replay attack
could have occurred. Furthermore, upon processing, for the EID-Record
that has the N-bit set to 1, the Map-Server proceeds to add the xTR-ID
contained in the Map-Request to the list of xTRs that have requested to
be subscribed to that EID-Prefix. If an xTR-ID is successfully added to the list of subscribers for an
EID-Prefix, the Map-Server MUST extract the nonce and
ITR-RLOCs present in the Map-Request and store the association between
the EID-Prefix, xTR-ID, ITR-RLOCs, and nonce. Any state that is already
present regarding ITR-RLOCs and/or nonce for the same xTR-ID
MUST be overwritten. When the LISP deployment has a
single Map-Server, the Map-Server can be configured to keep a single
nonce per xTR-ID for all EID-Prefixes (when used, this option
MUST be enabled at the Map-Server and all xTRs).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 Map-Server builds the
Map-Notify according to Sections and of with
the following considerations:
The Map-Server MUST use the nonce from the
Map-Request as the nonce for the Map-Notify.
The Map-Server MUST use its security association
with the xTR () to sign
the authentication data of the Map-Notify. The xTR MUST
use the security association to verify the received authentication
data.
The Map-Server MUST send the Map-Notify to one of
the ITR-RLOCs received in the Map-Request (which one is
implementation specific).
As a reminder, the initial transmission and retransmission of
Map-Notify messages by a Map-Server follow the procedure specified in
. 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 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.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 and
MUST use the Map-Notify to populate its Map-Cache with
the returned EID-Prefix and RLOC-set. As a reminder, following , 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 , the Map-Server can remove the subscription state. If
the Map-Server removes the subscription 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 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.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 successful in
establishing a new security association ().If the subscription request fails, the Map-Server sends a Map-Reply
to the originator of the Map-Request, as described in , with the following
considerations:
If the subscription request fails due to policy (e.g., for
explicitly 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 Loc-AFI = 0) with ACT
bits set to 4 "Drop/Policy-Denied".
If the subscription request fails due to authentication (e.g., when
a new security association is being established, as described in
), the Map-Server
MUST 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".
If the subscription request fails due to any other reason, the
Map-Server MUST follow with no changes.
The xTR processes any Map-Reply or Negative Map-Reply as specified in , 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 OPTIONAL for the xTR to
update its Map-Cache entry for the EID-Prefix (if any). If the subscription request fails (for whichever
reason), it is up to the implementation of the xTR to try to subscribe
again.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 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 . In
both cases, the TTL of the temporary subscription state or the Negative
Map-Reply SHOULD be configurable, with a value of
15 minutes being RECOMMENDED. The subscription state can also be created explicitly by
configuration at the Map-Server (possible when a pre-shared security
association exists, see )
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 MUST be configured with the initial nonce.
RECOMMENDED 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 MAY 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.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 that xTR-ID
(unless this is disabled via configuration, see previous
paragraph).
If the subscription state is removed, the Map-Server
MUST send a Map-Notify to the source RLOC of the
Map-Request.
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.
Removing subscription state at the Map-Server can lead to replay
attacks. To soften this, the Map-Server SHOULD keep the
last nonce seen per xTR-ID (and EID-Prefix, when applicable).
If the Map-Server does not keep the last nonces seen, then the
Map-Server MUST require the xTRs to subscribe using the
procedure described in
to create a new security association with the Map-Server.
If the Map-Server receives a Map-Request asking to remove a
subscription for an EID-Prefix without subscription state for that
xTR-ID and the EID-Prefix is 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-Prefix to that xTR
until the xTR subscribes to the more-specific EID-Prefix. The same
considerations regarding authentication, integrity protection, and nonce
checks, which are described in this section and for Map-Requests used to update subscription state,
apply for Map-Requests used to remove subscription state.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.Mapping Notification Publish ProceduresThe 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: 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 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 for Map-Notify, except for the following:
The Map-Notify MUST be sent to one of the ITR-RLOCs
associated with the xTR-ID of the subscriber (which one is
implementation specific).
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.
The Map-Server MUST use its security association
with the xTR to compute the authentication data of the
Map-Notify.
When the xTR receives a Map-Notify with an EID that is not local to the xTR, the xTR knows that the Map-Notify is to update an entry on its Map-Cache.
The xTR MUST 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 MUST 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 regarding
Map-Register nonces apply here for Map-Notify nonces.The xTR processes the received Map-Notify as specified in , with the following
considerations:
The xTR MUST use its security association with the
Map-Server () 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 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.
If the Map-Server tries all the ITR-RLOCs without receiving a
response, it may stop trying to send the
Map-Notify.
Security ConsiderationsGeneric security considerations related to LISP control messages are
discussed in . 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.It is RECOMMENDED to follow guidance from the last
paragraph of to
ensure integrity protection of Map-Request messages (e.g., to prevent
xTR-ID hijacking).Security Association between ITR and Map-ServerSince 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) can be used as follows to create a
security association between the ITR and the Map-Server.First, when the ITR is sending a Map-Request with the N-bit set
as described in , the ITR also performs
the steps described in . 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).When the Map-Server receives the Map-Request, it follows the
procedure specified in with the
following considerations: the Map-Server MUST 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 . 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 . No PubSubKey, security association, or subscription
state is created when the Map-Server responds with any Map-Reply
message.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:
The Map-Server extracts the OTK and the OTK Wrapping ID from the
LISP-SEC Encapsulated Control Message (ECM) Authentication Data.
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.
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.
Note that if the Map-Server replies with a Map-Notify, none of the
regular LISP-SEC steps regarding Map-Reply described in occur.DDoS Attack MitigationIf PubSub is deployed under the scope of applicability defined in
, 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, discusses rate-limiting
Map-Requests, and 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 when receiving a Map-Request from
that xTR-ID (i.e., the Map-Server will send a Map-Reply).IANA ConsiderationsIANA 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 :
Addition to the Map-Request Header Bits Registry
Spec Name
IANA Name
Bit Position
Description
Reference
I
Map-Request-I
11
xTR-ID Bit
RFC 9437
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 .The initial content of this registry is shown in .
Initial Content of LISP Control Plane Header Bits: Map‑Request-Record Registry
Spec Name
IANA Name
Bit Position
Description
Reference
N
Map-Request-N
1
Notification-Requested Bit
RFC 9437
The remaining bits (i.e., bit positions 2-8) are Unassigned.The policy for allocating new bits in this registry is
"Specification Required" (). Allocation requests are evaluated on the advice of one or more designated
experts.
Designated experts should consider whether the proposed registration duplicates
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
(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. ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.The Locator/ID Separation Protocol (LISP)This document describes the data plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces: Endpoint Identifiers (EIDs), which identify end hosts; and Routing Locators (RLOCs), which identify network attachment points. With this, LISP effectively separates control from data and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local Map-Cache.LISP requires no change to either host protocol stacks or underlay routers and offers Traffic Engineering (TE), multihoming, and mobility, among other features.This document obsoletes RFC 6830.Locator/ID Separation Protocol (LISP) Control PlaneThis document describes the control plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provide a simplified "front end" for one or more Endpoint IDs (EIDs) to Routing Locator mapping databases.By using this control plane service interface and communicating with Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and Egress Tunnel Routers (ETRs) are not dependent on the details of mapping database systems; this behavior facilitates modularity with different database designs. Since these devices implement the "edge" of the LISP control plane infrastructure, connecting EID addressable nodes of a LISP site, the implementation and operational complexity of the overall cost and effort of deploying LISP is reduced.This document obsoletes RFCs 6830 and 6833.Locator/ID Separation Protocol Security (LISP-SEC)This memo specifies Locator/ID Separation Protocol Security (LISP-SEC), a set of security mechanisms that provides origin authentication, integrity, and anti-replay protection to the LISP's Endpoint-ID-to-Routing-Locator (EID-to-RLOC) mapping data conveyed via the mapping lookup process. LISP-SEC also enables verification of authorization on EID-Prefix claims in Map-Reply messages.Informative ReferencesLISP L2/L3 EID Mobility Using a Unified Control PlaneCisco SystemsCisco SystemsCisco SystemsGoogle LLClispers.netWork in ProgressLISP PubSub Flow ExamplesOrangeThis document provides a set of flow examples to illustrate the use of LISP PubSub specification. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Locator/ID Separation Protocol Working Group mailing list (lisp@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/lisp/. Source for this draft and an issue tracker can be found at https://github.com/boucadair/lisp-pubsub-flow-examples.Work in ProgressGround-Based LISP for the Aeronautical Telecommunications NetworkFrequentisFrequentisGoogleCisco SystemsCisco SystemsCisco SystemsWork in ProgressLocator/ID Separation Protocol (LISP) ParametersIANALISP YANG ModelGoogleCisco SystemsCisco SystemsAvassaTechnical University of CataloniaCisco SystemsWork in ProgressThe Locator/ID Separation Protocol Internet Groper (LIG)A simple tool called the Locator/ID Separation Protocol (LISP) Internet Groper or 'lig' can be used to query the LISP mapping database. This document describes how it works. This document is not an Internet Standards Track specification; it is published for informational purposes.Uberlay Interconnection of Multiple LISP overlaysGoogle LLClispers.netCisco SystemsCisco SystemsCisco SystemsCisco SystemsThis document describes the use of the Locator/ID Separation Protocol (LISP) to interconnect multiple disparate and independent network overlays by using a transit overlay. The transit overlay is referred to as the "uberlay" and provides connectivity and control plane abstraction between different overlays. Each network overlay may use different control and data plane approaches and may be managed by a different organization. Structuring the network into multiple network overlays enables the interworking of different overlay approaches to data and control plane methods. The different network overlays are autonomous from a control and data plane perspective, this in turn enables failure survivability across overlay domains. This document specifies the mechanisms and procedures for the distribution of control plane information across overlay sites and in the uberlay as well as the lookup and forwarding procedures for unicast and multicast traffic within and across overlays. The specification also defines the procedures to support inter-overlay mobility of EIDs and their integration with the intra-overlay EID mobility procedures defined in draft-ietf-lisp-eid-mobility.Work in ProgressSample PubSub Deployment ExperiencesSome LISP production networks have been running different forms of PubSub for some time. The following subsections provide an inventory of some experience lessons from these deployments.PubSub as a Monitoring ToolSome 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')
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. Mitigating Negative Map-Cache Entries 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.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.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.Improved Mobility LatencyAn improved convergence time was observed on the presence of
mobility events on LISP networks running PubSub as compared with
running LISP . As described
in Section 4.1.2.1 of , 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.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.Enhanced Reachability with Dynamic Redistribution of
PrefixesThere 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 and . 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.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.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.Better ServiceabilityEID-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 . 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.Acknowledgments We would like to thank , , , , and for their great suggestions and help
regarding this document. Many thanks to for the careful
AD review.Thanks to for the security
directorate review, for the OPS-DIR
review, for the Gen-ART review, for the rtg-dir review, for the tsv directorate review, and
for the int-dir review. Thanks to , , , , , , ,
, , and for the IESG
review. This work was partly funded by the ANR LISP-Lab project
#ANR-13-INFR-009 .Contributorslispers.netSan JoseCAUnited States of Americafarinacci@gmail.comjohnsonleong@gmail.comCiscoSan JoseCAUnited States of Americafmaino@cisco.comOrangeRennesFrancechristian.jacquenet@orange.comCnamFrancestefano.secci@cnam.frAuthors' AddressesCiscoBarcelonaSpainnatal@cisco.comGoogleUnited States of Americaermagan@gmail.comUPC/BarcelonaTechBarcelonaSpainacabello@ac.upc.eduNexarsharon.barkai@getnexar.comOrangeRennesFrancemohamed.boucadair@orange.com