idnits 2.17.1 draft-rodrigueznatal-lisp-ms-smr-13.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-lisp-pubsub], [I-D.ietf-lisp-RFC6833bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 October 2021) is 927 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-09 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-23 Summary: 1 error (**), 0 flaws (~~), 4 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: Informational A. Cabellos-Aparicio 5 Expires: 14 April 2022 Technical University of Catalonia 6 V. Ermagan 7 Google 8 F. Maino 9 Cisco Systems 10 S. Barkai 11 Nexar Inc. 12 11 October 2021 14 MS-originated SMRs 15 draft-rodrigueznatal-lisp-ms-smr-13 17 Abstract 19 This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers 20 to send SMR messages. 22 This extension is intended to be used in some SDN deployments that 23 use LISP as a southbound protocol with (P)ITRs that are compliant 24 with [I-D.ietf-lisp-rfc6833bis]. In this use-case mapping updates do 25 not come from ETRs, but rather from a centralized controller that 26 pushes the updates directly to the Mapping System. In such 27 deployments, Map Servers will benefit from having a mechanism to 28 inform directly (P)ITRs about updates in the mappings they are 29 serving. Although implementations of this extension exist, this 30 extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being 31 documented for informational purposes. Newer implementations should 32 look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP 33 deployments. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 14 April 2022. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Simplified BSD License text 62 as described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 69 2. Map Server extension . . . . . . . . . . . . . . . . . . . . 3 70 3. Interoperability with legacy (P)ITRs . . . . . . . . . . . . 4 71 4. Deployment considerations . . . . . . . . . . . . . . . . . . 4 72 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 77 8.2. Informative References . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 80 1. Introduction 82 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] 83 splits current IP addresses in two different namespaces, Endpoint 84 Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map- 85 and-encap approach that relies in two entities, the Mapping System 86 and the Tunnel Routers. The Tunnel Routers are deployed at LISP 87 sites edge points and perform encapsulation and decapsulation of LISP 88 data packets. The Mapping System is a distributed database that 89 stores and disseminates EID-RLOC bindings across different Map- 90 Servers. LISP Tunnel Routers keep a cache of EID-RLOC mappings 91 pulled from the Mapping System. 93 There are several ways to keep this cache updated as described in 94 [I-D.ietf-lisp-rfc6833bis]. Among them, the Solicit Map-Request 95 (SMR) message allows to explicitly signal (P)ITRs to let them know 96 that some of their cached mappings may be outdated. However, vanilla 97 LISP as described in [I-D.ietf-lisp-rfc6833bis] only considers SMR 98 messages to be sent by an ETR. This document extends 99 [I-D.ietf-lisp-rfc6833bis] to cover the case where SMRs can be sent 100 also by a Map Server (MS). 102 This document introduces changes in the MS specification allowing 103 them to send SMR messages, however it does not require any 104 modification in the (P)ITRs. This document is backwards compatible 105 and enables upgraded MSs to interoperate via SMRs with legacy (P)ITRs 106 that only implement [I-D.ietf-lisp-rfc6833bis]. 108 This document offers a basic form of Publish/Subscribe (PubSub) 109 compatible with legacy LISP devices. The LISP WG is currently 110 working on [I-D.ietf-lisp-pubsub] as the comprehensive mechanism to 111 enable PubSub in LISP which deprecates this document. Newer 112 implementations should look into [I-D.ietf-lisp-pubsub] to support 113 PubSub in LISP deployments. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 2. Map Server extension 123 This document enables MS to generate and send SMR messages towards 124 (P)ITRs. SMRs originated in a MS follow the same format described in 125 [I-D.ietf-lisp-rfc6833bis]. Besides the fact that they are sent from 126 a MS, there is no difference between an SMR originated in an ETR and 127 one originated in a MS. 129 A MS supporting the extension described in this document is supposed 130 to keep track of the Map-Requests received for the mappings it is 131 serving. When receiving a Map-Request, the MS should extract the 132 source EID and ITR-RLOCs from the message and keep them associated 133 with the requested mapping. The MS is expected to keep this state 134 for a period equal to the TTL of the mapping. When the mapping 135 changes, the MS should build and send an SMR to the (P)ITR that 136 requested the mapping using the stored EID and ITR-RLOCs, as 137 described below. 139 When a MS generates an SMR, it uses as source-EID the EID-prefix it 140 wants the (P)ITR to send the SMR-invoked Map-Request for (i.e. the 141 EID of the mapping that changed). The EID included in the EID-record 142 field is the one belonging to the (P)ITR the MS sends the SMR towards 143 and that was extracted from the original Map-Request. The 144 destination locator is one of the ITR-RLOCs associated with the EID 145 of the (P)ITR that were received in the Map-Request. As source 146 locator for the SMR message, the MS uses one of its available 147 locators. This has implications in the processing of the SMR at the 148 (P)ITR as described in Section 4 150 As specified in [I-D.ietf-lisp-rfc6833bis] and noted in Section 7, 151 SMRs MUST be rate-limited. It must be noted as well that, as 152 described in Section 3, a MS that sends an SMR may not necessarily 153 receive the SMR-invoked Map-Request that the (P)ITR generates as 154 response to the SMR. 156 3. Interoperability with legacy (P)ITRs 158 This document introduces no changes in the specification of (P)ITRs 159 and thus it is backwards compatible with legacy equipment only 160 compliant with [I-D.ietf-lisp-rfc6833bis]. However, since SMRs were 161 designed to be sent by ETRs, and legacy (P)ITRs expect to receive 162 SMRs only from ETRs, the implications of sending SMRs from a MS are 163 discussed in this section. 165 As indicated in Section 2, the MS generates the SMR message using one 166 of its locators as source locator. However, this locator will not be 167 present in the Locator-Set cached for that EID-prefix at the (P)ITR. 168 Following [I-D.ietf-lisp-rfc6833bis], upon receiving the SMR message, 169 the (P)ITR will check if the source locator is in the Locator-Set 170 cached for that EID-record. Since it is not, the (P)ITR will send 171 the SMR-invoked Map-Request always to the Mapping System and never to 172 the source locator of the SMR message. This means that a MS can not 173 force an SMR-invoked Map-Request to be sent directly towards itself. 174 However, it is possible that the Mapping System in use is 175 instantiated (even partially) by the MS originator of the SMR. In 176 that case, it may be that the SMR-invoked Map Request will eventually 177 reach the MS, either directly or after being internally forwarded 178 through the Mapping System. 180 4. Deployment considerations 182 The extension defined in this document may be useful in scenarios 183 where the MS wants to signal (P)ITRs about changes on mappings it is 184 serving. For instance, when the MS is keeping track of the (P)ITRs 185 that are requesting its mappings and wants to inform them 186 intermediately whenever a mapping is updated. 188 SDN deployments that use LISP as a southbound protocol are 189 particularly suitable to take advantage of this extension. On the 190 SDN scenario, mapping updates will unlikely come from ETRs, but 191 rather from a centralized entity that pushes the updates directly to 192 the Mapping System. In such deployments, Map Servers will benefit 193 from having a mechanism to inform directly (P)ITRs about updates in 194 the mappings they are serving. 196 Due to scalability and security concerns, it is RECOMMENDED that this 197 extension is only applied in intra-domain scenarios where all LISP 198 devices are within a single administrative domain. 200 To limit the impact of the extension and to ease its integration with 201 the rest of LISP signaling and operation, it is RECOMMENDED that the 202 MS only sends SMR messages for those mappings it is proxy-replying 203 for. 205 5. Acknowledgments 207 The authors would like to thank Joel Halpern and Luigi Iannone for 208 their guidance regarding this document. 210 6. IANA Considerations 212 This memo includes no request to IANA. 214 7. Security Considerations 216 As described in [I-D.ietf-lisp-rfc6833bis], the SMR messages and the 217 SMR-invoked Map-Request MUST be rate-limited. This does not change 218 with the extension proposed in this document. 220 The (P)ITRs receiving SMRs from the MS will send Map-Request messages 221 to the Mapping System to retrieve authoritative mappings. It is 222 RECOMMENDED that the security mechanism described in 223 [I-D.ietf-lisp-sec] and [RFC8111] are in place to secure the mapping 224 retrieval and protect against unsolicited messages or hijacking 225 attacks. 227 8. References 229 8.1. Normative References 231 [I-D.ietf-lisp-rfc6833bis] 232 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 233 "Locator/ID Separation Protocol (LISP) Control-Plane", 234 Work in Progress, Internet-Draft, draft-ietf-lisp- 235 rfc6833bis-30, 18 November 2020, 236 . 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, 241 DOI 10.17487/RFC2119, March 1997, 242 . 244 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 245 Smirnov, "Locator/ID Separation Protocol Delegated 246 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 247 May 2017, . 249 8.2. Informative References 251 [I-D.ietf-lisp-pubsub] 252 Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, 253 S., and M. Boucadair, "Publish/Subscribe Functionality for 254 LISP", Work in Progress, Internet-Draft, draft-ietf-lisp- 255 pubsub-09, 28 June 2021, . 258 [I-D.ietf-lisp-sec] 259 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 260 "LISP-Security (LISP-SEC)", Work in Progress, Internet- 261 Draft, draft-ietf-lisp-sec-23, 22 September 2021, 262 . 265 Authors' Addresses 267 Alberto Rodriguez-Natal 268 Cisco Systems 269 170 Tasman Drive 270 San Jose, CA 271 United States of America 273 Email: natal@cisco.com 274 Albert Cabellos-Aparicio 275 Technical University of Catalonia 276 Barcelona 277 Spain 279 Email: acabello@ac.upc.edu 281 Vina Ermagan 282 Google 283 United States of America 285 Email: ermagan@gmail.com 287 Fabio Maino 288 Cisco Systems 289 170 Tasman Drive 290 San Jose, CA 291 United States of America 293 Email: fmaino@cisco.com 295 Sharon Barkai 296 Nexar Inc. 297 CA 298 United States of America 300 Email: sharon.barkai@getnexar.com