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