idnits 2.17.1 draft-rodrigueznatal-lisp-ms-smr-06.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 ([RFC6830], [I-D.rodrigueznatal-lisp-pubsub]), 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 (April 4, 2018) is 2186 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-14 Summary: 2 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: Informational A. Cabellos-Aparicio 5 Expires: October 6, 2018 Technical University of Catalonia 6 V. Ermagan 7 F. Maino 8 Cisco Systems 9 S. Barkai 10 Fermi Serverless 11 April 4, 2018 13 MS-originated SMRs 14 draft-rodrigueznatal-lisp-ms-smr-06 16 Abstract 18 This document extends [RFC6830] to allow Map Servers to send SMR 19 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 [RFC6830]. In this use-case mapping updates do not come from 24 ETRs, but rather from a centralized controller that pushes the 25 updates directly to the Mapping System. In such deployments, Map 26 Servers will benefit from having a mechanism to inform directly 27 (P)ITRs about updates in the mappings they are serving. Although 28 implementations of this extension exist, this extension is deprecated 29 by [I-D.rodrigueznatal-lisp-pubsub] and it is being documented for 30 informational purposes. Newer implementations should look into 31 [I-D.rodrigueznatal-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 October 6, 2018. 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) [RFC6830] splits current IP 83 addresses in two different namespaces, Endpoint Identifiers (EIDs) 84 and Routing Locators (RLOCs). LISP uses a map-and-encap approach 85 that relies in two entities, the Mapping System and the Tunnel 86 Routers. The Tunnel Routers are deployed at LISP sites edge points 87 and perform encapsulation and decapsulation of LISP data packets. 88 The Mapping System is a distributed database that stores and 89 disseminates EID-RLOC bindings across different Map-Servers. LISP 90 Tunnel Routers keep a cache of EID-RLOC mappings pulled from the 91 Mapping System. 93 There are several ways to keep this cache updated as described in 94 [RFC6830]. Among them, the Solicit Map-Request (SMR) message allows 95 to explicitly signal (P)ITRs to let them know that some of their 96 cached mappings may be outdated. However, vanilla LISP as described 97 in [RFC6830] only considers SMR messages to be sent by an ETR. This 98 document extends [RFC6830] to cover the case where SMRs can be sent 99 also by a Map Server (MS). 101 This document introduces changes in the MS specification allowing 102 them to send SMR messages, however it does not require any 103 modification in the (P)ITRs. This document is backwards compatible 104 and enables upgraded MSs to interoperate via SMRs with legacy (P)ITRs 105 that only implement [RFC6830]. 107 This document offers a basic form of Publish/Subscribe (PubSub) 108 compatible with legacy LISP devices. The LISP WG is currently 109 working on [I-D.rodrigueznatal-lisp-pubsub] as the comprehensive 110 mechanism to enable PubSub in LISP which deprecates this document. 111 Newer implementations should look into 112 [I-D.rodrigueznatal-lisp-pubsub] to support PubSub in LISP 113 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 [RFC6830]. Besides the fact that they are sent from a MS, there is 126 no difference between an SMR originated in an ETR and one originated 127 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 [RFC6830] and noted in Section 7, SMRs MUST be rate- 151 limited. It must be noted as well that, as described in Section 3, a 152 MS that sends an SMR may not necessarily receive the SMR-invoked Map- 153 Request that the (P)ITR generates as response to the SMR. 155 3. Interoperability with legacy (P)ITRs 157 This document introduces no changes in the specification of (P)ITRs 158 and thus it is backwards compatible with legacy equipment only 159 compliant with [RFC6830]. However, since SMRs were designed to be 160 sent by ETRs, and legacy (P)ITRs expect to receive SMRs only from 161 ETRs, the implications of sending SMRs from a MS are discussed in 162 this section. 164 As indicated in Section 2, the MS generates the SMR message using one 165 of its locators as source locator. However, this locator will not be 166 present in the Locator-Set cached for that EID-prefix at the (P)ITR. 167 Following [RFC6830], upon receiving the SMR message, the (P)ITR will 168 check if the source locator is in the Locator-Set cached for that 169 EID-record. Since it is not, the (P)ITR will send the SMR-invoked 170 Map-Request always to the Mapping System and never to the source 171 locator of the SMR message. This means that a MS can not force an 172 SMR-invoked Map-Request to be sent directly towards itself. However, 173 it is possible that the Mapping System in use is instantiated (even 174 partially) by the MS originator of the SMR. In that case, it may be 175 that the SMR-invoked Map Request will eventually reach the MS, either 176 directly or after being internally forwarded through the Mapping 177 System. 179 4. Deployment considerations 181 The extension defined in this document may be useful in scenarios 182 where the MS wants to signal (P)ITRs about changes on mappings it is 183 serving. For instance, when the MS is keeping track of the (P)ITRs 184 that are requesting its mappings and wants to inform them 185 intermediately whenever a mapping is updated. 187 SDN deployments that use LISP as a southbound protocol are 188 particularly suitable to take advantage of this extension. On the 189 SDN scenario, mapping updates will unlikely come from ETRs, but 190 rather from a centralized entity that pushes the updates directly to 191 the Mapping System. In such deployments, Map Servers will benefit 192 from having a mechanism to inform directly (P)ITRs about updates in 193 the mappings they are serving. 195 Due to scalability and security concerns, it is RECOMMENDED that this 196 extension is only applied in intra-domain scenarios where all LISP 197 devices are within a single administrative domain. 199 To limit the impact of the extension and to ease its integration with 200 the rest of LISP signaling and operation, it is RECOMMENDED that the 201 MS only sends SMR messages for those mappings it is proxy-replying 202 for. 204 5. Acknowledgments 206 The authors would like to thank Joel Halpern and Luigi Iannone for 207 their guidance regarding this document. 209 6. IANA Considerations 211 This memo includes no request to IANA. 213 7. Security Considerations 215 As described in [RFC6830], the SMR messages and the SMR-invoked Map- 216 Request MUST be rate-limited. This does not change with the 217 extension proposed in this document. 219 The (P)ITRs receiving SMRs from the MS will send Map-Request messages 220 to the Mapping System to retrieve authoritative mappings. It is 221 RECOMMENDED that the security mechanism described in 222 [I-D.ietf-lisp-sec] and [RFC8111] are in place to secure the mapping 223 retrieval and protect against unsolicited messages or hijacking 224 attacks. 226 8. References 228 8.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 236 Locator/ID Separation Protocol (LISP)", RFC 6830, 237 DOI 10.17487/RFC6830, January 2013, 238 . 240 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 241 Smirnov, "Locator/ID Separation Protocol Delegated 242 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 243 May 2017, . 245 8.2. Informative References 247 [I-D.ietf-lisp-sec] 248 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 249 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-14 250 (work in progress), October 2017. 252 [I-D.rodrigueznatal-lisp-pubsub] 253 Rodriguez-Natal, A., Ermagan, V., Leong, J., Maino, F., 254 Cabellos-Aparicio, A., Barkai, S., Farinacci, D., 255 Boucadair, M., Jacquenet, C., and s. 256 stefano.secci@lip6.fr, "Publish/Subscribe Functionality 257 for LISP", draft-rodrigueznatal-lisp-pubsub-02 (work in 258 progress), March 2018. 260 Authors' Addresses 262 Alberto Rodriguez-Natal 263 Cisco Systems 264 170 Tasman Drive 265 San Jose, CA 266 USA 268 Email: natal@cisco.com 270 Albert Cabellos-Aparicio 271 Technical University of Catalonia 272 Barcelona 273 Spain 275 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 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 Fermi Serverless 294 CA 295 USA 297 Email: sharon@fermicloud.io