draft-ietf-lisp-pubsub-05.txt   draft-ietf-lisp-pubsub-06.txt 
LISP Working Group A. Rodriguez-Natal LISP Working Group A. Rodriguez-Natal
Internet-Draft Cisco Systems Internet-Draft Cisco
Intended status: Experimental V. Ermagan Intended status: Experimental V. Ermagan
Expires: September 19, 2020 Google Expires: January 11, 2021 Google
J. Leong A. Cabellos
UPC/BarcelonaTech
F. Maino
Cisco Systems
A. Cabellos-Aparicio
Technical University of Catalonia
S. Barkai S. Barkai
Nexar Inc. Nexar
D. Farinacci
lispers.net
M. Boucadair M. Boucadair
C. Jacquenet
Orange Orange
S. Secci July 10, 2020
Cnam
March 18, 2020
Publish/Subscribe Functionality for LISP Publish/Subscribe Functionality for LISP
draft-ietf-lisp-pubsub-05 draft-ietf-lisp-pubsub-06
Abstract Abstract
This document specifies an extension to the use of Map-Request to This document specifies an extension to the use of Map-Request to
enable Publish/Subscribe (PubSub) operation for LISP. enable Publish/Subscribe (PubSub) operation for LISP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 47 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2020. This Internet-Draft will expire on January 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 15
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3
4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4 4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4
5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6 5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5
6. Mapping Notification Publish Procedures . . . . . . . . . . . 8 6. Mapping Notification Publish Procedures . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Security Association between ITR and MS . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9
10. Normative References . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis]
splits current IP addresses in two different namespaces, Endpoint splits current IP addresses in two different namespaces, Endpoint
Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map- Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map-
and-encap approach that relies on (1) a Mapping System (basically a and-encap approach that relies on (1) a Mapping System (basically a
distributed database) that stores and disseminates EID-RLOC mappings distributed database) that stores and disseminates EID-RLOC mappings
and on (2) LISP tunnel routers (xTRs) that encapsulate and and on (2) LISP tunnel routers (xTRs) that encapsulate and
decapsulate data packets based on the content of those mappings. decapsulate data packets based on the content of those mappings.
Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers
(RTRs) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC (RTRs) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC
mapping information from the Mapping System by means of an explicit mapping information from the Mapping System by means of an explicit
request message. [I-D.ietf-lisp-rfc6833bis] indicates how Egress request message. Section 7.1 of [I-D.ietf-lisp-rfc6833bis] indicates
Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about mapping changes. how Egress Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about
This document presents a Publish/Subscribe (PubSub) extension in mapping changes. This document presents a Publish/Subscribe (PubSub)
which the Mapping System can notify ITRs/RTRs/PITRs about mapping extension in which the Mapping System can notify ITRs/RTRs/PITRs
changes. When this mechanism is used, mapping changes can be about mapping changes. When this mechanism is used, mapping changes
notified faster and can be managed in the Mapping System versus the can be notified faster and can be managed in the Mapping System
LISP sites. versus the LISP sites.
In general, when an ITR/RTR/PITR wants to be notified for mapping In general, when an ITR/RTR/PITR wants to be notified for mapping
changes for a given EID-prefix, the following steps occur: changes for a given EID-prefix, the following steps occur:
(1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix.
(2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on
the Map-Request and includes its xTR-ID and Site-ID. the Map-Request and includes its xTR-ID and Site-ID.
(3) The Map-Request is forwarded to one of the Map-Servers that the (3) The Map-Request is forwarded to one of the Map-Servers that the
skipping to change at page 4, line 9 skipping to change at page 3, line 48
The specification described in this document makes the following The specification described in this document makes the following
deployment assumptions: deployment assumptions:
(1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is
assigned to each xTR. assigned to each xTR.
(2) Map-Servers are configured in proxy-reply mode, i.e., they are (2) Map-Servers are configured in proxy-reply mode, i.e., they are
solicited to generate and send Map-Reply messages for the solicited to generate and send Map-Reply messages for the
mappings they are serving. mappings they are serving.
(3) There can be either a soft-state or hard-state security The distribution of xTR-IDs (and Site-IDs) are out of the scope of
association between the xTRs and the Map-Servers. this document.
The distribution of xTR-IDs (and Site-IDs) as well as the management
of security associations are out of the scope of this document and
are for further study (see Section 7).
4. Map-Request PubSub Additions 4. Map-Request PubSub Additions
Figure 1 shows the format of the updated Map-Request to support the Figure 1 shows the format of the updated Map-Request to support the
PubSub functionality. PubSub functionality.
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 |
skipping to change at page 6, line 15 skipping to change at page 5, line 19
configured. configured.
Notification-Requested bit (N-bit): The N-bit of an EID-record is 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 set to 1 to specify that the xTR wants to be notified of updates
for that mapping record. for that mapping record.
xTR-ID field: xTR-ID is a 128 bit field at the end of the Map- xTR-ID field: xTR-ID is a 128 bit field at the end of the Map-
Request message, starting after the final Record in the message Request message, starting after the final Record in the message
(or the Map-Reply Record, if present). The xTR-ID is used to (or the Map-Reply Record, if present). The xTR-ID is used to
uniquely identify the sender of a Map-Request message. The xTR-ID uniquely identify the sender of a Map-Request message. The xTR-ID
is defined in [I-D.ietf-lisp-rfc6833bis] is defined in Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
Site-ID field: Site-ID is a 64 bit field at the end of the Map- Site-ID field: Site-ID is a 64 bit field at the end of the Map-
Request message, following the xTR-ID. Site-ID is used by the Request message, following the xTR-ID. Site-ID is used by the
Map-Server receiving the Map-Request message to identify which Map-Server receiving the Map-Request message to identify which
xTRs belong to the same site. The Site-ID is defined in xTRs belong to the same site. The Site-ID is defined in
[I-D.ietf-lisp-rfc6833bis] Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
5. Mapping Request Subscribe Procedures 5. Mapping Request Subscribe Procedures
The xTR subscribes for RLOC-set changes for a given EID-prefix by The xTR subscribes for RLOC-set changes for a given EID-prefix by
sending a Map-Request to the Mapping System with the N-bit set on the 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 EID-Record. The xTR builds a Map-Request according to Section 5.3 of
[I-D.ietf-lisp-rfc6833bis] but also does the following: [I-D.ietf-lisp-rfc6833bis] but also does the following:
(1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- (1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site-
ID to the Map-Request. The xTR-ID uniquely identifies the xTR. ID to the Map-Request. The xTR-ID uniquely identifies the xTR.
(2) The xTR MUST set the N-bit to 1 for each EID-Record to which the (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the
xTR wants to subscribe. xTR wants to subscribe.
The Map-Request is forwarded to the appropriate Map-Server through The Map-Request is forwarded to the appropriate Map-Server through
the Mapping System. This document does not assume that a Map-Server the Mapping System. This document does not assume that a Map-Server
is pre-assigned to handle the subscription state for a given xTR. 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 The Map-Server that receives the Map-Request will be the Map-Server
responsible to notify that specific xTR about future mapping changes responsible to notify that specific xTR about future mapping changes
for the subscribed mapping records. for the subscribed mapping records.
Upon receipt of the Map-Request, the Map-Server processes it as Upon receipt of the Map-Request, the Map-Server processes it as
described in [I-D.ietf-lisp-rfc6833bis]. Furthermore, upon described in Section 8.3 of [I-D.ietf-lisp-rfc6833bis]. Furthermore,
processing, for each EID-Record that has the N-bit set to 1, the Map- upon processing, for each EID-Record that has the N-bit set to 1, the
Server proceeds adding the xTR-ID contained in the Map-Request to the Map-Server proceeds adding the xTR-ID contained in the Map-Request to
list of xTR that have requested to be subscribed to that mapping the list of xTR that have requested to be subscribed to that mapping
record. record.
If the xTR-ID is added to the list, the Map-Server MUST send a Map- 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 Notify message back to the xTR to acknowledge the successful
subscription. The Map-Server MUST follow the specification in subscription. The Map-Server MUST follow the specification in
[I-D.ietf-lisp-rfc6833bis] to build the Map-Notify with the following Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify
considerations: with the following considerations:
(1) The Map-Server MUST use the nonce from the Map-Request as the (1) The Map-Server MUST use the nonce from the Map-Request as the
nonce for the Map-Notify. nonce for the Map-Notify.
(2) The Map-Server MUST use its security association with the xTR (2) The Map-Server MUST use its security association with the xTR
(see Section 3) to compute the authentication data of the Map- (see Section 3) to compute the authentication data of the Map-
Notify. Notify.
(3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs
received in the Map-Request. received in the Map-Request.
When the xTR receives a Map-Notify with a nonce that matches one in 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, the list of outstanding Map-Request messages sent with an N-bit set,
it knows that the Map-Notify is to acknowledge a successful it knows that the Map-Notify is to acknowledge a successful
subscription. The xTR processes this Map-Notify as described in subscription. The xTR processes this Map-Notify as described in
[I-D.ietf-lisp-rfc6833bis] with the following considerations. The Section 5.7 of [I-D.ietf-lisp-rfc6833bis] with the following
xTR MUST use its security association with the Map-Server (see considerations. The xTR MUST use its security association with the
Section 3) to validate the authentication data on the Map-Notify. Map-Server (see Section 7.1) to validate the authentication data on
The xTR MUST use the Map-Notify to populate its map-cache with the the Map-Notify. The xTR MUST use the Map-Notify to populate its map-
returned EID-prefix and RLOC-set. cache with the returned EID-prefix and RLOC-set.
The subscription of an xTR-ID to the list of subscribers for the EID- The subscription of an xTR-ID to the list of subscribers for the EID-
Record may fail for a number of reasons. For example, because of Record may fail for a number of reasons. For example, because of
local configuration policies (such as accept and drop lists of local configuration policies (such as accept and drop lists of
subscribers), or because the Map-Server has exhausted the resources subscribers), or because the Map-Server has exhausted the resources
to dedicate to the subscription of that EID-Record (e.g., the number to dedicate to the subscription of that EID-Record (e.g., the number
of subscribers excess the capacity of the Map-Server). of subscribers excess the capacity of the Map-Server).
If the subscription fails, the Map-Server MUST send a Map-Reply to If the subscription fails, the Map-Server MUST send a Map-Reply to
the originator of the Map-Request, as described in the originator of the Map-Request, as described in Section 8.3 of
[I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- [I-D.ietf-lisp-rfc6833bis]. The xTR processes the Map-Reply as
Server does not support PubSub operation. The xTR processes the Map- specified in Section 8.1 of [I-D.ietf-lisp-rfc6833bis].
Reply as specified in [I-D.ietf-lisp-rfc6833bis].
If an xTR-ID is successfully added to the list of subscribers for an If an xTR-ID is successfully added to the list of subscribers for an
EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs
present in the Map-Request, and store the association between the present in the Map-Request, and store the association between the
xTR-ID, ITR-RLOCs and nonce. Any already present state regarding EID-Record, xTR-ID, ITR-RLOCs and nonce. Any already present state
ITR-RLOCs and/or nonce for the same xTR-ID MUST be overwritten. regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be
overwritten.
If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown
Address), the Map-Server MUST remove the subscription state for that Address), the Map-Server MUST remove the subscription state for that
xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the
source RLOC of the Map-Request. When the TTL for the EID-record source RLOC of the Map-Request. When the TTL for the EID-record
expires, the EID-prefix is removed from the Map-Server's subscription expires, the EID-prefix is removed from the Map-Server's subscription
cache. On EID-Record removal, the Map-Server notifies the cache. On EID-Record removal, the Map-Server notifies the
subscribers via a Map-Notify with TTL equal 0. subscribers via a Map-Notify with TTL equal 0.
6. Mapping Notification Publish Procedures 6. Mapping Notification Publish Procedures
skipping to change at page 8, line 19 skipping to change at page 7, line 25
The publish procedure is implemented via Map-Notify messages that the The publish procedure is implemented via Map-Notify messages that the
Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- Map-Server sends to xTRs. The xTRs acknowledge the reception of Map-
Notifies via sending Map-Notify-Ack messages back to the Map-Server. Notifies via sending Map-Notify-Ack messages back to the Map-Server.
The complete mechanism works as follows. The complete mechanism works as follows.
When a mapping stored in a Map-Server is updated (e.g., via a Map- 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 Register from an ETR), the Map-Server MUST notify the subscribers of
that mapping via sending Map-Notify messages with the most updated that mapping via sending Map-Notify messages with the most updated
mapping information. The Map-Notify message sent to each of the mapping information. The Map-Notify message sent to each of the
subscribers as a result of an update event MUST follow the exact subscribers as a result of an update event MUST follow the exact
encoding and logic defined in [I-D.ietf-lisp-rfc6833bis] for Map- encoding and logic defined in Section 5.7 of
Notify, except for the following: [I-D.ietf-lisp-rfc6833bis] for Map-Notify, except for the following:
(1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated
with the xTR-ID of the subscriber. with the xTR-ID of the subscriber.
(2) The Map-Server incrementes the nonce every time it sends a Map- (2) The Map-Server increments the nonce every time it sends a Map-
Notify as publication to an xTR-ID. The starting nonce is set Notify as publication to an xTR-ID for a particular EID-Record.
as follows, if the subscription state at the Map-Server was The starting nonce is set as follows, if the subscription state
created by a received Map-Request with the N-bit set, the at the Map-Server was created by a received Map-Request with the
starting nonce in the Map-Notify sent as publication MUST be the N-bit set, the starting nonce in the Map-Notify sent as
one used in the Map-Request that created the subscription state. publication MUST be the one used in the Map-Request that created
If the subscription state was created by explicit configuration the subscription state. If the subscription state was created
at the Map-Server, the starting nonce in the Map-Notify sent as by explicit configuration at the Map-Server, the starting nonce
publication MUST be randomly generated by the Map-Server. in the Map-Notify sent as publication MUST be randomly generated
by the Map-Server.
(3) The Map-Server MUST use its security association with the xTR to (3) The Map-Server MUST use its security association with the xTR to
compute the authentication data of the Map-Notify. compute the authentication data of the Map-Notify.
When the xTR receives a Map-Notify with an EID not local to the xTR, 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 the xTR knows that the Map-Notify has been received to update an
entry on its map-cache. Processing of unsolicited Map-Notify entry on its map-cache. Processing of unsolicited Map-Notify
messages MUST be explicitly enabled via configuration at the xTR. messages MUST be explicitly enabled via configuration at the xTR.
The xTR keeps track of the last nonce seen in a Map-Notify received The xTR keeps track of the last nonce seen in a Map-Notify received
as a publication from the Map-Server. If a Map-Notify received as a as a publication from the Map-Server for the EID-Record. If a Map-
publication has a nonce value that is not greater than the saved Notify received as a publication has a nonce value that is not
nonce, the xTR drops the Map-Notify message and logs the fact a greater than the saved nonce, the xTR drops the Map-Notify message
replay attack could have occurred. The same considerations discussed and logs the fact a replay attack could have occurred. The same
in [I-D.ietf-lisp-rfc6833bis] regarding storing Map-Register nonces considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
apply here for Map-Notify nonces. regarding storing Map-Register nonces apply here for Map-Notify
nonces.
The xTR processes the received Map-Notify as specified in The xTR processes the received Map-Notify as specified in Section 5.7
[I-D.ietf-lisp-rfc6833bis], with the following considerations. The of [I-D.ietf-lisp-rfc6833bis], with the following considerations.
xTR MUST use its security association with the Map-Server (see The xTR MUST use its security association with the Map-Server (see
Section 3) to validate the authentication data on the Map-Notify. Section 7.1) to validate the authentication data on the Map-Notify.
The xTR MUST use the mapping information carried in the Map-Notify to The xTR MUST use the mapping information carried in the Map-Notify to
update its internal map-cache. The xTR MUST acknowledge the Map- update its internal map-cache. The xTR MUST acknowledge the Map-
Notify by sending back a Map-Notify-Ack (specified in Notify by sending back a Map-Notify-Ack (specified in Section 5.7 of
[I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to
the Map-Server. If after a configurable timeout, the Map-Server has the Map-Server. If after a configurable timeout, the Map-Server has
not received back the Map-Notify-Ack, it can try to send the Map- not received back the Map-Notify-Ack, it can try to send the Map-
Notify to a different ITR-RLOC for that xTR-ID. Notify to a different ITR-RLOC for that xTR-ID.
7. Security Considerations 7. Security Considerations
Generic security considerations related to LISP control messages are Generic security considerations related to LISP control messages are
discussed in [I-D.ietf-lisp-rfc6833bis]. discussed in Section 9 of [I-D.ietf-lisp-rfc6833bis].
In the particular case of PubSub, cache poisoning via malicious Map- In the particular case of PubSub, cache poisoning via malicious Map-
Notify messages is avoided by the use of nonce and the security Notify messages is avoided by the use of nonce and the security
association between the ITRs and the Map-Servers. Nevertheless, the association between the ITRs and the Map-Servers.
way to provide a security association between the ITRs and the Map-
Servers must be evaluated according to the size of the deployment. 7.1. Security Association between ITR and MS
For small deployments, it is possible to have a shared key (or set of
keys) between the ITRs and the Map-Servers. For larger and Internet- Since Map-Notifies from the Map-Server to the ITR need to be
scale deployments, scalability is a concern and further study is authenticated, there is a need for a soft-state or hard-state
needed. Such evaluation is one of the goals of this experimental security association (e.g. a PubSubKey) between the ITRs and the Map-
specification. 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-SEC [I-D.ietf-lisp-sec] can be used as follows to
create a security association between the ITR and the MS.
First, when the ITR is sending a Map-Request with the N-bit set
following Section 5, the ITR also performs the steps described in
Section 5.4 of [I-D.ietf-lisp-sec]. The ITR can then generate a
PubSubKey by deriving a key from the OTK as follows: PubSubKey = KDF(
OTK ), where KDF is the Key Derivation Function indicated by the OTK
Wrapping ID. If 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-Record the
ITR subscribes to (since the ITR will use a different OTK per Map-
Request).
When the Map-Server receives the Map-Request it follows Section 5.
If according to Section 5 the Map-Server is to reply with a Map-Reply
(e.g. due to PubSub not supported or subscription not accepted), then
it follows normal LISP-SEC procedure described in Section 5.7 of
[I-D.ietf-lisp-sec]. No PubSubKey or security association is created
in this case.
Otherwise, if, by following Section 5, the Map-Server is to reply
with a Map-Notify (e.g. due to subscription accepted) to a received
Map-Request, the following extra steps take place (note that if the
MS replies with a Map-Notify, none of the regular LISP-SEC steps
regarding Map-Reply described in Section 5.7 of [I-D.ietf-lisp-sec]
takes place).
o The MS extracts the OTK and OTK Wrapping ID from the LISP-SEC ECM
Authentication Data.
o The MS 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 which is used to establish a security association
between the ITR and the MS.
o The PubSubKey can now be used to sign and authenticate any Map-
Notify between the MS and the ITR for the subscribed EID-Record.
This includes the Map-Notify sent as a confirmation to the
subscription. When the ITR wants to update the security
association for that MS and EID-Record, it follows again the
procedure described in this section.
7.2. DDoS Attack Mitigation
Misbehaving nodes may send massive subscription requests which may Misbehaving nodes may send massive subscription requests which may
lead to exhaust the resources of Map-Servers. Furthermore, lead to exhaust the resources of Map-Servers. Furthermore,
frequently changing the state of a subscription may also be frequently changing the state of a subscription may also be
considered as an attack vector. To mitigate such issues, xTRs SHOULD considered as an attack vector. To mitigate such issues, xTRs SHOULD
rate-limit Map-Requests and Map-Servers SHOULD rate-limit Map- rate-limit Map-Requests and Map-Servers SHOULD rate-limit Map-
Notifies. Rate-limiting Map-Requests is discussed in Notifies. Rate-limiting Map-Requests is discussed in Section 5.3 of
[I-D.ietf-lisp-rfc6833bis] and the same guidelines apply here. To [I-D.ietf-lisp-rfc6833bis] and the same guidelines apply here. To
rate-limit Map-Notifies, a Map-Server MUST NOT send more than one rate-limit Map-Notifies, a Map-Server MUST NOT send more than one
Map-Notify per second to a particular xTR-ID. This parameter MUST be Map-Notify per second to a particular xTR-ID. This parameter MUST be
configurable. Note that when the Map-Notify rate-limit threshold is configurable. Note that when the Map-Notify rate-limit threshold is
met for a particular xTR-ID, the Map-Server will silently discard met for a particular xTR-ID, the Map-Server will silently discard
additional subscription requests from that xTR-ID. Similarly, for additional subscription requests from that xTR-ID. Similarly, for
pending mapping updates that need to be notified to that xTR-ID, the pending mapping updates that need to be notified to that xTR-ID, the
Map-Server will combine them into a single Map-Notify (with multiple Map-Server will combine them into a single Map-Notify (with multiple
EID-records) which it will send when the rate-limit mechanism allows EID-records) which it will send when the rate-limit mechanism allows
it to transmit again Map-Notifies to that xTR-ID. it to transmit again Map-Notifies to that xTR-ID.
8. Acknowledgments 8. Contributors
Dino Farinacci
lispers.net
San Jose, CA
USA
Email: farinacci@gmail.com
Johnson Leong
Email: johnsonleong@gmail.com
Fabio Maino
Cisco
170 Tasman Drive
San Jose, CA
USA
Email: fmaino@cisco.com
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Stefano Secci
Cnam
France
Email: stefano.secci@cnam.fr
9. Acknowledgments
This work is partly funded by the ANR LISP-Lab project #ANR- This work is partly funded by the ANR LISP-Lab project #ANR-
13-INFR-009 (https://www.lisp-lab.org). 13-INFR-009 (https://www.lisp-lab.org).
9. IANA Considerations 10. IANA Considerations
This document is requesting bit allocations in the Map-Request This document is requesting bit allocations in the Map-Request
message from the "LISP Control Plane Header Bits" registry introduced message from the "LISP Control Plane Header Bits" registry introduced
in [I-D.ietf-lisp-rfc6833bis]. In particular, this document requests in Section 12.6 of [I-D.ietf-lisp-rfc6833bis]. In particular, this
allocating the following two bits from the sub-registry "Map-Request document requests allocating the following two bits from the sub-
Header Bits". The position of these two bits in the Map-Request registry "Map-Request Header Bits". The position of these two bits
message can be found in Figure 1. in the Map-Request message can be found in Figure 1.
+----------+---------------+-------------+--------------------------+ +----------+---------------+-------------+--------------------------+
| Spec | IANA Name | Bit | Description | | Spec | IANA Name | Bit | Description |
| Name | | Position | | | Name | | Position | |
+----------+---------------+-------------+--------------------------+ +----------+---------------+-------------+--------------------------+
| I | map-request-I | 11 | xTR-ID Bit | | I | map-request-I | 11 | xTR-ID Bit |
| N | map-request-N | ... + 0 | Notification-Requested | | N | map-request-N | ... + 0 | Notification-Requested |
| | | | Bit | | | | | Bit |
+----------+---------------+-------------+--------------------------+ +----------+---------------+-------------+--------------------------+
Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry
10. Normative References 11. Normative References
[I-D.ietf-lisp-rfc6833bis] [I-D.ietf-lisp-rfc6833bis]
Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Farinacci, D., Maino, F., Fuller, V., and A. Cabellos-
Aparicio, "Locator/ID Separation Protocol (LISP) Control- Aparicio, "Locator/ID Separation Protocol (LISP) Control-
Plane", draft-ietf-lisp-rfc6833bis-27 (work in progress), Plane", draft-ietf-lisp-rfc6833bis-27 (work in progress),
January 2020. January 2020.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-21
(work in progress), July 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
skipping to change at page 10, line 43 skipping to change at page 12, line 4
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Authors' Addresses Authors' Addresses
Alberto Rodriguez-Natal Alberto Rodriguez-Natal
Cisco Systems Cisco
170 Tasman Drive 170 Tasman Drive
San Jose, CA San Jose, CA
USA USA
Email: natal@cisco.com Email: natal@cisco.com
Vina Ermagan Vina Ermagan
Google Google
USA USA
Email: ermagan@gmail.com Email: ermagan@gmail.com
Johnson Leong Albert Cabellos
UPC/BarcelonaTech
Email: johnsonleong@gmail.com
Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: fmaino@cisco.com
Albert Cabellos-Aparicio
Technical University of Catalonia
Barcelona Barcelona
Spain Spain
Email: acabello@ac.upc.edu Email: acabello@ac.upc.edu
Sharon Barkai Sharon Barkai
Nexar Inc. Nexar
Email: sharon.barkai@getnexar.com Email: sharon.barkai@getnexar.com
Dino Farinacci
lispers.net
San Jose, CA
USA
Email: farinacci@gmail.com
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Stefano Secci
Cnam
France
Email: stefano.secci@cnam.fr
 End of changes. 38 change blocks. 
119 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/