Current Open Questions in Path-Aware NetworkingGoogle Switzerland GmbHGustav-Gull-Platz 1Zurich8004Switzerlandietf@trammell.chPath Aware NetworkingIn 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 it 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 Research Group (PANRG), and has
been published to snapshot current thinking in this space.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Research Task Force
(IRTF). The IRTF publishes the results of Internet-related
research and development activities. These results might not be
suitable for deployment. This RFC represents the consensus of the Path Aware Networking
Research Group of the Internet Research Task Force (IRTF).
Documents approved for publication by the IRSG are not
candidates for any level of Internet Standard; see Section 2 of RFC
7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2022 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
() 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.
Table of Contents
. Introduction to Path-Aware Networking
. Definitions
. Questions
. A Vocabulary of Path Properties
. Discovery, Distribution, and Trustworthiness of Path Properties
. Supporting Path Selection
. Interfaces for Path Awareness
. Implications of Path Awareness for the Transport and Application Layers
. What is an Endpoint?
. Operating a Path-Aware Network
. Deploying a Path-Aware Network
. IANA Considerations
. Security and Privacy Considerations
. Informative References
Acknowledgments
Author's Address
Introduction to Path-Aware NetworkingIn the current Internet architecture, the network layer provides a
best-effort service to the endpoints using it, without verifiability of
the properties of the path between the endpoints. While there are
network-layer technologies that attempt better-than-best-effort
delivery, the interfaces to these are generally administrative as
opposed to endpoint exposed (e.g., Path Computation Element (PCE) and Software-Defined Wide Area
Network (SD-WAN) approaches), and they are often restricted to single
administrative domains. In this architecture, 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 Transport Layer Security (TLS) , can authenticate the remote endpoint. However,
little, if any, explicit information about the path is available to the
endpoints, and any assumptions made about that path often do not hold.
These sometimes have serious impacts on the application, as in the case
with BGP hijacking attacks.By contrast, in a path-aware internetworking architecture, endpoints
can select or influence the path(s) through the network used by any
given packet or flow. The network and transport layers explicitly expose
information about the path or paths available to the endpoints and to
the applications running on them, so that they can make this
selection. The Application-Layer Traffic Optimization (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.DefinitionsFor 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
that 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 to the first two questions it poses
about the vocabulary of path properties and how they are
disseminated.Research into path-aware internetworking 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.QuestionsRealizing 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 PropertiesThe first question: how are paths and path properties defined and represented?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 and its representation must be defined carefully,
as its design will have impacts on the properties (e.g.,
expressiveness, scalability, and security) of a given path-aware
internetworking architecture. 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.Discovery, Distribution, and Trustworthiness of Path PropertiesThe second question: how do endpoints and applications get access to accurate,
useful, and trustworthy 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 endpoints. Regardless of how path
property information is distributed, the endpoints require a method to
authenticate the properties in order 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.Supporting Path SelectionThe 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?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 trade-off
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 scalability/expressiveness trade-off. 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.Path selection may be exposed in terms of the properties of the path or the identity
of elements of the path. In the latter case, a path may be identified at any of
multiple layers (e.g., routing domain identifier, network-layer address, higher-layer
identifier or name, and so on). In this case, care must be taken to present
semantically useful information to those making decisions about which path(s)
to trust.Interfaces for Path AwarenessThe fourth question: how can interfaces among the network,
transport, and application layers support the use of 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.Implications of Path Awareness for the Transport and Application LayersThe fifth question: how should transport-layer and higher-layer
protocols be redesigned to work most effectively over a path-aware
networking layer?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 equivalent 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 reuse 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.What is an Endpoint?The sixth question: how is path awareness (in terms of vocabulary and
interfaces) different when applied to tunnel and overlay endpoints?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.Operating a Path-Aware NetworkThe 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?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 non-convergent 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 a 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."Deploying a Path-Aware NetworkThe 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?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 that 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 operation 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
operation 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.IANA ConsiderationsThis document has no IANA actions.
Security and Privacy Considerations
This document poses questions about path-aware internetworking; the
answers are a matter for future research, and security considerations
for those answers would be included in the corresponding RFCs that
describe them. While each of these questions is to a lesser or greater
degree relevant to the security and privacy of users of a path-aware
network, questions of discovery and trustworthiness ()
are most security-relevant.
Informative ReferencesSD-WAN Service Attributes and ServicesMEFMEF StandardA Path Computation Element (PCE)-Based ArchitectureConstraint-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.Application-Layer Traffic Optimization (ALTO) ProtocolApplications 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 StatementSince 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.Planning for Protocol Adoption and Subsequent TransitionsOver 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.The Transport Layer Security (TLS) Protocol Version 1.3This 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.The Wire Image of a Network ProtocolThis 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 SignalsThis 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.AcknowledgmentsMany thanks to , , ,
, , , , , , ,
, , , , ,
and 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.Author's AddressGoogle Switzerland GmbHGustav-Gull-Platz 1Zurich8004Switzerlandietf@trammell.ch