idnits 2.17.1 draft-boucadair-lisp-ms-assisted-forwarding-00.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 255 has weird spacing: '...LOC_itr dst=...' == Line 256 has weird spacing: '...RLOC_ms dst=...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: * Also, the Mapping System provides a leaf LISP network with the appropriate RLOC (referred to as MS_RLOC) so that it can use the MS-assisted forwarding feature. * MS_RLOC may be identical or distinct from the locator assigned to one of the Map-Resolvers that can be solicited by the leaf LISP network. 2 ITRs MUST support a configuration parameter to enable/disable this procedure. The default value of this parameter is "Disabled". 3 ITRs MAY be configured with a dedicated RLOC for this feature. This RLOC MAY NOT be the same locator as the one used to contact a Map-Resolver. If no dedicated RLOC is explicitly configured on an ITR for which the MS-assisted forwarding procedure is enabled, the ITR MUST use the locator of its Map-Resolver (i.e., MS_RLOC=ITR_Locator). 4 When an ITR receives a packet to be forwarded outside a given LISP domain, it MUST proceed to a lookup of the local mapping cache to check whether an entry matches this packet. -- The document date (September 17, 2015) is 3143 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-10 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Experimental France Telecom 5 Expires: March 20, 2016 September 17, 2015 7 Mapping System-Assisted Forwarding for Inter-Domain LISP Deployments 8 draft-boucadair-lisp-ms-assisted-forwarding-00 10 Abstract 12 One of the issues with current LISP operation is that some packets 13 are likely to be lost when there is no matching mapping entry 14 maintained by the Ingress Tunnel Router (ITR). This document 15 proposes a solution to address this issue with a particular focus on 16 LISP deployments at large scale. 18 This document introduces the concept of Implicit Map-Request and 19 Unsolicited Map-Reply messages. Also, it describes a solution to 20 disable data gleaning for a given flow at the upstream Egress Tunnel 21 Router (ETR). 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [RFC2119]. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 20, 2016. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Disable Data Gleaning . . . . . . . . . . . . . . . . . . . . 6 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative references . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative references . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Locator/ID Separation Protocol (LISP, [RFC6830] ) operation relies 77 upon a mapping mechanism that is used by ingress/egress Tunnel 78 Routers (xTR) to forward traffic over the LISP network. It is 79 commonly acknowledged that some packets are likely to be lost in some 80 specific situations, such as the absence of a mapping entry in the 81 mapping cache maintained by an ITR. This phenomenon is usually 82 denoted as the "first packet loss" issue. 84 This document suggests a solution that relies upon the assistance of 85 the Mapping System for the forwarding of the first packet(s) of a 86 flow, while corresponding mapping resolution is in progress. 88 Deploying LISP at the scale of the Internet heavility relies upon the 89 reliability of the LISP Mapping service. In particular, LISP 90 deployments at large scale must not degrade the level of quality as 91 currently provided by several decades of inter-domain routing 92 practices. 94 This document makes the following assumptions: 96 o Various LISP players (network operators, service providers, etc.) 97 are likely to deploy and operate LISP Mapping Systems. Multiple 98 Mapping Systems will therefore coexist for various reasons, e.g., 99 avoid country-centric governance, allow for distinct technologies 100 to implement the mapping service, business opportunities, service 101 innovation, etc. 102 o Interconnection between these Mapping Systems is required for the 103 sake of global connectivity and also to minimize the risk of 104 fragmenting the Internet. 105 o The entries of the mapping tables are exchanged between these 106 Mapping systems so that Map-Request messages can be processed as 107 close to the LISP leaf networks as possible. 108 o A leaf LISP-enabled network subscribes to the Mapping Service 109 provided by one or several Mapping Service operators. 110 o The contribution of each player involved in the provisioning and 111 the operation of a LISP-based connectivity forwarding service 112 should be rationalized so that clear interfaces are defined and 113 adequate mechanisms for troubleshooting, diagnosis and repair 114 purposes can be easily implemented and adopted. The inability of 115 identifying what is at the origin of the degradation of a LISP 116 connectivity service is seen as one of the hurdles that are likely 117 to jeopardize LISP deployments at large scale. 118 o ITRs are configured with a list of one or more Map-Resolvers 119 locators. Whether the provisioning of MR-related information to 120 ITRs is achieved using a configuration interface or a specific 121 discovery mechanism is out of scope of this document. 122 o Like [RFC6830], this document does not make any assumption of the 123 Mapping Service other than it supports the primitives defined in 124 [RFC6833]. 126 This document focuses on the sole LISP inter-domain use case. As 127 such, it is out of scope of this document to discuss the 128 applicability of the proposed solution to other LISP use cases (e.g., 129 LISP-based data center networking) . 131 Within this document, "Unsolicited Map-Reply" is used to refer to a 132 Map-Reply that is not associated with an (explicit) Map-Request 133 message. An unsolicited Map-Reply is sent to an ITR without 134 receiving a Map-Request from that ITR. 136 2. Proposed Solution 138 The rationale adopted by this document is that, instead of dropping 139 packets that do not match an existing mapping entry in a local cache 140 maintained by an ITR, these packets are used as Implicit Map- 141 Requests. In particular, the LISP-based forwarding of the first 142 packet(s) can be delegated to the Mapping System (MS) that is 143 supposed to maintain the required information to process the packet 144 (preferably close to the LISP leaf network or at least without 145 inducing severe path stretch). This mode is called MS-assisted LISP 146 forwarding. 148 Although this feature can be supported by an upstream transit 149 provider, this document focuses on the deployment of the MS-assisted 150 LISP forwarding solution at the Mapping System side. 152 The detailed procedure that aims at minimizing the risk of the 153 aforementioned "first packet loss" issue is specified hereafter (see 154 Figure 1 for a typical flow example): 156 1 The Mapping System is configured with a list of networks that are 157 allowed to invoke the MS-assisted forwarding service. The 158 corresponding authorization procedure may rely upon the service 159 subscription procedure itself (using static or dynamic means such 160 as [I-D.boucadair-connectivity-provisioning-protocol]). 162 * Also, the Mapping System provides a leaf LISP network with the 163 appropriate RLOC (referred to as MS_RLOC) so that it can use 164 the MS-assisted forwarding feature. 165 * MS_RLOC may be identical or distinct from the locator assigned 166 to one of the Map-Resolvers that can be solicited by the leaf 167 LISP network. 168 2 ITRs MUST support a configuration parameter to enable/disable this 169 procedure. The default value of this parameter is "Disabled". 170 3 ITRs MAY be configured with a dedicated RLOC for this feature. 171 This RLOC MAY NOT be the same locator as the one used to contact a 172 Map-Resolver. If no dedicated RLOC is explicitly configured on an 173 ITR for which the MS-assisted forwarding procedure is enabled, the 174 ITR MUST use the locator of its Map-Resolver (i.e., 175 MS_RLOC=ITR_Locator). 176 4 When an ITR receives a packet to be forwarded outside a given LISP 177 domain, it MUST proceed to a lookup of the local mapping cache to 178 check whether an entry matches this packet. 180 4.1 If a mapping entry is found, the ITR MUST proceed as in 181 [RFC6830]. 182 4.2 If no mapping entry is found and the MS-assisted forwarding 183 feature is enabled, the ITR MUST use the MS_RLOC to forward 184 the packet. That is, the origin packet is forwarded using a 185 LISP encapsulation header; the destination IP address of the 186 outer header is set to MS_RLOC (instead of the remote ETR's 187 RLOC associated with the destination EID). 189 4.2.1 The ITR MUST set the nonce-present and echo-nonce- 190 request bits. 191 4.2.2 Once forwarded, the ITR MUST listen, using port 4343, 192 to Unsolicited Map-Reply messages that will be 193 received from the Map-Resolver. 194 4.2.3 The ITR MUST follow the same behavior for packets that 195 belong to the same flow until a mapping is retrieved 196 from the Mapping System side. The packet will be used 197 as an "implicit Map-Request" from a downstream ITR. 198 5 Upon receipt of the encapsulated packet, the Mapping System: 200 5.1 MUST extract the destination EID and proceed to the lookup in 201 its global mapping table to retrieve the corresponding entry. 202 If a mapping entry is found, it MUST rewrite the source RLOC 203 to be set to the destination RLOC of the encapsulated packet 204 received from the leaf LISP network and the destination RLOC 205 to the RLOC retrieved from the mapping table. Then, the 206 packet is forwarded to the next hop. 208 5.1.1 Using the initial source RLOC to forward the packet 209 might be tempting, but this behavior is discouraged as 210 upstream networks implementing ingress filtering may 211 consider this packet as a spoofing attack. 212 5.1.2 The Mapping System may decide to reset the nonce- 213 present and echo-nonce-request bits. The setting of 214 these bits can be part of the service agreement 215 contracted between the leaf LISP network and the 216 Mapping Service provider. 217 5.1.3 Because upstream ETRs may use the outer LISP header if 218 it implemented information "gleaning", the LISP packet 219 may provide an explicit indication to the ETR to not 220 rely upon the outer header to create a "gleaned" Map- 221 Cache entry but rather proceed with an explicit Map- 222 Request. instead Section 3 proposes a solution for 223 carrying such indication in the LISP header. 224 5.2 In the meantime, an unsolicited Map-Reply message that 225 carries records associated with the destination EID, MUST be 226 sent to the ITR so that it can handle the packets locally 227 without any assistance from the Mapping System. 229 5.2.1 The Map-Reply message MUST use the same Nonce that was 230 included in the LISP-encapsulated packet received from 231 the downstream ITR. 232 5.2.2 A timer (or a maximum number of the packets) MAY be 233 used so that the assistance mode is deactivated at the 234 Mapping System side for this leaf LISP network/EID. 235 Discarding subsequent packets and associated settings 236 are deployment-specific. It is out of scope of this 237 document to elaborate on such design considerations. 238 6 Upon receipt of the Unsolicited Map-Reply message, the ITR MUST 239 proceed to Nonce validation checks. 241 6.1 If no error is found, it MUST retrieve the record carried in 242 the Map-Reply message. 243 6.2 The ITR MUST stop using the MS-assisted mode (i.e., for 244 forthcoming packets matching this mapping entry). 245 7 Subsequent packets that belong to the same flow are handled 246 locally (i.e., normal LISP operation is in progress). 248 +-------+ 249 |Mapping| 250 +--------+ |System | +--------+ 251 | ITR | +-------+ | ETR | 252 +--------+ | +--------+ 253 | | | 254 src=s_EID| | | 255 -------->|src=RLOC_itr dst=RLOC_ms| | 256 dst=d_EID|===Encapsulated Packet===>|src=RLOC_ms dst=RLOC_etr| 257 | Unsolicited Map-Reply |===Encapsulated Packet===>| 258 |<-------------------------| | 259 | | 260 src=s_EID| | 261 -------->|src=RLOC_itr dst=RLOC_etr|src=s_EID 262 dst=d_EID|===================Encapsulated Packet==============>|--------> 263 | |dst=d_EID 264 .... 265 src=s_EID| | 266 -------->|src=RLOC_itr dst=RLOC_etr|src=s_EID 267 dst=d_EID|===================Encapsulated Packet==============>|--------> 268 | |dst=d_EID 270 Figure 1: Flow Example 272 3. Disable Data Gleaning 274 [RFC6830] indicates the following: 276 Section 4: "In order to defer the need for a mapping lookup in the 277 reverse direction, an ETR MAY create a cache entry that maps the 278 source EID (inner-header source IP address) to the source RLOC 279 (outer-header source IP address) in a received LISP packet. Such 280 a cache entry is termed a "gleaned" mapping and only contains a 281 single RLOC for the EID in question." 282 Section 6.2: "Either side (more likely the server-side ETR) 283 decides not to send a Map-Request. For example, if the server- 284 side ETR does not send Map-Requests, it gleans RLOCs from the 285 client-side ITR, giving the client-side ITR responsibility for 286 bidirectional RLOC reachability and preferability. Server-side 287 ETR gleaning of the client-side ITR RLOC is done by caching the 288 inner-header source EID and the outer-header source RLOC of 289 received packets. The client-side ITR controls how traffic is 290 returned and can alternate using an outer- header source RLOC, 291 which then can be added to the list the server-side ETR uses to 292 return traffic. Since no Priority or Weights are provided using 293 this method, the server-side ETR MUST assume that each client-side 294 ITR RLOC uses the same best Priority with a Weight of zero. In 295 addition, since EID-Prefix encoding cannot be conveyed in data 296 packets, the EID-to-RLOC Cache on Tunnel Routers can grow to be 297 very large." 299 But the LISP specification does not describe any means for an ITR to 300 explicitly inform an ETR that it MUST NOT rely upon the data gleaning 301 but, instead, privilege the sending of an explicit Map-request. 303 For the particular case covered in this document, the lack of such 304 capability may lead to the involvement of an intermediate node for 305 both traffic directions. This behavior may not be suitable in some 306 deployment situations (e.g., mis-use the relay in the MS domain to 307 forward traffic, abuse, denial-of-service, etc.). In order to solve 308 this issue, this document proposes to associate a meaning with one of 309 the reserved flag bits (see Section 5.3 of [RFC6830]) to explicitly 310 indicate that, when this bit is set, data gleaning must be 311 deactivated. This bit is called the G-bit ("Gleaning" flag bit). 313 Figure 2 shows the required change to the LISP header. 315 OLD: 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 L |N|L|E|V|I|flags| Nonce/Map-Version | 318 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 S / | Instance ID/Locator-Status-Bits | 320 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 NEW: 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 L |N|L|E|V|I|G|flg| Nonce/Map-Version | 325 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 S / | Instance ID/Locator-Status-Bits | 327 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 2: G-bit in the LISP Header 331 The "flg" bits are reserved bits for future assignment as additional 332 flag bits. These additional flag bits MUST each be set to zero and 333 MUST be ignored upon receipt. 335 The description of the remaining fields is the same as in [RFC6830]. 337 4. Security Considerations 339 Security considerations discussed in [RFC6833] and [RFC6830] should 340 be taken into account. 342 5. IANA Considerations 344 This document does not make any request to IANA. 346 6. Acknowledgments 348 This work is partly funded by ANR LISP-Lab project #ANR-13-INFR- 349 009-X. 351 7. References 353 7.1. Normative references 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 361 Protocol (LISP) Map-Server Interface", RFC 6833, 362 DOI 10.17487/RFC6833, January 2013, 363 . 365 7.2. Informative references 367 [I-D.boucadair-connectivity-provisioning-protocol] 368 Boucadair, M., Jacquenet, C., Zhang, D., and P. 369 Georgatsos, "Connectivity Provisioning Negotiation 370 Protocol (CPNP)", draft-boucadair-connectivity- 371 provisioning-protocol-10 (work in progress), September 372 2015. 374 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 375 Locator/ID Separation Protocol (LISP)", RFC 6830, 376 DOI 10.17487/RFC6830, January 2013, 377 . 379 Authors' Addresses 381 Mohamed Boucadair 382 France Telecom 383 Rennes 35000 384 France 386 EMail: mohamed.boucadair@orange.com 388 Christian Jacquenet 389 France Telecom 390 Rennes 35000 391 France 393 EMail: christian.jacquenet@orange.com