Network management of encrypted traffic.docx

1、Network management of encrypted trafficNetwork management of encrypted trafficTechnical mitigations and business impacts GSMA ENCRY sub-group for PSMC Encryption Task Force Draft DateChange log0.128th July 2014Initial skeleton0.229th July 2014List of mitigations, Audience and purpose0.329th July 201

2、4Comments from WG call0.411th August 2014Technical solution details added, use case appendix added0.514th August 2014Changes following ENCRY #2 call: changed sections to Existing mitigations and Mitigations under investigation. Added new mitigations. Removed perspectives section and added sub-sectio

3、n in each mitigation to indicate the use cases affected. ContentsAudience and purpose of document 3Whats out of scope 3A note on terminology 3Background reading 3List of mitigations and impact analysis 3Existing mitigations 3Google Canary URL 3Google Proxy Bypass 5Heuristics 6HTTPS Server Name Indic

4、ation extension 6Mobile operating system filters 7Filtering apps (device-based) 7Filtering browsers 8Traffic management at lower network layers 8Mitigations under investigation 9Network proxy proposals 9Encouraging uptake of HTTP/2 without transport layer encryption 9Object Level Encryption: 10Filte

5、ring-apps (centralised ) 10Filtering with per-service permission 10List of strategies that are not recommended (out of scope) 10Table showing which mitigations apply to which use cases 11Recommendations 11Appendix A: Categorisation of use cases 11Use-cases out-of-scope for this paper 12Audience and

6、purpose of documentThe audience of the document is intended to be technical architects with knowledge of the operator network traffic management functions; browser vendors; middleware/proxy vendors. Information on non-technical (or non-network impacting) workarounds is also provided.The document cap

7、tures the mitigations identified to ensure that operators can execute on their traffic management requirements, as identified in the proxy use case document, . These use cases have been nroadly categorised, and each mitigation will indicate the category of use case that is applies to. Where a mitiga

8、tion involves a technical integration at the network, then that information is detailed.Whats out of scopeA range of use cases are listed, but this document makes no assumption as to whether they are relevant or mandatory for a given operator that is a per-operator decision.For this paper, non-mobil

9、e networks are out of scope, however a future version may consider fixed networks (whether directly connected or via a WiFi hub).A note on terminologyMitigation is used throughout this document, and refers to a method of supporting a particular use case when traffic is encrypted. To be clear, we are

10、 not trying to say that encryption is bad or should be stopped, rather that there is an impact on existing traffic management practices.A mitigation does not simply imply network-based software or policy enforcement, it may also include device-based alternatives or external industry efforts that sup

11、port both encryption and certain traffic management requirements.Background readingPlease see List of mitigations and impact analysisExisting mitigationsGoogle Canary URLReference documentation: Description: a single, unencrypted HTTP request is made by the Chrome for Mobile browser at startup and i

12、f the device changes networks (e.g. from WiFi to cellular). This request may be trapped by the network depending on the networks HTTP response, Chrome will or will not create an encrypted tunnel to the Google DCP (Data Compression Proxy). Therefore the network is in control of enabling or rejecting

13、encryption for a specific user.Scope: Google Chrome for Mobile users that have selected Reduce Data Usage setting, and intended to allow encryption to be disabled on a per-user basis. Google do not document when the network may reject or enable encryption: an example usage is to disable encryption f

14、or users not proven to be adults. Note that Google Data Compression Proxy optimisations still occur even if the content is not encrypted.Integration: Two processes are required1. Detect the request from the Chrome for Mobile browser. The requested URL is . This will travel unencrypted through to the

15、 Packet Data Network Gateway (PDN-GW in LTE, or equivalent in other networks) therefore could be trapped at several nodes, however point (2) below will dictate the optimal node for a given network.2. Determine any policy rules for the requesting userThis requires that the node performing (1) above h

16、as access to the requesting users identity, and the ability to lookup policy rules set for that identity (or groups that the identity is a member of). In practice this can mean a lookup to a PCRF (Policy Charging Rules Function) interface, passing the user identity, or to the Home Location Register

17、or any Customer Relationship Management system that categorises users. The user identity may have been extracted from either an HTTP request header, or from an additional lookup (such as IMSI lookup based on allocated IP address of the terminal). Should this process determine any policy rules applyi

18、ng to the requesting user, then the system will decide whether the rule(s) can allow or disallow encryption to occur. Example:Example_Operator categorises all customers as either child (the default) or adult. The customer must present credentials to the retail store to achieve adult categorisation.U

19、ser Ch is a child and user Ad is an adult connected to the Example_Operator network. Both use Google Chrome for Mobile, and have set Reduce Data Usage in their settings. When they start the browser, process (1) and (2) described above occurs, with the result:User Ch receives the HTTP response 403 Fo

20、rbidden from the Example_Operator network. This means that the Chrome for Mobile traffic may still utilise the Google DCP but encryption will not occur. Hence Example_Operator has visibility of the HTTP traffic en route to the Google DCP, and content filters for adult content can be applied.User Ad

21、receives the response HTTP 200 OK from the Example_Operator network. Hence Chrome for Mobile initiates an encrypted tunnel to the Google DCP, and Example_Operator network will not filter for adult content delivered over this tunnel.Notes:It is not clear whether a blanket rule of no encryption for al

22、l users is supported by Google (in other words, whether the Canary URL test can be failed in all cases).Mitigates the use cases:“Regulatory filtering”, “parental control”, “customer malware protection” when applied to child vs. adult SIMs, but only for traffic proxied by the Google DCP. I.e. http ov

23、er TLS requests made by Chrome for Mobile browsers with the DCP activated.Google Proxy BypassReference documentation: Description: a blacklist hosted at the Google DCP. Populated by Google based on operator submissions.Scope: Google Chrome for Mobile users that have selected Reduce Data Usage settin

24、g. Differs from the Canary URL process in that it is intended to be applied across all users, rather than a specific user or group.Integration: The operator is required to submit a list of URLs to Google that they wish to bypass the DCP. This submission is an offline-process; operators should submit

25、 URLs to their Google contact for attention of the DCP team to implement. Once the bypass URLs have been integrated at Google, then the following behaviour is expected:1. The Google DCP will detect any request to this URL2. Google will suspend encryption for a period of 1 to 5 minutes between the re

26、questing Chrome for Mobile browser and the DCP3. The DCP will respond to the Chrome for Mobile browser and make it reissue the request unencrypted.4. This will allow operator filters to detect the request and act accordingly.Example: Example_Operator provides several service portals for their mobile

27、 customers. These are hosted within their network (rather than the public Internet) in order to provide seamless authentication and lookup of sensitive customer data. HTTP requests to these portals are routed by Example_Operator s DNS service: therefore the portal URIs must be submitted to the Googl

28、e Proxy Bypass list, since a Google DNS will not be able to route to them.Notes: Note that by default Google bypass the proxy for international blacklists, namely the Internet Watch Foundation list (child abuse materials). The documentation mentions that national court order lists are also included,

29、 however gaps have been identified in these lists, possibly because Google may not be party to blocking issued by national telecoms regulators. Therefore operators are encouraged to determine the result of Google DCP usage when such court order blocked URIs are requested (for example, offshore gambl

30、ing sites). Mitigates the use cases:“Regulatory filtering”, “MNO Services” but only for traffic proxied by the Google DCP. I.e. http over TLS requests made by Chrome for Mobile browsers with the DCP activated.Heuristicso editor note: volunteer needed for this section!HTTPS Server Name Indication ext

31、ensionReference documentation: “Transport Layer Security (TLS) Extensions: Extension Definitions”, http:/tools.ietf.org/html/rfc6066#page-6Description: When initiating the TLS handshake, the Client MAY provide an extension field (server_name) which indicates the server it is attempting a secure connection with.Scope: All TLS connections that include a server_name exten