idnits 2.17.1 draft-rodrigueznatal-lisp-ms-smr-07.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 1, 2018) is 2024 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-15 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-pubsub-00 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-15 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 4, 2019 Technical University of Catalonia 6 V. Ermagan 7 F. Maino 8 Cisco Systems 9 S. Barkai 10 Fermi Serverless 11 October 1, 2018 13 MS-originated SMRs 14 draft-rodrigueznatal-lisp-ms-smr-07 16 Abstract 18 This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers 19 to send SMR messages. 21 This extension is intended to be used in some SDN deployments that 22 use LISP as a southbound protocol with (P)ITRs that are compliant 23 with [I-D.ietf-lisp-rfc6833bis]. In this use-case mapping updates do 24 not come from ETRs, but rather from a centralized controller that 25 pushes the updates directly to the Mapping System. In such 26 deployments, Map Servers will benefit from having a mechanism to 27 inform directly (P)ITRs about updates in the mappings they are 28 serving. Although implementations of this extension exist, this 29 extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being 30 documented for informational purposes. Newer implementations should 31 look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP 32 deployments. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 4, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 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 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 233 "Locator/ID Separation Protocol (LISP) Control-Plane", 234 draft-ietf-lisp-rfc6833bis-15 (work in progress), 235 September 2018. 237 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 238 Requirement Levels", BCP 14, RFC 2119, 239 DOI 10.17487/RFC2119, March 1997, 240 . 242 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 243 Smirnov, "Locator/ID Separation Protocol Delegated 244 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 245 May 2017, . 247 8.2. Informative References 249 [I-D.ietf-lisp-pubsub] 250 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 251 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 252 Boucadair, M., Jacquenet, C., and S. Secci, "Publish/ 253 Subscribe Functionality for LISP", draft-ietf-lisp- 254 pubsub-00 (work in progress), April 2018. 256 [I-D.ietf-lisp-sec] 257 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 258 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-15 259 (work in progress), April 2018. 261 Authors' Addresses 263 Alberto Rodriguez-Natal 264 Cisco Systems 265 170 Tasman Drive 266 San Jose, CA 267 USA 269 Email: natal@cisco.com 271 Albert Cabellos-Aparicio 272 Technical University of Catalonia 273 Barcelona 274 Spain 276 Email: acabello@ac.upc.edu 277 Vina Ermagan 278 Cisco Systems 279 170 Tasman Drive 280 San Jose, CA 281 USA 283 Email: vermagan@cisco.com 285 Fabio Maino 286 Cisco Systems 287 170 Tasman Drive 288 San Jose, CA 289 USA 291 Email: fmaino@cisco.com 293 Sharon Barkai 294 Fermi Serverless 295 CA 296 USA 298 Email: sharon@fermicloud.io