--- 1/draft-ietf-lisp-pubsub-03.txt 2019-09-11 18:13:10.704863190 -0700 +++ 2/draft-ietf-lisp-pubsub-04.txt 2019-09-11 18:13:10.732863909 -0700 @@ -1,33 +1,33 @@ LISP Working Group A. Rodriguez-Natal Internet-Draft Cisco Systems Intended status: Experimental V. Ermagan -Expires: September 12, 2019 Google +Expires: March 14, 2020 Google J. Leong F. Maino Cisco Systems A. Cabellos-Aparicio Technical University of Catalonia S. Barkai - Fermi Serverless + Nexar Inc. D. Farinacci lispers.net M. Boucadair C. Jacquenet Orange S. Secci Cnam - March 11, 2019 + September 11, 2019 Publish/Subscribe Functionality for LISP - draft-ietf-lisp-pubsub-03 + draft-ietf-lisp-pubsub-04 Abstract This document specifies an extension to the use of Map-Request to enable Publish/Subscribe (PubSub) operation for LISP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -35,21 +35,21 @@ 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 September 12, 2019. + This Internet-Draft will expire on March 14, 2020. Copyright Notice Copyright (c) 2019 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 @@ -62,21 +62,21 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 3 4. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4 5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6 6. Mapping Notification Publish Procedures . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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 @@ -118,22 +118,24 @@ (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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. + "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 deployment assumptions: (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is assigned to each xTR. (2) Map-Servers are configured in proxy-reply mode, i.e., they are @@ -266,21 +268,21 @@ it knows that the Map-Notify is to acknowledge a successful subscription. The xTR processes this Map-Notify as described in [I-D.ietf-lisp-rfc6833bis] with the following considerations. The xTR MUST use its security association with the Map-Server (see Section 3) 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. 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 - local configuration policies (such as white/black lists of + local configuration policies (such as accept and drop lists of subscribers), or because the Map-Server has exhausted the resources to dedicate to the subscription of that EID-Record (e.g., the number of subscribers excess the capacity of the Map-Server). If the subscription fails, the Map-Server MUST send a Map-Reply to the originator of the Map-Request, as described in [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- Server does not support PubSub operation. The xTR processes the Map- Reply as specified in [I-D.ietf-lisp-rfc6833bis]. @@ -309,48 +311,52 @@ 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 [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. - (2) For this version of the specification, the nonce in the Map- - Notify sent as publication 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 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 nonce - in the Map-Notify sent as publication MUST be randomly generated - by the Map-Server. + (2) The Map-Server incrementes the nonce every time it sends a Map- + Notify as publication to an xTR-ID. 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. (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 a nonce sent previously in a - Map-Request, or with a nonce not present in any list of previously - sent nonces but 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. + 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 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 + 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 [I-D.ietf-lisp-rfc6833bis] regarding storing Map-Register nonces + apply here for Map-Notify nonces. The xTR processes the received Map-Notify as specified in [I-D.ietf-lisp-rfc6833bis], with the following considerations. The xTR MUST use its security association with the Map-Server (see Section 3) 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 - [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. 7. Security Considerations Generic security considerations related to LISP control messages are discussed in [I-D.ietf-lisp-rfc6833bis]. @@ -403,45 +409,49 @@ | I | map-request-I | 11 | xTR-ID Bit | | N | map-request-N | ... + 0 | Notification-Requested | | | | | Bit | +----------+---------------+-------------+--------------------------+ Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry 10. Normative References [I-D.ietf-lisp-rfc6833bis] - Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, - "Locator/ID Separation Protocol (LISP) Control-Plane", - draft-ietf-lisp-rfc6833bis-24 (work in progress), February - 2019. + Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- + Aparicio, "Locator/ID Separation Protocol (LISP) Control- + Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), + June 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [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 Systems 170 Tasman Drive San Jose, CA USA Email: natal@cisco.com - Vina Ermagan Google USA Email: ermagan@gmail.com + Johnson Leong Cisco Systems 170 Tasman Drive San Jose, CA USA Email: joleong@cisco.com Fabio Maino Cisco Systems @@ -452,39 +462,37 @@ Email: fmaino@cisco.com Albert Cabellos-Aparicio Technical University of Catalonia Barcelona Spain Email: acabello@ac.upc.edu Sharon Barkai - Fermi Serverless - CA - USA + Nexar Inc. - Email: sharon@fermicloud.io + Email: sharon.barkai@getnexar.com Dino Farinacci lispers.net San Jose, CA USA Email: farinacci@gmail.com - Mohamed Boucadair Orange Rennes 35000 France Email: mohamed.boucadair@orange.com + Christian Jacquenet Orange Rennes 35000 France Email: christian.jacquenet@orange.com Stefano Secci Cnam France