[saag] feedback for draft-mm-wg-effect-encrypt

["Smith, Kevin, (R&D) Vodafone Group" <[e-mail]>]

Hi Kathleen,

As discussed at MaRNEW[1] , here are two sections of draft-smith-encrypted-traffic-management-03[2] which can be added to 'Effect of Ubiquitous Encryption' [3] . Once agreed,  I can remove the same text from [2] and simply point to the relevant section in [3]; and hence [2] will focus on solutions to persist traffic management for encrypted traffic (whilst maintaining privacy/security). 

Many thanks
Kevin

[1] https://www.iab.org/activities/workshops/marnew/ 
[2] http://tools.ietf.org/html/draft-smith-encrypted-traffic-management-03 
[3] https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ 

---------------------------------------------------------------------------
Additions for draft-mm-wg-effect-encrypt
---------------------------------------------------------------------------
{for section 2.1: new sub-section}

Access and policy enforcement

   Server load balancing

   Where network load balancers have been configured to route according
   to application-layer semantics, an encrypted payload is effectively
   invisible. This has resulted in practices of intercepting TLS in front
   of load balancers to regain that visibility, but at a cost to
   security and privacy.

   Network access

   Approved access to a network is a prerequisite to requests for
   Internet traffic - hence network access, including any authentication
   and authorisation, is not impacted encryption. 

   Cellular networks often sell tariffs that allow free-data access to
   certain sites, known as 'zero rating'.  A session to visit such a
   site incurs no additional cost or data usage to the user. This feature
   may be impacted if encryption hides the domain from the network.   

   Regulation and policy enforcement
   
   Mobile networks (and usually ISPs) operate under the regulations of their 
   licencing government authority. These regulations include Lawful Intercept, 
   adherence to Codes of Practice on content filtering, and application of court order filters.  
   These functions are impacted by encryption, typically
   by allowing a less granular means of implementation.  The enforcement
   of any Net Neutrality regulations is unlikely to be affected by
   content being encrypted.

   SPAM and malware filtering

   This has typically required full access to application data to filter
   various keywords, fraudulent headers and virus attachments.
   
   
  {New top level section} 
  
  Flow information visible to a network

   IP 5-tuple

   This indicates source and destination IP addresses/ports and the
   transport protocol.  This information is available during TLS, TCP-
   layer encryption (except ports), and IP-layer encryption (IPSec);
   although it may be obscured in Tunnel mode IPSec.

   This allows network management at a coarse IP-source level, which
   makes it of limited value where the origin server supports a blend of
   service types.

   TLS Server Name Indication

   When initiating the TLS handshake, the Client may provide an
   extension field (server_name) which indicates the server to which it
   is attempting a secure connection.  TLS SNI was standardized in 2003
   to enable servers to present the "correct TLS certificate" to clients
   in a deployment of multiple virtual servers hosted by the same server
   infrastructure and IP-address.  Although this is an optional
   extension, it is today supported by all modern browsers, web servers
   and developer libraries.  Notable exceptions are Android 2.2 and
   Internet Explorer 6 on Windows XP.  It should be noted that HTTP/2
   introduces the Alt-SVC method for upgrading the connection from
   HTTP/1 to either unencrypted or encrypted HTTP/2.  If the initial
   HTTP/1 request is unencrypted, the destination alternate service name
   can be identified before the communication is potentially upgraded to
   encrypted HTTP/2 transport.  HTTP/2 implementations MUST support the
   Server Name Indication (SNI) extension.

   This information is only visible if the client is populating the
   Server Name Indication extension.  This need not be done, but may be
   done as per TLS standard.  Therefore, even if existing network
   filters look out for seeing a Server Name Indication extension, they
   may not find one.  The per-domain nature of SNI may not reveal the
   specific service or media type being accessed, especially where the
   domain is of a provider offering a range of email, video, Web pages
   etc.  For example, certain blog or social network feeds may be deemed
   'adult content', but the Server Name Indication will only indicate
   the server domain rather than a URL path to be blocked.

   Application Layer Protocol Negotiation (ALPN)

   ALPN is a TLS extension which may be used to indicate the application
   protocol within the TLS session.  This is likely to be of more value
   to the network where it indicates a protocol dedicated to a
   particular traffic type (such as video streaming) rather than a
   multi-use protocol.  ALPN is used as part of HTTP/2 'h2', but will
   not indicate the traffic types which may make up streams within an
   HTTP/2 multiplex.
  
   Content length, bitrate and pacing
   
   The content length of encrypted traffic is effectively the same as 
   the cleartext. Although block ciphers utilise padding this makes a 
   negligible difference. Bitrate and pacing are generally application
   specific, and do not change when the content is encrypted. Multiplexed 
   formats (such as HTTP/2 and QUIC) may however incorporate several application streams
   over one connection, which makes the bitrate/pacing no longer application-specific.