ietf
[Top] [All Lists]

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

2017-03-10 01:36:17
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' 
<kathleen(_dot_)moriarty(_dot_)ietf(_at_)gmail(_dot_)com>; 
'saag(_at_)ietf(_dot_)org' <saag(_at_)ietf(_dot_)org>; 
'ietf(_at_)ietf(_dot_)org' <ietf(_at_)ietf(_dot_)org>
Cc: 'ALFRED C MORTON (AL)' <acmorton(_at_)att(_dot_)com>; 'stephen. farrell' 
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
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:kathleen(_dot_)moriarty(_dot_)ietf(_at_)gmail(_dot_)com]
Sent: Wednesday, March 08, 2017 2:18 PM
To: saag(_at_)ietf(_dot_)org
Cc: Badri Subramanyan <Badri(_dot_)Subramanyan(_at_)ril(_dot_)com>; ALFRED C 
MORTON (AL) <acmorton(_at_)att(_dot_)com>; stephen. farrell 
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
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, "Badri(_dot_)Subramanyan(_at_)ril(_dot_)com"
<Badri(_dot_)Subramanyan(_at_)ril(_dot_)com> 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."

<Prev in Thread] Current Thread [Next in Thread>