Firewall and Service Tickets (FAST)

Enabling applications and the network to work together to benefit users

Tom Herbert, November 9, 2024

Emerging network architectures and technologies offer a rich array of network services that could greatly benefit end users. In practice, realizing these benefits has proven difficult. The problem is a lack of secure coordination between applications and network infrastructure to provide end-to-end services. Firewall and Service Tickets (FAST) is a solution that facilitates coordination among the various players in communications.

FAST fundamentals

The basic idea of FAST is that applications signal the network for the services they want applied to packets. This is a form of Host-to-Network signaling where applications running on end hosts attach signals to packets that are interpreted by network nodes in the communication path. Host-to-Network signaling can be contrasted with Network-to-Host signaling where network nodes insert signals into packets infight to inform end hosts of network conditions like router congestion. While the mechanisms for carrying signals are similar, the higher level communication and security models of the two are very different-- so today we're just talking 'bout Host-to-Network signaling.

The fundamental element of FAST is a ticket. The word "ticket" is not accidental, there are a lot of parallels between FAST tickets and tickets in the real world, say like those needed to attend a Taylor Swift concert. FAST tickets allow admission into the network and specify requested services to be applied to packets. This is analogous to a concert ticket that grants admission into the venue and specifies the assigned seat (i.e. the requested service). Just like concert tickets, FAST tickets need to prevent forgery, be non-transferable, be authenticated, and may only be valid for a certain time.

To purchase a concert ticket we typically go through a ticket agent-- FAST works the same way. A host makes a ticket request to a FAST ticket agent that describes the desired services for some communication. Ticket requests are not in the critical data path, so an expressive interface like REST/XML may be used to request services with granularity; for instance, the example below shows a ticket request for video chat with specific requirements for frame rate, resolution, and delay. If the ticket agent can accommodate the request then it "prints" a FAST ticket and returns it to the requestor. The receiving application just attaches the ticket to packets of the associated communication without any further processing.

When a packet is sent with an attached ticket, nodes in the network interpret the ticket to allow admission and apply requested services. In many cases, only the first hop node needs to interpret the ticket-- this is where the grant of admission can be checked and any requested services can be mapped to lower layer network functions like 5G slices or network service chains. Interpreting the ticket involves decrypting it, authenticating it, determining if the source is authorized to use the ticket, and applying the requested services.

When fine grained services are applied to packets this is usually done the edge networks and not so much in core transit networks on the Internet. So we can conceptualize two domains where FAST services might be applied: the origin network and the destination network. This is modeled as a so-called dumbbell topology as shown in the diagram below (the source and destination of a packet might reside in the same network). Fast tickets are not global and are only interpretable in the network domain in which they originated. Tickets are encrypted or obfuscated such that they can only be deciphered, authenticated, and validated by network nodes in the domain that the ticket was issued. To the rest of the world, including the requesting host, a ticket is just an opaque set of bytes-- this establishes a clear security domain for FAST tickets and effectively is a zero trust security model!

For bidirectional communications, an application may want services to be applied to packets in both the "forward direction" (packets sent by the host) and "return direction" (packets sent by the peer host to the originating host). In order to have services applied on packets in the return direction, a source can request that the peer host reflects a sent forward ticket in the return path. That is when the remote peer sends a reply packet back to the source host, it copies the ticket received on the forward path into packets and marks the ticket as being reflected. When a packet with a reflected ticket is received at an ingress router of the origin network, the ticket is interpreted and appropriate services are applied.

Example 1: FAST and video chat

As an example of FAST, consider a user doing a video chat from their smartphone. Referring to the diagram below, a video chat application starts by requesting a ticket from a ticket agent in the local network (step a.). The ticket request indicates desired characteristics like expected latency, jitter requirements, or video frame rate. The ticket agent returns a ticket (step b.) and the ticket is then attached to packets sent for the video chat (step 1). In this example, the first hop router interprets tickets (step 2) and forwards packets in a “network slice” that provides the requested QoS. Packets traverse the local network with the requested services applied (step 3). If packets exit the local network into the Internet then the services are no longer applied, but the tickets remain attached to packets. At the peer server, received tickets are saved in the connection context and are subsequently reflected in reply packets sent back to the user (step 4). When reply packets enter the user’s local network, an ingress router processes the reflected tickets (step 5), and forwards packets in a network slice that provides the requested QoS (step 6). The reply packets traverse the local network with the services applied (step 7). When the original host receives reply packets, it simply ignores the reflected tickets (step 8).

Example 2: FAST and DTN

Delay-tolerant Networking, or DTN, is designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like service across interplanetary distances in support of deep space exploration. Because of the distances involved, conventional Internet approaches are either unworkable or impractical. One technique that doesn’t work so well with DTN is Quality of Service (QoS). The communications path with DTN consists of terrestrial, near earth, and deep space segments. These segments create a very heterogeneous path, and the service characteristics of these segments can be wildly different so the current one-size-fits-all approach of Internet protocols for network QoS doesn’t work very well. In particular, a few TOS bits in the IP header isn’t expressive enough to leverage QoS in end-to-end communications in DTN.

FAST can be productively used with DTN. An example of DTN with FAST is shown in the picture below. This picture depicts the use of FAST in an internetwork composed of a terrestrial Earth network, near earth spacecraft, and a Mars terrestrial network. At each segment, FAST tickets are interpreted to provide the best service for traversing that segment. In this example, the FAST ticket is interpreted by multiple hops, and at each hop information from the ticket to optimize communications for that hop.

Protocol and implementation details

As we mentioned, FAST is a form of Host-toNetwork signaling where information is encoded in each packet and the encoded information is interpreted by routers. In any form of signaling there is the signal carrier and the signal content. We already touched on the tickets as the signal content which are just a block of bytes-- since tickets are used in the critical path it's good to keep them small and concise. As for the signal carrier, we are proposing that tickets be carried in IPv6 Extension Headers with a basic format as illustrated below. While Extension Headers have some reachability issues on the Internet, compared to the alternatives they are by far the least problematic and really the only extensible method for per packet host to network signaling. We are actively working with IETF to address the reachability issues. It should also be noted that Extension Headers are currently only defined for IPv6 (IP Options are the analogous method for IPv4, but that “ship has sailed” for IPv4 Options ever being usable); part of our solution is would enable Extension Headers to work with IPv4.

Summing it all up

Firewall And Service Tickets is a so called win-win-win proposition: 1) application developers can leverage high throughput and low latency communications needed to enable new classes of applications in for virtual reality or AI/ML, 2) network providers can get return on investments in infrastructure investment and provide value through service differentiation, 3) and most importantly, users benefit from an ever improving Quality of Experience! For more detail on Firewall And Service Tickets take a look at the Internet Draft.