idnits 2.17.00 (12 Aug 2021) /tmp/idnits13642/draft-yw-spud-use-cases-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 28, 2015) is 2519 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3124' is defined on line 297, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2140 (Obsoleted by RFC 9040) == Outdated reference: A later version (-03) exists of draft-sprecher-mobile-tg-exposure-req-arch-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. You 3 Internet-Draft X. Wei 4 Intended status: Informational Huawei 5 Expires: December 30, 2015 June 28, 2015 7 Use Cases for SPUD 8 draft-yw-spud-use-cases-00 10 Abstract 12 The purpose of SPUD is to provide a standardized layer below the 13 transport layer, to behavior as a communication channel between the 14 host and network devices. So when a new transport protocol is 15 deployed, it's easy for network devices to cooperate with it. New 16 transports could have a common encapsulation to middleboxes. On the 17 other hand, the transport layer could also make use of the state of 18 network devices collected by the SPUD, to improve transport 19 performance. 21 This document provides some exemplary use cases for SPUD, especially 22 in stateful firewall and TCP optimization. The objective of this 23 draft is not to cover all conceivable p2a or a2p signaling in detail. 24 Rather, the intention is to explain the requirements in these use 25 cases as far as it is required to complement the problem statement of 26 the SPUD. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 30, 2015. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 3.1. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3.2. TCP Optimization . . . . . . . . . . . . . . . . . . . . 5 72 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 73 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 7.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 The purpose of SPUD is to provide a standardized layer below the 83 transport layer, to behavior as a communication channel between the 84 host and network devices. So when a new transport protocol is 85 deployed, it's easy for network devices to cooperate with it. New 86 transports could have a common encapsulation to middleboxes. For 87 example, when a new transport protocol is deployed, the middlebox 88 could be configured to allow the traffic even though it doesn't know 89 the new transport protocol. On the other hand, the transport layer 90 could also make use of the state of network devices collected by the 91 SPUD, to improve transport performance. 93 [I-D.hildebrand-spud-prototype] provides a prototype for grouping UDP 94 [RFC768] packets together into a "tube". [I-D.hardie-spud-use-cases] 95 describes some basic use cases for path declarations (p2a) and 96 application declarations (a2p). 98 This document provides some exemplary use cases for SPUD, especially 99 in stateful firewall and TCP optimization. The objective of this 100 draft is not to cover all conceivable p2a or a2p signaling in detail. 101 Rather, the intention is to explain the requirements in these use 102 cases as far as it is required to complement the problem statement of 103 the SPUD. 105 2. Terminology 107 This section contains definitions of term frequently used throughout 108 this document. 110 ICMP: Internet Control Message Protocol 112 MSS: Maximum Segment Size 114 RTT: Round-Trip Time 116 SPUD: Substrate Protocol for User Datagrams 118 TCP: Transmission Control Protocol 120 TCB: TCP Control Block 122 UDP: User Datagram Protocol 124 a2p: Application to Path 126 p2a: Path to Application 128 3. Use Cases 130 3.1. Firewall 132 Firewall is a kind of widely deployed middlebox that controls the 133 incoming and outgoing network traffic based on an applied rule set; 134 firewall usually works mainly on network layer and transport layer. 135 Based on whether firewall keeps track of the state of network 136 connection across it, firewall could be divided into stateless 137 firewall and stateful firewall, the latter one is more commonly 138 deployed. Compared with stateless firewall, stateful firewall 139 maintains states for network connections, the state could include IP 140 addresses, ports etc. Based on the states different packets could be 141 associated with a session. Stateful firewall could provide more 142 fine- grained network control, as the existing stateful firewall 143 could not only filter packet based on installed security policy but 144 also based on state information. For the design of SPUD, firewall 145 would be a very typical middlebox with which SPUD should be able to 146 interact. 148 The process of dealing with packets by stateful firewall could be 149 separated into two aspects: first, firewall administrator designs and 150 installs a set of security policies on firewall, examples of policies 151 could be prohibiting certain port numbers, prohibiting external host 152 from starting connection to internal hosts protected by the firewall; 153 second, if a connection is allowed, then firewall will establish a 154 session for the connection, and the session might be updated as long 155 as new packets belonging to the session arrive. 157 When a packet arrives at the firewall, if the packet belongs to an 158 existing session in firewall the packet will be allowed to pass 159 through; however if the packet doesn't belong to any existing 160 session, then security policy rules will be applied to decide whether 161 the packet is allowed, in case of the packet is allowed, a new 162 session will be created, if not the packet will be discarded. 164 In order for firewall to maintain session state for network 165 connection, the firewall must be able to know which session packets 166 belong to, i.e. how to associate independent packets with a session. 167 We should be aware that associating packets with a connection (we 168 named it connection-A here) to one session (named session-A here) is 169 just one case; another case is associating packet(s) not belonging to 170 connection-A but related to connection-A with session-A, for example, 171 normally firewall will forbid ICMP message (e.g. ICMP Host 172 unreachable or ICMP Network unreachable) initiated from external 173 network from passing through the firewall, but there are cases that 174 if the external initiated ICMP message is associated with an existing 175 session, the ICMP message should be allowed; another example is 176 association between FTP data connection and FTP control connection. 178 Another issue about firewall is that when a new transport protocol is 179 designed, the legacy firewall will be unable to properly deal with 180 traffic using the new transport protocol without any update of the 181 firewall for the new transport protocol, and the situation usually 182 leads to the traffic to be blocked. So one purpose of SPUD is to 183 increase the deployment of new transport protocol even if the 184 firewall is not updated for the new transport protocol. There could 185 be three potential solutions for this: (a) define a fixed SPUD layer 186 and hide the transport layer totally from firewall; (b) define a 187 flexible SPUD layer that could provide transport protocol related 188 information to firewall in a standardized form, so that the firewall 189 could learn about the behavior of new transport protocol; (c) define 190 an extensible SPUD layer, and the new transport protocol will be 191 designed by extending SPUD. 193 From the analysis above, in order to satisfy stateful firewall 194 requirements, SPUD protocol needs to provide the following functions: 196 (1) Assist firewall to associate a set of packets to the same 197 session, even though packets don't belong to but relate to the 198 connection. 200 (2) Provide enough traffic related information for firewall to 201 maintain state for the traffic. 203 (3) Indicate the start and stop of a session. 205 (4) Provide a standard interface to firewall assisting firewall to 206 deal with new transport protocol. 208 3.2. TCP Optimization 210 TCP [RFC793] is a connection-oriented reliable transport protocol. 211 Each TCP connection maintains state, usually in a data structure 212 called the TCP Control Block (TCB), containing information about the 213 connection state, such as RTT, MSS, congestion avoidance threshold. 214 These parameters can be shared across connections to the same host, 215 since they are in fact per-path (per-host-pair) dependent [RFC2140]. 217 The goal of state sharing is to improve transient transport 218 performance. However, these parameters cannot clearly reflect the 219 state of a specific on-path network device, for example, the state of 220 network bottleneck device on the path, which is very useful 221 information for TCP for TCB initialization. If TCP could obtain the 222 available bandwidth of the bottleneck device, it could adjust the 223 maximum congestion window size based on the ideal window size, which 224 can be calculated by "the bottleneck bandwidth * RTT". 225 [I-D.sprecher-mobile-tg-exposure-req-arch] presents the similar use 226 case, i.e. the requirements for a mobile throughput guidance exposure 227 mechanism that can be used to assist TCP in cellular networks, 228 ensuring better performance. 230 SPUD can be used for path declarations: information delivered to the 231 endpoints from devices along the path. Path declarations can be 232 thought of as enhanced ICMP for transports using SPUD, allowing 233 information about the condition or state of the path or the tube to 234 be communicated directly to a sender. Therefore, this usage would 235 enable the on-path network devices (e.g. gateway, router) to transmit 236 their states (e.g. delay, packet loss rate, and bandwidth) to the 237 transport layer. As the transport layer can obtain the state of the 238 on-path devices, it could make use of this information to configure 239 initial transport parameters. The objective is to optimize the 240 behavior of transport protocols. Meanwhile, the network state could 241 be shared across connections if they share the paths. The possible 242 scenario is shown in Figure 1. 244 +---------+ +---------+ 245 |Transport| |Transport| 246 |Layer |<--------------------------------------------->|Layer | 247 +---+-----+ +----+----+ 248 | | 249 | | 250 | ---------------------- | 251 | ////////// Networks \\\\\\\\ | 252 | /// \\\ | 253 | /+--------+ +--------+ \ | 254 | | |UDP|SPUD| +-------+ +-------+ |UDP|SPUD| | | 255 +--+ +--------+ |on-path| |on-path| +--------+ +----+ 256 | <---- |router | |router | ----> | 257 \\\\\ +-------+ +-------+ //// 258 \\\\\\\\\ //////// 259 ---------------------- 261 Figure 1: TCP Optimization Using SPUD 263 From the analysis above, in order to improve transport performance, 264 SPUD protocol needs to provide the following functions: 266 (1) Provide the state (e.g. bandwidth, delay) of on-path network 267 devices to the transport layer. 269 4. IANA Considerations 271 This document has no actions for IANA. 273 5. Security Considerations 275 For the use cases proposed in this document, the paritcipating 276 entities need to have certain kind of trust relationships with each 277 other. Meanwhile, the exposed information should be verifiable by 278 each other. How to establish the trust relationship and how to 279 verify the exposed information will be discussed in later versions of 280 this document. 282 6. Acknowledgement 284 The authors would like to thank Mirja Kuehlewind and Michael Welzl 285 for their comments. 287 7. References 289 7.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, March 1997. 294 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 295 April 1997. 297 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 298 RFC 3124, June 2001. 300 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 301 1980. 303 [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, 304 September 1981. 306 7.2. Informative References 308 [I-D.hardie-spud-use-cases] 309 Hardie, T., "Use Cases for SPUD", draft-hardie-spud-use- 310 cases-01 (work in progress), February 2015. 312 [I-D.hildebrand-spud-prototype] 313 Hildebrand, J. and B. Trammell, "Substrate Protocol for 314 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 315 prototype-03 (work in progress), March 2015. 317 [I-D.sprecher-mobile-tg-exposure-req-arch] 318 Jain, A., Terzis, A., Sprecher, N., Swaminathan, S., 319 Smith, K., and G. Klas, "Requirements and reference 320 architecture for Mobile Throughput Guidance Exposure", 321 draft-sprecher-mobile-tg-exposure-req-arch-01 (work in 322 progress), February 2015. 324 Authors' Addresses 325 Jianjie You 326 Huawei 327 101 Software Avenue, Yuhua District 328 Nanjing 210012 329 China 331 Email: youjianjie@huawei.com 333 Xinpeng Wei 334 Huawei 335 No. 3, Xin-Xi Rd., Haidian District 336 Beijing 100095 337 China 339 Email: weixinpeng@huawei.com