idnits 2.17.1 draft-irtf-panrg-questions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2018) is 2018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Path Aware Networking RG B. Trammell 3 Internet-Draft ETH Zurich 4 Intended status: Informational October 17, 2018 5 Expires: April 20, 2019 7 Open Questions in Path Aware Networking 8 draft-irtf-panrg-questions-01 10 Abstract 12 This document poses open questions in path-aware networking, as a 13 background for framing discussions in the Path Aware Networking 14 proposed Research Group (PANRG). These are split into making 15 properties of Internet paths available to endpoints, and allowing 16 endpoints to select paths through the Internet for their traffic. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 20, 2019. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction to Path-Aware Networking . . . . . . . . . . . . 2 53 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. A Vocabulary of Path Properties . . . . . . . . . . . . . 3 55 2.2. Discovery, Distribution, and Trustworthiness of Path 56 Properties . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Supporting Path Selection . . . . . . . . . . . . . . . . 4 58 2.4. Interfaces for Path Awareness . . . . . . . . . . . . . . 4 59 2.5. Implications of Path Awareness for the Data Plane . . . . 5 60 2.6. What is an Endpoint? . . . . . . . . . . . . . . . . . . 5 61 2.7. Operating a Path Aware Network . . . . . . . . . . . . . 6 62 2.8. Deploying a Path Aware Network . . . . . . . . . . . . . 6 63 3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 64 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. Normative References . . . . . . . . . . . . . . . . . . 7 66 4.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction to Path-Aware Networking 71 In the current Internet architecture, the interdomain network layer 72 provides an unverifiable, best-effort service: an application can 73 assume that a packet with a given destination address will eventually 74 be forwarded toward that destination, but little else. A transport 75 layer protocol such as TCP can provide reliability over this best- 76 effort service, and a protocol above the network layer such as IPsec 77 AH [RFC4302] or TLS [RFC5246] can authenticate the remote endpoint. 78 However, no explicit information about the path is available, and 79 assumptions about that path sometimes do not hold, sometimes with 80 serious impacts on the application, as in the case with BGP hijacking 81 attacks. 83 By contrast, in a path-aware internetworking architecture, endpoints 84 have the ability to select or influence the path through the network 85 used by any given packet, and the network layer explicitly exposes 86 information about the path or paths available between two endpoints 87 to those endpoints so that they can make this selection. Path 88 control at the packet level enables new transport protocols that can 89 leverage multipath connectivity across maximally-disjoint paths 90 through the Internet, even over a single interface. It also provides 91 transparency and control for applications and end-users to specify 92 constraints on the paths that traffic should traverse, for instance 93 to confound pervasive passive surveillance in the network core. 95 We note that this property of "path awareness" already exists in many 96 Internet-connected networks in an intradomain context. Indeed, much 97 of the practice of network engineering using encapsulation at layer 3 98 can be said to be "path aware", in that it explicitly assigns traffic 99 at tunnel endpoints to a given path within the network. Path-aware 100 internetworking seeks to extend this awareness across domain 101 boundaries without resorting to overlays, except as a transition 102 technology. 104 2. Questions 106 Realizing path-aware networking requires answers to a set of open 107 research questions. This document poses these questions, as a 108 starting point for discussions about how to realize path awareness in 109 the Internet, and to direct future research efforts within the Path 110 Aware Networking Research Group. 112 2.1. A Vocabulary of Path Properties 114 In order for information about paths to be exposed to the endpoints, 115 and for those endpoints to be able to use that information, it is 116 necessary to define a common vocabulary for path properties. The 117 elements of this vocabulary could include relatively static 118 properties, such as the presence of a given node on the path; as well 119 as relatively dynamic properties, such as the current values of 120 metrics such as loss and latency. 122 This vocabulary must be defined carefully, as its design will have 123 impacts on the expressiveness of a given path-aware internetworking 124 architecture. This expressiveness also exhibits tradeoffs. For 125 example, a system that exposes node-level information for the 126 topology through each network would maximize information about the 127 individual components of the path at the endpoints at the expense of 128 making internal network topology universally public, which may be in 129 conflict with the business goals of each network's operator. 131 The first question: how are path properties defined and represented? 133 2.2. Discovery, Distribution, and Trustworthiness of Path Properties 135 Once endpoints and networks have a shared vocabulary for expressing 136 path properties, the network must have some method for distributing 137 those path properties to the endpoint. Regardless of how path 138 property information is distributed to the endpoints, the endpoints 139 require a method to authenticate the properties - to determine that 140 they originated from and pertain to the path that they purport to. 142 Choices in distribution and authentication methods will have impacts 143 on the scalability of a path-aware architecture. Possible dimensions 144 in the space of distribution methods include in-band versus out-of- 145 band, push versus pull versus publish-subscribe, and so on. There 146 are temporal issues with path property dissemination as well, 147 especially with dynamic properties, since the measurement or 148 elicitation of dynamic properties may be outdated by the time that 149 information is available at the endpoints, and interactions between 150 the measurement and dissemination delay may exhibit pathological 151 behavior for unlucky points in the parameter space. 153 The second question: how do endpoints get access to trustworthy path 154 properties? 156 2.3. Supporting Path Selection 158 Access to trustworthy path properties is only half of the challenge 159 in establishing a path-aware architecture. Endpoints must be able to 160 use this information in order to select paths for traffic they send. 161 As with path property distribution, choices made in path selection 162 methods will also have an impact on the scalability and 163 expressiveness of a path-aware architecture, and dimensions included 164 in-band versus out-of-band, as well. Paths may also be selected on 165 multiple levels of granularity - per packet, per flow, per aggregate 166 - and this choice also has impacts on the scalabilty/expressiveness 167 tradeoff. Path selection must, like path property information, be 168 trustworthy, such that the result of a path selection at an endpoint 169 is predictable. 171 The third question: how can endpoints select paths to use for traffic 172 in a way that can be trusted by both the network and the endpoints? 174 2.4. Interfaces for Path Awareness 176 In order for applications to make effective use of a path-aware 177 networking architecture, the interfaces presented by the network and 178 transport layers must also expose path properties to the application 179 in a useful way, and provide a useful set of paths among which the 180 application can select. Path selection must be possible based not 181 only on the preferences and policies of the application developer, 182 but of end-users as well. Also, the path selection interfaces 183 presented to applications and end users will need to support multiple 184 levels of granularity. Most applications' requirements can be 185 satisfied with the expression path selection policies in terms of 186 properties of the paths, while some applications may need finer- 187 grained, per-path control. 189 The fourth question: how can interfaces to the transport and 190 application layers support the use of path awareness? 192 2.5. Implications of Path Awareness for the Data Plane 194 In the current Internet, the basic assumption that at a given time t 195 all traffic for a given flow will traverse a single path, for some 196 definition of path, generally holds. In a path aware network, this 197 assumption no longer holds. The absence of this assumption has 198 implications for the design of protocols above any path-aware network 199 layer. 201 For example, one advantage of multipath communication is that a given 202 end-to-end flow can be "sprayed" along multiple paths in order to 203 confound attempts to collect data or metadata from those flows for 204 pervasive surveillance purposes [RFC7624]. However, the benefits of 205 this approach are reduced if the upper-layer protocols use linkable 206 identifiers on packets belonging to the same flow across different 207 paths. Clients may mitigate linkability by opting to not re-use 208 cleartext connection identifiers, such as TLS session IDs or tickets, 209 on separate paths. The privacy-conscious strategies required for 210 effective privacy in a path-aware Internet are only possible if 211 higher-layer protocols such as TLS permit clients to obtain 212 unlinkable identifiers. 214 The fifth question: how should transport-layer and higher layer 215 protocols be redesigned to work most effectively over a path-aware 216 networking layer? 218 2.6. What is an Endpoint? 220 The vision of path-aware networking articulated so far makes an 221 assumption that path properties will be disseminated to endpoints on 222 which applications are running (terminals with user agents, servers, 223 and so on). However, incremental deployment may require that a path- 224 aware network "core" be used to interconnect islands of legacy 225 protocol networks. In these cases, it is the gateways, not the 226 application endpoints, that receive path properties and make path 227 selections for that traffic. The interfaces provided by this gateway 228 are necessarily different than those a path-aware networking layer 229 provides to its transport and application layers, and the path 230 property information the gateway needs and makes available over those 231 interfaces may also be different. 233 The sixth question: how is path awareness (in terms of vocabulary and 234 interfaces) different when applied to tunnel and overlay endpoints? 236 2.7. Operating a Path Aware Network 238 The network operations model in the current Internet architecture 239 assumes that traffic flows are controlled by the decisions and 240 policies made by network operators, as expressed in interdomain 241 routing protocols. In a network providing path selection to the 242 endpoints, however, this assumption no longer holds, as endpoints may 243 react to path properties by selecting alternate paths. Competing 244 control inputs from path-aware endpoints and the interdomain routing 245 control plane may lead to more difficult traffic engineering or 246 nonconvergent routing, especially if the endpoints' and operators' 247 notion of the "best" path for given traffic diverges significantly. 249 A concept for path aware network operations will need to have clear 250 methods for the resolution of apparent (if not actual) conflicts of 251 intent between the network's operator and the path selection at an 252 endpoint. It will also need set of safety principles to ensure that 253 increasing path control does not lead to decreasing connectivity; one 254 such safety principle could be "the existence of at least one path 255 between two endpoints guarantees the selection of at least one path 256 between those endpoints." 258 The seventh question: how can a path aware network in a path aware 259 internetwork be effectively operated, given control inputs from the 260 network administrator as well as from the endpoints? 262 2.8. Deploying a Path Aware Network 264 The vision presented in the introduction discusses path aware 265 networking from the point of view of the benefits accruing at the 266 endpoints, to designers of transport protocols and applications as 267 well as to the end users of those applications. However, this vision 268 requires action not only at the endpoints but within the 269 interconnected networks offering path aware connectivity. While the 270 specific actions required are a matter of the design and 271 implementation of a specific realization of a path aware protocol 272 stack, it is clear than any path aware architecture will require 273 network operators to give up some control of their networks over to 274 endpoint-driven control inputs. 276 Here the question of apparent versus actual conflicts of intent 277 arises again: certain network operations requirements may appear 278 essential, but are merely accidents of the interfaces provided by 279 current routing and management protocols. Incentives for deployment 280 must show how existing network operations requirements are met 281 through new path selection and property dissemination mechanisms. 283 The incentives for network operators and equipment vendors to do 284 provide be made clear, in terms of a plan to transition [RFC8170] an 285 internetwork to path-aware operation, one network and facility at a 286 time. 288 The eighth question: how can the incentives of network operators and 289 end-users be aligned to realize the vision of path aware networking? 291 3. Acknowledgments 293 Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kuehlewind, 294 Olivier Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood, 295 and Lee Howard, for discussions leading to questions in this 296 document. 298 This work is partially supported by the European Commission under 299 Horizon 2020 grant agreement no. 688421 Measurement and Architecture 300 for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat 301 for Education, Research, and Innovation under contract no. 15.0268. 302 This support does not imply endorsement. 304 4. References 306 4.1. Normative References 308 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 309 DOI 10.17487/RFC4302, December 2005, 310 . 312 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 313 (TLS) Protocol Version 1.2", RFC 5246, 314 DOI 10.17487/RFC5246, August 2008, 315 . 317 4.2. Informative References 319 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 320 Trammell, B., Huitema, C., and D. Borkmann, 321 "Confidentiality in the Face of Pervasive Surveillance: A 322 Threat Model and Problem Statement", RFC 7624, 323 DOI 10.17487/RFC7624, August 2015, 324 . 326 [RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and 327 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 328 May 2017, . 330 Author's Address 332 Brian Trammell 333 ETH Zurich 334 Gloriastrasse 35 335 8092 Zurich 336 Switzerland 338 Email: ietf@trammell.ch