idnits 2.17.1 draft-liu-intarea-ps-protocol-auth-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 : ---------------------------------------------------------------------------- ** There are 25 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 (May 20, 2017) is 2504 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2234' is defined on line 213, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 217, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 222, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 227, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTAREA Working Group Z.Liu 2 Internet-Draft 3 Intended status: Informational Y.Cao 4 Expires: November 20, 2017 5 D.Liu 6 Alibaba Group 7 M.QI 8 China Mobile 9 Q.Sun 10 China Telecom 11 May 20, 2017 13 Problem Statement of Transport and Application Layer Protocols Providing 14 Traffic Authentication Capability to Internet Middlebox 15 draft-liu-intarea-ps-protocol-auth-00 16 Abstract 17 Transport and application layer protocol provides end-to-end 18 connectivity for clients and servers, but conveys limited or even no 19 information to a middlebox, such as Policy and Charging Control (PCC) 20 system, between the client and server. However, PCC needs to authenticate the 21 client-server traffic so that it can perform the basic functionality, i.e., 22 charging the client. 23 Due to lack of traffic authentication capability in transport and 24 application layer protocol, state-of-the-art PCC adopts Deep Packet 25 Inspection (DPI) to understand client-server communication and decide 26 whether to charge a client. However, in this draft, we show that current 27 transport layer protocol(TCP) and application layer(HTTP, TLS) protocol cannot 28 meet the need of traffic authentication, i.e., the user can modify the packet 29 and by pass the ISP PCC to have free ride. 30 Due to the existence of the aforementioned free-riding attacks, we 31 believe that Transport and application layer protocol needs to provide 32 traffic authentication capability to a middlebox. 33 In this draft, we describe free-riding attacks and present requirements 34 for providing traffic authentication. 36 Requirements Language 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 40 document are to be interpreted as described in [RFC2119]. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on November 20, 2017. 59 Copyright Notice 61 Copyright (c) 2014 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 75 1. Introduction ...................................................... 3 76 2. Test Scenario ....................................................... 3 77 3. Protocol Vulnerabilities .......................................... 4 78 3.1. HTTP ............................................................ 4 79 3.2. TLS ............................................................. 5 80 3.3. TCP Retransmission .............................................. 5 81 3.4. TCP TTL ......................................................... 5 82 3.5. DNS .............................................................. 5 83 4. Requirement for protocol in Policy and Charging Control ........... 6 84 4.1. Privacy Protection ............................................... 6 85 4.2. Integrity ....................................................... 6 86 4.3. Backward Compatibility ............................................ 6 87 5. Security Considerations ............................................ 6 88 6. IANA Considerations................................................. 6 89 7. References......................................................... 6 90 7.1. Normative References ............................................ 6 91 7.2. Informative References ............................................ 7 92 8. Acknowledgments ................................................... 7 94 1. Introduction 95 Internet service providers (ISPs) often offer so-called zero-rating 96 services, in addition to their normal charged ones, for contracted or 97 affiliated content providers to either attract more users or shift the 98 payment responsibility from users to corresponding CPs. 100 To recognize whether a client-server communication is zero-rated, the 101 policy and charging control (PCC) system of ISP uses use traffic 102 inspection techniques, such as Deep Packet Inspection, to parse packets 103 and match them against filter rules bound to specific policy and charging 104 control rules (PCC rules). 106 We discover that current transport layer and application layer 107 protocols (e.g., TCP, TLS, HTTP, HTTP over TLS) cannot offer adequate 108 support via DPI for the PCC system to securely support these services. 109 Moreover, the use of DPI in combination with PCC exposes the mobile ISP 110 to malicious attacker. 112 2. Test Scenario 113 We describe the attack model and test environment in this section. 115 We create several attacks intended to mislead the ISP PCC system. 117 The test beds consist of two man-in-the-middle proxies where a local 118 proxy at client-side is deployed between the application and the ISP to 119 modify the client traffic and an external proxy is deployed in between 120 the ISP and the content provider to forward the traffic to the real 121 content provider and compromise the packet integrity from the real 122 content provider. Consider a normal connection: a client application, 123 e.g., a browser or a mobile APP, connects to a content provider via an 124 ISP. The two man-in-the-middle proxies interact with the connection and 125 modify the packets using different protocol stacks. The basic test bed is 126 shown in figure 1. 128 We deployed the Internal Proxy in a local computer and tethered to a 129 mobile device and External Proxy in cloud data center. 130 +------+ +--------+ +-----+ +--------+ +--------+ 131 | | | | | | | | | | 132 |client+--->Internal|===> ISP |===>External+--->Content | 133 | | | Proxy | | | | Proxy | |Provider| 134 | | | | | | |Optional| | | 135 +------+ +--------+ +-----+ +--------+ +--------+ 136 figure 1 137 3. Protocol Vulnerabilities 138 In this section, we describe how to launch the attacks against real- 139 world ISPs to mislead the Policy and Charging Control System. 140 3.1. HTTP 141 HTTP protocol is plain text which can be easily inspected by ISP DPI. 142 We use the test bed in section 2. The Client establishes an HTTP with a 143 Content Provider A via ISP. Note, this Content Provider A is not a zero-rating 144 program participant and the traffic go through this connection should be 145 volumetrically charged to the user. 147 When client initializes an HTTP request, the internal proxy changes the 148 HTTP 'hostname' field to the zero-rating URL of Content Provider B. The 149 ISP inspects this URL of Content Provider B thus triggering the zero- 150 rating policy. Although the packet to Content Provider A is carrier 151 'hostname' B, it can still be routed to the A's server based on IP 152 address. 154 Note: but this could be easily fixed by having an additional check on 155 DNS to make sure the hostname field matches the dstIP. 156 The internal proxy and external proxy can connect with each other by 157 means of a tunnel to create a more complex model. 158 3.2. TLS 159 Because TLS Traffic is end-to-end encrypted, ISP cannot inspect content 160 by DPI. However, the TLS Server Name Indication (SNI) field in TLS Client 161 Hello Extension is in plain text and contains identification of the content 162 provider (Short URL). The ISP can inspect the SNI to identify the packet. 164 We discover that SNI field is changeable from the client side. We 165 create a test based on the test bed in section 2. When the client sends 166 out a non-zero-rating TLS Hello packet to Content Provider A, The 167 internal proxy modifies the SNI field with the Content Provider B which 168 belongs to a zero-rating program. The Result shows that ISP also zero- 169 rates the traffic to Content Provider A. 170 3.3. TCP Retransmission 171 Some ISPs do not charge a user's TCP Retransmission packet. The attack 172 can use the internal proxy to capture the Zero-rating TCP Retransmission 173 packet and reconstruct a new packet with non-zero-rating content and sent the 174 packets to the external proxy for redirection. 175 3.4. TCP TTL 176 The attacker can launch an overcharging attack by modifying the TCP TTL 177 on of the packet from server send to the client to drop the packet after ISP 178 charging without users' awareness. 179 3.5. DNS 180 TBD 182 4. Requirement for protocol in Policy and Charging Control 183 In this section, we discuss the requirement for future protocol design 184 in Policy and Charging Control. 185 4.1. Privacy Protection 186 In encrypted traffic, the protocol must contain values for traffic 187 identification but packets which are being inspected by the ISP DPI 188 should not expose the user's content. 190 4.2. Integrity 191 The protocol should preserve the packet integrity to prevent attacker 192 modifying the packet content (header or payload). 194 4.3. Backward Compatibility 195 The protocol should be backward compatible. First, it should be 196 supported by current router and switch devices. Second, it should not 197 require client and server application to upgrade to support. 199 5. Security Considerations 200 TBD 201 6. IANA Considerations 202 TBD 203 7. References 204 7.1. Normative References 205 [1]Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997. 207 [2]Crocker, D. and Overell, P.(Editors), "Augmented BNF for 208 Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and 209 Demon Internet Ltd., November 1997. 211 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 212 Requirement Levels", BCP 14, RFC 2119, March 1997. 213 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 214 Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon 215 Internet Ltd., November 1997. 216 7.2. Informative References 217 [3] Arash Molavi Kakhki, Fangfan Li, David Cho nes, Ethan Katz- 218 Bassett, and Alan Mislove. 2016. BingeOn Under the Microscope: 219 Understanding T-Mobiles Zero-Rating Implementation. In Proceedings of the 2016 220 Workshop on QoE-based Analysis and Management of Data Communication Networks 221 (Internet-QoE '16). ACM, New York, NY, USA, 43-48. https://doi.org/2940136. 222 [4] Younghwan Go, Denis Foo Kune, Shinae Woo, KyoungSoo Park, and 223 Yongdae Kim. 2013. Towards Accurate Accounting of Cellular Data for TCP 224 Retransmission. In Proceedings of the 14th Workshop on Mobile Computing 225 Systems and Applications (HotMobile '13). ACM, New York, NY, USA, Article 2, 6 226 pages. https://doi.org/10. 1145/2444776. 227 [5] 3rd Generation Partnership Project (3GPP). (2015). TS 23.203, 228 Policy and charging control architecture (Release 14). Available: 229 http://www.3gpp.org/DynaReport/23203.htm 231 8. Acknowledgments 232 TBD 234 Authors' Addresses 236 Zhiheng Liu 238 Email: liu.cmri@gmail.com 240 Yinzhi Cao 242 Email: Yinzhi.cao@lehigh.edu 244 Dapeng Liu 245 Alibaba Group 246 Email: maxpassion@gmail.com 248 Minpeng Qi 249 China Mobile 250 Email: loopypuzzle@hotmail.com 252 Qiong Sun 253 China Telecom 254 Email: sunqiong@ctbri.com.cn