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

[Kathleen Moriarty <[e-mail]>]

Hi Kevin,

Thanks for your contribution to our draft.  We added most of your
text, but some overlap of existing text had us leave out a subsection.
See inline.

On Thu, Oct 8, 2015 at 11:37 AM, Smith, Kevin, (R&D) Vodafone Group
<[e-mail]> wrote:
> 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}

Great, thanks for this, a new section was added in 2.1 to cover this
helpful information.

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

This has been added just after the security monitoring section since
both may apply across network types that we used as groupings.

>
>   Flow information visible to a network

The word application was added in front of the section header as that
made sense once IP 5-tuple was removed.  We cover that already in
section 3.1.1, which also covers 2-tuple.  The 2-tuple and 5-tuple are
used in multiple network types, so we may want to think about bumping
this to another section.

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

Thank you for the rest of the text for this section, it's very helpful.

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

Best regards,
Kathleen & Al

>
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag



-- 

Best regards,
Kathleen