idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2018) is 2262 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1308, but no explicit reference was found in the text == Unused Reference: 'I-D.dolson-plus-middlebox-benefits' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ippm-6man-pdm-option' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-accurate-ecn' is defined on line 1354, but no explicit reference was found in the text == Unused Reference: 'I-D.trammell-plus-statefulness' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: 'RFC3449' is defined on line 1414, but no explicit reference was found in the text == Unused Reference: 'RFC3819' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: 'RFC5559' is defined on line 1463, but no explicit reference was found in the text == Unused Reference: 'RFC6679' is defined on line 1485, but no explicit reference was found in the text == Unused Reference: 'RFC7713' is defined on line 1512, but no explicit reference was found in the text == Unused Reference: 'Tor' is defined on line 1549, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-aqm-codel-00 == Outdated reference: A later version (-06) exists of draft-ietf-aqm-fq-codel-00 == Outdated reference: A later version (-10) exists of draft-ietf-aqm-pie-00 == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-10 == Outdated reference: A later version (-17) exists of draft-ietf-ippm-ioam-data-01 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-03 == Outdated reference: A later version (-28) exists of draft-ietf-tcpm-accurate-ecn-00 == Outdated reference: A later version (-20) exists of draft-ietf-tsvwg-l4s-arch-00 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-11 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 23 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Intended status: Informational C.S. Perkins 5 Expires: August 11, 2018 University of Glasgow 6 February 9, 2018 8 The Impact of Transport Header Confidentiality on Network Operation and 9 Evolution of the Internet 10 draft-fairhurst-tsvwg-transport-encrypt-06 12 Abstract 14 This document describes implications of applying end-to-end 15 encryption at the transport layer. It identifies in-network uses of 16 transport layer header information. It then reviews the implications 17 of developing end-to-end transport protocols that use encryption to 18 provide confidentiality of the transport protocol header and expected 19 implications of transport protocol design and network operation. 20 Since transport measurement and analysis of the impact of network 21 characteristics have been important to the design of current 22 transport protocols, it also considers the impact on transport and 23 application evolution. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 11, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Current uses of Transport Headers within the Network . . . . . 8 60 2.1. Observing Transport Information in the Network . . . . . . 8 61 2.1.1. Flow Identification . . . . . . . . . . . . . . . . . 9 62 2.1.2. Metrics derived from Transport Layer Headers . . . . . 9 63 2.1.3. Metrics derived from Network Layer Headers . . . . . . 12 64 2.2. Transport Measurement . . . . . . . . . . . . . . . . . . 14 65 2.2.1. Point of Measurement . . . . . . . . . . . . . . . . . 14 66 2.2.2. Use by Operators to Plan and Provision Networks . . . 15 67 2.2.3. Service Performance Measurement . . . . . . . . . . . 15 68 2.2.4. Measuring Transport to Support Network Operations . . 16 69 2.3. Use for Network Diagnostics and Troubleshooting . . . . . 17 70 2.3.1. Examples of measurements . . . . . . . . . . . . . . . 17 71 2.4. Observing Headers to Implement Network Policy . . . . . . 18 72 3. Encryption and Authentication of Transport Headers . . . . . . 18 73 3.1. Authenticating the Transport Protocol Header . . . . . . . 20 74 3.2. Encrypting the Transport Payload . . . . . . . . . . . . . 20 75 3.3. Encrypting the Transport Header . . . . . . . . . . . . . 20 76 3.4. Authenticating Transport Information and Selectively 77 Encrypting the Transport Header . . . . . . . . . . . . . 21 78 3.5. Optional Encryption of Header Information . . . . . . . . 21 79 4. Addition of Transport Information to Network-Layer Protocol 80 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 5. Implications of Protecting the Transport Headers . . . . . . . 22 82 5.1. Independent Measurement . . . . . . . . . . . . . . . . . 22 83 5.2. Characterising "Unknown" Network Traffic . . . . . . . . . 23 84 5.3. Accountability and Internet Transport Protocols . . . . . 23 85 5.4. Impact on Research, Development and Deployment . . . . . . 24 86 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 92 10.2. Informative References . . . . . . . . . . . . . . . . . 28 93 Appendix A. Revision information . . . . . . . . . . . . . . . . . 32 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 96 1. Introduction 97 This document describes implications of applying end-to-end 98 encryption at the transport layer. It reviews the implications of 99 developing end-to-end transport protocols that use encryption to 100 provide confidentiality of the transport protocol header and expected 101 implications of transport protocol design and network operation. It 102 also considers anticipated implications on transport and application 103 evolution. 105 The transport layer provides the first end-to-end interactions across 106 the Internet. Transport protocols layer directly over the network- 107 layer service and are sent in the payload of network-layer packets. 108 They support end-to-end communication between applications, supported 109 by higher-layer protocols, running on the end systems (or transport 110 endpoints). This simple architectural view hides one of the core 111 functions of the transport, however - to discover and adapt to the 112 properties of the Internet path that is currently being used. The 113 design of Internet transport protocols is as much about trying to 114 avoid the unwanted side effects of congestion on a flow and other 115 capacity-sharing flows, avoiding congestion collapse, adapting to 116 changes in the path characteristics, etc., as it is about end-to-end 117 feature negotiation, flow control and optimising for performance of a 118 specific application. 120 To achieve stable Internet operations the IETF transport community 121 has to date relied heavily on measurement and insights of the network 122 operations community to understand the trade-offs, and to inform 123 selection of appropriate mechanisms, to ensure a safe, reliable, and 124 robust Internet (e.g., [RFC1273]). In turn, the network operations 125 community relies on being able to understand the pattern and 126 requirements of traffic passing over the Internet, both in aggregate 127 and at the flow level - inspecting transport layer headers to help 128 understand traffic dynamics. 130 There are many motivations for deploying encrypted transports (i.e., 131 transport protocols that use encryption to provide confidentiality of 132 some or all of the transport-layer header information), and 133 encryption of transport payloads (i.e. Confidentiality of the 134 payload data). The increasing public concerns about the interference 135 with Internet traffic have led to a rapidly expanding deployment of 136 encryption to protect end-user privacy, in protocols like QUIC, but 137 also expected to forma a basis of future protocol designs. 139 Introducing cryptographic integrity checks to header fields can also 140 prevent undetected manipulation of the field by network devices. 141 However, it does not prevent inspection of the information by device 142 on path, and it is possible that such devices could develop 143 mechanisms that rely on the presence of such a field, or a known 144 value in the field. This leads to ossification of the header: An 145 endpoint could be required to supply the header to receive the 146 network service that it desires. In some cases, this could be benign 147 to the protocol (e.g., recognising the start of a connection), but in 148 other cases, any change to the protocol use of a specific header can 149 have undesirable implications (e.g., a mechanism implemented in a 150 network device, such as a firewall, that requires a header field to 151 have only a specific known set of values could prevent the device 152 from forwarding packets using a different version of a protocol that 153 introduces a new feature that changes the value present in this 154 field). A protocol that intentionally varies the format and value of 155 header fields (sometimes known as Greasing) has been suggested as a 156 way to help avoid such ossification of the transport protocol. 158 Implementations of network devices are encouraged to avoid side- 159 effects when protocols are updated. In particular, it is important 160 that protocols either do not expose information where the usage may 161 change in future protocols, or that methods that utilise the 162 information are robust to potential changes as protocols evolve over 163 time. 165 At the same time, some network operators and access providers, have 166 come to rely on the in-network measurement of transport properties 167 and the functionality provided by middleboxes to both support network 168 operations and enhance performance (e.g., [I-D.dolson-plus-middlebox- 169 benefits]). 171 A protocol design can use header encryption to provide 172 confidentiality of some or all of the protocol header information. 173 This prevents an on-path device from knowledge of the header field. 174 It therefore prevents mechanisms being built that directly rely on 175 the information or seeks to imply semantics of an exposed header 176 field. Protocol designers have often ignored these implications and 177 this document suggests that exposure of information should be 178 carefully considered when specifying new protocols. 180 Using encryption to provide confidentiality of the transport layer 181 brings some well-known privacy and security benefits. While a 182 protocol design that encrypts (hides) all the transport information 183 can help reduce ossification of the transport layer, it could result 184 in ossification of the network service. There can be advantages in 185 providing a level of ossification of the header in terms of providing 186 a set of specified header fields that are observable from in-network 187 devices. 189 There can also be implications when working with encrypted transport 190 protocols that hide transport header information from the network. 191 This present architectural challenges and considerations in the way 192 transport protocols are designed, and ability to characterise and 193 compare different transport solutions [Measure]. This results in 194 trade-offs around authentication, and confidentiality of transport 195 protocol headers and the potential support for other uses of this 196 header information. For example, it can impact the following 197 activities that rely on measurement and analysis of traffic flows: 199 Network Operations and Research: Observable transport headers enable 200 both operators and the research community to measure and analyse 201 protocol performance, network anomalies, and failure pathologies. 203 This information can help inform capacity planning, and assist in 204 determining the need for equipment and/or configuration changes by 205 network operators. 207 This data information can inform Internet engineering research, 208 and help the development of new protocols, methodologies, and 209 procedures. Hiding the entire transport protocol, including 210 header information, will restrict the availability of data, and 211 might lead to the development of alternative, and potentially more 212 intrusive, methods to acquire the needed data. 214 Providing confidentiality of the transport payload, but leaving 215 some, or all, of the transport headers unencrypted, possibly with 216 authentication, can provide the majority of the privacy and 217 security benefits while allowing some measurement. 219 Protection from Denial of Service: Observable transport headers can 220 provide useful input to classification of traffic and detection of 221 anomalous events, such as distributed denial of service attacks. 222 To be effective, this protection needs to be able to uniquely 223 disambiguate unwanted traffic. An inability to separate this 224 traffic using packet header information is expected to lead to 225 less precise pattern matching techniques or resort to 226 indiscriminately (rate) limiting uncharacterised traffic. 228 Network Troubleshooting and Diagnostics: Encrypting transport header 229 information eliminates the incentive for operators to troubleshoot 230 what they cannot interpret. A flow experiencing packet loss looks 231 like an unaffected flow when only observing network layer headers 232 (if transport sequence numbers and flow identifiers are obscured). 233 This limits understanding of the impact of packet loss on the 234 flows that share a network segment. Encrypted traffic therefore 235 implies "don't touch", and a likely trouble-shooting response will 236 be "can't help, no trouble found". The additional mechanisms that 237 will need to be introduced to help reconstruct transport-level 238 metrics add complexity and operational costs [I-D.mm-wg-effect- 239 encrypt]. 241 Network Traffic Analysis: Hiding transport protocol header 242 information can make it harder to determine which transport 243 protocols and features are being used across a network segment. 244 The trends in usage. This could impact the ability for an 245 operator to anticipate the need for network upgrades and roll-out. 246 It can also impact the on-going traffic engineering activities 247 performed by operators. While the impact may, in many cases, be 248 small there are scenarios where operators directly support 249 particular services (e.g., in radio links, or to troubleshoot 250 issues relating to Quality of Service, QoS; the ability to perform 251 fast re-routing of critical traffic, or support to mitigate the 252 characteristics of specific radio links). The more complex the 253 underlying infrastructure the more important this impact. 255 Open and Verifiable Network Data: The Hiding transport protocol 256 header information can reduces the range of actors that can 257 capture useful measurement data. This is, of course, its goal. 258 Doing so, however, limits the information sources available to the 259 Internet community to understand the operation of transport 260 protocols, so preventing access to the information necessary to 261 inform design decisions and standards for new protocols and 262 related operational practices. 264 There are dangers in a model where only endpoints (i.e., at user 265 devices and within service platforms) can observe performance, and 266 this cannot be independently verified. 268 To ensure the health of the standards and research communities, we 269 need independently captured data to develop new transport protocol 270 mechanisms based on the behaviour experienced in deployed 271 networks. 273 Independently verifiable performance metrics might also important 274 in order to demonstrate regulatory compliance in some 275 jurisdictions. 277 The last point leads us to consider the impact of hiding transport 278 headers in the specification and development of protocols and 279 standards. This has potential impact on: 281 o Understanding Feature Interactions: An appropriate vantage point, 282 coupled with timing information about traffic flows, provides a 283 valuable tool for benchmarking equipment, functions, and/or 284 configurations, and to understand complex feature interactions. 285 An inability to observe transport protocol information can limit 286 the ability to diagnose and explore interactions between features 287 at different protocol layers, a side-effect of not allowing a 288 choice of vantage point from which this information is observed. 290 o Supporting Common Specifications: The Transmission Control 291 Protocol (TCP) is the predominant transport protocol used over 292 Internet paths. Its many variants have broadly consistent 293 approaches to avoiding congestion collapse, and to ensuring the 294 stability of the network. Increased use of transport layer 295 encryption can overcome ossification, allowing deployment of new 296 transports and different types of congestion control. This 297 flexibility can be beneficial, but it can come at the cost of 298 fragmenting the ecosystem. There is little doubt that developers 299 will try to produce high quality transports for their target uses, 300 but it is not clear there are sufficient incentives to ensure good 301 practice that benefits the wide diversity of requirements for the 302 Internet community as a whole. Increased diversity, and the 303 ability to innovate without public scrutiny, risks point solutions 304 that optimise for specific needs, but accidentally disrupt 305 operations of/in different parts of the network. The social 306 contract that maintains the stability of the network relies on 307 accepting common specifications, and on the ability to verify that 308 others also conform. 310 o Operational practice: Published transport specifications allow 311 operators to check compliance. This can bring assurance to those 312 operating networks, often avoiding the need to deploy complex 313 techniques that routinely monitor and manage TCP/IP traffic flows 314 (e.g. Avoiding the capital and operational costs of deploying 315 flow rate-limiting and network circuit-breaker methods [RFC8084]). 316 When it is not possible to observe transport header information, 317 methods are still needed to confirm that the traffic produced 318 conforms to the expectations of the operator or developer. 320 o Restricting research and development: Hiding transport information 321 can impede independent research into new mechanisms, measurement 322 of behaviour, and development initiatives. Experience shows that 323 transport protocols are complicated to design and complex to 324 deploy, and that individual mechanisms need to be evaluated while 325 considering other mechanisms, across a broad range of network 326 topologies and with attention to the impact on traffic sharing the 327 capacity. Hiding transport header information (e.g., by pervasive 328 encryption of transport information) could eliminate the 329 independent self-checks that have previously been in place from 330 research and academic contributors (e.g., the role of the IRTF 331 ICCRG, and research publications in reviewing new transport 332 mechanisms and assessing the impact of their experimental 333 deployment). 335 In summary, a lack of visibility of transport header information can 336 impact the ways that protocols are designed, standardised, deployed, 337 and operated. The choice of whether future transport protocols 338 encrypt their protocol headers therefore needs to be taken based not 339 solely on security and privacy considerations, but also taking into 340 account the impact on operations, standards, and research. A network 341 that is secure but unusable due to persistent congestion collapse is 342 not an improvement, and while that would be an extreme outcome 343 proposals that impose high costs for very limited benefits need to be 344 considered carefully, to ensure the benefits outweigh the costs. 346 2. Current uses of Transport Headers within the Network 348 Despite transport headers having end-to-end meaning, some of these 349 transport headers have come to be used in various ways within the 350 Internet. In response to pervasive monitoring [RFC7624] revelations 351 and the IETF consensus that "Pervasive Monitoring is an Attack" 352 [RFC7258], efforts are underway to increase encryption of Internet 353 traffic,. Applying confidentiality to transport header fields would 354 affect how network protocols are designed and used [I-D.mm-wg-effect- 355 encrypt]. To understand these implications, it is first necessary to 356 understand how transport layer headers are currently observed and/or 357 modified by middleboxes within the network. 359 Transport protocols can be designed to encrypt or authenticate 360 transport header fields. Authentication methods at the transport 361 layer can be used to detect any changes to an immutable header field 362 that were made by a network device along a path. The intentional 363 modification of transport headers by middleboxes (such as Network 364 Address Translation, NAT, or Firewalls) is not considered. Common 365 issues concerning IP address sharing are described in [RFC6269]. 367 2.1. Observing Transport Information in the Network 369 In-network observation of transport protocol headers requires 370 knowledge of the format of the transport header: 372 o Flows need to be identified at the level required for monitoring; 373 o The protocol and version of the header need to be observable. As 374 protocols evolve over time and there may be a need to introduce 375 new transport headers. This may require interpretation of 376 protocol version information or connection setup information; 378 o Location and syntax of any transport headers to be observed. IETF 379 transport protocols specify this information. 381 The following subsections describe various ways that observable 382 transport information may be utilised. 384 2.1.1. Flow Identification 386 Transport protocol header information (with information in the 387 network header), can identify a flow and the connection state of the 388 flow, together with the protocol options being used. In some usages, 389 a low-numbered (well-known ) port number can identify a protocol 390 (although port information alone is not sufficient to guarantee 391 identification of a protocol). Transport protocols, such as TCP and 392 Stream Control Transport Protocol (SCTP) specify a standard base 393 header that includes sequence number information and other data, with 394 the possibility to negotiate additional headers at connection setup, 395 identified by an option number in the transport header. UDP-based 396 protocols can use, but sometimes do not use, well-known port numbers. 397 Some can instead be identified by signalling protocols or through the 398 use of magic numbers placed in the first byte(s) of the datagram 399 payload. 401 Flow identification is more complex and less easily achieved when 402 multiplexing is used at or above the transport layer. 404 2.1.2. Metrics derived from Transport Layer Headers 406 Some actors have a need to characterise the performance of link/ 407 network segments. Passive monitoring uses observed traffic to makes 408 inferences from transport headers to derive these measurements. A 409 variety of open source and commercial tools have been deployed that 410 utilise this information. The following metrics can be derived from 411 transport header information: 413 Traffic Rate and Volume: Header information e.g., (sequence number, 414 length) may allow derivation of volume measures per-application, 415 to characterise the traffic that uses a network segment or the 416 pattern of network usage. This may be measured per endpoint or 417 for an aggregate of endpoints (e.g., by an operator to assess 418 subscriber usage). It can also be used to trigger measurement- 419 based traffic shaping and to implement QoS support within the 420 network and lower layers. Volume measures can be valuable for 421 capacity planning (providing detail of trends rather than the 422 volume per subscriber). 424 Loss Rate and Loss Pattern: Flow loss rate may be derived (e.g., from 425 sequence number) and is often used as a metric for performance 426 assessment and to characterise transport behaviour. Understanding 427 the root cause of loss can help an operator determine whether this 428 requires corrective action. Network operators may also use the 429 variation in patterns of loss as a key performance metric, 430 utilising this to detect changes in the offered service. 432 There are various cause of loss, including: corruption on a link 433 (e.g., interference on a radio link), buffer overflow (e.g., due 434 to congestion), policing (traffic management), buffer management 435 (e.g., Active Queue Management, AQM), inadequate provision of 436 traffic preemption. Understanding flow loss rate requires either 437 maintaining per flow packet counters or by observing sequence 438 numbers in transport headers. Loss can be monitored at the 439 interface level by devices in the network. It is often important 440 to understand the conditions under which packet loss occurs. This 441 usually requires relating loss to the traffic flowing on the 442 network node/segment at the time of loss. 444 Observation of transport feedback information (observing loss 445 reports, e.g., RTP Control Protocol (RTCP), TCP SACK) can increase 446 understanding of the impact of loss and help identify cases where 447 loss may have been wrongly identified, or the transport did not 448 require the lost packet. It is sometimes more important to 449 understand the pattern of loss, than the loss rate - since losses 450 can often occur as bursts, rather than randomly-timed events. 452 Throughput and Goodput: The throughput observed by a flow can be 453 determined even when a flow is encrypted, providing the individual 454 flow can be identified. Goodput [RFC7928] is a measure of useful 455 data exchanged (the ratio of useful/total volume of traffic sent 456 by a flow), which requires ability to differentiate loss and 457 retransmission of packets (e.g., by observing packet sequence 458 numbers in the TCP or the Real Time Protocol, RTP, headers 459 [RFC3550]). 461 Latency: Latency is a key performance metric that impacts application 462 response time and user-perceived response time. It often 463 indirectly impacts throughput and flow completion time. Latency 464 determines the reaction time of the transport protocol itself, 465 impacting flow setup, congestion control, loss recovery, and other 466 transport mechanisms. The observed latency can have many 467 components [Latency]. Of these, unnecessary/unwanted queuing in 468 network buffers has often been observed as a significant factor. 469 Once the cause of unwanted latency has been identified, this can 470 often be eliminated, and determining latency metrics is a key 471 driver in the deployment of AQM [RFC7567], DiffServ [RFC2474], and 472 Explicit Congestion Notification (ECN) [RFC3168] [RFC8087]. 474 To measure latency across a part of a path, an observation point 475 can measure the experienced round trip time (RTT) using packet 476 sequence numbers, and acknowledgements, or by observing header 477 timestamp information. Such information allows an observation 478 point in the network to determine not only the path RTT, but also 479 to measure the upstream and downstream contribution to the RTT. 480 This may be used to locate a source of latency, e.g., by observing 481 cases where the ratio of median to minimum RTT is large for a part 482 of a path. 484 An example usage of this method could identify excessive buffers 485 to help deploy or configure AQM [RFC7567] [RFC7928] to effectively 486 eliminate unnecessary queuing in routers and other devices. AQM 487 methods need to be deployed at the capacity bottleneck, but are 488 often deployed in combination with other techniques, such as 489 scheduling [RFC7567] [I-D.ietf-aqm-fq-codel] and although 490 parameter-less methods are desired [RFC7567], current methods [I-D 491 .ietf-aqm-fq-codel] [I-D.ietf-aqm-codel] [I-D.ietf-aqm-pie] often 492 cannot scale across all possible deployment scenarios. The 493 service offered by operators can therefore benefit from latency 494 information to understand the impact of deployment and tune 495 deployed services. 497 Jitter: Some network applications are sensitive to changes in packet 498 timing. For such applications, it can be necessary to measure the 499 jitter observed along a portion of the path. The requirements to 500 measure jitter resemble those for the measurement of latency. 502 Flow Reordering: Significant flow reordering can impact time-critical 503 applications and can be interpreted as loss by reliable 504 transports. Many transport protocol techniques are impacted by 505 reordering (e.g., triggering TCP retransmission, or re-buffering 506 of real-time applications). Packet reordering can occur for many 507 reasons (from equipment design to misconfiguration of forwarding 508 rules). Since this impacts transport performance, network tools 509 are needed to detect and measure unwanted/excessive reordering. 511 As in the drive to reduce network latency, there is a need for 512 operational tools to detect mis-ordered packet flows and quantify 513 the degree or reordering. Techniques for measuring reordering 514 typically observe packet sequence numbers. Metrics have been 515 defined that evaluate whether a network has maintained packet 516 order on a packet-by-packet basis [RFC4737] and [RFC5236]. 518 There have been initiatives in the IETF transport area to reduce 519 the impact of reordering within a transport flow, possibly leading 520 to reduce the requirements for ordering. These have promise to 521 simplify network equipment design as well as the potential to 522 improve robustness of the transport service. Measurements of 523 reordering can help understand the level of reordering within 524 deployed infrastructure, and inform decisions about how to 525 progress such mechanisms. 527 Some protocols provide in-built monitoring and reporting functions. 528 Transport fields in the RTP header [RFC3550] [RFC4585] can be 529 observed to derive traffic volume measurements and provide 530 information on the progress and quality of a session using RTP. Key 531 performance indicators are retransmission rate, packet drop rate, 532 sector utilisation level, a measure of reordering, peak rate, the CE- 533 marking rate, etc. Metadata is often important to understand the 534 context under which the data was collected, including the time, 535 observation point, and way in which metrics were accumulated. The 536 RTCP protocol directly reports some of this information in a form 537 that can be directly visible in the network. A user of summary 538 measurement data needs to trust the source of this data and the 539 method used to generate the summary information. 541 When information in transport headers is concealed, measurements need 542 to rely on pattern inferences and other heuristics grows, and 543 accuracy suffers [I-D.mm-wg-effect-encrypt]. 545 2.1.3. Metrics derived from Network Layer Headers 547 Some transport information is made visible in the network-layer 548 protocol header. These header fields are not encrypted and can be 549 used to make flow observations. 551 Use of IPv6 Network-Layer Flow Label: Endpoints are encouraged expose 552 flow information in the IPv6 Flow Label field of the network-layer 553 header (e.g., [RFC8085]). This can be used to inform network-layer 554 queuing, forwarding (e.g., for equal cost multi-path (ECMP) 555 routing, and Link Aggregation, LAG). This can provide useful 556 information to assign packets to flows in the data collected by 557 measurement campaigns. Although important to characterising a 558 path, it does not directly provide any performance data. 560 Use Network-Layer Differentiated Services Code Point Point: Applicati 561 ons can expose their delivery expectations to the network by 562 setting the Differentiated Services Code Point (DSCP) field of 563 IPv4 and IPv6 packets. This can be used to inform network-layer 564 queuing and forwarding, and can also provide information on the 565 relative importance of packet information collected by measurement 566 campaigns, but does not directly provide any performance data. 568 This field provides explicit information that can be used in place 569 of inferring traffic requirements (e.g., by inferring QoS 570 requirements from port information via a multi-field classifier). 571 The DSCP value can therefore impact the quality of experience for 572 a flow. Observations of service performance need to consider this 573 field when a network path has support for differentiated service 574 treatment. 576 Use of Explicit Congestion Marking: ECN [RFC3168] is an optional 577 transport mechanism that uses a code point in the network-layer 578 header. Use of ECN can offer gains in terms of increased 579 throughput, reduced delay, and other benefits when used over a 580 path that includes equipment that supports an AQM method that 581 performs Congestion Experienced (CE) marking of IP packets 582 [RFC8087]. 584 ECN exposes the presence of congestion on a network path to the 585 transport and network layer. The reception of CE-marked packets 586 can therefore be used to monitor the presence and estimate the 587 level of incipient congestion on the upstream portion of the path 588 from the point of observation (Section 2.5 of [RFC8087]). Because 589 ECN marks carried in the IP protocol header, it is much easier to 590 measure ECN than metering packet loss. However, interpreting the 591 marking behaviour (i.e., assessing congestion and diagnosing 592 faults) requires context from the transport layer (path RTT, 593 visibility of loss - that could be due to queue overflow, 594 congestion response, etc) [RFC7567]. 596 Some ECN-capable network devices can provide richer (more frequent 597 and fine-grained) indication of their congestion state. Setting 598 congestion marks proportional to the level of congestion (e.g., 599 Data Center TCP, DCTP [RFC8257], and Low Latency Low Loss Scalable 600 throughput, L4S, [I-D.ietf-tsvwg-l4s-arch]. 602 Use of ECN requires a transport to feed back reception information 603 on the path towards the data sender. Exposure of this Transport 604 ECN feedback provides an additional powerful tool to understand 605 ECN-enabled AQM-based networks [RFC8087]. 607 AQM and ECN offer a range of algorithms and configuration options, 608 it is therefore important for tools to be available to network 609 operators and researchers to understand the implication of 610 configuration choices and transport behaviour as use of ECN 611 increases and new methods emerge [RFC7567] [RFC8087]. ECN- 612 monitoring is expected to become important as AQM is deployed that 613 supports ECN [RFC8087]. 615 2.2. Transport Measurement 617 The common language between network operators and application/content 618 providers/users is packet transfer performance at a layer that all 619 can view and analyse. For most packets, this has been transport 620 layer, until the emergence of QUIC, with the obvious exception of 621 VPNs and IPsec. When encryption conceals more layers in a packet, 622 people seeking understanding of the network operation need to rely 623 more on pattern inferences and other heuristics. The accuracy of 624 measurements therefore suffers, as does the ability to investigate 625 and troubleshoot interactions between different anomalies. For 626 example, the traffic patterns between a web server and a browser are 627 dependent on browser supplier and version, even use of the 628 application (e.g., web e-mail access). Even when measurement datasets 629 are made available (e.g., from endpoints) additional metadata, such 630 as the state of the network, is often required to interpret the data. 631 Collecting and coordinating such metadata is more difficult when the 632 observation point is at a different location to the bottleneck/device 633 under evaluation. 635 Packet sampling techniques can be used to scale the processing 636 involved in observing packets on high rate links. This exports only 637 the packet header information of (randomly) selected packets. The 638 utility of these measurements depends on the type of bearer and 639 number of mechanisms used by network devices. Simple routers are 640 relatively easy to manage, a device with more complexity demands 641 understanding of the choice of many system parameters. This level of 642 complexity exists when several network methods are combined. 644 This section discusses topics concerning observation of transport 645 flows, with a focus on transport measurement. 647 2.2.1. Point of Measurement 649 Often measurements can only be understood in the context of the other 650 flows that share a bottleneck. A simple example is monitoring of 651 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 652 queues (statistically assigned per flow), management of the queue 653 length (CODEL), flow-scheduling, and a starvation prevention 654 mechanism. Usually such algorithms are designed to be self-tuning, 655 but current methods typically employ heuristics that can result in 656 more loss under certain path conditions (e.g., large RTT, effects of 657 multiple bottlenecks [RFC7567]). 659 In-network measurements can distinguish between upstream and 660 downstream metrics with respect to a measurement point. These are 661 particularly useful for locating the source of problems or to assess 662 the performance of a network segment or a particular device 663 configuration. 665 By correlating observations of headers at multiple points along the 666 path (e.g., at the ingress and egress of a network segment), an 667 observer can determine the contribution of a portion of the path to 668 an observed metric (to locate a source of delay, jitter, loss, 669 reordering, congestion marking, etc.). 671 2.2.2. Use by Operators to Plan and Provision Networks 673 Traffic measurements (e.g., traffic volume, loss, latency) is used by 674 operators to help plan deployment of new equipment and configurations 675 in their networks. Data is also important to equipment vendors who 676 need to understand traffic trends and patterns of usage as inputs to 677 decisions about planning products and provisioning for new 678 deployments. This measurement information can also be correlated 679 with billing information when this is also collected by an operator. 681 A network operator supporting traffic that uses transport header 682 encryption may not have access to per-flow measurement data. Trends 683 in aggregate traffic can be observed and can be related this to the 684 endpoint addresses being used, but it may not be possible to 685 correlate patterns in measurements with changes in transport 686 protocols (e.g., the impact of changes in introducing a new transport 687 protocol mechanism). This increases the dependency on other indirect 688 sources of information to inform planning and provisioning. 690 2.2.3. Service Performance Measurement 692 Traffic measurements (e.g., traffic volume, loss, latency) can be 693 used by various actors to help analyse the performance offered to the 694 users of a network segment, and inform operational practice. 696 While active measurements may be used in-network passive measurements 697 can have advantages in terms of eliminating unproductive traffic, 698 reducing the influence of test traffic on the overall traffic mix, 699 and the ability to choose the point of measurement Section 2.2.1. 700 However, passive measurements may rely on observing transport 701 headers. 703 2.2.4. Measuring Transport to Support Network Operations 705 Information provided by tools observing transport headers can help 706 determine whether mechanisms are needed in the network to prevent 707 flows from acquiring excessive network capacity. Operators can 708 implement operational practices to manage traffic flows (e.g., to 709 prevent flows from acquiring excessive network capacity under severe 710 congestion) by deploying rate-limiters, traffic shaping or network 711 transport circuit breakers [RFC8084]. 713 Congestion Control Compliance of Traffic: Congestion control is a key 714 transport function. Many network operators implicitly accept that 715 TCP traffic to comply with a behaviour that is acceptable for use 716 in the shared Internet. TCP algorithms have been continuously 717 improved over decades, and they have reached a level of efficiency 718 and correctness that custom application-layer mechanisms will 719 struggle to easily duplicate [RFC8085]. 721 A standards-compliant TCP stack provides congestion control may 722 therefore be judged safe for use across the Internet. 723 Applications developed on top of well-designed transports can be 724 expected to appropriately control their network usage, reacting 725 when the network experiences congestion, by back-off and reduce 726 the load placed on the network. This is the normal expected 727 behaviour for TCP and SCTP. 729 However when anomalies are detected, tools can interpret the 730 transport protocol header information to help understand the 731 impact of specific transport protocols (or protocol mechanisms) on 732 the other traffic that shares a network. An observation in the 733 network can gain understanding of the dynamics of a flow and its 734 congestion control behaviour. Analysing observed packet sequence 735 numbers can be used to help build confidence that an application 736 flow backs-off its share of the network load in the face of 737 persistent congestion, and hence to understand whether the 738 behaviour is appropriate for sharing limited network capacity. 739 For example, it is common to visualise plots of TCP sequence 740 numbers versus time for a flow to understand how a flow shares 741 available capacity, deduce its dynamics in response to congestion, 742 etc. 744 Congestion Control Compliance for UDP traffic UDP provides a minimal 745 message-passing transport that has no inherent congestion control 746 mechanisms. Because congestion control is critical to the stable 747 operation of the Internet, applications and other protocols that 748 choose to use UDP as a transport are required to employ mechanisms 749 to prevent congestion collapse, avoid unacceptable contributions 750 to jitter/latency, and to establish an acceptable share of 751 capacity with concurrent traffic [RFC8085]. 753 A network operator needs tools to understand if UDP flows comply 754 with congestion control expectations and therefore whether there 755 is a need to deploy methods such as rate-limiters, transport 756 circuit breakers or other methods to enforce acceptable usage for 757 the offered service. 759 UDP flows that expose a well-known header by specifying the format 760 of header fields can allow information to be observed to gain 761 understanding of the dynamics of a flow and its congestion control 762 behaviour. For example, tools exist to monitor various aspects of 763 the RTP and RTCP header information of real-time flows (see 764 Section 2.1.2. 766 2.3. Use for Network Diagnostics and Troubleshooting 768 Transport header information is useful for a variety of operational 769 tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, 770 assess performance, capacity planning, management of denial of 771 service threats, and responding to user performance questions. These 772 tasks seldom involve the need to determine the contents of the 773 transport payload, or other application details. 775 A network operator supporting traffic that uses transport header 776 encryption can see only encrypted transport headers. This prevents 777 deployment of performance measurement tools that rely on transport 778 protocol information. Choosing to encrypt all information may be 779 expected to reduce the ability for networks to "help" (e.g., in 780 response to tracing issues, making appropriate Quality of Service, 781 QoS, decisions). For some this will be blessing, for others it may be 782 a curse. For example, operational performance data about encrypted 783 flows needs to be determined by traffic pattern analysis, rather than 784 relying on traditional tools. This can impact the ability of the 785 operator to respond to faults, it could require reliance on endpoint 786 diagnostic tools or user involvement in diagnosing and 787 troubleshooting unusual use cases or non-trivial problems. A key 788 need here is that tools need to provide useful information during 789 network anomalies (e.g., significant reordering, high or intermittent 790 loss). Although many network operators utilise transport information 791 as a part of their operational practice, the network will not break 792 because transport headers are encrypted. 794 2.3.1. Examples of measurements 795 Future versions of this document may provide more about existing 796 tooling at Network Operations Centres that rely upon observing 797 transport layer header information. 799 Debugging and diagnosing the root causes of faults concern particular 800 users traffic is an activity that may depend on connection 801 information from the protocol - In some case, this may involve active 802 injection of test traffic to complete a measurement. Most operators 803 do not have access to user equipment. There may also be costs 804 associated with running such tests (e.g., the implications of 805 bandwidth tests in a mobile network are obvious). Some active 806 measurements (e.g., response under load or particular workloads) may 807 perturb other traffic, and could require dedicated access to the 808 network segment. An alternative approach is to use in-network 809 techniques that observe transport packet headers in operational 810 networks to make the measurements. 812 in other cases, measurement involves dissecting traffic flows. The 813 observed transport layer information can help identify whether the 814 link/network tuning is effective and alert to potential problems that 815 can be hard to derive from link or device measurements alone. The 816 design trade-offs for radio networks are often very different to 817 those of wired networks. A radio-based network (e.g., cellular 818 mobile, enterprise WiFi, satellite access/back-haul, point-to-point 819 radio) has the complexity of a subsystem that performs radio resource 820 management - with direct impact on the available capacity, and 821 potentially loss/reordering of packets. The impact of the pattern of 822 loss and congestion, differs for different traffic types, correlation 823 with propagation and interference can all have significant impact on 824 the cost and performance of a provided service. The need for this 825 type of information is expected to increase as operators bring 826 together heterogeneous types of network equipment and seek to deploy 827 opportunistic methods to access radio spectrum. 829 XXX Note: The authors are looking for contributions that say more 830 about the things people are currently doing with exposed transport 831 fields and what problems they are trying to solve, or how they use 832 the information they derive. How problematic is new tools to follow- 833 up. Examples could include: Health monitoring; anomoly/DoS 834 detection; Capacity planning, etc XXX 836 2.4. Observing Headers to Implement Network Policy 838 Information from the transport protocol can be used by a multi-field 839 classifier as a part of policy framework. Policies are commonly used 840 for QoS management for resource-constrained networks and by firewalls 841 that use the information to implement access rules. Traffic that 842 cannot be classified, will typically receive a default treatment. 844 3. Encryption and Authentication of Transport Headers 845 End-to-end encryption can be applied at various protocol layers. It 846 can be applied above the transport to encrypt the transport payload. 847 Encryption methods can hide information from an eavesdropper in the 848 network. Encryption can also help protect the privacy of a user, by 849 hiding data relating to user/device identity or location. Neither an 850 integrity check nor encryption methods prevent traffic analysis, and 851 usage needs to reflect that profiling of users, identification of 852 location and fingerprinting of behaviour can take place even on 853 encrypted traffic flows. 855 One motive to use encryption is a response to perceptions that the 856 network has become ossified by over-reliance on middleboxes that 857 prevent new protocols and mechanisms from being deployed. This has 858 lead to a common perception that there is too much "manipulation" of 859 protocol headers within the network, and that designing to deploy in 860 such networks is preventing transport evolution. In the light of 861 this, a method that authenticates transport headers may help improve 862 the pace of transport development, by eliminating the need to always 863 consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or 864 potentially to only explicitly enable middlebox use for particular 865 paths with particular middleboxes that are deliberately deployed to 866 realise a useful function for the network and/or users[RFC3135]. 868 Another motivation stems from increased concerns about privacy and 869 surveillance. Some Internet users have valued the ability to protect 870 identity, user location, and defend against traffic analysis, and 871 have used methods such as IPsec ESP. Revelations about the use of 872 pervasive surveillance [RFC7624] have, to some extent, eroded trust 873 in the service offered by network operators, and following the 874 Snowden revelation in the USA in 2013 has led to an increased desire 875 for people to employ encryption to avoid unwanted "eavesdropping" on 876 their communications. Whatever the reasons, there are now activities 877 in the IETF to design new protocols that may include some form of 878 transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]). 880 Authentication methods (that provide integrity checks of protocols 881 fields) have also been specified at the network layer, and this also 882 protects transport header fields. The network layer itself carries 883 protocol header fields that are increasingly used to help forwarding 884 decisions reflect the need of transport protocols, such the IPv6 Flow 885 Label [RFC6437], the DSCP and ECN. 887 The use of transport layer authentication and encryption exposes a 888 tussle between middlebox vendors, operators, applications developers 889 and users. 891 o On the one hand, future Internet protocols that enable large-scale 892 encryption assist in the restoration of the end-to-end nature of 893 the Internet by returning complex processing to the endpoints, 894 since middleboxes cannot modify what they cannot see. 896 o On the other hand, encryption of transport layer header 897 information has implications for people who are responsible for 898 operating networks and researchers and analysts seeking to 899 understand the dynamics of protocols and traffic patterns. 901 Whatever the motives, a decision to use pervasive of transport header 902 encryption will have implications on the way in which design and 903 evaluation is performed, and which can in turn impact the direction 904 of evolution of the TCP/IP stack. 906 The next subsections briefly review some security design options for 907 transport protocols. 909 3.1. Authenticating the Transport Protocol Header 911 Transport layer header information can be authenticated. An 912 integrity check that protects the immutable transport header fields, 913 but can still expose the transport protocol header information in the 914 clear, allowing in-network devices to observes these fields. An 915 integrity check can not prevent in-network modification, but can 916 avoid a receiving accepting changes and avoid impact on the transport 917 protocol operation. 919 An example transport authentication mechanism is TCP-Authentication 920 (TCP-AO) [RFC5925]. This TCP option authenticates TCP segments, 921 including the IP pseudo header, TCP header, and TCP data. TCP-AO 922 protects the transport layer, preventing attacks from disabling the 923 TCP connection itself. TCP-AO may interact with middleboxes, 924 depending on their behaviour [RFC3234]. 926 The IPsec Authentication Header (AH) [RFC4302] was designed to work 927 at the network layer and authenticate the IP payload. This approach 928 authenticates all transport headers, and verifies their integrity at 929 the receiver, preventing in-network modification. 931 3.2. Encrypting the Transport Payload 933 The transport layer payload can be encrypted to protect the content 934 of transport segments. This leaves transport protocol header 935 information in the clear. The integrity of immutable transport 936 header fields could be protected by combining this with an integrity 937 check (Section 3.1). 939 Examples of encrypting the payload include Transport Layer Security 940 (TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP 941 [RFC6347] [RFC7525]. 943 3.3. Encrypting the Transport Header 945 The network layer payload could be encrypted (including the entire 946 transport header and payload). This method does not expose any 947 transport information to devices in the network, which also prevents 948 modification along a network path. 950 The IPsec Encapsulating Security Payload (ESP) [RFC4303] is an 951 example of encryption at the network layer, it encrypts and 952 authenticates all transport headers, preventing visibility of the 953 headers by in-network devices. Some Virtual Private Network (VPN) 954 methods also encrypt these headers. 956 3.4. Authenticating Transport Information and Selectively Encrypting 957 the Transport Header 959 A transport protocol design can encrypt selected header fields, while 960 also choosing to authenticate fields in the transport header. This 961 allows specific transport header fields to be made observable by 962 network devices. End-to end integrity checks can prevent an endpoint 963 from undetected modification of the immutable transport headers. 965 The choice of which fields to expose and which to encrypt is a design 966 choice for the transport protocol. Any selective encryption method 967 requires trading two conflicting goals for a transport protocol 968 designer to decide which header fields to encrypt. On the one hand, 969 security work typically employs a design technique that seeks to 970 expose only what is needed. On the other hand, there may be 971 performance and operational benefits in exposing selected information 972 to network tools. 974 Mutable fields in the transport header provide opportunities for 975 middleboxes to modify the transport behaviour (e.g., the extended 976 headers described in [I-D.trammell-plus-abstract-mech]). This 977 considers only immutable fields in the transport headers, that is, 978 fields that may be authenticated End-to-End across a path. 980 An example of a method that encrypts some, but not all, transport 981 information is GRE-in-UDP [RFC8086] when used with GRE encryption. 983 3.5. Optional Encryption of Header Information 985 There are implications to the use of optional header encryption in 986 the design of a transport protocol, where support of optional 987 mechanisms can increase the complexity of the protocol and its 988 implementation and in the management decisions that are required to 989 use variable format fields. Instead, fields of a specific type ought 990 to always be sent with the same level of confidentiality or integrity 991 protection. 993 4. Addition of Transport Information to Network-Layer Protocol Headers 995 The transport information can be made visible in a network-layer 996 header. This has the advantage that this information can then be 997 observed by in-network devices. This has the advantage that a single 998 header can support all transport protocols, but there may also be 999 less desirable implications of separating the operation of the 1000 transport protocol from the measurement framework. 1002 Some measurements may be made by adding additional protocol headers 1003 carrying operations, administration and management (OAM) information 1004 to packets at the ingress to a maintenance domain (e.g., an Ethernet 1005 protocol header with timestamps and sequence number information using 1006 a method such as 802.11ag or in-situ OAM [I-D.ietf-ippm-ioam-data]) 1007 and removing the additional header at the egress of the maintenance 1008 domain. This approach enables some types of measurements, but does 1009 not cover the entire range of measurements described in this 1010 document. In some cases, it can be difficult to position measurement 1011 tools at the required segments/nodes and there can be challenges in 1012 correlating the downsream/upstream information when in-band OAM data 1013 is inserted by an on-path device. 1015 Another example of a network-layer approach is the IPv6 Performance 1016 and Diagnostic Metrics (PDM) Destination Option [I-D.ietf-ippm-6man- 1017 pdm-option]. This allows a sender to optionally include a 1018 destination option that caries header fields that can be used to 1019 observe timestamps and packet sequence numbers. This information 1020 could be authenticated by receiving transport endpoints when the 1021 information is added at the sender and visible at the receiving 1022 endpoint, although methods to do this have not currently been 1023 proposed. This method needs to be explicitly enabled at the sender. 1025 It can be undesirable to rely on methods requiring options or 1026 extension headers. IPv4 network options are often not supported (or 1027 are carried on a slower processing path) and some IPv6 networks are 1028 also known to drop packets that set an IPv6 header extension (e.g., 1029 [RFC7872]). Another disadvantage is that protocols that separately 1030 expose header information do not necessarily have an advantage to 1031 expose the information that is utilised by the protocol itself, and 1032 could manipulate this header information to gain an advantage from 1033 the network. 1035 5. Implications of Protecting the Transport Headers 1037 This section explores key implications of working with encrypted 1038 transport protocols. 1040 5.1. Independent Measurement 1042 Independent observation by multiple actors is important for 1043 scientific analysis. Encrypting transport header encryption changes 1044 the ability for other actors to collect and independently analyse 1045 data. Internet transport protocols employ a set of mechanisms. Some 1046 of these need to work in cooperation with the network layer - loss 1047 detection and recovery, congestion detection and congestion control, 1048 some of these need to work only End-to-End (e.g., parameter 1049 negotiation, flow-control). 1051 When encryption conceals information in the transport header, it 1052 could be possible for an applications to provide summary data on 1053 performance and usage of the network. This data could be made 1054 available to other actors. However, this data needs to contain 1055 sufficient detail to understand (and possibly reconstruct the network 1056 traffic pattern for further testing) and to be correlated with the 1057 configuration of the network paths being measured. Sharing 1058 information between actors needs also to consider the privacy of the 1059 user and the incentives for providing accurate and detailed 1060 information. Protocols that expose the state information used by the 1061 transport protocol in their header information (e.g., timestamps used 1062 to calculate the RTT, packet numbers used to asses congestion and 1063 requests for retransmission) provide an incentive for the sending 1064 endpoint to provide correct information, increasing confidence that 1065 the observer understands the transport interaction with the network. 1066 This becomes important when considering changes to transport 1067 protocols, changes in network infrastructure, or the emergence of new 1068 traffic patterns. 1070 5.2. Characterising "Unknown" Network Traffic 1072 The patterns and types of traffic that share Internet capacity 1073 changes with time as networked applications, usage patterns and 1074 protocols continue to evolve. 1076 If "unknown" or "uncharacterised" traffic patterns form a small part 1077 of the traffic aggregate passing through a network device or segment 1078 of the network the path, the dynamics of the uncharacterised traffic 1079 may not have a significant collateral impact on the performance of 1080 other traffic that shares this network segment. Once the proportion 1081 of this traffic increases, the need to monitor the traffic and 1082 determine if appropriate safety measures need to be put in place. 1084 Tracking the impact of new mechanisms and protocols requires traffic 1085 volume to be measured and new transport behaviours to be identified. 1086 This is especially true of protocols operating over a UDP substrate. 1087 The level and style of encryption needs to be considered in 1088 determining how this activity is performed. On a shorter timescale, 1089 information may also need to be collected to manage denial of service 1090 attacks against the infrastructure. 1092 5.3. Accountability and Internet Transport Protocols 1094 Information provided by tools observing transport headers can help 1095 determine whether mechanisms are needed in the network to prevent 1096 flows from acquiring excessive network capacity, and where needed to 1097 deploy appropriate tools Section 2.2.4. Obfuscating or hiding this 1098 information using encryption is expected to lead operators and 1099 maintainers of middleboxes (firewalls, etc.) to seek other methods to 1100 classify and mechanisms to condition network traffic. 1102 A lack of data seems likely to reduce the level of precision with 1103 which these mechanisms are applied, and this needs to be considered 1104 when evaluating the impact of designs for transport encryption. This 1105 could lead to increased use of rate limiting, circuit breaker 1106 techniques [RFC8084], or even blocking of uncharacterised traffic. 1107 This would hinder deployment of new mechanisms and/or protocols. 1109 5.4. Impact on Research, Development and Deployment 1111 There are both opportunities and also challenges to the design, 1112 evaluation and deployment of new transport protocol mechanisms. 1114 Integrity checks can avoiding network devices undetected modification 1115 of protocols, whereas encryption and obfuscation can prevent these 1116 headers being utilised by network devices. This provides greater 1117 freedom to update the protocols and can therefore ease 1118 experimentation with new techniques and their final deployment in 1119 endpoints. 1121 Measurement data is increasingly being used to inform design 1122 decisions in networking research, during development of new 1123 mechanisms and protocols and in standardisation. Measurement has a 1124 critical role in the design of transport protocol mechanisms and 1125 their acceptance by the wider community (e.g., as a method to judge 1126 the safety for Internet deployment). Observation of pathologies are 1127 also important in understanding the interactions between cooperating 1128 protocols and network mechanism, the implications of sharing capacity 1129 with other traffic and the impact of different patterns of usage. 1131 Attention needs to be paid to the expected scale of deployment of new 1132 protocols and protocol mechanisms. Whatever the mechanism, 1133 experience has shown that it is often difficult to correctly 1134 implement combination of mechanisms [RFC8085]. These mechanisms 1135 therefore typically evolve as a protocol matures, or in response to 1136 changes in network conditions, changes in network traffic or changes 1137 to application usage. 1139 New transport protocol formats are expected to facilitate an 1140 increased pace of transport evolution, and with it the possibility to 1141 experiment with and deploy a wide range of protocol mechanisms. 1142 There has been recent interest in a wide range of new transport 1143 methods, e.g., Larger Initial Window, Proportional Rate Reduction 1144 (PRR), congestion control methods based on measuring bottleneck 1145 bandwidth and round-trip propagation time, the introduction of AQM 1146 techniques and new forms of ECN response (e.g., DCTP, and methods 1147 proposed for L4S).The growth and diversity of applications and 1148 protocols using the Internet also continues to expand. For each new 1149 method or application it is desirable to build a body of data 1150 reflecting its behaviour under a wide range of deployment scenarios, 1151 traffic load, and interactions with other deployed/candidate methods. 1153 Open standards motivate a desire for this evaluation to include 1154 independent observation and evaluation of performance data, which in 1155 turn suggests control over where and when measurement samples are 1156 collected. This requires consideration of the appropriate balance 1157 between encrypting all and no transport information. 1159 6. Conclusions 1161 XXX Notes for a draft conclusion XXX 1163 The majority of traffic sent by the present Internet uses two well- 1164 known transport protocols: e.g., TCP and UDP. 1166 Although TCP represents the majority of current traffic, some 1167 important real-time applications have used UDP, and much of this 1168 traffic utilises RTP format headers in the payload of the UDP data. 1169 Since these protocol headers have been fixed for decades, a range of 1170 tools and analysis methods have became common and well-understood. 1171 Over this period, the transport protocol headers have mostly changed 1172 slowly, and so also the need to develop tools track new versions of 1173 the protocol. 1175 Encryption (confidentiality and strong integrity checks) have 1176 properties that are being incorporated into new protocols and which 1177 have important benefits. The pace of development of transports using 1178 the WebRTC data channel and the rapid deployment of QUIC prototype 1179 transports can both be attributed to using a combination of UDP 1180 transport and encryption of the UDP payload. 1182 The traffic that can be observed by devices in a network is a 1183 function of transport protocol design/options, network use, 1184 applications and user characteristics. In general, when only a small 1185 proportion of the traffic has a specific (different) characteristic. 1186 Such traffic seldom leads to an operational issue although the 1187 ability to measure and monitor it is less. The desire to understand 1188 the traffic and protocol interactions typically grows as the 1189 proportion of traffic increases in volume. The challenges increase 1190 when multiple instances of an evolving protocol contribute to the 1191 traffic that share network capacity. 1193 An increased pace of evolution therefore needs to be accompanied by 1194 methods that can be successfully deployed and used across operational 1195 networks. This leads to a need for network operators (at various 1196 level (ISPs, enterprises, firewall maintainer, etc) to identify 1197 appropriate operational support functions and procedures. 1199 Protocols that change their transport header format (wire format) or 1200 their behaviour (e.g., algorithms that are needed to classify and 1201 characterise the protocol), will require new tooling needs to be 1202 developed to catch-up with the changes. If the currently deployed 1203 tools and methods are no longer relevant and performance may not be 1204 correctly measured. This can increase the response-time after 1205 faults, and can impact the ability to manage the network resulting in 1206 traffic causing traffic to be treated inappropriately (e.g., rate 1207 limiting because of being incorrectly classified/monitored). There 1208 are benefits in exposing consistent information to the network that 1209 avoids traffic being mis-classified and then receiving a default 1210 treatment by the network. 1212 A protocol specification therefore needs to weigh the benefits of 1213 ossifying common headers, versus the potential demerits of exposing 1214 specific information that could be observed along the network path to 1215 provide tools to manage new variants of protocols. Several scenarios 1216 to illustrate different ways this could evolve are provided below: 1218 o One scenario is when transport protocols provide consistent 1219 information to the network by intentionally exposing a part of the 1220 transport header. The design fixes the format of this information 1221 between versions of the protocol. This level of ossification 1222 allows an operator to establish tooling and procedures that allow 1223 it to provide consistent traffic management as the protocol 1224 evolves. In contrast to TCP (where all protocol information is 1225 exposed), evolution of the transport is facilitated by providing 1226 cryptographic integrity checks of the transport header fields 1227 (preventing undetected middlebox changes) and encryption of other 1228 protocol information (preventing observation within the network). 1229 The transport information can be used by operators to provide 1230 troubleshooting, easement and any necessary functions for the 1231 class of traffic (priority, retransmission, reordering, circuit 1232 breakers, etc). 1234 o An alternative scenario adopts different design goals, with a 1235 different outcome. A protocol that encrypts all header 1236 information forces network operators to act independently from 1237 apps/transport developments to provide the transport information 1238 they need. A range of approaches may proliferate - as in current 1239 networks, operators can add a shim header to each packet as a flow 1240 as it crosses the network ; other operators/managers could develop 1241 heuristics and pattern recognition to derive information that 1242 classifies flows and estimates quality metrics for the service 1243 being used; some could decide to rate-limit or block traffic until 1244 new tooling is in place. In many cases, the derived information 1245 can be used by operators to provide necessary functions for the 1246 class of traffic (priority, retransmission, reordering, circuit 1247 breakers, etc). Troubleshooting, and measurement becomes more 1248 difficult or could require additional information. In some cases, 1249 operators might need access to keying information to interpret 1250 encrypted data that they observe. Some use cases could demand use 1251 of transports that do not use encryption. 1253 The outcome could have significant implications on the way the 1254 Internet architecture develops. It exposes a risk that significant 1255 actors (e.g., developers and transport designers) achieve more 1256 control of the way in which the Internet architecture develops.In 1257 particular, there is a possibility that designs could evolve to 1258 significantly benefit of customers for a specific vendor, and that 1259 communities with very different network, applications or platforms 1260 could then suffer at the expense of benefits to their vendors own 1261 customer base. In such a scenario, there could be no incentive to 1262 support other applications/products or to work in other networks 1263 leading to reduced access for new approaches. 1265 7. Acknowledgements 1267 The author would like to thank all who have talked to him face-to- 1268 face or via email. ... 1270 This work has received funding from the European Union's Horizon 2020 1271 research and innovation programme under grant agreement No 688421.The 1272 opinions expressed and arguments employed reflect only the authors' 1273 view. The European Commission is not responsible for any use that 1274 may be made of that information. 1276 8. Security Considerations 1278 This document is about design and deployment considerations for 1279 transport protocols. Authentication, confidentiality protection, and 1280 integrity protection are identified as Transport Features by 1281 RFC8095". As currently deployed in the Internet, these features are 1282 generally provided by a protocol or layer on top of the transport 1283 protocol; no current full-featured standards-track transport protocol 1284 provides these features on its own. Therefore, these features are 1285 not considered in this document, with the exception of native 1286 authentication capabilities of TCP and SCTP for which the security 1287 considerations in RFC4895. 1289 Open data, and accessibility to tools that can help understand trends 1290 in application deployment, network traffic and usage patterns can all 1291 contribute to understanding security challenges. Standard protocols 1292 and understanding of the interactions between mechanisms and traffic 1293 patterns can also provide valuable insight into appropriate security 1294 design. Like congestion control mechanisms, security mechanisms are 1295 difficult to design and implement correctly. It is hence recommended 1296 that applications employ well-known standard security mechanisms such 1297 as DTLS, TLS or IPsec, rather than inventing their own. 1299 9. IANA Considerations 1301 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1303 This memo includes no request to IANA. 1305 10. References 1306 10.1. Normative References 1308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1309 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1310 RFC2119, March 1997, . 1313 10.2. Informative References 1315 [I-D.dolson-plus-middlebox-benefits] 1316 Dolson, D., Snellman, J., Boucadair, M. and C. Jacquenet, 1317 "Beneficial Functions of Middleboxes", Internet-Draft 1318 draft-dolson-plus-middlebox-benefits-03, March 2017. 1320 [I-D.ietf-aqm-codel] 1321 Nichols, K., Jacobson, V., McGregor, A. and J. Jana, 1322 "Controlled Delay Active Queue Management", Internet-Draft 1323 draft-ietf-aqm-codel-00, October 2014. 1325 [I-D.ietf-aqm-fq-codel] 1326 Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1327 J. and E. Dumazet, "FlowQueue-Codel", Internet-Draft 1328 draft-ietf-aqm-fq-codel-00, January 2015. 1330 [I-D.ietf-aqm-pie] 1331 Pan, R., Natarajan, P., Baker, F. and G. White, "PIE: A 1332 Lightweight Control Scheme To Address the Bufferbloat 1333 Problem", Internet-Draft draft-ietf-aqm-pie-00, October 1334 2014. 1336 [I-D.ietf-ippm-6man-pdm-option] 1337 Elkins, N., Hamilton, R. and m. mackermann@bcbsm.com, 1338 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1339 Option", Internet-Draft draft-ietf-ippm-6man-pdm- 1340 option-10, May 2017. 1342 [I-D.ietf-ippm-ioam-data] 1343 Brockners, F., Bhandari, S., Pignataro, C., Gredler, H., 1344 Leddy, J., Youell, S., Mizrahi, T., Mozes, D., Lapukhov, 1345 P., Chang, R. and d. daniel.bernier@bell.ca, "Data Fields 1346 for In-situ OAM", Internet-Draft draft-ietf-ippm-ioam- 1347 data-01, October 2017. 1349 [I-D.ietf-quic-transport] 1350 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1351 and Secure Transport", Internet-Draft draft-ietf-quic- 1352 transport-03, May 2017. 1354 [I-D.ietf-tcpm-accurate-ecn] 1355 Briscoe, B., Kuehlewind, M. and R. Scheffenegger, "More 1356 Accurate ECN Feedback in TCP", Internet-Draft draft-ietf- 1357 tcpm-accurate-ecn-00, December 2015. 1359 [I-D.ietf-tsvwg-l4s-arch] 1360 Briscoe, B., Schepper, K. and M. Bagnulo, "Low Latency, 1361 Low Loss, Scalable Throughput (L4S) Internet Service: 1362 Architecture", Internet-Draft draft-ietf-tsvwg-l4s- 1363 arch-00, May 2017. 1365 [I-D.mm-wg-effect-encrypt] 1366 Moriarty, K. and A. Morton, "Effect of Pervasive 1367 Encryption on Operators", Internet-Draft draft-mm-wg- 1368 effect-encrypt-11, April 2017. 1370 [I-D.trammell-plus-abstract-mech] 1371 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1372 Layer under Endpoint Control", Internet-Draft draft- 1373 trammell-plus-abstract-mech-00, September 2016. 1375 [I-D.trammell-plus-statefulness] 1376 Kuehlewind, M., Trammell, B. and J. Hildebrand, 1377 "Transport-Independent Path Layer State Management", 1378 Internet-Draft draft-trammell-plus-statefulness-02, 1379 December 2016. 1381 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1382 Techniques and Their Merits", November 2014. 1384 [Measure] Fairhurst, G., Kuehlewind, M. and D. Lopez, "Measurement- 1385 based Protocol Design", June 2017. 1387 [RFC1273] Schwartz, M.F., "Measurement Study of Changes in Service- 1388 Level Reachability in the Global TCP/IP Internet: Goals, 1389 Experimental Design, Implementation, and Policy 1390 Considerations", RFC 1273, DOI 10.17487/RFC1273, November 1391 1991, . 1393 [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, 1394 "Definition of the Differentiated Services Field (DS 1395 Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 1396 10.17487/RFC2474, December 1998, . 1399 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1400 Shelby, "Performance Enhancing Proxies Intended to 1401 Mitigate Link-Related Degradations", RFC 3135, DOI 1402 10.17487/RFC3135, June 2001, . 1405 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 1406 Explicit Congestion Notification (ECN) to IP", RFC 3168, 1407 DOI 10.17487/RFC3168, September 2001, . 1410 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1411 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1412 . 1414 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1415 Sooriyabandara, "TCP Performance Implications of Network 1416 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1417 December 2002, . 1419 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. 1420 Jacobson, "RTP: A Transport Protocol for Real-Time 1421 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1422 July 2003, . 1424 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1425 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. 1426 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1427 RFC 3819, DOI 10.17487/RFC3819, July 2004, . 1430 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1431 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1432 December 2005, . 1434 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 1435 10.17487/RFC4302, December 2005, . 1438 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 1439 4303, DOI 10.17487/RFC4303, December 2005, . 1442 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. and J. Rey, 1443 "Extended RTP Profile for Real-time Transport Control 1444 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 1445 10.17487/RFC4585, July 2006, . 1448 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S. 1449 and J. Perser, "Packet Reordering Metrics", RFC 4737, DOI 1450 10.17487/RFC4737, November 2006, . 1453 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A. and R. 1454 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1455 DOI 10.17487/RFC5236, June 2008, . 1458 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1459 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 1460 RFC5246, August 2008, . 1463 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1464 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1465 . 1467 [RFC5925] Touch, J., Mankin, A. and R. Bonica, "The TCP 1468 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1469 June 2010, . 1471 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P. and P. 1472 Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 1473 10.17487/RFC6269, June 2011, . 1476 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1477 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1478 January 2012, . 1480 [RFC6437] Amante, S., Carpenter, B., Jiang, S. and J. Rajahalme, 1481 "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/ 1482 RFC6437, November 2011, . 1485 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P. 1486 and K. Carlberg, "Explicit Congestion Notification (ECN) 1487 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1488 2012, . 1490 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1491 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1492 2014, . 1494 [RFC7525] Sheffer, Y., Holz, R. and P. Saint-Andre, "Recommendations 1495 for Secure Use of Transport Layer Security (TLS) and 1496 Datagram Transport Layer Security (DTLS)", BCP 195, RFC 1497 7525, DOI 10.17487/RFC7525, May 2015, . 1500 [RFC7567] Baker, F.Ed., and G. Fairhurst, Ed., "IETF 1501 Recommendations Regarding Active Queue Management", BCP 1502 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, . 1505 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1506 Trammell, B., Huitema, C. and D. Borkmann, 1507 "Confidentiality in the Face of Pervasive Surveillance: A 1508 Threat Model and Problem Statement", RFC 7624, DOI 1509 10.17487/RFC7624, August 2015, . 1512 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1513 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1514 DOI 10.17487/RFC7713, December 2015, . 1517 [RFC7872] Gont, F., Linkova, J., Chown, T. and W. Liu, "Observations 1518 on the Dropping of Packets with IPv6 Extension Headers in 1519 the Real World", RFC 7872, DOI 10.17487/RFC7872, June 1520 2016, . 1522 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N.Ed., and D. 1523 Ros, "Characterization Guidelines for Active Queue 1524 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1525 2016, . 1527 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", BCP 1528 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, . 1531 [RFC8085] Eggert, L., Fairhurst, G. and G. Shepherd, "UDP Usage 1532 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1533 March 2017, . 1535 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X. and T. Herbert, "GRE-in- 1536 UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 1537 2017, . 1539 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1540 Explicit Congestion Notification (ECN)", RFC 8087, DOI 1541 10.17487/RFC8087, March 2017, . 1544 [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L. 1545 and G. Judd, "Data Center TCP (DCTCP): TCP Congestion 1546 Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, 1547 October 2017, . 1549 [Tor] The Tor Project, ., "https://www.torproject.org", June 1550 2017. 1552 Appendix A. Revision information 1554 -00 This is an individual draft for the IETF community. 1556 -01 This draft was a result of walking away from the text for a few 1557 days and then reorganising the content. 1559 -02 This draft fixes textual errors. 1561 -03 This draft follows feedback from people reading this draft. 1563 -04 This adds an additional contributor and includes significant 1564 reworking to ready this for review by the wider IETF community Colin 1565 Perkins joined the author list. 1567 Comments from the community are welcome on the text and 1568 recommendations. 1570 -05 Corrections received and helpful inputs from Mohamed Boucadair. 1572 -06 Updated following comments from Stephen Farrell, and feedback via 1573 email. Added a draft conclusion section to sketch some strawman 1574 scenarios that could emerge. 1576 Authors' Addresses 1578 Godred Fairhurst 1579 University of Aberdeen 1580 Department of Engineering 1581 Fraser Noble Building 1582 Aberdeen, AB24 3UE 1583 Scotland 1585 Email: gorry@erg.abdn.ac.uk 1586 URI: http://www.erg.abdn.ac.uk/ 1588 Colin Perkins 1589 University of Glasgow 1590 School of Computing Science 1591 Glasgow, G12 8QQ 1592 Scotland 1594 Email: csp@csperkins.org 1595 URI: https://csperkins.org//