Skip to main content

The Impact of Transport Header Encryption on Operation and Evolution of the Internet
draft-fairhurst-tsvwg-transport-encrypt-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Gorry Fairhurst
Last updated 2017-06-02 (Latest revision 2017-05-28)
Replaced by draft-ietf-tsvwg-transport-encrypt, draft-ietf-tsvwg-transport-encrypt, RFC 9065
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-fairhurst-tsvwg-transport-encrypt-01
quot;
   number placed at the start of each UDP datagram.

   Once the protocol has been determined, the transport header can be
   determined from a published specification.  If multiple formats are
   permitted, this may also require observing the protocol version being
   used and possibly parameter negotiation at connection setup.

5.2.2.  Use of a Transport as a Substrate

   When a transport is used as a substrate, the transport provides an
   encapsulation that allows another transport flow to be within the
   payload of a transport flow.  The transported protocol header may
   provide additional information for multiplexing multiple flows over
   the same 5-tuple.  The UDP Guidelines [RFC8085] provides some
   guidance on using UDP as a substrate protocol.  If there is no
   additional information about the protocol transported by the
   substrate, this may be viewed as an opaque traffic aggregate, and
   prevents transport measurement in the network.  Examples include GRE-
   in-UDP [RFC8086], SCTP-in-UDP. The GRE-in-UDP encapsulation may
   include an encrypted payload, but does not encrypt the GRE protocol
   header.

5.2.3.  Support for Mobility and Flow Migration

   With the proliferation of mobile connected devices, there is a stated
   need for connection-oriented protocols to maintain connections after
   a network migration by an endpoint.  The ability and desirability of
   in-network devices to track such migration depends on the context.
   On the one hand, a load-balancer device in front of server may find
   it useful to map a migrated connection to the same server endpoint.
   On the other hand, a user performing migration to avoid detection may
   prefer the network not to be able to correlate the different parts of
   a migrating session.  Care must then be exercised to make sure that
   the information encoded by the endpoints is not sufficient to
   identify unique flows and facilitate a persistent surveillance attack
   vector [I-D.mm-wg-effect-encrypt].

   The impact of flow migration on measurement activities depends on the
   data being measured, rate of migration and level of encryption that
   is employed.  Requirements for load balancing and mobility can lead
   to complex protocol interactions.

Fairhurst              Expires December 02, 2017               [Page 18]
Internet-Draft            Transport Encryption                 June 2017

5.2.4.  Flow Start and Stop

   Transports can expose that start and end of flows in a transport
   header field (e.g., TCP SYN, FIN, RST). This can also help
   measurement devices identify the start of flows, or to remove stale
   flow information.  This information is supplemental - flows can start
   and end at any time, the Internet network layer provides only a best
   effort service that allows alternate routing, reordering, loss, etc,
   so a network measurement tool can not rely upon observing these
   indicators.  The time to complete a protocol connection and/or
   session setup can be reported.

   Flow information can provide in-network devices to manage their
   forwarding state [I-D.trammell-plus-statefulness].  It can assist a
   firewall in deciding which flows are permitted through a security
   gateway, or to help maintain the network address translation (NAT)
   bindings in a NAPT or application layer gateway.  This information
   may also find use in load balancers, where visibility of the 5-tuple
   could assist in selecting a server [I-D.mm-wg-effect-encrypt].

   Access to flow information and an observable start/stop indication
   [I-D.trammell-plus-statefulness] can avoid UDP middleboxes relying on
   timeouts to remove old state.  Without this middleboxes are unaware
   when a particular flow ceases to be used by an application [RFC8085].
   This can lead to the state table entries not keeping state for less
   time for flows that are not identifiable.

5.3.  Observable Transport Sequence Number

   The TCP or RTP sequence number can be observed in one direction (the
   direction that carries data segments). An authenticated header
   prevents this field being modified or terminated/split [RFC3135] by a
   network device, but allows this still to be used to observe progress
   of the network flow.

   An incrementing sequence number enables detection of loss (either by
   correlating ingress and egress value, or when assuming that all
   packets follow a single path), duplication and reordering (with
   understanding that not necessarily all packets of a flow follow the
   same path, and reordering can complicate processing of observations).
   Tools are widely available to interpret RTP and TCP sequence numbers,
   ranging from open source tools to dedicated commercial packages.  As
   for TCP, use by in-network measurement devices needs to account for
   the impact of load-balancing of flows, changes in forwarding
   behaviour, measurement loss (rather than observed packet loss), etc.

5.4.  Observable Transport Reception

Fairhurst              Expires December 02, 2017               [Page 19]
Internet-Draft            Transport Encryption                 June 2017

   Acknowledgement (ACK) data provides information about the path from
   the network device to the remote endpoint.  The information can help
   identify packet loss (or the point of loss), RTT, and other network-
   related performance parameters (e.g., throughput, jitter,
   reordering). Unless this information is correlated with other data
   there is no way to disambiguate the cause of impairments (congestion
   loss, link transmission loss, equipment failure).

   An in-network device must not modify the flow of end-to-end ACK data
   when using an authenticated protocol.  That is, must not use the in-
   network methods described in [RFC3449].  This can impact the
   performance and/or efficiency (e.g., cost) of using paths where the
   return capacity is limited or has implications on the overall design
   (e.g., using TCP with cellular mobile uplinks, DOCSIS uplinks).

   The TCP stream can be observed by correlating the stream of TCP ACKs
   that flow from a receiver in the return direction.  Although these
   ACKs are cumulative, and are not necessarily sent on the same path as
   the forward data, when visible, their sequence can confirm successful
   transmission and the path RTT. In the case of TCP they may also
   indicate packet loss (duplicate ACKs).

   An RTP session can provide reception information [RFC3550] [RFC4585]
   feedback using the RTCP framework.  This reception information and
   can be observed by in-network measurement devices and can be
   interpreted to provide a variety of quality of experience information
   for the related RTP flow, as well as basic network performance data
   (RTT, loss, jitter, etc).

5.5.  Observable Transport Timestamps

   The use of timestamps for latency and jitter measurements Section
   3.2.5 is discussed in other sections of the current version of the
   document.

5.6.  Observable ECN Transport Feedback Information

   Transport protocols that use ECN Section 3.3.3 need to provide ECN
   feedback information in the transport header to inform the sender
   whether packets have been received with an ECN CE-mark [RFC3819].
   This information can be in the form of feedback once each RTT
   [RFC3819] or more frequent.  The latter may involve sending a
   detailed list of all ECN-marked packets (e.g., [I-D.ietf-tcpm-
   accurate-ecn] and [RFC6679]). The detailed information can provide
   detail about the pattern and rate of marking.  The information
   provided in these protocol headers can help a network operator to
   understand the congestion status of the forward path and the impact
   of marking algorithms on the traffic that is carried [RFC8087].

   IETF specifications for Congestion Exposure (CONVEX) [RFC7713] and
   Per-congestion Notification (PCB) [RFC5559] are examples of
   frameworks that monitor reception reports for CE-marked packets to
   support network operations.

Fairhurst              Expires December 02, 2017               [Page 20]
Internet-Draft            Transport Encryption                 June 2017

5.7.  Other Observable Transport Fields

   This section is not complete - later revision may determine other
   fields or remove this section.

5.8.  Interpretation of Transport Header Fields

   Understanding and analysing transport protocol behaviour typically
   demands tracking changes to the protocol state at the transport
   endpoints.  Although protocols communicate state information in their
   protocol headers, a protocol implementation typically also contains
   internal state that is not directly visible from observing transport
   protocol headers.  Effective measurement tools need to consider that
   not all packets may be observed (due to drops at the capture tap or
   because packets take an alternate route that does not pass the tap).
   Some flows of packets may also be encapsulated within a maintenance
   domain in other protocols, which further complicates analysis.

   Some examples of using network measurements of transport headers to
   infer internal TCP transport state information include:

   o  The TCP congestion window (cwnd) and slow start threshold
      (ssthresh). Tools for analysing in-network performance of TCP may
      observe sequence number to infer the current congestion controller
      state.
   o  The TCP RTT estimator and TCP Retransmission Time Out (RTO) value.
      This can be estimated by correlating sequence and acknowledgement
      numbers, or possibly by observing TCP timestamp options.
   o  Use of pacing (and pacing rate) and use of methods such as
      Proportional Rate Reduction (PRR) and Congestion Window validation
      (CWV). This may be estimated from observing timing of segments
      with TCP sequence numbers.  This is important to some congestion
      control mechanisms and can be important for applications that are
      rate limited or send traffic bursts.
   o  Receiver window and flow control state.  This may be inferred from
      information in TCP ACK segments.  It is important to applications
      where the remote endpoint is resource constrained, or the path
      exhibits a large RTT.
   o  Retransmission state and receiver buffer.  This may be inferred
      from information in TCP ACK segments (especially when SACK blocks
      are provided), this can be important to the performance of
      applications that send traffic bursts.
   o  Use of ACK delay and Nagle algorithm.  This may be estimated from
      observing timing of segments with TCP sequence numbers, and is
      important to the performance of thin application flows.

5.9.  Requirements for Transport Measurement

   Transport measurement introduces the following requirements to
   identify the observable information:

Fairhurst              Expires December 02, 2017               [Page 21]
Internet-Draft            Transport Encryption                 June 2017

   o  Observable protocol type and version information is needed to
      identify the protocol being used when characterising the traffic,
      and to enable further observation of the flow.
   o  Observable format information is needed to allow an observer to
      determine the presence of any observable header fields.
   o  A published specification is needed to allow an observer to
      determine the size and position of any observable header fields so
      that these fields may be decoded by a measurement tool.
   o  Observable flow start/stop information can assist some forms of
      measurement and has utility for middleboxes that track state.

   The need for in-network transport measurement introduces the
   following requirements for observable information in transport header
   fields:

   o  Observable transport information to determine the progress of
      flows for each direction of communication.  This requires
      observable packet numbers.
   o  Observable transport information to determine loss, and understand
      the response to congestion for a network segment.  This requires
      observable reception information (e.g., packet acknowledgment
      information).
   o  Observable transport information is needed for more advanced
      measurement of latency, jitter, etc.  This requires an observable
      field and a method to correlating return information with the
      observed field.  This could utilise a packet number and/or
      transmission timestamp information.  This information needs to be
      available in both directions of transmission.
   o  Exposure of Transport ECN feedback provides a powerful tool to
      understand ECN-enabled AQM-based networks.  (Forward ECN
      information is already observable in the network header).

6.  The Effect of Encrypting Transport Header Fields

   This section explores key implications of working with encrypted
   transport protocols.

6.1.  Independent Measurement

   Independent observation by multiple actors is important for
   scientific analysis.  Encrypting transport header encryption changes
   the ability for other actors to collect and independently analyse
   data.  Internet transport protocols employ a set of mechanisms.  Some
   of these need to work in cooperation with the network layer - loss
   detection and recovery, congestion detection and congestion control,
   some of these need to work only end-to-end (e.g., parameter
   negotiation, flow-control.

Fairhurst              Expires December 02, 2017               [Page 22]
Internet-Draft            Transport Encryption                 June 2017

   When encryption conceals information in the transport header, it
   could be possible for an applications to provide summary data on
   performance and usage of the network.  This data could be made
   available to other actors.  However, this data needs to contain
   sufficient detail to understand (and possibly reconstruct the network
   traffic pattern for further testing) and to be correlated with the
   configuration of the network paths being measured.  Sharing
   information between actors needs also to consider the privacy of the
   user and the incentives for providing accurate and detailed
   information.  Protocols that expose the state information used by the
   transport protocol in their header information (e.g., timestamps used
   to calculate RTT, packet numbers used to asses congestion and
   requests for retransmission) provide an incentive for the sending
   endpoint to provide correct information, increasing confidence that
   the observer understands the transport interaction with the network.
   This becomes important when considering changes to transport
   protocols, changes in network infrastructure, or the emergence of new
   traffic patterns.

6.2.  Characterising "Unknown" Network Traffic

   If "unknown" or "uncharacterised" traffic patterns form a small part
   of the traffic aggregate passing through a network device or segment
   of the network the path, the dynamics of the uncharacterised traffic
   may not have a significant collateral impact on the performance of
   other traffic that shares this network segment.  Once the proportion
   of this traffic increases, the need to monitor the traffic and
   determine if appropriate safety measures need to be put in place.

   Tracking the impact of new mechanisms and protocols requires traffic
   volume to be measured and new transport behaviours to be identified.
   This is especially true of protocols operating over a UDP substrate.
   The level and style of encryption needs to be considered in
   determining how this activity is performed.  On a shorter timescale,
   information may also need to be collected to manage denial of service
   attacks against the infrastructure.

6.3.  Accountability and Internet Transport Portocols

   Attention therefore needs to be paid to the expected scale of
   deployment of new protocols and protocol mechanisms.  Whatever the
   mechanism, experience has shown that it is often difficult to

Fairhurst              Expires December 02, 2017               [Page 23]
Internet-Draft            Transport Encryption                 June 2017

   correctly implement combination of mechanisms [RFC8085].  These
   mechanisms therefore typically evolve as a protocol matures, or in
   response to changes in network conditions, changes in network traffic
   or changes to application usage.

   The growth and diversity of applications and protocols using the
   Internet continues to expand - and there has been recent interest in
   a wide range of new transport methods, e.g., Larger Initial Window,
   Proportional Rate Reduction (PRR), congestion control methods based
   on measuring bottleneck bandwidth and round-trip propagation time,
   the introduction of AQM techniques and new forms of ECN response
   (e.g., Data Centre TCP, DCTP [I-D.ietf-tcpm-dctcp], and methods
   proposed for Low Latency Low Loss Scalable throughput, L4S).  For
   each new method it is desirable to build a body of data reflecting
   its behaviour under a wide range of deployment scenarios, traffic
   load, and interactions with other deployed/candidate methods.

   Measurement therefore has a critical role in the design of transport
   protocol mechanisms and their acceptance by the wider community
   (e.g., as a method to judge the safety for Internet deployment.  Open
   standards suggest that such evaluation needs to include independent
   observation and evaluation of performance data.

7.  Implications on Evolution of the Internet Transport

   The transport layer provides the first end-to-end interactions across
   the Internet.  Transport protocols are layered directly over the
   network service and are sent in the payload of network-layer packets.
   However, this simple architectural view hides one of the core
   functions of the transport - to discover and adapt to the properties
   of the Internet path that is currently being used.  The design of
   Internet transport protocols is as much about trying to avoid the
   unwanted side effects of congestion on a flow and other capacity-
   sharing flows, avoiding congestion collapse, adapting to changes in
   the path characteristics, etc., as it is about end-to-end feature
   negotiation, flow control and optimising for performance of a
   specific application.

   To achieve stable Internet operations the IETF transport community,
   has to date, relied heavily on measurement and insight provided from
   the wider community to understand the trade-offs and to inform
   selection of select appropriate mechanisms to ensure a safe, reliable
   and robust Internet since the 1990's.

Fairhurst              Expires December 02, 2017               [Page 24]
Internet-Draft            Transport Encryption                 June 2017

   There are many motivations for deploying encrypted transports, and
   encryption of transport payloads.  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. At the same time, network operators and access
   providers, especially in mobile networks, have come to rely on the
   in-network functionality provided by middleboxes both to enhance
   performance and support network operations.  This document has
   expanded upon the expected implications on operational practices when
   working with encrypted transport protocols, and offers insight into
   the potential benefit of authentication, encryption and techniques
   that require in-network devices to interpret specific protocol header
   fields.  It presents a need for architectural changes and
   consideration of approaches to the way network transport protocols
   are designed when using encryption[Measure].

   The use of encryption at the transport layer comes with implications
   that need to be considered:

   Troubleshooting and diagnostics. Encrypting all transport information
      eliminates the incentive for operators to troubleshoot what they
      cannot interpret: one flow experiencing packet loss looks like any
      other.  When transport header encryption prevents decoding the
      transport header (if sequence numbers and flow ID are obscured),
      and hence understanding the impact on a particular flow or flows
      that share a common network segment.  Encrypted traffic therefore
      implies "don't touch", and a likely first response will be "can't
      help, no trouble found", or the implication that this complexity
      comes with an additional operational cost [I-D.mm-wg-effect-
      encrypt].
      

   Open verifyable data The use of transport header encryption may
      reduce the range of actors who can capture useful measurement
      data.  This may in future restrict the information sources
      available to the Internet community to understand the operation of
      the network and transport protocols, necessary to inform
      standardisation and design decisions for new protocols, equipment
      and operational practices.  There are dangers in a model where
      transport information is only observable at endpoints: i.e., at
      user devices and within service platforms and a need for
      independently captured data to develop open standards and
      stimulate research into new methods.
      

Fairhurst              Expires December 02, 2017               [Page 25]
Internet-Draft            Transport Encryption                 June 2017

   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).  This
      should continue when encrypted transport headers are used, but
      methods need to confirm that the traffic produced conforms to the
      expectations of the operator or developer.
      

   Traffic analysis The use of encryption could make it harder to
      determine which transport methods are being used across a network
      segment and the trends in usage.  This could impact the ability
      for an operator to anticipate the need for network upgrades and
      roll-out.  It can also impact on-going traffic engineering
      activities.  Although the impact in many case may be small, there
      are cases where operators directly support services (e.g., in
      radio environments, or to troubleshoot QoS-related issues) and the
      more complex the underlying infrastructure the more important this
      impact.
      

   Interactions between mechanisms An appropriate vantage point, coupled
      with timing information for the flow (fine-grained timestamps) is
      a valuable tool in benchmarking equipment/configurations and
      understanding non-trivial interactions.  Encryption restricts the
      ability to explore interactions between functions at different
      protocol layers.  This is a side-effect of not allowing a choice
      of the vantage point from which this information is observed.
      This can be important (e.g., in examining collateral impact of
      flows sharing a bottleneck, or where the intention is to
      understand the interaction between a layer 2 function (e.g., radio
      resource management policy, a channel impairment, an AQM
      configuration, a Per Hop Behaviour (PHB) or scheduling method) and
      a transport protocol).
      

Fairhurst              Expires December 02, 2017               [Page 26]
Internet-Draft            Transport Encryption                 June 2017

   Common specifications Since the introduction of congestion control,
      TCP has continued to be the predominate transport, with a
      consistent approach to avoiding congestion collapse.  There is a
      risk that the diversity of transport mechanisms could also
      increase, with incentives to use a wide range of methods, this is
      not in itself a problem, nor is this a direct result of
      encryption.  Encryption of all headers places the onus on
      validation in the hands of developers.  While there is little to
      doubt that developers will seek to produce high quality code for
      their target use, it is not clear whether there is sufficient
      incentive to ensure good practice that benefits the wide diversity
      of requirements from the Internet community as a whole.  However,
      when encryption is used, this risk needs to be weighed against the
      reduced visibility of the interactions between traffic, the
      network and the mechanisms.  Especially, if a development cycle
      focused on specific protocols/applications could offer incentives
      for optimisations that could prove suboptimal for users or
      operators that utilise a network segments with different
      characteristics than targeted by the developer.
      

   Restricting research and development The use of encryption may impede
      independent research into new mechanisms, measurement of
      behaviour, and development initiatives.  Experience shows that
      high quality transport protocols are complicated to design and
      complex to deploy, and that individual mechanisms need to be
      evaluated while considering other mechanism, across a broad range
      of network topologies and with attention to the impact on traffic
      sharing the capacity.  Adopting 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).

   Pervasive use of transport header encryption can impact the ways that
   future protocols are designed and deployed.  The choice of whether
   candidate transport designs should encrypt their protocol headers
   therefore needs to be taken based not just on security
   considerations, but also on the impact on operating networks and the
   constrictions this may place on evolution of Internet protocols.
   While encryption of all transport information can help reduce
   ossification of the transport layer, it could result in ossification
   of the network service.  There can be advantages in providing a level
   of ossification of the header in terms of providing a set of open
   specified header fields that are observable from in-network devices.

8.  Acknowledgements

   The author would like to thank all who have talked to him face-to-
   face or via email.  ...

Fairhurst              Expires December 02, 2017               [Page 27]
Internet-Draft            Transport Encryption                 June 2017

   This work has received funding from the European Union's Horizon 2020
   research and innovation programme under grant agreement No 688421.The
   opinions expressed and arguments employed reflect only the authors'
   view.  The European Commission is not responsible for any use that
   may be made of that information.

9.  IANA Considerations

   XX RFC ED - PLEASE REMOVE THIS SECTION XXX

   This memo includes no request to IANA.

10.  Security Considerations

   This document is about design and deployment considerations for
   transport protocols.  Authentication, confidentiality protection, and
   integrity protection are identified as Transport Features by
   RFC8095".  As currently deployed in the Internet, these features are
   generally provided by a protocol or layer on top of the transport
   protocol; no current full-featured standards-track transport protocol
   provides these features on its own.  Therefore, these features are
   not considered in this document, with the exception of native
   authentication capabilities of TCP and SCTP for which the security
   considerations in RFC4895.

   Like congestion control mechanisms, security mechanisms are difficult
   to design and implement correctly.  It is hence recommended that
   applications employ well-known standard security mechanisms such as
   DTLS, TLS or IPsec, rather than inventing their own.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997, <http://www.rfc-editor.org/info/
              rfc2119>.

11.2.  Informative References

   [I-D.dolson-plus-middlebox-benefits]
              Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet,
              "Beneficial Functions of Middleboxes", Internet-Draft
              draft-dolson-plus-middlebox-benefits-03, March 2017.

   [I-D.ietf-aqm-codel]
              Nichols, K., Jacobson, V., McGregor, A. and J. Jana,
              "Controlled Delay Active Queue Management", Internet-Draft
              draft-ietf-aqm-codel-00, October 2014.

   [I-D.ietf-aqm-fq-codel]

Fairhurst              Expires December 02, 2017               [Page 28]
Internet-Draft            Transport Encryption                 June 2017

              Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys,
              J. and E. Dumazet, "FlowQueue-Codel", Internet-Draft
              draft-ietf-aqm-fq-codel-00, January 2015.

   [I-D.ietf-aqm-pie]
              Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A
              Lightweight Control Scheme To Address the Bufferbloat
              Problem", Internet-Draft draft-ietf-aqm-pie-00, October
              2014.

   [I-D.ietf-ippm-6man-pdm-option]
              Elkins, N., Hamilton, R. and m.  mackermann@bcbsm.com,
              "IPv6 Performance and Diagnostic Metrics (PDM) Destination
              Option", Internet-Draft draft-ietf-ippm-6man-pdm-
              option-10, May 2017.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Internet-Draft draft-ietf-quic-
              transport-03, May 2017.

   [I-D.ietf-tcpm-accurate-ecn]
              Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More
              Accurate ECN Feedback in TCP", Internet-Draft draft-ietf-
              tcpm-accurate-ecn-00, December 2015.

   [I-D.ietf-tcpm-dctcp]
              Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.
              and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion
              Control for Datacenters", Internet-Draft draft-ietf-tcpm-
              dctcp-06, May 2017.

   [I-D.ietf-tsvwg-l4s-arch]
              Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency,
              Low Loss, Scalable Throughput (L4S) Internet Service:
              Architecture", Internet-Draft draft-ietf-tsvwg-l4s-
              arch-00, May 2017.

   [I-D.mm-wg-effect-encrypt]
              Moriarty, K. and A. Morton, "Effect of Pervasive
              Encryption on Operators", Internet-Draft draft-mm-wg-
              effect-encrypt-11, April 2017.

   [I-D.trammell-plus-abstract-mech]
              Trammell, B., "Abstract Mechanisms for a Cooperative Path
              Layer under Endpoint Control", Internet-Draft draft-
              trammell-plus-abstract-mech-00, September 2016.

   [I-D.trammell-plus-statefulness]
              Kuehlewind, M., Trammell, B. and J. Hildebrand,
              "Transport-Independent Path Layer State Management",
              Internet-Draft draft-trammell-plus-statefulness-02,
              December 2016.

Fairhurst              Expires December 02, 2017               [Page 29]
Internet-Draft            Transport Encryption                 June 2017

   [Latency]  Briscoe, B., "Reducing Internet Latency: A Survey of
              Techniques and Their Merits", November 2014.

   [Measure]  Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement-
              based Protocol Design", June 2017.

   [RFC2474]  Nichols, K., Blake, S., Baker, F. and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
              10.17487/RFC2474, December 1998, <http://www.rfc-
              editor.org/info/rfc2474>.

   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
              Shelby, "Performance Enhancing Proxies Intended to
              Mitigate Link-Related Degradations", RFC 3135, DOI
              10.17487/RFC3135, June 2001, <http://www.rfc-editor.org/
              info/rfc3135>.

   [RFC3168]  Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
              Explicit Congestion Notification (ECN) to IP", RFC 3168,
              DOI 10.17487/RFC3168, September 2001, <http://www.rfc-
              editor.org/info/rfc3168>.

   [RFC3234]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002,
              <http://www.rfc-editor.org/info/rfc3234>.

   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M.
              Sooriyabandara, "TCP Performance Implications of Network
              Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449,
              December 2002, <http://www.rfc-editor.org/info/rfc3449>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R. and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <http://www.rfc-editor.org/info/rfc3550>.

   [RFC3819]  Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L.
              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
              RFC 3819, DOI 10.17487/RFC3819, July 2004, <http://www
              .rfc-editor.org/info/rfc3819>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
              December 2005, <http://www.rfc-editor.org/info/rfc4301>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, DOI
              10.17487/RFC4302, December 2005, <http://www.rfc-
              editor.org/info/rfc4302>.

Fairhurst              Expires December 02, 2017               [Page 30]
Internet-Draft            Transport Encryption                 June 2017

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, DOI 10.17487/RFC4303, December 2005, <http://www
              .rfc-editor.org/info/rfc4303>.

   [RFC4585]  Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey,
              "Extended RTP Profile for Real-time Transport Control
              Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI
              10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/
              info/rfc4585>.

   [RFC4737]  Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.
              and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI
              10.17487/RFC4737, November 2006, <http://www.rfc-
              editor.org/info/rfc4737>.

   [RFC5236]  Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R.
              Whitner, "Improved Packet Reordering Metrics", RFC 5236,
              DOI 10.17487/RFC5236, June 2008, <http://www.rfc-
              editor.org/info/rfc5236>.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
              RFC5246, August 2008, <http://www.rfc-editor.org/info/
              rfc5246>.

   [RFC5559]  Eardley, P., Ed., "Pre-Congestion Notification (PCN)
              Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009,
              <http://www.rfc-editor.org/info/rfc5559>.

   [RFC5925]  Touch, J., Mankin, A. and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <http://www.rfc-editor.org/info/rfc5925>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6437]  Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme,
              "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/
              RFC6437, November 2011, <http://www.rfc-editor.org/info/
              rfc6437>.

   [RFC6679]  Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.
              and K. Carlberg, "Explicit Congestion Notification (ECN)
              for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
              2012, <http://www.rfc-editor.org/info/rfc6679>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

Fairhurst              Expires December 02, 2017               [Page 31]
Internet-Draft            Transport Encryption                 June 2017

   [RFC7525]  Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations
              for Secure Use of Transport Layer Security (TLS) and
              Datagram Transport Layer Security (DTLS)", BCP 195, RFC
              7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-
              editor.org/info/rfc7525>.

   [RFC7567]  Baker, F.Ed.,  and G. Fairhurst, Ed., "IETF
              Recommendations Regarding Active Queue Management", BCP
              197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <http://
              www.rfc-editor.org/info/rfc7567>.

   [RFC7624]  Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
              Trammell, B., Huitema, C. and D. Borkmann,
              "Confidentiality in the Face of Pervasive Surveillance: A
              Threat Model and Problem Statement", RFC 7624, DOI
              10.17487/RFC7624, August 2015, <http://www.rfc-editor.org/
              info/rfc7624>.

   [RFC7713]  Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx)
              Concepts, Abstract Mechanism, and Requirements", RFC 7713,
              DOI 10.17487/RFC7713, December 2015, <http://www.rfc-
              editor.org/info/rfc7713>.

   [RFC7928]  Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed.,  and D.
              Ros, "Characterization Guidelines for Active Queue
              Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July
              2016, <http://www.rfc-editor.org/info/rfc7928>.

   [RFC8084]  Fairhurst, G., "Network Transport Circuit Breakers", BCP
              208, RFC 8084, DOI 10.17487/RFC8084, March 2017, <http://
              www.rfc-editor.org/info/rfc8084>.

   [RFC8085]  Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage
              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
              March 2017, <http://www.rfc-editor.org/info/rfc8085>.

   [RFC8086]  Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in-
              UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March
              2017, <http://www.rfc-editor.org/info/rfc8086>.

   [RFC8087]  Fairhurst, G. and M. Welzl, "The Benefits of Using
              Explicit Congestion Notification (ECN)", RFC 8087, DOI
              10.17487/RFC8087, March 2017, <http://www.rfc-editor.org/
              info/rfc8087>.

   [Tor]      The Tor Project,  ., "https://www.torproject.org", June
              2017.

Appendix A.  Revision information

   -00 This is an individual draft for the IETF community

Fairhurst              Expires December 02, 2017               [Page 32]
Internet-Draft            Transport Encryption                 June 2017

   -01 This draft was a result of walking away from the text for a few
   days and then reorganising the content.  Comments from the community
   are welcome on the text and recommendations.

Author's Address

   Godred Fairhurst
   University of Aberdeen
   Department of Engineering
   Fraser Noble Building
   Aberdeen, AB24 3UE
   Scotland
   
   Email: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk/

Fairhurst              Expires December 02, 2017               [Page 33]