doc: Add RFC documents

1 files changed, 483 insertions, 0 deletions

diff --git a/doc/rfc/rfc9217.txt b/doc/rfc/rfc9217.txt
new file mode 100644
index 0000000..61afa48
--- /dev/null
+++ b/doc/rfc/rfc9217.txt
@@ -0,0 +1,483 @@
+
+
+
+
+Internet Research Task Force (IRTF)                          B. Trammell
+Request for Comments: 9217                       Google Switzerland GmbH
+Category: Informational                                       March 2022
+ISSN: 2070-1721
+
+
+            Current Open Questions in Path-Aware Networking
+
+Abstract
+
+   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 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
+   https://www.rfc-editor.org/info/rfc9217.
+
+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
+   (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.
+
+Table of Contents
+
+   1.  Introduction to Path-Aware Networking
+     1.1.  Definitions
+   2.  Questions
+     2.1.  A Vocabulary of Path Properties
+     2.2.  Discovery, Distribution, and Trustworthiness of Path
+           Properties
+     2.3.  Supporting Path Selection
+     2.4.  Interfaces for Path Awareness
+     2.5.  Implications of Path Awareness for the Transport and
+           Application Layers
+     2.6.  What is an Endpoint?
+     2.7.  Operating a Path-Aware Network
+     2.8.  Deploying a Path-Aware Network
+   3.  IANA Considerations
+   4.  Security and Privacy Considerations
+   5.  Informative References
+   Acknowledgments
+   Author's Address
+
+1.  Introduction to Path-Aware Networking
+
+   In 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)
+   [RFC4655] and Software-Defined Wide Area Network (SD-WAN) [MEF70]
+   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) [RFC8446], 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 [RFC7285] 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 [RFC7624].
+
+   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.
+
+1.1.  Definitions
+
+   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
+   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.
+
+2.  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.
+
+2.1.  A Vocabulary of Path Properties
+
+   The 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.
+
+2.2.  Discovery, Distribution, and Trustworthiness of Path Properties
+
+   The 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.
+
+2.3.  Supporting Path Selection
+
+   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?
+
+   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.
+
+2.4.  Interfaces for Path Awareness
+
+   The 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.
+
+2.5.  Implications of Path Awareness for the Transport and Application
+      Layers
+
+   The 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 [RFC7624].  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.
+
+2.6.  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.
+
+2.7.  Operating a Path-Aware Network
+
+   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?
+
+   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."
+
+2.8.  Deploying a Path-Aware Network
+
+   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?
+
+   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 [RFC8546] in network monitoring for DDoS prevention
+   appears in conflict with the deployment of encrypted transports, only
+   because path signaling [RFC8558] 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 [RFC8170] 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.
+
+3.  IANA Considerations
+
+   This document has no IANA actions.
+
+4.  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
+   (Section 2.2) are most security-relevant.
+
+5.  Informative References
+
+   [MEF70]    MEF, "SD-WAN Service Attributes and Services", MEF
+              Standard, MEF 70, July 2019, <https://www.mef.net/wp-
+              content/uploads/2019/07/MEF-70.pdf>.
+
+   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+              Computation Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <https://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
+              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
+              "Application-Layer Traffic Optimization (ALTO) Protocol",
+              RFC 7285, DOI 10.17487/RFC7285, September 2014,
+              <https://www.rfc-editor.org/info/rfc7285>.
+
+   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
+              Trammell, B., Huitema, C., and D. Borkmann,
+              "Confidentiality in the Face of Pervasive Surveillance: A
+              Threat Model and Problem Statement", RFC 7624,
+              DOI 10.17487/RFC7624, August 2015,
+              <https://www.rfc-editor.org/info/rfc7624>.
+
+   [RFC8170]  Thaler, D., Ed., "Planning for Protocol Adoption and
+              Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
+              May 2017, <https://www.rfc-editor.org/info/rfc8170>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8546]  Trammell, B. and M. Kuehlewind, "The Wire Image of a
+              Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April
+              2019, <https://www.rfc-editor.org/info/rfc8546>.
+
+   [RFC8558]  Hardie, T., Ed., "Transport Protocol Path Signals",
+              RFC 8558, DOI 10.17487/RFC8558, April 2019,
+              <https://www.rfc-editor.org/info/rfc8558>.
+
+Acknowledgments
+
+   Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kühlewind,
+   Olivier Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood,
+   Lee Howard, Mohamed Boucadair, Thorben Krüger, Gorry Fairhurst,
+   Spencer Dawkins, Reese Enghardt, Laurent Ciavaglia, Stephen Farrell,
+   and Richard Yang 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 Address
+
+   Brian Trammell
+   Google Switzerland GmbH
+   Gustav-Gull-Platz 1
+   CH-8004 Zurich
+   Switzerland
+   Email: ietf@trammell.ch