| draft-ietf-lisp-pubsub-03.txt | draft-ietf-lisp-pubsub-04.txt | |||
|---|---|---|---|---|
| LISP Working Group A. Rodriguez-Natal | LISP Working Group A. Rodriguez-Natal | |||
| Internet-Draft Cisco Systems | Internet-Draft Cisco Systems | |||
| Intended status: Experimental V. Ermagan | Intended status: Experimental V. Ermagan | |||
| Expires: September 12, 2019 Google | Expires: March 14, 2020 Google | |||
| J. Leong | J. Leong | |||
| F. Maino | F. Maino | |||
| Cisco Systems | Cisco Systems | |||
| A. Cabellos-Aparicio | A. Cabellos-Aparicio | |||
| Technical University of Catalonia | Technical University of Catalonia | |||
| S. Barkai | S. Barkai | |||
| Fermi Serverless | Nexar Inc. | |||
| D. Farinacci | D. Farinacci | |||
| lispers.net | lispers.net | |||
| M. Boucadair | M. Boucadair | |||
| C. Jacquenet | C. Jacquenet | |||
| Orange | Orange | |||
| S. Secci | S. Secci | |||
| Cnam | Cnam | |||
| March 11, 2019 | September 11, 2019 | |||
| Publish/Subscribe Functionality for LISP | Publish/Subscribe Functionality for LISP | |||
| draft-ietf-lisp-pubsub-03 | draft-ietf-lisp-pubsub-04 | |||
| 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 46 ¶ | skipping to change at page 1, line 46 ¶ | |||
| 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 12, 2019. | This Internet-Draft will expire on March 14, 2020. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 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 30 ¶ | skipping to change at page 2, line 30 ¶ | |||
| 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 . . . . . . . . . . . . 6 | |||
| 6. Mapping Notification Publish Procedures . . . . . . . . . . . 8 | 6. Mapping Notification Publish Procedures . . . . . . . . . . . 8 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 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 | |||
| skipping to change at page 3, line 38 ¶ | skipping to change at page 3, line 38 ¶ | |||
| (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the | (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the | |||
| received Map-Notify. | received Map-Notify. | |||
| This operation is repeated for all EID-prefixes for which ITR/RTR/ | 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 | PITR want to be notified. The ITR/RTR/PITR can set the N-bit for | |||
| several EID-prefixes within a single Map-Request. | several EID-prefixes within a single Map-Request. | |||
| 2. Requirements Language | 2. Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| document are to be interpreted as described in [RFC2119]. | "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 | 3. Deployment Assumptions | |||
| 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 | |||
| skipping to change at page 7, line 30 ¶ | skipping to change at page 7, line 30 ¶ | |||
| 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 | [I-D.ietf-lisp-rfc6833bis] with the following considerations. The | |||
| xTR MUST use its security association with the Map-Server (see | xTR MUST use its security association with the Map-Server (see | |||
| Section 3) to validate the authentication data on the Map-Notify. | 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 | The xTR MUST use the Map-Notify to populate its map-cache with the | |||
| returned EID-prefix and RLOC-set. | 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 white/black 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 | |||
| [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- | [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- | |||
| Server does not support PubSub operation. The xTR processes the Map- | Server does not support PubSub operation. The xTR processes the Map- | |||
| Reply as specified in [I-D.ietf-lisp-rfc6833bis]. | Reply as specified in [I-D.ietf-lisp-rfc6833bis]. | |||
| skipping to change at page 8, line 25 ¶ | skipping to change at page 8, line 25 ¶ | |||
| 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 [I-D.ietf-lisp-rfc6833bis] for Map- | |||
| Notify, except for the following: | 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) For this version of the specification, the nonce in the Map- | (2) The Map-Server incrementes the nonce every time it sends a Map- | |||
| Notify sent as publication is set as follows. If the | Notify as publication to an xTR-ID. The starting nonce is set | |||
| subscription state at the Map-Server was created by a received | as follows, if the subscription state at the Map-Server was | |||
| Map-Request with the N-bit set, the nonce in the Map-Notify sent | created by a received Map-Request with the N-bit set, the | |||
| as publication MUST be the one used in the Map-Request that | starting nonce in the Map-Notify sent as publication MUST be the | |||
| created the subscription state. If the subscription state was | one used in the Map-Request that created the subscription state. | |||
| created by explicit configuration at the Map-Server, the nonce | If the subscription state was created by explicit configuration | |||
| in the Map-Notify sent as publication MUST be randomly generated | at the Map-Server, the starting nonce in the Map-Notify sent as | |||
| by the Map-Server. | 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 a nonce sent previously in a | When the xTR receives a Map-Notify with an EID not local to the xTR, | |||
| Map-Request, or with a nonce not present in any list of previously | the xTR knows that the Map-Notify has been received to update an | |||
| sent nonces but with an EID not local to the xTR, the xTR knows that | entry on its map-cache. Processing of unsolicited Map-Notify | |||
| the Map-Notify has been received to update an entry on its map-cache. | messages MUST be explicitly enabled via configuration at the xTR. | |||
| Processing of unsolicited Map-Notify messages MUST be explicitly | The xTR keeps track of the last nonce seen in a Map-Notify received | |||
| enabled via configuration at the xTR. | 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 | The xTR processes the received Map-Notify as specified in | |||
| [I-D.ietf-lisp-rfc6833bis], with the following considerations. The | [I-D.ietf-lisp-rfc6833bis], with the following considerations. The | |||
| xTR MUST use its security association with the Map-Server (see | xTR MUST use its security association with the Map-Server (see | |||
| Section 3) to validate the authentication data on the Map-Notify. | Section 3) 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 | |||
| [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 [I-D.ietf-lisp-rfc6833bis]. | |||
| skipping to change at page 10, line 22 ¶ | skipping to change at page 10, line 28 ¶ | |||
| | 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 | 10. Normative References | |||
| [I-D.ietf-lisp-rfc6833bis] | [I-D.ietf-lisp-rfc6833bis] | |||
| Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, | Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- | |||
| "Locator/ID Separation Protocol (LISP) Control-Plane", | Aparicio, "Locator/ID Separation Protocol (LISP) Control- | |||
| draft-ietf-lisp-rfc6833bis-24 (work in progress), February | Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), | |||
| 2019. | June 2019. | |||
| [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 | ||||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | ||||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Alberto Rodriguez-Natal | Alberto Rodriguez-Natal | |||
| Cisco Systems | Cisco Systems | |||
| 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 | |||
| USA | USA | |||
| Email: ermagan@gmail.com | Email: ermagan@gmail.com | |||
| Johnson Leong | Johnson Leong | |||
| Cisco Systems | Cisco Systems | |||
| 170 Tasman Drive | 170 Tasman Drive | |||
| San Jose, CA | San Jose, CA | |||
| USA | USA | |||
| Email: joleong@cisco.com | Email: joleong@cisco.com | |||
| Fabio Maino | Fabio Maino | |||
| Cisco Systems | Cisco Systems | |||
| skipping to change at page 11, line 28 ¶ | skipping to change at page 11, line 34 ¶ | |||
| Email: fmaino@cisco.com | Email: fmaino@cisco.com | |||
| Albert Cabellos-Aparicio | Albert Cabellos-Aparicio | |||
| Technical University of Catalonia | Technical University of Catalonia | |||
| Barcelona | Barcelona | |||
| Spain | Spain | |||
| Email: acabello@ac.upc.edu | Email: acabello@ac.upc.edu | |||
| Sharon Barkai | Sharon Barkai | |||
| Fermi Serverless | Nexar Inc. | |||
| CA | ||||
| USA | ||||
| Email: sharon@fermicloud.io | Email: sharon.barkai@getnexar.com | |||
| Dino Farinacci | Dino Farinacci | |||
| lispers.net | lispers.net | |||
| San Jose, CA | San Jose, CA | |||
| USA | USA | |||
| Email: farinacci@gmail.com | 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 | Christian Jacquenet | |||
| Orange | Orange | |||
| Rennes 35000 | Rennes 35000 | |||
| France | France | |||
| Email: christian.jacquenet@orange.com | Email: christian.jacquenet@orange.com | |||
| Stefano Secci | Stefano Secci | |||
| Cnam | Cnam | |||
| France | France | |||
| End of changes. 19 change blocks. | ||||
| 35 lines changed or deleted | 43 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/ | ||||