idnits 2.17.00 (12 Aug 2021) /tmp/idnits2985/draft-conet-aeon-problem-statement-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 (July 3, 2014) is 2872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3416' is defined on line 375, but no explicit reference was found in the text == Outdated reference: draft-ietf-netconf-restconf has been published as RFC 8040 == Outdated reference: draft-ietf-rtcweb-use-cases-and-requirements has been published as RFC 7478 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5766 (Obsoleted by RFC 8656) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Fan 3 Internet-Draft H. Deng 4 Intended status: Informational China Mobile 5 Expires: January 4, 2015 M. Boucadair 6 France Telecom 7 T. Reddy 8 C. Eckel 9 Cisco Systems, Inc. 10 B. Williams 11 Akamai, Inc. 12 July 3, 2014 14 Application Enabled Collaborative Networking: Problem Statement 15 draft-conet-aeon-problem-statement-01 17 Abstract 19 Identification and treatment of application flows are important to 20 many application providers and network operators. They often rely on 21 these capabilities to deploy and/or support a wide range of 22 applications. These applications generate flows that may have 23 specific connectivity requirements that can be met if made known to 24 the network. Historically, this functionality has been implemented 25 to the extent possible using heuristics, which inspect and infer flow 26 characteristics. Heuristics may be based on port ranges, network 27 separation (e.g. subnets or VLANs, Deep Flow Inspection (DFI), or 28 Deep Packet Inspection (DPI). But many application flows in current 29 usages are dynamic, adaptive, time-bound, encrypted, peer-to-peer, 30 asymmetric, used on multipurpose devices, and have different 31 priorities depending on direction of flow, user preferences, and 32 other factors. Any combination of these properties renders heuristic 33 based techniques less effective and may result in compromises to 34 application security or user privacy. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 4, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 72 2.1. Types of Signaling . . . . . . . . . . . . . . . . . . . 3 73 3. Typical Workflows . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Limitations of Heuristic Based Solutions . . . . . . . . . . 4 75 5. Limitations of Existing Signaling Mechanisms . . . . . . . . 5 76 6. Efforts in Progress . . . . . . . . . . . . . . . . . . . . . 6 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 78 8. Informative References . . . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 Networks today, whether public or private, are challenged with 84 demands to support rapidly increasing amounts of traffic. New 85 channels for creating and consuming rich media are deployed at a 86 rapid pace. Pervasive video and access on demand are becoming second 87 nature to consumers. Communication applications make extensive use 88 of rich media, placing unprecedented quality of experience 89 expectation on the underlying network. These trends present 90 challenges for network forecast and planning operations. 92 Now more so than ever before, identification and treatment of 93 application flows are critical for the successful deployment and 94 operation of a growing number of business and household applications. 95 These applications are based on a wide range of signaling protocols 96 and deployed by a diverse set of application providers that is not 97 necessarily affiliated with the network providers across which the 98 applications are used. 100 Historically, identification of application flows has been 101 accomplished using heuristics, which infer flow characteristics based 102 on port ranges, network separation, or inspection of the flow itself. 103 Inspection techniques include DPI, which matches against 104 characteristic signatures (e.g. key string, binary sequence, etc.) 105 and DFI, which analyzes statistical characteristics and connection 106 behavior of flows. Each of these techniques suffers from a set of 107 limitations, particularly in the face of the network challenges 108 outlined previously. 110 Heuristic-based approaches may not be efficient and require 111 continuous updates of application signatures. Port based solutions 112 suffer from port overloading and inconsistent port usage. Network 113 separation techniques like IP subnetting are error prone and increase 114 network management complexity. DPI and DFI are computationally 115 expensive, prone to error, and become more challenging with greater 116 adoption of encrypted signaling and secured media. An additional 117 drawback of DPI and DFI is that any insights are not available, or 118 need to be recomputed, at network nodes further down the application 119 flow path. 121 As the IETF establishes default behaviors that thwart pervasive 122 surveillance (e.g. [RFC7258]), it will be important to offer 123 mechanisms that allow applications to request differential network 124 treatment for their flows. The intent is to have applications 125 protect the contents of their flows, yet have the ability to opt-in 126 to information exchanges that provide a more precise allocation of 127 network resources and thus a better user experience. 129 2. Definitions and Terminology 131 2.1. Types of Signaling 133 The following terms describe the relationship between signaling and 134 the media to which it is associated. 136 o off-path: signaling along a different network path than the media 137 flow 139 o on-path: signaling along the same network path as the media flow 141 * in-band: signaling on the same port as the media flow 143 * out-of-band: signaling on a different port than the media flow 145 3. Typical Workflows 147 Various heuristic based approaches are used prevalently and 148 successfully for the following workflows: 150 1. Provide network operators with visibility of traffic usage and 151 patterns for troubleshooting, capacity planning, and other off 152 network workflows. This is done by exporting observed traffic 153 analysis via standard protocols such as IPFIX [RFC7011] and SNMP 154 [RFC3416]as well as by proprietary protocols and methods. 156 2. Provide network operators with visibility of application and data 157 usage for accounting and billing. 159 3. Provide differentiated network services for specific traffic 160 classes according to network operator defined policies. 161 Techniques to achieve this include traffic classification, 162 policing and shaping (e.g. [RFC2475]), providing admission 163 control (e.g. [RFC6601]), impacting routing, and permitting 164 passage of specific traffic (e.g. firewall functions). 166 4. Limitations of Heuristic Based Solutions 168 These workflows, visibility and differentiated network services, are 169 critical in many networks. However, their reliance on inspection and 170 observation limits their deployment. Reasons for this include the 171 following: 173 o Identification based on IP address lists is difficult to manage. 174 The addresses may be numerous and may change, they may be dynamic, 175 private, or otherwise not meant to be exposed. With Content 176 Delivery Network InterConnection (CDNI) [RFC6770], content could 177 be served either from an upstream CDN (uCDN) or any of a number of 178 downstream CDNs (dCDN), and it will not be possible to manually 179 track the IP addresses of all the CDN surrogates. Even in cases 180 where identification by IP addresses is possible, more granular 181 identification of individual flows is not possible (e.g. audio 182 vs. video vs. data). 184 o Classification based on TCP/UDP port numbers often result in 185 incorrect behaviour due to port overloading (i.e. ports used by 186 applications other than those claiming the port with IANA). 188 o More and more traffic is encrypted, rendering DPI and DFI 189 impossible, inefficient, or much more complex, and sometimes at 190 the expense of privacy or security (e.g. need to share encryption 191 keys with intermediary proxy performing DPI/DFI). 193 o Visibility generally requires inspecting the signaling traffic of 194 applications. This traffic may flow through a different network 195 path than the actual application data traffic. Impacting the 196 traffic behavior is ineffective in those scenarios. 198 o Extensions to signaling protocols and changes in the ways 199 application use them can result in false negatives or false 200 positives during inspection. 202 o Inspection techniques are completely non-standard, so the ability 203 and accuracy to identify traffic varies across vendors, and 204 different implementation are likely to give different results for 205 the same traffic. 207 o Inspection techniques that require parsing the payload of packets 208 (e.g. DPI) not only impact performance due to additional 209 processing, but also impact memory due to the growing number and 210 size of signatures to identify new protocols. 212 o Network services leveraging heuristic based classification have a 213 negative effect on the application behavior by impacting its 214 traffic, while they do not provide explicit feedback to the 215 application. This results in a lost opportunity for the 216 application to gain insight and adjust its operation accordingly. 218 5. Limitations of Existing Signaling Mechanisms 220 The IETF has standardized several mechanisms involving explicit 221 signaling between applications and the network that may be used to 222 support visibility and differentiated network services workflows. 223 Unfortunately, none of these has experienced widespread deployment 224 success, nor are they well suited for the applications usages 225 described previously. Existing signaling options include the 226 following: 228 o RSVP [RFC2205] is the original on-path signaling protocol 229 standardized by the IETF. It is transported out-of-band and could 230 be used to signal information about any transport protocol traffic 231 (it currently supports TCP and UDP). Its original goal was to 232 provide admission control. Its requirement for explicit 233 reservation of resources end to end proved too heavy for most 234 network environments. Its success was further impacted by its 235 reliance on router-alert, which often leads to RSVP packets being 236 filtered by intervening networks, and by its requirement for 237 access to a raw socket, something that is generally not available 238 to applications running in user space. To date, more lightweight 239 signaling workflows utilizing RSVP have not been standardized 240 within the IETF. 242 o NSIS (next Steps in Signaling) [RFC5978] is the next iteration of 243 RSVP-like signaling defined by the IETF. It focused on the same 244 fundamental workflow as RSVP admission control as its main driver, 245 and because it did not provide significant enough use-case 246 benefits over RSVP, it has seen even less adoption than RSVP. 248 o DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet 249 marking can help provide QoS in some environments, but such 250 markings are often modified or removed at various points in the 251 network or when crossing network boundaries. There are additional 252 limitations when using DiffServ with real-time communications 253 applications, and the DART working group has been chartered to 254 write a document that explains the limitations that exist with 255 DiffServ when used with RTP in general as well in the specific 256 RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements]. 258 6. Efforts in Progress 260 Not surprisingly, there are several evolving proposals that aim to 261 address the visibility and differentiated network services workflows 262 where existing approaches are not sufficient. Protocol specific 263 extensions are being defined, creating duplicate or inconsistent 264 information models. This results operational complexity and a need 265 to convert information between protocols to leverage the best 266 protocol option for each specific use case. Examples of evolving 267 signaling options include the following: 269 o STUN [RFC5389] is an on-path, in-band signaling protocol that 270 could be extended to provide signaling to on-path network devices. 271 It provides an easily inspected packet signature, at least for 272 transport protocols such as UDP. Through its extensions TURN 273 [RFC5766] and ICE [RFC5245], it is becoming prevalent in 274 application signaling driven by the initial use-case of providing 275 NAT and firewall traversal capabilities and detecting local and 276 remote candidates for peer-to-peer media sessions. The TRAM 277 working group is chartered to update TURN and STUN to make them 278 more suitable for WebRTC. 280 o Port Control Protocol (PCP) [RFC6887] provides a mechanism to 281 describe a flow to the network. The primary driver for PCP is 282 creating port mappings on NAT and firewall devices. When doing 283 this, PCP pushes flow information from the host into the network 284 (specifically to the network's NAT or firewall device), and 285 receives information back from the network (from the NAT or 286 firewall device). It is not meant to be used end-to-end but 287 rather independently on one "edge" of a flow. It is therefore an 288 attractive alternative because it allows the introduction of 289 application to network signaling without relying on the remote 290 peer. This is especially useful in multi-domain communications. 292 o RESTCONF [I-D.ietf-netconf-restconf] is a REST-like protocol that 293 provides a programmatic interface over HTTP for accessing data 294 defined in YANG, using the datastores defined in NETCONF 295 [RFC6241]. It is meant to provide a standard mechanism for web 296 applications to access the configuration data, operational data, 297 data-model specific protocol operations, and notification events 298 within a networking device, in a modular and extensible manner. 300 o Interface to the Routing System (I2RS) is a working group 301 chartered to provide interfaces for management applications, 302 network controllers, and user applications to make specific 303 demands on the network. 305 o Abstraction and Control of Transport Networks (ACTN) is a non- 306 working group mailing list intended to enable discussion of the 307 architecture, use-cases, and requirements that provide abstraction 308 and virtual control of transport networks to various applications/ 309 clients. 311 o Prefix coloring has been proposed for use in HOMENET and 6MAN 312 working groups to provide differentiated services to applications 313 based on IP address. 315 o RTP Media Congestion Avoidance Techniques (RMCAT) has been 316 chartered to address the lack of generally accepted congestion 317 control mechanisms for interactive real-time media, which is often 318 carried via sets of flows using RTP over UDP. Explicit exchanges 319 of flow characteristics and congestion information between 320 applications and the network could play an important role in such 321 mechanisms. 323 o Transport Services (TAPS) is an effort to create a working group 324 to define transport services that are exposed to internet 325 applications. A TAP enabled application identifies its needs of 326 the locally available transports services via an API. Some of the 327 information provided is the same as what AEON proposes to have the 328 application communicate to the network. Furthermore, the 329 transport services of TAPS could benefit from this communication 330 with the network. 332 o Service Function Chaining (SFC) is a working group chartered to 333 address issues associated with the deployment of service functions 334 (e.g. firewalls, load balancers) in large-scale environments. 335 Service function chaining is the definition and instantiation of 336 an ordered set of instances of such service functions, and the 337 subsequent "steering" of traffic flows through those service 338 functions. Flow characteristics communicated via AEON could be 339 used as input into an SFC classifier and it could be transported 340 as SFC metadata. 342 7. Acknowledgements 344 The authors thank Toerless Eckert, Reinaldo Penno, Dan Wing, Amine 345 Choukir, Paul Jones, and Bill VerSteeg for their contributions to 346 this document. 348 8. Informative References 350 [I-D.ietf-netconf-restconf] 351 Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, 352 "RESTCONF Protocol", draft-ietf-netconf-restconf-00 (work 353 in progress), March 2014. 355 [I-D.ietf-rtcweb-use-cases-and-requirements] 356 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 357 Time Communication Use-cases and Requirements", draft- 358 ietf-rtcweb-use-cases-and-requirements-14 (work in 359 progress), February 2014. 361 [IEEE-802.1Q] 362 "IEEE Standards for Local and Metropolitan Area Networks: 363 Virtual Bridged Local Area Networks", IEEE 802.1Q, 2005, 364 . 367 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 368 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 369 Functional Specification", RFC 2205, September 1997. 371 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 372 and W. Weiss, "An Architecture for Differentiated 373 Services", RFC 2475, December 1998. 375 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 376 Simple Network Management Protocol (SNMP)", STD 62, RFC 377 3416, December 2002. 379 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 380 Guidelines for DiffServ Service Classes", RFC 4594, August 381 2006. 383 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 384 (ICE): A Protocol for Network Address Translator (NAT) 385 Traversal for Offer/Answer Protocols", RFC 5245, April 386 2010. 388 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 389 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 390 October 2008. 392 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 393 Relays around NAT (TURN): Relay Extensions to Session 394 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 396 [RFC5978] Manner, J., Bless, R., Loughney, J., and E. Davies, "Using 397 and Extending the NSIS Protocol Family", RFC 5978, October 398 2010. 400 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 401 Bierman, "Network Configuration Protocol (NETCONF)", RFC 402 6241, June 2011. 404 [RFC6601] Ash, G. and D. McDysan, "Generic Connection Admission 405 Control (GCAC) Algorithm Specification for IP/MPLS 406 Networks", RFC 6601, April 2012. 408 [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, 409 K., and G. Watson, "Use Cases for Content Delivery Network 410 Interconnection", RFC 6770, November 2012. 412 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 413 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 414 2013. 416 [RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of 417 the IP Flow Information Export (IPFIX) Protocol for the 418 Exchange of Flow Information", STD 77, RFC 7011, September 419 2013. 421 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 422 Attack", BCP 188, RFC 7258, May 2014. 424 Authors' Addresses 425 Peng Fan 426 China Mobile 427 32 Xuanwumen West Street, Xicheng District 428 Beijing 100053 429 P.R. China 431 Email: fanpeng@chinamobile.com 433 Hui Deng 434 China Mobile 435 32 Xuanwumen West Street, Xicheng District 436 Beijing 100053 437 P.R. China 439 Email: denghui@chinamobile.com 441 Mohamed Boucadair 442 France Telecom 443 Rennes 35000 444 France 446 Email: mohamed.boucadair@orange.com 448 Tirumaleswar Reddy 449 Cisco Systems, Inc. 450 Cessna Business Park, Varthur Hobli 451 Sarjapur Marathalli Outer Ring Road 452 Bangalore, Karnataka 560103 453 India 455 Email: tireddy@cisco.com 457 Charles Eckel 458 Cisco Systems, Inc. 459 170 West Tasman Drive 460 San Jose, CA 95134 461 USA 463 Email: eckelcu@cisco.com 464 Brandon Williams 465 Akamai, Inc. 466 8 Cambridge Center 467 Cambridge, MA 02142 468 USA 470 Email: brandon.williams@akamai.com