Re: [tsvwg] comments on draft-fairhurst-tsvwg-transport-encrypt-06

["MORTON, ALFRED C (AL)" <[e-mail]>]

Hi Gorry,

One place you asked for text (and preparing the NPOV text
is the hardest part, almost no one can do it alone, and many
will retreat when asked for text or reveal their bias when 
they write) :

>>        This data information can inform Internet engineering research,
>>        and help the development of new protocols, methodologies, and
>>        procedures.  Hiding the entire transport protocol, including
>>        header information, will restrict the availability of data, and
>>        might lead to the development of alternative, and potentially more
>>        intrusive, methods to acquire the needed data.
>> [acm]
>> ...might lead to...
>> The speculation here will not be welcome to some.
>I suspect you are correct, but then I think the possibility is true. Are 
>there better words?

[acm] this is a start, and it avoids speculating about the dark side of the response:
 
Concealing the transport protocol header information makes the stream performance 
unavailable to passive observers along the path, and
likely leads to the development of alternative methods to collect that data.

-=-=-=-=-=-=-=-=--=-=-=-=-

In general, use of "X needs Y" has been interpreted as "REQUIRED" by 
those who don't yet agree to replace the connection status info that TCP provided.
Also, it never helped achieve agreement to mention the worst possible
instantiation of alternative methods.

hope this helps,
Al

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: Saturday, April 7, 2018 10:07 PM
> To: MORTON, ALFRED C (AL) <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: comments on draft-fairhurst-tsvwg-transport-encrypt-06
> 
> On 07/04/2018, 21:01, MORTON, ALFRED C (AL) wrote:
> > Hi Gorry,
> > as promised, I have a few comments that may help,
> > drawing from experience. Edits too. See [acm].
> Thanks ever so much, we have consumed this input, see below:
> > Al
> >
> > 1.  Introduction
> >
> > ...
> >     There are many motivations for deploying encrypted transports (i.e.,
> >     transport protocols that use encryption to provide confidentiality
> of
> >     some or all of the transport-layer header information), and
> >     encryption of transport payloads (i.e.  Confidentiality of the
> >     payload data). The increasing public concerns about the interference
> >     with Internet traffic have led to a rapidly expanding deployment of
> >     encryption to protect end-user privacy, in protocols like QUIC, but
> >     also expected to forma a basis of future protocol designs.
> > [acm]
> > s/forma a/form a/
> Thanks, fixed.
> > ...
> >
> >     Introducing cryptographic integrity checks to header fields can also
> >     prevent undetected manipulation of the field by network devices.
> >     However, it does not prevent inspection of the information by device
> >     on path, and it is possible that such devices could develop
> >     mechanisms that rely on the presence of such a field, or a known
> >     value in the field.  This leads to ossification of the header: An
> >     endpoint could be required to supply the header to receive the
> >     network service that it desires.  In some cases, this could be
> benign
> >     to the protocol (e.g., recognising the start of a connection), but
> in
> >     other cases, any change to the protocol use of a specific header can
> >     have undesirable implications (e.g., a mechanism implemented in a
> >     network device, such as a firewall, that requires a header field to
> >     have only a specific known set of values could prevent the device
> >     from forwarding packets using a different version of a protocol that
> >     introduces a new feature that changes the value present in this
> >     field). A protocol that intentionally varies the format and value of
> >     header fields (sometimes known as Greasing) has been suggested as a
> > [acm]
> > "Greasing" doesn't seem to have a formal definition, and may only have
> meaning
> > among those working on QUIC.
> That was the intention of saying "sometimes". I added a reference for
> the moment to
> ID.draft-thomson-quic-grease.
> >     way to help avoid such ossification of the transport protocol.
> >
> >     Implementations of network devices are encouraged to avoid side-
> >     effects when protocols are updated.  In particular, it is important
> >     that protocols either do not expose information where the usage may
> >     change in future protocols, or that methods that utilise the
> >     information are robust to potential changes as protocols evolve over
> >     time.
> >
> >     At the same time, some network operators and access providers, have
> >     come to rely on the in-network measurement of transport properties
> >     and the functionality provided by middleboxes to both support
> network
> >     operations and enhance performance (e.g., [I-D.dolson-plus-
> middlebox-
> >     benefits]).
> >
> >     A protocol design can use header encryption to provide
> >     confidentiality of some or all of the protocol header information.
> >     This prevents an on-path device from knowledge of the header field.
> >     It therefore prevents mechanisms being built that directly rely on
> >     the information or seeks to imply semantics of an exposed header
> >     field.  Protocol designers have often ignored these implications and
> >     this document suggests that exposure of information should be
> >     carefully considered when specifying new protocols.
> > [acm] suggested NPOV:
> > ... suggests that the balance between information exposed and concealed
> > should be carefully considered when specifying new protocols.
> That sounds good, this has been changed.
> >     Using encryption to provide confidentiality of the transport layer
> >     brings some well-known privacy and security benefits.  While a
> >
> >     protocol design that encrypts (hides) all the transport information
> >     can help reduce ossification of the transport layer, it could result
> >     in ossification of the network service.
> > [acm]
> > ...in ossification of the network service<  at other layers>  ???
> > (not clear what is meant)
> OK, we will rework the logic here.
> >     There can be advantages in
> >     providing a level of ossification of the header in terms of
> providing
> >     a set of specified header fields that are observable from in-network
> >     devices.
> >
> >     There can also be implications when working with encrypted transport
> >     protocols that hide transport header information from the network.
> >     This present architectural challenges and considerations in the way
> >     transport protocols are designed, and ability to characterise and
> >     compare different transport solutions [Measure].  This results in
> >     trade-offs around authentication, and confidentiality of transport
> >     protocol headers and the potential support for other uses of this
> >     header information.  For example, it can impact the following
> >     activities that rely on measurement and analysis of traffic flows:
> >
> >     Network Operations and Research: Observable transport headers enable
> >        both operators and the research community to measure and analyse
> >        protocol performance, network anomalies, and failure pathologies.
> >
> >        This information can help inform capacity planning, and assist in
> >        determining the need for equipment and/or configuration changes
> by
> >        network operators.
> >
> >        This data information can inform Internet engineering research,
> >        and help the development of new protocols, methodologies, and
> >        procedures.  Hiding the entire transport protocol, including
> >        header information, will restrict the availability of data, and
> >        might lead to the development of alternative, and potentially
> more
> >        intrusive, methods to acquire the needed data.
> > [acm]
> > ...might lead to...
> > The speculation here will not be welcome to some.
> I suspect you are correct, but then I think the possibility is true. Are
> there better words?
> >        Providing confidentiality of the transport payload, but leaving
> >        some, or all, of the transport headers unencrypted, possibly with
> >        authentication, can provide the majority of the privacy and
> >        security benefits while allowing some measurement.
> >
> >     Protection from Denial of Service: Observable transport headers can
> > [acm]
> > s/can/currently/
> > (just delete "can")
> OK
> >
> >        provide useful input to classification of traffic and detection
> of
> >        anomalous events, such as distributed denial of service attacks.
> >        To be effective, this protection needs to be able to uniquely
> >        disambiguate unwanted traffic.  An inability to separate this
> >        traffic using packet header information is expected to lead to
> > [acm]
> > ...expected to lead to...
> > the discussion of speculative outcomes will not be welcome to some.
> > better to provide a more balanced story (see below)
> >        less precise pattern matching techniques or resort to
> >        indiscriminately (rate) limiting uncharacterised traffic.
> > [acm]
> > something like:
> >        ...An inability to separate this
> >        traffic using packet header information may result in less-
> efficient
> > 	  identification of unwanted traffic or development of different
> >        methods.
> I suggest this: An inability to separate this traffic using packet
> header information may result in less-efficient identification of
> unwanted traffic or development of different methods (e.g. rate-limiting
> uncharacterised traffic).
> >
> >     Network Troubleshooting and Diagnostics:  Encrypting transport
> header
> >        information eliminates the incentive for operators to
> troubleshoot
> >        what they cannot interpret.  A flow experiencing packet loss
> looks
> >        like an unaffected flow when only observing network layer headers
> >        (if transport sequence numbers and flow identifiers are
> obscured).
> >        This limits understanding of the impact of packet loss on the
> >        flows that share a network segment.
> > [acm]
> > suggest a more direct effect:
> > 	  This limits understanding of the impact of packet loss on the
> >        flows, or even localizing the network segment causing packet
> loss.
> >
> I changed this, but also added latency - since I suspect moving forward
> this will become important and can equally be very hard to trouble shoot:
> 
> "This limits understanding of the impact of packet loss or latency on
> the flows, or even localizing the network segment causing the packet
> loss or latency."
> > 	Encrypted traffic therefore
> >        implies "don't touch", and a likely trouble-shooting response
> will
> >        be "can't help, no trouble found".
> > [acm]
> > suggest:
> >        Encrypted traffic may imply "don't touch" to some, and could
> limit a
> > 	  trouble-shooting response to "can't help, no trouble found".
> >
> Much better, thanks.
> > 	The additional mechanisms that
> >        will need to be introduced to help reconstruct transport-level
> >        metrics add complexity and operational costs [I-D.mm-wg-effect-
> >        encrypt].
> > [acm]
> > I'm fairly sure that any discussion of Operator "needs" have been
> > removed from the draft. Otherwise, cite a section # where it remains.
> Ah pity. I'll rmeove the reference, and instead be explicit:
> "The additional mechanisms that will need to be introduced to help
> reconstruct transport-level metrics add complexity and operational costs
> (e.g. in deploying additional functions in equipment or adding traffic
> overhead)."
> >     Network Traffic Analysis: Hiding transport protocol header
> >        information can make it harder to determine which transport
> >        protocols and features are being used across a network segment.
> >        The trends in usage.
> > [acm] the last bit is a sentence fragment...
> >
> Removed.
> >
> > 	This could impact the ability for an
> >        operator to anticipate the need for network upgrades and roll-
> out.
> >        It can also impact the on-going traffic engineering activities
> >        performed by operators.  While the impact may, in many cases, be
> >        small there are scenarios where operators directly support
> >        particular services (e.g., in radio links, or to troubleshoot
> >        issues relating to Quality of Service, QoS; the ability to
> perform
> >        fast re-routing of critical traffic, or support to mitigate the
> >        characteristics of specific radio links). The more complex the
> >        underlying infrastructure the more important this impact.
> >
> >     Open and Verifiable Network Data:  The Hiding transport protocol
> >        header information can reduces the range of actors that can
> >        capture useful measurement data.  This is, of course, its goal.
> > [acm]
> > The QUIC approach is to employ an existing transport protocol that
> > reveals little information (UDP), and perform legacy transport
> > functions at higher layers instead.
> > It's a little different: "hiding protocol messages and stream delivery"
> > seems to fit this approach.  The transport layer becomes
> inconsequential.
> I changed this to:
> "For example, one approach could be to employ an existing transport
> protocol that reveals little information (UDP), and perform traditional
> transport functions at higher layers using transport information
> protected by confidentiality. Such a design, limits the information
> sources available to the Internet community to understand the operation
> of new transport protocols, so preventing access to the information
> necessary to inform design decisions and standardisation of the new
> protocols and related operational practices."
> >        Doing so, however, limits the information sources available to
> the
> >        Internet community to understand the operation of transport
> > [acm]
> > s/transport/new/   (understand the operation of new protocols)
> > the legacy transport functions have been moved and made opaque.
> >
> >        protocols, so preventing access to the information necessary to
> >        inform design decisions and standards for new protocols and
> >        related operational practices.
> >
> >        There are dangers in a model where only endpoints (i.e., at user
> >        devices and within service platforms) can observe performance,
> and
> >        this cannot be independently verified.
> > [acm]
> > "dangers" won't pass the NPOV filter:
> > Maybe:
> > The cooperating dependence of network, application, and host to
> > provide communication performance on the Internet is uncertain when
> > only endpoints (i.e., at user devices and within service platforms)
> > can observe performance, and performance cannot be independently
> verified
> > by all parties.
> Thanks, used.
> >        To ensure the health of the standards and research communities,
> we
> >        need independently captured data to develop new transport
> protocol
> >        mechanisms based on the behaviour experienced in deployed
> >        networks.
> > [acm]
> > "we need..."  needs new phrasing that allows for other solutions.
> Fixed.
> >        Independently verifiable performance metrics might also important
> > [acm]
> > s/also/also be/
> OK
> >        in order to demonstrate regulatory compliance in some
> >        jurisdictions.
> >
> >     The last point leads us to consider the impact of hiding transport
> >     headers in the specification and development of protocols and
> >     standards.  This has potential impact on:
> >
> >     o  Understanding Feature Interactions: An appropriate vantage point,
> >        coupled with timing information about traffic flows, provides a
> >        valuable tool for benchmarking equipment, functions, and/or
> >        configurations, and to understand complex feature interactions.
> >        An inability to observe transport protocol information can limit
> >        the ability to diagnose and explore interactions between features
> >        at different protocol layers, a side-effect of not allowing a
> >        choice of vantage point from which this information is observed.
> >
> >     o  Supporting Common Specifications: The Transmission Control
> >        Protocol (TCP) is the predominant transport protocol used over
> >        Internet paths.  Its many variants have broadly consistent
> >        approaches to avoiding congestion collapse, and to ensuring the
> >        stability of the network.  Increased use of transport layer
> >        encryption can overcome ossification, allowing deployment of new
> >        transports and different types of congestion control.  This
> >        flexibility can be beneficial, but it can come at the cost of
> >        fragmenting the ecosystem.  There is little doubt that developers
> >        will try to produce high quality transports for their target
> uses,
> >        but it is not clear there are sufficient incentives to ensure
> good
> >        practice that benefits the wide diversity of requirements for the
> >        Internet community as a whole.  Increased diversity, and the
> >        ability to innovate without public scrutiny, risks point
> solutions
> >        that optimise for specific needs, but accidentally disrupt
> >        operations of/in different parts of the network.  The social
> >        contract that maintains the stability of the network relies on
> >        accepting common specifications, and on the ability to verify
> that
> >        others also conform.
> > [acm]
> > s/network/Internet/g  above paragraph
> OK
> >
> >     o  Operational practice: Published transport specifications allow
> >        operators to check compliance.  This can bring assurance to those
> >        operating networks, often avoiding the need to deploy complex
> >        techniques that routinely monitor and manage TCP/IP traffic flows
> >        (e.g.  Avoiding the capital and operational costs of deploying
> >        flow rate-limiting and network circuit-breaker methods
> [RFC8084]).
> >        When it is not possible to observe transport header information,
> >        methods are still needed to confirm that the traffic produced
> >        conforms to the expectations of the operator or developer.
> >
> >     o  Restricting research and development: Hiding transport
> information
> >        can impede independent research into new mechanisms, measurement
> >        of behaviour, and development initiatives.  Experience shows that
> >        transport protocols are complicated to design and complex to
> >        deploy, and that individual mechanisms need to be evaluated while
> >        considering other mechanisms, across a broad range of network
> >        topologies and with attention to the impact on traffic sharing
> the
> >        capacity.  Hiding transport header information (e.g., by
> pervasive
> >        encryption of transport information) could eliminate the
> >        independent self-checks that have previously been in place from
> >        research and academic contributors (e.g., the role of the IRTF
> >        ICCRG, and research publications in reviewing new transport
> >        mechanisms and assessing the impact of their experimental
> >        deployment).
> > [acm]
> > "Hiding transport header info..."
> > speculation here, and "eliminate' is probably too strong, given that
> > other methods exist for study.
> OK, I suggest we avoid the linkage, and refer only to the impact that
> would happen if there was less open data:
> "If this results in reduced availability of open data, it could
> eliminate the independent self-checks to the standardisation process
> that have previously been in place from research and academic
> contributors (e.g., the role of the IRTF ICCRG, and research
> publications in reviewing new transport mechanisms and assessing the
> impact of their experimental deployment)."
> - still speculation, but now only on what happens when you do things in
> pricade.
> >     In summary, a lack of visibility of transport header information can
> >     impact the ways that protocols are designed, standardised, deployed,
> >     and operated.  The choice of whether future transport protocols
> >     encrypt their protocol headers therefore needs to be taken based not
> >     solely on security and privacy considerations, but also taking into
> >     account the impact on operations, standards, and research.  A
> network
> >     that is secure but unusable due to persistent congestion collapse is
> >     not an improvement, and while that would be an extreme outcome
> >     proposals that impose high costs for very limited benefits need to
> be
> >     considered carefully, to ensure the benefits outweigh the costs.
> > [acm]
> > "...secure but unusable due to persistent congestion collapse..."
> > is clearly for shock value, and very far from NPOV expression of the
> issue.
> :-).  Probably conjecture. Instead replaced by:
> "The choice of whether future transport protocols encrypt their protocol
> headers therefore needs to be taken based not solely on security and
> privacy considerations, but also taking into account the impact on
> operations, standards, and research. Any new Internet transport need to
> provide appropriate transport mechanisms and operational support to
> assure the resulting traffic can not result in persistent congestion
> collapse <xref
> target="RFC2914">.
> 
> > 2.  Current uses of Transport Headers within the Network
> >
> >     Despite transport headers having end-to-end meaning, some of these
> >     transport headers have come to be used in various ways within the
> >     Internet.  In response to pervasive monitoring [RFC7624] revelations
> >     and the IETF consensus that "Pervasive Monitoring is an Attack"
> >     [RFC7258], efforts are underway to increase encryption of Internet
> >     traffic,.  Applying confidentiality to transport header fields would
> >     affect how network protocols are designed and used [I-D.mm-wg-
> effect-
> >     encrypt].
> > [acm]
> > the draft indicates how current protocol information is used.
> OK
> >     To understand these implications, it is first necessary to
> >     understand how transport layer headers are currently observed and/or
> >     modified by middleboxes within the network.
> >
> >     Transport protocols can be designed to encrypt or authenticate
> >     transport header fields.  Authentication methods at the transport
> >     layer can be used to detect any changes to an immutable header field
> >     that were made by a network device along a path.  The intentional
> >     modification of transport headers by middleboxes (such as Network
> >     Address Translation, NAT, or Firewalls) is not considered.  Common
> >     issues concerning IP address sharing are described in [RFC6269].
> >
> > ...
> > 2.1.2.  Metrics derived from Transport Layer Headers
> >
> >     Some actors have a need to characterise the performance of link/
> >     network segments.
> > [acm]
> > s/.../Some actors manage their portion of the Internet by characterizing
> the.../
> Yes, thanks.
> >     Passive monitoring uses observed traffic to makes
> >     inferences from transport headers to derive these measurements.  A
> >     variety of open source and commercial tools have been deployed that
> >     utilise this information.  The following metrics can be derived from
> >     transport header information:
> >
> >     Traffic Rate and Volume: Header information e.g., (sequence number,
> >        length) may allow derivation of volume measures per-application,
> >        to characterise the traffic that uses a network segment or the
> >        pattern of network usage.  This may be measured per endpoint or
> >
> >        for an aggregate of endpoints (e.g., by an operator to assess
> >        subscriber usage). It can also be used to trigger measurement-
> >        based traffic shaping and to implement QoS support within the
> >        network and lower layers.  Volume measures can be valuable for
> >        capacity planning (providing detail of trends rather than the
> >        volume per subscriber).
> >
> >     Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g.,
> from
> >        sequence number) and is often used as a metric for performance
> >        assessment and to characterise transport behaviour.
> Understanding
> >        the root cause of loss can help an operator determine whether
> this
> >        requires corrective action.  Network operators may also use the
> >        variation in patterns of loss as a key performance metric,
> >        utilising this to detect changes in the offered service.
> >
> >        There are various cause of loss, including: corruption on a link
> > s/cause/causes/
> OK.
> >        (e.g., interference on a radio link), buffer overflow (e.g., due
> >        to congestion), policing (traffic management), buffer management
> >        (e.g., Active Queue Management, AQM), inadequate provision of
> >        traffic preemption.  Understanding flow loss rate requires either
> >        maintaining per flow packet counters or by observing sequence
> >        numbers in transport headers.  Loss can be monitored at the
> >        interface level by devices in the network.  It is often important
> >        to understand the conditions under which packet loss occurs.
> This
> >        usually requires relating loss to the traffic flowing on the
> >        network node/segment at the time of loss.
> >
> >        Observation of transport feedback information (observing loss
> >        reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can
> increase
> >        understanding of the impact of loss and help identify cases where
> >        loss may have been wrongly identified, or the transport did not
> >        require the lost packet.  It is sometimes more important to
> >        understand the pattern of loss, than the loss rate - since losses
> >        can often occur as bursts, rather than randomly-timed events.
> >
> >     Throughput and Goodput: The throughput observed by a flow can be
> >        determined even when a flow is encrypted, providing the
> individual
> >        flow can be identified.  Goodput [RFC7928] is a measure of useful
> >        data exchanged (the ratio of useful/total volume of traffic sent
> >        by a flow), which requires ability to differentiate loss and
> >        retransmission of packets (e.g., by observing packet sequence
> >        numbers in the TCP or the Real Time Protocol, RTP, headers
> >        [RFC3550]).
> >
> > ...
> >
> >     Jitter: Some network applications are sensitive to changes in packet
> >        timing.  For such applications, it can be necessary to measure
> the
> >        jitter observed along a portion of the path.  The requirements to
> >        measure jitter resemble those for the measurement of latency.
> > [acm]
> > Let's  s/Jitter/Delay Variation/g  for wider applicability.
> > Ref to RFC 3393 and RFC 5481
> Yes.
> >     Flow Reordering: Significant flow reordering can impact time-
> critical
> >        applications and can be interpreted as loss by reliable
> >        transports.  Many transport protocol techniques are impacted by
> >        reordering (e.g., triggering TCP retransmission, or re-buffering
> >        of real-time applications). Packet reordering can occur for many
> >        reasons (from equipment design to misconfiguration of forwarding
> >        rules). Since this impacts transport performance, network tools
> >        are needed to detect and measure unwanted/excessive reordering.
> >
> >        As in the drive to reduce network latency, there is a need for
> >        operational tools to detect mis-ordered packet flows and quantify
> >        the degree or reordering.  Techniques for measuring reordering
> >        typically observe packet sequence numbers.  Metrics have been
> >        defined that evaluate whether a network has maintained packet
> >        order on a packet-by-packet basis [RFC4737] and [RFC5236].
> >
> >        There have been initiatives in the IETF transport area to reduce
> >        the impact of reordering within a transport flow, possibly
> leading
> >        to reduce the requirements for ordering.  These have promise to
> >        simplify network equipment design as well as the potential to
> >        improve robustness of the transport service.  Measurements of
> >        reordering can help understand the level of reordering within
> >        deployed infrastructure, and inform decisions about how to
> >        progress such mechanisms.
> >
> >     Some protocols provide in-built monitoring and reporting functions.
> >     Transport fields in the RTP header [RFC3550] [RFC4585] can be
> >     observed to derive traffic volume measurements and provide
> >     information on the progress and quality of a session using RTP. Key
> >     performance indicators are retransmission rate, packet drop rate,
> >     sector utilisation level, a measure of reordering, peak rate, the
> CE-
> >     marking rate, etc.  Metadata is often important to understand the
> >     context under which the data was collected, including the time,
> >     observation point, and way in which metrics were accumulated.  The
> >     RTCP protocol directly reports some of this information in a form
> >     that can be directly visible in the network.  A user of summary
> >     measurement data needs to trust the source of this data and the
> >     method used to generate the summary information.
> >
> >     When information in transport headers is concealed, measurements
> need
> >     to rely on pattern inferences and other heuristics grows, and
> >     accuracy suffers [I-D.mm-wg-effect-encrypt].
> > [acm]
> > The wording of this sentence has probably changed now,
> > probably a direct quote will be the least risky going forward.
> Changed.
> > 2.1.3.  Metrics derived from Network Layer Headers
> > [acm]
> > stopped here for now, but probably other places where comments
> > like the above would apply...
> OK.
> 
> We will work on a new revision, and hopefully publish this soon.
> 
> Gorry