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, . 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, . [I-D.herbert-eh-inflight-removal] Herbert, T., "Infight Removal of IPv6 Hop-by-Hop and Routing Headers", Work in Progress, Internet-Draft, draft- herbert-eh-inflight-removal-01, 2 October 2023, . Herbert Expires 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, . [I-D.ietf-6man-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-07, 27 September 2023, . [I-D.ietf-6man-hbh-processing] Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options Processing Procedures", Work in Progress, Internet-Draft, draft-ietf-6man-hbh-processing-10, 26 September 2023, . [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, . [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, . [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, . [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, . 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC7605] Touch, J., "Recommendations on Using Assigned Transport Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605, August 2015, . [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, . [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, . [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, . [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, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [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, . 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, . [TLSCERT] "Alert (TA17-075A), HTTPS Interception Weakens TLS Security", March 2017, . [_3GPP-5G] "5G; System Architecture for the 5G System", September 2018, . Author's Address Tom Herbert SiPanda Santa Clara, CA, United States of America Email: tom@herbertland.com Herbert Expires 6 April 2024 [Page 25]