idnits 2.17.1 draft-rodrigueznatal-lisp-ms-smr-09.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 (October 7, 2019) is 1660 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-25 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-04 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-19 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: April 9, 2020 Technical University of Catalonia 6 V. Ermagan 7 Google 8 F. Maino 9 Cisco Systems 10 S. Barkai 11 Nexar Inc. 12 October 7, 2019 14 MS-originated SMRs 15 draft-rodrigueznatal-lisp-ms-smr-09 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 April 9, 2020. 51 Copyright Notice 53 Copyright (c) 2019 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 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 70 2. Map Server extension . . . . . . . . . . . . . . . . . . . . 3 71 3. Interoperability with legacy (P)ITRs . . . . . . . . . . . . 4 72 4. Deployment considerations . . . . . . . . . . . . . . . . . . 4 73 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 78 8.2. Informative References . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6833bis] 84 splits current IP addresses in two different namespaces, Endpoint 85 Identifiers (EIDs) and Routing Locators (RLOCs). LISP uses a map- 86 and-encap approach that relies in two entities, the Mapping System 87 and the Tunnel Routers. The Tunnel Routers are deployed at LISP 88 sites edge points and perform encapsulation and decapsulation of LISP 89 data packets. The Mapping System is a distributed database that 90 stores and disseminates EID-RLOC bindings across different Map- 91 Servers. LISP Tunnel Routers keep a cache of EID-RLOC mappings 92 pulled from the Mapping System. 94 There are several ways to keep this cache updated as described in 95 [I-D.ietf-lisp-rfc6833bis]. Among them, the Solicit Map-Request 96 (SMR) message allows to explicitly signal (P)ITRs to let them know 97 that some of their cached mappings may be outdated. However, vanilla 98 LISP as described in [I-D.ietf-lisp-rfc6833bis] only considers SMR 99 messages to be sent by an ETR. This document extends 100 [I-D.ietf-lisp-rfc6833bis] to cover the case where SMRs can be sent 101 also by a Map Server (MS). 103 This document introduces changes in the MS specification allowing 104 them to send SMR messages, however it does not require any 105 modification in the (P)ITRs. This document is backwards compatible 106 and enables upgraded MSs to interoperate via SMRs with legacy (P)ITRs 107 that only implement [I-D.ietf-lisp-rfc6833bis]. 109 This document offers a basic form of Publish/Subscribe (PubSub) 110 compatible with legacy LISP devices. The LISP WG is currently 111 working on [I-D.ietf-lisp-pubsub] as the comprehensive mechanism to 112 enable PubSub in LISP which deprecates this document. Newer 113 implementations should look into [I-D.ietf-lisp-pubsub] to support 114 PubSub in LISP deployments. 116 1.1. Requirements Language 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 2. Map Server extension 124 This document enables MS to generate and send SMR messages towards 125 (P)ITRs. SMRs originated in a MS follow the same format described in 126 [I-D.ietf-lisp-rfc6833bis]. Besides the fact that they are sent from 127 a MS, there is no difference between an SMR originated in an ETR and 128 one originated in a MS. 130 A MS supporting the extension described in this document is supposed 131 to keep track of the Map-Requests received for the mappings it is 132 serving. When receiving a Map-Request, the MS should extract the 133 source EID and ITR-RLOCs from the message and keep them associated 134 with the requested mapping. The MS is expected to keep this state 135 for a period equal to the TTL of the mapping. When the mapping 136 changes, the MS should build and send an SMR to the (P)ITR that 137 requested the mapping using the stored EID and ITR-RLOCs, as 138 described below. 140 When a MS generates an SMR, it uses as source-EID the EID-prefix it 141 wants the (P)ITR to send the SMR-invoked Map-Request for (i.e. the 142 EID of the mapping that changed). The EID included in the EID-record 143 field is the one belonging to the (P)ITR the MS sends the SMR towards 144 and that was extracted from the original Map-Request. The 145 destination locator is one of the ITR-RLOCs associated with the EID 146 of the (P)ITR that were received in the Map-Request. As source 147 locator for the SMR message, the MS uses one of its available 148 locators. This has implications in the processing of the SMR at the 149 (P)ITR as described in Section 4 151 As specified in [I-D.ietf-lisp-rfc6833bis] and noted in Section 7, 152 SMRs MUST be rate-limited. It must be noted as well that, as 153 described in Section 3, a MS that sends an SMR may not necessarily 154 receive the SMR-invoked Map-Request that the (P)ITR generates as 155 response to the SMR. 157 3. Interoperability with legacy (P)ITRs 159 This document introduces no changes in the specification of (P)ITRs 160 and thus it is backwards compatible with legacy equipment only 161 compliant with [I-D.ietf-lisp-rfc6833bis]. However, since SMRs were 162 designed to be sent by ETRs, and legacy (P)ITRs expect to receive 163 SMRs only from ETRs, the implications of sending SMRs from a MS are 164 discussed in this section. 166 As indicated in Section 2, the MS generates the SMR message using one 167 of its locators as source locator. However, this locator will not be 168 present in the Locator-Set cached for that EID-prefix at the (P)ITR. 169 Following [I-D.ietf-lisp-rfc6833bis], upon receiving the SMR message, 170 the (P)ITR will check if the source locator is in the Locator-Set 171 cached for that EID-record. Since it is not, the (P)ITR will send 172 the SMR-invoked Map-Request always to the Mapping System and never to 173 the source locator of the SMR message. This means that a MS can not 174 force an SMR-invoked Map-Request to be sent directly towards itself. 175 However, it is possible that the Mapping System in use is 176 instantiated (even partially) by the MS originator of the SMR. In 177 that case, it may be that the SMR-invoked Map Request will eventually 178 reach the MS, either directly or after being internally forwarded 179 through the Mapping System. 181 4. Deployment considerations 183 The extension defined in this document may be useful in scenarios 184 where the MS wants to signal (P)ITRs about changes on mappings it is 185 serving. For instance, when the MS is keeping track of the (P)ITRs 186 that are requesting its mappings and wants to inform them 187 intermediately whenever a mapping is updated. 189 SDN deployments that use LISP as a southbound protocol are 190 particularly suitable to take advantage of this extension. On the 191 SDN scenario, mapping updates will unlikely come from ETRs, but 192 rather from a centralized entity that pushes the updates directly to 193 the Mapping System. In such deployments, Map Servers will benefit 194 from having a mechanism to inform directly (P)ITRs about updates in 195 the mappings they are serving. 197 Due to scalability and security concerns, it is RECOMMENDED that this 198 extension is only applied in intra-domain scenarios where all LISP 199 devices are within a single administrative domain. 201 To limit the impact of the extension and to ease its integration with 202 the rest of LISP signaling and operation, it is RECOMMENDED that the 203 MS only sends SMR messages for those mappings it is proxy-replying 204 for. 206 5. Acknowledgments 208 The authors would like to thank Joel Halpern and Luigi Iannone for 209 their guidance regarding this document. 211 6. IANA Considerations 213 This memo includes no request to IANA. 215 7. Security Considerations 217 As described in [I-D.ietf-lisp-rfc6833bis], the SMR messages and the 218 SMR-invoked Map-Request MUST be rate-limited. This does not change 219 with the extension proposed in this document. 221 The (P)ITRs receiving SMRs from the MS will send Map-Request messages 222 to the Mapping System to retrieve authoritative mappings. It is 223 RECOMMENDED that the security mechanism described in 224 [I-D.ietf-lisp-sec] and [RFC8111] are in place to secure the mapping 225 retrieval and protect against unsolicited messages or hijacking 226 attacks. 228 8. References 230 8.1. Normative References 232 [I-D.ietf-lisp-rfc6833bis] 233 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- 234 Aparicio, "Locator/ID Separation Protocol (LISP) Control- 235 Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), 236 June 2019. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, 240 DOI 10.17487/RFC2119, March 1997, 241 . 243 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 244 Smirnov, "Locator/ID Separation Protocol Delegated 245 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 246 May 2017, . 248 8.2. Informative References 250 [I-D.ietf-lisp-pubsub] 251 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 252 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 253 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 254 Subscribe Functionality for LISP", draft-ietf-lisp- 255 pubsub-04 (work in progress), September 2019. 257 [I-D.ietf-lisp-sec] 258 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 259 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-19 260 (work in progress), July 2019. 262 Authors' Addresses 264 Alberto Rodriguez-Natal 265 Cisco Systems 266 170 Tasman Drive 267 San Jose, CA 268 USA 270 Email: natal@cisco.com 272 Albert Cabellos-Aparicio 273 Technical University of Catalonia 274 Barcelona 275 Spain 277 Email: acabello@ac.upc.edu 279 Vina Ermagan 280 Google 281 USA 283 Email: ermagan@gmail.com 284 Fabio Maino 285 Cisco Systems 286 170 Tasman Drive 287 San Jose, CA 288 USA 290 Email: fmaino@cisco.com 292 Sharon Barkai 293 Nexar Inc. 294 CA 295 USA 297 Email: sharon.barkai@getnexar.com