idnits 2.17.00 (12 Aug 2021) /tmp/idnits13322/draft-conet-aeon-requirements-00.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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-conet-aeon-problem-statement-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Fan 3 Internet-Draft China Mobile 4 Intended status: Informational M. Boucadair 5 Expires: January 4, 2015 France Telecom 6 B. Williams 7 Akamai, Inc. 8 T. Reddy 9 C. Eckel 10 Cisco Systems, Inc. 11 July 3, 2014 13 Application Enabled Collaborative Networking Requirements 14 draft-conet-aeon-requirements-00 16 Abstract 18 Identification and treatment of application flows are important to 19 many application providers and network operators. Historically, this 20 functionality has been implemented to the extent possible using 21 heuristics, which inspect and infer flow characteristics. But many 22 application flows in current usages are dynamic, adaptive, time- 23 bound, encrypted, peer-to-peer, asymmetric, used on multipurpose 24 devices, and have different priorities depending on direction of 25 flow, user preferences, and other factors. Any combination of these 26 properties renders heuristic based techniques less effective and may 27 result in compromises to application security or user privacy. The 28 document states requirements for a solution that enables 29 identification and treatment of application flows without suffering 30 the limitations that plague existing solutions. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 4, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. Informative References . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 72 1. Introduction 74 Identification and treatment of application flows are important to 75 many application providers and network operators. The problems faced 76 by existing solutions that try to provide such visibility and to 77 enable appropriate treatment of application flows are described in 78 detail in [I-D.conet-aeon-problem-statement]. 80 As the IETF establishes default behaviors that thwart pervasive 81 surveillance (e.g. [RFC7258]), it will be important to provide 82 mechanisms for applications that want to have the network provide 83 differential flow treatment for their data. The intent is to have 84 applications protect the contents of their flows, yet have the 85 ability to opt-in to information exchanges that provide a more 86 precise allocation of network resources and thus better user 87 experience. The document provide a complete set of requirements for 88 such a solution. 90 2. Terminology 92 The section clarifies the intended meaning of specific terms used 93 within this document. 95 o 5-tuple: The combination of source IP address and port, 96 destination IP address and port, and transport protocol used to 97 transport an application flow. 99 o Application: An instance of an application running on end user's 100 device, such as a web application running on an laptop or an 101 application running on a mobile device. 103 o Flow characteristics: Characteristics of an individual application 104 flow, such as 5-tuple used to transport the flow, tolerance to 105 delay, loss, or jitter, anticipated average or maximum rate, 106 relative priority with respect to the application's other flows, 107 etc. Examples of individual application flows include an audio 108 flow, a video flow, a data flow, etc. 110 o Network node: A network element, such as a router, switch, 111 wireless access point, firewall, etc., that is in the path of one 112 or more application flows. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 3. Requirements 120 Rather than encourage independent, protocol specific solutions to 121 this problem, this document advocates a protocol and application 122 independent information model and individual data models that can be 123 applied in a consistent fashion across a variety of protocols to 124 enable explicit communication between applications and the networks 125 on which they are used. The requirements are: 127 Req-1: MUST provide a mechanism for applications to explicitly 128 signal the flow characteristics for their flows to the network. 130 Req-2: MUST provide network nodes visibility to the flow 131 characteristics signaled by applications. 133 Req-3: MUST provide mechanism for applications to receive feedback 134 from the network. This feedback communicates anticipated ability 135 of the network node to accommodate the corresponding flow. 137 Req-4: MUST provide visibility for both directions of a flow, 138 including flows that cross administrative boundaries. 140 Req-5: MUST provides mechanism for mutual authentication between 141 applications and network nodes, such that applications signal flow 142 characteristics and receive feedback from trusted network nodes 143 and network nodes process flow characteristics signaled by 144 authorized applications. 146 Req-6: MUST provide mechanism for 3rd party authentication and 147 authorization for over-the-top (OTT) applications. 149 Req-7: MUST provide mechanism for integrity protection and replay 150 protection of exchanges between the application and the network. 152 Req-8: MUST provide mechanism for applications to opt-out of any 153 explicit signaling of their flow characteristics to the network. 155 Req-9: MUST provide mechanism for flow characteristics signaled by 156 applications to change over time, and in a timely manner, in 157 response to changes in application operation. 159 Req-10: MUST provide mechanism for feedback provided by network 160 nodes to change over time, and in a timely manner, in response to 161 changes in network conditions. 163 Req-11: SHOULD provide mechanism for application flow 164 characteristics to be propagated to all network nodes within a 165 network. 167 Req-12: MUST NOT dramatically affect the performance of 168 participating network nodes and other network infrastructure 169 propagating the flow characteristics. 171 Req-13: MUST be applicable for both IPv4 and IPv6 deployments. 173 Req-14: SHOULD reuse or extend existing IETF standard protocols 174 wherever possible. 176 Req-15: MUST provide considerations for protection against denial of 177 service attacks against network nodes. 179 Req-16: MUST provide mechanism(s) that can be implemented as part of 180 a user process or library that does NOT require any special 181 privileges. 183 In designing a solution that meets these requirements, considerations 184 should be made for existing deployments of heuristic based 185 mechanisms. Such mechanisms are used in many networks and it is 186 desirable that they continue to work as applications and networks 187 nodes are incrementally enabled with functionality provided by this 188 solution. 190 4. Informative References 192 [I-D.conet-aeon-problem-statement] 193 Fan, P., Deng, H., Boucadair, M., Reddy, T., and C. Eckel, 194 "Application Enabled Collaborative Networking: Problem 195 Statement and Requirements", draft-conet-aeon-problem- 196 statement-00 (work in progress), May 2014. 198 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 199 Requirement Levels", BCP 14, RFC 2119, March 1997. 201 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 202 Attack", BCP 188, RFC 7258, May 2014. 204 Authors' Addresses 206 Peng Fan 207 China Mobile 208 32 Xuanwumen West Street, Xicheng District 209 Beijing 100053 210 P.R. China 212 Email: fanpeng@chinamobile.com 214 Mohamed Boucadair 215 France Telecom 216 Rennes 35000 217 France 219 Email: mohamed.boucadair@orange.com 221 Brandon Williams 222 Akamai, Inc. 223 8 Cambridge Center 224 Cambridge, MA 02142 225 USA 227 Email: brandon.williams@akamai.com 228 Tirumaleswar Reddy 229 Cisco Systems, Inc. 230 Cessna Business Park, Varthur Hobli 231 Sarjapur Marathalli Outer Ring Road 232 Bangalore, Karnataka 560103 233 India 235 Email: tireddy@cisco.com 237 Charles Eckel 238 Cisco Systems, Inc. 239 170 West Tasman Drive 240 San Jose, CA 95134 241 USA 243 Email: eckelcu@cisco.com