RE: Last call feedback: draft-mm-wg-effect-encrypt

[<[e-mail]>]

Kathleen/Al,

	I have included additional information inline. Please let me know if you need additional information.

Thanks,
Badri

-----Original Message-----
From: Badri Subramanyan 
Sent: Thursday, March 09, 2017 8:19 AM
To: 'Kathleen Moriarty' <[e-mail]>; '[e-mail]' <[e-mail]>; '[e-mail]' <[e-mail]>
Cc: 'ALFRED C MORTON (AL)' <[e-mail]>; 'stephen. farrell' <[e-mail]>
Subject: RE: Last call feedback: draft-mm-wg-effect-encrypt

Kathleen/Al,

	Thanks for the clarification. I have included my comments inline. 
	I am still looking for references and will send it out as I find them.

Thanks,
Badri

-----Original Message-----
From: Kathleen Moriarty [mailto:[e-mail]]
Sent: Wednesday, March 08, 2017 2:18 PM
To: [e-mail]
Cc: Badri Subramanyan <[e-mail]>; ALFRED C MORTON (AL) <[e-mail]>; stephen. farrell <[e-mail]>
Subject: Last call feedback: draft-mm-wg-effect-encrypt

Hello Badri,

Thank you very much for your review and feedback on the draft.  This is very helpful to add in your perspective.  I do have a few questions in line and am hoping you have some good references for us to cite as well.  We need to get a draft revision out by Friday, so hopefully we can iterate quickly.


>
> On Feb 23, 2017, at 9:54 AM, "[e-mail]"
> <[e-mail]> wrote:
>
> Hello,
>
>
>
>                 I work for a Mobile Service Provider and wanted to 
> start by thanking you for putting this document together (Effects of 
> Pervasive Encryption). Encryption of content has been impacting the 
> service providers for sometime, and this document outlines it very 
> well. I had a few comments/suggestions on the document. This documents 
> is comprehensive, but there are a few impacts more specific to Mobile 
> Carriers which I thought were not included. I would greatly appreciate 
> it, if you could look into these and modify the document as suited.
>
>
>
> 1.       ALG – Application Layer Gateway, is a feature used by Firewalls,
> NAT boxes and Load Balancers to identify streams which are related and 
> treat them alike. Many of the protocols work in conjunction to deliver a service.
> Eg. RTSP/RTCP/RTP protocols are used to provide video service. RTSP 
> uses TCP and negotiates the UDP ports used for RTP and RTCP 
> communication. RTSP and RTCP form the control plane, when RTP forms the data plane.
>
> a.       The ALG feature makes the Firewall application-aware and allow or
> block a video content as desired.
>
> b.      This feature is also used as of today on the Firewall or NAT box.
> The scenario here is, the FW/NAT box acts as a demarcation point 
> between the DMZ and untrusted network, which allows out bound traffic 
> and any flow initiated from within the DMZ. When we have service with 
> multiple flows, some of these could be initiated from within the DMZ, 
> which should enable other flows in both directions. Eg. RTSP Request 
> from within the DMZ would need to allow RTP packets from the untrusted 
> zone into the DMZ. The FW/NAT box can only allow this if they are 
> aware of the co-relation between the different flows using feature like ALG.
>
> c.       The ALG feature on a LB similarly would allow the identification of
> the different co-related flows and treat them alike – allow, block, LB 
> them to the same server or re-route to another set of servers.
>
> If the streams are encrypted, then the ALG feature would be rendered 
> useless. This would limit the capability of any network element to 
> make smart policing and routing decisions based on application layer attributes.

Do you know if these can work with a 2-tuple or 5-tuple?  Is there an impact from encryption via TLS for instance?  If so, what is that impact?
[Badri] The rules in most of the cases is 5-tuple to accurately depict a flow. Yes, there is an impact from encryption via TLS as most of the implementations of ALG get information regarding supporting protocols by parsing data. With TLS encryption, the ALG loses the ability to parse, hence get information on the supporting protocols.

What is used by ALG to correlate streams?  This would be helpful to understand if this particular method for ALGs does become 'useless'
and also to figure out if other options may exist to perform the functions needed.
[Badri] RFC 2663, Section 2.9 gives information about ALG. There isn’t one defined method to implement it and some of the methods used by vendors are included below.
1.  Parse the content of the primary stream and identify the 5-tuple of the supporting streams as it is being negotiated.
2. Intercept and modify the 5-tuple information of the supporting stream as the it is being negotiated on the primary stream. This is a little more intrusive in nature.

Do you have references on this that are stable (ones we can cite in an RFC)?
RFC 2663, Section 2.9

I have also spelled out some of the acronyms below RTSP - Real Time Streaming Protocol RTCP - Real Time Control Protocol RTP - Real Time Protocol ALG - Application Level Gateway/Application Layer Gateway LB - Load Balancers DMZ - Demilitarized Zone FW - Firewall

>
> 2.       Over-The-Top Caching web content – You did touch upon this topic in
> section 2.1.4, but I think this is a big enough topic that it warrants 
> its own subsection. As the Internet traffic increases across the 
> world, Mobile Carriers and other Service Providers are using caching 
> solution to keep up with the bandwidth needs. Caching at a high level 
> would allow for web/video and other caches to be located closer to the 
> customers. The first time a content is requested, it is stored in the 
> cache and every request going forward would be served from the cache 
> thus cutting down on the backhaul tonnage between the source of the 
> content and the cache. This not only helps in cutting down on the 
> bandwidth requirements, but also cuts down on the latency with quicker time to first byte and improves customer experience.
> Mobile Carriers are deploying caches closer to the customers, thus 
> cutting down latency drastically. These caches play an even more 
> significant role when the latency to the destination is very high, eg:
> Mobile carrier is located in the Asia, but the source content is located in US or vice versa.
> This also helps mobile carriers located outside of US, to cut down on 
> their Internet traffic to the US, which directly translates to 
> savings. The cache server uses information in the HTTP headers, 
> payload and other attribute to make the effective caching decisions.
> As we move to encryption the cache server does not have this information, rendering them useless.

Do you have references on this trend?  It would be good if we can cite a resource as we also heard at the MARNEW workshop that some content carriers prefer end-to-end solutions.  In that case, caching wouldn't work anyway.  If there are trends in both directions, it would be good to cite resources.
Caching helps in reducing Latency and Internet bandwidth for the a Mobile Carrier, which is the basis of HTTP Caching as described in RFC 7234. Let me check to see if there are any white papers which talk about this trend of using OTT Caches...
RFC 7234 gives information on HTTP Caching and the expected benefits. The Internet Protocol Journal published by Cisco also contains information on web caching and its benefit (http://www.cisco.com/c/dam/en_us/about/ac123/ac147/archived_issues/ipj_2-3/ipj_2-3.pdf) . The following article also talks about proxy and caching on the mobile carrier networks - https://nsl.cs.usc.edu/~jyr/papers/90818.pdf
>
> 3.       HTTP header enrichment – HTTP header enrichment has been a
> mechanism for the mobile carrier to provide “allowed” (Non-CPNI) 
> subscriber information to third parties or other internal systems. The 
> third parties can in turn provide customized service, or use it to 
> bill the customer or allow/block selective content…. This 
> header-enrichment method is also used within the Mobile Carrier to 
> pass information internally between sub-systems, thus keeping the 
> internal systems loosely-coupled. With encryption, the mobile carrier 
> loses the capability to include any information in the content itself 
> as it is encrypted, making it impossible for the mobile carrier to pass on the information in any HTTP headers.

A reference would be helpful, thanks!
[Badri] RFC 7230 allows of addition and use of new headers in section 3.2 (3.2.1 specifically). Initially custom headers prepended the value "x-" to the header name. Even though this practice was deprecated in RFC 6648, these header are still widely used to maintain support for legacy systems. The paper "Header Enrichment or ISP Enrichment?" (https://www.icir.org/vern/papers/header-enrichment-hotmiddle15.pdf) talks about the use of this feature across different Mobile Carriers. This paper also gets into the vulnerability of using this mechanism, if customer privacy information is sent over the internet. 

>
> 4.       HTTP Redirection – As of today the Mobile Carrier would need to
> block or redirect a customer for multiple reasons

>
> a.       The customer may not be allowed to view the content due to parental
> controls.

OK, so you have the information to block, but no ability to redirect in this case.

[Badri] Yes, that the exactly the scenario. The mobile provider has the destination domain/IP Address from the Customer request and identifies this domain as a blocked domain under Parental control.

>
> b.      The customer  may not be allowed to view the content as they have
> not purchased the content.

Wouldn't this be a server-side decision anyway?  In that case, TLS makes no difference.
[Badri] The particular scenario I was referring to is where the customer is charged by the Mobile Carrier on behalf of the content provider. As an example a customer buys a streaming service from the mobile provider, which allows the customer to stream video content from the video provider. The customer gets a single bill from the Mobile provider, and the Mobile provider has a rev-share model with the video provider. This is method is used by Mobile providers and content partners to promote each other and in return the customer get the convenience of one bill as compared to different bill from each content partner.
>
> c.       The customer may not be allowed as they have reached their usage
> limit and need to buy additional data.
>
> Currently, the Mobile carrier redirects the customer using HTTP 
> redirect to a page which educates the customer on the reason for the 
> blockage and provide steps to proceed. Once the content is encrypted, 
> the Mobile carrier loses the option to redirect the traffic and the 
> only option being to block the customer, for all scenarios. This would 
> not only cause bad customer experience, but would also need another 
> way to pass on the additional information to the customer – text 
> message. If for any reason, the customer is not able to find the 
> information, he/she would have to call customer care to find out the 
> reason. This is not only an inconvenience to the customer, but also an overhead to the service provider.
>
>

This is reasonable to add.  Do you have a reference we can cite on the practices?
[Badri] These are practices that have been followed in the industry, but don’t know if they have been published anywhere. I will check and get back to you.

Thank you!
Kathleen
>
>                 Please feel free to get back to me if you have any 
> questions.
>
>
>

> Thanks,
>
> Badri
>
> Reliance Jio
>
>
> "Confidentiality Warning: This message and any attachments are 
> intended only for the use of the intended recipient(s), are 
> confidential and may be privileged. If you are not the intended 
> recipient, you are hereby notified that any review, re-transmission, 
> conversion to hard copy, copying, circulation or other use of this 
> message and any attachments is strictly prohibited. If you are not the 
> intended recipient, please notify the sender immediately by return 
> email and delete this message and any attachments from your system.
>
> Virus Warning: Although the company has taken reasonable precautions 
> to ensure no viruses are present in this email. The company cannot 
> accept responsibility for any loss or damage arising from the use of 
> this email or attachment."



-- 

Best regards,
Kathleen

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."