Internet Engineering Task Force Attila Mihaly Internet-Draft Szilveszter Nadas Intended status: Informational Ericsson Expires: September 2015 March 9, 2015 Enablers for Transport Layer Protocol Evolution draft-mihaly-enablers-for-tlp-evolution-00.txt Abstract In this document we collected requirements for TLP evolution. These requirements are the consequence of removing obstacles of TLP evolution. This results in a higher variety of expected TLP implementations and lower trust level in these. Confidentiality of communication and security is more and more important. Middleboxes which today are one of the obstacles of the evolution shall be taken into account and incentivized to cooperate in the future landscape. Resulting from the requirements we propose areas for further investigation. 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 9, 2015. Mihaly Expires September 9, 2015 [Page 1] Internet-Draft Enablers for TLP evolution March 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. Table of Contents 1. Introduction...................................................3 1.1. Main obstacles to TLP evolution...........................3 1.1.1. Kernel-based TLP implementations.....................3 1.1.2. Middleboxes..........................................4 2. Requirements on the TLP framework..............................4 2.1. Enforce expected TLP behavior.............................4 2.2. Enable application access to TLPs.........................5 2.3. Allow for consistent TLP selection........................5 2.4. Allow the path influencing TLP selection..................5 2.5. Ensure expected TLP performance characteristics...........5 2.6. Ensure that the access providers can be part of the value chain..........................................................6 2.7. Ensure confidentiality of end-to-end communication........6 2.8. Ensure security of end-to-end communication...............6 2.9. Ensure user control.......................................7 3. Ideas for framework evolution..................................7 3.1. API definitions for TLP selection within the host.........7 3.2. Generic TLP related functions and APIs....................9 3.3. Mechanisms for consistent TLP selection...................9 3.4. Security solutions for multiple trust domains............10 3.5. In-band protocol for Middlebox communication.............10 4. On open source TLP implementations............................12 5. Related work..................................................12 6. Conventions used in this document.............................13 7. Security Considerations.......................................13 8. IANA Considerations...........................................13 9. Conclusions...................................................13 10. References...................................................14 10.1. Normative References....................................14 10.2. Informative References..................................14 Mihaly Expires September 9, 2015 [Page 2] Internet-Draft Enablers for TLP evolution March 2015 11. Acknowledgments..............................................15 1. Introduction In this document we collect requirements for TLP evolution. These requirements are the consequence of removing obstacles of evolution. Note that we are not after the requirements on the TLP development as such, but rather the requirements on the eco-system that allow fast evolution and deployment of new TLPs. When deriving the requirements we consider the interest of all actors: users, application developers, network operators, equipment vendors as well as operating system vendors to result in an infrastructure where cooperation between the parties becomes possible. The premise of all the discussion is that TLPs need to evolve, and potentially at a faster pace than it is allowed today. A few use cases are collected to demonstrate the potential need for many application and access network related TLP features that should be available in a flexible way[FLEX]. Based on the requirements, in the second part we discuss the new features that are needed and provide ideas to meet these requirements. 1.1. Main obstacles to TLP evolution The following obstacles were discussed at a related IAB workshop [SEMI]. 1.1.1. Kernel-based TLP implementations One problem with the innovation in the TLP area is that the transport protocols are currently implemented in the kernel. Kernel updates are generally slow. The proprietary TLP implementations that would require modifications of the existing transport protocols in the clients are therefore not usable. Each new modification needs to undergo a long standardization process, followed by a period until it is deployed in the operating systems. This process may take years. The solution to this problem, which is also observed today in some of the new TLP designs (QUIC, WebRTC), is that, instead of the kernel, they are implemented in the application space on the top of UDP. This is a way to speed up the innovation on the transport protocol layer in the current eco-system. Mihaly Expires September 9, 2015 [Page 3] Internet-Draft Enablers for TLP evolution March 2015 1.1.2. Middleboxes The ubiquitous deployment of middleboxes is another main reason of what is called the 'ossification' of the transport layer. Firewalls and NATs often inspect packets beyond the IP header and often drop packets based on port numbers or other identified protocol and application characteristics or, more commonly, because of non- identified protocol characteristics. The only 100 percent 'safe' protocol to be transmitted through middleboxes is HTTP and HTTPs over TCP. Even the UDP-based traffic is often dropped or policed. Note that there may be means to implement improved TLPs with framing format embedded over the TCP layer to avoid potential problems with middleboxes. However, this introduces additional complexity and overhead. Another, often neglected reason why the above approach is not advisable is that middleboxes and the policies they enforce have an important role in the eco-system. The internet is a critical infrastructure a number of services are using from emergency services to banking systems, which should therefore be protected against misbehaving protocols. Middleboxes that filter out unknown TLP implementations together with miss-behaving kernel-based TLP implementations are the means to keep the Internet stable. In conclusion, a solution is needed that lets the middleboxes not block user space TLP implementations but in a way that protects against miss-behaving TLPs. 2. Requirements on the TLP framework Overcoming the abovementioned obstacles need changes in the TLP framework. Also, when the above obstacles are overcome new requirements result from the changed ecosystem. 2.1. Enforce expected TLP behavior One conclusion that relates to both user space TLP implementations and new TLP behavior is that protection is needed against buggy and/or malicious TLP implementations. This serves the interest of all parties and has two aspects: . Protecting the other flows of the same user. . Protecting the other customers using the network domain from the potential negative effect of other traffic. One can always gain a lot of capacity in a shared network just by being Mihaly Expires September 9, 2015 [Page 4] Internet-Draft Enablers for TLP evolution March 2015 aggressive. If there are no regulating network mechanisms then both the overall network utility and fairness of assessing network resources are compromised. The behavior that needs to be verified in proprietary TLP implementations is e.g., congestion control aggressiveness, packet size, packet shaping. 2.2. Enable application access to TLPs Introducing a proprietary TLP causes a 'walled-garden' effect, i.e., the new protocol with the new features is only available for the services provided by the developer of the transport protocol. Commercialization of the new TLPs and re-usage of open-source implementations both support fast TLP innovation, but require that the new TLPs SHOULD be selectable by different applications. 2.3. Allow for consistent TLP selection While the previous requirement 2.2. relates to TLP selection within the host, this requirement states that the framework SHOULD allow for a consistent TLP selection for a given connection towards a certain remote host through certain legacy paths. That is, the finally selected TLP should be supported by the other endpoint as well as the network domains on the path. This is to guarantee interoperability during gradual deployment of new TLPs and their support in the network. 2.4. Allow the path influencing TLP selection Note that middleboxes on path may explicitly be part of the TLP selection process. They may favor the usage of certain TLPs because of some enhancement functions that they could offer (see discussion in 2.6. ) 2.5. Ensure expected TLP performance characteristics By TLP performance characteristics we mean the non-functional, i.e., performance-related TLP features. Interactions needed for the selection and usage of proper TLPs (including within-the-host interactions as well as interactions with the other party and the network domain) SHOULD not result in significant degradation of expected TLP performance characteristics. For example, if a transport protocol has been designed for low setup latency then this should be preserved by introducing a framework that achieves the above goals. Mihaly Expires September 9, 2015 [Page 5] Internet-Draft Enablers for TLP evolution March 2015 Note that the above requirement is strictly valid for the case when communicating to a known party through a known network domain. In other cases a more complex setup procedure (including e.g., the exchange of security credentials with the other party or the middlebox) may be needed. In some cases it MAY be also allowed that the very first session is delayed until a proper TLP is downloaded if one of the parties does not possess the required TLP. But such cases should be as rare as possible, e.g., a browser downloading the unsupported TLP once when first demand is encountered and then storing it for future usage. 2.6. Ensure that the access providers can be part of the value chain The framework SHALL allow access providers (ISPs and Mobile operators) provide a cooperative middlebox environment for user space TLP implementations. Middleboxes can generate value for the hosts in a number of different scenarios; we direct the reader to our recent position paper where we gave a summary of potential middlebox roles for Mobile Broadband [MBC]. Naturally, content providers and users who are not willing to participate in this cooperation and want to avoid any unwanted traffic manipulation by middleboxes MUST be able to do that. Also, the cooperation with middleboxes SHOULD be possible on different trust levels. When there is a high trust level in a middlebox, the middlebox should be able to access and manipulate higher layers, i.e., TLP or application layers. 2.7. Ensure confidentiality of end-to-end communication A valid demand from the end-users and content providers is that the eco-system SHALL allow for confidentiality of end-to-end communication. A trend in data communication is to encrypt everything including the transport layer and above. However, if middlebox communication requires access and manipulation of the TLP fields, then object security solutions are needed to guarantee confidentiality. 2.8. Ensure security of end-to-end communication The framework SHOULD also make all possible actions to avoid that a hostile entity along the path cannot cause any harm to the hosts by exploiting the flaws in the user space TLP implementations (at least not by using reasonable amount of processing resources). Unfortunately it is very hard to prepare TLP implementations to be robust against any harmful change in the protocol fields. Middlebox interaction may however require that some of the TLP fields can be accessed or modified by trusted middleboxes. Mihaly Expires September 9, 2015 [Page 6] Internet-Draft Enablers for TLP evolution March 2015 2.9. Ensure user control It SHOULD be possible allow the users to control TLP behavior. On the host side this means that the user may keep control on what TLP should be selected for a certain application. Moreover, it SHOULD be possible to control the transmission resource sharing between the different applications or streams. Otherwise, specific TLP behavior can override user expectations on the transmission resource sharing and this may cause unwanted effect on the user experience. Note that such resource sharing problems are also apparent today e.g., file sharing using a broadband access may cause bad Skype or video streaming experience. The above requirement also has relevance for Middlebox communication, i.e., the user SHOULD have the possibility to decide what information is sent out related to a certain application or TLP. 3. Ideas for framework evolution 3.1. API definitions for TLP selection within the host New APIs are needed to support a consistent TLP selection as specified in 2.3. Figure 1 depicts the new interfaces (shown by question marks) that a user space TLP suite brings in, in addition to the existing selection alternatives. Mihaly Expires September 9, 2015 [Page 7] Internet-Draft Enablers for TLP evolution March 2015 +---+ +---+ +---+ +---+ +----+ |APP| |APP| |APP| |APP| |APP | +-^-+ +-^-+ +-^-+ +-^-+ +----+ | | | | +----+ | | | | |TLP3| | +--v-------+ | | +-^--+ | |Middleware| | | | | +^------^--+ | | | | | | | | | | | | | | | | | +----v------------v----+ | | | | |Protocol Selection API| | | | | +^---------^-----------+ | | | | | | | ? | | | | | ? | | | | | +-------v--------------v-+ | | | | |(User Space TLPs) | | | | | | | | | | | | +----+ +----+ | | | | | | |TLP1| |TLP2| ... | | | | | | +----+ +----+ | | | | | +-+----+^--+----+--------+ | | | | | | | | | | ? | +-v-----v--v---------v----------------------v-+ | (Operating System) | | +---+ +---+ | | |TCP| |UDP| ... | | +---+ +---+ | +----------------------+---+---+---+----------+ Figure 1 : Transport protocol selection alternatives with User Space transport protocol implementations It is apparent that using middleware and high-level TLP selection APIs (like that proposed in [TAPS]) is advantageous for a framework involving user space TLPs since they separate application development from TLP development and make new, innovative TLP solutions possible also for legacy applications. However, direct selection of TPLs by the applications should also be possible. Low- level APIs to the new functions residing in the operating system are also needed (see discussion in 3.2. ) Mihaly Expires September 9, 2015 [Page 8] Internet-Draft Enablers for TLP evolution March 2015 3.2. Generic TLP related functions and APIs It is apparent that there is some generic functionality needed (i.e., transport layer functionality that applies on the top of the different user space TLP flavors) in order to fulfill the requirements in section 2. : . Resource control component for the total transmission resources in the host, to fulfill requirement 2.9. . Trust API that enforces a certain trust level, i.e., controls what different features and APIs a certain TLP has access to in the operating system. For example, some TLPs may control the resource control parameters, others not. This is needed because TLPs may be designed by different parties and not every TLP should be allowed to use all kernel functions. . API in the operating system for time-critical processing, e.g., packet shaping. Time-critical processing is one functionality that may only be done efficiently in the operating system . A common policing function (needed to fulfill the requirements in 2.1. and 2.9. on host side) . Congestion control communication component with standard framing on congestion control 'classes' (needed to fulfill the requirements in 2.1. and 2.9. on the network side) . Other middlebox communication component for exchanging information about the 'service' required (to support requirement 2.6. ) . A security function that verifies the different TLP implementations requested and downloaded from remote sources Note that there may be other common features and APIs required besides those listed above. It is FFS to identify all necessary functions. 3.3. Mechanisms for consistent TLP selection There is a need for fast TLP identification and negotiation mechanisms, which is derived from the requirements in 2.2. and 2.5. , respectively. The selection mechanisms may potentially involve middleboxes in the path. There can be many alternatives for this which is outside the scope of this document. The selection may include communication with a trusted part of code at the other end, which provides some proof about the TLP implementation. Mihaly Expires September 9, 2015 [Page 9] Internet-Draft Enablers for TLP evolution March 2015 3.4. Security solutions for multiple trust domains As stipulated in 2.8. , it is important that the TLP fields should not be easily changeable by nodes along the path because this can help exploiting bugs in a TLP implementation. A potential solution is to also authenticate the transport layer. However, network side enhancements on different layers could lead to improved end-to-end quality, as we discuss in 2.6. In some cases, this implies that the middleboxes should be able to modify information on the transport layer or above: transcoder proxies, parental control, TLP proxies translating between an 'old' and a 'new' TLP, etc. The conclusion from the above is that security solutions are needed that enable that different entities have access to the information at the different layers. If there is a hint on the expected capabilities of the other end on a certain layer, the setup messages for the different layers can be grouped together in order to speed up the connection establishment, in the spirit of requirement 2.5. 3.5. In-band protocol for Middlebox communication The smooth and fair networking so far has been highly aided by the TCP/IP "narrow-waist", i.e., the assumption that all sources use TCP-like congestion avoidance mechanisms. Misbehaving sources have been possible to identify because of the fact that TCP wire format (ACKs and sequence numbers) allows to identify both the congestion signal and the congestion avoidance action, i.e., how many data is sent upon the detection of packet losses. The proliferation of UDP- based traffic in the network with many new features with unknown and untested behavior could make even the simple traffic management that guarantees that all users get their share quite troublesome. Middleboxes may need to enforce expected behavior in the network domain because of conflicting interests, as specified in the requirement 2.1. A potential help in that is the identification of the expected congestion behavior of TLPs (e.g., congestion control used, constant bitrate flow, or chatty flow not adapting etc.) on the network side. We recognize that any information from hosts that would represent negative discrimination is useless, since all hosts would evidently use the indication that implies the best treatment. However this 'best treatment' is not obvious and the preferred congestion treatment depends on application needs. For example, an application using CBR-type of traffic would 'sacrifice' additional bandwidth (e.g., by a rate-limiter in the network) for zero packet loss provided by the network up to a certain congestion level. To fully avoid misuse of certain congestion indicators, the network should be able to ensure some kind of fairness for the different Mihaly Expires September 9, 2015 [Page 10] Internet-Draft Enablers for TLP evolution March 2015 congestion control mechanisms, to avoid scenarios where a certain congestion behavior indicated would take more resources than others over arbitrary period of time. By default, when there is no indication on the congestion control behavior used, the network could enforce a TCP-friendly behavior for the flow, without requiring any specific knowledge about TLP specifics (or apply a traffic treatment that result in comparable congestion 'volumes'. However, we foresee that new TLPs providing features tailored for specific application needs will have different congestion control behavior. For these flows the network may enforce a different congestion control behavior than default, given it receives the needed information. Middlebox communication shall be made in a way that does not impede TLP evolution, which is likely faster than middlebox evolution. This requires that the framework should not require that all middleboxes should know all details (e.g., frame structure) of the TLPs. This hints towards an in-band signaling solution as proposed in [SPUD], where a new independent layer is introduced for middlebox communication and where the parameters conveyed are independent from the specific TLP used, but rather standardized information pointing to a well-defined congestion behavior. Communication from the middlebox towards the hosts is motivated by the consistent TLP selection requirement 2.3. The end hosts may be informed about middlebox capability on coping with a certain TLP to be able to select a TLP that is supported by the network middleboxes too. In addition to communication about TLP congestion behavior, other TLP capabilities could be exchanged and negotiated with a middlebox in order to make use of some TLP enhancement functions. Such a middlebox signaling layer also allows the endpoint convey additional IP-layer (delay, loss targets, etc.) or application-layer (proxy, transcoding feature negotiation etc.) information about their traffic (if they want to) in order to enable additional services in the spirit of the requirement 2.6. However, to support these features, the framework should allow middleboxes to setup a signaling connection in-band using the already setup user plane connection in the end-to-end communication in an authenticated way to advertise their services and communicate to the endpoints in a secure way. Requirement 2.5. implies that the performance overhead of the above in-band signaling protocol should be minimal in the generic case, and the communication setup should be fast. Certain scenarios may be Mihaly Expires September 9, 2015 [Page 11] Internet-Draft Enablers for TLP evolution March 2015 exception to the rule, e.g., setting up communication to a new middlebox along a path, exchanging context to another middlebox due to handovers, etc. 4. On open source TLP implementations Open source implementation may facilitate TLP evolution. The user space TLP (feature) implementations become faster, allowing smaller players leverage on the existing features that are designed and validated by bigger players. This may be further facilitated by pre- agreed software design rules for TLPs. However, the eco-system should allow also for non-open source. Firstly, because nothing would prevent big players come out with their own user space implementations. Further, it creates a competitive eco-system allowing e.g., start-ups to design and commercialize new proprietary TLP implementations. This helps innovation. In conclusion, open source does not bring in any specific requirements to the eco-system compared to other user space implementations. However, there could be TLP designs that facilitate re-use of open source and thus contribute to faster TLP evolution. 5. Related work There is an on-going activity and WG in IETF targeting the definition of a transport-layer interface exposed to the applications, on which, instead of specifying a protocol, a 'transport service' is specified [TAPS]. The primary scope for the activity is to make it possible to select the best transport protocol implementation for the applications, i.e., to use the existing transport protocol implementations in the clients, which are currently never of seldom used. There is also an EU horizon 2020 activity proposal with similar scope proposing to solve issues for NAT traversal, Path MTU discovery and falling back to a semantically-equivalent service in the selection layer, i.e., completely hidden from the application [NEAT] . As mentioned above, TLP selection layers are advantageous since they separate application development from TLP development. However, they should consider the framework extensions identified in this document. The recently formed IAB program [SEMI] and resulting BoF discussions [SPUD] started from the very same understanding that middleboxes in the network have expectations on the packet and flow structures, Mihaly Expires September 9, 2015 [Page 12] Internet-Draft Enablers for TLP evolution March 2015 which block TLP evolution. The workshop held in January 2015 identified that a mechanism is needed for applications at the end as well as boxes along the path to explicitly declare their assumptions and intentions. The design goals identified in this document for such a communication are intended to serve as input to the protocol discussion. 6. Conventions used in this document 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 RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 7. Security Considerations We argue in 2.7. 2.8. and 3.4. that other means that end-to-end encryption mechanisms involving the transport layer are necessary to address middlebox communication and also ensure the confidentiality and integrity of end-to-end communication. Exposing additional information to kernel functions and also to the network middleboxes raises a number of security questions about what should be exposed, how should be exposed etc. The present document does not address these issues, but they should be talked in future framework discussions. 8. IANA Considerations This draft presently does not pose any requirements to IANA. 9. Conclusions In this document we collected requirements for TLP evolution. These requirements are the consequence of removing obstacles of evolution. This results in a higher variety of expected TLP implementations and lower trust level in these. With the evolved TLPs even better performance is expected. Confidentiality of communication and security is more and more important. Middleboxes which today are one of the obstacles of the evolution shall be taken into account and incentivized to cooperate in the future landscape. Mihaly Expires September 9, 2015 [Page 13] Internet-Draft Enablers for TLP evolution March 2015 Resulting from the requirements we have identified the following ideas for further investigation. . API definitions for TLP selection within the host . Generic TLP related functions and APIs . Mechanisms for consistent TLP selection . Security solutions for multiple trust domains . In-band protocol for Middlebox communication We would like to invite the community to complete this analysis based on potential missing pieces of the problem space to address, further requirements, or further design goals that are useful for fast TLP evolution. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [FLEX] Flexibility of Transport Layer Protocols: Problem Statement draft-mihaly-TP-flexibility-00.txt [TAPS] Transport Services Charter, https://datatracker.ietf.org/doc/charter-ietf-taps/ [NEAT] A New, Evolutive API and Transport Architecture for the Internet (NEAT), project proposal to Call ICT 5-2014 'Smart Networks and Novel Internet Architectures", on the Horizon 2020 Work programme [SEMI] IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI), http://www.iab.org/activities/workshops/semi/ [SPUD] A new BoF called 'Session Protocol for User Datagrams' (SPUD) is proposed for IETF92, see http://trac.tools.ietf.org/bof/trac/#Transport Stack. The background of it has been discussed in a recent IAB workshop 'Evolution in a Middlebox Internet' (SEMI), see https://www.iab.org/activities/workshops/semi/ Mihaly Expires September 9, 2015 [Page 14] Internet-Draft Enablers for TLP evolution March 2015 [MBC] Nadas, S. and Loreto, S: Middleboxes in Cellular Networks, position paper to SEMI WorkShop, https://www.iab.org/wp- content/IAB-uploads/2014/12/semi2015_nadas.pdf 11. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Copyright (c) 2015 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). Mihaly Expires September 9, 2015 [Page 15] Internet-Draft Enablers for TLP evolution March 2015 Authors' Addresses Attila Mihaly Ericsson H-1117 Budapest, Irinyi Jozsef u 4-20, Hungary Email: Attila.Mihaly@ericsson.com Szilveszter Nadas Ericsson H-1117 Budapest, Irinyi Jozsef u 4-20, Hungary Email: Szilveszter.Nadas@ericsson.com Mihaly Expires September 9, 2015 [Page 16]