Network Working Group T. Herbert
Internet-Draft SiPanda
Intended status: Informational 4 October 2023
Expires: 6 April 2024
Host to Network Signaling
draft-herbert-host2netsig-00
Abstract
This document discusses the motivations, use cases, and requirements
for Host to Network Signaling. In Host to Network Signaling, hosts
annotate packets with information that is intended for consumption by
on-path elements. Signals may be used to request services on a per
packet basis from on-path elements, to request admission into the
network, or to provide diagnostics and tracing information.
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 6 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Herbert Expires 6 April 2024 [Page 1]
Internet-Draft host2netsig October 2023
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Network services in dumbbell network topologies . . . . . 4
2.2. Requesting network services . . . . . . . . . . . . . . . 5
2.3. Network services . . . . . . . . . . . . . . . . . . . . 6
2.4. Filling the gap of Transport Path Signals . . . . . . . . 7
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Mapping to network slices . . . . . . . . . . . . . . . . 8
3.2. Host to network signaling in wireless networks . . . . . 8
3.3. Explicit signals . . . . . . . . . . . . . . . . . . . . 8
3.4. Traffic flow analysis . . . . . . . . . . . . . . . . . . 9
3.5. Routing hints . . . . . . . . . . . . . . . . . . . . . . 9
4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 9
4.1. Stateful firewalls and proxies . . . . . . . . . . . . . 9
4.1.1. Problems with transport stateful network devices . . 10
4.1.2. Problems with application layer firewalls . . . . . . 11
4.2. Differentiated services . . . . . . . . . . . . . . . . . 12
4.3. Deep packet inspection . . . . . . . . . . . . . . . . . 12
5. Proposals for host to network signaling . . . . . . . . . . . 12
5.1. Embedded information in UDP encapsulation . . . . . . . . 12
5.2. UDP Options . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Overloading the IPv6 Flow Label . . . . . . . . . . . . . 14
5.4. Overloading bits in IPv6 addresses . . . . . . . . . . . 15
5.5. Stateful mechanisms . . . . . . . . . . . . . . . . . . . 16
5.6. Destination Options . . . . . . . . . . . . . . . . . . . 16
5.7. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 17
5.7.1. Processing requirements of Hop-by-Hop Options . . . . 18
5.7.2. Support in IPv4 . . . . . . . . . . . . . . . . . . . 19
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Host to Network Signaling allows end hosts or applications to signal
the on-path elements, or network nodes in the path, for requests for
service or admission into a network on a per packet basis. The
signal is expressed as ancillary information attached to packets.
Herbert Expires 6 April 2024 [Page 2]
Internet-Draft host2netsig October 2023
Host to Network Signals are explicit signals conveyed in the network
layer for the purpose of being processed and consumed by some or all
network nodes in the path. Host to network signaling can be
contrasted with Transport Path Signals as discussed in [RFC8558].
The primary difference is that Host to Network Signaling employs
explicit signals carried in the network layer, and, unlike Transport
Path Signals, these signals may be independent of the transport layer
and do not require on-path elements to parse transport layer headers
or track transport layer state in the network.
Host to network signals are sent by hosts to network nodes. The
converse of host to network signaling is "network to host signaling"
where network nodes modify ancillary information in packets to signal
the destination host. The purpose of network to host signaling is to
report information on a per packet basis that is consumed by the
destination host; an example of a network to host signaling protocol
is IOAM. Host to network signaling and network to host signaling
have different characteristics in the nature of the signals,
modifiabilty of the data, and security. Network to host signaling is
a separate topic in its own right and is considered out of scope for
this document.
A host to network signal may be scoped such that only particular on-
path nodes process and act on the signal. The scope can be enforced
by encrypting the signal such that only authorized network nodes are
able to decode the signal. This also serves as a security mechanism
to limit the exposure of data in the signal and to minimize the plain
text sent in a packet. The scope can even exclude the source host
from being able to decode the signal such that it must treat that
signal data as an opaque object provided by a local network agent to
be attached to packets. Host to network signals may 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
signal data is non-transferable between hosts or users.
Host to network signals may include an expiration time to such that
they are only useful for some period of time. For instance, if a
host to network signal is attached to the packets of a flow for the
purpose of requesting network services, an associated expiration time
would allow the infrastructure to limit the use of the signal for a
certain period of time and prevent unlimited reuse of the signal.
While host to network signals do not directly covey connection state,
such as connection establishment and tear down, they may still be
associated with a transport layer flow. For instance, when a host
creates first creates a flow it may be provided with signal by a
network agent to attach to packets of a flow. The signal data
Herbert Expires 6 April 2024 [Page 3]
Internet-Draft host2netsig October 2023
describes the services being requested for the flow. When an on-path
element processes the signal, it applies the services on the basis of
the signal contents without regard to transport layer state.
An important attribute of host to network signals is that they are
stateless inside the network. In particular, this facilitates multi-
homing where routers in different paths for a flow would be able to
decode and process host to network signals in packets associated with
a flow.
Host to network signals are inherently uni-directional. In order for
a source to affect services on the return path of a flow, "signal
reflection" may be employed. The idea is that a signal can be sent
with a "reflect" attribute. At a peer host, the signal can be
reflected in reply packets to affect services for packets in the
return path.
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
This section discusses the motivation for a consistent and ubiquitous
solution for host to network signaling.
2.1. Network services in dumbbell network topologies
End to end communications can often be modeled as a "dumbbell"
topology where two communicating end hosts connect to the Internet
via a local provider network and the provider networks connect to
transit networks to communicate across the Internet.
_____
__________ ( ) __________
+--------+ ( ) ( ) ( ) +--------+
| User 1 +---( Provider A )--( Transit )--( Provider B )---+ User 2 |
+--------+ (__________) ( ) (__________) +--------+
(_____)
Figure 1
Within each provider network of the dumbbell topology, network
services may be provided on behalf of the users of the local network.
In the figure above, Provider A may provide services and service
agreements for users in its network including User 1; and likewise,
Herbert Expires 6 April 2024 [Page 4]
Internet-Draft host2netsig October 2023
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, that is transit
networks may be considered the "open Internet". Services provided by
different provider networks may be very different and dependent on
the implementation of the network as well as the local policies of
the provider.
2.2. Requesting network services
Based on the dumbbell network topology, services and service
differentiation can be considered local to each network provider.
Host to network signaling is a mechanism whereby each user and
application can request from its local provider the services to be
applied to its traffic. The data of the signal may be provided by an
agent in the local provider network. The contents of the signal
describe the services that the application desires. When a packet is
sent by an application with a host to network signal attached, the
signal is interpreted in the provider network to allow the packet to
traverse the network and to map the packet to the appropriate
services. In this model, the host to network signal is only relevant
in its origin domain, that is the provider network or limited domain
[RFC8799] in which the network signal was issued. Outside of the
origin domain, network signals are uninterpretable opaque objects;
encryption of the signal data can be employed to limit exposure of
the signal's contents. An outcome of this design is that there is no
requirement for a standard set of signals that all networks must
support; signals can be defined in each provider network per their
needs and the network services they offer. While the signal content
may differ between networks, the protocol to carry and request
signals should be common and ubiquitous.
While the signals themselves are intended to be extensible and not
limited to a few predefined possibilities, there is also a motivation
to use a namespace to tag different signals with a global value.
This is especially useful to avoid name conflicts when two networks
share each other's signals. An IANA registry could be employed to
allow different vendors or entities to request a portion of the
common namespace to define their signals.
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 a host to network signal without
modification or interpretation. When a packet with a reflected
signal enters the origin network of the signal, network nodes can
interpret the signal and apply appropriate services for transitting
the network to the destination host.
Herbert Expires 6 April 2024 [Page 5]
Internet-Draft host2netsig October 2023
The use of host to network signals may be bilateral for a flow so
that each peer requests service from its local network. Therefore
packets may contain two types of signals: one that is set by the
source host to signal its local provider network, and the other is a
reflected signal relevant to the provider network of the destination
host.
Signals are scoped values in that they only have meaning in their
origin domain in which a signal was issued. The format, meaning, and
interpretation of host to network signals is specific to the origin
domain. By mutual agreement, two or more networks or limited domains
may share the policy and interpretations of network signals thereby
logically extending the origin domain of the signals. For instance,
there could be an agreement between two provider networks to
interpret each other's signals or to use a common signal format.
2.3. Network services
There are a number of potential use cases for requesting network
services that motivate host to network signaling. As an example,
consider the common problem of applications on mobile devices that
need to signal their provider network for services.
In a typical client/server model of serving content, end host clients
communicate with servers on the Internet. Clients are typically user
devices that are connected to the Internet through a provider
network. In the case of mobile devices, such as smartphones, the
devices are connected to the Internet through a mobile provider
network (RAN). 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.
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, for example streaming an HD movie might need high throughput
but not particularly low latency; on the other hand, a live video
chat might have lower throughput demands but could have stringent low
latency requirements.
Note that network services requested by applications are relevant to
both packets sent by an end host and those sent from a peer towards
the end host. For the latter case, the network needs to be able to
map packets sent from hosts on external networks or on the Internet
to the services requested by the receiving application.
Herbert Expires 6 April 2024 [Page 6]
Internet-Draft host2netsig October 2023
Host to network signaling is applicable to the mobile network use
case. The application running in the User Equipment (UE) would
request signals for services from an agent in their local provider.
When packets are sent by the UE into the RAN the signal is attached
data. The first hop router could first validate the signal and then
apply the requested services by mapping the packet into the internal
mechanisms of the network that provide differentiated service
(network slicing, SFC, DSCP, etc.). Reflected signals 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 signal
by mapping them to the internal mechanisms for differentiated
services of the network for forwarding to the UE.
2.4. Filling the gap of Transport Path Signals
[RFC8558] discusses the nature of signals seen by on-path elements
examining transport protocols, and [RFC9419] discusses principles for
designing mechanisms that use or provide path signals. [RFC8558]
differentiates implicit and explicit signals. Implicit signals are
those that are inferred from the transport layer, and explicit
signals are data set in packets with the explicit purpose of
signaling network nodes in the path. [RFC8558] notes the trend
towards encrypting more layers of the packet which reduces the
effectiveness of implicit signals and acknowledges that "The
transport messages were not necessarily intended for consumption by
on-path network elements".
To fill the gap created by encryption of transport layer headers and
reduced visibility to network nodes, [RFC8558] suggests that implicit
signals inferred from transport layer headers could replaced by
explicit Network-Layer Signals, which is equivalent to host to
network signals.
[RFC8558] makes several recommendations that are applicable to host
to network signaling. Information should only be exposed to the
network if the sender intends for the data to be consumed by network
elements on the path. The signals should be independent of any
protocol state machine at the endpoints. Signal data should be
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.
3. Use cases
This section presents some use cases for host to network signaling.
Herbert Expires 6 April 2024 [Page 7]
Internet-Draft host2netsig October 2023
3.1. Mapping to network slices
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 request 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.
Host to network signals offer a generic and common protocol to allow
applications in UEs to signal the RAN for services.
3.2. Host to network signaling in wireless networks
[I-D.kaippallimalil-tsvwg-media-hdr-wireless] describes a mechanism
to annotate packets with metadata that is attached to packets to
classify packets in wireless networks in order to provide appropriate
QoS. The method is particularly motivated by use cases where fully
encrypted media streams are used or the transport layer flow
information is encrypted or obscured.
The metadata is intended to be processed and consumed by a specific
intermediate node, the Wireless Node. The metadata is a type of host
to network signal, so a common host to network signaling solution
should be applicable.
3.3. Explicit signals
[I-D.reddy-tsvwg-explcit-signal] defines a mechanism for endpoints to
explicitly signal encrypted metadata to the network, and the network
to signal its ability to accommodate that metadata back to the
endpoints. This mechanism can be used where the endpoints desire
that some network elements along the path receive these explicit
signals.
The "explicit signals" described in this draft are a potential use
case of host to network signaling.
Herbert Expires 6 April 2024 [Page 8]
Internet-Draft host2netsig October 2023
3.4. Traffic flow analysis
[I-D.cc-v6ops-wlcg-flow-label-marking] describes a mechanism to mark
packets of flows with information that identifies the application or
user that is sending packets. The information is consumed by network
nodes to perform analysis on how packets for various applications are
flowing through a network.
This draft uses the IPv6 flow label to convey the information to
identify applications. This is a non-standard use of the flow label
and the amount of information that the flow label can carry is quite
limited (the flow label is alternative). A common host to network
signaling solution offers an alternative that would be generic,
extensible and standardizable.
3.5. Routing hints
Host to network signals could be used to indicate routing "hints" to
the network. For instance, a signal might be used to request
services for QoS and the signal might be interpreted by routers when
choosing the right path to provide those services.
It should be noted that host to network signals don't supplant or
replace packet routing. Packets must be deliverable to their
destination solely based on the IP addresses of the packet and a
Routing header if one is present (a Routing header could be
considered a specialized host to network signal). A host to network
signal may be used to affect routing as an optimization.
4. Existing mechanisms
This section surveys some of the current solutions for packet
admission control and requesting networking services. These
solutions tend to generally be ad hoc or architecturally limiting.
4.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
have a number of problems that have had adverse effects.
Herbert Expires 6 April 2024 [Page 9]
Internet-Draft host2netsig October 2023
4.1.1. Problems with transport stateful network devices
On-path network nodes that maintain transport flow state, such as
firewall and NAT devices, have proven problematic. These devices
break the End-to-End model that has resulted in several detrimental
effects:
* Stateful devices in the network break multi-homing and multi-path.
For instance, when a firewall performs TCP connection tracking,
all packets of the flow in both directions must traverse the
device that has established state. In a multi-homed or multi-path
deployment, if a packet traverses a different firewall device than
the one in which the flow state was established, the result can be
that the connection is broken.
* Stateful devices can be an anonymous single points of failure in
the network path. For instance, stateful devices can break
individual connections mid-flow due to state eviction. Since the
memory for state is a finite resource, stateful network devices
implement eviction policies to prevent resource exhaustion. A
common method is to evict a state once the connection goes idle
for some period of time. To prevent state eviction, an end host
may send keepalives at periodic intervals to make it appear that a
connection isn't idle. A host has no way to determine the idle
timeout of anonymous stateful devices in the path, so it has to
make a guess as the proper frequency of keepalives. Often this
results in packets being sent on the network solely to keep
connections alive and otherwise carry no useful information.
* Stateful devices only work for a narrow set of specific transport
protocols headers that are supported by the device implementation.
As evident by the experience with QUIC deployment, enabling
stateful firewalls for a new transport protocol is a major
undertaking that would likely only be successful if pushed by a
very large player (i.e. QUIC was pushed by Google).
* Stateful devices can only work when the necessary transport layer
headers are parsable and not "too deep" in the packet. For
instance, the TCP headers in an IPsec transport mode packet for
TCP wouldn't be visible to intermediate devices so a stateful
firewall may block such packets. Even if the transport layer
header is in plain text, it may be too deep in the packet such
that an intermediate node is unable to parse the headers; this is
discussed in [I-D.ietf-6man-eh-limits].
Herbert Expires 6 April 2024 [Page 10]
Internet-Draft host2netsig October 2023
* Stateful devices have ossified transport layer protocols.
Transport protocols were originally intended to be End-to-End, and
protocols such as TCP allow negotiation of options between the end
points for extensibility. When a stateful device is in the path,
it is a silent and anonymous, but potentially invasive,
participant in the transport layer protocol. Even if the
endpoints negotiate a options, it might be unacceptable to the
intermediate node which may result in a dropped connection.
* Transport protocols that are encapsulated in UDP, such as QUIC,
have risk of misinterpretation since port numbers are not standard
protocol numbers. Per [RFC7605] "Port numbers are sometimes used
by intermediate devices on a network path,... It is important to
recognize that any interpretation of port numbers -- except at the
endpoints -- may be incorrect". The upshot of this is that an
intermediate node that is parsing an UDP encapsulated protocol
must assume that the interpretation could be incorrect result in
incorrect processing of packets.
4.1.2. Problems with application layer firewalls
Application layer firewalls parse application layers in packets for
the purposes of filtering and classification for services. For
instance, an application layer firewall might parse an HTTP request
to perform virus scanning or fine grained service classification.
Application layer firewalls are typically stateful devices so they
suffer from the same problems as described for transport stateful
devices. Furthermore, they depend on being able to parse transport
layer payloads containing application layer protocols such as HTTP in
TCP. For instance, HTTP is commonly parsed to determine URL, content
type, and other application level information that the network is
interested in for providing services. Application protocol parsing
can only be effective with the specific application layer protocols
that a device is programmed to parse. More importantly, application
layer protocol parsing is essentially 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 on behalf of users, is effectively a man-in-
the-middle attack and is considered a security vulnerability
[TLSCERT].
Herbert Expires 6 April 2024 [Page 11]
Internet-Draft host2netsig October 2023
4.2. Differentiated services
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.
4.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. Recently, there is a drive to encrypt as much of
the packet as possible including the transport layer. For instance,
this is the approach espoused by QUIC [RFC9000]: "QUIC authenticates
the entirety of each packet and encrypts as much of each packet as is
practical."
The drive to encrypt as much of a packet as possible has
substantially reduced the network's visibility into packets. This is
a prudent security philosophy, however it does reduce the utility of
devices that were previously processing transport layer headers and
application payloads to benefit the users-- for providing QoS as well
as firewalls.
Host to network signaling is a means to maintain the value these
devices without creating dependencies on transport layer protocols
and still maintaining strong security. The application of host to
network signaling is discussed below.
5. Proposals for host to network signaling
This section surveys some proposals to address the need for
applications to signal the network.
5.1. Embedded information in UDP encapsulation
There have been various proposals to embed host to network signals in
the payload of UDP encapsulation, sometimes this technique
colloquially refers to UDP as "the new network layer". [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
Herbert Expires 6 April 2024 [Page 12]
Internet-Draft host2netsig October 2023
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 a predominant
transport protocol on the Internet.
* Unless a UDP protocol is natively designed to include the embedded
information, a shim header is required between the IP header and
real transport layer header. As demonstrated by QUIC [RFC9000],
the trend in transport protocols is to encrypt as much of the
packet as possible including the transport layer headers; it seems
likely that few new 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
security liability for those transport protocols that
intentionally hide transport layer protocols and state. For
example, QUIC [RFC9000] espouses the design principle to encrypt
as much of the packet as possible including the transport layer.
An external protocol that exposes information about QUIC transport
state would be inconsistent with that design principle and likely
considered a security risk.
Herbert Expires 6 April 2024 [Page 13]
Internet-Draft host2netsig October 2023
5.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] and
[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 protocols
requires encapsulation and applications need to change. In
particular, this is incompatible with TCP which is a predominant
transport protocol on the Internet.
* UDP Options are in protocol trailers of packets which makes it
difficult to implement processing efficiently. This is especially
true for hardware implementations that are common in high
performance routers for which it may be infeasible to even support
processing of protocol trailers.
* UDP Options are specified as transport layer options, whereas
network signals are more aptly described as network layer options.
Mixing the two together creates problems. For instance, an
intermediate node would only be interested in processing network
options and would ignore transport options. Searching in a list
of TLVs containing both transport and network options may be
expensive especially in a hardware datapath (skipping over TLVs
being ignored is not zero cost processing).
5.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.
The drawbacks of this approach are:
* The flow label is only twenty bits, and if some bits are reserved
to retain flow entropy then the effective number of bits available
Herbert Expires 6 April 2024 [Page 14]
Internet-Draft host2netsig October 2023
for signaling may be less; for example,
[I-D.cc-v6ops-wlcg-flow-label-marking] uses sixteen bits of the
flow label for signaling). In any case, the amount of information
the flow label could carry is quite limited.
* IPv4 does not have a flow label.
* There is no codepoint to indicate that a flow label is formatted
in a certain way. This could lead to misinterpretation of the
flow label as intermediate nodes.
* The use may reduce flow entropy in the flow label thereby
adversely affecting ECMP routing.
* The flow label is expected to be unchanged for the duration of a
flow so there is no means to change service parameters mid-flow or
per packet.
5.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 IPv6 address could be used to convey
the signal, intermediate devices would then interpret these bits as
host to 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.
Herbert Expires 6 April 2024 [Page 15]
Internet-Draft host2netsig October 2023
* 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.
* This changes IPv6 addressing policies including re-numbering
policies, and will likely require changes to IPv6 host stacks.
5.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 stateful devices 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.
5.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:
Herbert Expires 6 April 2024 [Page 16]
Internet-Draft host2netsig October 2023
* 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.
* The Destination Options header may follow a variable length Hop-
by-Hop Options thereby requiring deeper parsing of packets. The
Hop-by-Hop Options header MUST immediately follow the IPv6 header
if present and is always at a fixed offset in the packet (at a
forty byte offset relative to the start of the IPv6 header),
however the Destination Options header may follow other extension
headers and is at a variable offset in packets.
5.7. 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, and they
immediately follow the IPv6 header at a fixed offset in the packet.
The drawbacks of Hop-by-Hop Options are:
* The original processing requirements of IPv6 [RFC2460] impeded
deployment of Hop-by-Hop Options in that all routers in the path
were required to process Hop-by-Hop options.
* Packets containing Hop-by-Hop Options headers may be summarily
discarded by some network providers as a matter of policy
[RFC7872],[RFC9098].
* They are IPv6 specific, there is no equivalent support in IPv4.
The sections below present some mitigations and solutions for these
drawbacks.
Herbert Expires 6 April 2024 [Page 17]
Internet-Draft host2netsig October 2023
5.7.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, others 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
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.
* [I-D.herbert-eh-inflight-removal] describes a protocol to remove
Herbert Expires 6 April 2024 [Page 18]
Internet-Draft host2netsig October 2023
Hop-by-Hop Options headers from packets in flight. This could be
applied in host to network signaling by arranging that the last
router that processes a signal 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 signal isn't relevant to the
downstream routers.
5.7.2. Support in IPv4
A new IPv4 option could be defined for host to network signaling.
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, 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.
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 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.
6. Requirements
The requirements for host to network signaling are:
* A common and standard carrier of host to network signals MUST be
defined. A carrier is a protocol that encapsulates signal data
sent by host or applications and that is processed by network
nodes. The carrier should be extensible, generic, and formatted
to be efficiently processed by network nodes.
* The content of host to network signals MUST have an extensible
format to allow arbitrary services to be requested. The format of
the data SHOULD be concise to minimize the on-the-wire overhead of
a signal.
Herbert Expires 6 April 2024 [Page 19]
Internet-Draft host2netsig October 2023
* Host to network signals MUST be transport protocol agnostic and
usable with any transport protocol including TCP, UDP, IPsec, and
various forms of network tunneling. Host to network signals MUST
be conveyed in network layer headers.
* Host to network signaling MUST be stateless within the network.
In particular intermediate nodes MUST NOT be required to create
and maintain state for transport layer connections.
* Host to network signaling MUST work in a multi-homed and multi-
path environments. For instance, if two packets are sent for a
flow that are annotated with the same host to network signal, the
signal MUST be properly processed even if there are no common on-
path nodes for the two packets.
* A host to network signal MUST be appropriately encrypted or
obfuscated such that to a node not participating in network
signaling the signal is opaque data.
* Host to network signals MUST NOT be mutable.
* If host to network signals are encrypted then there SHOULD be
protocol defined for performing key distribution among those nodes
that perform decryption in the network.
* Host to network signal SHOULD provide a clear API for applications
to minimize the changes to an application. Their use should be an
"add-on" to the existing communications of an application.
* Host to network signaling MUST deter spoofing and other misuse
that might result in unauthorized use of network services or
denial of service attack.
* Host to network signaling SHOULD 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).
Herbert Expires 6 April 2024 [Page 20]
Internet-Draft host2netsig October 2023
* Host to network signals SHOULD employ a IANA managed namespace to
allow different parties to create their own signals without risk
of conflicting with others.
* Host to network signaling SHOULD provide mechanisms or protocols
by which a host or application can request host to network signals
from an agent in its local network. A request can specify the
parameters of services being requested, and the response to a
request is the signal data encapsulating the granted services.
The provided signal data is carried in a host to network signal
that is attached to packets sent by the host or application to be
processed with the requested services. The request protocol MAY
employ protocols such as XML and REST.
* Host to network signals MAY be removed from packets. In some use
case scenarios the host to network signal in packets would only be
processed by one node in the network. For instance, a mobile
device might attach a signal in packets that is only processed by
the first hop router in the RAN. The first hop router maps the
signal to mechanisms in the network fabric to provide the
services, and any downstream routers for the packet don't need to
process the signal. To limit visibility and maximize
compatibility with the downstream routers, the last router that
processes a host to network signal MAY remove the signal from the
packet. If the signal is in a Hop-by-Hop Option then removal of
the data could be accomplished by removing the Hop-by-Hop Header
[I-D.herbert-eh-inflight-removal].
7. Security Considerations
There are three main security considerations:
* Leakage of content specific information to untrusted third parties
must be avoided.
* Host to network signals cannot be forged, illegitimately used, or
otherwise abused.
* The presence or processing of host to network signals cannot lead
to Denial of Service attacks.
Herbert Expires 6 April 2024 [Page 21]
Internet-Draft host2netsig October 2023
Network to host may be exposed to third parties on the Internet
including untrusted and unknown networks in the path of packets.
Therefore, signals should be encrypted or obfuscated by the origin
network.
Host to network signals can have an expiration time, must be
resistant to forgery, and must be non transferable. A host to
network signal should be valid for the specific source and
destination addresses that it was issued for. Signals could
revocable by implementing a banned-list of revoked host to network
signals.
If a network supports host to network signaling, it should manage
resources to avoid Denial of Service for processing signals. Various
techniques to minimize the processing cost and properly provision the
network to handle worst case load should be considered.
8. IANA Considerations
9. References
9.1. Normative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
9.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.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 6 April 2024 [Page 22]
Internet-Draft host2netsig October 2023
[I-D.herbert-ipv4-eh]
Herbert, T., "IPv4 Extension Headers and Flow Label", Work
in Progress, Internet-Draft, draft-herbert-ipv4-eh-01, 2
May 2019, <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>.
[I-D.ietf-tsvwg-udp-options]
Touch, J. D., "Transport Options for UDP", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-23,
15 September 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-udp-options-23>.
[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>.
Herbert Expires 6 April 2024 [Page 23]
Internet-Draft host2netsig October 2023
[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>.
[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,
<https://www.rfc-editor.org/info/rfc7872>.
[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>.
[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 6 April 2024 [Page 24]
Internet-Draft host2netsig October 2023
[RFC9419] Arkko, J., Hardie, T., Pauly, T., and M. Kühlewind,
"Considerations on Application - Network Collaboration
Using Path Signals", RFC 9419, DOI 10.17487/RFC9419, July
2023, <https://www.rfc-editor.org/info/rfc9419>.
[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 6 April 2024 [Page 25]