idnits 2.17.1 draft-ietf-lisp-pubsub-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2018) is 2000 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-19 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP Working Group A. Rodriguez-Natal 3 Internet-Draft V. Ermagan 4 Intended status: Experimental J. Leong 5 Expires: May 7, 2019 F. Maino 6 Cisco Systems 7 A. Cabellos-Aparicio 8 Technical University of Catalonia 9 S. Barkai 10 Fermi Serverless 11 D. Farinacci 12 lispers.net 13 M. Boucadair 14 C. Jacquenet 15 Orange 16 S. Secci 17 Cnam 18 November 3, 2018 20 Publish/Subscribe Functionality for LISP 21 draft-ietf-lisp-pubsub-02 23 Abstract 25 This document specifies an extension to the use of Map-Request to 26 enable Publish/Subscribe (PubSub) operation for LISP. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 7, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 64 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 65 4. Deployment Assumptions . . . . . . . . . . . . . . . . . . . 4 66 5. Map-Request PubSub Additions . . . . . . . . . . . . . . . . 4 67 6. Mapping Request Subscribe Procedures . . . . . . . . . . . . 6 68 7. Mapping Notification Publish Procedures . . . . . . . . . . . 8 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] 78 splits current IP addresses in two different namespaces, Endpoint 79 Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map- 80 and-encap approach that relies on (1) a Mapping System (basically a 81 distributed database) that stores and disseminates EID-RLOC mappings 82 and on (2) LISP tunnel routers (xTRs) that encapsulate and 83 decapsulate data packets based on the content of those mappings. 85 Ingress Tunnel Routers (ITRs) / Re-encapsulating Tunnel Routers 86 (RTRs) / Proxy Ingress Tunnel Routers (PITRs) pull EID-to-RLOC 87 mapping information from the Mapping System by means of an explicit 88 request message. [I-D.ietf-lisp-rfc6833bis] indicates how Egress 89 Tunnel Routers (ETRs) can tell ITRs/RTRs/PITRs about mapping changes. 90 This document presents a Publish/Subscribe (PubSub) extension in 91 which the Mapping System can notify ITRs/RTRs/PITRs about mapping 92 changes. When this mechanism is used, mapping changes can be 93 notified faster and can be managed in the Mapping System versus the 94 LISP sites. 96 In general, when an ITR/RTR/PITR wants to be notified for mapping 97 changes for a given EID-prefix, the following steps occur: 99 (1) The ITR/RTR/PITR sends a Map-Request for that EID-prefix. 101 (2) The ITR/RTR/PITR sets the Notification-Requested bit (N-bit) on 102 the Map-Request and includes its xTR-ID and Site-ID. 104 (3) The Map-Request is forwarded to one of the Map-Servers that the 105 EID-prefix is registered to. 107 (4) The Map-Server creates subscription state for the ITR/RTR/PITR 108 on the EID-prefix. 110 (5) The Map-Server sends a Map-Notify to the ITR/RTR/PITR to 111 acknowledge the successful subscription. 113 (6) When there is an RLOC-set change for the EID-prefix, the Map- 114 Server sends a Map-Notify message to each ITR/RTR/PITR in the 115 subscription list. 117 (7) Each ITR/RTR/PITR sends a Map-Notify-Ack to acknowledge the 118 received Map-Notify. 120 This operation is repeated for all EID-prefixes for which ITR/RTR/ 121 PITR want to be notified. The ITR/RTR/PITR can set the N-bit for 122 several EID-prefixes within a single Map-Request. 124 2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 3. Definition of Terms 132 LISP xTR-ID: A 128-bit field that is used as a unique identifier 133 for an xTR. The xTR-ID is especially useful for identifying 134 multiple xTRs serving the same site/EID-prefix. A value of all 135 zeros indicate the xTR-ID is unspecified. 137 LISP Site-ID: A 64-bit field that is used as a unique identifier 138 of a group of xTRs belonging to the same site. A value of 0 139 indicate the Site-ID is unspecified. 141 4. Deployment Assumptions 143 The specification described in this document makes the following 144 deployment assumptions: 146 (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 147 assigned to each xTR. 149 (2) Map-Servers are configured in proxy-reply mode, i.e., they are 150 solicited to generate and send Map-Reply messages for the 151 mappings they are serving. 153 (3) There can be either a soft-state or hard-state security 154 association between the xTRs and the Map-Servers. 156 The distribution of xTR-IDs (and Site-IDs) as well as the management 157 of security associations are out of the scope of this document and 158 are for further study (see Section 8). 160 5. Map-Request PubSub Additions 162 Figure 1 shows the format of the updated Map-Request to support the 163 PubSub functionality. 165 0 1 2 3 166 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |Type=1 |A|M|P|S|p|s|R|I| Reserved | IRC | Record Count | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Nonce . . . | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | . . . Nonce | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Source-EID-AFI | Source EID Address ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | ... | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 183 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 \ | EID-Prefix ... | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Map-Reply Record ... | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | | 189 + + 190 | | 191 + xTR-ID + 192 | | 193 + + 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 + Site-ID + 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID 203 The following is added to the Map-Request message defined in 204 Section 5.2 of [I-D.ietf-lisp-rfc6833bis]: 206 xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1 207 to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are 208 present at the end of the Map-Request message. If an xTR is 209 configured with an xTR-ID or Site-ID, it MUST set the I-bit to 1 210 and include its xTR-ID and Site-ID in the Map-Request messages it 211 generates. If either the xTR-ID or Site-ID is not configured, an 212 unspecified value is encoded for whichever ID that is not 213 configured. 215 Notification-Requested bit (N-bit): The N-bit of an EID-record is 216 set to 1 to specify that the xTR wants to be notified of updates 217 for that mapping record. 219 xTR-ID field: xTR-ID is a 128 bit field at the end of the Map- 220 Request message, starting after the final Record in the message 221 (or the Map-Reply Record, if present). The xTR-ID is used to 222 uniquely identify the sender of a Map-Request message, especially 223 in the case where a site has more than one xTR. A value of all 224 zeros indicate that an xTR-ID is not specified, though encoded in 225 the message. This is useful in the case where a Site-ID is 226 specified, but no xTR-ID is configured. 228 Site-ID field: Site-ID is a 64 bit field at the end of the Map- 229 Request message, following the xTR-ID. Site-ID is used by the 230 Map-Server receiving the Map-Request message to identify which 231 xTRs belong to the same site. A value of 0 indicates that a Site- 232 ID is not specified, though encoded in the message. 234 6. Mapping Request Subscribe Procedures 236 The xTR subscribes for RLOC-set changes for a given EID-prefix by 237 sending a Map-Request to the Mapping System with the N-bit set on the 238 EID-Record. The xTR builds a Map-Request according to 239 [I-D.ietf-lisp-rfc6833bis] but also does the following: 241 (1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- 242 ID to the Map-Request. The xTR-ID uniquely identifies the xTR. 244 (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the 245 xTR wants to subscribe. 247 The Map-Request is forwarded to the appropriate Map-Server through 248 the Mapping System. This document does not assume that a Map-Server 249 is pre-assigned to handle the subscription state for a given xTR. 250 The Map-Server that receives the Map-Request will be the Map-Server 251 responsible to notify that specific xTR about future mapping changes 252 for the subscribed mapping records. 254 Upon receipt of the Map-Request, the Map-Server processes it as 255 described in [I-D.ietf-lisp-rfc6833bis]. Furthermore, upon 256 processing, for each EID-Record that has the N-bit set to 1, the Map- 257 Server proceeds adding the xTR-ID contained in the Map-Request to the 258 list of xTR that have requested to be subscribed to that mapping 259 record. 261 If the xTR-ID is added to the list, the Map-Server MUST send a Map- 262 Notify message back to the xTR to acknowledge the successful 263 subscription. The Map-Server MUST follow the specification in 264 Section 6.1.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify 265 with the following considerations: 267 (1) The Map-Server MUST use the nonce from the Map-Request as the 268 nonce for the Map-Notify. 270 (2) The Map-Server MUST use its security association with the xTR 271 (see Section 4) to compute the authentication data of the Map- 272 Notify. 274 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs 275 received in the Map-Request. 277 When the xTR receives a Map-Notify with a nonce that matches one in 278 the list of outstanding Map-Request messages sent with an N-bit set, 279 it knows that the Map-Notify is to acknowledge a successful 280 subscription. The xTR processes this Map-Notify as described in 281 [I-D.ietf-lisp-rfc6833bis] with the following considerations. The 282 xTR MUST use its security association with the Map-Server (see 283 Section 4) to validate the authentication data on the Map-Notify. 284 The xTR MUST use the Map-Notify to populate its map-cache with the 285 returned EID-prefix and RLOC-set. 287 The subscription of an xTR-ID to the list of subscribers for the EID- 288 Record may fail for a number of reasons. For example, because of 289 local configuration policies (such as white/black lists of 290 subscribers), or because the Map-Server has exhausted the resources 291 to dedicate to the subscription of that EID-Record (e.g., the number 292 of subscribers excess the capacity of the Map-Server). 294 If the subscription fails, the Map-Server MUST send a Map-Reply to 295 the originator of the Map-Request, as described in 296 [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- 297 Server does not support PubSub operation. The xTR processes the Map- 298 Reply as specified in [I-D.ietf-lisp-rfc6833bis]. 300 If an xTR-ID is successfully added to the list of subscribers for an 301 EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs 302 present in the Map-Request, and store the association between the 303 xTR-ID, ITR-RLOCs and nonce. Any already present state regarding 304 ITR-RLOCs and/or nonce for the same xTR-ID MUST be overwritten. 306 If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown 307 Address), the Map-Server MUST remove the subscription state for that 308 xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the 309 source RLOC of the Map-Request. When the TTL for the EID-record 310 expires, the EID-prefix is removed from the Map-Server's subscription 311 cache. On EID-Record removal, the Map-Server notifies the 312 subscribers via a Map-Notify with TTL equal 0. 314 7. Mapping Notification Publish Procedures 316 The publish procedure is implemented via Map-Notify messages that the 317 Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- 318 Notifies via sending Map-Notify-Ack messages back to the Map-Server. 319 The complete mechanism works as follows. 321 When a mapping stored in a Map-Server is updated (e.g., via a Map- 322 Register from an ETR), the Map-Server MUST notify the subscribers of 323 that mapping via sending Map-Notify messages with the most updated 324 mapping information. The Map-Notify message sent to each of the 325 subscribers as a result of an update event MUST follow the exact 326 encoding and logic defined in [I-D.ietf-lisp-rfc6833bis] for Map- 327 Notify, except for the following: 329 (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 330 with the xTR-ID of the subscriber. 332 (2) For this version of the specification, the nonce in the Map- 333 Notify sent as publication is set as follows. If the 334 subscription state at the Map-Server was created by a received 335 Map-Request with the N-bit set, the nonce in the Map-Notify sent 336 as publication MUST be the one used in the Map-Request that 337 created the subscription state. If the subscription state was 338 created by explicit configuration at the Map-Server, the nonce 339 in the Map-Notify sent as publication MUST be randomly generated 340 by the Map-Server. 342 (3) The Map-Server MUST use its security association with the xTR to 343 compute the authentication data of the Map-Notify. 345 When the xTR receives a Map-Notify with a nonce sent previously in a 346 Map-Request, or with a nonce not present in any list of previously 347 sent nonces but with an EID not local to the xTR, the xTR knows that 348 the Map-Notify has been received to update an entry on its map-cache. 349 Processing of unsolicited Map-Notify messages MUST be explicitly 350 enabled via configuration at the xTR. 352 The xTR processes the received Map-Notify as specified in 353 [I-D.ietf-lisp-rfc6833bis], with the following considerations. The 354 xTR MUST use its security association with the Map-Server (see 355 Section 4) to validate the authentication data on the Map-Notify. 356 The xTR MUST use the mapping information carried in the Map-Notify to 357 update its internal map-cache. The xTR MUST acknowledge the Map- 358 Notify by sending back a Map-Notify-Ack (specified in 359 [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to 360 the Map-Server. If after a configurable timeout, the Map-Server has 361 not received back the Map-Notify-Ack, it can try to send the Map- 362 Notify to a different ITR-RLOC for that xTR-ID. 364 8. Security Considerations 366 Generic security considerations related to LISP control messages are 367 discussed in [I-D.ietf-lisp-rfc6833bis]. 369 In the particular case of PubSub, cache poisoning via malicious Map- 370 Notify messages is avoided by the use of nonce and the security 371 association between the ITRs and the Map-Servers. Nevertheless, the 372 way to provide a security association between the ITRs and the Map- 373 Servers must be evaluated according to the size of the deployment. 374 For small deployments, it is possible to have a shared key (or set of 375 keys) between the ITRs and the Map-Servers. For larger and Internet- 376 scale deployments, scalability is a concern and further study is 377 needed. Such evaluation is one of the goals of this experimental 378 specification. 380 Misbehaving nodes may send massive subscription requests which may 381 lead to exhaust the resources of Map-Servers. Furthermore, 382 frequently changing the state of a subscription may also be 383 considered as an attack vector. To mitigate such issues, xTRs SHOULD 384 rate-limit Map-Requests and Map-Servers SHOULD rate-limit Map- 385 Notifies. Rate-limiting Map-Requests is discussed in 386 [I-D.ietf-lisp-rfc6833bis] and the same guidelines apply here. To 387 rate-limit Map-Notifies, a Map-Server MUST NOT send more than one 388 Map-Notify per second to a particular xTR-ID. This parameter MUST be 389 configurable. Note that when the Map-Notify rate-limit threshold is 390 met for a particular xTR-ID, the Map-Server will silently discard 391 additional subscription requests from that xTR-ID. Similarly, for 392 pending mapping updates that need to be notified to that xTR-ID, the 393 Map-Server will combine them into a single Map-Notify (with multiple 394 EID-records) which it will send when the rate-limit mechanism allows 395 it to transmit again Map-Notifies to that xTR-ID. 397 9. Acknowledgments 399 This work is partly funded by the ANR LISP-Lab project #ANR- 400 13-INFR-009 (https://www.lisp-lab.org). 402 10. IANA Considerations 404 This document is requesting bit allocations in the Map-Request 405 message from the "LISP Control Plane Header Bits" registry introduced 406 in [I-D.ietf-lisp-rfc6833bis]. In particular, this document requests 407 allocating the following two bits from the sub-registry "Map-Request 408 Header Bits". The position of these two bits in the Map-Request 409 message can be found in Figure 1. 411 +----------+---------------+-------------+--------------------------+ 412 | Spec | IANA Name | Bit | Description | 413 | Name | | Position | | 414 +----------+---------------+-------------+--------------------------+ 415 | I | map-request-I | 11 | xTR-ID Bit | 416 | N | map-request-N | ... + 0 | Notification-Requested | 417 | | | | Bit | 418 +----------+---------------+-------------+--------------------------+ 420 Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry 422 11. Normative References 424 [I-D.ietf-lisp-rfc6833bis] 425 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 426 "Locator/ID Separation Protocol (LISP) Control-Plane", 427 draft-ietf-lisp-rfc6833bis-19 (work in progress), October 428 2018. 430 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 431 Requirement Levels", BCP 14, RFC 2119, 432 DOI 10.17487/RFC2119, March 1997, 433 . 435 Authors' Addresses 437 Alberto Rodriguez-Natal 438 Cisco Systems 439 170 Tasman Drive 440 San Jose, CA 441 USA 443 Email: natal@cisco.com 444 Vina Ermagan 445 Cisco Systems 446 170 Tasman Drive 447 San Jose, CA 448 USA 450 Email: vermagan@cisco.com 452 Johnson Leong 453 Cisco Systems 454 170 Tasman Drive 455 San Jose, CA 456 USA 458 Email: joleong@cisco.com 460 Fabio Maino 461 Cisco Systems 462 170 Tasman Drive 463 San Jose, CA 464 USA 466 Email: fmaino@cisco.com 468 Albert Cabellos-Aparicio 469 Technical University of Catalonia 470 Barcelona 471 Spain 473 Email: acabello@ac.upc.edu 475 Sharon Barkai 476 Fermi Serverless 477 CA 478 USA 480 Email: sharon@fermicloud.io 481 Dino Farinacci 482 lispers.net 483 San Jose, CA 484 USA 486 Email: farinacci@gmail.com 488 Mohamed Boucadair 489 Orange 490 Rennes 35000 491 France 493 Email: mohamed.boucadair@orange.com 495 Christian Jacquenet 496 Orange 497 Rennes 35000 498 France 500 Email: christian.jacquenet@orange.com 502 Stefano Secci 503 Cnam 504 France 506 Email: stefano.secci@cnam.fr