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]