INTAREA Working Group Z.Liu Internet-Draft Intended status: Informational Y.Cao Expires: November 20, 2017 D.Liu Alibaba Group M.QI China Mobile Q.Sun China Telecom May 20, 2017 Problem Statement of Transport and Application Layer Protocols Providing Traffic Authentication Capability to Internet Middlebox draft-liu-intarea-ps-protocol-auth-00 Abstract Transport and application layer protocol provides end-to-end connectivity for clients and servers, but conveys limited or even no information to a middlebox, such as Policy and Charging Control (PCC) system, between the client and server. However, PCC needs to authenticate the client-server traffic so that it can perform the basic functionality, i.e., charging the client. Due to lack of traffic authentication capability in transport and application layer protocol, state-of-the-art PCC adopts Deep Packet Inspection (DPI) to understand client-server communication and decide whether to charge a client. However, in this draft, we show that current transport layer protocol(TCP) and application layer(HTTP, TLS) protocol cannot meet the need of traffic authentication, i.e., the user can modify the packet and by pass the ISP PCC to have free ride. Due to the existence of the aforementioned free-riding attacks, we believe that Transport and application layer protocol needs to provide traffic authentication capability to a middlebox. In this draft, we describe free-riding attacks and present requirements for providing traffic authentication. 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]. Liu et al. Expires November 20, 2017 [Page 1] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 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." This Internet-Draft will expire on November 20, 2017. Copyright Notice Copyright (c) 2014 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. Liu et al. Expires November 20, 2017 [Page 2] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 Table of Contents 1. Introduction ...................................................... 3 2. Test Scenario ....................................................... 3 3. Protocol Vulnerabilities .......................................... 4 3.1. HTTP ............................................................ 4 3.2. TLS ............................................................. 5 3.3. TCP Retransmission .............................................. 5 3.4. TCP TTL ......................................................... 5 3.5. DNS .............................................................. 5 4. Requirement for protocol in Policy and Charging Control ........... 6 4.1. Privacy Protection ............................................... 6 4.2. Integrity ....................................................... 6 4.3. Backward Compatibility ............................................ 6 5. Security Considerations ............................................ 6 6. IANA Considerations................................................. 6 7. References......................................................... 6 7.1. Normative References ............................................ 6 7.2. Informative References ............................................ 7 8. Acknowledgments ................................................... 7 1. Introduction Internet service providers (ISPs) often offer so-called zero-rating services, in addition to their normal charged ones, for contracted or affiliated content providers to either attract more users or shift the payment responsibility from users to corresponding CPs. To recognize whether a client-server communication is zero-rated, the policy and charging control (PCC) system of ISP uses use traffic inspection techniques, such as Deep Packet Inspection, to parse packets and match them against filter rules bound to specific policy and charging control rules (PCC rules). We discover that current transport layer and application layer protocols (e.g., TCP, TLS, HTTP, HTTP over TLS) cannot offer adequate support via DPI for the PCC system to securely support these services. Moreover, the use of DPI in combination with PCC exposes the mobile ISP to malicious attacker. 2. Test Scenario We describe the attack model and test environment in this section. We create several attacks intended to mislead the ISP PCC system. Liu et al. Expires November 20, 2017 [Page 3] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 The test beds consist of two man-in-the-middle proxies where a local proxy at client-side is deployed between the application and the ISP to modify the client traffic and an external proxy is deployed in between the ISP and the content provider to forward the traffic to the real content provider and compromise the packet integrity from the real content provider. Consider a normal connection: a client application, e.g., a browser or a mobile APP, connects to a content provider via an ISP. The two man-in-the-middle proxies interact with the connection and modify the packets using different protocol stacks. The basic test bed is shown in figure 1. We deployed the Internal Proxy in a local computer and tethered to a mobile device and External Proxy in cloud data center. +------+ +--------+ +-----+ +--------+ +--------+ | | | | | | | | | | |client+--->Internal|===> ISP |===>External+--->Content | | | | Proxy | | | | Proxy | |Provider| | | | | | | |Optional| | | +------+ +--------+ +-----+ +--------+ +--------+ figure 1 3. Protocol Vulnerabilities In this section, we describe how to launch the attacks against real- world ISPs to mislead the Policy and Charging Control System. 3.1. HTTP HTTP protocol is plain text which can be easily inspected by ISP DPI. We use the test bed in section 2. The Client establishes an HTTP with a Content Provider A via ISP. Note, this Content Provider A is not a zero-rating program participant and the traffic go through this connection should be volumetrically charged to the user. When client initializes an HTTP request, the internal proxy changes the HTTP 'hostname' field to the zero-rating URL of Content Provider B. The Liu et al. Expires November 20, 2017 [Page 4] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 ISP inspects this URL of Content Provider B thus triggering the zero- rating policy. Although the packet to Content Provider A is carrier 'hostname' B, it can still be routed to the A's server based on IP address. Note: but this could be easily fixed by having an additional check on DNS to make sure the hostname field matches the dstIP. The internal proxy and external proxy can connect with each other by means of a tunnel to create a more complex model. 3.2. TLS Because TLS Traffic is end-to-end encrypted, ISP cannot inspect content by DPI. However, the TLS Server Name Indication (SNI) field in TLS Client Hello Extension is in plain text and contains identification of the content provider (Short URL). The ISP can inspect the SNI to identify the packet. We discover that SNI field is changeable from the client side. We create a test based on the test bed in section 2. When the client sends out a non-zero-rating TLS Hello packet to Content Provider A, The internal proxy modifies the SNI field with the Content Provider B which belongs to a zero-rating program. The Result shows that ISP also zero- rates the traffic to Content Provider A. 3.3. TCP Retransmission Some ISPs do not charge a user's TCP Retransmission packet. The attack can use the internal proxy to capture the Zero-rating TCP Retransmission packet and reconstruct a new packet with non-zero-rating content and sent the packets to the external proxy for redirection. 3.4. TCP TTL The attacker can launch an overcharging attack by modifying the TCP TTL on of the packet from server send to the client to drop the packet after ISP charging without users' awareness. 3.5. DNS TBD Liu et al. Expires November 20, 2017 [Page 5] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 4. Requirement for protocol in Policy and Charging Control In this section, we discuss the requirement for future protocol design in Policy and Charging Control. 4.1. Privacy Protection In encrypted traffic, the protocol must contain values for traffic identification but packets which are being inspected by the ISP DPI should not expose the user's content. 4.2. Integrity The protocol should preserve the packet integrity to prevent attacker modifying the packet content (header or payload). 4.3. Backward Compatibility The protocol should be backward compatible. First, it should be supported by current router and switch devices. Second, it should not require client and server application to upgrade to support. 5. Security Considerations TBD 6. IANA Considerations TBD 7. References 7.1. Normative References [1]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2]Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. Liu et al. Expires November 20, 2017 [Page 6] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 7.2. Informative References [3] Arash Molavi Kakhki, Fangfan Li, David Cho nes, Ethan Katz- Bassett, and Alan Mislove. 2016. BingeOn Under the Microscope: Understanding T-Mobiles Zero-Rating Implementation. In Proceedings of the 2016 Workshop on QoE-based Analysis and Management of Data Communication Networks (Internet-QoE '16). ACM, New York, NY, USA, 43-48. https://doi.org/2940136. [4] Younghwan Go, Denis Foo Kune, Shinae Woo, KyoungSoo Park, and Yongdae Kim. 2013. Towards Accurate Accounting of Cellular Data for TCP Retransmission. In Proceedings of the 14th Workshop on Mobile Computing Systems and Applications (HotMobile '13). ACM, New York, NY, USA, Article 2, 6 pages. https://doi.org/10. 1145/2444776. [5] 3rd Generation Partnership Project (3GPP). (2015). TS 23.203, Policy and charging control architecture (Release 14). Available: http://www.3gpp.org/DynaReport/23203.htm 8. Acknowledgments TBD Liu et al. Expires November 20, 2017 [Page 7] Internet-Draft draft-liu-intarea-ps-protocol-auth-00 May 2017 Authors' Addresses Zhiheng Liu Email: liu.cmri@gmail.com Yinzhi Cao Email: Yinzhi.cao@lehigh.edu Dapeng Liu Alibaba Group Email: maxpassion@gmail.com Minpeng Qi China Mobile Email: loopypuzzle@hotmail.com Qiong Sun China Telecom Email: sunqiong@ctbri.com.cn Liu et al. Expires November 20, 2017 [Page 8]