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
Google Google
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/