idnits 2.17.1 draft-herbert-idloc-fast-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7872' is mentioned on line 587, but not defined == Unused Reference: 'RFC8200' is defined on line 675, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-herbert-fast-01 == Outdated reference: A later version (-04) exists of draft-muscariello-intarea-hicn-00 == Outdated reference: A later version (-04) exists of draft-auge-dmm-hicn-mobility-deployment-options-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Informational Quantonium 4 Expires: December 2018 6 June 26, 2018 8 Lightweight Identifier-Locator Mapping Using FAST 9 draft-herbert-idloc-fast-00 11 Abstract 13 This proposal provides a method to implement identifier to locator 14 mapping in the datapath without the need to access an in-network 15 mapping database or cache. Mappings are encoded in Firewall and 16 Service Tickets (FAST) tickets as locator information. When a packet 17 is sent by a mobile node, a ticket is attached that providers the 18 locator to use in the return path. Peer nodes receive packets with 19 these tickets, cache the tickets in a flow context, and then attach 20 them to packets they send as reflected tickets. When a packet with a 21 reflected ticket enters an identifier-locator domain, the ticket is 22 parsed to extract the locator. That locator is then used to send the 23 packet to the appropriate destination over a network overlay. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/1id-abstracts.html 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 Copyright and License Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2 Background and motivation . . . . . . . . . . . . . . . . . . . 4 64 2.1 Mapping Systems . . . . . . . . . . . . . . . . . . . . . . 4 65 2.2 hICN mobility proposal . . . . . . . . . . . . . . . . . . . 5 66 2.3 Firewall and Service Tickets . . . . . . . . . . . . . . . . 5 67 3 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2 Reference Topology . . . . . . . . . . . . . . . . . . . . . 7 70 3.3 Basic packet flow . . . . . . . . . . . . . . . . . . . . . 8 71 4 Firewall and Service Tickets encoding . . . . . . . . . . . . . 9 72 4.1 ILA locator encoding . . . . . . . . . . . . . . . . . . . . 10 73 4.2 Locator index encoding . . . . . . . . . . . . . . . . . . . 10 74 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1 Packet flow . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.1.1 Ticket requests . . . . . . . . . . . . . . . . . . . . 11 77 5.1.1.1 Fully qualified locators . . . . . . . . . . . . . . 12 78 5.1.1.2 Unqualified locators . . . . . . . . . . . . . . . . 12 79 5.1.2 First hop router processing . . . . . . . . . . . . . . 12 80 5.1.3 Transit to the peer . . . . . . . . . . . . . . . . . . 12 81 5.1.4 Peer reflection . . . . . . . . . . . . . . . . . . . . 12 82 5.1.5 Return path from peer . . . . . . . . . . . . . . . . . 13 83 5.1.6 Ingress into the origin network . . . . . . . . . . . . 13 84 5.1.7 Network overlay termination . . . . . . . . . . . . . . 13 85 5.1.8 Reception at origin of application . . . . . . . . . . . 14 86 5.2 Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 5.3 Mobile events . . . . . . . . . . . . . . . . . . . . . . . 14 88 5.4 Interaction with expired tickets . . . . . . . . . . . . . . 15 89 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 90 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16 91 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 94 9.2 Informative References . . . . . . . . . . . . . . . . . . 16 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 1 Introduction 99 Identifier-locator protocols, such as ILA and LISP, rely on a 100 distributed mapping system that maps identifiers to locators for 101 transmit across an overlay network. Typically, the set of mappings 102 are maintained in a distributed database or mapping cache. Border 103 routers of an identifier-locator domain access the database or cache 104 to map ingress packets to their appropriate locator. The router can 105 then use a network overlay method to deliver the packet to the mobile 106 destination; this could be done by address transformation (like in 107 ILA) or encapsulation (as done by LISP). 109 This proposal suggests and alternative method to do fast path 110 anchorless mobility with identifier-locator protocols that eschews 111 accessing a mapping database or mapping cache in the datapath. 113 2 Background and motivation 115 This section provides background and motivation. 117 2.1 Mapping Systems 119 Identifier-locator protocols, network virtualization, and mobility 120 share a common problem of resolving a mobile or virtual node to its 121 location in the network. In identifier-locator terminology this is 122 mapping an identifier to a locator. In virtualization, the process is 123 mapping a virtual address to a physical address, and in mobility it 124 is determining the current location of a host with a mobile address. 126 In a common overlay model, the mapping of identifier to locator is 127 done before sending a packet over a network overlay. The locator is 128 an underlay address for forwarding a packet across the network 129 overlay. There are several methods that can be used to implement the 130 network overlay, for instance encapsulation or address transformation 131 could be used, however the motivation and operation mapping 132 identifiers to locators are essentially the same in any case. 134 The set of identifier to locator mappings essentially is a 135 distributed database, and in fact some implementations implement a 136 mapping system using an "off the shelf" database. Identifiers don't 137 inherently allow aggregation, so the number of individual entries in 138 the mapping system maybe quite large (at most one entry for each 139 identifier). Even in a moderate size network the number of entries 140 will exceed the number that can be stored in memory of a singe device 141 so the mapping system must be sharded in some fashion. 143 One proposed method to scale a mapping system is to use mapping 144 caches. Border routers implement a mapping cache that contains a 145 working set of identifier to locator mappings for traffic currently 146 passing through the router. Caches are a dynamic optimization driven 147 by the traffic pattern, however their use in the network entails 148 potential issues of scaling and DOSability. 150 2.2 hICN mobility proposal 152 hICN with anchorless mobility [HICN-AMM] is an alternative proposal 153 to using a distributed mapping system with identifier locator 154 protocols. 156 [HICN-AMM] highlights some drawbacks of traditional mapping systems: 158 o They entangle forwarding operations and changes to network 159 location 161 o Mapping systems at large scale are difficult to manage 163 o Convergence time after a location change (handover in mobile 164 network terminology) may be excessive. 166 [HICN-AMM] and [HICN] describe a solution that eliminates the need 167 for a global mapping system by sending locator information in-line 168 with the data path. The locator information is embedded in a new 169 transport layer header ("Path Label" in transport header shown in 170 [HICN]). The transport layer header is parsed by routers in the path 171 and they use the information to create state for forwarding packets 172 in the return path. 174 The proposal described in this draft adopts the in-line approach to 175 convey locator information, however the protocol in the FAST method 176 is strictly confined to the network layer and there is no requirement 177 for transport state to be maintained by the network. 179 2.3 Firewall and Service Tickets 181 Firewall and Service Tickets (FAST) is a technique to allow an 182 application to signal to the network requests for admission and 183 services for a flow. A ticket is data that is attached to a packet by 184 the source that is inspected and validated by intermediate nodes in a 185 network. Tickets express a grant or right for packets to traverse a 186 network or have services applied to them. Tickets may also be 187 modified by intermediate nodes under certain circumstances. 189 In order to apply services to inbound packets for a communication, 190 remote peers reflect received tickets in packets they send without 191 interpreting them. Tickets are stateless within the network, however 192 they can be used to attain per flow semantics. Note that in lieu of 193 creating flow state in the network, state of interest to the network 194 can be cached at the endpoints and provided in data packets. Tickets 195 are encrypted and opaque to the end points for security and privacy. 197 This proposal uses FAST tickets to convey and reflect locator 198 information from a peer. FAST tickets employ IPv6 Destination or Hop- 199 by-Hop options. 201 3 Solution Overview 203 The central idea of using identifier locator protocols with FAST is 204 to put locator information in packets that can be used by network 205 nodes to achieve forwarding over a network overlay. In FAST, the 206 information is contained in a ticket and can be encrypted or 207 otherwise obfuscated so that only the nodes in the network that set 208 the information in the packet can parse it. 210 Transparent mobility can be achieved within the network layer, and 211 accordingly this solution and protocol are confined in the network 212 layer. Any signaling between applications and the network, or between 213 transport protocols and the network, is done via IPv6 Destination or 214 Hop-by-Hop options. This solution is specific to IPv6. 216 3.1 Requirements 218 This section lists some requirements for using FAST with identifier 219 locator protocols as a solution for fast and efficient mobility. 221 Requirements are: 223 - Solution works with any transport protocol or application 225 - Intermediate devices only process, inspect, or change network 226 layer headers as specified by RFC8200 228 - Communication for a flow is bidirectional (at least packets are 229 sent in both directions) 231 - Solution is an optimization for highly efficient fast path 232 anchorless mobile communications. The system must allow a slow 233 path fallback (for instance if extension headers are dropped for 234 some path) 236 - Client side supports FAST. Changes are described in [FAST]. This 237 should entail no kernel or protocol stack changes since FAST is 238 encoded in extension headers than can be set for flows using 239 existing APIs 241 - Server side supports ticket reflection as described in [FAST]. 242 This is a generic change in the protocol stack that should be 243 transparent to applications. 245 - FAST routers need to be deployed. These are typically border 246 routers of a domain as described in [FAST] 248 - Other intermediate nodes need to properly forward packets with 249 FAST tickets (Hop-by-Hop or Destination options). Note that 250 RFC8200 relaxes the requirement that all nodes in a path process 251 Hop-by-Hop options 253 - Does not rely an transport state being maintained in the network 255 - Makes no assumptions that packets for a flow always follow the 256 same path, or that any part of the network path must symmetric 257 for both directions of a flow 259 - Maintain security and privacy. In particular, locators are only 260 visible in the network that implement an overlay that uses them 262 3.2 Reference Topology 264 The diagram below provides a reference topology for a simple mobile 265 network. 266 ______ 267 _________ ( ) 268 +---------+ ( ) +---------+ ( ) +------+ 269 | eNodeB1 +---( RAN )---+ BRouter +---( Internet )--+ Peer | 270 +---------+ (_________) +----+----+ ( ) +------+ 271 | \ | (______) 272 +---------+ | \ | 273 | eNodeB2 +-------+ \ | 274 +---+-----+ +--------+--+ 275 | | Anchor | 276 +---+-----+ +-----------+ 277 | UE | 278 +---------+ 279 Figure 1 281 The diagram shows a mobile network that contains two eNodeB's (points 282 of attachment) and one UE (end device) that is currently attached to 283 eNodeB2. The UE is mobile so it can move from one eNodeB to another 284 (for instance it may attach to eNodeB1 at some point). The externally 285 visible address of the UE is an identifier that does not change when 286 the UE moves in the network. In the diagram, UE may be communicating 287 with the "Peer" host in the Internet. The Peer only knows the UE by 288 its externally visible address. To achieve communications, packets 289 from the Peer to the UE are sent over some type of network overlay. 291 The packets of interest with respect to mobility are those destined 292 to the UE. The Peer might itself be mobile, but that case should be 293 symmetric and transparent. In this model, it is the local network of 294 a node that deals with mobility of devices in the network. 296 It is common for mobile communications to go through an anchor point 297 that has access to the complete mapping database and provides the 298 entry point to the network overlay. Anchors may be heavyweight and 299 force packets into a "long" path with respect to latency. There is 300 motivation to allow a fast path for critical latency sensitive 301 communications that bypass anchor points. In figure 1, this fast path 302 would be implemented in BRouter. That is instead of forwarding 303 packets through the Anchor, it performs identifier locator-mapping 304 and network overlay functions itself. 306 The typically proposed method to eliminate the anchor point is to 307 implement a mapping cache (in the diagram this would be to place a 308 cache at BRouter). The proposal described here is an alternative that 309 doesn't requires a cache. 311 3.3 Basic packet flow 313 To use identifier-locator protocols with FAST, an application running 314 on a host gets a ticket from the network. The ticket encodes 315 information about the current location of the host. When the 316 application sends packet, the ticket is attached (in an extension 317 header). Packets having the ticket are the forwarded to the peer 318 destination. At the peer, the ticket is saved in flow context, and 319 subsequently when it sends response packets back to the UE the ticket 320 is attached to packets as a reflected ticket. 322 When a packet with a ticket is received at a border router of an 323 identifier-locator domain, the router parses the reflected ticket and 324 checks if locator information is included. If it is, the border 325 router then uses it to send the packet to the proper destination for 326 the network overlay. 328 For example, if ILA is in use in the network topology show above, the 329 flow might be: 331 1) Application in UE requests ticket, a ticket agent in the 332 provider network provides a ticket with locator information 333 indicating that UEs location is at eNode2. 335 2) Application sends packets. A ticket containing locator 336 information for eNodeB2 is attached to each packet. 338 3) Packet traverse network and are received at Peer. The peer node 339 saves the receive ticket in a flow context for the application. 341 4) Peer sends responses. The saved ticket is attached to its 342 packets as reflected tickets. 344 5) When a packet is received from the peer at BRouter, the 345 attached ticket is parsed. The locator information is extracted 346 that indicates the locator for eNodeB2. BRouter transforms the 347 destination address to an ILA locator address and forwards the 348 packet. 350 6) eNodeB receives ILA packets and performs the reverse 351 transformation to restore the original destination address 352 (typical ILA-N processing). 354 7) Packets are forward to UE. They still contain a ticket which 355 can be validated by the UE. 357 4 Firewall and Service Tickets encoding 359 FAST tickets are encoded in Hop-by-Hop or Destination options. If an 360 option is modifiable then Hop-by-Hop options should be used. 362 The format of a FAST ticket in a Destination or Hop-byHop option is: 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Option Type | Opt Data Len | Type | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 368 | | 369 ~ Ticket ~ 370 | | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Tickets are not intended to be parsed outside of the origin network 374 domain that issues them. Therefore, the ticket format is arbitrary at 375 the discretion of the domain in which they are issued and 376 interpreted. 378 [FAST] suggests a simple and efficient encoding of a Service Profile 379 Index: 381 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Reserved | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Expiration time | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Service Profile Index | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 This format can be amended to include locator information. Below are 391 some example encodings. Note that tickets are potentially set in all 392 datapath packets so minimizing protocol overhead is a consideration. 394 4.1 ILA locator encoding 396 ILA locators are sixty-four bits, and they can be encoded in a FAST 397 ticket in straightforward fashion. A ticket with expiration time, 398 service profile and an ILA locator may have format: 400 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type |Q| Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Expiration time | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Service Profile Index | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 + Locator + 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Where the 'Q' bit indicates that an unqualified locator was 414 overwritten. See Section X. 416 A full 128 bit address could similarly be encoded. 418 4.2 Locator index encoding 420 A network may have a comparatively small number of potential 421 locators. For instance, a mobile provider might associate each eNodeB 422 with a locator and there may only be a few million of these. In this 423 case, the border routers might maintain a static table of locator 424 addresses that can simply be indexed by number in a much smaller 425 range. A locator index encoded in a ticket might look like this: 427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type |Q| Reserved | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Expiration time | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Service Profile Index | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Locator Index | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Where the 'Q' bit indicates that an unqualified locator was 439 overwritten. 441 5 Operation 443 This section describes the operation of identifier-locator protocols 444 using FAST. 446 5.1 Packet flow 448 This sections describes the details of packet flow using identifier 449 locator protocols with FAST. 451 5.1.1 Ticket requests 453 Applications request FAST tickets from a ticket agent in the network 454 local to the application. The ticket agent can return a ticket for 455 the application to use in its data packets. The ticket includes 456 information that is parsed by elements in the issuing network. The 457 ticket information may include a locator. In other words if the 458 application is on a mobile device, the network may provide a ticket 459 that has a locator indicating the current location of the device. 461 [FAST] describes the process of an application requesting tickets and 462 setting them in packets. An application will not normally need to 463 make any special requests for mobility, in this model mobility is 464 expected to be transparent to the application (the ticket may contain 465 information about mobility that is opaque to the application). An 466 issued ticket having locator information will be of type "origin 467 ticket to be reflected". 469 There are two possibilities for locator information in an issued 470 ticket: 472 1) The locator is fully qualified. 474 2) The locator is no qualified. 476 5.1.1.1 Fully qualified locators 478 If the locator is qualified then the issued ticket contains the 479 locator for the end node. If the locator changes, that is the node 480 moves, then a new ticket will need to be issued to the application. 482 5.1.1.2 Unqualified locators 484 If the locator is not qualified, then the locator information in the 485 issued ticket contains a "not set" value. For instance, in the case 486 the locator is expressed by a Locator Index as in section 2.2, the 487 "not set" value may be -1 (all ones). A upstream router of an end 488 node may write a qualified locator value into the locator 489 information; most often this would just be its own locator value in 490 cases where it is the first upstream hop of end devices that provides 491 location in the network. For instance, an eNodeB router acting as the 492 first hop for a UE may write its locator value in tickets of packets 493 it's forwarding from UEs. The implication is that this will be the 494 locator used in the network overlay on the return path to reach the 495 end node. Note that to write a locator into to a ticket requires that 496 the ticket is in a modifiable Hop-by-Hop option. 498 5.1.2 First hop router processing 500 Once an application has been issued a ticket with a locator it will 501 set the tickets in all packets sent to the peer node. The first hop 502 upstream router in the FAST domain parses the ticket; this may 503 typically be the first hop router in a provider network closest to 504 end customer node. 506 If the ticket contains a qualified locator, the first hop node may 507 validate it (as part of FAST ticket validation). If the ticket has 508 unqualified locator information, the first hop node may set it to a 509 qualified locator value in the packet. As described above, the 510 locator information written is likely to be that corresponding to the 511 locator of the first hop device. 513 5.1.3 Transit to the peer 515 Beyond the first hop router to the ultimate peer destination, no 516 processing of the locator information in a ticket should be needed. 517 Intervening networks and routers should deliver the ticket to the 518 destination host unchanged. 520 5.1.4 Peer reflection 522 At the peer host, the procedures described in [FAST] are followed to 523 save the received ticket in a flow context and to reflect it in 524 subsequent packets. As with other reflected tickets, one containing 525 locator information is treated as an opaque value that is not parsed 526 or modified by the peer or any network outside of the origin network. 528 5.1.5 Return path from peer 530 Packets sent by a peer will include reflected tickets for a flow. No 531 processing of the locator information in a ticket should be needed 532 until the packet reaches the origin network of the ticket. 533 Intervening networks and routers should deliver the ticket to the 534 destination origin network unchanged. 536 5.1.6 Ingress into the origin network 538 A the border router for the origin network, tickets are parsed and 539 the encoded services are applied. If the ticket contains locator 540 information then that can be used for forward the packet over the 541 overlay network. 543 The specific operation depends on the protocol used to provide the 544 overlay network functionality. For instance, if ILA is in use and the 545 locator information is just a sixty-four bit locator as described in 546 Section 4.1, then the given locator is written to the destination of 547 the packet and the packet is forwarded towards the locator following 548 the procedures of ILA. Similarly, if a locator index is contained in 549 the ticket as described in Section 4.2, then that value is used to 550 index the locator table to get a sixty-four bit locator that can be 551 written into the destination address. Procedures for use of the 552 locator information to do encapsulation, such as that done by LISP, 553 are similar. 555 Note that the service parameters contained in the ticket may provide 556 addition information about how the packet is to be sent over the 557 network overlay. For instance, the service parameters might indicate 558 the packet is encrypted or to use some extensions of an encapsulation 559 protocol. 561 5.1.7 Network overlay termination 563 When a packet is received at the terminating point of an overlay it 564 is restored to the original packet. That is, if the packet was 565 encpasulated then it's unencpasulated, or if the destination address 566 was transformed then the reverse transformation is done to restore 567 the original address. 569 If the ticket was modified by the network, for instance an 570 unqualified locator was overwritten (indicated by the 'Q' bit being 571 set as described in Section 4), then the original ticket needs to be 572 restored. 574 5.1.8 Reception at origin of application 576 At the end host, received reflected tickets are validated for 577 acceptance as described in [FAST]. This is done by comparing the 578 received ticket to that which was sent on the corresponding flow. 580 5.2 Fallback 582 The proposal described here is strictly a fast path optimization. It 583 should not be assumed that tickets can completely replace a mobile 584 infrastructure. In particular, this solution relies on several 585 parties to implement protocols correctly. For instance, the use of 586 extension headers requires that they can be successfully sent through 587 a network. As reported in [RFC7872], support for forwarding packets 588 with extension headers is not yet ubiquitous. 590 Therefore, a fallback infrastructure is required. In the simplest 591 case, this is just to fallback to forwarding through anchor points. 592 That path can be chosen independently of whether the fast path is 593 implemented. In the data path the selection of which path to take is 594 easily chosen, if a packet contains a valid ticket with valid locator 595 information then the fast path can be taken, else the slow path is 596 selected. 598 5.3 Mobile events 600 When a mobile node moves and its locator changes, it is desirable to 601 converge to using the new locator as a quickly as possible. With 602 tickets that contain locator information, a modified ticket needs to 603 be sent to a peer host. 605 If an application was issued a ticket with qualified locator 606 information then a new ticket needs to the be issued. This can be 607 done by the application receiving a signal that a mobile event has 608 occurred that causes it to make new ticket requests for established 609 flows. 611 If an application has a ticket with an unqualified locator then the 612 network should start writing the new locator information into packets 613 that are sent by the application after the mobile event. This should 614 be transparent to the application. 616 Note that in either case, in order to update the tickets that a peer 617 is reflecting, the application needs to send packets to the peer that 618 includes an updated ticket. There is no guarantee on when an 619 application may send packets, so there is the possibility of a window 620 where the peer node is sending reflected tickets with outdated 621 locator information. The window should be limited by the expiration 622 time of a ticket (see below), however it is recommended to implement 623 mechanisms to avoid communication blackholes. For instance, a "care 624 of address" mapping entry could be installed at the old locator 625 device to forward to the new one. Such solutions are also used to 626 mitigate database convergence time or update caches in other 627 solutions. 629 5.4 Interaction with expired tickets 631 FAST typically expects ticket to have an expiration time. If a ticket 632 is received within the expiration time and it is considered valid, 633 then the packet is forwarded per the services indicated by the 634 ticket. If a packet with a ticket is received that is expired, it 635 might still be accepted subject to rate limiting. Accepting expired 636 tickets is useful in the case that a connection goes idle and after 637 some time the remote peer starts to send. 639 For tickets that are expired and contain locator information, an 640 implementation should ignore the locator information and take the 641 fallback path. If the mobile application responds it can include a 642 fresh ticket so that the fast path is taken on subsequent packets. 643 Ignoring the locator information in expired tickets puts an upper 644 bound on the window that an outdated locator can be used (see section 645 5.3). 647 6 Security Considerations 649 Locator information can be highly sensitive data especially if it 650 could reveal physical location of individuals. Effort must be made to 651 safeguard this information. In particular, locators in plain text 652 should only be exposed within the origin network providing mobility. 653 This includes hiding locators from end hosts. [FAST] discusses 654 security of tickets including recommendations to encrypt them. 656 Tickets may be reused in packets for some period, and it is desirable 657 to prevent third parties from making an inferences based on the fact 658 the a ticket for a flow changed. For instance, it should not be 659 deducible that a node has moved on the basis of a new ticket being 660 used on a flow. To avoid this possibility tickets for a flow should 661 be changed randomly to avoid correlating ticket changes to events. 663 7 IANA Considerations 665 There are no IANA considerations in this document. [FAST] requests 666 numbers for Destination and Hop-by-Hop options that would be used by 667 this proposal. 669 8 Acknowledgments 671 9 References 673 9.1 Normative References 675 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 676 (IPv6) Specification", STD 86, RFC 8200, DOI 677 10.17487/RFC8200, July 2017, . 680 [FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert- 681 fast-01, June 2018. 683 9.2 Informative References 685 [HICN] L. Muscariello, G. Carofiglio, J. Auge, and M. Papalini, 686 "Hybrid Information-Centric Networking", draft-muscariello- 687 intarea-hicn-00, June 2018 689 [HICN-AMM] Auge, J., Carofiglio, G., Muscariello, L., and M. 690 Papalini, "Anchorless mobility management through hICN 691 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 692 mobility-deployment-options-00 (work in progress), June 693 2018. 695 Author's Address 697 Tom Herbert 698 Quantonium 699 Santa Clara, CA 700 USA 702 Email: tom@quantonium.net