idnits 2.17.1 draft-herbert-route-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 (October 10, 2018) is 2023 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SPRING' is mentioned on line 174, but not defined == Missing Reference: 'MAGLEV' is mentioned on line 271, but not defined == Missing Reference: 'RFC7872' is mentioned on line 675, but not defined == Unused Reference: 'RFC8200' is defined on line 764, 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 (~~), 8 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: April 2019 6 October 10, 2018 8 Encoding Routing in Firewall and Service Tickets 9 draft-herbert-route-fast-00 11 Abstract 13 This document describes a method to encode routing information in 14 Firewall and Service Tickets (FAST). Encoded routing information 15 provides the local routing for packets sent in either the forward or 16 return paths of a flow. FAST ticket reflection at peer hosts ensures 17 that the routing information is attached to packets being sent in the 18 return path. When a packet with a FAST ticket containing routing 19 information enters the network in which the ticket was issued, the 20 ticket is parsed to extract the routing information and is forwarded 21 per the information. Routing in Firewall and Service Tickets has a 22 number of use cases. It can be used as a type of source routing, used 23 with identifier-locator protocols to provide a locator in the return 24 path, and can be used to specify a backend instance in Layer 4 load 25 balancing for processing connections to a virtual IP address. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2 Background and motivation . . . . . . . . . . . . . . . . . . . 4 67 2.1 Problem statement . . . . . . . . . . . . . . . . . . . . . 4 68 2.2 Firewall and Service Tickets . . . . . . . . . . . . . . . . 4 69 2.3 Similar efforts . . . . . . . . . . . . . . . . . . . . . . 5 70 2.3.1 Segment routing . . . . . . . . . . . . . . . . . . . . 5 71 2.3.2 hICN mobility proposal . . . . . . . . . . . . . . . . . 5 72 2.4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.4.1 Identifier-locator protocols and virtualization . . . . 6 74 2.4.2 Segment routing . . . . . . . . . . . . . . . . . . . . 6 75 2.4.3 Layer 4 load balancing . . . . . . . . . . . . . . . . . 7 76 3 Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2 Reference Topology . . . . . . . . . . . . . . . . . . . . . 9 79 3.3 Basic packet flow . . . . . . . . . . . . . . . . . . . . . 10 80 4 Firewall and Service Tickets encoding . . . . . . . . . . . . . 11 81 4.1 ILA locator encoding . . . . . . . . . . . . . . . . . . . . 12 82 4.2 Locator index encoding . . . . . . . . . . . . . . . . . . . 12 83 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5.1 Ticket requests . . . . . . . . . . . . . . . . . . . . . . 13 85 5.2 Qualified locators . . . . . . . . . . . . . . . . . . . . . 13 86 5.2.1 Fully qualified locators . . . . . . . . . . . . . . . . 14 87 5.2.2 Unqualified locators . . . . . . . . . . . . . . . . . . 14 88 5.3 First hop router processing . . . . . . . . . . . . . . . . 14 89 5.4 Transit to the peer . . . . . . . . . . . . . . . . . . . . 14 90 5.5 Ingress into the origin network . . . . . . . . . . . . . . 15 91 5.6 Network overlay termination . . . . . . . . . . . . . . . . 15 92 5.7 Fallback . . . . . . . . . . . . . . . . . . . . . . . . . . 16 93 5.8 Mobile events . . . . . . . . . . . . . . . . . . . . . . . 16 94 5.9 Interaction with expired tickets . . . . . . . . . . . . . . 16 96 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 97 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18 98 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 99 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 101 9.2 Informative References . . . . . . . . . . . . . . . . . . . 18 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 104 1 Introduction 106 This document specifies a method to encode routing information in 107 Firewall and Service Tickets (FAST). FAST allows hosts to signal the 108 network for services to be applied to packets in the form of tickets 109 that are issued by the network and attached to packets. Tickets may 110 encode information as to how the packet is to be routed in the local 111 network. Tickets can be reflected by peer nodes for a connection, so 112 that routing information can be applied in the reverse path of a 113 flow. When a packet with an attached ticket containing routing 114 information enters a network, the ticket is parsed and the encoded 115 routing is applied to the packet. The routing information is 116 arbitrary per the network's needs. For instance, it may indicate a 117 tunnel to send the packets on, a segment routing list, a locator in 118 identifier-locator protocols, or the IP address for a backend 119 instance of a layer 4 load balancer. 121 2 Background and motivation 123 This section provides background and motivation. 125 2.1 Problem statement 127 A network may implement arbitrary complex routing of packets, mobile 128 routing functions, or routing for service function chains. Often such 129 functions require routing packets on a per flow basis or perhaps 130 based on some awareness of application content. 132 Typically, this advanced routing is done by an ingress router into a 133 network. This router may need to perform Deep Packet Inspection (DPI) 134 into the transport layer, may maintain state for every flow 135 traversing it, or may maintain a mapping table of mobile or virtual 136 addresses to their locators or physical nodes. The net effect is that 137 intermediate nodes perform complex transport protocol specific 138 functions that are difficult to to scale. In turn, the complexity in 139 such nodes contributes to protocol ossification. 141 2.2 Firewall and Service Tickets 143 Firewall and Service Tickets (FAST) is a technique to allow an 144 application to signal to the network requests for admission and 145 services for a flow. A ticket is data that is attached to a packet by 146 the source that is inspected and validated by intermediate nodes in a 147 network. Tickets express a grant or right for packets to traverse a 148 network or have services applied to them. Tickets may also be 149 modified by intermediate nodes under certain circumstances. 151 In order to apply services to inbound packets for a communication, 152 remote peers reflect received tickets in packets they send without 153 interpreting them. Tickets are stateless within the network, however 154 they can be used to attain per flow semantics. Note that in lieu of 155 creating flow state in the network, state of interest to the network 156 can be cached at the endpoints and provided in data packets. Tickets 157 are encrypted and opaque to the end points for security and privacy. 158 FAST is IPv6 specific and uses Hop-by-Hop options. 160 This draft proposes to encode routing information into FAST tickets. 161 The necessary information for routing packets is contained within the 162 network layer headers of each packet. The encoded data obviates the 163 need for DPI, flow state, or complex route lookups at ingress 164 routers. 166 2.3 Similar efforts 168 This section highlights similar efforts that encode routing 169 information in packets with the intent that intermediate nodes will 170 consume the information. 172 2.3.1 Segment routing 174 Segment routing [SPRING] is a type of source routing that employs a 175 routing header. A segment routing header contains a list of segment 176 identifiers (SIDs) that indicate the nodes to visit by their IPv6 177 addresses. Segment routing is often deployed with IP encapsulation. 178 When a packet enters a segment routing domain, a lookup is performed 179 on the packet to retrieve the segment list. The packet is then 180 encapsulated in IPv6 and a segment routing header is attached to the 181 packet. The lookup may be stateless in simple cases, or may require a 182 stateful lookup with full blown connection tracking. 184 Segment routing is intended for use in a limited domain and not on 185 the Internet. Use over the Internet would expose internal addresses 186 in the route list, offers no security, and would have considerable 187 overhead. Additionally, segment routing only describes routing in the 188 the forward path to a destination, not the return path. 190 2.3.2 hICN mobility proposal 192 hICN with anchorless mobility [HICN-AMM] is an alternative proposal 193 to using a distributed mapping system with identifier locator 194 protocols. 196 [HICN-AMM] highlights some drawbacks of traditional mapping systems: 198 o They entangle forwarding operations and changes to network 199 location 201 o Mapping systems at large scale are difficult to manage 203 o Convergence time after a location change (handover in mobile 204 network terminology) may be excessive. 206 [HICN-AMM] and [HICN] describe a solution that eliminates the need 207 for a global mapping system by sending locator information in-line 208 with the data path. The locator information is embedded in a new 209 transport layer header ("Path Label" in the transport header shown in 210 [HICN]). The transport layer header is parsed by routers in the path 211 and they use the information to create state for forwarding packets 212 in the return path. 214 Similar to FAST, the hICN proposal adopts an in-line approach to 215 convey routing information. However, the protocol in the FAST method 216 is strictly confined to the network layer and there is no requirement 217 for transport state to be maintained by the network. 219 2.4 Use cases 221 This section highlights some use cases of FAST to carry routing 222 information. 224 2.4.1 Identifier-locator protocols and virtualization 226 Identifier-locator protocols, such as ILA and LISP, rely on a 227 distributed mapping system that maps identifiers to locators for 228 transit across a network overlay. Typically, the set of mappings are 229 maintained in a distributed database or mapping cache. Border routers 230 of an identifier-locator domain access the database or cache to map 231 ingress packets to their appropriate locator. The router can then use 232 a network overlay method to deliver packets to their mobile 233 destination; this could be done by address transformation (like in 234 ILA) or encapsulation (as done by LISP). 236 This proposal suggests an alternative which is to encode locators in 237 Firewall and Service Tickets. This method allows fast path anchorless 238 mobility with identifier-locator protocols that eschews accessing a 239 mapping database or mapping cache for every packet in the datapath. 241 2.4.2 Segment routing 243 A FAST ticket could encode bits that network nodes interpret and 244 expand into a segment routing list. When a ticket with such an 245 encoding enters a network, or segment routing domain in this case, it 246 is parsed and the information is expanded to the full segment list. 247 The packet is encapsulated, the segment list is attached in a routing 248 header, and the packet is forwarded towards the destination. The 249 encoded information might have some compressed form such as an index 250 into a table or a bit map of nodes or services that are needed. FAST 251 tickets are encrypted or obfuscated so that they are opaque to the 252 Internet, they are also reflected so that segment routing can be 253 applied to the reverse path of flow. 255 2.4.3 Layer 4 load balancing 257 Layer 4 load balancers route packets addressed to virtual IP 258 addresses (VIPs). A virtual IP address is shared amongst some number 259 of backend servers. Routing to backend servers is done on a per flow 260 basis so that the targeted backend is the one that terminates the 261 flow. Routing must be consistent for the lifetime of the flow lest 262 packets are received on the wrong backend (in which case packets are 263 dropped and the connection might be disconnected. 265 Consistent routing is accomplished in two ways: 1) a consistent hash 266 of the 5-tuple is used to load balance flows across the backend 267 servers, and 2) connection tracking is used to map a flow to its 268 assigned backend server. The number of backend servers may be dynamic 269 and connections may be migrated between servers. The goal of routing 270 by a load balancer is to minimize black holes and connection drops. 271 The Maglev load balancer [MAGLEV] implements an efficient algorithm 272 employing a hybrid of these two techniques, however it does not 273 entirely eliminate the possibility of connections being dropped. 275 Both tuple hashing and connection tracking have some disadvantages. 276 Consistent hashing in the presence of dynamic number servers is a 277 hard problem. Connection tracking entails network state which is 278 difficult to scale and can be susceptible to Denial of Service (DOS) 279 attack. 281 FAST can be applied to provide a stateless and robust solution for 282 load balancing. When a server backend server receives a connection 283 request it creates a ticket that encodes its instance identity (for 284 example the backend IP address). The ticket is attached to packets 285 for the connection that are sent back the client. The client in turn 286 will reflect the tickets in subsequent packets it sends. When the 287 load balancer receives a packet with a reflected ticket, it decodes 288 the ticket and extracts the identity of the assigned backend server. 289 The load balancer then forwards the packet to the address for the 290 indicated backend. If received packets don't have a ticket attached 291 (the first packet on the connection or the peer doesn't reflect 292 tickets) then tuple hashing can be used as a fallback. 294 Using FAST to encode the backend server instance is impervious to 295 changes to the number of backend servers and requires no flow state 296 in the network. If a connection migrates, the server simply creates a 297 new ticket that indicates the new backend server for the flow. Once 298 the server sends packets with the updated ticket, the client will 299 reflect it and the load balancer will properly route packets for the 300 flow to the correct backend. 302 3 Solution Overview 304 The central idea of this design is that arbitrary routing information 305 is attached to packets and is interpreted by network nodes to achieve 306 expedited forwarding. In FAST, routing information is encoded in 307 tickets and can be encrypted or otherwise obfuscated. Only the nodes 308 in the origin network of the information are able to parse and 309 interpret it. Since the information is secured it can safely be 310 contained in packets sent on the open Internet. 312 Since packets contain the information needed to route them, route 313 lookups and per flow state maintained in the network to hold routing 314 information is obviated. Packets can effectively be source routed in 315 both the forward and return paths. FAST operates at the network layer 316 and doesn't require network nodes to perform Deep Packet Inspection 317 (DPI) into the transport layer. Any signaling between applications 318 and the network, or between transport protocols and the network, is 319 done via Hop-by-Hop options. This solution is specific to IPv6. 321 3.1 Requirements 323 This section lists some requirements for encoding routing in FAST. 325 Requirements are: 327 - Solution works with any transport protocol or application 329 - Intermediate devices only process, inspect, or change network 330 layer headers as specified by RFC8200 332 - Communication for a flow is bidirectional 334 - Solution is an optimization for fast path routing. The system 335 must allow a slow path fallback (for instance, if extension 336 headers are dropped for some path) 338 - Client side supports FAST. Necessary support is described in 339 [FAST]. This should entail no kernel or protocol stack changes 340 since FAST is encoded in extension headers than can be set for 341 flows using existing APIs 343 - Server side supports ticket reflection as described in [FAST]. 344 This is a generic change in the protocol stack that should be 345 transparent to applications. 347 - FAST routers need to be deployed. These are typically border 348 routers of a domain as described in [FAST]. 350 - Other intermediate nodes need to properly forward packets with 351 FAST tickets (Hop-by-Hop options). Note that RFC8200 relaxes the 352 requirement that all nodes in a path process Hop-by-Hop options 354 - Does not rely an transport state being maintained in the network 356 - Makes no assumptions that packets for a flow always follow the 357 same path, or that any part of the network path must be 358 symmetric for both directions of a flow 360 - Maintain security and privacy. In particular, locators are only 361 visible in the network that implement an overlay that uses them 363 3.2 Reference Topology 365 The diagram below provides a reference topology for a simple mobile 366 network. 367 ______ 368 __________ ( ) 369 +---------+ ( Provider ) +---------+ ( ) +------+ 370 | eNodeB1 +---( network )---+ BRouter +---( Internet )--+ Peer | 371 +---------+ (__________) +----+----+ ( ) +------+ 372 | \ | (______) 373 +---------+ | \ | 374 | eNodeB2 +--------+ \ | 375 +---+-----+ +--------+--+ 376 | | Anchor | 377 +---+-----+ +-----------+ 378 | UE | 379 +---------+ 380 Figure 1 382 The diagram shows a mobile network that contains two eNodeB's (points 383 of attachment) and one UE (end host device) that is attached to 384 eNodeB2. The UE is mobile so it can move from one eNodeB to another 385 (for instance it may attach to eNodeB1 at some point). The externally 386 visible address of the UE is an identifier that does not change when 387 the UE moves in the network. In the diagram, UE may be communicating 388 with the "Peer" host in the Internet. The Peer only knows the UE by 389 its externally visible address. To achieve communications, packets 390 from the Peer to the UE are sent over some type of network overlay 391 when transiting the provider network. 393 The packets of interest with respect to mobility are those destined 394 to the UE. The Peer might itself be mobile, but that case should be 395 symmetric and transparent. In this model, it is the local network of 396 a mobile node that deals with mobility of devices in the network. 398 It is common for mobile communications to go through an anchor point 399 that has access to the complete mapping database and provides the 400 entry point to the network overlay. Anchors may be heavyweight and 401 force packets into a "long" path with respect to latency. There is 402 motivation to allow a fast path for critical latency sensitive 403 communications that bypass anchor points. In figure 1, this fast path 404 would be implemented in BRouter. That is, instead of forwarding 405 packets through the Anchor, it performs identifier locator-mapping 406 and network overlay functions itself. 408 The typically proposed method to eliminate the anchor point is to 409 implement a mapping cache (in the diagram this would be to place a 410 cache at BRouter). The proposal described here is an alternative that 411 doesn't require a cache. 413 3.3 Basic packet flow 415 To use routing with FAST, an application running on a host gets a 416 ticket from the network. The ticket encodes the routing information 417 of interest to the network. When the application sends a packet, the 418 ticket is attached (in an extension header). Packets with the ticket 419 are the forwarded to the peer destination. At the peer, the ticket is 420 saved in a flow context. Subsequently, when an application sends 421 response packets back to its peer the ticket is attached to packets 422 as a reflected ticket. 424 When a packet with a ticket is received at a border router of the 425 domain that issued the ticket, the router parses the reflected ticket 426 and verifies it. If it is valid, the border router applies the 427 encoded routing information to forward the packet on to its 428 destination. 430 For example, if ILA is in use in the network topology show above, the 431 flow might be: 433 1) Application in UE requests a ticket. A ticket agent in the 434 provider network provides a ticket with locator information 435 indicating that UE's location is at eNode2. 437 2) Application sends packets. The ticket containing locator 438 information for eNodeB2 is attached to each packet. 440 3) Packets traverse network and are received at Peer. The peer 441 node saves the receive ticket in a flow context for the 442 application. 444 4) Peer sends responses. The saved ticket is attached to packets 445 as reflected tickets. 447 5) When a packet is received from the peer at BRouter, the 448 attached ticket is parsed. The locator information is extracted 449 that indicates the locator for eNodeB2. BRouter transforms the 450 destination address to an ILA locator address and forwards the 451 packet. 453 6) eNodeB receives ILA packets and performs the reverse 454 transformation to restore the original destination address 455 (typical ILA-N processing). 457 7) Packets are forward to UE. They still contain a ticket which 458 can be validated by the UE. 460 4 Firewall and Service Tickets encoding 462 FAST tickets are encoded in Hop-by-Hop options. The format of a FAST 463 ticket in a Hop-by-Hop option is: 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Option Type | Opt Data Len | Prop | Rsvd | Type | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 ~ Ticket ~ 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Tickets are not intended to be parsed outside of the origin network 475 domain that issues them. Therefore, the format is arbitrary per the 476 discretion of the domain in which they are issued. 478 [FAST] suggests a simple and efficient encoding of a Service Profile 479 Index: 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Prop | Rsvd | Type | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Expiration time | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Service Profile Index | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 This format can be amended to include routing information. Below are 491 some example encodings. Note that tickets are potentially set in all 492 datapath packets so minimizing protocol overhead is a consideration. 494 4.1 ILA locator encoding 496 ILA locators are sixty-four bits, and they can be encoded in a FAST 497 ticket in a straightforward fashion. A ticket with expiration time, 498 service profile and an ILA locator may have format: 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Prop | Rsvd | Type |Q| 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Expiration time | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Service Profile Index | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | | 509 + Locator + 510 | | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Where the 'Q' bit indicates that an unqualified locator was 514 overwritten. See Section 5.2. 516 A full 128 bit address could similarly be encoded for use with LISP 517 or other encapsulation protocols. 519 4.2 Locator index encoding 521 A network may have a comparatively small number of locators. For 522 instance, a mobile provider might associate each eNodeB with a 523 locator and there may only be a few million of these. In this case, 524 the border routers might maintain a static table of locator addresses 525 that can simply be indexed by number in a small range. Similarly, the 526 backend server in the layer 4 load balancing case might also be 527 indicated by an index into a table of backend servers. 529 A locator index encoded in a ticket might look like this: 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Prop | Rsvd | Type |Q| 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Expiration time | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Service Profile Index | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Locator Index | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 Where the 'Q' bit indicates that an unqualified locator was 543 overwritten. See section 5.2. 545 5 Operation 547 This section describes the operation of encoding routing information 548 in FAST tickets. 550 5.1 Ticket requests 552 Applications request FAST tickets from a ticket agent in the network 553 local to the application. The ticket agent can return a ticket for 554 the application to use in its data packets. The ticket includes 555 information that is parsed by elements in the issuing network. The 556 ticket information may include routing information. For example, if 557 the application is on a mobile device, the network may provide a 558 ticket that has a locator indicating the current location of the 559 device. 561 [FAST] describes the process of an application requesting tickets and 562 setting them in packets. An application will not normally need to 563 make any special requests for routing information and the use of 564 routing information is expected to be transparent to the application. 566 5.2 Qualified locators 568 There are two possibilities for locator information in an issued 569 ticket: 571 1) The locator is fully qualified. 573 2) The locator is not qualified. 575 5.2.1 Fully qualified locators 577 If the locator is qualified then the issued ticket contains the 578 locator for the end node. If the locator changes, that is the node 579 moves, then a new ticket will need to be issued to the application. 581 5.2.2 Unqualified locators 583 If the locator is not qualified, then the locator information in the 584 issued ticket contains a "not set" value. For instance, in the case 585 the locator is expressed by a Locator Index as in section 4.2, the 586 "not set" value may be -1 (all ones). A upstream router of an end 587 node may write a locator value into the locator information to make 588 it qualified; most often this would just be its own locator value in 589 cases where it is the first upstream hop of end devices that provides 590 location in the network. For instance, an eNodeB router acting as the 591 first hop for a UE may write its locator value in tickets of packets 592 it is forwarding from UEs. The implication is that this will be the 593 locator used in the network overlay on the return path to reach the 594 end node. Note that to write a locator into to a ticket requires that 595 the ticket is in a modifiable Hop-by-Hop option. 597 5.3 First hop router processing 599 Once an application has been issued a ticket with routing information 600 it will set the ticket in all packets sent to the peer node. The 601 first hop upstream router in the FAST domain parses the ticket; this 602 may typically be the first hop router in a provider network closest 603 to end user nodes. 605 If the ticket contains a qualified locator, the first hop node may 606 validate it (as part of FAST ticket validation). If the ticket has 607 unqualified locator information, the first hop node may set it to a 608 qualified locator value in the packet. As described above, the 609 locator information written is likely to be that corresponding to the 610 locator of the first hop device. 612 5.4 Transit to the peer 614 Beyond the first hop router to the ultimate peer destination, no 615 processing of routing information in a ticket should be needed. 616 Intervening networks and routers should deliver the ticket to the 617 destination host unchanged. 619 At the peer host, the procedures described in [FAST] are followed to 620 save the received ticket in a flow context and to reflect it in 621 subsequent packets. As with other reflected tickets, one containing 622 routing information is treated as an opaque value that is not parsed 623 or modified by the peer or any network outside of the origin network. 625 Packets sent by a peer will include reflected tickets for a flow. No 626 processing of reflected routing information in a ticket should be 627 needed until the packet reaches the origin network of the ticket. 628 Intervening networks and routers should deliver the ticket to the 629 destination origin network unchanged. 631 5.5 Ingress into the origin network 633 At the border router for the origin network, tickets are parsed and 634 the encoded services are applied. If a ticket contains routing 635 information then that can be used to forward the packet over an 636 overlay network. 638 The specific operation depends on the protocol used to provide the 639 overlay network functionality. For instance, if ILA is in use and the 640 locator information is just a sixty-four bit locator as described in 641 Section 4.1, then the given locator is written to the destination of 642 the packet and the packet is forwarded to the locator address 643 following the procedures of ILA. Similarly, if a locator index is 644 contained in the ticket as described in Section 4.2, then that value 645 is used to index the locator table to get a sixty-four bit locator 646 that can be written into the destination address. Procedures for use 647 of the locator information to do encapsulation, such as that done by 648 LISP, are similar. 650 Note that the service parameters contained in the ticket may provide 651 additional information about how the packet is to be sent over the 652 network overlay. For instance, the service parameters might indicate 653 the packet is encrypted or to use some extensions of an encapsulation 654 protocol. 656 5.6 Network overlay termination 658 When a packet is received at the terminating point of an overlay it 659 is restored to the original packet. If the packet was encpasulated 660 then it's unencpasulated, or if the destination address was 661 transformed then the reverse transformation is done to restore the 662 original address. 664 At the end host, received reflected tickets are validated for 665 acceptance as described in [FAST]. This is done by comparing the 666 received ticket to that which was sent on the corresponding flow. 668 5.7 Fallback 670 The proposal described here is considered an optimization. Routing 671 information in FAST tickets is not intended to completely replace a 672 routing infrastructure. In particular, this solution relies on 673 several parties to implement protocols correctly. For instance, the 674 use of extension headers requires that they can be successfully sent 675 through a network. As reported in [RFC7872], Internet support for 676 forwarding packets with extension headers is not yet ubiquitous. 678 Therefore, a fallback is required when encoding routing information 679 in FAST is not viable for a flow. In the mobile case, the fallback 680 might be to forward through anchor points. In the layer 4 load 681 balancer case, the fallback may be to use the tuple hash. 683 5.8 Mobile events 685 When a mobile node moves and its locator changes, it is desirable to 686 converge to using the new locator as a quickly as possible. With 687 tickets that contain locator information, a modified ticket needs to 688 be sent to a peer host. 690 If an application was issued a ticket with qualified locator 691 information then a new ticket needs to be issued. This can be done by 692 the application receiving a signal that a mobile event has occurred 693 causing it to make new ticket requests for established flows. 695 If an application has a ticket with an unqualified locator then the 696 network should start writing the new locator information into packets 697 that are sent by the application after the mobile event. This should 698 be transparent to the application. 700 Note that in either case, in order to update the tickets that a peer 701 is reflecting, the application needs to send packets to the peer that 702 includes an updated ticket. There is no guarantee when an application 703 may send packets, so there is the possibility of a window where the 704 peer node is sending reflected tickets with outdated locator 705 information. The window should be limited by the expiration time of a 706 ticket (see below), however it is recommended to implement mechanisms 707 to avoid communication blackholes. For instance, a "care of address" 708 mapping entry could be installed at the old locator device to forward 709 to the new one. Such solutions are also used to mitigate database 710 convergence time or cache synchronization time. 712 5.9 Interaction with expired tickets 714 FAST typically expects ticket to have an expiration time. If a ticket 715 is received before the expiration time and it is otherwise valid, 716 then the packet is forwarded per the services indicated by the 717 ticket. If a packet is received with an expired ticket, it might 718 still be accepted subject to rate limiting. Accepting expired tickets 719 is useful in the case that a connection goes idle and after some time 720 the remote peer starts to send. 722 For tickets that are expired and contain routing information, an 723 implementation should ignore the routing information and take the 724 fallback path. When an application sends new packets, it can include 725 a fresh ticket so that the fast path is taken on subsequent packets. 726 Ignoring the routing information in expired tickets puts an upper 727 bound on the window that outdated information can be used. 729 6 Security Considerations 731 Routing information can be highly sensitive data especially if it 732 could reveal the physical location or identity of individuals. Effort 733 must be made to safeguard this information. In particular, locators 734 in plain text should only be exposed within the origin network 735 providing mobility. This includes hiding locators from end hosts. 736 [FAST] discusses security of tickets including recommendations to 737 encrypt them. 739 Tickets may be reused in packets for some period, and it is desirable 740 to prevent third parties from making inferences based on the fact 741 that a ticket for a flow changed. For instance, it should not be 742 deducible that a node has moved on the basis of a new ticket being 743 used on a flow. To avoid this possibility tickets for a flow should 744 be changed randomly to avoid correlating ticket changes to events. 746 Per [FAST], tickets are expected to be encrypted or obfuscated to 747 prevent nodes outside the origin network from interpreting them. The 748 only information an external node should be able to deduce is that a 749 packet contains a ticket. Accordingly, routing information encoded in 750 tickets is hidden from external nodes. This allows securely sending 751 packets with encoded local routing information over the Internet. 753 7 IANA Considerations 755 There are no IANA considerations in this document. [FAST] requests 756 numbers for Hop-by-Hop options that would be used by this proposal. 758 8 Acknowledgments 760 9 References 762 9.1 Normative References 764 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 765 (IPv6) Specification", STD 86, RFC 8200, DOI 766 10.17487/RFC8200, July 2017, . 769 [FAST] Herbert, T., "Firewall and Service Tickets", draft-herbert- 770 fast-01, June 2018. 772 9.2 Informative References 774 [HICN] L. Muscariello, G. Carofiglio, J. Auge, and M. Papalini, 775 "Hybrid Information-Centric Networking", draft-muscariello- 776 intarea-hicn-00, June 2018 778 [HICN-AMM] Auge, J., Carofiglio, G., Muscariello, L., and M. 779 Papalini, "Anchorless mobility management through hICN 780 (hICN-AMM): Deployment options", draft-auge-dmm-hicn- 781 mobility-deployment-options-00 (work in progress), June 782 2018. 784 Author's Address 786 Tom Herbert 787 Quantonium 788 Santa Clara, CA 789 USA 791 Email: tom@herbertland.com