Internet DRAFT - draft-liu-intarea-ps-protocol-auth
draft-liu-intarea-ps-protocol-auth
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]
