Network Working Group T. Herbert Internet-Draft SiPanda Intended status: Standards Track 4 August 2023 Expires: 5 February 2024 Firewall and Service Tickets (FAST) draft-herbert-fast-06 Abstract Firewall and Service Tickets is a generic and extensible protocol mechanism for hosts to send explicit signals to on-path elements to request network services on a per packet basis. This is a type of "host to networks signaling", and the data of the signal is a "ticket" that accompanies a packet. A ticket indicates the requested services or a grant of admission into a network; tickets are processed by network nodes to instantiate the requested services. Tickets are scoped to be relevant to their "origin domain" which is the network or limited domain in which they are issued. Outside of their origin domain tickets are not processed and are forwarded as opaque data. To prevent forgery and to obscure the services being requested, tickets are authenticated, encrypted, or otherwise obfuscated such that they can only be read by network nodes in their origin domain. Tickets are sent in IPv6 Hop-by-Hop options. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 February 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Herbert Expires 5 February 2024 [Page 1] Internet-Draft FAST August 2023 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2. Motivation and requirements . . . . . . . . . . . . . . . . . 5 2.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Current mechanisms . . . . . . . . . . . . . . . . . . . 6 2.2.1. Stateful firewalls and proxies . . . . . . . . . . . 7 2.2.2. QoS signaling . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Deep packet inspection . . . . . . . . . . . . . . . 7 2.3. Proposals for host to network signaling . . . . . . . . . 8 2.3.1. Embedded information in UDP encapsulation . . . . . . 8 2.3.2. UDP Options . . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Overloading the IPv6 Flow Label . . . . . . . . . . . 9 2.3.4. Overloading bits in IPv6 addresses . . . . . . . . . 10 2.3.5. Stateful mechanisms . . . . . . . . . . . . . . . . . 11 2.3.6. Destination Options . . . . . . . . . . . . . . . . . 11 2.4. Motivation for Hop-by-Hop Options . . . . . . . . . . . . 12 2.4.1. Processing requirements of Hop-by-Hop Options . . . . 12 2.4.2. Hop-by-Hop packet drops as a matter of policy . . . . 13 2.4.3. Support in IPv4 . . . . . . . . . . . . . . . . . . . 14 2.4.3.1. IPv4 Options . . . . . . . . . . . . . . . . . . 14 2.4.3.2. IPv4 Extension Headers . . . . . . . . . . . . . 15 2.5. Requirements . . . . . . . . . . . . . . . . . . . . . . 15 2.6. Related work . . . . . . . . . . . . . . . . . . . . . . 16 2.6.1. Transport Path Signals . . . . . . . . . . . . . . . 16 2.6.2. Network tokens . . . . . . . . . . . . . . . . . . . 16 2.6.3. IOAM . . . . . . . . . . . . . . . . . . . . . . . . 17 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 17 3.1. Example communications flow . . . . . . . . . . . . . . . 19 3.2. Packet format . . . . . . . . . . . . . . . . . . . . . . 20 3.2.1. Option format . . . . . . . . . . . . . . . . . . . . 21 3.2.2. Ticket format . . . . . . . . . . . . . . . . . . . . 22 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1. Origin and reflection properties and ordering . . . . . . 23 4.2. Application and ticket agent processing . . . . . . . . . 24 4.2.1. Ticket requests . . . . . . . . . . . . . . . . . . . 24 4.2.2. Ticket agents . . . . . . . . . . . . . . . . . . . . 24 4.2.3. Ticket identification . . . . . . . . . . . . . . . . 25 Herbert Expires 5 February 2024 [Page 2] Internet-Draft FAST August 2023 4.2.4. Ticket use . . . . . . . . . . . . . . . . . . . . . 25 4.2.5. Ticket agent delegation . . . . . . . . . . . . . . . 25 4.3. Forward path processing . . . . . . . . . . . . . . . . . 26 4.4. Peer host processing . . . . . . . . . . . . . . . . . . 26 4.5. Processing reflected tickets . . . . . . . . . . . . . . 27 4.5.1. Network processing . . . . . . . . . . . . . . . . . 27 4.5.2. Host processing . . . . . . . . . . . . . . . . . . . 28 4.6. Handling dropped extension headers . . . . . . . . . . . 28 4.6.1. Mitigation for dropped extension headers . . . . . . 28 4.6.2. Fallback for dropped extension headers . . . . . . . 29 5. Implementation considerations . . . . . . . . . . . . . . . . 29 5.1. Application support . . . . . . . . . . . . . . . . . . . 29 5.2. Ticket reflection . . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . 32 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction Firewall and Service Tickets (FAST) is a technique to allow an application to signal the on-path elements, or network nodes, for requests for service. This is a type of "host to network signaling". A "ticket" is the data of the signal and is a (relatively) small object that expresses the services being requested. Tickets are attached to a packet by the source node, and are processed by certain network nodes to instantiate the requested services. Tickets may be used as an admission control mechanism to grant passage of packets to traverse a network or pass through a firewall. Tickets are scoped data such that a ticket is only relevant and interpretable in their "origin domain" which is the network or limited domain [RFC8799] in which the ticket was issued. Tickets are allowed to traverse networks beyond their origin domain, however network nodes outside of the origin domain don't interpret or apply the services of a ticket. To enforce this, tickets are encrypted and authenticated such that a ticket is only readable by network nodes in its origin domain. Tickets are also encrypted and authenticated to prevent forgery, to prevent modification, to hide details about requested services, to hide information that might reveal application characteristics or users, and to enforce that tickets are non- transferable between hosts or users. Tickets may also have an expiration time to limit reuse. Herbert Expires 5 February 2024 [Page 3] Internet-Draft FAST August 2023 An application requests tickets from a ticket agent in their local domain. A ticket request describes the requested services, and the ticket agent issues tickets to the application for those services. In turn, the application attaches the tickets to its packets and network nodes interpret them to provide the requested services. As a packet with attached tickets is forwarded in a network, network nodes in the origin domain can interpret the ticket and apply the requested services. Tickets are typically be requested on a per flow basis, however they are stateless entities relative to network processing. It is not required that the same ticket be used for all packets of a flow. While tickets themselves are stateless, they can be used to elicit stateful semantics. For instance, a ticket may be issued as a grant of admission that permits packets of a flow to pass through a border firewall and enter a network. In this case, the association between the ticket, a flow, and the admission policy is made by the ticket agent when the ticket is created. When a ticket is processed, these associations are implicit in the ticket such that network nodes don't need to be stateful or perform transport layer connection tracking. Effectively, this is a means to replace stateful firewalls with stateless mechanisms providing the same behavior. Tickets may be "non-reflected" or "reflected". A non-reflected ticket is sent by a source to apply services in the "forward path" of communications. Non-reflected tickets are interpreted in the origin domain of the source and services are provided. A reflected ticket is one that was reflected by a peer host and sent to apply services in the "return" path" in bidirectional communications. A ticket can be sent in the forward path and marked as "reflect". When the peer host receives the packet, it reflects the ticket by sending it in reply packets and remarking the ticket as being "reflected". Reflected tickets are processed by network nodes in the origin domain corresponding to the packet's destination to apply requested services. In this manner, tickets can be used to affect packets in the return direction of a flow relative to some host. Herbert Expires 5 February 2024 [Page 4] Internet-Draft FAST August 2023 The contents, format, and semantics of tickets are not fixed so as to be extensible. A "ticket type" accompanies each ticket that describes the format and semantics. The type number space includes global ticket types and private ticket types. Global ticket types are useful in cases where tickets and common ticket formats are shared amongst multiple networks and tickets need to be interpreted by those networks. Private ticket types can be used for custom applications or experimentation. Tickets may express a rich variety of services and service parameters including priority, QoS parameters, latency requirements, throughput requirements, security parameters, etc. Tickets are coded in IPv6 Hop-by-Hop options. Tickets are not modifiable in-flight, so therefore a single unmodifiable Hop-by-Hop option is requested. Note that this specification specifies the protocol mechanisms for carrying host to network signaling in tickets, it not does describe a particular format or semantics of tickets. Those are expected to be defined in separate documents for different use cases of tickets. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Motivation and requirements This section presents the motivation and requirements for Firewall and Service Tickets, and in particular the motivation for using Hop- by-Hop Options as the carrier of host to network signaling. 2.1. Use cases There are a number of use cases for host to network signaling. As an example, we consider the common problem of applications on mobile devices that need to signal their provider network for services. In a typical client/server model of serving content, end host clients communicate with servers on the Internet. Clients are typically user devices that are connected to the Internet through a provider network. In the case of mobile devices, such as smartphones, the devices are connected to the Internet through a mobile provider network. Content providers (web servers and content caches) tend to be more directly connected to the Internet, the largest of which can connect at exchange points. Herbert Expires 5 February 2024 [Page 5] Internet-Draft FAST August 2023 Provider networks can be architected to provide differentiated services and levels of services to their users based on application characteristics. For example, a mobile carrier network can provide different latency and throughput guarantees for different types of content. A network may offer different services for optimizing video: streaming an HD movie might need high throughput but not particularly low latency; a live video chat might have lower throughput demands but have stringent low latency requirements. The 3GPP standard for 5G [_3GPP-5G] defines a set of mechanisms to provide a rich array of services for users. These mechanisms employ Network Function Virtualization (NFV), Service Function Chaining (SFC), and network slices that divide physical network resources into different virtualized slices to provide different services. To make use of these mechanisms, the applications running in UEs (User Equipment) will need to indicate desired services of the RAN (Radio Access Network). When packets for the UE arrive at the ingress router to the RAN, the service requests in the packet can be mapped to the mechanisms and protocols to instantiate the services as the packet traverses the RAN. For instance, a video chat application may request bounded latency that is implemented by the network by a network slice; so packets sent by the application should be mapped to that network slice. Note that network services requested by applications are relevant to both packets sent by an end node and those sent from a peer towards the end node. For the latter case, the network needs to be able to map packets sent from hosts on the Internet to the services requested by the receiving application. FAST is applicable to this mobile network use case. The application running in the UE would request tickets for services from a ticket agent in their local provider. When packets are sent by the UE in the RAN, the first hop router could interpret the ticket. The router would first validate the ticket and then apply the requested services by mapping them into the internal mechanisms of the network (network slicing, SFC, DSCP, etc.). Reflected tickets could also be used so that when reply packets enter the network, the border router of the RAN would apply the requested services in the reflected ticket by mapping them to the internal mechanisms of the network for forwarding to the UE. 2.2. Current mechanisms Current solutions for controlling admission to the network and requesting services are mostly ad hoc and architecturally limiting. Herbert Expires 5 February 2024 [Page 6] Internet-Draft FAST August 2023 2.2.1. Stateful firewalls and proxies Stateful firewalls and proxies are the predominantly deployed techniques to control access to a network and provide services on a per flow basis. While they provide some benefits of security, they break the end-to-end model and have otherwise restricted the Internet in several ways: * They require parsing over transport layer headers in the fast path of forwarding. * They are limited to work only with a handful of protocols and protocol features thereby ossifying protocols. * They break the ability to use multi-homing and multi-path. All packets for a flow must traverse a specific network device in both directions of communication. * They can break end to end security. NAT for instance breaks the TCP authentication option. * They are single points of failure and network bottlenecks. 2.2.2. QoS signaling In the current Internet, there is little coordination between hosts and the network to provide services based on characteristics of the application. Differentiated services [RFC8837] provides an IP layer means to classify and manage traffic, however it is lacking in richness of expression and lacks a ubiquitous interface that allows applications to request service with any granularity. Without additional state, there is no means for the network infrastructure to validate that a third party application requesting QoS adheres to network policies. 2.2.3. Deep packet inspection Some network devices perform Deep Packet Inspection (DPI) into the application layer data to determine whether to admit packets or what services to apply. For instance, HTTP is commonly parsed to determine URL, content type, and other application level information that the network is interested in. DPI can only be effective with the application layer protocols that a device is programmed to parse. More importantly, application level DPI is effectively obsoleted in the network due the pervasive use of TLS. TLS interception and SSL inspection, whereby an intermediate node implements a proxy that decrypts a TLS session and re-encrypts, is considered a security vulnerability [TLSCERT]. Herbert Expires 5 February 2024 [Page 7] Internet-Draft FAST August 2023 2.3. Proposals for host to network signaling This section surveys some proposals to address the need for applications to signal the network. The proposals tend to be point solutions to the problem that would work in only limited contexts. 2.3.1. Embedded information in UDP encapsulation There have been various proposals to embed host to network signals in the payload of UDP encapsulation. [PLUS] (Path Layer UDP Substrate) proposed a UDP based protocol to allow applications to signal a rich set of characteristics and service requirements to the network. The advantages of PLUS is that it's run over UDP so it doesn't affect or modify network layer protocols, and it implements its own transport layer state machine as a ubiquitous means to expose transport layer connection semantics to network nodes thereby leveraging existing mechanisms in stateful devices such as stateful firewalls. The drawbacks of this approach are: * This technique only works with UDP. To work with other protocol requires encapsulation and applications need to change. In particular, this is incompatible with TCP which is the predominant transport protocol on the Internet. * Unless a UDP protocol is natively designed to include the embedded information, a shim header is required between the IP header and real transport layer header. As demonstrated by QUIC [RFC9000], the trend in transport protocols is to encrypt as much of the packet as possible including the transport headers; it is likely that few UDP protocols would embed plain text information, so packets would inevitably need an extra UDP header which increases the complexity and diminishes feasibility of the solution. * Embedding network signals inside UDP payload requires that intermediate nodes parse and process UDP payloads. Since UDP port numbers do not have global meaning [RFC7605], there is the possibility of misinterpretation and of silent data corruption if intermediate nodes modify UDP payloads. PLUS attempts to mitigate this issue with the use of magic numbers, however that can only ever be probabilistically correct. * Making session semantics visible to the network in plaintext is a Herbert Expires 5 February 2024 [Page 8] Internet-Draft FAST August 2023 security liability for those transport protocols that intentionally hide transport layer protocols and state. For example, QUIC [RFC9000] espouses the design principle to encrypt as much of the packet as possible including the transport layer. An external protocol that exposes information about QUIC transport state would be inconsistent with that design principle and likely considered a security risk. 2.3.2. UDP Options UDP Options [I-D.ietf-tsvwg-udp-options] is a new protocol that defines a transport options for UDP in the "surplus area" of UDP packets. There are proposals to place host to network signals in UDP Options ([I-D.kaippallimalil-tsvwg-media-hdr-wireless], [I-D.reddy-tsvwg-explcit-signal]). This approach has the advantage that UDP packets can be annotated with additional information without affecting the payload or requiring changes to the application protocol or the application. The drawbacks of this approach are: * This approach only works with UDP. To work with other protocol requires encapsulation and applications need to change. In particular, this is incompatible with TCP which is the predominant transport protocol on the Internet. * UDP Options are in protocol trailers of packets which makes it difficult to implement processing efficiently. This is especially true for hardware implementations that are common in high performance routers for which it may be infeasible to even support processing of protocol trailers. * UDP Options are specified as transport layer options, whereas network signals are more aptly described as network layer options. Mixing the two together creates problems. For instance, an intermediate node would only be interested in processing network options and would ignore transport options. Searching in a list of TLVs containing both transport and network options may be expensive especially in a hardware datapath (skipping over TLVs being ignored is not zero cost processing). 2.3.3. Overloading the IPv6 Flow Label There have been a number of proposals to overload the IPv6 flow label with host to network signaling information ([I-D.cc-v6ops-wlcg-flow-label-marking]). The advantage of this approach is no change to the application or on-the-wire protocol. Herbert Expires 5 February 2024 [Page 9] Internet-Draft FAST August 2023 The drawbacks of this approach are: * The flow label is only twenty bytes, and if some bits are reserved to retain flow entropy then the effective number of bits available for signaling may be less; for example, [I-D.cc-v6ops-wlcg-flow-label-marking] uses sixteen bits of the flow label for signaling). In any case, the amount of information the flow label could carry is quite limited. * IPv4 does not have a flow label. * There is no codepoint to indicate that a flow label is formatted in a certain way. This could lead to misinterpretation of the flow label as intermediate nodes. * The use may reduce flow entropy in the flow label thereby adversely affecting ECMP routing. * The flow label is expected to be unchanged for the duration of a flow so there is no means to change service parameters mid-flow or per packet. 2.3.4. Overloading bits in IPv6 addresses There have been suggestions that host to network signaling could be embedded in IPv6 addresses. The basic idea is that some number of low order bits in the 128 bit IP address could be used to convey the signal, intermediate devices would then interpret these bits as network signals. The higher order bits would be a prefix that contains the host identifier. This could be done in either the source or destination address, and nodes could differentiate addresses containing signaling by their address prefix. The advantage of this approach is no change to the application or on-the- wire protocol, and this is independent of the flow label so there is no reduction of entropy for ECMP routing. The drawbacks of this approach are: * The number of bits in an address use for network signaling would be limited. * This only works with IPv6. The IPv4 does address space is not large enough, thirty-two bits, to support embedded information in addresses. * Addresses for a flow are fixed for the lifetime of the flow. There is no means to change service parameters mid-flow or per packet Herbert Expires 5 February 2024 [Page 10] Internet-Draft FAST August 2023 * This changes IPv6 addressing policies, and will likely require changes to IPv6 host stacks 2.3.5. Stateful mechanisms There are proposals to leverage stateful protocols that are interpreted by network nodes including proposals to use a TLS extension or a STUN attribute for per flow host for host to network signaling (([I-D.yiakoumis-network-tokens]). The advantage of these techniques is that they don't require changes to datapath packets and are confined to the control plane. The drawbacks of this approach are: * The approach require stateful devices in the network and thus the known issues of those entail-- problems with multihoming, state eviction, scaling, etc. * The mechanisms are transport protocol specific and require stateful or session based transport protocol semantics (for instance TLS only works with TCP). * The signals for a flow are set at flow creation time, so there is no means to change service parameters mid-flow, or on a per packet basis. 2.3.6. Destination Options There have been suggestions to place network signaling inside IPv6 Destination Options in lieu of using Hop-by-Hop Options. The rationale is that packets with Destination Options are less likely to be dropped than Hop-by-Hop Options. The use of Destination Options for this purpose would entail that intermediate nodes parse Destination Options. The drawbacks of this approach are: * Destination Options were never intended to processed by intermediate nodes per [RFC8200]. This would be a major change to IPv6 that is not necessarily backwards compatible. * Destination Options may follow Hop-by-Hop Options thereby requiring deeper parsing of packets. Hop-by-Hop Options extension MUST immediately follow the IPv6 header, whereas Destinations may follow other extension headers. Herbert Expires 5 February 2024 [Page 11] Internet-Draft FAST August 2023 2.4. Motivation for Hop-by-Hop Options IPv6 Hop-by-Hop Options are designed to be an extensible means for host to signaling and network to host signaling on a per packet basis. Hop-by-hop Options address most of the issues that affect the alternate proposals described above-- Hop-by-Hop Options work with any transport protocol, they are variable length to allow rich expression, they are stateless, they can change between packets of the same flow, they are outside of transport layer protocol, they are defined as part of an Internet standard [RFC8200], they are explicitly intended to be processed by intermediate nodes, they are located in headers of a packet, as opposed to trailers, immediately following the IPv6 header. The drawbacks of Hop-by-Hop Options are: * The original processing requirements have impeded deployment of Hop-by-Hop Options * They may be dropped by some network providers as a matter of policy * They are IPv6 specific, there is no equivalent support in IPv4 The sections below present some mitigations and solutions for these drawbacks. 2.4.1. Processing requirements of Hop-by-Hop Options [RFC2460] required that all intermediate nodes in a path process Hop- by-Hop Options. Some routers deferred processing of Hop-by-Hop Options to the software slow path, other ignored them, and still others elected to summarily drop all packets containing Hop-by-Hop Options. A related issue was that the number of Hop-by-Hop Options in a packet was only limited by the MTU for the packet-- the lack of a limit combined with the requirement that nodes must skip over unknown options (when high order bit in the option type isn't set), creates the opportunity for DOS attacks by sending long lists of unknown Hop-by-Hop options. The net effect of these issues was that deployment of Hop-by-Hop Options on the Internet was impeded. There is ongoing work to fix, or at least mitigate, the deployability problems of Hop-by-Hop options: * [RFC8200] specifies that intermediate nodes MAY ignore Hop-by-Hop options. There is no concept of a Hop-by-Hop option that must be processed by all nodes, the current assumption in defining any option is that it may be processed by only by some nodes in the Herbert Expires 5 February 2024 [Page 12] Internet-Draft FAST August 2023 path, or even none at all. Allowing nodes to ignore options they're not interested in, instead of just dropping the packets, preserves the usability of Hop-by-Hop across the whole path. * [I-D.ietf-6man-hbh-processing] modifies the processing of Hop-by- Hop options described in [RFC8200] to make processing of the IPv6 Hop-by-Hop Options header practical. In particular, this clarifies the expectation that Hop-by-Hop Options should not be processed in the slow path and that new Hop-by-Hop options are designed to always be processed in the fast path. * [I-D.ietf-6man-eh-limits] specifies that intermediate nodes that process Hop-by-Hop Options may set and apply configurable limits on Hop-by-Hop processing. For instance, one limit is for the number of options that are processed; if the limit is exceeded then options processing is terminated and the packet is forwarded without any ill-effects. The use of limits is optional and while specific default limits are recommended, there are no specific "hard" limits that must be enforced. 2.4.2. Hop-by-Hop packet drops as a matter of policy Some network providers elect to drop packets with Hop-by-Hop Options as a matter of policy under the ostensible rationale that they are inherent security risks or they are not useful to end users [RFC9098]. Regardless of any requirements or evidence provided by IETF, it is likely that some number of network providers will maintain such policies for the foreseeable future; so we can never expect that network support for Hop-by-Hop Options or extension headers will be universal. Note that Hop-by-Hop Options aren't unique in this regard, several other protocols might subject to arbitrarily blocking in the network including fragmented packets, IPsec packets, UDP to "unauthorized" ports, and even IPv6, itself-- nothing has 100% support on the Internet (expect maybe plain TCP/IPv4). There is also a great deal of inconsistency amongst providers in their policies regarding extension headers. Some will drop all packets with extension headers, some might decide to drop certain extension header types, and still others may allow all extension headers in their network. These inconsistencies are not unique for IPv6 extension headers, there are similar in inconsistencies in policies regarding the acceptability of transport port numbers, fragmentation, ICMP, and IP protocols other than TCP and UDP. The most common proposed workaround to ad hoc policies that block a standard protocol, is to restrict use of the protocol to limited domains [RFC8799]. Despite what the term "limited domain" might Herbert Expires 5 February 2024 [Page 13] Internet-Draft FAST August 2023 suggest, limited domains are not relegated to be small insignificant networks, and in fact could comprise very large networks. Multiple peered networks could cooperate to create arbitrarily large domains that are proper subsets of the Internet. Within a limited domain, support for Hop-by-Hop Options could be ensured on all devices such that communications between nodes in the limited domain could reliably use FAST to request services from the networks of the limited domain. While there will likely never be 100% support of Hop-by-Hop Options over the open Internet, there are paths that work even today and one would expect more success as problems with IPv6 and extension headers are identified and fixed ([I-D.elkins-v6ops-eh-deepdive-cloud]). The problem is not dissimilar than the fact that there is not yet 100% support of IPv6 across all paths in the Internet. It is conceivable, that an end host could either probe or have access to a priori information that is used to determine if Hop-by-Hop Options are viable to a given destination. If they're viable then Hop-by-Hop Options can be sent, if they're not viable then the host can fallback to not using Hop-by-Hop Options which may degrade service but stills allows communication. Mechanisms to determine if Hop-by-Hop Options are viable to a destination are out of scope for this document, however possible solutions include techniques similar to Happy Eyeballs [RFC8305], other probing, or a mashup map of capabilities on the Internet. 2.4.3. Support in IPv4 Extension headers are not defined for IPv4. This section discusses two solutions to support the FAST Hop-by-Hop Option in IPv4. 2.4.3.1. IPv4 Options A new IPv4 option could be defined for FAST. IPv4 options are designed to be inspected by intermediate nodes, however support is not widespread to the extent that they may be far less deployable than even IPv6 Hop-by-Hop Options. A major reason for this is that, unlike IPv6, the IPv4 header is variable length. Many hardware devices have long assumed that the IPv4 header is twenty bytes, processing a larger header will likely be problematic causing drops or packets being relegated to slow path processing. Herbert Expires 5 February 2024 [Page 14] Internet-Draft FAST August 2023 2.4.3.2. IPv4 Extension Headers An alternative to IPv4 Options is to enable Extension Headers in IPv4 [I-D.herbert-ipv4-eh]. This solution doesn't affect the IP header, but does introduce a new IP protocol to IPv4 devices. Some network nodes might need to be configured to forward the extension header types and this would affect ECMP routing since the transport headers, continuing the port numbers used in ECMP, would not be parsed. [I-D.herbert-ipv4-eh] describes repurposing the Identification field of the IPv4 header to be a flow label to compensate for the effects on routers if they can't access transport layer headers. 2.5. Requirements The requirements for Firewall and Service Tickets are: * Tickets SHOULD be stateless within the network. In particular intermediate nodes MUST NOT be required to create and maintain state for transport layer connections. * Tickets MUST work in a multi-homed and multi-path environments. * Outside of the network that issued a ticket, the origin network, tickets MUST be opaque and obfuscated so that no application specific information is derivable. * Tickets MUST work with any transport protocol as well as in the presence of any IP protocol feature (e.g. other extension headers that might be present). * Tickets SHOULD minimize the changes to an application. Their use should be an "add-on" to the existing communications of an application. * Tickets MUST deter spoofing and other misuse that might result in unauthorized use of network services or denial of service attack. * Tickets MUST be contained in the IP layer protocol. In particular, FAST MUST NOT require parsing transport layer headers. * Tickets MUST allow services to be applied in the return path of a communication. In a client/server application it is often the packets in the reverse path that require the most service (for instance if a video is being streamed to a client). * A fallback MUST be present to handle the case that extension Herbert Expires 5 February 2024 [Page 15] Internet-Draft FAST August 2023 headers are dropped within the network or a peer node does not reflect tickets. A fallback allows functional communications but provides it in a potentially degraded mode of service. 2.6. Related work 2.6.1. Transport Path Signals [RFC8558] discusses discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. Implicit signals are those that are inferred from the transport layer, and explicit signals are set in packets with the explicit purpose of signaling network nodes in the path. The RFC notes the trend towards encrypting more layers of the packet which reduces the effectiveness of implicit signals. To address this, explicit signals could be used. One option suggested is to replace implicit signals with explicit Network-Layer Signals and in particular IPv6 Hop-by-Hop options could be used to convey signals -- FAST is such an approach. [RFC8558] makes several recommendations that are applicable to FAST. As recommended, FAST tickets only expose information to the network that is intended to be consumed by network elements on the path. The signals are independent of any protocol state machine at the endpoints. FAST tickets are integrity protected and unmodifiable in- flight, and furthermore, they can be scoped by encryption or obfuscation to limit visibility of the underlying signal to the origin domain and its authorized delegates. [RFC9419] discusses principles for designing mechanisms that use or provide path signals. This specification defines the common carrier of path signals, and it is flexible to carry as content which adhere to the principles for signal content described in [RFC9419]. 2.6.2. Network tokens Network tokens [I-D.yiakoumis-network-tokens], is a similar protocol to FAST. A network token is data that is used to explicitly and securely coordinate with networks about how their traffic is treated. [I-D.yiakoumis-network-tokens] describes in some detail potential formats for network tokens, including the possibility of network tokens being represented as JWT and CWT objects Similar to FAST, Network Tokens proposes network token reflection by peers. The properties are the same as FAST, and in fact the proposed property field uses the same values to express reflection properties. Herbert Expires 5 February 2024 [Page 16] Internet-Draft FAST August 2023 Network tokens proposes two methods for signaling network nodes: using a STUN attribute and a Hop-by-Hop option. The proposed Hop-by- Hop option is very similar to the FAST Hop-by-Hop option. [I-D.yiakoumis-network-tokens] acknowledges that it is important to minimize the length of Hop-by-Hop options, the use of Service Profile Indices described in this document may be a possible solution. While FAST is primarily focused on defining a common carrier and procedures for host to network signaling, [I-D.yiakoumis-network-tokens] is a little higher layer in that it describes some details and examples of data formats for signaling. It is conceivable that a FAST ticket type could be reserved for carrying a network tokens. 2.6.3. IOAM [I-D.ioametal-ippm-6man-ioam-ipv6-options] describes a method for carrying IOAM data in IPv6 Hop-by-Hop options. IOAM in is an instance of network to host signaling, as opposed to host network signaling which is the subject of this specification. The option format for ticket data is very similar to the format used for IOAM data. A useful feature of IOAM is the concept of loopback that allows end hosts to loopback IOAM options in reply packets so that both the forward and return paths of a flow can be measured; this is mostly an analogue of the ticket reflection defined for FAST. 3. Architecture The figure below illustrates an example network path between two hosts on the Internet. Each host connects to the Internet via a provider network, and provider networks are connected in the Internet by transit networks. _____ __________ ( ) __________ +--------+ ( ) ( ) ( ) +--------+ | User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 2 | +--------+ (__________) ( ) (__________) +--------+ (_____) Figure 1 Herbert Expires 5 February 2024 [Page 17] Internet-Draft FAST August 2023 Within each provider network, services may be provided on behalf of the users of the network. In the figure above, Provider A may provide services and service agreements for users in its network including User 1; and likewise Provider B can provide services to users in its network including User 2. It is assumed that, transit networks don't typically provide user specific services or service differentiation-- this is a so called "dumb bell" topology. Services provided by different provider networks may be very different and dependent on the implementation of the network as well as the policies of the provider. Based on this model, services and service differentiation can be considered local to each network provider. FAST is a mechanism whereby each user and application can request from its local provider the services to be applied to its traffic. A request for service is made to a FAST "ticket agent". The contents of the request describe the services that the application desires. The ticket agent responds with a "ticket" that the application sets in its packets. When a packet is sent by the application with a ticket attached, the ticket is interpreted in the provider network to allow the packet to traverse the network and to map the packet to the appropriate services. A ticket is only relevant its origin domain, that is the provider network or limited domain in which the ticket was issued. Outside of the origin domain, tickets are uninterpretable opaque objects. To facilitate network traversal and service mapping in the return direction for a flow, that is reply packets sent from a peer host, peer hosts can be asked to reflect tickets without modification or interpretation. This is done by saving the ticket received in packets of a flow in the flow context and attaching the saved reflected ticket to packets being sent in the reverse direction on the flow. The use of tickets may be bilateral for a flow so that each peer requests service from its local network. Therefore packets may contain two types of tickets: one that is set by the sending host to signal its local provider network, and the other is the reflected ticket that is a signal to the provider network of the peer endpoint. Herbert Expires 5 February 2024 [Page 18] Internet-Draft FAST August 2023 Tickets are scoped values in that they only have meaning in their origin domain in which a ticket was issued. The format, meaning, and interpretation of tickets is specific to the origin domain. By mutual agreement, two or more networks or limited domains may share the policy and interpretations of tickets thereby extending the origin domain. For instance, there could be an agreement between two provider networks to interpret each others tickets or to use a common format. 3.1. Example communications flow Figure 2 provides an example communications flow using FAST. 1. Ticket +--------+ request +------------> | Ticket | / +---------- | Agent | +---+ / 2. Ticket +--------+ / +-----+ reply ______ / v __________ ( ) +--------+ ( ) ( ) +--------+ | Client +----------( Provider A )--( Internet )---+ Server | +--------+ (__________) ( ) +--------+ (______) 3. App sends, 4,5. Net applies 6. Ignore ticket 7,8. Server ticket attached services in Internet reflect -------------------> -----------------> --------------------+ \ Reverse path / ------------------ <----------------- <---------------------+ 12. Validate 10,11. Network applies 9. Ignore ticket reflected ticket services in Internet Figure 2 Referencing figure 2, consider that the Client is establishing a video chat with the Server and wishes to have low latency service for video applied by its local network (Provider A). The flow of events may be: 1. The Client makes a ticket request to a ticket agent of Provider A that describes the video application and may include detailed characteristics such as resolution, frame rate, latency requirements, etc. 2. The ticket agent issues a ticket to the Client that indicates that packets of the flow have a right to traverse the network and the services to be applied to the packets of the flow. Herbert Expires 5 February 2024 [Page 19] Internet-Draft FAST August 2023 3. The video chat application sends packets with the ticket attached for the video chat. 4. The first hop router in Provider A's network interprets the ticket in packets and applies the appropriate services (e.g. sets diffserv, forwards on a network slice, encapsulates in MPLS, encapsulates with segment routing, etc.). 5. Packets traverse Provider A's network with the appropriate services being applied, the ticket is forwarded but not necessarily processed after the first hop router. 6. Packets traverse transit networks and the Server's provider network, the attached tickets are ignored since they are only interpretable in the origin domain. 7. Packets are received at the Server. Attached tickets that are marked as "reflect" are saved in the flow context for the video chat. 8. The Server's video chat application eventually sends packets back to the Client. The last ticket previously received from the Client is now reflected in these packets. The server may also attach non-reflected ticket to requested services from the server's provider network. 9. Packets with the reflected ticket traverse the Server's provider network and transit networks, the reflected ticket is ignored. 10. An ingress router in Provider A's network interprets the reflected ticket and applies appropriate services to the packets for traversing the local network. 11. Packets are forwarded within Provider's A network with the appropriate services applied. The reflected ticket is forwarded along with the packet, but not necessarily processed after the ingress router. 12. Packets are received at the host for the Client. The reflected ticket can be validated by comparing the received ticket with that being sent for the flow. 3.2. Packet format A ticket is sent in a Hop-by-Hop option. Herbert Expires 5 February 2024 [Page 20] Internet-Draft FAST August 2023 3.2.1. Option format The format of an Hop-by-Hop option containing a ticket is: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | Prop | Rsvd | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Ticket data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: * Option type=0xf [TBD]: Type of Hop-by-Hop option. One option type allocation is requested for FAST. The high order two bits of the option type are 00 to indicate that an unknown option should be skipped and no ICMP error is sent. The third high order bit of the type is zero to indicate that the option data does not change en route * Opt Data Len: Length of the option data field. The option data is comprised the Prop, Rsvd, and Type fields and the ticket data. * Prop: Indicates properties of the ticket for reflection and origin. Possible values are: * 0: Non-reflected ticket, don't reflect at receiver * 1: Non-reflected ticket, reflect at receiver * 2: Non-reflected ticket, no forward processing just reflect at receiver * 3: Reflected ticket * Type: Indicates the type and format of the ticket. This value is used by nodes in the origin network to interpret the rest of the ticket data. Values for this field are specific to the network that issues the ticket. Value ranges are: * 0-0x7f: Global types that are specified in a registry (see IANA Considerations) * 0x80-0xff: Private types that may be used within a network or cooperating networks Herbert Expires 5 February 2024 [Page 21] Internet-Draft FAST August 2023 3.2.2. Ticket format A ticket encodes service parameters that describe the desired services as well as additional fields that could be used to provide privacy and integrity of the ticket. The format of a ticket is defined by the network in which the ticket is issued for private ticket types, or by publicly specified global types. A ticket should be obfuscated or encrypted for privacy so that it can only be interpreted in its origin domain. A ticket should be uninterpretable to any nodes outside its origin domain, and it should be opaque to applications or hosts that are granted a ticket. Tickets should be resistant to spoofing or forgery so that an attacker cannot illegitimately get service by applying a ticket seen on other flows. It is RECOMMENDED that tickets are encrypted and each ticket has an expiration time. For instance, a ticket may be created by encrypting the ticket data with an expiration time and using the source address, destination address, and a shared key as the key for encryption. For example, a ticket with an expiration time may have the format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiration time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Service parameters ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the expiration time is in a format understood by the local network nodes which maintain synchronized time. The Service parameters are relevant to local network nodes and describe the services to be applied. The service parameters could simply be a set of flags for services, a Service Parameter Index that is index to a service profile table shared amongst the network nodes, or could have more elaborate structure indicates numerical values for individual service parameters. As suggested in [I-D.yiakoumis-network-tokens], JWT or CWT objects could be used to expresses services in ticket data. Since tickets are sent in the datapath, they should be limited in size to maximize reachability and minimize packet overhead (for instance, [I-D.ietf-6man-eh-limits] suggests that all the IPv6 extension headers in a packet should be limited to sixty-four bytes in size when sending over anonymous networks). Herbert Expires 5 February 2024 [Page 22] Internet-Draft FAST August 2023 A simple ticket containing a thirty-two bit Service Protocol Index with an expiration time might be: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Expiration time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Profile Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the Type indicates the type of ticket and in this case indicates it is a service profile index. Service Profile Index could be an index into a table that describes the services to be applied. Both the expiration time an service profile index could be an encrypted or somehow obfuscated to avoid leaking information to third parties, 4. Operation 4.1. Origin and reflection properties and ordering There are four origin and reflection properties that may be applied to a ticket: * Non-reflected tickets that are not reflected by the receiver * Non-reflected tickets that are reflected by the receiver * Reflected tickets that are processed in the return path * Non-reflected tickets that are not processed in the forward path, but are reflected by the receiver Non-reflected tickets are those set by an application that was issued a ticket and have an additional property indicating whether they are to be reflected by a peer host. Reflected tickets are those that have been received and reflected by a peer host. A sender SHOULD set at most one ticket option for each property in a packet. If ticket options with different properties are set within a single packet, they SHOULD have the following ordering in the Hop-by- Hop Options list: 1. Non-reflected tickets that are not reflected 2. Non-reflected tickets that are reflected Herbert Expires 5 February 2024 [Page 23] Internet-Draft FAST August 2023 3. Non-reflected tickets that not processed in the forward path, but are reflected 4. Reflected tickets If a packet contains more than one non-reflected ticket then only the first one SHOULD be processed in the forward path. If a packet contains more than one ticket to be reflected, then only the first one SHOULD be reflected. If a packet contains more than one reflected ticket then only the first one SHOULD be processed in the return path. 4.2. Application and ticket agent processing A application supporting tickets requests tickets, sets them in packets, and validates reflected tickets. 4.2.1. Ticket requests An application that wishes to use network services first requests tickets from a ticket agent in its local domain. An issued ticket is opaque to the application and the application MUST NOT attempt to interpret it or take any other action other than attaching the ticket to its packets. A ticket agent MAY provide both a ticket not to be reflected and one that is to be reflected. The intent is that different tickets can be used between the forward and return paths for the flow. In the case that two tickets are provided, the not to be reflected SHOULD appear first in the options list. 4.2.2. Ticket agents The document does not specify the protocol or processing of ticket agents. There are a few general possibilities for implementation. One possible design is that a ticket agent is an entity in the local network that applications contact when creating a flow that requires network services. The application may specify its request in XML or JSON structure with canonical elements (the definition is outside the scope of this document). The application makes a request to the ticket agent for the local network. This could be done via a web service using REST APIs. Internally in the host, the ticket agent might be accessed through a library that interfaces to a ticket daemon that in turn arbitrates requests between the applications and a ticket agent in the network. Herbert Expires 5 February 2024 [Page 24] Internet-Draft FAST August 2023 Another approach might be to integrate the ticket agent into the application or the host OS on which an application runs. In the model the host would autonomously create tickets that are compatible with its local origin domain. 4.2.3. Ticket identification Tickets SHOULD be valid only for a specific IP source and destination address for which they were issued. The ticket should contain information to validate that. For instance, if a ticket is encrypted then the IP addresses could be part of the key. Note that transport layer ports and other transport layer information are not included ticket identification, however an application can request tickets and validate reflected tickets on a per flow basis. Issued tickets are stored in the flow context and the saved information SHOULD be used to validate received reflected tickets. 4.2.4. Ticket use When the ticket agent issues and returns a ticket, the application starts setting the ticket in the Hop-by-Hop option of packets. This is typically done by setting a socket option on a socket (in the case of TCP) or by indicating the option in the ancillary data when sending on an unconnected socket (in the case of UDP). The application SHOULD continue to use the same ticket for the flow until it is updated with a new ticket. The ticket agent SHOULD return an expiration time with the ticket. An application can use the ticket until the expiration time, at which point it can request a new ticket to continue communications. In order to make the ticket transition process seamless, an application MAY request a new ticket before the old one expires where for some period of time both the old and new ticket are valid in the origin domain. 4.2.5. Ticket agent delegation A network MAY delegate ticket creation to hosts in a limited fashion. This would entail the network ticket agent issuing a master ticket to a host ticket agent which in turn can use the master ticket to create a limited number of tickets for its own use. The details of ticket agent delegation are outside the scope of this document. Herbert Expires 5 February 2024 [Page 25] Internet-Draft FAST August 2023 4.3. Forward path processing When a packet with a ticket enters a network, a network node can determine if the ticket originated in its network and must be processed. This is done by considering the origin of the ticket and the source or destination IP address. For a non-reflected, the source address is considered. If the source address is local to the network then the ticket can be interpreted as being issued by the local origin domain. For a reflected ticket, the destination address is considered. If the destination address is local to the network then the ticket can be interpreted as being issued by the local origin domain. If a ticket is determined to have been issued by the origin domain of an intermediate node then the ticket is processed. The ticket is decrypted if necessary and the expiration time is checked. If the ticket is verified to be authentic and valid then requested service are applied to the packet. For instance, in a 5G network the packet may be forwarded on a network slice for the characteristics the application has requested (real-time video for instance). If an origin ticket cannot be verified, for instance the ticket cannot be authenticated, then the ticket SHOULD be ignored and the packet processed as though no ticket were present. If tickets are being used for admission control into a network then this MAY result in the packet being dropped. Note that the network can be architected such that tickets only need to be processed at ingress points to a network. Minimally, ticket processing might occur at only two points in a network: at the first hop router when packets with non-reflected tickets are sent from a user device into a provider network, and at a border router when packets with reflected tickets enter the network from external networks or the Internet. It is possible to design FAST handling such that any ticket in a packet is processed at most once within a network, specifically only at these two ingress points. Once a ticket is processed and mapped to the network's internal service mechanisms, it should not need further examination. This design serves as a valuable optimization because ticket processing may be expensive, for instance decrypting a ticket, and so it's desirable to limit ticket processing in a network to a few specialized nodes designed to efficiently process tickets. 4.4. Peer host processing When a peer host receives a non-reflected ticket it SHOULD NOT process the ticket unless the host is in the same origin domain of the ticket and it is configured to process tickets. Herbert Expires 5 February 2024 [Page 26] Internet-Draft FAST August 2023 When a host receives a packet with a ticket whose property is "reflect", it SHOULD save the ticket in its flow context and reflect it on subsequent packets. When the application reflects ticket, it copies the whole option and modifies the ticket property to be "reflected ticket". The application SHOULD continue to reflect the ticket until a different one is received in a packet of the flow or a packet without a service ticket option is received on the flow. In the latter case, if a packet is received for a flow with no ticket to reflect, then the receiver should clear its saved ticket for the flow and not send a reflected ticket until a packet is received on the flow that contains a ticket to reflect. Note that the latest ticket that is received is the one to be reflected, if packets have been received out of order relative to the transport flow then it is possible that the reflected ticket is from an earlier packet in a flow and the source attempted to update the ticket. A receiver SHOULD NOT determine the proper ticket to use based on transport layer ordering, and sending reflected tickets out of order MUST NOT lead to insidious behaviors. When a peer host sends a packet with reflected tickets, it MAY also attach its own tickets for processing in its local origin domain. These peer host MAY request the ticket to be reflected or not reflected. 4.5. Processing reflected tickets 4.5.1. Network processing When a packet with a reflected ticket enters the origin network of the ticket, the ticket SHOULD be processed. The ticket is first validated. Validation entails decoding or decrypting the ticket and checking the expiration time. If the ticket is valid and has not expired time then the services expressed in the ticket can be applied.. A network MAY accept expired reflected tickets for some configurable period after the expiration time. Rate limiting SHOULD be applied to packets with expired reflected tickets. Accepting expired tickets is useful in the case that a connection goes idle and after sometime the remote peer starts to send. The ticket it reflects MAY be expired and presumably the receiving host will quickly respond with a new ticket to be reflected. Herbert Expires 5 February 2024 [Page 27] Internet-Draft FAST August 2023 If a ticket fails validation then an appropriate action is taken. If tickets are only being used to request QoS services, then the appropriate action might be to forward the packet with default, best effort service. If tickets are being used for admission control, e.g. for passing through a firewall, then the appropriate action may be to drop the packet. If ticket validation fails the packet SHOULD be logged. 4.5.2. Host processing Upon receiving a packet with a reflected ticket, an end host SHOULD validate the ticket before accepting the packet. This verification is done by comparing the received ticket to that which is set to be sent on the corresponding flow. If the tickets do not match then the packet MAY be dropped and the event SHOULD be logged. A host SHOULD retain and validate expired tickets that are reflected to allow a peer time to receive and reflect an updated ticket. 4.6. Handling dropped extension headers The downside of using IPv6 extension headers on the Internet is that they are currently not completely reliable. Some intermediate nodes will drop extension headers with rates described in [RFC7872]. 4.6.1. Mitigation for dropped extension headers There are some mitigating factors for this problem: * FAST could be deployed in limited domains where the networks is designed to properly handle extension headers. * A provider network that implements tickets would need to ensure that extension headers are at least usable within their network. * Transit networks are less likely to arbitrarily drop packets with extension headers. * Many content providers, especially the larger ones, may be directly connected to the Internet. For example, front end web servers may be co-located as exchange points. * The requirement that nodes must process Hop-by-hop options has been relaxed in [RFC8200]. It is permissible for intermediate nodes to ignore them. * Increased deployment of IPv6 and viable use cases of extension headers, such as described here, may motivate vendors to fix issues with extension headers. Herbert Expires 5 February 2024 [Page 28] Internet-Draft FAST August 2023 4.6.2. Fallback for dropped extension headers Since the possibility that extension headers are dropped cannot be completely eliminated, a fallback is prescribed for use with tickets. When an application connects to a new destination for which it has no history about the viability of extension headers, it can perform a type of Happy Eyeballs probing. The concept is for a host to send a number of packets with and without tickets. The application can observe whether packets with tickets are being dropped or not being reflected. There are a few possible outcomes of this process: * A packet with a ticket is dropped and an ICMP error for extension headers [RFC8883] processing limits is received. This is a strong signal that extension headers are not viable to the destination and should not be used for the flow. * A packet with a ticket is dropped and no ICMP error is received. This is a signal that extension headers may not be usable. If such drops are observed for all or a significant fraction of packets and there are no drops for packets that were sent without tickets, then extension headers should be considered not usable to the destination * Packets with tickets are not being dropped, however tickets are not being reflected. This is a signal that the peer application does not support reflection, or packets with extension headers are being dropped in the return path. Tickets may be sent, however they are only useful in the forward path, so a host should not request tickets to be reflected. * Packets with tickets are not being dropped and tickets are properly being reflected. Tickets are useful in both directions. 5. Implementation considerations 5.1. Application support Existing client applications can be modified to request tickets and send them in packets. The OS networking stack may need some small changes or configuration to enable an application to specify the option for its packets. The interface to the ticket agent would likely be via a library API. Herbert Expires 5 February 2024 [Page 29] Internet-Draft FAST August 2023 For a connected socket (TCP, SCTP, or connected UDP socket), a Hop- by-Hop option can be set on the socket via the setsockopt system call in BSD sockets API. For an unconnected socket (UDP) the ticket option can be set as ancillary data in the sendmsg system call. Happy Eyeballs for extension headers or simple probing could be implemented in the networking stack for a connection oriented transport protocol such as TCP. For connectionless protocols, probing could be handled by an application library. 5.2. Ticket reflection To perform ticket reflection, servers must be updated. In the case of a connected socket (TCP, SCTP, or a connected UDP socket) this can be done as relatively minor change to the kernel networking stack which would be transparent to applications. For unconnected UDP, an application could receive the ticket as part of the ancillary data in recvmsg system call, and then send the reflected ticket in a reply using ancillary data in sendmsg. 6. Security Considerations There are three main security considerations: * Leakage of content specific information to untrusted third parties must be avoided. * Tickets cannot be forged, illegitimately used, or otherwise abused. * The presence or processing of tickets cannot lead to Denial of Service attacks. Tickets may be exposed to third parties on the Internet including untrusted and unknown networks in the path of packets. Therefore, tickets should be encrypted or obfuscated by the origin network. Tickets need to have an expiration time, must be resistant to forgery, and must be non transferable. A ticket should be valid for the specific source and destination addresses that it was issued for. Tickets are could revocable by implemented a banned-list containing revoked tickets. If a network supports tickets, it should manage resources to avoid Denial of Service for processing tickets. Various techniques to minimize the processing cost and properly provision the network to handle worst case load should be considered. Herbert Expires 5 February 2024 [Page 30] Internet-Draft FAST August 2023 7. IANA Considerations IANA is requested to assigned the following Hop-By-Hop option: +-----------+---------------+-------------+---------------+ | Hex Value | Binary value | Description | Reference | | | act chg rest | | | +-----------+---------------+-------------+---------------+ | 0x0F [TBD]| 00 0 01111 | Firewall | This document | | | | and Service | | | | | Ticket | | +-----------+---------------+-------------+---------------+ IANA is requested to set up a registry for the Ticket property. These types are 4 bit values. New values for 0x4-0xf are assigned via Standards Action [RFC8126]. +----------------+----------------------+---------------+ | Ticket property| Description | Reference | +----------------+----------------------+---------------+ | 0x0 | Non-reflected ticket | This document | | | and don't reflect | | +----------------+----------------------+---------------+ | 0x1 | Non-reflected ticket | This document | | | and reflect | | +----------------+----------------------+---------------+ | 0x2 | Non-reflected ticket,| This document | | | don't process but | | | | reflect | | +----------------+----------------------+---------------+ | 0x3 | Reflected ticket | This document | +----------------+----------------------+---------------+ IANA is requested to set up a registry for the Ticket types. These types are 8 bit values. Value 0 to 0x7f are reserved for assignment via Standards Action [RFC8126]. Values 0x80 to 0xff are for private use. +----------------+--------------------+---------------+ | Ticket type | Description | Reference | +----------------+--------------------+---------------+ | 0x0-0x7f | Assignable | This document | +----------------+--------------------+---------------+ | 0x80-0xff | Private use | This document | +----------------+--------------------+---------------+ 8. References Herbert Expires 5 February 2024 [Page 31] Internet-Draft FAST August 2023 8.1. Normative References [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 8.2. Informative References [I-D.cc-v6ops-wlcg-flow-label-marking] Carder, D. W., Chown, T., McKee, S., and M. Babik, "Use of the IPv6 Flow Label for WLCG Packet Marking", Work in Progress, Internet-Draft, draft-cc-v6ops-wlcg-flow-label- marking-02, 10 July 2023, . [I-D.elkins-v6ops-eh-deepdive-cloud] Elkins, N., Sinha, P., and A. Deshpande, "Deep Dive into IPv6 Extension Header Testing: Cloud", Work in Progress, Internet-Draft, draft-elkins-v6ops-eh-deepdive-cloud-00, 6 July 2023, . [I-D.herbert-ipv4-eh] Herbert, T., "IPv4 Extension Headers and Flow Label", Work in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2 May 2019, . [I-D.ietf-6man-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-04, 6 May 2023, . [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-09, 4 July 2023, . Herbert Expires 5 February 2024 [Page 32] Internet-Draft FAST August 2023 [I-D.ietf-tsvwg-udp-options] Touch, J. D., "Transport Options for UDP", Work in Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-22, 9 June 2023, . [I-D.ioametal-ippm-6man-ioam-ipv6-options] Bhandari, S., Brockners, F., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., Spiegel, M., Krishnan, S., and R. Asati, "In-situ OAM IPv6 Options", Work in Progress, Internet- Draft, draft-ioametal-ippm-6man-ioam-ipv6-options-02, 28 March 2019, . [I-D.kaippallimalil-tsvwg-media-hdr-wireless] Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media Header Extensions for Wireless Networks", Work in Progress, Internet-Draft, draft-kaippallimalil-tsvwg- media-hdr-wireless-02, 5 July 2023, . [I-D.reddy-tsvwg-explcit-signal] Reddy.K, T., Wing, D., and M. Boucadair, "An Approach for Encrypted Transport Protocol Path Explicit Signals", Work in Progress, Internet-Draft, draft-reddy-tsvwg-explcit- signal-01, 7 July 2023, . [I-D.yiakoumis-network-tokens] Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network Tokens", Work in Progress, Internet-Draft, draft- yiakoumis-network-tokens-02, 22 December 2020, . [PLUS] Tramell, B. and M. Kuehlewind, "Path Layer UDP Substrate Specification", December 2016, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Herbert Expires 5 February 2024 [Page 33] Internet-Draft FAST August 2023 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, . [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, "Observations on the Dropping of Packets with IPv6 Extension Headers in the Real World", RFC 7872, DOI 10.17487/RFC7872, June 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [RFC8837] Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS", RFC 8837, DOI 10.17487/RFC8837, January 2021, . [RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to Processing Limits", RFC 8883, DOI 10.17487/RFC8883, September 2020, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . Herbert Expires 5 February 2024 [Page 34] Internet-Draft FAST August 2023 [RFC9098] Gont, F., Hilliard, N., Doering, G., Kumari, W., Huston, G., and W. Liu, "Operational Implications of IPv6 Packets with Extension Headers", RFC 9098, DOI 10.17487/RFC9098, September 2021, . [RFC9419] Arkko, J., Hardie, T., Pauly, T., and M. Kuhlewind, "Considerations on Application - Network Collaboration Using Path Signals", RFC 9419, DOI 10.17487/RFC9419, July 2023, . [TLSCERT] "Alert (TA17-075A), HTTPS Interception Weakens TLS Security", March 2017, . [_3GPP-5G] "5G; System Architecture for the 5G System", September 2018, . Author's Address Tom Herbert SiPanda Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 5 February 2024 [Page 35]