Network Working Group T. Herbert
Internet-Draft SiPanda
Intended status: Standards Track 1 August 2023
Expires: 2 February 2024
Firewall and Service Tickets (FAST)
draft-herbert-fast-05
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 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 2 February 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Herbert Expires 2 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 . . . . . . . . . . . . . . . 18
3.2. Packet format . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1. Option format . . . . . . . . . . . . . . . . . . . . 20
3.2.2. Ticket format . . . . . . . . . . . . . . . . . . . . 21
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 2 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 . . . . . . . . . . . . . . . . . 25
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 . . . . . . . 28
5. Implementation considerations . . . . . . . . . . . . . . . . 29
5.1. Application support . . . . . . . . . . . . . . . . . . . 29
5.2. Ticket reflection . . . . . . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . 31
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 2 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 a 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 2 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 smart phones, 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 2 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 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 2 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 a 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
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 2 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 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 2 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 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 wich 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 2 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 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 2 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 2 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 2 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 2 February 2024 [Page 13]
Internet-Draft FAST August 2023
suggest, limited domains are not relegated to be small insignificant
networks, and in fact could be comprised of quite 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 communications. 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 2 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 2 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.
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.
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 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 possible solution.
Herbert Expires 2 February 2024 [Page 16]
Internet-Draft FAST August 2023
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
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 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.
Herbert Expires 2 February 2024 [Page 17]
Internet-Draft FAST August 2023
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.
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.
Herbert Expires 2 February 2024 [Page 18]
Internet-Draft FAST August 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
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.
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.
Herbert Expires 2 February 2024 [Page 19]
Internet-Draft FAST August 2023
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.
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires 2 February 2024 [Page 20]
Internet-Draft FAST August 2023
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
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.
Herbert Expires 2 February 2024 [Page 21]
Internet-Draft FAST August 2023
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 application or host that is 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).
A simple ticket containing a thirty-two bit Service Protocol Index
with an expiration time might be:
Herbert Expires 2 February 2024 [Page 22]
Internet-Draft FAST August 2023
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
3. Non-reflected tickets that not processed in the forward path, but
are reflected
4. Reflected tickets
Herbert Expires 2 February 2024 [Page 23]
Internet-Draft FAST August 2023
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.
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.
Herbert Expires 2 February 2024 [Page 24]
Internet-Draft FAST August 2023
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 packets in as a Hop-by-Hop option. 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.
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
Herbert Expires 2 February 2024 [Page 25]
Internet-Draft FAST August 2023
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 wth 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.
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
Herbert Expires 2 February 2024 [Page 26]
Internet-Draft FAST August 2023
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.
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.
Herbert Expires 2 February 2024 [Page 27]
Internet-Draft FAST August 2023
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.
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.
Herbert Expires 2 February 2024 [Page 28]
Internet-Draft FAST August 2023
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 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.
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.
Herbert Expires 2 February 2024 [Page 29]
Internet-Draft FAST August 2023
Happy Eyeballs for extension headers or simple probing could be
implemented in the networking stack for a connection oriented
transport protocol such a 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 nontransferable. 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.
7. IANA Considerations
IANA is requested to assigned the following Hop-By-Hop option:
Herbert Expires 2 February 2024 [Page 30]
Internet-Draft FAST August 2023
+-----------+---------------+-------------+---------------+
| 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
8.1. Normative References
Herbert Expires 2 February 2024 [Page 31]
Internet-Draft FAST August 2023
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
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,
<https://datatracker.ietf.org/doc/html/draft-cc-v6ops-
wlcg-flow-label-marking-02>.
[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, <https://datatracker.ietf.org/doc/html/draft-
elkins-v6ops-eh-deepdive-cloud-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-
herbert-ipv4-eh-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-04>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-09>.
[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, <https://datatracker.ietf.org/doc/html/draft-
ietf-tsvwg-udp-options-22>.
Herbert Expires 2 February 2024 [Page 32]
Internet-Draft FAST August 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, <https://datatracker.ietf.org/doc/html/draft-
ioametal-ippm-6man-ioam-ipv6-options-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-
kaippallimalil-tsvwg-media-hdr-wireless-02>.
[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,
<https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-
explcit-signal-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-yiakoumis-
network-tokens-02>.
[PLUS] Tramell, B. and M. Kuehlewind, "Path Layer UDP Substrate
Specification", December 2016,
<https://datatracker.ietf.org/doc/draft-trammell-plus-
spec/00/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
Herbert Expires 2 February 2024 [Page 33]
Internet-Draft FAST August 2023
[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
August 2015, <https://www.rfc-editor.org/info/rfc7605>.
[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, <httpss://www.rfc-
editor.org/info/rfc7872>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet
Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
<https://www.rfc-editor.org/info/rfc8799>.
[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, <https://www.rfc-editor.org/info/rfc8837>.
[RFC8883] Herbert, T., "ICMPv6 Errors for Discarding Packets Due to
Processing Limits", RFC 8883, DOI 10.17487/RFC8883,
September 2020, <httpss://www.rfc-editor.org/info/
rfc8883>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[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, <https://www.rfc-editor.org/info/rfc9098>.
Herbert Expires 2 February 2024 [Page 34]
Internet-Draft FAST August 2023
[TLSCERT] "Alert (TA17-075A), HTTPS Interception Weakens TLS
Security", March 2017, <https://www.cisa.gov/news-
events/alerts/2017/03/16/https-interception-weakens-tls-
security>.
[_3GPP-5G] "5G; System Architecture for the 5G System", September
2018, <https://www.etsi.org/deliver/
etsi_ts/123500_123599/123501/15.03.00_60/
ts_123501v150300p.pdf>.
Author's Address
Tom Herbert
SiPanda
Santa Clara, CA,
United States of America
Email: tom@herbertland.com
Herbert Expires 2 February 2024 [Page 35]