Network Working Group J. You Internet-Draft X. Wei Intended status: Informational Huawei Expires: December 30, 2015 June 28, 2015 Use Cases for SPUD draft-yw-spud-use-cases-00 Abstract The purpose of SPUD is to provide a standardized layer below the transport layer, to behavior as a communication channel between the host and network devices. So when a new transport protocol is deployed, it's easy for network devices to cooperate with it. New transports could have a common encapsulation to middleboxes. On the other hand, the transport layer could also make use of the state of network devices collected by the SPUD, to improve transport performance. This document provides some exemplary use cases for SPUD, especially in stateful firewall and TCP optimization. The objective of this draft is not to cover all conceivable p2a or a2p signaling in detail. Rather, the intention is to explain the requirements in these use cases as far as it is required to complement the problem statement of the SPUD. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." You & Wei Expires December 30, 2015 [Page 1] Internet-Draft Use Cases for SPUD June 2015 This Internet-Draft will expire on December 30, 2015. Copyright Notice Copyright (c) 2015 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 (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. TCP Optimization . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The purpose of SPUD is to provide a standardized layer below the transport layer, to behavior as a communication channel between the host and network devices. So when a new transport protocol is deployed, it's easy for network devices to cooperate with it. New transports could have a common encapsulation to middleboxes. For example, when a new transport protocol is deployed, the middlebox could be configured to allow the traffic even though it doesn't know the new transport protocol. On the other hand, the transport layer could also make use of the state of network devices collected by the SPUD, to improve transport performance. [I-D.hildebrand-spud-prototype] provides a prototype for grouping UDP [RFC768] packets together into a "tube". [I-D.hardie-spud-use-cases] You & Wei Expires December 30, 2015 [Page 2] Internet-Draft Use Cases for SPUD June 2015 describes some basic use cases for path declarations (p2a) and application declarations (a2p). This document provides some exemplary use cases for SPUD, especially in stateful firewall and TCP optimization. The objective of this draft is not to cover all conceivable p2a or a2p signaling in detail. Rather, the intention is to explain the requirements in these use cases as far as it is required to complement the problem statement of the SPUD. 2. Terminology This section contains definitions of term frequently used throughout this document. ICMP: Internet Control Message Protocol MSS: Maximum Segment Size RTT: Round-Trip Time SPUD: Substrate Protocol for User Datagrams TCP: Transmission Control Protocol TCB: TCP Control Block UDP: User Datagram Protocol a2p: Application to Path p2a: Path to Application 3. Use Cases 3.1. Firewall Firewall is a kind of widely deployed middlebox that controls the incoming and outgoing network traffic based on an applied rule set; firewall usually works mainly on network layer and transport layer. Based on whether firewall keeps track of the state of network connection across it, firewall could be divided into stateless firewall and stateful firewall, the latter one is more commonly deployed. Compared with stateless firewall, stateful firewall maintains states for network connections, the state could include IP addresses, ports etc. Based on the states different packets could be associated with a session. Stateful firewall could provide more fine- grained network control, as the existing stateful firewall You & Wei Expires December 30, 2015 [Page 3] Internet-Draft Use Cases for SPUD June 2015 could not only filter packet based on installed security policy but also based on state information. For the design of SPUD, firewall would be a very typical middlebox with which SPUD should be able to interact. The process of dealing with packets by stateful firewall could be separated into two aspects: first, firewall administrator designs and installs a set of security policies on firewall, examples of policies could be prohibiting certain port numbers, prohibiting external host from starting connection to internal hosts protected by the firewall; second, if a connection is allowed, then firewall will establish a session for the connection, and the session might be updated as long as new packets belonging to the session arrive. When a packet arrives at the firewall, if the packet belongs to an existing session in firewall the packet will be allowed to pass through; however if the packet doesn't belong to any existing session, then security policy rules will be applied to decide whether the packet is allowed, in case of the packet is allowed, a new session will be created, if not the packet will be discarded. In order for firewall to maintain session state for network connection, the firewall must be able to know which session packets belong to, i.e. how to associate independent packets with a session. We should be aware that associating packets with a connection (we named it connection-A here) to one session (named session-A here) is just one case; another case is associating packet(s) not belonging to connection-A but related to connection-A with session-A, for example, normally firewall will forbid ICMP message (e.g. ICMP Host unreachable or ICMP Network unreachable) initiated from external network from passing through the firewall, but there are cases that if the external initiated ICMP message is associated with an existing session, the ICMP message should be allowed; another example is association between FTP data connection and FTP control connection. Another issue about firewall is that when a new transport protocol is designed, the legacy firewall will be unable to properly deal with traffic using the new transport protocol without any update of the firewall for the new transport protocol, and the situation usually leads to the traffic to be blocked. So one purpose of SPUD is to increase the deployment of new transport protocol even if the firewall is not updated for the new transport protocol. There could be three potential solutions for this: (a) define a fixed SPUD layer and hide the transport layer totally from firewall; (b) define a flexible SPUD layer that could provide transport protocol related information to firewall in a standardized form, so that the firewall could learn about the behavior of new transport protocol; (c) define You & Wei Expires December 30, 2015 [Page 4] Internet-Draft Use Cases for SPUD June 2015 an extensible SPUD layer, and the new transport protocol will be designed by extending SPUD. From the analysis above, in order to satisfy stateful firewall requirements, SPUD protocol needs to provide the following functions: (1) Assist firewall to associate a set of packets to the same session, even though packets don't belong to but relate to the connection. (2) Provide enough traffic related information for firewall to maintain state for the traffic. (3) Indicate the start and stop of a session. (4) Provide a standard interface to firewall assisting firewall to deal with new transport protocol. 3.2. TCP Optimization TCP [RFC793] is a connection-oriented reliable transport protocol. Each TCP connection maintains state, usually in a data structure called the TCP Control Block (TCB), containing information about the connection state, such as RTT, MSS, congestion avoidance threshold. These parameters can be shared across connections to the same host, since they are in fact per-path (per-host-pair) dependent [RFC2140]. The goal of state sharing is to improve transient transport performance. However, these parameters cannot clearly reflect the state of a specific on-path network device, for example, the state of network bottleneck device on the path, which is very useful information for TCP for TCB initialization. If TCP could obtain the available bandwidth of the bottleneck device, it could adjust the maximum congestion window size based on the ideal window size, which can be calculated by "the bottleneck bandwidth * RTT". [I-D.sprecher-mobile-tg-exposure-req-arch] presents the similar use case, i.e. the requirements for a mobile throughput guidance exposure mechanism that can be used to assist TCP in cellular networks, ensuring better performance. SPUD can be used for path declarations: information delivered to the endpoints from devices along the path. Path declarations can be thought of as enhanced ICMP for transports using SPUD, allowing information about the condition or state of the path or the tube to be communicated directly to a sender. Therefore, this usage would enable the on-path network devices (e.g. gateway, router) to transmit their states (e.g. delay, packet loss rate, and bandwidth) to the transport layer. As the transport layer can obtain the state of the You & Wei Expires December 30, 2015 [Page 5] Internet-Draft Use Cases for SPUD June 2015 on-path devices, it could make use of this information to configure initial transport parameters. The objective is to optimize the behavior of transport protocols. Meanwhile, the network state could be shared across connections if they share the paths. The possible scenario is shown in Figure 1. +---------+ +---------+ |Transport| |Transport| |Layer |<--------------------------------------------->|Layer | +---+-----+ +----+----+ | | | | | ---------------------- | | ////////// Networks \\\\\\\\ | | /// \\\ | | /+--------+ +--------+ \ | | | |UDP|SPUD| +-------+ +-------+ |UDP|SPUD| | | +--+ +--------+ |on-path| |on-path| +--------+ +----+ | <---- |router | |router | ----> | \\\\\ +-------+ +-------+ //// \\\\\\\\\ //////// ---------------------- Figure 1: TCP Optimization Using SPUD From the analysis above, in order to improve transport performance, SPUD protocol needs to provide the following functions: (1) Provide the state (e.g. bandwidth, delay) of on-path network devices to the transport layer. 4. IANA Considerations This document has no actions for IANA. 5. Security Considerations For the use cases proposed in this document, the paritcipating entities need to have certain kind of trust relationships with each other. Meanwhile, the exposed information should be verifiable by each other. How to establish the trust relationship and how to verify the exposed information will be discussed in later versions of this document. You & Wei Expires December 30, 2015 [Page 6] Internet-Draft Use Cases for SPUD June 2015 6. Acknowledgement The authors would like to thank Mirja Kuehlewind and Michael Welzl for their comments. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997. [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", RFC 3124, June 2001. [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1980. [RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981. 7.2. Informative References [I-D.hardie-spud-use-cases] Hardie, T., "Use Cases for SPUD", draft-hardie-spud-use- cases-01 (work in progress), February 2015. [I-D.hildebrand-spud-prototype] Hildebrand, J. and B. Trammell, "Substrate Protocol for User Datagrams (SPUD) Prototype", draft-hildebrand-spud- prototype-03 (work in progress), March 2015. [I-D.sprecher-mobile-tg-exposure-req-arch] Jain, A., Terzis, A., Sprecher, N., Swaminathan, S., Smith, K., and G. Klas, "Requirements and reference architecture for Mobile Throughput Guidance Exposure", draft-sprecher-mobile-tg-exposure-req-arch-01 (work in progress), February 2015. Authors' Addresses You & Wei Expires December 30, 2015 [Page 7] Internet-Draft Use Cases for SPUD June 2015 Jianjie You Huawei 101 Software Avenue, Yuhua District Nanjing 210012 China Email: youjianjie@huawei.com Xinpeng Wei Huawei No. 3, Xin-Xi Rd., Haidian District Beijing 100095 China Email: weixinpeng@huawei.com You & Wei Expires December 30, 2015 [Page 8]