draft-ietf-lisp-pubsub-06.txt   draft-ietf-lisp-pubsub-07.txt 
LISP Working Group A. Rodriguez-Natal LISP Working Group A. Rodriguez-Natal
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Experimental V. Ermagan Intended status: Experimental V. Ermagan
Expires: January 11, 2021 Google Expires: July 12, 2021 Google
A. Cabellos A. Cabellos
UPC/BarcelonaTech UPC/BarcelonaTech
S. Barkai S. Barkai
Nexar Nexar
M. Boucadair M. Boucadair
Orange Orange
July 10, 2020 January 8, 2021
Publish/Subscribe Functionality for LISP Publish/Subscribe Functionality for LISP
draft-ietf-lisp-pubsub-06 draft-ietf-lisp-pubsub-07
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 38 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 January 11, 2021. This Internet-Draft will expire on July 12, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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 . . . . . . . . . . . . 5 5. Mapping Request Subscribe Procedures . . . . . . . . . . . . 5
6. Mapping Notification Publish Procedures . . . . . . . . . . . 7 6. Mapping Notification Publish Procedures . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7.1. Security Association between ITR and MS . . . . . . . . . 8 7.1. Security Association between ITR and MS . . . . . . . . . 8
7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9 7.2. DDoS Attack Mitigation . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . 11 11. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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.
skipping to change at page 6, line 17 skipping to change at page 6, line 17
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
Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify Section 5.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify
with the following 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 7.1) 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
Section 5.7 of [I-D.ietf-lisp-rfc6833bis] with the following Section 5.7 of [I-D.ietf-lisp-rfc6833bis] with the following
skipping to change at page 7, line 31 skipping to change at page 7, line 31
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 Section 5.7 of encoding and logic defined in Section 5.7 of
[I-D.ietf-lisp-rfc6833bis] for Map-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 increments the nonce every time it sends a Map- (2) The Map-Server increments the nonce by one every time it sends a
Notify as publication to an xTR-ID for a particular EID-Record. Map-Notify as publication to an xTR-ID for a particular EID-
The starting nonce is set as follows, if the subscription state Record. The starting nonce is set as follows, if the
at the Map-Server was created by a received Map-Request with the subscription state at the Map-Server was created by a received
N-bit set, the starting nonce in the Map-Notify sent as Map-Request with the N-bit set, the starting nonce in the Map-
publication MUST be the one used in the Map-Request that created Notify sent as publication MUST be the one used in the Map-
the subscription state. If the subscription state was created Request that created the subscription state. If the
by explicit configuration at the Map-Server, the starting nonce subscription state was created by explicit configuration at the
in the Map-Notify sent as publication MUST be randomly generated 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 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 MUST keep track of the last nonce seen in a Map-Notify
as a publication from the Map-Server for the EID-Record. If a Map- received as a publication from the Map-Server for the EID-Record. If
Notify received as a publication has a nonce value that is not 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 greater than the saved nonce, the xTR drops the Map-Notify message
and logs the fact a replay attack could have occurred. The same and logs the fact a replay attack could have occurred. To compare
two nonces, the xTR uses the serial number arithmetic defined in
[RFC1982] with SERIAL_BITS = 64. The nonce field space (64 bits) is
considered large enough to not be depleted during normal operation of
the protocol (e.g., assuming a fast publication rate of one Map-
Notify per EID-Record per Map-Server per second, the nonce field
space will not be depleted in 0.5 trillion years). The same
considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis] considerations discussed in Section 5.6 of [I-D.ietf-lisp-rfc6833bis]
regarding storing Map-Register nonces apply here for Map-Notify regarding storing Map-Register nonces apply here for Map-Notify
nonces. nonces.
The xTR processes the received Map-Notify as specified in Section 5.7 The xTR processes the received Map-Notify as specified in Section 5.7
of [I-D.ietf-lisp-rfc6833bis], with the following considerations. of [I-D.ietf-lisp-rfc6833bis], with the following considerations.
The xTR MUST use its security association with the Map-Server (see The xTR MUST use its security association with the Map-Server (see
Section 7.1) 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-
skipping to change at page 11, line 30 skipping to change at page 11, line 35
| | | | 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
11. 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-30 (work in progress),
January 2020. November 2020.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-21 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-21
(work in progress), July 2020. (work in progress), July 2020.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>.
[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
 End of changes. 13 change blocks. 
24 lines changed or deleted 34 lines changed or added

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