[saag] Last call feedback: draft-mm-wg-effect-encrypt

[Kathleen Moriarty <[e-mail]>]

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?

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.

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

>
> 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.

>
> 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!

>
> 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.

>
> 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.

>
> 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?

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