idnits 2.17.1 draft-herbert-fast-04.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 444: '... o Tickets SHOULD be stateless wi...' RFC 2119 keyword, line 445: '...termediate nodes MUST NOT be required ...' RFC 2119 keyword, line 448: '... o Tickets MUST work in a multi-h...' RFC 2119 keyword, line 450: '... that issued a ticket, tickets MUST be...' RFC 2119 keyword, line 454: '... 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 (April 10, 2019) is 1842 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 (-13) exists of draft-carpenter-limited-domains-03 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: October 2019 6 April 10, 2019 8 Firewall and Service Tickets 9 draft-herbert-fast-04 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 services 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 IPv6 Hop-by-Hop options. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1 Current mechanisms . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.1 Stateful firewalls and proxies . . . . . . . . . . . . . 4 64 2.1.2 QoS signaling . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.3 Deep packet inspection . . . . . . . . . . . . . . . . . 5 66 2.2 Proposals for applications to signal the network . . . . . . 5 67 2.2.1 SPUD/PLUS . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.2.2 Path aware networking . . . . . . . . . . . . . . . . . 7 69 2.3 Emerging use cases . . . . . . . . . . . . . . . . . . . . . 7 70 3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 3.1 Example communications flow . . . . . . . . . . . . . . . . 9 72 3.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4 Packet format . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 4.1 Option format . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.2 Option types . . . . . . . . . . . . . . . . . . . . . . . . 12 76 4.3 Ticket format . . . . . . . . . . . . . . . . . . . . . . . 12 77 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 5.1 Origin and reflection properties and ordering . . . . . . . 14 79 5.2 Origin application processing . . . . . . . . . . . . . . . 14 80 5.2.1 Ticket requests . . . . . . . . . . . . . . . . . . . . 14 81 5.2.2 Ticket identification . . . . . . . . . . . . . . . . . 15 82 5.2.3 Ticket use . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.2.4 Ticket agent delegation . . . . . . . . . . . . . . . . 15 84 5.3 Origin network processing . . . . . . . . . . . . . . . . . 15 85 5.4 Peer host processing . . . . . . . . . . . . . . . . . . . . 16 86 5.5 Processing reflected tickets . . . . . . . . . . . . . . . . 17 87 5.5.1 Network processing . . . . . . . . . . . . . . . . . . . 17 88 5.5.2 Host processing . . . . . . . . . . . . . . . . . . . . 17 89 5.6 Handling dropped extension headers . . . . . . . . . . . . . 17 90 5.6.1 Mitigation for dropped extension headers . . . . . . . . 18 91 5.6.2 Fallback for dropped extension headers . . . . . . . . . 18 93 6 Implementation considerations . . . . . . . . . . . . . . . . . 19 94 6.1 Origin applications . . . . . . . . . . . . . . . . . . . . 19 95 6.2 Ticket reflection . . . . . . . . . . . . . . . . . . . . . 19 96 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 20 97 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 98 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 9.1 Normative References . . . . . . . . . . . . . . . . . . . 21 100 9.2 Informative References . . . . . . . . . . . . . . . . . . 21 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 1 Introduction 105 Firewall and Service Tickets (FAST) is a technique to allow an 106 application to signal to the network requests for admission and 107 services for packets. A ticket is data that is attached to a packet 108 by the source node, and it is then inspected and validated by certain 109 intermediate nodes in a network. Tickets express a grant or right for 110 packets to traverse a network or have services applied to them. 112 An application requests tickets for admission or services from a 113 ticket agent in their local network. The agent issues tickets to the 114 application which in turn attaches these to its packets. In the 115 forwarding path, intermediate network nodes may interpret tickets and 116 apply requested services on packets. 118 Tickets are validated for authenticity by the network and contain an 119 expiration time so that they cannot be easily forged. Tickets do not 120 have a global interpretation, they can only be interpreted within the 121 network or local domain ([LIMDOM]) that issues them. In order to 122 apply services to inbound packets for a communication, remote peers 123 reflect received tickets in packets they send without interpreting 124 them. Tickets are stateless within the network, however they can be 125 used to attain per flow semantics. Firewall and service tickets are 126 non-transferable and revocable. 128 Tickets are coded in IPv6 Hop-by-Hop 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 break the end-to-end 145 model and have otherwise restricted the Internet in several ways: 147 o They require parsing over transport layer headers in the fast 148 path of forwarding. 150 o They are limited to work only with a handful of protocols and 151 protocol features thereby ossifying protocols. 153 o They break the ability to use multi-homing and multi-path. All 154 packets for a flow must traverse a specific network device in 155 both directions of a communication. 157 o They can break end to end security. NAT for instance breaks the 158 TCP authentication option. 160 o They are single points of failure and network bottlenecks. 162 2.1.2 QoS signaling 164 In the current Internet, there is little coordination between hosts 165 and the network to provide services based on characteristics of the 166 application. Differentiated services provides an IP layer means to 167 classify and manage traffic, however it is lacking in richness of 168 expression and lacks a ubiquitous interface that allows applications 169 to request service with any granularity. Without additional state, 170 there is no means for the network infrastructure to validate that a 171 third party application requesting QoS adheres to network policies. 173 2.1.3 Deep packet inspection 175 Some network devices perform Deep Packet Inspection (DPI) into the 176 application data to determine whether to admit packets or what 177 services to apply. For instance, HTTP is commonly parsed to determine 178 URL, content type, and other application level information the 179 network is interested in. DPI can only be effective with the 180 application layer protocols that a device is programmed to parse. 181 More importantly, application level DPI is effectively obsoleted in 182 the network due the pervasive use of TLS. TLS interception and SSL 183 inspection, whereby an intermediate node implements a proxy that 184 decrypts a TLS session and re-encrypts, is considered a security 185 vulnerability [TLSCERT]. 187 2.2 Proposals for applications to signal the network 189 This section surveys some proposals to address the need for 190 applications to signal the network. 192 2.2.1 SPUD/PLUS 194 SPUD (Session Protocol Underneath Datagrams) [SPUD] and its successor 195 PLUS (Path Layer UDP Substrate) [PLUS] proposed a UDP based protocol 196 to allow applications to signal a rich set of characteristics and 197 service requirements to the network. 199 SPUD had a number of drawbacks: 201 o SPUD is based on a specific protocol used over UDP. This requires 202 applications to change to use a new protocol. In particular SPUD 203 is incompatible with TCP which is the predominant transport 204 protocol on the Internet. 206 o SPUD requires that intermediate nodes parse and process UDP 207 payloads. Since UDP port numbers do not have global meaning 208 [RFC7605] there is the possibility of misinterpretation and of 209 silent data corruption if intermediate nodes modify UDP payloads. 210 SPUD attempts to mitigate this issue with the use of magic 211 numbers, however that can only ever be probabilistically correct. 213 o SPUD included stateful flow tracking in the network. This 214 problematic because: 216 o Not all communications have well defined connection semantics. 217 For instance, a unidirectional data stream has no connection 218 semantics at all. 220 o Stateful network devices breaks multi-homing and multi-path; 221 they assume that all packets of a flow in both directions are 222 seen by the node doing tracking flow state. Stateful 223 firewalls, for instance, require all packets for a flow to 224 always go through the same device in both directions. This 225 disallows flexibility and optimized traffic flow that a multi- 226 homed network affords. 228 o Maintaining per flow state in the network is an obvious 229 scaling problem. 231 o Keepalives to maintain a network state in a device, such as 232 those sent to prevent a NAT state from being evicted, carry no 233 useful information to the end user and in large numbers can 234 become a source of congestion. 236 o The meta data information in SPUD would have global definition. 237 This problematic because: 239 o Application specific information could be leaked to unknown 240 and untrusted parties. 242 o Establishing a specification on what data should be conveyed 243 in SPUD will be difficult. Different service providers may 244 want different information, applications may also have 245 differing requirements about what is safe to make visible. 247 2.2.2 Path aware networking 249 Path aware networking (PAN) [PAN] is an IRTF effort to allow 250 applications to select paths through the Internet for their traffic. 251 The idea is that in choosing different paths an application can 252 select from the different characteristics that are associated with 253 different paths. Path aware networking requires a means to express 254 the various paths and their associated characteristics to 255 applications. In the data path, a method to express desired path for 256 a packet is needed-- this presumably could be by a mechanism such as 257 segment routing. 259 PAN and FAST have similar characteristics, particularly with respect 260 to the need for applications and networks to communicate about 261 network path characteristics. However, where PAN presumably endeavors 262 to allow path selection by an application, FAST allows applications 263 to select their desired path characteristics and it is up to the 264 network to select the actual path. This distinction is important to 265 maximize flexibility, especially in situations where providing any 266 detailed path information to untrusted end device is a security risk 267 (which is typical in a provider network or on the Internet). 269 2.3 Emerging use cases 271 In a typical client/server model of serving content, end host clients 272 communicate with servers on the Internet. Clients are typically user 273 devices that are connected to the Internet through a provider 274 network. In the case of mobile devices, such as smart phones, the 275 devices are connected to the Internet through a mobile provider 276 network. Content providers (web servers and content caches) tend to 277 be more directly connected to the Internet, the largest of which can 278 connect at exchange points. 280 Provider networks can be architected to provide different services 281 and levels of services to their users based on characteristics of 282 applications. For example, a mobile carrier network can provide 283 different latency and throughput guarantees for different types of 284 content. A network may offer different services for optimizing video: 285 streaming an HD movie might need high throughput but not particularly 286 low latency; a live video chat might have lower throughput demands 287 but have stringent low latency requirements. 289 The emerging 3GPP standard for 5G defines a set of mechanisms to 290 provide a rich array of services for users. These mechanisms employ 291 Network Function Virtulization (NFV), Service Function Chaining 292 (SFC), and network slices that divide physical network resources into 293 different virtualized slices to provide different services. To make 294 use of these mechanisms, the applications running in UEs (User 295 Equipment) will need to indicate desired services of the RAN (Radio 296 Access Network). For instance, a video chat application may request 297 bounded latency that is implemented by the network as a network 298 slice; so packets sent by the application should be mapped to that 299 network slice. 301 Note that network services requested by applications are relevant to 302 both packets sent by an end node and those sent from a peer towards 303 the end node. For the latter case, the network needs to be able to 304 map packets sent from hosts on the Internet to the services requested 305 by the receiving application. 307 3 Architecture 309 The figure below illustrates an example network path between two 310 hosts on the Internet. Each host connects to the Internet via a 311 provider network, and provider networks are connected in the Internet 312 by transit networks. 313 _____ 314 __________ ( ) __________ 315 +--------+ ( ) ( ) ( ) +--------+ 316 | User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 2 | 317 +--------+ (__________) ( ) (__________) +--------+ 318 (_____) 320 Figure 1 322 Within each provider network, services may be provided on behalf of 323 the users of the network. In the figure above, Provider 1 may provide 324 services and service agreements for users in its network including 325 User 1; and likewise Provider B can provide services to users in its 326 network including User 2. Transit networks don't typically provide 327 user specific services or service differentiation. 329 Services provided by different provider networks may be very 330 different and dependent on the implementation of the network as well 331 as the policies of the provider. 333 Based on this model, services and service differentiation can be 334 considered local to each network provider. FAST is a mechanism 335 whereby each user and application can request from its local provider 336 the services to be applied to its traffic. A request for service is 337 made to a FAST "ticket agent". The contents of the request describe 338 the services that the application desires. The ticket agent responds 339 with a "ticket" that the application sets in its packets. When a 340 packet is sent by the application with a ticket attached, the ticket 341 is interpreted in the provider network to allow the packet to 342 traverse the network and to map the packet to the appropriate 343 services. The ticket is only relevant to the provider network that 344 issued the ticket, to the application itself and nodes outside of the 345 provider network the ticket is an uinterpretable opaque object. 347 To facilitate network traversal and service mapping in the reverse 348 direction for a flow, that is packets sent from a peer host, peer 349 hosts reflect tickets without modification or interpretation. This is 350 done by saving the ticket received in packets of a flow and attaching 351 that as a reflected ticket to packets being sent on the flow. 353 The use of tickets may be bilateral for a flow so that each peer 354 requests service from its local network. Therefore packets may 355 contain two types of tickets: one that is set by the sending host to 356 signal its local provider network, and the other is the reflected 357 ticket that is a signal to the provider network of the peer endpoint. 359 Tickets are scoped values, they only have meaning in the network in 360 which they were issued. The format, meaning, and interpretation of 361 tickets is network specific. By mutual agreement, two networks may 362 share the policy and interpretations of tickets. For instance, there 363 could be an agreement between two provider networks to interpret each 364 others tickets or to use a common format. 366 3.1 Example communications flow 368 Figure 2 provides an example communications flow using FAST. 370 1. Ticket +--------+ 371 request +------------> | Ticket | 372 / +---------- | Agent | 373 +---+ / 2. Ticket +--------+ 374 / +-----+ reply ______ 375 / v __________ ( ) 376 +--------+ ( ) ( ) +--------+ 377 | Client +----------( Provider A )--( Internet )---+ Server | 378 +--------+ (__________) ( ) +--------+ 379 (______) 381 3. App sends, 4,5. Net applies 6. Ignore ticket 7,8. Server 382 ticket attached services in Internet reflect 383 -------------------> -----------------> --------------------+ 384 \ 385 Reverse path / 386 <------------------ <----------------- <--------------------+ 387 12. Validate 10,11. Network applies 9. Ignore ticket 388 reflected ticket services in Internet 390 Figure 2 392 Referencing figure 2, consider that the Client is establishing a 393 video chat with the Server and wishes to have low latency service for 394 video applied by its local network (Provider A). The flow of events 395 may be: 397 1. The Client makes a ticket request to a ticket agent of Provider 398 A that describes the video application and may include detailed 399 characteristics such as resolution, frame rate, latency, etc. 401 2. The ticket agent issues a ticket to the Client that indicates 402 that packets of the flow have a right to traverse the network 403 and the services to be applied to the packets of the flow. 405 3. The video chat application sends packets with the ticket 406 attached for the video chat. 408 4. The first hop node in Provider A's network interprets the 409 ticket in packets and applies the appropriate services (e.g. 410 sets diffserv, forwards on a network slice, encapsulates in 411 MPLS, encapsulates with segment routing, etc.). 413 5. Packets traverse Provider A's network with the appropriate 414 services being applied. 416 6. Packets traverse transit networks and the Server's provider 417 network, the attached tickets are ignored. 419 7. Packets are received at the Server. Attached tickets are saved 420 in the context of the flow for the video chat. 422 8. The Server's video chat application sends packets back to the 423 Client. The last ticket previously received from the Client is 424 now reflected in these packets. 426 9. Packets traverse the Server's provider network and transit 427 networks, the reflected ticket is ignored. 429 10. An ingress node in Provider A's network interprets the 430 reflected ticket and applies appropriate services to the 431 packets for traversing the local network. 433 11. Packets are forwarded within Provider's A network with the 434 appropriate services applied. 436 12. Packets are received at the host for the Client. The reflected 437 ticket is validated by comparing the received ticket with that 438 being sent for the flow. 440 3.2 Requirements 442 The requirements for Firewall and Service Tickets are: 444 o Tickets SHOULD be stateless within the network. In particular 445 intermediate nodes MUST NOT be required to create and maintain 446 state for transport layer connections. 448 o Tickets MUST work in a multi-homed and multi-path environments. 450 o Outside of the network that issued a ticket, tickets MUST be 451 opaque and obfuscated so that no application specific 452 information is derivable. 454 o Tickets MUST work with any transport protocol as well as in the 455 presence of any IP protocol feature (e.g. other extension 456 headers are present). 458 o Tickets SHOULD minimize the changes to an application. Their use 459 should be an "add-on" to the existing communications of an 460 application. 462 o Tickets MUST deter spoofing and other misuse that might result 463 in illegitimate use of network services or denial of service 464 attack. 466 o Tickets MUST be contained in the IP layer protocol. In 467 particular, FAST MUST NOT require parsing transport layer 468 headers. 470 o Tickets MUST allow services to be applied in the return path of 471 a communication. In a client/server application it is often the 472 packets in the reverse path that require the most service (for 473 instance if a video is being streamed to a client). 475 o A fallback MUST be present to handle the case that extension 476 headers are dropped within the network or a peer node does not 477 reflect tickets. A fallback allows functional communications but 478 provides it in a potentially degraded mode of service. 480 4 Packet format 482 A ticket is sent in a Hop-by-Hop option. 484 4.1 Option format 486 The format of an Hop-by-Hop option containing a ticket is: 488 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Option Type | Opt Data Len | Prop | Rsvd | Type | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | | 494 ~ Ticket ~ 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Fields: 500 o Option type: Type of Hop-by-Hop option. This document proposes 501 two possible values for ticket: an unmodifiable and a modifiable 502 variant. 504 o Opt Data Len: Length of the option data field. The option data 505 is comprised the Prop, Rsvd, and Type fields and the ticket 506 data. 508 o Prop: Indicates properties of the ticket for reflection and 509 origin. Possible values are: 511 o 0x0: Ticket from origin, don't reflect at receiver 513 o 0x1: Ticket from origin, reflect at receiver 515 o 0x2: Reflected ticket 517 o 0x3-0xf: Reserved 519 o Type: The type and format of the ticket. This value is used by 520 nodes in the origin network to interpret the rest of the ticket 521 data. Values for this field are specific to the network that 522 issues the ticket. 524 4.2 Option types 526 The are two option numbers requested for the ticket option: 0x0F and 527 0x2F. The latter allows modification by network nodes. Since tickets 528 are secured, only the nodes in the network that created a ticket will 529 be able to modify it. 531 4.3 Ticket format 533 A ticket encodes service parameters that describe the desired 534 services as well as additional fields that would be used to provide 535 privacy and integrity. 537 The format of a ticket is defined by the network in which the ticket 538 is issued. A ticket should be obfuscated or encrypted for privacy so 539 that only the local network can interpret it. It should be 540 uniterpretable to any nodes outside the network and to the 541 application or host that is granted a ticket. It should be resistant 542 to spoofing so that an attacker cannot illegitimately get service by 543 applying a ticket seen on other flows. 545 It is RECOMMENDED that tickets are encrypted and each ticket has an 546 expiration time. For instance, a ticket may be created by encrypting 547 the ticket data with an expiration time and using the source address, 548 destination address, and a shared key as the key for encryption. 550 For example, a ticket with an expiration time may have the format: 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Expiration time | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 ~ Service parameters ~ 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 Where the expiration time is in a format understood by the local 562 network nodes which maintain synchronized time. The Service 563 parameters are relevant to local network nodes and describe the 564 services to be applied. The service parameters could simply be a set 565 of flags for services, an index to a service profile table shared 566 amongst the network nodes, or possibly have more elaborate structure 567 that could indicate numerical values for characteristics that have a 568 range. The service parameters could also include a type field to 569 allow a network to define different representations of service 570 parameters. 572 A simple ticket containing a service protocol index might be: 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Expiration time | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Service Profile Index | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Where Type indicates the type of ticket and in this case indicates it 582 is a service profile index. Service Profile Index could be an index 583 into a table that describes the services to be applied. 585 5 Operation 587 5.1 Origin and reflection properties and ordering 589 There are three origin and reflection properties that may be applied 590 to a ticket: 592 o Origin tickets that are not reflected 594 o Origin tickets to be reflected 596 o Reflected tickets 598 Origin tickets are those set by an application that was issued a 599 ticket and have an additional property indicating whether they are to 600 be reflected by a peer host. Reflected tickets are those that have 601 been received and reflected by a peer host. 603 A sender SHOULD set at most one ticket option for each property in a 604 packet. If ticket options with different properties are set within a 605 single packet, they SHOULD have the following ordering in the Hop-by- 606 Hop Options list: 608 1. Origin tickets that are not reflected 610 2. Origin tickets to be reflected 612 3. Reflected tickets 614 If a packet contains more than one ticket option with the same origin 615 and reflection property, only the first ticket option appearing in 616 the list for the property is processed. Additional options for the 617 same property type are parsed but not processed. 619 5.2 Origin application processing 621 An origin application requests tickets, sets them in packets, and 622 validates reflected tickets. 624 5.2.1 Ticket requests 626 An application that wishes to use network services first requests 627 tickets from a ticket agent. The application request could be in the 628 form of an XML structure with canonical elements (the definition is 629 outside the scope of this document). The application makes a request 630 to the ticket agent for the local network. This could be done via a 631 web service using REST APIs. Internally in the host, the ticket agent 632 might be accessed through a library that interfaces to a ticket 633 daemon that in turn arbitrates requests between the applications and 634 a ticket agent in the network. 636 An issued ticket is opaque to the application and the application 637 should not attempt to interpret it or take any other action other 638 than attaching the ticket to its packets. 640 A ticket agent MAY provide both a origin ticket not to be reflected 641 and one that is to be reflected. The intent is that different tickets 642 can be used between the outbound and inbound paths for the flow. In 643 the case that two tickets are provided, the origin ticket not to be 644 reflected MUST appear first in the options list. 646 5.2.2 Ticket identification 648 Tickets are valid for a specific IP source and destination address 649 for which they were issued. Transport layer ports and other transport 650 layer information are not included ticket identification, however an 651 application can request tickets and validate reflected tickets on a 652 per flow basis. Issued tickets are stored in the flow context and the 653 saved information is used to validate reflected tickets. 655 5.2.3 Ticket use 657 When the ticket agent issues an returns a ticket, the application 658 sets the ticket as a Hop-by-Hop option. This is typically done by 659 setting a socket option on a socket (in the case of TCP) or by 660 indicating the option in the ancillary data when sending on a 661 unconnected socket (in the case of UDP). The application SHOULD 662 continue to use the same ticket for the flow until it is updated with 663 a new ticket. 665 The ticket agent SHOULD return an expiration time with the ticket. An 666 application can use the ticket until the expiration time, at which 667 point it can request a new ticket to continue communications. In 668 order to make the ticket transition process seamless an application 669 MAY request a new ticket before the old one expires. 671 5.2.4 Ticket agent delegation 673 A network MAY delegate creation of tickets to hosts in a limited 674 fashion. This would entail the network ticket agent issuing a master 675 ticket to a host ticket agent which in turn can use the master ticket 676 to create a limited number of tickets for its own use. The details of 677 ticket agent delegation are outside the scope of this document. 679 5.3 Origin network processing 680 When a packet with a ticket enters a network, a network node can 681 determine if the ticket originated in its network and must be 682 processed. This is done by considering the origin of the ticket and 683 the source or destination IP address. For an origin ticket (i.e. a 684 ticket is not reflected), the source address is considered. If the 685 source address is local to the network then the ticket can be 686 interpreted. For a reflected ticket, the destination address is 687 considered. If the destination address is local to the network then 688 the ticket can be interpreted. 690 If a ticket origin is determined to be the local network then the 691 ticket is processed. The ticket is decrypted if necessary and the 692 expiration time is checked. If the ticket is verified to be authentic 693 and valid then the packet is mapped to be processed by the requested 694 services. For instance, in a 5G network the packet may be forwarded 695 on a network slice for the characteristics the application has 696 requested (real-time video for instance). 698 If an origin ticket cannot be verified, for instance the ticket 699 cannot be authenticated, then the ticket SHOULD be ignored and the 700 packet processed as though no ticket were present. 702 Note that there are logically only two ingress points into the 703 network at which a provider needs to process tickets: when a local 704 user sends a packet into the provider network with an origin ticket, 705 and when a packet from an external network enters the provider's 706 network with a reflected ticket. Any ticket should be processed at 707 most once within a network. Once a ticket is processed and mapped to 708 the network's service mechanisms it should not need further 709 examination. 711 If there is more than one origin ticket present, then the first one 712 encountered is processed and any additional origin tickets SHOULD be 713 ignored by a network node. Note that this will be the case if a 714 ticket agent issued both a origin ticket not to be reflected and one 715 to be reflected; the ticket not to be reflected should appear first 716 in the packet and thus would be the one processed by a local node in 717 the network. 719 If there is more than one reflected ticket present, then the first 720 one encountered is processed and any additional reflected tickets 721 SHOULD be ignored. 723 5.4 Peer host processing 725 When a host receives a packet with a ticket whose property is "Origin 726 and to be reflected", it SHOULD save the ticket in its flow context 727 and reflect it on subsequent packets. When the application reflects 728 the option, it copies the whole option and only modifies the type to 729 indicate a "reflected ticket". The application SHOULD continue to 730 reflect the ticket until a different one is received from the origin 731 or a packet without a service ticket option is received on the flow. 732 Note that the latest ticket that is received is the one to be 733 reflected, if packets have been received out of order for a flow it 734 is possible that the reflected ticket is from an earlier packet in a 735 flow. 737 If there is more than one origin ticket to be reflected present, then 738 the first one encountered is processed and any additional origin 739 tickets to be reflected SHOULD be ignored. 741 A peer host MUST ignore received origin tickets that are not to be 742 reflected. 744 5.5 Processing reflected tickets 746 5.5.1 Network processing 748 When a packet with a reflected ticket enters the origin network of 749 the ticket, the ticket SHOULD be processed. The ticket is validated. 750 Validation entails decoding or decrypting the ticket and checking the 751 expiration time. If the ticket is valid and has not expired time then 752 the packet is verified for forwarding. 754 A network MAY accept expired reflected tickets for some configurable 755 period after the expiration time. Rate limiting SHOULD be applied to 756 packets with expired reflected tickets. Accepting expired tickets is 757 useful in the case that a connection goes idle and after sometime the 758 remote peer starts to send. The ticket it reflects may be expired and 759 presumably the receiving host will quickly respond with a new ticket. 761 5.5.2 Host processing 763 Upon receiving a packet with a reflected ticket, an end host SHOULD 764 validate the ticket before accepting the packet. This verification is 765 done by comparing the received ticket to that which is set to be sent 766 on the corresponding flow. If the tickets do not match then the 767 packet is dropped and the event SHOULD be logged. 769 A host SHOULD retain and validate expired tickets that are reflected 770 to allow a peer time to receive and reflect an updated ticket. 772 5.6 Handling dropped extension headers 774 The downside of using IPv6 extension headers on the Internet is that 775 they are currently not completely reliable. Some intermediate nodes 776 will drop extension headers with rates described in [RFC7872]. 778 5.6.1 Mitigation for dropped extension headers 780 There are some mitigating factors for this problem: 782 o A provider network that implements tickets would need to ensure 783 that extension headers are at least usable within their network. 785 o Transit networks are less likely to arbitrarily drop packets 786 with extension headers. 788 o Many content providers, especially the larger ones, may be 789 directly connected to the Internet. For example, front end web 790 servers may be co-located as exchange points. 792 o The requirement that nodes must process Hop-by-hop options has 793 been relaxed in [RFC8200]. It is permissible for intermediate 794 nodes to ignore them. 796 o Increased deployment of IPv6 and viable use cases of extension 797 headers, such as described here, may motivate vendors to fix 798 issues with extension headers. 800 5.6.2 Fallback for dropped extension headers 802 Since the possibility that extension headers are dropped cannot be 803 completely eliminated, a fallback is included for use with tickets. 805 When an application connects to a new destination for which it has no 806 history about the viability of extension headers, it can perform a 807 type of Happy Eyeballs probing. The concept is for a host to send a 808 number of packets with and without tickets. The application can 809 observe whether packets with tickets are being dropped or not being 810 reflected. 812 There are a few possible outcomes of this process: 814 o A packet with a ticket is dropped and an ICMP for extension 815 headers [ICMPEH] processing limits is received. This is a strong 816 signal that extension headers are not viable to the destination 817 and should not be used for the flow. 819 o A packet with a ticket is dropped and no ICMP error is received. 820 This is a signal that extension headers may not be usable. If 821 such drops are observed for all or a significant fraction of 822 packets and there are no drops for packets that were sent 823 without tickets, then extension headers should be considered not 824 viable for the flow. 826 o Packets with tickets are not being dropped, however tickets are 827 not being reflected. This is a signal that the peer application 828 does not support reflection. Tickets may be sent, however they 829 are only useful in the outbound path. 831 o Packets with tickets are not being dropped and tickets are 832 properly being reflected. Tickets are useful in both directions. 834 If extension headers are found to not be viable or tickets are not 835 being properly reflected, a possible fallback is to not use tickets. 836 In this case, communications might remain functional, however they 837 would be operate in a degraded mode of service. The network may 838 fallback to creating per flow state in the network; the ticket that 839 an application sent with packets during probing could be used to 840 instantiate the service characteristics maintained in a flow state. 842 6 Implementation considerations 844 6.1 Origin applications 846 Existing client applications can be modified to request tickets and 847 set them in packets. The OS networking stack may need some small 848 changes or configuration to enable an application to specify the 849 option for its packets. 851 The interface to the ticket agent would likely be via a library API. 853 For a connected socket (TCP, SCTP, or connected UDP socket), a Hop- 854 by-Hop option can be set on the socket via the setsockopt system call 855 in BSD sockets API. For an unconnected socket (UDP) the ticket option 856 can be set as ancillary data in the sendmsg system call. 858 Happy Eyeballs for extension headers, described in section 5.6.2, 859 could be implemented in the networking stack for a connection 860 oriented transport protocol such a TCP. For connectionless protocols, 861 probing could be handled by an application library. 863 6.2 Ticket reflection 865 To perform ticket reflection, servers must be updated. In the case of 866 a connected socket (TCP, SCTP, or a connected UDP socket) this can be 867 done as relatively minor change to the kernel networking stack which 868 would be transparent to applications. For unconnected UDP, an 869 application could receive the ticket as part of the ancillary data in 870 recvmsg system call, and then send the reflected ticket in a reply 871 using ancillary data in sendmsg. 873 7 Security Considerations 875 There are two main security considerations: 877 o Leakage of content specific information to untrusted third 878 parties must be avoided. 880 o Tickets cannot be forged, illegitimately used, or otherwise 881 abused. 883 Tickets may be visible to the Internet including untrusted and 884 unknown networks in the path of sent packets. Therefore, tickets 885 should be encrypted or obfuscated by the origin network. 887 Tickets need to have an expiration time, must be resistant to 888 forgery, and must be nontransferable. A ticket should be valid for 889 the specific source and destination addresses that it was issued for. 890 Tickets are revocable by implemented a black-list contained revoked 891 tickets. 893 8 IANA Considerations 895 IANA is requested to assigned the following Hop-By-Hop options: 897 +-----------+---------------+-------------+---------------+ 898 | Hex Value | Binary value | Description | Reference | 899 | | act chg rest | | | 900 +-----------+---------------+-------------+---------------+ 901 | 0x0F | 00 0 01111 | Firewall | This document | 902 | | | and Service | | 903 | | | Ticket | | 904 +-----------+---------------+-------------+---------------+ 905 | 0x2F | 00 1 01111 | Modifiable | This document | 906 | | | Firewall | | 907 | | | and Service | | 908 | | | Ticket | | 909 +-----------+---------------+-------------+---------------+ 911 IANA is requested to set up a registry for the Ticket property. These 912 types are 4 bit values. New values for 0x3-0xf are assigned via 913 Standards Action [RFC5226]. 915 +----------------+--------------------+---------------+ 916 | Ticket type | Description | Reference | 917 +----------------+--------------------+---------------+ 918 | 0x0 | Ticket from origin | This document | 919 | | and don't reflect | | 920 +----------------+--------------------+---------------+ 921 | 0x1 | Ticket from origin | This document | 922 | | and reflect | | 923 +----------------+--------------------+---------------+ 924 | 0x2 | Reflected ticket | This document | 925 +----------------+--------------------+---------------+ 927 9 References 929 9.1 Normative References 931 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 932 (IPv6) Specification", STD 86, RFC 8200, DOI 933 10.17487/RFC8200, July 2017, . 936 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 937 IANA Considerations Section in RFCs", RFC 5226, DOI 938 10.17487/RFC5226, May 2008, . 941 9.2 Informative References 943 [RFC7605] Touch, J., "Recommendations on Using Assigned Transport 944 Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, 945 August 2015, . 947 [RFC7872] Got, F., Linkova, J., Chown, T., and W. Liu, "Observations 948 on the Dropping of Packets with IPv6 Extension Headers in 949 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, 950 . 952 [TLSCERT] United States Computer Emergency Readiness Team (US-CERT), 953 "Alert (TA17-075A), HTTPS Interception Weakens TLS 954 Security, March 2017 956 [SPUD] Hildebrand, J. and Trammell, B., "Substrate Protocol for 957 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 958 prototype-03, March 2015 960 [PLUS] Trammell, B. and Kuehlewind, M., "Path Layer UDP Substrate 961 Specification", draft-trammell-plus-spec-01, March 2017 963 [PAN] Trammell, B., "Open Questions in Path Aware Networking", 964 draft-trammell-panrg-questions-02, December 2017 966 [ICMPEH] Herbert, T., "ICMPv6 errors for discarding packets due to 967 processing limits", draft-herbert-6man-icmp-limits-03, 968 January 2018 970 [LIMDOM] Carpenter, B. and Liu, B., "Limited Domains and Internet 971 Protocols", draft-carpenter-limited-domains-03, June 2018 973 Author's Address 975 Tom Herbert 976 Quantonium 977 Santa Clara, CA 978 USA 980 Email: tom@quantonium.net