Internet DRAFT - draft-herbert-fast
draft-herbert-fast
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,
<https://www.rfc-editor.org/info/rfc2119>.
[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
[APNIC-EH] Huston, G., "IPv6 extension headers revisited", October
2022, <https://blog.apnic.net/2022/10/13/ipv6-extension-
headers-revisited>.
[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,
<https://datatracker.ietf.org/doc/html/draft-herbert-eh-
inflight-removal-01>.
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, <https://datatracker.ietf.org/doc/html/
draft-herbert-host2netsig-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-07, 27 September 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
limits-07>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-6man-
hbh-processing-10>.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc7872>.
[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>.
[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>.
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]
