--- 1/draft-ietf-lisp-pubsub-08.txt 2021-06-28 12:13:25.047573819 -0700 +++ 2/draft-ietf-lisp-pubsub-09.txt 2021-06-28 12:13:25.075574522 -0700 @@ -1,94 +1,95 @@ LISP Working Group A. Rodriguez-Natal Internet-Draft Cisco Intended status: Experimental V. Ermagan -Expires: August 6, 2021 Google +Expires: December 30, 2021 Google A. Cabellos UPC/BarcelonaTech S. Barkai Nexar M. Boucadair Orange - February 2, 2021 + June 28, 2021 Publish/Subscribe Functionality for LISP - draft-ietf-lisp-pubsub-08 + draft-ietf-lisp-pubsub-09 Abstract - This document specifies an extension to the use of Map-Request to - enable Publish/Subscribe (PubSub) operation for LISP. + This document specifies an extension to the Request/Reply based LISP + Control Plane to enable Publish/Subscribe (PubSub) operation. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 6, 2021. + This Internet-Draft will expire on December 30, 2021. Copyright Notice Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 - 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4 5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5 6. Mapping Notification Publish Procedures . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7.1. Security Association between ITR and MS . . . . . . . . . 8 7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 11. Normative References . . . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 + 11. Normative References . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction - The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] - splits current IP addresses in two different namespaces, Endpoint - Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses 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. + The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] + [I-D.ietf-lisp-rfc6833bis] splits current IP addresses in two + different namespaces, Endpoint Identifiers (EIDs) and Routing + Locators (RLOCs). LISP uses 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) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC mapping information from the Mapping System by means of an explicit - request message. Section 7.1 of [I-D.ietf-lisp-rfc6833bis] indicates + request message. Section 6.1 of [I-D.ietf-lisp-rfc6833bis] 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 steps occur: @@ -99,32 +100,32 @@ (3) The Map-Request is forwarded to one of the Map-Servers that the EID-prefix is registered to. (4) The Map-Server creates subscription state for the ITR/RTR/PITR on the EID-prefix. (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to acknowledge the successful subscription. - (6) When there is an RLOC-set change for the EID-prefix, the Map- - Server sends a Map-Notify message to each ITR/RTR/PITR in the - subscription list. + (6) 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. (7) 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 ITR/RTR/ PITR want to be notified. The ITR/RTR/PITR can set the N-bit for several EID-prefixes within a single Map-Request. -2. Requirements Language +2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Deployment Assumptions The specification described in this document makes the following @@ -179,87 +180,86 @@ | | + Site-ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID The following is added to the Map-Request message defined in Section 5.2 of [I-D.ietf-lisp-rfc6833bis]: - xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1 - to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are - present at the end of the Map-Request message. If an xTR is - configured with an xTR-ID or Site-ID, it MUST set the I-bit to 1 - and include its xTR-ID and Site-ID in the Map-Request messages it - generates. If either the xTR-ID or Site-ID is not configured, an - unspecified value is encoded for whichever ID that is not - configured. + xTR-ID bit (I-bit): This bit is set to 1 to indicate that a 128 + bit xTR-ID and a 64 bit Site-ID fields are present at the end of + 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. 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 mapping record. 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 (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 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- Request message, following the xTR-ID. Site-ID is used by the Map-Server receiving the Map-Request message to identify which xTRs belong to the same site. The Site-ID is defined in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] 5. Mapping Request Subscribe Procedures - 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 - EID-Record. The xTR builds a Map-Request according to Section 5.3 of + The xTR subscribes for changes for 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 Section 5.3 of [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- 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 xTR wants to subscribe. 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 to notify 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 Section 8.3 of [I-D.ietf-lisp-rfc6833bis]. Furthermore, upon processing, for each EID-Record that has the N-bit set to 1, the - Map-Server proceeds adding the xTR-ID contained in the Map-Request to - the list of xTR that have requested to be subscribed to that mapping + 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 mapping record. 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 MUST follow the specification in Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify with the following considerations: (1) The Map-Server MUST use the nonce from the Map-Request as the nonce for the Map-Notify. (2) The Map-Server MUST use its security association with the xTR (see Section 7.1) to compute the authentication data of the Map- Notify. (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 (which one is implementation + specific). 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 Section 5.7 of [I-D.ietf-lisp-rfc6833bis] with the following considerations. The xTR MUST use its security association with the Map-Server (see Section 7.1) to validate the authentication data on the Map-Notify. The xTR MUST use the Map-Notify to populate its map- cache with the returned EID-prefix and RLOC-set. @@ -280,53 +280,57 @@ EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs present in the Map-Request, and store the association between the EID-Record, xTR-ID, ITR-RLOCs and nonce. Any already present state regarding ITR-RLOCs and/or nonce for the same xTR-ID MUST be overwritten. The following specifies the procedure to remove a subscription. 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 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 - expires, the EID-prefix is removed from the Map-Server's subscription - cache. On EID-Record removal, the Map-Server notifies the - subscribers via a Map-Notify with TTL equal 0. + source RLOC of the Map-Request. + + When an EID-Record 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 0. 6. Mapping Notification Publish Procedures The publish procedure is implemented via Map-Notify messages that the 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 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 updated mapping information. The Map-Notify message sent to each of the subscribers as a result of an update event MUST follow the exact encoding and logic defined in Section 5.7 of [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 - with the xTR-ID of the subscriber. + with the xTR-ID of the subscriber (which one is implementation + specific). (2) 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- Record. The starting nonce is set as follows, if the subscription state at the Map-Server was created by a received Map-Request with the N-bit set, the starting nonce in the Map- Notify sent as publication MUST be the one used in the Map- Request that created the subscription state. If the subscription state was created by explicit configuration at the - Map-Server, the starting nonce in the Map-Notify sent as - publication MUST be randomly generated by the Map-Server. + Map-Server (possible when a pre-shared security association + exists, see Section 7), the starting nonce 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 compute the authentication data of the Map-Notify. 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. Processing of unsolicited Map-Notify messages MUST be explicitly enabled via configuration at the xTR. 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-Record. If @@ -346,21 +350,23 @@ The xTR processes the received Map-Notify as specified in Section 5.7 of [I-D.ietf-lisp-rfc6833bis], with the following considerations. The xTR MUST use its security association with the Map-Server (see 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 update its internal map-cache. The xTR MUST acknowledge the Map- 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 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- - Notify to a different ITR-RLOC for that xTR-ID. + 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. 7. Security Considerations Generic security considerations related to LISP control messages are discussed in Section 9 of [I-D.ietf-lisp-rfc6833bis]. 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. @@ -468,60 +474,92 @@ Email: stefano.secci@cnam.fr 9. Acknowledgments This work is partly funded by the ANR LISP-Lab project #ANR- 13-INFR-009 (https://www.lisp-lab.org). 10. IANA Considerations - This document is requesting bit allocations in the Map-Request - message from the "LISP Control Plane Header Bits" registry introduced - in Section 12.6 of [I-D.ietf-lisp-rfc6833bis]. In particular, this - document requests allocating the following two bits from the sub- - registry "Map-Request Header Bits". The position of these two bits - in the Map-Request message can be found in Figure 1. + This document requests IANA to assign a new bit from the "LISP + Control Plane Header Bits: Map-Request" sub-registry under the + "Locator/ID Separation Protocol (LISP) Parameters" registry available + at [IANA-LISP]. The position of this bit in the Map-Request message + can be found in Figure 1. + + +-----------+---------------+--------------+-------------+ + | Spec Name | IANA Name | Bit Position | Description | + +-----------+---------------+--------------+-------------+ + | I | map-request-I | 11 | xTR-ID Bit | + +-----------+---------------+--------------+-------------+ + + Table 1: Additions to the Map-Request Header Bits Sub-Registry + + This document also requests the creation of a new sub-registry + entitled "LISP Map-Request Record Bits" under the "Locator/ID + Separation Protocol (LISP) Parameters" registry available at + [IANA-LISP]. + + The initial content of this sub-registry is shown below: +----------+---------------+-------------+--------------------------+ | Spec | IANA Name | Bit | Description | | Name | | Position | | +----------+---------------+-------------+--------------------------+ - | I | map-request-I | 11 | xTR-ID Bit | - | N | map-request-N | ... + 0 | Notification-Requested | + | N | map-request-N | 1 | Notification-Requested | | | | | Bit | +----------+---------------+-------------+--------------------------+ - Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry + Bits in position 2-8 are for future assignment. + + The policy for allocating new bits from this sub-registry is + Specification Required (Section 4.6 of [RFC8126]). 11. Normative References + [I-D.ietf-lisp-rfc6830bis] + Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. + Cabellos, "The Locator/ID Separation Protocol (LISP)", + draft-ietf-lisp-rfc6830bis-36 (work in progress), November + 2020. + [I-D.ietf-lisp-rfc6833bis] - Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- - Aparicio, "Locator/ID Separation Protocol (LISP) Control- - Plane", draft-ietf-lisp-rfc6833bis-30 (work in progress), - November 2020. + Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, + "Locator/ID Separation Protocol (LISP) Control-Plane", + draft-ietf-lisp-rfc6833bis-30 (work in progress), November + 2020. [I-D.ietf-lisp-sec] - Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. - Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 - (work in progress), January 2021. + Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, + "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-22 (work + in progress), January 2021. + + [IANA-LISP] + IANA, "Locator/ID Separation Protocol (LISP) Parameters", + . [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Alberto Rodriguez-Natal Cisco 170 Tasman Drive San Jose, CA