idnits 2.17.1 draft-herbert-fast-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 418: '... o Tickets MUST be stateless with...' RFC 2119 keyword, line 419: '...termediate nodes MUST NOT be required ...' RFC 2119 keyword, line 422: '... o Tickets MUST work in a multi-h...' RFC 2119 keyword, line 424: '... that issued a ticket, tickets MUST be...' RFC 2119 keyword, line 428: '... o Tickets MUST work with any tra...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2018) is 2132 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-03) exists of draft-herbert-6man-icmp-limits-00 Summary: 2 errors (**), 0 flaws (~~), 2 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: Standard Quantonium 4 Expires: December 2018 6 June 25, 2018 8 Firewall and Service Tickets 9 draft-herbert-fast-01 11 Abstract 13 This document describes the Firewalls and Service Tickets protocol. A 14 ticket is data that accompanies a packet and indicates a granted 15 right to traverse a network or a request for network service to be 16 applied. Applications request tickets from a local agent in the 17 network and attach issued tickets to packets. Firewall tickets are 18 issued to grant packets the right to traverse a network; service 19 tickets indicate the desired service to be applied to a packets. A 20 single ticket may provide both firewall and service ticket 21 information. Tickets are sent in either IPv6 Destination options or 22 Hop-by-Hop options. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as 32 Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/1id-abstracts.html 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 Copyright and License Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1 Current mechanisms . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.1 Stateful firewalls and proxies . . . . . . . . . . . . . 4 65 2.1.2 QoS signaling . . . . . . . . . . . . . . . . . . . . . 5 66 2.1.3 Deep packet inspection . . . . . . . . . . . . . . . . . 5 67 2.2 Alternative proposals . . . . . . . . . . . . . . . . . . . 5 68 2.2.1 SPUD/PLUS . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.2.2 Path aware networking . . . . . . . . . . . . . . . . . 6 70 2.3 Emerging use cases . . . . . . . . . . . . . . . . . . . . . 7 71 3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3.1 Example packet flow . . . . . . . . . . . . . . . . . . . . 9 73 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4 Packet format . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.1 Option format . . . . . . . . . . . . . . . . . . . . . . . 11 76 4.2 Option types . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.3 Ticket format . . . . . . . . . . . . . . . . . . . . . . . 12 78 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.1 Ticket types and ordering . . . . . . . . . . . . . . . . . 13 80 5.2 Origin application processing . . . . . . . . . . . . . . . 14 81 5.2.1 Ticket requests . . . . . . . . . . . . . . . . . . . . 14 82 5.2.2 Ticket identification . . . . . . . . . . . . . . . . . 14 83 5.2.3 Ticket use . . . . . . . . . . . . . . . . . . . . . . . 14 84 5.2.4 Ticket scope . . . . . . . . . . . . . . . . . . . . . . 15 85 5.3 Origin network processing . . . . . . . . . . . . . . . . . 15 86 5.4 Peer host processing . . . . . . . . . . . . . . . . . . . . 16 87 5.5 Processing reflected tickets . . . . . . . . . . . . . . . . 16 88 5.5.1 Network processing . . . . . . . . . . . . . . . . . . . 16 89 5.5.2 Host processing . . . . . . . . . . . . . . . . . . . . 17 90 5.6 Handling dropped extension headers . . . . . . . . . . . . . 17 91 5.6.1 Mitigation for dropped extension headers . . . . . . . . 17 92 5.6.2 Fallback for dropped extension headers . . . . . . . . . 17 94 6 Implementation considerations . . . . . . . . . . . . . . . . . 18 95 6.1 Origin applications . . . . . . . . . . . . . . . . . . . . 18 96 6.2 Ticket reflection . . . . . . . . . . . . . . . . . . . . . 19 97 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 19 98 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19 99 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 9.1 Normative References . . . . . . . . . . . . . . . . . . . 20 101 9.2 Informative References . . . . . . . . . . . . . . . . . . 20 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1 Introduction 106 Firewall and Service Tickets (FAST) is a technique to allow an 107 application to signal to the network requests for admission and 108 services for a flow. A ticket is data that is attached to a packet by 109 the source that is inspected and validated by intermediate nodes in a 110 network. Tickets express a grant or right for packets to traverse a 111 network or have services applied to them. 113 An application requests tickets for admission or services from a 114 ticket agent in their local network. The agent issues tickets to the 115 application which in turn attaches these to its packets. In the 116 forwarding path, intermediate network nodes interpret tickets and 117 apply requested services on packets. 119 Tickets are validated for authenticity by the network and contain an 120 expiration time so that they cannot be easily forged. Tickets do not 121 have a global interpretation, they can only be interpreted within the 122 network that issues them. In order to apply services to inbound 123 packets for a communication, remote peers reflect received tickets in 124 packets they send without interpreting them. Tickets are stateless 125 within the network, however can be used to attain per flow semantics. 126 Firewall and service tickets are are non-transferable and revocable. 128 Tickets are coded in IPv6 Hop-by-Hop or Destination options. 130 2 Motivation 132 This section presents the motivation for Firewall and Service 133 Tickets. 135 2.1 Current mechanisms 137 Current solutions for controlling admission to the network and 138 requesting services are mostly ad hoc and architecturally limiting. 140 2.1.1 Stateful firewalls and proxies 142 Stateful firewalls and proxies are the predominantly deployed 143 techniques to control access to a network on a per flow basis. While 144 they provide some benefits of security, they have also break the end- 145 to-end model and have otherwise restricted the Internet in several 146 ways: 148 o They require parsing over transport layer headers in the fast 149 path of forwarding. 151 o They are limited to work only with a handful of protocols and 152 protocol features thereby ossifying protocols. 154 o They break the ability to use mulithoming and multipath. All 155 packets for a flow must traverse a specific network device in 156 both directions of a communication. 158 o They can break end to end security. NAT for instance breaks the 159 TCP authentication option. 161 o They have created single points of failure and become network 162 bottlenecks. 164 2.1.2 QoS signaling 166 In the current Internet, there is little coordination between hosts 167 and the network to provide services based on characteristics of the 168 application. Differentiated services provides an IP layer means to 169 classify and manage traffic, however it is lacking in richness of 170 expression and lacks a ubiquitous interface that allows applications 171 to request service with any granularity. Without additional state, 172 there is no means for the network infrastructure to validate that a 173 third party application has requested QoS that adheres to network 174 policies. 176 2.1.3 Deep packet inspection 178 Some network devices perform Deep Packet Inspection (DPI) into the 179 application data to determine whether to admit packets or what 180 services to apply. For instance, HTTP is commonly parsed to determine 181 URL, content type, and other application level information the 182 network is interested in. DPI can only be effective with the 183 application layer protocols that a device is programmed to parse. 184 More importantly, application level DPI is being effectively 185 obsoleted in the network due the pervasive use of TLS. TLS 186 interception and SSL inspection, whereby an intermediate node 187 implements a proxy that decrypts a TLS session and re-encrypts, is 188 considered a security vulnerability [TLSCERT]. 190 2.2 Alternative proposals 192 This section surveys some proposals to address the need for 193 applications to signal the network. 195 2.2.1 SPUD/PLUS 197 SPUD (Session Protocol Underneath Datagrams) [SPUD] and its successor 198 PLUS (Path Layer UDP Substrate) [PLUS] proposed a UDP based protocol 199 to allow applications to signal a rich set of characteristics and 200 service requirements to the network. 202 SPUD has a number of drawbacks: 204 o SPUD is based on a specific protocol used over UDP. This requires 205 applications to change to use a new protocol. In particular SPUD 206 is incompatible with TCP which is the predominant transport 207 protocol on the Internet. 209 o SPUD requires that intermediate nodes parse and process UDP 210 payloads. Since UDP port numbers do not have global meaning 211 [RFC7605] there is the possibility of misinterpretation and of 212 silent data corruption if intermediate nodes modify UDP payloads. 213 SPUD attempts to mitigate this issue with the use of magic 214 numbers, however that can only ever be probabilistically correct. 216 o SPUD included stateful flow tracking in the network. This 217 problematic because: 219 o Not all communications have well defined connection semantics. 220 For instance, a unidirectional data stream has no connection 221 semantics at all. 223 o Stateful network devices breaks multi-homing; they assume that 224 all packets of a flow in both directions are seen by the node 225 doing tracking flow state. Stateful firewalls, for instance, 226 require all packets for a flow to always go through the same 227 device in both directions. This disallows flexibility and 228 optimized traffic flow that a multi-homed network affords. 230 o The meta data information in SPUD would have global definition. 231 This problematic because: 233 o Application specific information could be leaked to unknown 234 and untrusted parties. 236 o Establishing a specification on what data should be conveyed 237 in SPUD will be difficult. Different service providers may 238 want different pieces of information, applications may also 239 have different ideas about what information is safe to make 240 visible. 242 2.2.2 Path aware networking 244 Path aware networking (PAN) [PAN] is an IRTF effort to allow 245 applications to select paths through the Internet for their traffic. 246 The idea is that in choosing different paths an application can 247 select form the different characteristics that are associated with 248 different paths. Path aware networking requires a means to express 249 the various paths and their associated characteristics to 250 applications. In the data path, a method to express desired path for 251 a packet is needed-- this presumably could be by a mechanism such as 252 segment routing. 254 PAN and FAST have similar characteristics, particularly with respect 255 to the need for applications and networks to communicate about 256 network path characteristics. However, where PAN presumably endeavors 257 to allow path selection by an application, FAST allows applications 258 to select their desired path characteristics and it is up to the 259 network to select the actual path. This distinction is important to 260 maximize flexibility, especially in situations where providing any 261 detailed path information to untrusted end device is a security risk 262 (which would be the typical case in a provider network). 264 2.3 Emerging use cases 266 In a typical client/server model of serving content, end host clients 267 communicate with servers on the Internet. Clients are typically user 268 devices that are connected to the Internet through a provider 269 network. In the case of mobile devices, such as smart phones, the 270 devices are connected to the Internet through a mobile provider 271 network. Content providers (web servers and content caches) tend to 272 be more directly connected to the Internet, the largest of which can 273 connect at exchange points. 275 Provider networks can be architected to provide different services 276 and levels of services to their users based on characteristics of 277 applications. For example, a mobile carrier network can provide 278 different latency and throughput guarantees for different types of 279 content. A network may offer different services for optimizing video: 280 streaming an HD movie might need high throughput but not particularly 281 low latency; a live video chat might have lower throughput demands 282 but have stringent low latency requirements. 284 The emerging 3GPP standard for 5G defines a set of mechanisms to 285 provide a rich array of services for users. These mechanisms employ 286 Network Function Virtulization (NFV), Service Function Chaining 287 (SFC), and network slices that divide physical network resources into 288 different virtualized slices to provide different services. To make 289 use of these mechanisms the applications running in UEs (User 290 Equipment) will need to indicate desired services of the RAN (Radio 291 Access Network). For instance, a video chat application may request 292 bounded latency that is implemented by the network as a network 293 slice; so packets sent by the application should be mapped to that 294 network slice. 296 Note that an application service applies to both packets sent by an 297 end node and those sent from a peer towards the end node. For the 298 latter case, the network needs to be able to map packets sent from 299 hosts on the Internet to the services requested by the receiving 300 application. 302 3 Architecture 304 The figure below illustrates an example network path between two 305 hosts on the Internet. Each host connects to the Internet via a 306 provider network, and provider networks are connected in the Internet 307 by transit networks. 308 _____ 309 __________ ( ) __________ 310 +--------+ ( ) ( ) ( ) +--------+ 311 | User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 2 | 312 +--------+ (__________) ( ) (__________) +--------+ 313 (_____) 315 Figure 1 317 Within each provider network, services may be provided on behalf of 318 the users of the network. In the figure above, Provider 1 may provide 319 services and service agreements for users in its network including 320 User 1; and likewise Provider B can provide services to users in its 321 network including User 2. Transit networks service all users and 322 don't typically provide user specific services or service 323 differentiation. 325 Services provided by different provider networks may be very 326 different and dependent on the implementation of the network as well 327 as the policies of the provider. 329 Based on this model, services and service differentiation can be 330 considered local to each network provider. FAST is a mechanism 331 whereby each user and application can request from its local provider 332 the services to be applied to its traffic. A request for service is 333 made to a FAST "ticket agent". The contents of the request describe 334 the services that application desires. The ticket agent responds with 335 a "ticket" that the application sets in its packets. When a packet is 336 sent by the application with a ticket attached, the ticket is 337 interpreted in the provider network to allow the packet to traverse 338 the network and to map the packet to the appropriate services. The 339 ticket is only relevant to the provider network of the application, 340 to the application itself and nodes outside of the provider network 341 the ticket is only an uinterpretable opaque object. 343 To facilitate network traversal and service mapping in the reverse 344 direction for a flow, that is packets sent from a peer host, peer 345 hosts reflect tickets without modification or interpretation. This is 346 done by saving the ticket received in packets of a flow and attaching 347 that as a reflected ticket to packets being sent on the flow. 349 The use of tickets may be bilateral for a connection so that each 350 peer requests service from its local network. Therefore packets may 351 contain two types of tickets: one that is set by the sending host to 352 signal its local provider network, and the other is the reflected 353 ticket that is a signal to the provider network of the peer endpoint. 355 Tickets are scoped values, they only have meaning in the network in 356 which they were issued. The format, meaning, and interpretation of 357 tickets is network specific. By mutual agreement, two networks may 358 share the policy and interpretations of tickets. For instance, there 359 could be an agreement between two provider networks to interpret each 360 others tickets or to use a common format. 362 3.1 Example packet flow 364 Referencing the diagram in figure 1, consider that User 1 is 365 establishing a video chat with User 2 and wishes to have low latency 366 service for video applied by its local network (Provider 1). The flow 367 of events may be: 369 1. User 1 makes a ticket request to a ticket agent of Provider A 370 that describes the video application and may include detailed 371 characteristics such as resolution, frame rate, latency, etc. 373 2. The ticket agent issues a ticket to User 1 that indicates that 374 packets of the flow have a right to traverse the network and 375 the services to be applied to the packets of the flow. 377 3. The video chat application sends packets with the ticket 378 attached for the video chat. 380 4. The first hop node in Provider A's network interprets the 381 ticket in packets and applies the appropriate services (e.g. 382 sets diffserv, forwards on a network slice, encapsulates in 383 MPLS, etc.). 385 5. Packets traverse Provider A's network with the appropriate 386 services being applied. 388 6. Packets traverse transit networks and Provider B network, the 389 attached tickets are ignored. 391 7. Packets are received at User 2. Attached tickets are saved in 392 the context of the flow for the video chat. 394 8. User 2's video chat application sends packets to User 1. The 395 last ticket previously received from User 1 is now reflected in 396 these packets. 398 9. Packets traverse Provider B network and transit networks, the 399 reflected ticket is ignored. 401 10. An ingress node in Provider A's network interprets the 402 reflected tickets and applies appropriate services to the 403 packets for traversing the local network. 405 11. Packets are forwarded within Provider's A network with the 406 appropriate services applied. No other intermediate nodes 407 should need to interpret the tickets. 409 12. Packets are received at the host for User 1. The reflected 410 ticket is validated by comparing the received ticket with that 411 being sent for the flow. It the ticket is determined valid then 412 the packet is accepted. 414 3.2 Requirements 416 The requirements for Firewall and Service Tickets are: 418 o Tickets MUST be stateless within the network. In particular 419 intermediate nodes MUST NOT be required to create and maintain 420 state for transport layer connections. 422 o Tickets MUST work in a multi-homed and multi-path environments. 424 o Outside of the network that issued a ticket, tickets MUST be 425 opaque and obfuscated so that no application specific 426 information is derivable. 428 o Tickets MUST work with any transport protocol as well as in the 429 presence of any IP protocol feature (e.g. other extension 430 headers are present). 432 o Tickets SHOULD minimize the changes to an application. Their use 433 should be an "add-on" to the existing communications of an 434 application. 436 o Tickets MUST deter spoofing and other misuse that might result 437 in illegitimate use of network services or denial of service 438 attack. 440 o Tickets MUST be contained in the IP layer protocol. In 441 particular, tickets MUST NOT require parsing transport layer 442 headers. 444 o Tickets MUST allow services to be applied in the return path of 445 a communication. In a client/server application it is often the 446 packets in the reverse path that require the most service (for 447 instance if a video is being streamed to a client). 449 o A fallback MUST be present to handle the case that extension 450 headers are dropped within the network or a peer node does not 451 reflect tickets. A fallback allows functional communications but 452 provides it in a degrade mode of service. 454 4 Packet format 456 A ticket is sent as Destination option or a Hop-by-Hop option. 458 4.1 Option format 460 The same option types and format are used for both a Destination and 461 Hop-by-Hop option. The format of the option is: 463 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Option Type | Opt Data Len | Type | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 468 | | 469 ~ Ticket ~ 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Fields: 475 o Option type: Type of Hop-by-Hop or Destination option. This 476 document proposes two possible values for ticket: an 477 unmodifiable and a modifiable variant. 479 o Opt Data Len: Length of the option data field. This is two plus 480 the length of the ticket field 482 o Type: Indicates the type and reflection property of the ticket. 483 This is one of: 485 o 0x0: Ticket from origin, don't reflect at receiver 487 o 0x1: Ticket from origin, reflect at receiver 488 o 0x2: Reflected ticket 490 o 0x3-0xf: Reserved 492 4.2 Option types 494 A ticket may be sent as a Destination option or Hop-by-Hop option. 495 The rationale is that the two methods exhibit different drop rates. 496 For instance, [RFC7872] indicates that the drop rate to Alexa's Top 497 1M Sites for Destination options was 10.91%, whereas Hop-by-Hop 498 options have a drop rate of 39.03% 500 The are two option numbers requested for the ticket option: 0x0F and 501 0x2F. The latter allows modification. This would be used in 502 situations where the network nodes needed to modify the option with 503 new information. If the option is modifiable it SHOULD be a Hop-by- 504 Hop option. 506 4.3 Ticket format 508 A ticket encodes service parameters that describe the desired 509 services as well as additional fields that would be used to provide 510 privacy and integrity. 512 The format of a ticket is defined by the network in which the ticket 513 is issued. A ticket should be obfuscated or encrypted for privacy so 514 that only the local network can interpret it. It should be 515 uniterpretable to any nodes outside the network and to the 516 application or host that is granted a ticket. It should be resistant 517 to spoofing so that an attacker cannot illegitimately get service by 518 applying a ticket seen on other flows. 520 It is recommended that tickets are encrypted and each ticket has an 521 expiration time. For instance, a ticket may be created by encrypting 522 the ticket data with an expiration time and using the source address, 523 destination address, and a shared key as the key for encryption. 525 For example, a ticket with an expiration time may have the format: 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Expiration time | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | | 532 ~ Service parameters ~ 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Where the expiration time is in a format understood by the local 536 network nodes which maintain synchronized time. The Service 537 parameters are relevant to network nodes and describe the services to 538 be applied. The service parameters could simply be a set of flags for 539 services, an index to a service profile known by the network nodes, 540 or possibly have more elaborate structure that could indicate 541 numerical values for characteristics that have a range. The service 542 parameters could also include a type field to allow a network to 543 define different representations of service parameters. 545 A simple ticket containing a service protocol index might be: 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Expiration time | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type | Service Profile Index | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Where Type indicates the type of ticket and in this case indicates it 555 is a service profile index. Service Profile Index could be an index 556 into a table that describes the services to be applied. 558 5 Operation 560 5.1 Ticket types and ordering 562 There are three types of tickets that may be contained in a packet: 564 o origin tickets that are not reflected 566 o origin tickets to be reflected 568 o reflected tickets 570 Origin tickets are those set by an application that was issued a 571 ticket and have an additional property indicating whether they are to 572 be reflected by a peer host. Reflected tickets are those that have 573 been received and reflected by a peer host. 575 A sender SHOULD set at most one of each type of ticket in a packet. 576 If different types of ticket are sent with single packet they SHOULD 577 have the following ordering: 579 1. origin tickets that are not reflected 581 2. origin tickets to be reflected 582 3. reflected tickets 584 5.2 Origin application processing 586 An origin application requests tickets, sets them in packets, and 587 validates reflected tickets. 589 5.2.1 Ticket requests 591 An application that wishes to use network services first requests 592 tickets from a ticket agent. The application request could be in the 593 form of an XML structure with a canonical elements (the definition is 594 outside the scope of this document). The application makes a request 595 to the ticket agent for the local network. This could be done via a 596 web service using HTTP PUT/GET. Internally in the host, the ticket 597 agent might be accessed through a library that interfaces to a ticket 598 daemon that in turn arbitrates requests between the applications and 599 a ticket agent in the network. 601 An issued ticket is opaque to the application and the application 602 should not attempt to interpret it or take any other action other 603 than attaching the ticket to its packets. 605 A ticket agent MAY provide both a origin ticket not to be reflected 606 and one that is to be reflected. The intent is that different tickets 607 can be used between the outbound and inbound paths for the flow. In 608 the case that two tickets are provided, the origin ticket not to be 609 reflected MUST appear first in the options list. 611 5.2.2 Ticket identification 613 Tickets are valid for a specific IP source and destination address 614 for which they were issued. Transport layer ports and other transport 615 layer information are not included ticket identification, however an 616 application can request tickets and validate reflected tickets on a 617 per flow basis. Issued tickets are stored in the flow context and the 618 saved information is used to validate reflected tickets. 620 5.2.3 Ticket use 622 When the ticket agent issues an returns a ticket, the application 623 sets the ticket as a Hop-by-Hop option or Destination option as 624 specified. This is typically done by setting socket option on a 625 socket (in the case of TCP) or by indicating the option in the 626 ancillary data when sending on a unconnected socket (in the case of 627 UDP). The application SHOULD continue to use the same ticket for the 628 flow until it is updated with a new ticket. 630 The ticket agent SHOULD return an expiration time with the ticket. An 631 application can use the ticket until the expiration time, at which 632 point it can request a new ticket to continue communications. In 633 order to make the ticket transition process seamless an application 634 MAY request a new ticket before the old one expires. 636 A host SHOULD set in a packet at most one origin ticket not to be 637 reflected and one origin ticket to be reflected. 639 5.2.4 Ticket scope 641 Tickets are valid for a specific IP source and destination address 642 for which they were issued. Transport layer ports and other transport 643 layer information are not included ticket identification, however an 644 application can request tickets and validate reflected tickets on a 645 per flow basis. Issued tickets are stored in the flow context and the 646 saved information is used to validate reflected tickets. 648 A network MAY delegate creation of tickets to hosts in a limited 649 fashion. This would entail the network ticket agent issuing a master 650 ticket to a host ticket agent which in turn can use the master ticket 651 to create a limited number of tickets. The details of ticket agent 652 delegation are outside the scope of this document. 654 5.3 Origin network processing 656 When a packet with a ticket enters a network, a network node can 657 determine if the ticket originated in its network and must be 658 processed. This is done by considering the origin of the ticket and 659 the source or destination IP address. For an origin ticket (i.e. 660 ticket is not reflected), the source address is considered. If the 661 source address is local to the network then the ticket can be 662 interpreted. For a reflected ticket, the destination address is 663 considered. If the destination address is local to the network then 664 the ticket can be interpreted. 666 If a ticket origin is determined to be the local network then the 667 ticket is processed. The ticket is decrypted if necessary and the 668 expiration time is checked. If the ticket is verified to be authentic 669 and valid then the packet is mapped to be processed by the requested 670 services. For instance, in a 5G network the packet may be forwarded 671 on a network slice for the characteristics the application has 672 requested (real-time video for instance). 674 Note that there are logically only two ingress points into the 675 network at which a provider needs to process tickets: when a local 676 user sends a packet into the provider network with an origin ticket, 677 and when a packet from an external network enters the provider's 678 network with a reflected ticket. Any ticket should be processed at 679 most once within a network. Once a ticket is processed and mapped to 680 the network's service mechanisms it should not need further 681 examination. 683 If there is more than one origin ticket present, then the first one 684 encountered is processed and any additional origin tickets SHOULD be 685 ignored by a network node. Note that this will be the case if a 686 ticket agent issued both a origin ticket not to be reflected and one 687 to be reflected; the ticket not to be reflected should appear first 688 in the packet and thus would be the one processed by the node. 690 If there is more than one reflected ticket present, then the first 691 one encountered is processed and any additional reflected tickets 692 SHOULD be ignored. 694 5.4 Peer host processing 696 When a host receives a packet with a ticket whose type is "from 697 origin and needs to be reflected", it SHOULD save the ticket in its 698 flow context and reflect it on subsequent packets. When the 699 application reflects the option, it copies the whole option and only 700 modifies the type to indicate a "reflected ticket". The application 701 SHOULD continue to reflect the ticket until a different one is 702 received from the origin or a packet without a service ticket option 703 is received on the flow. Note that the latest ticket that is received 704 is the one to be reflected, if packets have been received out of 705 order for a flow it is possible that the reflected ticket is from an 706 earlier packet in a flow. 708 If there is more than one origin ticket to be reflected present, then 709 the first one encountered is processed and any additional origin 710 tickets to be reflected SHOULD be ignored. 712 A peer host MUST ignore received origin tickets that are not to be 713 reflected. 715 5.5 Processing reflected tickets 717 5.5.1 Network processing 719 When a packet with a reflected ticket enters the origin network of 720 the ticket, the ticket MUST be processed. The ticket is validated. 721 Validation entails decoding or decrypting the ticket and checking the 722 expiration time. If the ticket is valid and has not expired time then 723 the packet is verified for forwarding. 725 A network MAY accept expired reflected tickets for some configurable 726 period after the expiration time. Rate limiting SHOULD be applied to 727 packets with expired reflected tickets. Accepting expired tickets is 728 useful in the case that a connection goes idle and after sometime the 729 remote peer starts to send. The ticket it reflects may be expired and 730 presumably the receiving host will quickly respond with a new ticket. 732 5.5.2 Host processing 734 Upon receiving a packet with a reflected ticket an end host MUST 735 validate the ticket before accepting the packet. This verification is 736 done by comparing the received ticket to that which is set to be sent 737 on the corresponding flow. If the tickets do not match then the 738 packet is dropped and the event SHOULD be logged. 740 A host SHOULD retain and validate expired tickets that are reflected 741 to allow a peer time to receive and reflect an updated ticket. 743 5.6 Handling dropped extension headers 745 The downside of using IPv6 extension headers on the Internet is that 746 they are currently not completely reliable. Some intermediate nodes 747 will drop extension headers with rates described in [RFC7872]. 749 5.6.1 Mitigation for dropped extension headers 751 There are some mitigating factors for this problem: 753 o A provider network that implements tickets would need to ensure 754 that extension headers are at least usable within their network. 756 o Transit networks are less likely to arbitrarily drop packets 757 with extension headers. 759 o Many content providers, especially the larger ones, may be 760 directly connected to the Internet. For example, front end web 761 servers may be co-located as exchange points. 763 o The requirement that nodes must process Hop-by-hop options has 764 been relaxed in [RFC8200]. It is permissible for intermediate 765 nodes to ignore them. 767 o Increased deployment of IPv6 and viable use cases of extension 768 headers, such as described here, may motivate vendors to fix 769 issues with extension headers. 771 5.6.2 Fallback for dropped extension headers 773 Since the possibility that extension headers are dropped cannot be 774 completely eliminated, a fallback is included for use with tickets. 776 When an application connects to a new destination for which it has no 777 history about the viability of extension headers, it can perform a 778 type of Happy Eyeballs probing. The concept is for a host to send a 779 number of packets with and without tickets. The application can 780 observe whether packets with tickets are being dropped or not being 781 reflected. 783 There are a few possible outcomes of this process: 785 o A packet with a ticket is dropped and an ICMP for extension 786 headers [ICMPEH] processing limits is received. This is a strong 787 signal that extension headers are not viable to the destination 788 and should not be used for the flow. 790 o A packet with a ticket is dropped and no ICMP error is received. 791 This is a signal that extension headers may not be usable. If 792 such drops are observed for all or a significant fraction of 793 packets and there are no drops for packets that were sent 794 without tickets, then extension headers should be considered not 795 viable for the flow. 797 o Packets with tickets are not being dropped, however tickets are 798 not being reflected. This is a signal that the peer application 799 does not support reflection. Tickets may be sent, however they 800 are only useful in the outbound path. 802 o Packet with tickets are not being dropped and tickets are 803 properly being reflected. Tickets are useful in both directions. 805 If extension headers are found to not be viable or tickets are not 806 being properly reflected, a possible fallback is to not use tickets. 807 In this case, communications might remain functional, however they 808 would be operate in a degraded mode of service. The network may 809 fallback to creating per flow state in the network; the ticket that 810 an application sent with packets during probing could be used to 811 instantiate the service characteristics maintained in a flow state. 813 6 Implementation considerations 815 6.1 Origin applications 817 Existing client applications can be modified to request tickets and 818 set them in packets. The kernel may need some small changes or 819 configuration to enable an application to specify the option for its 820 packets. 822 The interface to the ticket agent would likely be via a library API. 824 Using the BSD sockets interface, for a connected socket (TCP, SCTP, 825 or connected UDP socket) a Hop-by-Hop or Destination option can be 826 set on the socket via the setsockopt system call. For an unconnected 827 socket (UDP) the ticket option can be set as ancillary data in the 828 sendmsg system call. 830 Happy Eyeballs for extension headers, described in section 5.6.2, 831 could be implemented in the kernel for a connection oriented 832 transport protocol such a TCP. For connectionless protocols, probing 833 could be handled by an application library. 835 6.2 Ticket reflection 837 To perform ticket reflection, servers must be updated. In the case of 838 a connected socket (TCP, SCTP, or a connected UDP socket) this can be 839 done as relatively minor change to the kernel networking stack which 840 would be transparent to applications. For unconnected UDP, an 841 application could receive the ticket as part of the ancillary data in 842 recvmsg system call, and then send the reflected ticket in a reply 843 using ancillary data in sendmsg. 845 7 Security Considerations 847 There are two main security considerations: 849 o Leakage of content specific information to untrusted third 850 parties must be avoided. 852 o Tickets cannot be forged or illegitimately used. 854 Tickets may be visible to the Internet including untrusted and 855 unknown networks in the path of sent packets. Therefore, tickets 856 should be encrypted or obfuscated by the origin network. 858 Tickets need to have an expiration time, must be resistant to 859 forgery, and must be nontransferable. A ticket should be valid for 860 the specific source and destination addresses that it was issued for. 861 Tickets are revocable by implemented a black-list contained revoked 862 tickets. 864 8 IANA Considerations 866 IANA is requested to assigned the following Destination and Hop-By- 867 Hop options: 869 +-----------+---------------+-------------+---------------+ 870 | Hex Value | Binary value | Description | Reference | 871 | | act chg rest | | | 872 +-----------+---------------+-------------+---------------+ 873 | 0x0F | 00 0 01111 | Firewall | This document | 874 | | | and Service | | 875 | | | Ticket | | 876 +-----------+---------------+-------------+---------------+ 877 | 0x2F | 00 1 01111 | Modifiable | This document | 878 | | | Firewall | | 879 | | | and Service | | 880 | | | Ticket | | 881 +-----------+---------------+-------------+---------------+ 883 IANA is requested to set up a registry for the Ticket types. These 884 types are 4 bit values. New values for control types 0x3-0xf are 885 assigned via Standards Action [RFC5226]. 887 +----------------+--------------------+---------------+ 888 | Ticket type | Description | Reference | 889 +----------------+--------------------+---------------+ 890 | 0x0 | Ticket from origin | This document | 891 | | and don't reflect | | 892 +----------------+--------------------+---------------+ 893 | 0x1 | Ticket from origin | This document | 894 | | and reflect | | 895 +----------------+--------------------+---------------+ 896 | 0x2 | Reflected ticket | This document | 897 +----------------+--------------------+---------------+ 899 9 References 901 9.1 Normative References 903 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 904 (IPv6) Specification", STD 86, RFC 8200, DOI 905 10.17487/RFC8200, July 2017, . 908 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 909 IANA Considerations Section in RFCs", RFC 5226, DOI 910 10.17487/RFC5226, May 2008, . 913 9.2 Informative References 915 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 916 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 917 August 2015, . 919 [RFC7872] Got, F., Linkova, J., Chown, T., and W. Liu, "Observations 920 on the Dropping of Packets with IPv6 Extension Headers in 921 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, 922 . 924 [TLSCERT] United States Computer Emergency Readiness Team (US-CERT), 925 "Alert (TA17-075A), HTTPS Interception Weakens TLS 926 Security, March 2017 928 [SPUD] Hildebrand, J. and Trammell, B., "Substrate Protocol for 929 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 930 prototype-03, March 2015 932 [PLUS] Trammell, B. and Kuehlewind, M., "Path Layer UDP Substrate 933 Specification", draft-trammell-plus-spec-01, March 2017 935 [PAN] Trammell, B., "Open Questions in Path Aware Networking", 936 draft-trammell-panrg-questions-02, December 2017 938 [ICMPEH] Herbert, T., "ICMPv6 errors for discarding packets due to 939 processing limits", draft-herbert-6man-icmp-limits-00.txt 941 Author's Address 943 Tom Herbert 944 Quantonium 945 Santa Clara, CA 946 USA 948 Email: tom@quantonium.net