idnits 2.17.1 draft-ietf-lisp-pubsub-04.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 (September 11, 2019) is 1661 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-25 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: March 14, 2020 Google 6 J. Leong 7 F. Maino 8 Cisco Systems 9 A. Cabellos-Aparicio 10 Technical University of Catalonia 11 S. Barkai 12 Nexar Inc. 13 D. Farinacci 14 lispers.net 15 M. Boucadair 16 C. Jacquenet 17 Orange 18 S. Secci 19 Cnam 20 September 11, 2019 22 Publish/Subscribe Functionality for LISP 23 draft-ietf-lisp-pubsub-04 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 March 14, 2020. 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 . . . . . . . . . . . . . . . . . . . . . 10 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", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Deployment Assumptions 135 The specification described in this document makes the following 136 deployment assumptions: 138 (1) A unique 128-bit xTR-ID (plus a 64-bit Site-ID) identifier is 139 assigned to each xTR. 141 (2) Map-Servers are configured in proxy-reply mode, i.e., they are 142 solicited to generate and send Map-Reply messages for the 143 mappings they are serving. 145 (3) There can be either a soft-state or hard-state security 146 association between the xTRs and the Map-Servers. 148 The distribution of xTR-IDs (and Site-IDs) as well as the management 149 of security associations are out of the scope of this document and 150 are for further study (see Section 7). 152 4. Map-Request PubSub Additions 154 Figure 1 shows the format of the updated Map-Request to support the 155 PubSub functionality. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |Type=1 |A|M|P|S|p|s|R|I| Rsvd |L|D| IRC | Record Count | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Nonce . . . | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | . . . Nonce | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Source-EID-AFI | Source EID Address ... | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | ... | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | ITR-RLOC-AFI n | ITR-RLOC Address n ... | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 / |N| Reserved | EID mask-len | EID-Prefix-AFI | 175 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 \ | EID-Prefix ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Map-Reply Record ... | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 + + 182 | | 183 + xTR-ID + 184 | | 185 + + 186 | | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | | 189 + Site-ID + 190 | | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1: Map-Request with I-bit, N-bit, xTR-ID, and Site-ID 195 The following is added to the Map-Request message defined in 196 Section 5.2 of [I-D.ietf-lisp-rfc6833bis]: 198 xTR-ID bit (I-bit): The I-bit of a Map-Request message is set to 1 199 to indicate that a 128 bit xTR-ID and a 64 bit Site-ID fields are 200 present at the end of the Map-Request message. If an xTR is 201 configured with an xTR-ID or Site-ID, it MUST set the I-bit to 1 202 and include its xTR-ID and Site-ID in the Map-Request messages it 203 generates. If either the xTR-ID or Site-ID is not configured, an 204 unspecified value is encoded for whichever ID that is not 205 configured. 207 Notification-Requested bit (N-bit): The N-bit of an EID-record is 208 set to 1 to specify that the xTR wants to be notified of updates 209 for that mapping record. 211 xTR-ID field: xTR-ID is a 128 bit field at the end of the Map- 212 Request message, starting after the final Record in the message 213 (or the Map-Reply Record, if present). The xTR-ID is used to 214 uniquely identify the sender of a Map-Request message. The xTR-ID 215 is defined in [I-D.ietf-lisp-rfc6833bis] 217 Site-ID field: Site-ID is a 64 bit field at the end of the Map- 218 Request message, following the xTR-ID. Site-ID is used by the 219 Map-Server receiving the Map-Request message to identify which 220 xTRs belong to the same site. The Site-ID is defined in 221 [I-D.ietf-lisp-rfc6833bis] 223 5. Mapping Request Subscribe Procedures 225 The xTR subscribes for RLOC-set changes for a given EID-prefix by 226 sending a Map-Request to the Mapping System with the N-bit set on the 227 EID-Record. The xTR builds a Map-Request according to 228 [I-D.ietf-lisp-rfc6833bis] but also does the following: 230 (1) The xTR MUST set the I-bit to 1 and append its xTR-ID and Site- 231 ID to the Map-Request. The xTR-ID uniquely identifies the xTR. 233 (2) The xTR MUST set the N-bit to 1 for each EID-Record to which the 234 xTR wants to subscribe. 236 The Map-Request is forwarded to the appropriate Map-Server through 237 the Mapping System. This document does not assume that a Map-Server 238 is pre-assigned to handle the subscription state for a given xTR. 239 The Map-Server that receives the Map-Request will be the Map-Server 240 responsible to notify that specific xTR about future mapping changes 241 for the subscribed mapping records. 243 Upon receipt of the Map-Request, the Map-Server processes it as 244 described in [I-D.ietf-lisp-rfc6833bis]. Furthermore, upon 245 processing, for each EID-Record that has the N-bit set to 1, the Map- 246 Server proceeds adding the xTR-ID contained in the Map-Request to the 247 list of xTR that have requested to be subscribed to that mapping 248 record. 250 If the xTR-ID is added to the list, the Map-Server MUST send a Map- 251 Notify message back to the xTR to acknowledge the successful 252 subscription. The Map-Server MUST follow the specification in 253 Section 6.1.7 of [I-D.ietf-lisp-rfc6833bis] to build the Map-Notify 254 with the following considerations: 256 (1) The Map-Server MUST use the nonce from the Map-Request as the 257 nonce for the Map-Notify. 259 (2) The Map-Server MUST use its security association with the xTR 260 (see Section 3) to compute the authentication data of the Map- 261 Notify. 263 (3) The Map-Server MUST send the Map-Notify to one of the ITR-RLOCs 264 received in the Map-Request. 266 When the xTR receives a Map-Notify with a nonce that matches one in 267 the list of outstanding Map-Request messages sent with an N-bit set, 268 it knows that the Map-Notify is to acknowledge a successful 269 subscription. The xTR processes this Map-Notify as described in 270 [I-D.ietf-lisp-rfc6833bis] with the following considerations. The 271 xTR MUST use its security association with the Map-Server (see 272 Section 3) to validate the authentication data on the Map-Notify. 273 The xTR MUST use the Map-Notify to populate its map-cache with the 274 returned EID-prefix and RLOC-set. 276 The subscription of an xTR-ID to the list of subscribers for the EID- 277 Record may fail for a number of reasons. For example, because of 278 local configuration policies (such as accept and drop lists of 279 subscribers), or because the Map-Server has exhausted the resources 280 to dedicate to the subscription of that EID-Record (e.g., the number 281 of subscribers excess the capacity of the Map-Server). 283 If the subscription fails, the Map-Server MUST send a Map-Reply to 284 the originator of the Map-Request, as described in 285 [I-D.ietf-lisp-rfc6833bis]. This is also the case when the Map- 286 Server does not support PubSub operation. The xTR processes the Map- 287 Reply as specified in [I-D.ietf-lisp-rfc6833bis]. 289 If an xTR-ID is successfully added to the list of subscribers for an 290 EID-Record, the Map-Server MUST extract the nonce and ITR-RLOCs 291 present in the Map-Request, and store the association between the 292 xTR-ID, ITR-RLOCs and nonce. Any already present state regarding 293 ITR-RLOCs and/or nonce for the same xTR-ID MUST be overwritten. 295 If the Map-Request only has one ITR-RLOC with AFI = 0 (i.e., Unknown 296 Address), the Map-Server MUST remove the subscription state for that 297 xTR-ID. In this case, the Map-Server MUST send the Map-Notify to the 298 source RLOC of the Map-Request. When the TTL for the EID-record 299 expires, the EID-prefix is removed from the Map-Server's subscription 300 cache. On EID-Record removal, the Map-Server notifies the 301 subscribers via a Map-Notify with TTL equal 0. 303 6. Mapping Notification Publish Procedures 305 The publish procedure is implemented via Map-Notify messages that the 306 Map-Server sends to xTRs. The xTRs acknowledge the reception of Map- 307 Notifies via sending Map-Notify-Ack messages back to the Map-Server. 308 The complete mechanism works as follows. 310 When a mapping stored in a Map-Server is updated (e.g., via a Map- 311 Register from an ETR), the Map-Server MUST notify the subscribers of 312 that mapping via sending Map-Notify messages with the most updated 313 mapping information. The Map-Notify message sent to each of the 314 subscribers as a result of an update event MUST follow the exact 315 encoding and logic defined in [I-D.ietf-lisp-rfc6833bis] for Map- 316 Notify, except for the following: 318 (1) The Map-Notify MUST be sent to one of the ITR-RLOCs associated 319 with the xTR-ID of the subscriber. 321 (2) The Map-Server incrementes the nonce every time it sends a Map- 322 Notify as publication to an xTR-ID. The starting nonce is set 323 as follows, if the subscription state at the Map-Server was 324 created by a received Map-Request with the N-bit set, the 325 starting nonce in the Map-Notify sent as publication MUST be the 326 one used in the Map-Request that created the subscription state. 327 If the subscription state was created by explicit configuration 328 at the Map-Server, the starting nonce in the Map-Notify sent as 329 publication MUST be randomly generated by the Map-Server. 331 (3) The Map-Server MUST use its security association with the xTR to 332 compute the authentication data of the Map-Notify. 334 When the xTR receives a Map-Notify with an EID not local to the xTR, 335 the xTR knows that the Map-Notify has been received to update an 336 entry on its map-cache. Processing of unsolicited Map-Notify 337 messages MUST be explicitly enabled via configuration at the xTR. 338 The xTR keeps track of the last nonce seen in a Map-Notify received 339 as a publication from the Map-Server. If a Map-Notify received as a 340 publication has a nonce value that is not greater than the saved 341 nonce, the xTR drops the Map-Notify message and logs the fact a 342 replay attack could have occurred. The same considerations discussed 343 in [I-D.ietf-lisp-rfc6833bis] regarding storing Map-Register nonces 344 apply here for Map-Notify nonces. 346 The xTR processes the received Map-Notify as specified in 347 [I-D.ietf-lisp-rfc6833bis], with the following considerations. The 348 xTR MUST use its security association with the Map-Server (see 349 Section 3) to validate the authentication data on the Map-Notify. 350 The xTR MUST use the mapping information carried in the Map-Notify to 351 update its internal map-cache. The xTR MUST acknowledge the Map- 352 Notify by sending back a Map-Notify-Ack (specified in 353 [I-D.ietf-lisp-rfc6833bis]), with the nonce from the Map-Notify, to 354 the Map-Server. If after a configurable timeout, the Map-Server has 355 not received back the Map-Notify-Ack, it can try to send the Map- 356 Notify to a different ITR-RLOC for that xTR-ID. 358 7. Security Considerations 360 Generic security considerations related to LISP control messages are 361 discussed in [I-D.ietf-lisp-rfc6833bis]. 363 In the particular case of PubSub, cache poisoning via malicious Map- 364 Notify messages is avoided by the use of nonce and the security 365 association between the ITRs and the Map-Servers. Nevertheless, the 366 way to provide a security association between the ITRs and the Map- 367 Servers must be evaluated according to the size of the deployment. 368 For small deployments, it is possible to have a shared key (or set of 369 keys) between the ITRs and the Map-Servers. For larger and Internet- 370 scale deployments, scalability is a concern and further study is 371 needed. Such evaluation is one of the goals of this experimental 372 specification. 374 Misbehaving nodes may send massive subscription requests which may 375 lead to exhaust the resources of Map-Servers. Furthermore, 376 frequently changing the state of a subscription may also be 377 considered as an attack vector. To mitigate such issues, xTRs SHOULD 378 rate-limit Map-Requests and Map-Servers SHOULD rate-limit Map- 379 Notifies. Rate-limiting Map-Requests is discussed in 380 [I-D.ietf-lisp-rfc6833bis] and the same guidelines apply here. To 381 rate-limit Map-Notifies, a Map-Server MUST NOT send more than one 382 Map-Notify per second to a particular xTR-ID. This parameter MUST be 383 configurable. Note that when the Map-Notify rate-limit threshold is 384 met for a particular xTR-ID, the Map-Server will silently discard 385 additional subscription requests from that xTR-ID. Similarly, for 386 pending mapping updates that need to be notified to that xTR-ID, the 387 Map-Server will combine them into a single Map-Notify (with multiple 388 EID-records) which it will send when the rate-limit mechanism allows 389 it to transmit again Map-Notifies to that xTR-ID. 391 8. Acknowledgments 393 This work is partly funded by the ANR LISP-Lab project #ANR- 394 13-INFR-009 (https://www.lisp-lab.org). 396 9. IANA Considerations 398 This document is requesting bit allocations in the Map-Request 399 message from the "LISP Control Plane Header Bits" registry introduced 400 in [I-D.ietf-lisp-rfc6833bis]. In particular, this document requests 401 allocating the following two bits from the sub-registry "Map-Request 402 Header Bits". The position of these two bits in the Map-Request 403 message can be found in Figure 1. 405 +----------+---------------+-------------+--------------------------+ 406 | Spec | IANA Name | Bit | Description | 407 | Name | | Position | | 408 +----------+---------------+-------------+--------------------------+ 409 | I | map-request-I | 11 | xTR-ID Bit | 410 | N | map-request-N | ... + 0 | Notification-Requested | 411 | | | | Bit | 412 +----------+---------------+-------------+--------------------------+ 414 Table 1: Additions to the LISP Map-Request Header Bits Sub-Registry 416 10. Normative References 418 [I-D.ietf-lisp-rfc6833bis] 419 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 420 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 421 Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), 422 June 2019. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, 426 DOI 10.17487/RFC2119, March 1997, 427 . 429 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 430 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 431 May 2017, . 433 Authors' Addresses 435 Alberto Rodriguez-Natal 436 Cisco Systems 437 170 Tasman Drive 438 San Jose, CA 439 USA 441 Email: natal@cisco.com 442 Vina Ermagan 443 Google 444 USA 446 Email: ermagan@gmail.com 448 Johnson Leong 449 Cisco Systems 450 170 Tasman Drive 451 San Jose, CA 452 USA 454 Email: joleong@cisco.com 456 Fabio Maino 457 Cisco Systems 458 170 Tasman Drive 459 San Jose, CA 460 USA 462 Email: fmaino@cisco.com 464 Albert Cabellos-Aparicio 465 Technical University of Catalonia 466 Barcelona 467 Spain 469 Email: acabello@ac.upc.edu 471 Sharon Barkai 472 Nexar Inc. 474 Email: sharon.barkai@getnexar.com 476 Dino Farinacci 477 lispers.net 478 San Jose, CA 479 USA 481 Email: farinacci@gmail.com 482 Mohamed Boucadair 483 Orange 484 Rennes 35000 485 France 487 Email: mohamed.boucadair@orange.com 489 Christian Jacquenet 490 Orange 491 Rennes 35000 492 France 494 Email: christian.jacquenet@orange.com 496 Stefano Secci 497 Cnam 498 France 500 Email: stefano.secci@cnam.fr