Internet DRAFT - draft-herbert-net2hostsig

draft-herbert-net2hostsig







Network Working Group                                         T. Herbert
Internet-Draft                                                   SiPanda
Intended status: Informational                         27 September 2023
Expires: 30 March 2024


                       Host to Network Signaling
                      draft-herbert-net2hostsig-00

Abstract

   This document discusses the motivations, use cases, and requirements
   for Host to Network Signaling.  In Host to Network Signaling, a 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 to
   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 30 March 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 30 March 2024                 [Page 1]

Internet-Draft                 host2netsig                September 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 . . . . . . . . . . . . . . . .   7
     3.2.  Host to network signaling in wireless networks  . . . . .   8
     3.3.  Explicit signals  . . . . . . . . . . . . . . . . . . . .   8
     3.4.  Traffic flow analysis . . . . . . . . . . . . . . . . . .   8
   4.  Existing mechanisms . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  Stateful firewalls and proxies  . . . . . . . . . . . . .   9
       4.1.1.  Problems with transport stateful network devices  . .   9
       4.1.2.  Problems with application layer firewalls . . . . . .  10
     4.2.  Differentiated services . . . . . . . . . . . . . . . . .  11
     4.3.  Deep packet inspection  . . . . . . . . . . . . . . . . .  11
   5.  Proposals for host to network signaling . . . . . . . . . . .  12
     5.1.  Embedded information in UDP encapsulation . . . . . . . .  12
     5.2.  UDP Options . . . . . . . . . . . . . . . . . . . . . . .  13
     5.3.  Overloading the IPv6 Flow Label . . . . . . . . . . . . .  13
     5.4.  Overloading bits in IPv6 addresses  . . . . . . . . . . .  14
     5.5.  Stateful mechanisms . . . . . . . . . . . . . . . . . . .  15
     5.6.  Destination Options . . . . . . . . . . . . . . . . . . .  15
     5.7.  Hop-by-Hop Options  . . . . . . . . . . . . . . . . . . .  16
       5.7.1.  Processing requirements of Hop-by-Hop Options . . . .  16
       5.7.2.  Support in IPv4 . . . . . . . . . . . . . . . . . . .  17
   6.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22

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 an a per packet basis.  The
   signal is expressed as ancillary information that attached packets.

   Host to Network Signals are explcit 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



Herbert                   Expires 30 March 2024                 [Page 2]

Internet-Draft                 host2netsig                September 2023


   contrasted with Transport Path Signals as discussed in [RFC8558].
   The primary difference is that Host to Network Signaling employs
   explicit signals in 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 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.











Herbert                   Expires 30 March 2024                 [Page 3]

Internet-Draft                 host2netsig                September 2023


   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
   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 a signal 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
   reply 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




Herbert                   Expires 30 March 2024                 [Page 4]

Internet-Draft                 host2netsig                September 2023


   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
   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 the 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 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.

   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.

   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 that
   is the reflected to signal relevant to the provider network of the
   destination host.



Herbert                   Expires 30 March 2024                 [Page 5]

Internet-Draft                 host2netsig                September 2023


   Signals are scoped values in that they only have meaning in their
   origin domain in which a ticket was issued.  The format, meaning, and
   interpretation of 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 others tickets 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 a 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.

   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



Herbert                   Expires 30 March 2024                 [Page 6]

Internet-Draft                 host2netsig                September 2023


   (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.  The RFC 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 layers 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.

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



Herbert                   Expires 30 March 2024                 [Page 7]

Internet-Draft                 host2netsig                September 2023


   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
   convey 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 another potential
   use case for host to network signaling.

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
   that is sending packets.  The information is consumed by intermediate
   modes to perform analysis on how packets for various applications are
   flowing through a network.






Herbert                   Expires 30 March 2024                 [Page 8]

Internet-Draft                 host2netsig                September 2023


   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.

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.

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 resources, 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 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.



Herbert                   Expires 30 March 2024                 [Page 9]

Internet-Draft                 host2netsig                September 2023


   *  Stateful devices only work for a narrow set of specific transport
      protocols headers that are support by the device implementation.
      As evident by the experience with QUIC deployment, enabling
      stateful firewalls for a new transport protocol is a major
      undertaken 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 with 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 it is likely
      that a stateful firewall would 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 [eh-limits].

   *  Stateful devices have ossified 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 silent and anonymous participant in the Transport layer.
      Even if the end points 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 parser 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 such as HTTP in TCP.  While many of these devices had
   benevolent intent, some had less than benevolent intent were



Herbert                   Expires 30 March 2024                [Page 10]

Internet-Draft                 host2netsig                September 2023


   tantamount to be man-in-the-middle attacks.  To strengthen security,
   it is now common to encrypt transport payloads effectively rendering
   application firewalls ineffective.  A proposed alternative is for the
   application layer firewall to terminate TLS on behalf of users,
   however that is considered insecure.


   For instance, HTTP is commonly parsed to determine URL, content type,
   and other application level information that the network is
   interested in.  Application protocol parsing can only be effective
   with the application layer protocols that a device is programmed to
   parse.  More importantly, application layer parsing is effectively
   obsoleted in the network due the pervasive use of TLS.  TLS
   interception and SSL inspection, whereby an intermediate node
   implements a proxy that decrypts a TLS session and re-encrypts, is
   considered a security vulnerability [TLSCERT].

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.






Herbert                   Expires 30 March 2024                [Page 11]

Internet-Draft                 host2netsig                September 2023


   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
   it implements its own transport layer state machine as a ubiquitous
   means to expose transport layer connection semantics to network nodes
   thereby leveraging existing mechanisms in stateful devices such as
   stateful firewalls.

   The drawbacks of this approach are:

   *  This technique only works with UDP.  To work with other protocol
      requires encapsulation and applications need to change.  In
      particular, this is incompatible with TCP which is the predominant
      transport protocol on the Internet.

   *  Unless a UDP protocol is natively designed to include the embedded
      information, a shim header is required between the IP header and
      real transport layer header.  As demonstrated by QUIC [RFC9000],
      the trend in transport protocols is to encrypt as much of the
      packet as possible including the transport layer headers; it is
      likely that few UDP protocols would embed plain text information,
      so packets would inevitably need an extra UDP header which
      increases the complexity and diminishes feasibility of the
      solution.

   *  Embedding network signals inside UDP payload requires that
      intermediate nodes parse and process UDP payloads.  Since UDP port
      numbers do not have global meaning [RFC7605], there is the
      possibility of misinterpretation and of silent data corruption if
      intermediate nodes modify UDP payloads.  PLUS attempts to mitigate
      this issue with the use of magic numbers, however that can only
      ever be probabilistically correct.



Herbert                   Expires 30 March 2024                [Page 12]

Internet-Draft                 host2netsig                September 2023


   *  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.

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 the predominant
      transport protocol on the Internet.

   *  UDP Options are in protocol trailers of packets which makes it
      difficult to implement processing efficiently.  This is especially
      true for hardware implementations that are common in high
      performance routers for 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.



Herbert                   Expires 30 March 2024                [Page 13]

Internet-Draft                 host2netsig                September 2023


   The drawbacks of this approach are:

   *  The flow label is only twenty bytes, and if some bits are reserved
      to retain flow entropy then the effective number of bits available
      for signaling may be less; for example,
      [I-D.cc-v6ops-wlcg-flow-label-marking] uses sixteen bits of the
      flow label for signaling).  In any case, the 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.

   *  Addresses for a flow are fixed for the lifetime of the flow.
      There is no means to change service parameters mid-flow or per
      packet.



Herbert                   Expires 30 March 2024                [Page 14]

Internet-Draft                 host2netsig                September 2023


   *  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:

   *  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 follow other extension
      headers and is at a variable offset in packets.



Herbert                   Expires 30 March 2024                [Page 15]

Internet-Draft                 host2netsig                September 2023


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

   *  They may be dropped 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.

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, other ignored them, and still
   others elected to summarily drop all packets containing Hop-by-Hop
   Options.  A related issue was that the number of Hop-by-Hop Options
   in a packet was only limited by the MTU for the packet-- the lack of
   a limit combined with the requirement that nodes must skip over
   unknown options (when high order bit in the option type isn't set),
   creates the opportunity for DOS attacks by sending long lists of
   unknown Hop-by-Hop options.  The net effect of these issues was that
   deployment of Hop-by-Hop Options on the Internet was impeded.

   There is ongoing work to fix, or at least mitigate, the deployability
   problems of Hop-by-Hop options:

   *  [RFC8200] specifies that intermediate nodes MAY ignore Hop-by-Hop





Herbert                   Expires 30 March 2024                [Page 16]

Internet-Draft                 host2netsig                September 2023


      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.

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 far
   less deployable than even IPv6 Hop-by-Hop Options.  A major reason
   for this is that, unlike IPv6, the IPv4 header is variable length.
   Many hardware devices have long assumed that the IPv4 header is
   twenty bytes, processing a larger header will likely be problematic
   causing drops or packets being relegated to slow path processing.

   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.







Herbert                   Expires 30 March 2024                [Page 17]

Internet-Draft                 host2netsig                September 2023


6.  Requirements

   The requirements for host to network signaling are:

   *  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.

   *  Host to network signals MUST be transport protocol agnostic and
      and usable with an 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 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 a host to network signal,
      the signal can 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 signal SHOULD provide a clear API to applications
      the 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 MUST allow services to be applied in the
      return path of a communication.  In a client/server application it
      is often the packets in the reverse path that require the most
      service (for instance, if a video is being streamed to a client).

      Host to network signaling SHOULD provide a mechanisms by which
      hosts or application can request signals from the network to
      attach to packets.  A request can be a detailed list of services
      requested for a flow, and the provide signal encapsulates the
      services to be provider.  The response to a request is the signal
      data that the host or application can attach to its packets.




Herbert                   Expires 30 March 2024                [Page 18]

Internet-Draft                 host2netsig                September 2023


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.

   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 implemented a banned-list revoked host to network.

   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










Herbert                   Expires 30 March 2024                [Page 19]

Internet-Draft                 host2netsig                September 2023


   [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-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-05, 25 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-eh-
              limits-05>.

   [I-D.ietf-6man-hbh-processing]
              Hinden, R. M. and G. Fairhurst, "IPv6 Hop-by-Hop Options
              Processing Procedures", Work in Progress, Internet-Draft,
              draft-ietf-6man-hbh-processing-09, 4 July 2023,
              <https://datatracker.ietf.org/doc/html/draft-ietf-6man-
              hbh-processing-09>.

   [I-D.ietf-tsvwg-udp-options]
              Touch, J. D., "Transport Options for UDP", Work in
              Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-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>.










Herbert                   Expires 30 March 2024                [Page 20]

Internet-Draft                 host2netsig                September 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,
              <https://datatracker.ietf.org/doc/html/draft-reddy-tsvwg-
              explcit-signal-01>.

   [I-D.yiakoumis-network-tokens]
              Yiakoumis, Y., McKeown, N., and F. Sorensen, "Network
              Tokens", Work in Progress, Internet-Draft, draft-
              yiakoumis-network-tokens-02, 22 December 2020,
              <https://datatracker.ietf.org/doc/html/draft-yiakoumis-
              network-tokens-02>.

   [PLUS]     Tramell, B. and M. Kuehlewind, "Path Layer UDP Substrate
              Specification", December 2016,
              <https://datatracker.ietf.org/doc/draft-trammell-plus-
              spec/00/>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <https://www.rfc-editor.org/info/rfc2460>.

   [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>.





Herbert                   Expires 30 March 2024                [Page 21]

Internet-Draft                 host2netsig                September 2023


   [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>.

   [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 30 March 2024                [Page 22]