Current Open Questions in Path Aware Networking
Google Switzerland GmbH
Gustav-Gull-Platz 1
8004 Zurich
Switzerland
ietf@trammell.ch
Path Aware Networking RG
Internet-Draft
In contrast to the present Internet architecture, a path-aware internetworking
architecture has two important properties: it exposes the properties of
available Internet paths to endpoints, and provides for endpoints and
applications to use these properties to select paths through the Internet for
their traffic. While this property of "path awareness" already exists in many
Internet-connected networks within single domains and via administrative
interfaces to the network layer, a fully path-aware internetwork expands these
concepts across layers and across the Internet.
This document poses questions in path-aware networking open as of 2021, that
must be answered in the design, development, and deployment of path-aware
internetworks. It was originally written to frame discussions in the Path Aware
Networking proposed Research Group (PANRG), and has been published to snapshot
current thinking in this space.
Discussion Venues
Source for this draft and an issue tracker can be found at
.
Introduction to Path-Aware Networking
In the current Internet architecture, the network layer provides an
unverifiable, best-effort service to the endpoints using it. While there are
technologies that attempt better-than-best-effort delivery, the interfaces to
these are generally administrative as opposed to endpoint-exposed (e.g. PCE
and SD-WAN approaches), and they are often restricted to single
administrative domains. In this environment, an application can assume that a
packet with a given destination address will eventually be forwarded toward that
destination, but little else.
A transport layer protocol such as TCP can provide reliability over this
best-effort service, and a protocol above the network layer such as IPsec AH
or TLS can authenticate the remote endpoint. However,
little, if any, explicit information about the path is available to the
endpoint, and assumptions about that path often do not hold, sometimes with
serious impacts on the application, as in the case with BGP hijacking attacks.
By contrast, in a path-aware internetworking architecture, endpoints have the
ability to select or influence the path through the network used by any given
packet or flow. The network and transport layers explicitly expose information
about the path or paths available from one endpoint to another, and to those
endpoints and the applications running on them, so that they can make this
selection. The ALTO protocol can be seen as an example of a
path-awareness approach implemented in transport-layer terms on the present
Internet protocol stack.
Path selection provides explicit visibility and control of network treatment to
applications and users of the network. This selection is available to the
application, transport, and/or network layer entities at each endpoint. Path
control at the flow and subflow level enables the design of new transport
protocols that can leverage multipath connectivity across disjoint paths through
the Internet, even over a single physical interface. When exposed to
applications, or to end-users through a system configuration interface, path
control allows the specification of constraints on the paths that traffic should
traverse, for instance to confound passive surveillance in the network core
.
We note that this property of "path awareness" already exists in many
Internet-connected networks within single domains. Indeed, much of the practice
of network engineering using encapsulation at layer 3 can be said to be "path
aware", in that it explicitly assigns traffic at tunnel endpoints to a given
path within the network. Path-aware internetworking seeks to extend this
awareness across domain boundaries without resorting to overlays, except as a
transition technology.
This document presents a snapshot of open questions in this space that will need
to be answered in order to realize a path-aware internetworking architecture; it
is published to further frame discussions within and outside the Path Aware
Networking Research Group, and is published with the rough consensus of that
group.
Definition
For purposes of this document, "path aware networking" describes endpoint
discovery of the properties of paths they use for communication across an
internetwork, and endpoint reaction to these properties that affects routing
and/or data transfer. Note that this can and already does happen to some extent
in the current Internet architecture; this definition expands current techniques
of path discovery and manipulation to cross administrative domain boundaries and
up to the transport and application layers at the endpoints.
Expanding on this definition, a "path aware internetwork" is one in which
endpoint discovery of path properties and endpoint selection of paths used by
traffic exchanged by the endpoint are explicitly supported, regardless of the
specific design of the protocol features which enable this discovery and
selection.
A "path", for the purposes of these definitions, is abstractly defined as a
sequence of adjacent path elements over which a packet can be transmitted,
where the definition of "path element" is technology-dependent. As this document
is intended to pose questions rather than answer them, it assumes that this
definition will be refined as part of the answer the first two questions it
poses, about the vocabulary of path properties and how they are disseminated.
Research into path aware networking covers any and all aspects of
designing, building, and operating path aware internetworks or the networks
and endpoints attached to them. This document presents a collection of
research questions to address in order to make a path aware Internet a
reality.
Questions
Realizing path-aware networking requires answers to a set of open research
questions. This document poses these questions, as a starting point for
discussions about how to realize path awareness in the Internet, and to direct
future research efforts within the Path Aware Networking Research Group.
A Vocabulary of Path Properties
In order for information about paths to be exposed to an endpoint, and for the
endpoint to make use of that information, it is necessary to define a common
vocabulary for paths through an internetwork, and properties of those paths. The
elements of this vocabulary could include terminology for components of a path
and properties defined for these components, for the entire path, or for
subpaths of a path. These properties may be relatively static, such as the
presence of a given node or service function on the path; as well as relatively
dynamic, such as the current values of metrics such as loss and latency.
This vocabulary must be defined carefully, as its design will have impacts on
the expressiveness of a given path-aware internetworking architecture. This
expressiveness also exhibits tradeoffs. For example, a system that exposes
node-level information for the topology through each network would maximize
information about the individual components of the path at the endpoints, at
the expense of making internal network topology universally public, which may
be in conflict with the business goals of each network's operator. Furthermore,
properties related to individual components of the path may change frequently
and may quickly become outdated. However, aggregating the properties of
individual components to distill end-to-end properties for the entire path is
not trivial.
The first question: how are paths and path properties defined and represented?
Discovery, Distribution, and Trustworthiness of Path Properties
Once endpoints and networks have a shared vocabulary for expressing path
properties, the network must have some method for distributing those path
properties to the endpoint. Regardless of how path property information is
distributed to the endpoints, the endpoints require a method to authenticate
the properties -- to determine that they originated from and pertain to the
path that they purport to.
Choices in distribution and authentication methods will have impacts on the
scalability of a path-aware architecture. Possible dimensions in the space of
distribution methods include in-band versus out-of-band, push versus pull
versus publish-subscribe, and so on. There are temporal issues with path
property dissemination as well, especially with dynamic properties, since the
measurement or elicitation of dynamic properties may be outdated by the time
that information is available at the endpoints, and interactions between the
measurement and dissemination delay may exhibit pathological behavior for
unlucky points in the parameter space.
The second question: how do endpoints and applications get access to accurate,
useful, and trustworthy path properties?
Supporting Path Selection
Access to trustworthy path properties is only half of the challenge in
establishing a path-aware architecture. Endpoints must be able to use this
information in order to select paths for specific traffic they send. As with the
dissemination of path properties, choices made in path selection methods will
also have an impact on the tradeoff between scalability and expressiveness of a
path-aware architecture. One key choice here is between in-band and
out-of-band control of path selection. Another is granularity of path selection
(whether per packet, per flow, or per larger aggregate), which also has a large
impact on the scalabilty/expressiveness tradeoff. Path selection must, like
path property information, be trustworthy, such that the result of a path
selection at an endpoint is predictable. Moreover, any path selection mechanism
should aim to provide an outcome that is not worse than using a single path, or
selecting paths at random.
The third question: how can endpoints select paths to use for traffic in a way
that can be trusted by the network, the endpoints, and the applications using them?
Interfaces for Path Awareness
In order for applications to make effective use of a path-aware networking
architecture, the control interfaces presented by the network and transport
layers must also expose path properties to the application in a useful way, and
provide a useful set of paths among which the application can select. Path
selection must be possible based not only on the preferences and policies of the
application developer, but of end-users as well. Also, the path selection
interfaces presented to applications and end users will need to support multiple
levels of granularity. Most applications' requirements can be satisfied with the
expression of path selection policies in terms of properties of the paths, while
some applications may need finer-grained, per-path control. These interfaces
will need to support incremental development and deployment of applications, and
provide sensible defaults, to avoid hindering their adoption.
The fourth question: how can interfaces among the network, transport, and
application layers support the use of path awareness?
Implications of Path Awareness for the Transport and Application Layers
In the current Internet, the basic assumption that at a given time all
traffic for a given flow will receive the same network treatment and traverse
the same path or equivalend paths often holds. In a path aware network,
this assumption is more easily violated. The weakening of this assumption
has implications for the design of protocols above any path-aware network layer.
For example, one advantage of multipath communication is that a given
end-to-end flow can be "sprayed" along multiple paths in order to confound
attempts to collect data or metadata from those flows for pervasive
surveillance purposes . However, the benefits of this approach are
reduced if the upper-layer protocols use linkable identifiers on packets
belonging to the same flow across different paths. Clients may mitigate
linkability by opting to not re-use cleartext connection identifiers, such as
TLS session IDs or tickets, on separate paths. The privacy-conscious
strategies required for effective privacy in a path-aware Internet are only
possible if higher-layer protocols such as TLS permit clients to obtain
unlinkable identifiers.
The fifth question: how should transport-layer and higher layer protocols be
redesigned to work most effectively over a path-aware networking layer?
What is an Endpoint?
The vision of path-aware networking articulated so far makes an assumption
that path properties will be disseminated to endpoints on which applications
are running (terminals with user agents, servers, and so on). However,
incremental deployment may require that a path-aware network "core" be used to
interconnect islands of legacy protocol networks. In these cases, it is the
gateways, not the application endpoints, that receive path properties and make
path selections for that traffic. The interfaces provided by this gateway are
necessarily different than those a path-aware networking layer provides to its
transport and application layers, and the path property information the
gateway needs and makes available over those interfaces may also be different.
The sixth question: how is path awareness (in terms of vocabulary and
interfaces) different when applied to tunnel and overlay endpoints?
Operating a Path Aware Network
The network operations model in the current Internet architecture assumes that
traffic flows are controlled by the decisions and policies made by network
operators, as expressed in interdomain and intradomain routing protocols. In
a network providing path selection to the endpoints, however, this assumption
no longer holds, as endpoints may react to path properties by selecting
alternate paths. Competing control inputs from path-aware endpoints and the routing
control plane may lead to more difficult traffic engineering or nonconvergent
forwarding, especially if the endpoints' and operators' notion of the "best" path
for given traffic diverges significantly. The degree of difficulty may depend on
the fidelity of information made available to path selection algorithms at
the endpoints. Explicit path selection can also specify
outbound paths, while BGP policies are expressed in terms of inbound traffic.
A concept for path aware network operations will need to have clear methods
for the resolution of apparent (if not actual) conflicts of intent between the
network's operator and the path selection at an endpoint. It will also need
set of safety principles to ensure that increasing path control does not lead
to decreasing connectivity; one such safety principle could be "the existence
of at least one path between two endpoints guarantees the selection of at
least one path between those endpoints."
The seventh question: how can a path aware network in a path aware internetwork
be effectively operated, given control inputs from network administrators,
application designers, and end users?
Deploying a Path Aware Network
The vision presented in the introduction discusses path aware networking from
the point of view of the benefits accruing at the endpoints, to designers of
transport protocols and applications as well as to the end users of those
applications. However, this vision requires action not only at the endpoints but
also within the interconnected networks offering path aware connectivity. While
the specific actions required are a matter of the design and implementation of a
specific realization of a path aware protocol stack, it is clear than any path
aware architecture will require network operators to give up some control of
their networks over to endpoint-driven control inputs.
Here the question of apparent versus actual conflicts of intent arises again:
certain network operations requirements may appear essential, but are merely
accidents of the interfaces provided by current routing and management
protocols. For example, related (but adjacent) to path aware networking, the
widespread use of the TCP wire image in network monitoring for DDoS
prevention appears in conflict with the deployment of encrypted transports, only
because path signaling has been implicit in the deployment of past
transport protocols.
Similarly, incentives for deployment must show how existing network operations
requirements are met through new path selection and property dissemination
mechanisms.
The incentives for network operators and equipment vendors need to be made
clear, in terms of a plan to transition an internetwork to
path-aware operation, one network and facility at a time. This plan to
transition must also take into account that the dynamics of path aware
networking early in this transition (when few endpoints and flows in the
Internet use path selection) may be different than those later in the
transition.
Aspects of data security and information management in a network that explicitly
radiates more information about the network's deployment and configuration, and
implicitly radiates information about endpoint configuration and preference
through path selection, must also be addressed.
The eighth question: how can the incentives of network operators and end-users
be aligned to realize the vision of path aware networking, and how can the
transition from current ("path-oblivious") to path-aware networking be managed?
Acknowledgments
Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind, Olivier
Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood, Lee Howard, Mohamed
Boucadair, Thorben Krueger, Gorry Fairhurst, Spencer Dawkins, Theresa Enghardt,
and Laurent Ciavaglia, for discussions leading to questions in this document, and
for feedback on the document itself.
This work is partially supported by the European Commission under Horizon 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxed
Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and
Innovation under contract no. 15.0268. This support does not imply endorsement.
Informative References
A Path Computation Element (PCE)-Based Architecture
Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.
IP Authentication Header
This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
Application-Layer Traffic Optimization (ALTO) Protocol
Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.
The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.
This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.
Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement
Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.
The Wire Image of a Network Protocol
This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications that increased encryption has for network functions that use the wire image.
Transport Protocol Path Signals
This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
Planning for Protocol Adoption and Subsequent Transitions
Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions; thus, some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and it also summarizes what makes for a good transition plan.