Network Working Group T. Herbert Internet-Draft SiPanda Intended status: Standards Track 7 October 2023 Expires: 9 April 2024 Firewall and Service Tickets draft-herbert-fast-07 Abstract This document describes the Firewalls and Service Tickets (FAST) protocol. This is a generic and extensible protocol for hosts to signal network nodes to request services or to gain admission into a network. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network services to be applied (in the latter case the ticket serves as a service profile). Applications request tickets from a local agent in their network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to packets. A single ticket may provide both firewall and service ticket information and semantics. 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 9 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Herbert Expires 9 April 2024 [Page 1] Internet-Draft FAST October 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. Motivation for FAST . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Hop-by-Hop Options as a signal carrier . . . . . . . . . . . 4 2.1. Motivation for using Hop-by-Hop Options . . . . . . . . . 4 2.2. Drawbacks of Hop-by-Hop Options . . . . . . . . . . . . . 5 2.2.1. Mitigating Hop-by-Hop Options packet drops . . . . . 5 2.2.2. Support in IPv4 . . . . . . . . . . . . . . . . . . . 6 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Example communications flow . . . . . . . . . . . . . . . 8 4. Protocol format . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Option format . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Option types . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Ticket Data format . . . . . . . . . . . . . . . . . . . 11 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Origin and reflection properties . . . . . . . . . . . . 12 5.2. Origin application processing . . . . . . . . . . . . . . 13 5.2.1. Ticket requests . . . . . . . . . . . . . . . . . . . 13 5.2.2. Ticket identification . . . . . . . . . . . . . . . . 14 5.2.3. Ticket use . . . . . . . . . . . . . . . . . . . . . 14 5.2.4. Ticket agent delegation . . . . . . . . . . . . . . . 14 5.3. Origin network processing . . . . . . . . . . . . . . . . 15 5.4. Destination host processing . . . . . . . . . . . . . . . 16 5.5. Processing reflected tickets . . . . . . . . . . . . . . 16 5.5.1. Network processing . . . . . . . . . . . . . . . . . 16 5.5.2. Host processing . . . . . . . . . . . . . . . . . . . 16 5.6. Removing tickets from packets . . . . . . . . . . . . . . 17 5.6.1. Methods to remove tickets . . . . . . . . . . . . . . 17 5.6.1.1. Overwriting with a null ticket . . . . . . . . . 17 5.6.1.2. Removing Hop-by-Hop Options containing tickets . 17 5.6.2. Removing tickets without loss of functionality . . . 17 5.6.3. Removing tickets with loss of functionality . . . . . 18 6. Implementation considerations . . . . . . . . . . . . . . . . 19 6.1. Origin applications . . . . . . . . . . . . . . . . . . . 19 6.2. Router implementation . . . . . . . . . . . . . . . . . . 20 6.3. Ticket reflection . . . . . . . . . . . . . . . . . . . . 20 6.4. Security Considerations . . . . . . . . . . . . . . . . . 20 Herbert Expires 9 April 2024 [Page 2] Internet-Draft FAST October 2023 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Firewall and Service Tickets (FAST) is a protocol to allow an application to signal the network to request admission and services for packets. FAST is the carrier of signals in host to network signaling. The motivation and use cases of host to network signaling are discussed in [I-D.herbert-host2netsig]. A ticket is data that is attached to a packet by a source node and is validated and processed by some or all intermediate nodes in a network. Tickets can express a grant for packets to traverse a network or have services applied to them. Tickets can be opaque or have a visible structure containing attributes of requested services. Tickets may be encrypted and integrity protected to limit visibility and prevent abuse. An application requests tickets for admission or services from a ticket agent in their local network. The agent issues tickets to the application which in turn attaches them to its packets. In the forwarding path, intermediate network nodes may interpret tickets and apply requested services on packets. Tickets are validated for authenticity by the network and may contain an expiration time so that they cannot be easily forged. Tickets do not have a global interpretation, they can only be interpreted in the context of the network or limited domain [RFC8799] that issues them. In order to apply services to inbound packets for a communication, remote peers reflect received tickets in packets they send without interpreting them. Tickets are stateless within the network, however they can be used to attain per flow semantics. Firewall and service tickets should be non-transferable and revocable. Tickets are coded in IPv6 Hop-by-Hop options. 1.1. Motivation for FAST The general motivation and use cases for host to network signaling is discussed in [I-D.herbert-host2netsig]. The motivation for using IPv6 Hop-by-Hop Options as the carrier of host to network signals is discussed below. Herbert Expires 9 April 2024 [Page 3] Internet-Draft FAST October 2023 1.2. 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. Hop-by-Hop Options as a signal carrier The carrier of host to network signaling in FAST is IPv6 Hop-by-Hop Options [RFC8200]. This section discusses the motivation for using Hop-by-Hop Options, the drawbacks of Hop-by-Hop Options, and methods to mitigate those drawbacks. 2.1. Motivation for using Hop-by-Hop Options [I-D.herbert-host2netsig] discusses some alternatives that might be considered for the carrier protocol of host to network signaling. Compared to the these alternatives, Hop-by-Hop Options has a number advantages that motivate the use of Hop-by-Hop Options as the ubiquitous carrier of host to network signals: * IPv6 Hop-by-Hop Options are explicitly designed to be a standard and extensible protocol for host to network signaling on a per packet basis. Hop-by-Hop options also facilitate network to host signaling. * Hop-by-Hop Options are defined as part of an Internet standard STD 86 [RFC8200]. * Hop-by-Hop Options are a network layer protocol and are independent of both transport layer and link layer protocols. * Hop-by-Hop Options work with any transport protocol, encrypted IPsec tunnels, as well as any other encapsulation protocols in IPv6. * Hop-by-Hop Options are variable length to allow rich expression. * Hop-by-Hop Options are stateless. * Hop-by-Hop Options can change between packets of the same flow. * Hop-by-Hop Options are explicitly intended to be processed by intermediate nodes in the path of a packet. Herbert Expires 9 April 2024 [Page 4] Internet-Draft FAST October 2023 * Hop-by-Hop Options are located in headers of a packet as opposed to trailers, and the Hop-by-Hop Options header immediately follows the IPv6 header at a fixed offset in the packet. These characteristics make Hop-by-Hop Options amenable to efficient processing in both software and hardware implementations. 2.2. Drawbacks of Hop-by-Hop Options Hop-by-Hop Options have two main drawbacks: * Packets containing Hop-by-Hop Options headers may be summarily discarded by some network providers as a matter of policy [RFC7872],[RFC9098]. * Hop-by-Hop Options is an IPv6 specific protocol, there is no equivalent protocol in IPv4. The sections below describe mitigations for these drawbacks. 2.2.1. Mitigating Hop-by-Hop Options packet drops The original processing requirements of IPv6 [RFC2460] Hop-by-Hop Options required all routers in the path to process the Hop-by-Hop Options header and its options. In response to this requirement, some routers deferred processing of Hop-by-Hop Options to the software slow path, others ignored them, and still others elected to summarily discard 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 the high order bit in the option type isn't set, created 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 significantly impeded to the point that the current data suggests that packet with Hop-by-Hop Options have more than a 99% drop rate [APNIC-EH]. 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, and the current assumption in defining any new option is that it may be processed by only by some nodes in the path or even none at all. Allowing nodes to ignore options they're not interested in, instead of just discarding the packets, preserves the usability of Hop-by-Hop across the whole path. Herbert Expires 9 April 2024 [Page 5] Internet-Draft FAST October 2023 * [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 Options 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. * [I-D.herbert-eh-inflight-removal] describes a protocol to remove Hop-by-Hop Options headers from packets in-flight. This could be applied in FAST by arranging that the last router that processes a ticket in a Hop-by-Hop option removes the Hop-by-Hop Options header from the packet. By removing the Hop-by-Hop Options header, downstream nodes would allow the packet and no functionality is lost since the ticket isn't relevant to the downstream routers. 2.2.2. Support in IPv4 A new IPv4 option could be defined to contain tickets. IPv4 options are designed to be inspected by intermediate nodes, however support is not widespread to the extent that they may be less deployable than even IPv6 Hop-by-Hop Options. A major reason for this is that the IPv4 header, unlike the IPv6 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 packet discards or packets being relegated to slow path processing. An alternative to IPv4 Options is to enable Extension Headers in IPv4 [I-D.herbert-ipv4-eh] and use Hop-by-Hop Options in IPv4 packets. This solution doesn't affect the IP header, but does introduce a new IP protocol to IPv4 devices. Some routers might need to be configured to forward IPv4 packets with IP Protocol 0 for Hop-by-Hop Options. This scheme would affect ECMP routing since the transport layer 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. Herbert Expires 9 April 2024 [Page 6] Internet-Draft FAST October 2023 3. Architecture The figure below illustrates an example of network paths between three communicating hosts. Each host connects to the Internet via a provider network, and provider networks are connected in the Internet by transit networks. In this example, User 1 and User 2 reside in Provider A's network and User 2 is in Provider B's network. With respect to FAST, we'll assume User 1 and User 2 are in the same limited domain and User 3 is in a different limited domain than User 1 and User 2. _____ __________ ( ) __________ +--------+ ( ) ( ) ( ) +--------+ | User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 3 | +--------+ (__________) ( ) (__________) +--------+ | (_____) +--------+ | User 2 | +--------+ Figure 1 Within each provider network, services may be provided on behalf of the users of the network. In the figure above, Provider 1 may provide services and service agreements for users in its network including User 1 and User 2; and likewise Provider B can provide services to users in its network including User 3. We assume transit networks don't typically provide user specific services or service differentiation. 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. The ticket has meaning in its "origin network", that is the provider network in which the ticket was created. A ticket provided by a local ticket agent is attached to packets as an "origin ticket". When a packet is sent by the application with an attached origin ticket, the ticket is interpreted by nodes in the local provider network as the origin network of the ticket. The ticket is interpreted and processed to allow the packet to traverse the network and to map it to the appropriate services. A ticket is only relevant Herbert Expires 9 April 2024 [Page 7] Internet-Draft FAST October 2023 to the origin network that issued the ticket; to the application itself and nodes outside of the provider's network and its limited domain, the ticket is an uninterpretable opaque object. To facilitate network traversal and service mapping in the reverse direction for a flow, that is packets sent from a peer host, peer hosts reflect tickets without modification or interpretation. This is done by saving the ticket received in packets of a flow and attaching the ticket as a "reflected ticket" to packets being sent on the flow. When a packet with a reflected ticket enters the origin network of the ticket, the ticket is processed by a network node to allow the packet to traverse the network and to map it to the appropriate services. 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. Tickets are scoped values, they only have meaning in the network in which they were issued. The format, meaning, and interpretation of tickets are network specific. By mutual agreement, two networks may share the policy and interpretations of tickets. 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 with reflected tickets. Herbert Expires 9 April 2024 [Page 8] Internet-Draft FAST October 2023 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, 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. A ticket reply is sent to the Client. 3. The video chat application sends packets for the video chat with the ticket attached in Hop-by-Hop Options. 4. The first hop node 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. Herbert Expires 9 April 2024 [Page 9] Internet-Draft FAST October 2023 6. Packets traverse transit networks and the Server's provider network, the attached tickets are ignored. 7. Packets are received at the Server. Attached tickets are saved in the context of the flow for the video chat. 8. The Server's video chat application sends packets back to the Client. The last ticket previously received from the Client is now reflected in these packets. 9. Packets traverse the Server's provider network and transit networks, the reflected ticket is ignored. 10. An ingress node 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. 12. Packets are received at the host for the Client. The reflected ticket may be validated by comparing the received reflected ticket with that being sent for the flow. 4. Protocol format A ticket is sent in an option in a Hop-by-Hop Options header. 4.1. Option format The format of a 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 | Pr| Ticket Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Ticket Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: * Option Type: Type of Hop-by-Hop option. This document proposes two possible types for FAST ticket options: an unmodifiable and a modifiable variant. Herbert Expires 9 April 2024 [Page 10] Internet-Draft FAST October 2023 * Opt Data Len: Length of the option data field. The option data is comprised the Pr, Ticket Type, and Ticket Data fields. * Pr: Indicates the origin and reflection properties of the ticket. Possible values are: - 0x0: Origin ticket not reflected. Don't reflect at receiver - 0x1: Origin ticket to be reflected. Ticket is requested to be reflected by the destination host - 0x2: Reflected ticket. The ticket was reflected by a destination host and is being returned to the origin source host - 0x3: Reserved * Ticket Type: 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. The type is an IANA managed number space. A type of 0 indicates a "null" ticket that isn't to be processed by receivers. * Ticket Data: Contains the ticket data that describes the service applied. The format of the data is determined by the Ticket Type. 4.2. Option types The are two option numbers requested for the ticket option: 0x0F and 0x2F. The latter allows modification by network nodes. Since tickets are secured, only the nodes in the network that created a ticket will be able to modify it. 4.3. Ticket Data format The Ticket Data in FAST Ticket option encodes service parameters that describe the desired services as well as additional fields that would be used to provide privacy and integrity. The format of Ticket Data is not fixed and is determined by the Ticket Type and the origin network of the ticket. A ticket should be obfuscated or encrypted for privacy so that only the local network can interpret it. It should be uninterpretable to any nodes outside the network and to the application or host that is granted a ticket. A ticket should be resistant to spoofing so that an attacker cannot illegitimately get service by applying a ticket observed on other flows. Herbert Expires 9 April 2024 [Page 11] Internet-Draft FAST October 2023 It is RECOMMENDED that tickets are encrypted to prevent unnecessary information exposure and abuse of tickets. It is also RECOMMENDED that tickets have 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, an index to a service profile table shared amongst the network nodes, or possibly have more elaborate structure that could indicate numerical values for characteristics that have a range. A simple ticket containing a service protocol index might 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 Profile Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where the Ticket Type would indicate the Ticket Data contains a service profile index. Service Profile Index could be used as an index into a table that describes the services to be applied. 5. Operation 5.1. Origin and reflection properties There are three origin and reflection properties that may be applied to a ticket: Herbert Expires 9 April 2024 [Page 12] Internet-Draft FAST October 2023 * Origin tickets not reflected * Origin tickets to be reflected * Reflected tickets Origin 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: * Origin ticket not reflected * Reflected ticket * Origin ticket to be reflected If a packet contains more than one ticket option with the same origin and reflection property, only the first ticket option appearing in the list for the property is processed. Additional options for the same property MAY be parsed but SHOULD NOT be processed. 5.2. Origin application processing An origin application requests tickets, sets them in packets, and validates reflected tickets. 5.2.1. Ticket requests An application that wishes to use network services first requests tickets from a ticket agent. The application request could be in the form of an XML structure with canonical elements (the definition is outside the scope of this document). The application makes a request to a ticket agent in its 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. An issued ticket is opaque to the application and the application SHOULD NOT attempt to interpret it or take any other action other than to attach the ticket to its packets. Herbert Expires 9 April 2024 [Page 13] Internet-Draft FAST October 2023 A ticket agent MAY provide both an origin ticket not 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 origin ticket not reflected MUST appear first in the options list and the origin ticket to be reflected SHOULD NOT be processed in the forward path. The protocols and details for making requests to ticket agents are out of scope for this specification. 5.2.2. Ticket identification Tickets are valid for the specific IP source and destination addresses for which they were issued. 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 is used to validate reflected tickets. 5.2.3. Ticket use When the ticket agent issues and returns a ticket, the application sets the ticket as a Hop-by-Hop option in 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 a 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. 5.2.4. Ticket agent delegation A network MAY delegate creation of tickets 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 9 April 2024 [Page 14] Internet-Draft FAST October 2023 5.3. Origin network processing When a packet with a ticket enters a network, an ingress 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 an origin ticket (i.e. a ticket is not reflected), the source address is considered. If the source address is local to the network then the ticket can be interpreted. For a reflected ticket, the destination address is considered. If the destination address is local to the network then the ticket can be interpreted. If the ticket origin is determined to be the local network 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 the packet is mapped to be processed by the requested services. For instance, in a 5G network the packet may be forwarded on a network slice for the characteristics that 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. Note that there are logically only two ingress points into the network at which a provider needs to process tickets: when a local user sends a packet into the provider network with an origin ticket, and when a packet from an external network enters the provider's network with a reflected ticket. Typically, a ticket should only need to be processed at most once within a network at one of these ingress points. Once a ticket is processed and mapped to the network's service mechanisms, it should not normally need further processing or examination. If there is more than one origin ticket present, then the first one encountered is processed and any additional origin tickets SHOULD be ignored by a network node. Note that this will be the case if a ticket agent issued both a origin ticket not reflected and one to be reflected; the origin ticket not reflected should appear first in the packet and thus would be the one processed by nodes in the origin network of the ticket. If there is more than one reflected ticket present, then the first one encountered is processed and any additional reflected tickets SHOULD be ignored. Herbert Expires 9 April 2024 [Page 15] Internet-Draft FAST October 2023 5.4. Destination host processing When a host receives a packet with an origin ticket to be reflected, it SHOULD save the ticket in its flow context and reflect it on subsequent packets. When the application reflects the option, it copies the whole option and only modifies the type to indicate a "reflected ticket". The application SHOULD continue to reflect the ticket for packets of the flow until a different one is received from the origin or a packet without an origin ticket to be reflected is received on the flow. Note that the latest ticket received is the one to be reflected, if packets have been received out of order for a flow it is possible that the reflected ticket is from an earlier packet in a flow. If there is more than one origin ticket to be reflected present, then the first one encountered is processed and any additional origin tickets to be reflected SHOULD be ignored. A destination host MUST ignore received origin tickets not reflected. 5.5. Processing reflected tickets 5.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 validated. Validation entails decoding or decrypting the ticket and checking the expiration time. If the ticket is valid and has not expired then the ticket is processed. A network MAY accept expired reflected tickets for some configurable period after the expiration time. Rate limiting MAY 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 of the reflected ticket will quickly respond with a new origin ticket to be reflected. 5.5.2. Host processing Upon receiving a packet with a reflected ticket, an end host MAY 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 event SHOULD be logged. A host MAY accept expired tickets that are reflected to allow a peer time to receive and reflect an updated ticket. Herbert Expires 9 April 2024 [Page 16] Internet-Draft FAST October 2023 5.6. Removing tickets from packets Once the last node in a network path has processed a ticket in a packet, any network downstream nodes won't need to access the ticket. As stated above, typically only one node in the network needs to process a ticket. Once a ticket has been processed by the last node that processes it, it can safely be removed from the packet since it's not needed by any downstream nodes. The motivation for removing tickets in-flight is two-fold: 1) It's a security measure to minimize visibility of the data, and 2) It simplifies the packet to increase chances of successful delivery across a network. 5.6.1. Methods to remove tickets There are two methods to remove a ticket from a packet: * Create a "null" ticket option by writing zeros in the option data. * Remove the Hop-by-Hop Options header containing the ticket 5.6.1.1. Overwriting with a null ticket A ticket can be removed from a packet by overwriting the option data of the ticket with all zeroes. The ticket option type MUST be the modifiable variant. Ticket Type 0 is reserved as the "null" type and is not processed by any receivers. Using this method to remove the option eliminates visibility of ticket data to downstream network nodes. 5.6.1.2. Removing Hop-by-Hop Options containing tickets Tickets can be removed from packets by removing the Hop-by-Hop Option header containing the tickets. The protocol for removing the Hop-by- Hop Options header in-flight is specified in [I-D.herbert-eh-inflight-removal]. Note that a Hop-by-Hop Options may contain multiple tickets or other unrelated options, if multiple options are present then the effects of removing the whole Hop-by-Hop Options header should be considered ([I-D.herbert-eh-inflight-removal] offers some guidance). 5.6.2. Removing tickets without loss of functionality A ticket may be removed from a packet without loss of functionality under these conditions: Herbert Expires 9 April 2024 [Page 17] Internet-Draft FAST October 2023 * The last network node that processes a packet containing an origin ticket not reflected MAY remove the ticket from a packet. It may be typical that the last network node that processes the ticket is the first hop router in the network, so removing the ticket minimizes visibility of the ticket data to network nodes. * The last network node that processes a reflected ticket MAY remove the ticket from a packet. It may be typical that the last network node to process a reflected ticket will be the ingress network node of packets received from an external network. An origin ticket to be reflected cannot be removed from a packet without affecting functionality. In order for the ticket to be reflected back to the source host, it must be received by the destination host. 5.6.3. Removing tickets with loss of functionality In some cases it may be beneficial to remove tickets from packets at the cost of losing some functionality. For instance, when a packet with tickets is exiting a limited domain, it may be better to remove the Hop-by-Hop Options header containing the ticket rather than forwarding the packet outside of the limited domain and risking that the packet will be discarded because it contains a Hop-by-Hop Options header. In the case of FAST, the effects of removing Hop-by-Hop Options depends on the properties of tickets in the Hop-by-Hop Options that are being removed: * If an origin ticket not reflected is removed then presumably no intermediate nodes outside the limited domain would process the ticket, so there is no expected loss of functionality. * If an origin ticket to be reflected is removed then the ticket will not be seen by the peer host and will thus never be reflected. Ingress routers in the return path from the peer will need to employ alternative mechanisms to deduce packet characteristics for applying services or may just perform default processing of packets. Herbert Expires 9 April 2024 [Page 18] Internet-Draft FAST October 2023 * If a reflected ticket is removed then the peer network will not see the ticket and thus its ingress nodes may need to employ alternate mechanisms to deduce packet characteristics for applying services or may just perform default processing of packets. Note that when a reflected ticket is sent this indicates that an origin ticket to be reflected was received by a destination host. This establishes that Hop-by-Hop Options are viable over the path from the original source of the ticket to the reflecting host. If the network path is symmetric in both directions, then this might indicate that Hop-by-Hop Options are viable in the return direction as well. Removing a Hop-by-Hop Options header containing reflected tickets or tickets to be reflected when a packet exits a limited domain represents a tradeoff. On one hand, the benefits and functionality of ticket reflection are lost, but on the other hand packet discards may be avoided so communications are still viable and any origin tickets sent can still be applied in the origin network before the Hop-by-Hop Options header is removed. To preserve the benefits as much as possible, the limited domain can be extended to be as large as possible. As suggested in Figure 1, if two hosts reside in the same limited domain, like User 1 and User 2, then there is no need to discard packets with tickets to be reflected or reflected tickets. It conceivable that methods like probing could be used to extend the limited domain for Hop-by-Hop Options header viability. For instance, a type of Happy Eyeballs probing could be done where hosts or network nodes probe the capabilities of a path to a destination by sending a number of packets with tickets to be reflected. The sending host can observe whether packets with tickets are being properly reflected. If tickets are successfully being reflected then that is evidence that Hop-by-Hop Options are viable the network path to and from the destination. A table of destination networks could be distributed to egress routers of the network, and when they forward packets with tickets, the routers could consult the table to determine if the Hop-by-Hop Options header containing the tickets should be removed. 6. Implementation considerations 6.1. Origin applications Existing client applications can be modified to request tickets and set them in packets. The OS networking stack may need some changes or configuration to enable an application to specify the Hop-by-Hop option in its packets. Herbert Expires 9 April 2024 [Page 19] Internet-Draft FAST October 2023 The interface to the ticket agent would likely be via a library API. 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. 6.2. Router implementation Routers that process tickets will need to process Hob-by-Hop Options headers. As described in [I-D.ietf-6man-hbh-processing], routers should process the ticket options in the fast path. Routers can also apply the limits described in [I-D.ietf-6man-eh-limits] to limit processing to only FAST options. For instance, if a Hop-by-Hop Options header contains FAST options, the router would need to process or parse at most two options (an origin ticket and a reflected ticket). Thus the router could enforce a limit on number of Hop-by-Hop options in a packet to be two (presuming there are no other Hop-by-Hop Options of interest and that the FAST options always precede other Hop-by-Hop options that might not be relevant to the router). If the tickets defined in a network are all some well known fixed length then a router could implement processing of fixed length Hop- by-Hop Options headers instead of variable length ones. Since the Hop-by-Hop Options header immediately follows the IPv6 header, the combination of the IPv6 header and the Hop-by-Hop Options header could be processed as one extended fixed length header. 6.3. 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.4. Security Considerations There are two main security considerations: * Leakage of content specific information to untrusted third parties must be avoided. Herbert Expires 9 April 2024 [Page 20] Internet-Draft FAST October 2023 * Tickets cannot be forged, illegitimately used, or otherwise abused. Tickets may be visible to the Internet including untrusted and unknown networks in the path of sent packets. Therefore, tickets should be encrypted or obfuscated by the origin network. The details of encrypting tickets are outside the scope of this document. 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 may be revocable by implemented a black-list contained revoked tickets. 7. IANA Considerations IANA is requested to assigned the following Hop-By-Hop options: +-----------+---------------+-------------+---------------+ | Hex Value | Binary value | Description | Reference | | | act chg rest | | | +-----------+---------------+-------------+---------------+ | 0x0F | 00 0 01111 | Firewall | This document | | | | and Service | | | | | Ticket | | +-----------+---------------+-------------+---------------+ | 0x2F | 00 1 01111 | Modifiable | This document | | | | Firewall | | | | | and Service | | | | | Ticket | | +-----------+---------------+-------------+---------------+ IANA is requested to set up a registry for the Ticket Property. These types are 2 bit values. +----------------+--------------------+---------------+ | Ticket type | Description | Reference | +----------------+--------------------+---------------+ | 0x0 | Ticket from origin | This document | | | and don't reflect | | +----------------+--------------------+---------------+ | 0x1 | Ticket from origin | This document | | | and reflect | | +----------------+--------------------+---------------+ | 0x2 | Reflected ticket | This document | +----------------+--------------------+---------------+ | 0x3 | Reserved | This document | +----------------+--------------------+---------------+ Herbert Expires 9 April 2024 [Page 21] Internet-Draft FAST October 2023 IANA is requested to create a new sub-registry titled "FAST Ticket Types" for ticket types. The "FAST Ticket Types" registry consists of 14-bit hexadecimal values along with descriptive strings, assignee/contact information, and references. The registration rules for the new registry are (as defined by [RFC8126]): +-------------------+------------------------------------+ | Range | Registration Procedures | +-------------------+------------------------------------+ | 0x0000 | This document ("null" type) | +-------------------+------------------------------------+ | 0x0001-0x00FF | IETF Review | +-------------------+------------------------------------+ | 0x0100-0x3EFF | First Come First Served | +-------------------+------------------------------------+ | 0x3F00-0x3FFF | Experimental Use | +-------------------+------------------------------------+ 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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 [APNIC-EH] Huston, G., "IPv6 extension headers revisited", October 2022, . [I-D.herbert-eh-inflight-removal] Herbert, T., "Infight Removal of IPv6 Hop-by-Hop and Routing Headers", Work in Progress, Internet-Draft, draft- herbert-eh-inflight-removal-01, 2 October 2023, . Herbert Expires 9 April 2024 [Page 22] Internet-Draft FAST October 2023 [I-D.herbert-host2netsig] Herbert, T., "Host to Network Signaling", Work in Progress, Internet-Draft, draft-herbert-host2netsig-00, 4 October 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-07, 27 September 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-10, 26 September 2023, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [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, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [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, . Author's Address Herbert Expires 9 April 2024 [Page 23] Internet-Draft FAST October 2023 Tom Herbert SiPanda Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 9 April 2024 [Page 24]