diff options
Diffstat (limited to 'doc/rfc/rfc9217.txt')
| -rw-r--r-- | doc/rfc/rfc9217.txt | 483 |
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 |