idnits 2.17.1 draft-fairhurst-tsvwg-transport-encrypt-03.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 (August 30, 2017) is 2421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 1337, but no explicit reference was found in the text == Unused Reference: 'RFC4301' is defined on line 1452, but no explicit reference was found in the text == Unused Reference: 'RFC5559' is defined on line 1485, 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 (-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 (-10) exists of draft-ietf-tcpm-dctcp-06 == 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 (~~), 14 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 August 30, 2017 5 Expires: March 3, 2018 7 The Impact of Transport Header Encryption on Operation and Evolution of 8 the Internet 9 draft-fairhurst-tsvwg-transport-encrypt-03 11 Abstract 13 This document describes implications of applying end-to-end 14 encryption at the transport layer. It identifies some in-network 15 uses of transport layer header information that can be used with a 16 transport header integrity check. It reviews the implication of 17 developing encrypted end-to-end transport protocols and examines the 18 implication of developing and deploying encrypted end-to-end 19 transport protocols. Since transport measurement and analysis of the 20 impact of network characteristics have been important to the design 21 of current transport protocols, it also considers some anticipated 22 implications on transport and application evolution. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Internet Transports and Pervasive Encryption . . . . . . . . 5 60 2.1. Authenticating the Transport Protocol Header . . . . . . 6 61 2.2. Encrypting the Transport Payload . . . . . . . . . . . . 6 62 2.3. Encrypting the Transport Header . . . . . . . . . . . . . 6 63 2.4. Authenticating Transport Information and Selectively 64 Encrypting the Transport Header . . . . . . . . . . . . . 7 65 2.5. Adding Transport Information to Network-Layer Protocol 66 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Use of Transport Headers in the Network . . . . . . . . . . . 8 68 3.1. Use to Identify Flows and Packet Formats . . . . . . . . 9 69 3.2. Measurements derived from Transport Header Information . 9 70 3.2.1. Use to Characterise Traffic Rate and Volume . . . . . 10 71 3.2.2. Measuring Loss Rate and Loss Pattern . . . . . . . . 10 72 3.2.3. Measuring Throughput and Goodput . . . . . . . . . . 11 73 3.2.4. Measuring Latency (Network Transit Delay and Jitter) 11 74 3.2.5. Measuring Flow Reordering . . . . . . . . . . . . . . 12 75 3.3. Measurements derived from Network-Transport Information . 12 76 3.3.1. Use of IPv6 Network-Layer Flow Label . . . . . . . . 12 77 3.3.2. Use Network-Layer Differentiated Services Code Point 78 Point . . . . . . . . . . . . . . . . . . . . . . . . 13 79 3.3.3. Use of Explicit Congestion Marking . . . . . . . . . 13 80 4. Transport Measurement . . . . . . . . . . . . . . . . . . . . 14 81 4.1. Point of Measurement . . . . . . . . . . . . . . . . . . 14 82 4.2. Use by Operators to Plan and Provision Networks . . . . . 15 83 4.3. Service Performance Measurement . . . . . . . . . . . . . 15 84 4.4. Use for Network Diagnostics and Troubleshooting . . . . . 15 85 4.5. Acceptable Response to Congestion . . . . . . . . . . . . 16 86 4.5.1. Measuring Compliance of UDP Traffic . . . . . . . . . 16 87 4.5.2. Measuring Transport to Support Network Operations . . 17 88 5. Observing Transport Flows with Encrypted Transport Header 89 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.1. Transport Information at the Network Layer . . . . . . . 17 91 5.2. An Observable Transport Flow Identifier . . . . . . . . . 18 92 5.2.1. A Method to Determine Header Format . . . . . . . . . 18 93 5.2.2. Use of a Transport as a Substrate . . . . . . . . . . 18 94 5.2.3. Support for Mobility and Flow Migration . . . . . . . 19 95 5.2.4. Flow Start and Stop . . . . . . . . . . . . . . . . . 19 96 5.3. Observable Transport Sequence Number . . . . . . . . . . 20 97 5.4. Observable Transport Reception . . . . . . . . . . . . . 20 98 5.5. Observable Transport Timestamps . . . . . . . . . . . . . 21 99 5.6. Observable ECN Transport Feedback Information . . . . . . 21 100 5.7. Other Observable Transport Fields . . . . . . . . . . . . 21 101 5.8. Interpretation of Transport Header Fields . . . . . . . . 21 102 5.9. Requirements for Transport Measurement . . . . . . . . . 22 103 6. The Effect of Encrypting Transport Header Fields . . . . . . 23 104 6.1. Independent Measurement . . . . . . . . . . . . . . . . . 23 105 6.2. Characterising "Unknown" Network Traffic . . . . . . . . 24 106 6.3. Accountability and Internet Transport Portocols . . . . . 24 107 7. Implications on Evolution of the Internet Transport . . . . . 25 108 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 109 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 110 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 29 113 11.2. Informative References . . . . . . . . . . . . . . . . . 29 114 Appendix A. Revision information . . . . . . . . . . . . . . . . 33 115 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34 117 1. Introduction 119 This document discusses the implications of end-to-end encryption 120 applied at the transport layer, and examines the impact on transport 121 protocol design, transport use, and network operations and 122 management. It also considers some anticipated implications on 123 transport and application evolution. 125 The transport layer is the first end-to-end layer in the network 126 stack. Despite headers having end-to-end meaning, some transport 127 headers have come to be used in various ways within the Internet. In 128 response to pervasive monitoring [RFC7624] revelations and the IETF 129 consensus that "Pervasive Monitoring is an Attack" [RFC7258], efforts 130 are underway to increase encryption of Internet traffic, which would 131 prevent visibility of transport headers. This has implications on 132 how network protocols are designed and used 133 [I-D.mm-wg-effect-encrypt]. 135 Transport information that is sent without end-to-end integrity check 136 could be modified by "middleboxes" - defined as any intermediary box 137 performing functions apart from normal, standard functions of an IP 138 router on the data path between a source host and destination host 139 [RFC3234]. When transport headers are modified by network devices on 140 the path, this can change the end-to-end protocol transport protocol 141 behaviour in a way that may have benefits (e.g., to user performance/ 142 cost) or may hinder (e.g., disrupting application experience). 143 Whatever the outcome, modification of packets by a middlebox was not 144 usually intended when the protocol was specified and is usually not 145 known by the sending or receiving endpoints. 147 Middleboxes have been deployed for a variety of reasons [RFC3234], 148 including protocol enhancement, proxies such as Protocol Enhancing 149 Proxies (PEPs) [RFC3135], TCP acknowledgement (ACK) enhancement 150 [RFC3449], use by application protocol caches 151 [I-D.mm-wg-effect-encrypt], application layer gateways 152 [I-D.mm-wg-effect-encrypt], etc. 153 [I-D.dolson-plus-middlebox-benefits] summarizes some of the functions 154 provided by such middleboxes, and benefits that may arise when used 155 in specific deployment scenarios. Such methods, which involve in- 156 network modification of transport headers, are not further discussed. 158 Transport protocols can be designed to encrypt or authenticate 159 transport header fields. Authentication methods at the transport 160 layer can detect any changes to an immutable header field that were 161 made by a network device along a path. These methods do not require 162 encryption of the header fields, and hence authenticated fields may 163 remain visible to network devices. A receiving transport endpoint 164 can use an integrity check to avoid accepting modified protocol 165 headers. This document therefore does not consider the case where 166 there is undetected modification of the transport header fields as a 167 packet traverses the network path. The intentional modification of 168 transport headers by middleboxes (such as Network Address Translation 169 with Protocol Translation, NAT-P) is not considered. 171 Authentication methods (that provide integrity checks of protocols 172 fields) have also been specified at the network layer, and this also 173 protects transport header fields. The network layer itself carries 174 protocol header fields that are increasingly used to help forwarding 175 decisions reflect the need of transport protocols, such the IPv6 Flow 176 Label [RFC6437], the Differentiated Services Code Point (DSCP) 177 [RFC2474] and Explicit Congestion Notification (ECN) [RFC3168]. 179 Encryption methods can hide information from an eavesdropper in the 180 network. Encryption can also help protect the privacy of a user, by 181 hiding data relating to user/device identity or location. Neither an 182 integrity check nor encryption methods prevent traffic analysis, and 183 usage needs to reflect that profiling of users and fingerprinting of 184 behaviour can take place even on encrypted traffic flows. 186 This document seeks to identify the implications of various 187 approaches to transport protocol authentication and encryption. 189 2. Internet Transports and Pervasive Encryption 191 End-to-end encryption can be applied at various protocol layers. It 192 can be applied above the transport to encrypt the transport payload. 193 One motive to use encryption is a response to perceptions that the 194 network has become ossified by over-reliance on middleboxes that 195 prevent new protocols and mechanisms from being deployed. This has 196 lead to a common perception that there is too much "manipulation" of 197 protocol headers within the network, and that designing to deploy in 198 such networks is preventing transport evolution. In the light of 199 this, a method that authenticates transport headers may help improve 200 the pace of transport development, by eliminating the need to always 201 consider deployed middleboxes [I-D.trammell-plus-abstract-mech], or 202 potentially to only explicitly enable middlebox use for particular 203 paths with particular middleboxes that are deliberately deployd to 204 realise a useful function for the network and/or users[RFC3135]. 206 Another perspective stems from increased concerns about privacy and 207 surveillance. Some Internet users have valued the ability to protect 208 identity and defend against traffic analysis, and have used methods 209 such as IPsec ESP and Tor [Tor]. Revelations about the use of 210 pervasive surveillance [RFC7624] have, to some extent, eroded trust 211 in the service offered by network operators, and following the 212 Snowden revelation in the USA in 2013 has led to an increased desire 213 for people to employ encryption to avoid unwanted "eavesdropping" on 214 their communications. Whatever the reasons, there are now activities 215 in the IETF to design new protocols that may include some form of 216 transport header encryption (e.g., QUIC [I-D.ietf-quic-transport]). 218 The use of transport layer authentication and encryption exposes a 219 tussle between middlebox vendors, operators, applications developers 220 and users. 222 o On the one hand, future Internet protocols that enable large-scale 223 encryption assist in the restoration of the end-to-end nature of 224 the Internet by returning complex processing to the endpoints, 225 since middleboxes cannot modify what they cannot see. 226 o On the other hand, encryption of transport layer header 227 information has implications for people who are responsible for 228 operating networks and researchers and analysts seeking to 229 understand the dynamics of protocols and traffic patterns. 231 Whatever the motives, a decision to use pervasive of transport header 232 encryption will have implications on the way in which design and 233 evaluation is performed, and which can in turn impact the direction 234 of evolution of the TCP/IP stack. 236 The next subsections briefly review some security design options for 237 transport protocols. 239 2.1. Authenticating the Transport Protocol Header 241 Transport layer header information can be authenticated. An 242 integrity check that protects the immutable transport header fields, 243 but can still expose the transport protocol header information in the 244 clear, allowing in-network devices to observes these fields. An 245 integrity check can not prevent in-network modification, but can 246 avoid accepting changes and avoid impact on the transport protocol 247 operation. 249 An example transport authentication mechanism is TCP-Authentication 250 (TCP-AO) [RFC5925]. This TCP option authenticates TCP segments, 251 including the IP pseudo header, TCP header, and TCP data. TCP-AO 252 protects the transport layer, preventing attacks from disabling the 253 TCP connection itself. TCP-AO may interact with middleboxes, 254 depending on their behavior [RFC3234]. 256 The IPSec Authentication Header (AH) [RFC4302] works at the network 257 layer and authenticates the IP payload. This therefore also 258 authenticates all transport headers, and verifies their integrity at 259 the receiver, preventing in-network modification. 261 2.2. Encrypting the Transport Payload 263 The transport layer payload can be encrypted to protect the content 264 of transport segments. This leaves transport protocol header 265 information in the clear. The integrity of immutable transport 266 header fields could be protected by combining this with an integrity 267 check (Section 2.1). 269 Examples of encrypting the payload include Transport Layer Security 270 (TLS) over TCP [RFC5246] [RFC7525] or Datagram TLS (DTLS) over UDP 271 [RFC6347] [RFC7525]. 273 2.3. Encrypting the Transport Header 275 The network layer payload could be encrypted (including the entire 276 transport header and payload). This method does not expose any 277 transport information to devices in the network, which also prevents 278 modification along the network path. 280 The IPSec Encapsulating Security Payload (ESP) [RFC4303] is an 281 example of encryption at the network layer, it encrypts and 282 authenticates all transport headers, preventing visibility of the 283 headers by in-network devices. Some Virtual Private Network (VPN) 284 methods also encrypt these headers. 286 2.4. Authenticating Transport Information and Selectively Encrypting 287 the Transport Header 289 A transport protocol design can encrypt selected header fields, while 290 also choosing to authenticate fields in the transport header. This 291 allows specific transport header fields to be made observable by 292 network devices. End-to end integrity checks can prevent an endpoint 293 from undetected modification of the immutable transport headers. 295 The choice of which fields to expose and which to encrypt is a design 296 choice for the transport protocol. Any selective encryption method 297 requires trading two conflicting goals for a transport protocol 298 designer to decide which header fields to encrypt. On the one hand, 299 security work typically employs a design technique that seeks to 300 expose only what is needed. On the other hand, there may be 301 performance and operational benefits in exposing selected information 302 to network tools. 304 Mutable fields in the transport header provide opportunities for 305 middleboxes to modify the transport behaviour (e.g., the extended 306 headers described in [I-D.trammell-plus-abstract-mech]). This 307 considers only immutable fields in the transport headers, that is, 308 fields that may be authenticated end-to-end across a path. 310 An example of a method that encrypts some, but not all, transport 311 information is GRE-in-UDP [RFC8086] when used with GRE encryption. 313 2.5. Adding Transport Information to Network-Layer Protocol Headers 315 The transport information can be made visible in a network-layer 316 header. This has the advantage that this information can then be 317 observed by in-network devices. This has the advantage that a single 318 header can support all transport protocols, but there may also be 319 less desirable implications of separating the operation of the 320 transport protocol from the measurement framework. 322 Some measurements may be made by adding additional protocol headers 323 carrying operations, administration and management (OAM) information 324 to packets at the ingress to a maintenance domain (e.g., an Ethernet 325 protocol header with timestamps and sequence number information using 326 a method such as 802.11ag) and removing the additional header at the 327 egress of the maintenance domain. This approach enables some types 328 of measurements, but does not cover the entire range of measurements 329 described in this document. 331 Another example of a network-layer approach is the IPv6 Performance 332 and Diagnostic Metrics (PDM) Destination Option 333 [I-D.ietf-ippm-6man-pdm-option]. This allows a sender to optionally 334 include a destination option that caries header fields that can be 335 used to observe timestamps and packet sequence numbers. This 336 information could be authenticated by receiving transport endpoints 337 when the information is added at the sender and visible at the 338 receiving endpoint, although methods to do this have not currently 339 been proposed. This method needs to be explicitly enabled at the 340 sender. 342 A drawback of using extension headers is that IPv4 network options 343 are often not supported (or are carried on a slower processing path) 344 and some IPv6 networks are also known to drop packets that set an 345 IPv6 header extension. Another disadvantage is that protocols that 346 separately expose header information do not necessarily have an 347 advantage to expose the information that is utilised by the protocol 348 itself, and could manipulate this header information to gain an 349 advantage from the network. 351 3. Use of Transport Headers in the Network 353 This section identifies ways that actors can benefit by observing 354 (non-encrypted) transport header fields at devices in the network. 355 The list of actors who perform measurements include: 357 o Protocol developers and implementors of TCP/IP stacks; 358 o Researchers working on new mechanisms; 359 o Use of new applications using existing applications; 360 o Analysis researching the impact of mechanisms on network equipment 361 or specific network topologies; 362 o Staff supporting operation of a network. 364 One approach is to use active measurement using dedicated tools to 365 generate and measure test traffic. To test a transport path, such 366 active tools need to be run from an endpoint, and most operators do 367 not have access to user equipment. There may also be costs 368 associated with running such tests (e.g., the implications of 369 bandwidth tests in a mobile network are obvious). Some active 370 measurements (e.g., response under load or particular workloads) may 371 perturb other traffic, and could require dedicated access to the 372 network segment. An alternative approach is to use in-network 373 techniques that observe transport packet headers in operational 374 networks to make the measurements. 376 Transport layer information can help identify whether the link/ 377 network tuning is effective and alert to potential problems that can 378 be hard to derive from link or device measurements alone. The design 379 trade offs for radio networks are often very different to those of 380 wired networks. A radio-based network (e.g., cellular mobile, 381 enterprise WiFi, satellite access/backhaul, point-to-point radio) has 382 the complexity of a subsystem that performs radio resource management 383 - with direct impact on the available capacity, and potentially loss/ 384 reordering of packets. The impact of the pattern of loss and 385 congestion, differs for different traffic types, correlation with 386 propagation and interference can all have significant impact on the 387 cost and performance of a provided service. The need for this type 388 of information is expected to increase as operators bring together 389 heterogeneous types of network equipment and seek to deploy 390 opportunistic methods to access radio spectrum. 392 In-network observation of transport protocol headers requires 393 knowledge of the format of the transport header: 395 o Flows, need to be identified at the level required for monitoring; 396 o The protocol and version of the header that is being used. As 397 protocols evolve over time and there may be a need to introduce 398 new transport headers. This may require interpretation of 399 protocol version information or connection setup information; 400 o The position and syntax of any transport headers that need to be 401 observed. IETF transport protocols specify this information. 403 The following subsections describe various ways that observable 404 transport information may be utilised. 406 3.1. Use to Identify Flows and Packet Formats 408 Transport protocol header information can identify a flow and the 409 connection state of the flow, together with the protocol options 410 being used. In some usages, a low-numbered (well-known ) port that 411 can identify a protocol (although port information alone is not 412 sufficient to guarantee identification of a protocol). Transport 413 protocols, such as TCP and SCTP specify a standard base header that 414 includes sequence number information and other data, with the 415 possibility to negotiate additional headers at connection setup and 416 identified by an option number in the transport header. UDP-based 417 protocols sometimes do not use well-known ports but also can instead 418 be identified by signalling protocols or through the use of magic 419 numbers placed in the first byte(s) of the datagram payload. 421 3.2. Measurements derived from Transport Header Information 423 Some actors have a need to characterise the performance of link/ 424 network segments. Passive monitoring uses observed traffic to makes 425 inferences from transport headers to derive measurements. A variety 426 of open source and commercial tools can utilise this information. 428 Transport fields in the Real Time Protocol (RTP) header[RFC3550] 429 [RFC4585] can be observed to derive traffic volume measurements and 430 provide information on the progress and quality of a session using 431 RTP. Key performance indicators are retransmission rate, packet drop 432 rate, sector utilization level, a measure of reordering, peak rate, 433 the CE-marking rate, etc. Metadata is often important to understand 434 the context under which the data was collected, including the time, 435 observation point, and way in which metrics were accumulated. 437 Some Internet transports report summary performance data that is 438 observable in the network (e.g., RTCP feedback[RFC3550]). A user of 439 summary measurement data needs to trust the source of this data and 440 the method used to generate the summary information. 442 When encryption conceals information in packet headers, measurements 443 need to rely on pattern inferences and other heuristics grows, and 444 accuracy suffers [I-D.mm-wg-effect-encrypt]. 446 3.2.1. Use to Characterise Traffic Rate and Volume 448 Transport headers may be observed to derive volume measures per- 449 application, to characterise the traffic using a network segment and 450 pattern of network usage. This may be measured per endpoint or 451 aggregate of endpoint (e.g., by an operator to assess subscriber 452 usage). This can also be used to trigger measurement-based traffic 453 shaping and to implement QoS support within the network and lower 454 layers. Volume measures can be valuable for capacity planning 455 (providing detail of trends rather than the volume per subscriber). 457 3.2.2. Measuring Loss Rate and Loss Pattern 459 Flow loss rate is often used as a metric for performance assessment 460 and to characterise the transport behaviour. Understanding the root 461 cause of loss can help an operator determine whether this requires 462 corrective action. 464 There are various cause of loss, including: corruption on a link 465 (e.g., interference on a radio link), buffer overflow (e.g., due to 466 congestion), policing (traffic management), buffer management (e.g., 467 Active Queue Management (AQM). Loss can be monitored at the 468 interface level by devices in the network. It is often important to 469 understand the conditions under which packet loss occurs, which 470 usually means relating loss to the traffic flowing on the network 471 segment at the time of loss. Understanding flow loss rate requires 472 either maintaining per flow packet counters or by observing sequence 473 numbers in transport headers. 475 Observation of transport feedback information (observing loss 476 reports, e.g., RTCP, TCP SACK) can increase understanding of the 477 impact of loss and help identify cases where loss may have been 478 wrongly identified, or the transport did not require the lost packet. 479 It is sometimes more important to understand the pattern of loss, 480 than the loss rate - since losses can often occur as bursts, rather 481 than randomly timed events. 483 3.2.3. Measuring Throughput and Goodput 485 The throughput observed by a flow can be determined even when a flow 486 is encrypted, providing the individual flow can be identified. 487 Goodput [RFC7928] is a measure of useful data exchanged (the ratio of 488 useful/total volume of traffic sent by a flow), which requires 489 ability to differentiate loss and retransmission of packets (e.g., by 490 observing packet sequence numbers in TCP or RTP). 492 3.2.4. Measuring Latency (Network Transit Delay and Jitter) 494 Latency is a key performance metric that impacts application response 495 time and user-perceived response time. It also often indirectly 496 impacts throughput and flow completion time. Latency determines the 497 reaction time of the transport protocol itself, impacting flow setup, 498 congestion control, loss recovery, and other transport mechanisms. 499 The observed latency can have many components [Latency]. Of these, 500 unnecessary/unwanted queuing in network buffers has often been 501 observed as a significant factor. Once the cause of unwanted latency 502 has been identified, this can often be eliminated, and determining 503 latency metrics is a key driver in the deployment of AQM [RFC7567], 504 DiffServ [RFC2474], and ECN [RFC3168] [RFC8087]. 506 To measure latency across a part of the path, an observation point 507 can measure the experienced round trip time (RTT) using packet 508 sequence numbers, and acknowledgements, or by observing header 509 timestamp information. Such information allows an observation point 510 in the network to determine not only the path RTT, but also to 511 measure the upstream and downstream contribution to the RTT. This 512 may be used to locate a source of latency, e.g., by observing cases 513 where the ratio of median to minimum RTT is large for a part of a 514 path. 516 An example usage of this method could be to identify excessive 517 buffers and to deploy or configure Active Queue Management (AQM) 518 [RFC7567] [RFC7928]. Operators deploying such tools can effectively 519 eliminate unnecessary queuing in routers and other devices. AQM 520 methods need to be deployed at the capacity bottleneck, but are often 521 deployed in combination with other techniques, such as scheduling 522 [RFC7567] [I-D.ietf-aqm-fq-codel] and although parameter-less methods 523 are desired [RFC7567], current methods [I-D.ietf-aqm-fq-codel] 524 [I-D.ietf-aqm-codel] [I-D.ietf-aqm-pie] often cannot scale across all 525 possible deployment scenarios. The service offered by operators can 526 therefore benefit from latency information to understand the impact 527 of deployment and tune deployed services. 529 Some network applications are sensitive to packet jitter, and it can 530 be necessary to measure the jitter observed along a portion of the 531 path. The requirements to measure jitter resemble those for the 532 measurement of latency. 534 3.2.5. Measuring Flow Reordering 536 Significant flow reordering can impact time-critical applications and 537 can be interpreted as loss by reliable transports. Many transport 538 protocol techniques are impacted by reordering (e.g., triggering TCP 539 retransmission, or rebuffering of real-time applications). Packet 540 reordering can occur for many reasons (from equipment design to 541 misconfiguration of forwarding rules). 543 As in the drive to reduce network latency, there is a need for 544 operational tools to be able to detect misordered packet flows and 545 quantify the degree or reordering. Techniques for measuring 546 reordering typically observe packet sequence numbers. Metrics have 547 been defined that evaluate whether a network has maintained packet 548 order on a packet-by-packet basis [RFC4737] and [RFC5236]. 550 There has been initiatives in the IETF transport area to reduce the 551 impact of reordering withing a transport flow, possibly leading to 552 reduced the requirements for ordering. These have promise to 553 simplify network equipment design as well as the potential to improve 554 robustness of the transport service. Measurements of reordering can 555 help understand the level of reordering within deployed 556 infrastructure, and inform decisions about how to progress such 557 mechanisms. 559 3.3. Measurements derived from Network-Transport Information 561 This section describes transport information that is already 562 observable in network-layer header fields. 564 3.3.1. Use of IPv6 Network-Layer Flow Label 566 Endpoints should expose flow information in the IPv6 Flow Label field 567 of the network-layer header (e..g. [RFC8085]). This can be used to 568 inform network-layer queuing, forwarding (e.g., for equal cost multi- 569 path (ECMP) routing, and Link Aggregation (LAG)). This can provide 570 useful information to assign packets to flows in the data collected 571 by measurement campaigns. Although important to characterising a 572 path, it does not directly provide any performance data. 574 3.3.2. Use Network-Layer Differentiated Services Code Point Point 576 Application can expose their delivery expectations to the network, by 577 setting the Differentiated Services Code Point (DSCP) field of IPv4 578 and IPv6 packets. This can be used to inform network-layer queuing 579 and forwarding, and can also provide information on the relative 580 importance of packet information collected by measurement campaigns, 581 but does not directly provide any performance data. 583 This field provides explicit information that can be used in place of 584 inferring traffic requirements (e.g., by inferring QoS requirements 585 from port information via a multi-field classifier). The DSCP value 586 can therefore impact the quality of experience for a flow. 587 Observations of service performance need to consider this field when 588 a network path has support for differentiated service treatment. 590 3.3.3. Use of Explicit Congestion Marking 592 Explicit Congestion Notification (ECN)[RFC3168] uses a codepoint in 593 the network-layer header. Use of ECN can offer gains in terms of 594 increased throughput, reduced delay, and other benefits when used 595 over a path that includes equipment that supports an AQM method that 596 performs Congestion Experienced (CE) marking of IP packets [RFC8087]. 598 This exposes the presence of congestion on a network path to the 599 transport and network layer. The reception of Congestion Experienced 600 (CE) marked packets can therefore be used to monitor the presence and 601 estimate the level of incipient congestion on the upstream portion of 602 the path from the point of observation (Section 2.5 of [RFC8087]). 603 Because ECN marks carried in the IP protocol header, measuring ECN 604 can be much easier than metering packet loss. However, interpreting 605 the marking behaviour (i.e., assessing congestion and diagnosing 606 faults) requires context from the transport layer (path RTT, 607 visibility of loss - that could be due to queue overflow, congestion 608 response, etc)[RFC7567]. 610 Some ECN-capable network devices can provide richer (more frequent 611 and fine-grained) indication of their congestion state. Setting 612 congestion marks proportional to the level of congestion (e.g., DCTP 613 [I-D.ietf-tcpm-dctcp], and L4S [I-D.ietf-tsvwg-l4s-arch]). 615 AQM and ECN offer a range of algorithms and configuration options, it 616 is therefore important for tools to be available to network operators 617 and researchers to understand the implication of configuration 618 choices and transport behaviour as use of ECN increases and new 619 methods emerge [RFC7567] [RFC8087]. ECN-monitoring is expected to 620 become important as AQM is deployed that supports ECN [RFC8087] 622 Section 5.6 describes the transport layer feedback information that 623 accompanies the use of ECN. 625 4. Transport Measurement 627 The common language between network operators and application/content 628 providers/users is packet transfer performance at a layer that all 629 can view and analyze. For most packets, this has been transport 630 layer, until the emergence of QUIC, with the obvious exception of 631 VPNs and IPsec. When encryption conceals more layers in a packet, 632 people seeking understanding of the network operation need to rely 633 more on pattern inferences and other heuristics. The accuracy of 634 measurements therefore suffers, as does the ability to investigate 635 and troubleshoot interactions between different anomalies. For 636 example, the traffic patterns between server and browser are 637 dependent on browser supplier and version, even when the sessions use 638 the same server application (e.g., web e-mail access). Even when 639 measurement datasets are made available (e.g., from endpoints) 640 additional metadata, such as the state of the network, is often 641 required to interpret the data. Collecting and coordinating such 642 metadata is more difficult when the observation point is at a 643 different location to the bottleneck/device under evaluation. 645 Packet sampling techniques can be used to scale processing involved 646 in observing packets on high rate links. This only exports the 647 packet header information of (randomly) selected packets. The 648 utility of these measurements depends on the type of bearer and 649 number of mechanisms used by network devices. Simple routers are 650 relatively easy to manage, a device with more complexity demands 651 understanding of the choice of many system parameters. This level of 652 complexity exists when several network methods are combined. 654 This section discusses topics concerning transport measurement. 656 4.1. Point of Measurement 658 Often measurements can only be understood in the context of the other 659 flows that share a bottleneck. A simple example is the monitoring of 660 AQM. For example, FQ-CODEL [I-D.ietf-aqm-fq-codel], combines sub 661 queues (statistically assigned per flow), management of the queue 662 length (CODEL), flow-scheduling, and a starvation prevention 663 mechanism. Usually such algorithms are designed to be self-tuning, 664 but current methods typically employ heuristics that can result in 665 more loss under certain path conditions (e.g., large RTT, effects of 666 multiple bottlenecks [RFC7567]). 668 In-network measurements that can distinguish between upstream and 669 downstream metrics with respect to the measurement point. They are 670 particularly useful for locating the source of problems or to assess 671 the performance of a network segment or a particular device 672 configuration. 674 4.2. Use by Operators to Plan and Provision Networks 676 Traffic measurements (e.g. Traffic volume, loss, latency) is used by 677 operators to help plan deployment of new equipment and configurations 678 in their networks. Data is also important to equipment vendors who 679 need to understand traffic trends traffic and patterns of usage as 680 inputs to decisions about planning products and provisioning for new 681 deployments. This measurement information can also be correlated 682 with billing information when this is also collected by an operator. 684 A network operator supporting traffic that uses transport header 685 encryption may not have access to per-flow measurement data. Trends 686 in aggregate traffic can be observed and can be related this to the 687 endpoint addresses being used, but it may not be possible to 688 correlate patterns in measurements with changes in transport 689 protocols (e.g., the impact of changes in introducing a new transport 690 protocol mechanism). This increases the dependency on other indirect 691 sources of information to inform planning and provisioning. 693 4.3. Service Performance Measurement 695 Traffic measurements (e.g., traffic volume, loss, latency) can be 696 used by various actors to help understand the performance available 697 to users of a network segment. While active measurements may be used 698 in-network passive measurements can have advantages in terms of 699 eliminating unproductive traffic, reducing the influence of test 700 traffic on the overall traffic mix, and the ability to choose the 701 point of measurement Section 4.1. 703 4.4. Use for Network Diagnostics and Troubleshooting 705 Transport header information is useful for a variety of operational 706 tasks [I-D.mm-wg-effect-encrypt]: to diagnose network problems, 707 assess performance, capacity planning, management of denial of 708 service threats, and responding to user performance questions. These 709 tasks seldom involve the need to determine the contents of the 710 transport payload, or other application details. 712 A network operator supporting traffic that uses transport header 713 encryption can see only encrypted transport headers. This prevents 714 deployment of performance measurement tools that rely on transport 715 protocol information. Choosing to encrypt all information may be 716 expected to reduce the ability for networks to "help" (e.g., in 717 response to tracing issues, making appropriate Quality of Service, 718 QoS, decisions). For some this will be blessing, for others it may 719 be a curse. For example, operational performance data about 720 encrypted flows needs to be determined by traffic pattern analysis, 721 rather than relying on traditional tools. This can impact the 722 ability of the operator to respond to faults, it could require 723 reliance on endpoint diagnostic tools or user involvement in 724 diagnosing and troubleshooting unusual use cases or non-trivial 725 problems. Although many network operators utilise transport 726 information as a part of their operational practice, the network will 727 not break because transport headers are encrypted. 729 4.5. Acceptable Response to Congestion 731 Congestion control is a key transport function. Many network 732 operators implicitly accept that TCP traffic to comply with a 733 behaviour that is acceptable for use in the shared Internet. TCP 734 algorithms have been continuously improved over decades, and they 735 have reached a level of efficiency and correctness that custom 736 application-layer mechanisms will struggle to easily duplicate 737 [RFC8085]. A standards-compliant TCP stack provides congestion 738 control that is therefore judged safe for use across the Internet. 739 Applications developed on top of well-designed transports can be 740 expected to appropriately control their network usage, reacting when 741 the network experiences congestion, by back-off and reduce the load 742 placed on the network. This is the normal expected behaviour for TCP 743 and other IETF-defined transports. 745 Tools exist that can interpret the transport protocol header 746 information to help understand the impact of specific transport 747 protocols (or protocol mechanisms) on other traffic that shares their 748 network. An observation in the network can gain understanding of the 749 dynamics of a flow and its congestion control behaviour. Analysing 750 observed packet sequence numbers can be used to help build confidence 751 that an application flow backs-off its share of the network load in 752 the face of persistent congestion, and hence to understand whether 753 the behaviour is appropriate for sharing limited network capacity. 754 For example, it is common to visualise plots of TCP sequence numbers 755 versus time for a flow to understand how a flow shares available 756 capacity, deduce its dynamics in response to congestion, etc. 758 4.5.1. Measuring Compliance of UDP Traffic 760 UDP provides a minimal message-passing transport that has no inherent 761 congestion control mechanisms. Because congestion control is 762 critical to the stable operation of the Internet, applications and 763 other protocols that choose to use UDP as an Internet transport must 764 employ mechanisms to prevent congestion collapse, avoid unacceptable 765 contributions to jitter/latency, and to establish an acceptable share 766 of capacity with concurrent traffic [RFC8085]. 768 A network operator has no way of knowing the specific methods used by 769 a UDP application, unless the header format can be determined. Tools 770 are needed to understand if UDP flows comply with congestion control 771 expectations and therefore whether there is a need to deploy methods 772 such as rate-limiters, transport circuit breakers or other methods to 773 enforce acceptable usage. UDP flows that expose a well-known header 774 by specifying the format of header fields can allow information to be 775 observed that gains understanding of the dynamics of a flow and its 776 congestion control behaviour. For example, tools exist to monitor 777 various aspects of the RTP and RTCP header information of real-time 778 flows (see Section 3.2). 780 4.5.2. Measuring Transport to Support Network Operations 782 By correlating observations at multiple points along the path (e.g., 783 at the ingress and egress of a network segment), an observer can 784 determine the contribution of a portion of the path to an observed 785 metric (to locate a source of delay, jitter, loss, reordering, 786 congestion marking, etc). 788 Information provided by tools can help determine whether mechanisms 789 are needed in the network to prevent flows from acquiring excessive 790 network capacity. Operators can manage traffic flows (e.g., to 791 prevent flows from acquiring excessive network capacity under severe 792 congestion) by deploying rate-limiters, traffic shaping or network 793 transport circuit breakers [RFC8084]. 795 5. Observing Transport Flows with Encrypted Transport Header Fields 797 This section examines implications of encrypting specific transport 798 header information. 800 5.1. Transport Information at the Network Layer 802 Some transport information is made visible in the network-layer 803 protocol header. These header fields are not encrypted and can be 804 used to make flow observations. Endpoints should expose flow 805 information in the IPv6 Flow Label Section 3.3.1 in the network-layer 806 header. This can be used to inform network-layer queuing, forwarding 807 (e.g., for equal cost multi-path (ECMP) routing, and Link Aggregation 808 (LAG)). For transport measurement, this can provide useful 809 information to assign packets to flows in the data collected by 810 measurement campaigns, but does not directly provide any performance 811 data. Similarly the Differentiated Services CodePoint (DCSP) 812 indicates expected forwarding treatment Section 3.3.2. The ECN field 813 provides observable congestion data and can help inform measurement 814 of flow congestion Section 3.3.3. 816 5.2. An Observable Transport Flow Identifier 818 To measure and analyse a transport protocol, a measurement tool needs 819 to be able to identify traffic flows. Aggregation of sessions, and 820 persistent use of established transport flows by multiple sessions 821 means that a flow at the transport layer is not necessarily the same 822 as a flow seen at the application layer. This is usually not a 823 consequence. Data is measured for the aggregate transport flow. 825 Some measurement methods sample traffic, rather than collecting all 826 packets passing through a measurement point. These methods still 827 require a way to determine the presence, size and position of any 828 observable header fields - but may need to do this without observing 829 a protocol exchange for a connection setup. 831 5.2.1. A Method to Determine Header Format 833 If flow information is observed from transport headers, then there 834 needs to be a way to identify the format of the header Section 3.1. 835 Some IETF transport protocols are identified by an IP protocol number 836 (e.g. ,TCP, SCTP, UDP). All IETF-defined transport protocols include 837 a transport port field in their transport header. Higher layer 838 protocols (e.g., HTTP) can be sometimes be observed by a well-known 839 port value, which can be indicative of the protocol being 840 encapsulated, but there is no way to enforce this usage. This can be 841 used to configure decapsulation, alternatives include a "magic" 842 number placed at the start of each UDP datagram. 844 Once the protocol has been determined, the transport header can be 845 determined from a published specification. If multiple formats are 846 permitted, this may also require observing the protocol version being 847 used and possibly parameter negotiation at connection setup. 849 5.2.2. Use of a Transport as a Substrate 851 When a transport is used as a substrate, the transport provides an 852 encapsulation that allows another transport flow to be within the 853 payload of a transport flow. The transported protocol header may 854 provide additional information for multiplexing multiple flows over 855 the same 5-tuple. The UDP Guidelines [RFC8085] provides some 856 guidance on using UDP as a substrate protocol. If there is no 857 additional information about the protocol transported by the 858 substrate, this may be viewed as an opaque traffic aggregate, and 859 prevents transport measurement in the network. Examples include GRE- 860 in-UDP [RFC8086], SCTP-in-UDP. The GRE-in-UDP encapsulation may 861 encrypt the payload, but does not encrypt the GRE protocol header. 863 5.2.3. Support for Mobility and Flow Migration 865 With the proliferation of mobile connected devices, there is a stated 866 need for connection-oriented protocols to maintain connections after 867 a network migration by an endpoint. The ability and desirability of 868 in-network devices to track such migration depends on the context. 869 On the one hand, a load-balancer device in front of server may find 870 it useful to map a migrated connection to the same server endpoint. 871 On the other hand, a user performing migration to avoid detection may 872 prefer the network not to be able to correlate the different parts of 873 a migrating session. Care must then be exercised to make sure that 874 the information encoded by the endpoints is not sufficient to 875 identify unique flows and facilitate a persistent surveillance attack 876 vector [I-D.mm-wg-effect-encrypt]. 878 The impact of flow migration on measurement activities depends on the 879 data being measured, rate of migration and level of encryption that 880 is employed. Requirements for load balancing and mobility can lead 881 to complex protocol interactions. 883 5.2.4. Flow Start and Stop 885 Transports can expose that start and end of flows in a transport 886 header field (e.g., TCP SYN, FIN, RST). This can also help 887 measurement devices identify the start of flows, or to remove stale 888 flow information. This information is supplemental - flows can start 889 and end at any time, the Internet network layer provides only a best 890 effort service that allows alternate routing, reordering, loss, etc, 891 so a network measurement tool can not rely upon observing these 892 indicators. The time to complete a protocol connection and/or 893 session setup can be reported. 895 Flow information can provide in-network devices to manage their 896 forwarding state [I-D.trammell-plus-statefulness]. It can assist a 897 firewall in deciding which flows are permitted through a security 898 gateway, or to help maintain the network address translation (NAT) 899 bindings in a NAPT or application layer gateway. This information 900 may also find use in load balancers, where visibility of the 5-tuple 901 could assist in selecting a server [I-D.mm-wg-effect-encrypt]. 903 Access to flow information and an observable start/stop indication 904 [I-D.trammell-plus-statefulness] can avoid stateful middleboxes 905 relying on timeouts to remove old state. Without this, middleboxes 906 are unaware when a particular flow ceases to be used by an 907 application[RFC8085]. This can lead to the state table entries 908 keeping state for less time for flows that are not identifiable. 910 5.3. Observable Transport Sequence Number 912 The TCP or RTP sequence number can be observed in one direction (the 913 direction that carries data segments). An authenticated header 914 prevents this field being modified or terminated/split [RFC3135] by a 915 network device, but allows this still to be used to observe progress 916 of the network flow. 918 An incrementing sequence number enables detection of loss (either by 919 correlating ingress and egress value, or when assuming that all 920 packets follow a single path), duplication and reordering (with 921 understanding that not necessarily all packets of a flow follow the 922 same path, and reordering can complicate processing of observations). 923 Tools are widely available to interpret RTP and TCP sequence numbers, 924 ranging from open source tools to dedicated commercial packages. As 925 for TCP, use by in-network measurement devices needs to account for 926 the impact of load-balancing of flows, changes in forwarding 927 behaviour, measurement loss (rather than observed packet loss), etc. 929 5.4. Observable Transport Reception 931 Acknowledgement (ACK) data provides information about the path from 932 the network device to the remote endpoint. The information can help 933 identify packet loss (or the point of loss), RTT, and other network- 934 related performance parameters (e.g., throughput, jitter, 935 reordering). Unless this information is correlated with other data 936 there is no way to disambiguate the cause of impairments (congestion 937 loss, link transmission loss, equipment failure). 939 An in-network device must not modify the flow of end-to-end ACK data 940 when using an authenticated protocol. That is, must not use the in- 941 network methods described in [RFC3449]. This can impact the 942 performance and/or efficiency (e.g., cost) of using paths where the 943 return capacity is limited or has implications on the overall design 944 (e.g., using TCP with cellular mobile uplinks, DOCSIS uplinks). 946 The TCP stream can be observed by correlating the stream of TCP ACKs 947 that flow from a receiver in the return direction. Although these 948 ACKs are cumulative, and are not necessarily sent on the same path as 949 the forward data, when visible, their sequence can confirm successful 950 transmission and the path RTT. In the case of TCP they may also 951 indicate packet loss (duplicate ACKs). 953 An RTP session can provide reception information [RFC3550] [RFC4585] 954 feedback using the RTCP framework. This reception information and 955 can be observed by in-network measurement devices and can be 956 interpreted to provide a variety of quality of experience information 957 for the related RTP flow, as well as basic network performance data 958 (RTT, loss, jitter, etc). 960 5.5. Observable Transport Timestamps 962 The use of timestamps for latency and jitter measurements 963 Section 3.2.4 is discussed in other sections of the current version 964 of the document. 966 5.6. Observable ECN Transport Feedback Information 968 Transport protocols that use ECN Section 3.3.3 need to provide ECN 969 feedback information in the transport header to inform the sender 970 whether packets have been received with an ECN CE-mark [RFC3819]. 971 This information can be in the form of feedback once each RTT 972 [RFC3819] or more frequent. The latter may involve sending a 973 detailed list of all ECN-marked packets (e.g., 974 [I-D.ietf-tcpm-accurate-ecn] and [RFC6679]). The detailed 975 information can provide detail about the pattern and rate of marking. 976 The information provided in these protocol headers can help a network 977 operator to understand the congestion status of the forward path and 978 the impact of marking algorithms on the traffic that is carried 979 [RFC8087]. 981 IETF specifications for Congestion Exposure (CONVEX) [RFC7713] is an 982 example of a framework that monitors reception reports for CE-marked 983 packets to support network operations. 985 5.7. Other Observable Transport Fields 987 This section is not complete - later revision may determine other 988 fields or remove this section. 990 5.8. Interpretation of Transport Header Fields 992 Understanding and analysing transport protocol behaviour typically 993 demands tracking changes to the protocol state at the transport 994 endpoints. Although protocols communicate state information in their 995 protocol headers, a protocol implementation typically also contains 996 internal state that is not directly visible from observing transport 997 protocol headers. Effective measurement tools need to consider that 998 not all packets may be observed (due to drops at the capture tap or 999 because packets take an alternate route that does not pass the tap). 1000 Some flows of packets may also be encapsulated within a maintenance 1001 domain in other protocols, which further complicates analysis. 1003 Some examples of using network measurements of transport headers to 1004 infer internal TCP transport state information include: 1006 o The TCP congestion window (cwnd) and slow start threshold 1007 (ssthresh). Tools for analysing in-network performance of TCP may 1008 observe sequence number to infer the current congestion controller 1009 state. 1010 o The TCP RTT estimator and TCP Retransmission Time Out (RTO) value. 1011 This can be estimated by correlating sequence and acknowledgement 1012 numbers, or possibly by observing TCP timestamp options. 1013 o Use of pacing (and pacing rate) and use of methods such as 1014 Proportional Rate Reduction (PRR) and Congestion Window validation 1015 (CWV). This may be estimated from observing timing of segments 1016 with TCP sequence numbers. This is important to some congestion 1017 control mechanisms and can be important for applications that are 1018 rate limited or send traffic bursts. 1019 o Receiver window and flow control state. This may be inferred from 1020 information in TCP ACK segments. It is important to applications 1021 where the remote endpoint is resource constrained, or the path 1022 exhibits a large RTT. 1023 o Retransmission state and receiver buffer. This may be inferred 1024 from information in TCP ACK segments (especially when SACK blocks 1025 are provided), this can be important to the performance of 1026 applications that send traffic bursts. 1027 o Use of ACK delay and Nagle algorithm. This may be estimated from 1028 observing timing of segments with TCP sequence numbers, and is 1029 important to the performance of thin application flows. 1031 5.9. Requirements for Transport Measurement 1033 Transport measurement and analysis of the impact of network 1034 characteristics have been important to the design of current 1035 transport protocols. Transport measurement introduces the following 1036 requirements to identify the observable information: 1038 o Observable protocol type and version information is needed to 1039 identify the protocol being used when characterising the traffic, 1040 and to enable further observation of the flow. 1041 o Observable format information is needed to allow an observer to 1042 determine the presence of any observable header fields. 1043 o A published specification is needed to allow an observer to 1044 determine the size and position of any observable header fields so 1045 that these fields may be decoded by a measurement tool. 1046 o Observable flow start/stop information can assist some forms of 1047 measurement and has utility for middleboxes that track state. 1049 The need for in-network transport measurement introduces the 1050 following requirements for observable information in transport header 1051 fields: 1053 o Observable transport information to determine the progress of 1054 flows for each direction of communication. This requires 1055 observable packet numbers. 1056 o Observable transport information to determine loss, and understand 1057 the response to congestion for a network segment. This requires 1058 observable reception information (e.g., packet acknowledgment 1059 information). 1060 o Observable transport information is needed for more advanced 1061 measurement of latency, jitter, etc. This requires an observable 1062 field and a method to correlating return information with the 1063 observed field. This could utilise a packet number and/or 1064 transmission timestamp information. This information needs to be 1065 available in both directions of transmission. 1066 o Exposure of Transport ECN feedback provides a powerful tool to 1067 understand ECN-enabled AQM-based networks. (Forward ECN 1068 information is already observable in the network header). 1070 6. The Effect of Encrypting Transport Header Fields 1072 This section explores key implications of working with encrypted 1073 transport protocols. 1075 6.1. Independent Measurement 1077 Independent observation by multiple actors is important for 1078 scientific analysis. Encrypting transport header encryption changes 1079 the ability for other actors to collect and independently analyse 1080 data. Internet transport protocols employ a set of mechanisms. Some 1081 of these need to work in cooperation with the network layer - loss 1082 detection and recovery, congestion detection and congestion control, 1083 some of these need to work only end-to-end (e.g., parameter 1084 negotiation, flow-control). 1086 When encryption conceals information in the transport header, it 1087 could be possible for an applications to provide summary data on 1088 performance and usage of the network. This data could be made 1089 available to other actors. However, this data needs to contain 1090 sufficient detail to understand (and possibly reconstruct the network 1091 traffic pattern for further testing) and to be correlated with the 1092 configuration of the network paths being measured. Sharing 1093 information between actors needs also to consider the privacy of the 1094 user and the incentives for providing accurate and detailed 1095 information. Protocols that expose the state information used by the 1096 transport protocol in their header information (e.g., timestamps used 1097 to calculate RTT, packet numbers used to asses congestion and 1098 requests for retransmission) provide an incentive for the sending 1099 endpoint to provide correct information, increasing confidence that 1100 the observer understands the transport interaction with the network. 1101 This becomes important when considering changes to transport 1102 protocols, changes in network infrastructure, or the emergence of new 1103 traffic patterns. 1105 6.2. Characterising "Unknown" Network Traffic 1107 If "unknown" or "uncharacterised" traffic patterns form a small part 1108 of the traffic aggregate passing through a network device or segment 1109 of the network the path, the dynamics of the uncharacterised traffic 1110 may not have a significant collateral impact on the performance of 1111 other traffic that shares this network segment. Once the proportion 1112 of this traffic increases, the need to monitor the traffic and 1113 determine if appropriate safety measures need to be put in place. 1115 Tracking the impact of new mechanisms and protocols requires traffic 1116 volume to be measured and new transport behaviours to be identified. 1117 This is especially true of protocols operating over a UDP substrate. 1118 The level and style of encryption needs to be considered in 1119 determining how this activity is performed. On a shorter timescale, 1120 information may also need to be collected to manage denial of service 1121 attacks against the infrastructure. 1123 6.3. Accountability and Internet Transport Portocols 1125 Attention therefore needs to be paid to the expected scale of 1126 deployment of new protocols and protocol mechanisms. Whatever the 1127 mechanism, experience has shown that it is often difficult to 1128 correctly implement combination of mechanisms [RFC8085]. These 1129 mechanisms therefore typically evolve as a protocol matures, or in 1130 response to changes in network conditions, changes in network traffic 1131 or changes to application usage. 1133 The growth and diversity of applications and protocols using the 1134 Internet continues to expand - and there has been recent interest in 1135 a wide range of new transport methods, e.g., Larger Initial Window, 1136 Proportional Rate Reduction (PRR), congestion control methods based 1137 on measuring bottleneck bandwidth and round-trip propagation time, 1138 the introduction of AQM techniques and new forms of ECN response 1139 (e.g., Data Centre TCP, DCTP [I-D.ietf-tcpm-dctcp], and methods 1140 proposed for Low Latency Low Loss Scalable throughput, L4S). For 1141 each new method it is desirable to build a body of data reflecting 1142 its behaviour under a wide range of deployment scenarios, traffic 1143 load, and interactions with other deployed/candidate methods. 1145 Measurement therefore has a critical role in the design of transport 1146 protocol mechanisms and their acceptance by the wider community 1147 (e.g., as a method to judge the safety for Internet deployment. Open 1148 standards suggest that such evaluation needs to include independent 1149 observation and evaluation of performance data. 1151 7. Implications on Evolution of the Internet Transport 1153 The transport layer provides the first end-to-end interactions across 1154 the Internet. Transport protocols are layered directly over the 1155 network service and are sent in the payload of network-layer packets. 1156 However, this simple architectural view hides one of the core 1157 functions of the transport - to discover and adapt to the properties 1158 of the Internet path that is currently being used. The design of 1159 Internet transport protocols is as much about trying to avoid the 1160 unwanted side effects of congestion on a flow and other capacity- 1161 sharing flows, avoiding congestion collapse, adapting to changes in 1162 the path characteristics, etc., as it is about end-to-end feature 1163 negotiation, flow control and optimising for performance of a 1164 specific application. 1166 To achieve stable Internet operations the IETF transport community, 1167 has to date, relied heavily on measurement and insight provided from 1168 the wider community to understand the trade-offs and to inform 1169 selection of select appropriate mechanisms to ensure a safe, reliable 1170 and robust Internet since the 1990's. 1172 There are many motivations for deploying encrypted transports, and 1173 encryption of transport payloads. The increasing public concerns 1174 about the interference with Internet traffic have led to a rapidly 1175 expanding deployment of encryption to protect end-user privacy, in 1176 protocols like QUIC. At the same time, network operators and access 1177 providers, especially in mobile networks, have come to rely on the 1178 in-network functionality provided by middleboxes both to enhance 1179 performance and support network operations. 1181 This document has expanded upon the expected implications on 1182 operational practices when working with encrypted transport 1183 protocols, and offers insight into the potential benefit of 1184 authentication, encryption and techniques that require in-network 1185 devices to interpret specific protocol header fields. It presents a 1186 need for architectural changes and consideration of approaches to the 1187 way network transport protocols are designed when using 1188 encryption[Measure]. 1190 The use of encryption at the transport layer comes with implications 1191 that need to be considered: 1193 Troubleshooting and diagnostics: Encrypting all transport 1194 information eliminates the incentive for operators to troubleshoot 1195 what they cannot interpret: one flow experiencing packet loss 1196 looks like any other. When transport header encryption prevents 1197 decoding the transport header (if sequence numbers and flow ID are 1198 obscured), and hence understanding the impact on a particular flow 1199 or flows that share a common network segment. Encrypted traffic 1200 therefore implies "don't touch", and a likely first response will 1201 be "can't help, no trouble found", or the need to add complexity 1202 that comes with an additional operational cost 1203 [I-D.mm-wg-effect-encrypt]. 1205 Open verifyable data: The use of transport header encryption may 1206 reduce the range of actors who can capture useful measurement 1207 data. This may in future restrict the information sources 1208 available to the Internet community to understand the operation of 1209 the network and transport protocols, necessary to inform 1210 standardisation and design decisions for new protocols, equipment 1211 and operational practices. There are dangers in a model where 1212 transport information is only observable at endpoints: i.e., at 1213 user devices and within service platforms and a need for 1214 independently captured data to develop open standards and 1215 stimulate research into new methods. 1217 Operational practice: Published transport specifications allow 1218 operators to check compliance. This can bring assurance to those 1219 operating networks, often avoiding the need to deploy complex 1220 techniques that routinely monitor and manage TCP/IP traffic flows 1221 (e.g. Avoiding the capital and operational costs of deploying 1222 flow rate-limiting and network circuit-breaker methods). This 1223 should continue when encrypted transport headers are used, but 1224 methods need to confirm that the traffic produced conforms to the 1225 expectations of the operator or developer. 1227 Traffic analysis: The use of encryption could make it harder to 1228 determine which transport methods are being used across a network 1229 segment and the trends in usage. This could impact the ability 1230 for an operator to anticipate the need for network upgrades and 1231 roll-out. It can also impact on-going traffic engineering 1232 activities. Although the impact in many case may be small, there 1233 are cases where operators directly support services (e.g., in 1234 radio links, or to troubleshoot QoS-related issues). The more 1235 complex the underlying infrastructure the more important this 1236 impact. 1238 Interactions between mechanisms: An appropriate vantage point, 1239 coupled with timing information for the flow (fine-grained 1240 timestamps) is a valuable tool in benchmarking equipment/ 1241 configurations and understanding non-trivial interactions. 1242 Encryption restricts the ability to explore interactions between 1243 functions at different protocol layers. This is a side-effect of 1244 not allowing a choice of the vantage point from which this 1245 information is observed. This can be important (e.g., in 1246 examining collateral impact of flows sharing a bottleneck, or 1247 where the intention is to understand the interaction between a 1248 layer 2 function (e.g., radio resource management policy, a 1249 channel impairment, an AQM configuration, a Per Hop Behaviour 1250 (PHB) or scheduling method, and a transport protocol). 1252 Common specifications: Since the introduction of congestion control, 1253 TCP has continued to be the predominate transport, with a 1254 consistent approach to avoiding congestion collapse. There is a 1255 risk that the diversity of transport mechanisms could also 1256 increase, with incentives to use a wide range of methods, this is 1257 not in itself a problem, nor is this a direct result of 1258 encryption. Encryption of all headers places the onus on 1259 validation in the hands of developers. While there is little to 1260 doubt that developers will seek to produce high quality code for 1261 their target use, it is not clear whether there is sufficient 1262 incentive to ensure good practice that benefits the wide diversity 1263 of requirements from the Internet community as a whole. The use 1264 of encryption needs to be weighed against the reduced visibility 1265 of the interactions between traffic, the network and the 1266 mechanisms. Especially, if a development cycle could focus on 1267 specific protocols/applications and then offer incentives for 1268 optimisations that could prove suboptimal for users or operators 1269 that utilise a network segments with different characteristics 1270 than targeted by the developer. 1272 Restricting research and development: The use of encryption may 1273 impede independent research into new mechanisms, measurement of 1274 behaviour, and development initiatives. Experience shows that 1275 transport protocols are complicated to design and complex to 1276 deploy, and that individual mechanisms need to be evaluated while 1277 considering other mechanism, across a broad range of network 1278 topologies and with attention to the impact on traffic sharing the 1279 capacity. Adopting pervasive encryption of transport information 1280 could eliminate the independent self-checks that have previously 1281 been in place from research and academic contributors (e.g., the 1282 role of the IRTF ICCRG, and research publications in reviewing new 1283 transport mechanisms and assessing the impact of their 1284 experimental deployment). 1286 Pervasive use of transport header encryption can impact the ways that 1287 future protocols are designed and deployed. The choice of whether 1288 candidate transport designs should encrypt their protocol headers 1289 therefore needs to be taken based not just on security 1290 considerations, but also on the impact on operating networks and the 1291 constrictions this may place on evolution of Internet protocols. 1292 While encryption of all transport information can help reduce 1293 ossification of the transport layer, it could result in ossification 1294 of the network service. There can be advantages in providing a level 1295 of ossification of the header in terms of providing a set of open 1296 specified header fields that are observable from in-network devices. 1298 8. Acknowledgements 1300 The author would like to thank all who have talked to him face-to- 1301 face or via email. ... 1303 This work has received funding from the European Union's Horizon 2020 1304 research and innovation programme under grant agreement No 688421.The 1305 opinions expressed and arguments employed reflect only the authors' 1306 view. The European Commission is not responsible for any use that 1307 may be made of that information. 1309 9. IANA Considerations 1311 XX RFC ED - PLEASE REMOVE THIS SECTION XXX 1313 This memo includes no request to IANA. 1315 10. Security Considerations 1317 This document is about design and deployment considerations for 1318 transport protocols. Authentication, confidentiality protection, and 1319 integrity protection are identified as Transport Features by 1320 RFC8095". As currently deployed in the Internet, these features are 1321 generally provided by a protocol or layer on top of the transport 1322 protocol; no current full-featured standards-track transport protocol 1323 provides these features on its own. Therefore, these features are 1324 not considered in this document, with the exception of native 1325 authentication capabilities of TCP and SCTP for which the security 1326 considerations in RFC4895. 1328 Like congestion control mechanisms, security mechanisms are difficult 1329 to design and implement correctly. It is hence recommended that 1330 applications employ well-known standard security mechanisms such as 1331 DTLS, TLS or IPsec, rather than inventing their own. 1333 11. References 1335 11.1. Normative References 1337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1338 Requirement Levels", BCP 14, RFC 2119, 1339 DOI 10.17487/RFC2119, March 1997, . 1342 11.2. Informative References 1344 [I-D.dolson-plus-middlebox-benefits] 1345 Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, 1346 "Beneficial Functions of Middleboxes", draft-dolson-plus- 1347 middlebox-benefits-03 (work in progress), March 2017. 1349 [I-D.ietf-aqm-codel] 1350 Nichols, K., Jacobson, V., McGregor, A., and J. Jana, 1351 "Controlled Delay Active Queue Management", draft-ietf- 1352 aqm-codel-00 (work in progress), October 2014. 1354 [I-D.ietf-aqm-fq-codel] 1355 Hoeiland-Joergensen, T., McKenney, P., Taht, D., Gettys, 1356 J., and E. Dumazet, "FlowQueue-Codel", draft-ietf-aqm-fq- 1357 codel-00 (work in progress), January 2015. 1359 [I-D.ietf-aqm-pie] 1360 Pan, R., Natarajan, P., Baker, F., and G. White, "PIE: A 1361 Lightweight Control Scheme To Address the Bufferbloat 1362 Problem", draft-ietf-aqm-pie-00 (work in progress), 1363 October 2014. 1365 [I-D.ietf-ippm-6man-pdm-option] 1366 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, 1367 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1368 Option", draft-ietf-ippm-6man-pdm-option-10 (work in 1369 progress), May 2017. 1371 [I-D.ietf-quic-transport] 1372 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1373 and Secure Transport", draft-ietf-quic-transport-03 (work 1374 in progress), May 2017. 1376 [I-D.ietf-tcpm-accurate-ecn] 1377 Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More 1378 Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- 1379 ecn-00 (work in progress), December 2015. 1381 [I-D.ietf-tcpm-dctcp] 1382 Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., 1383 and G. Judd, "Datacenter TCP (DCTCP): TCP Congestion 1384 Control for Datacenters", draft-ietf-tcpm-dctcp-06 (work 1385 in progress), May 2017. 1387 [I-D.ietf-tsvwg-l4s-arch] 1388 Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, 1389 Low Loss, Scalable Throughput (L4S) Internet Service: 1390 Architecture", draft-ietf-tsvwg-l4s-arch-00 (work in 1391 progress), May 2017. 1393 [I-D.mm-wg-effect-encrypt] 1394 Moriarty, K. and A. Morton, "Effect of Pervasive 1395 Encryption on Operators", draft-mm-wg-effect-encrypt-11 1396 (work in progress), April 2017. 1398 [I-D.trammell-plus-abstract-mech] 1399 Trammell, B., "Abstract Mechanisms for a Cooperative Path 1400 Layer under Endpoint Control", draft-trammell-plus- 1401 abstract-mech-00 (work in progress), September 2016. 1403 [I-D.trammell-plus-statefulness] 1404 Kuehlewind, M., Trammell, B., and J. Hildebrand, 1405 "Transport-Independent Path Layer State Management", 1406 draft-trammell-plus-statefulness-02 (work in progress), 1407 December 2016. 1409 [Latency] Briscoe, B., "Reducing Internet Latency: A Survey of 1410 Techniques and Their Merits", November 2014. 1412 [Measure] Fairhurst, G., Kuehlewind, M., and D. Lopez, "Measurement- 1413 based Protocol Design", June 2017. 1415 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1416 "Definition of the Differentiated Services Field (DS 1417 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1418 DOI 10.17487/RFC2474, December 1998, . 1421 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1422 Shelby, "Performance Enhancing Proxies Intended to 1423 Mitigate Link-Related Degradations", RFC 3135, 1424 DOI 10.17487/RFC3135, June 2001, . 1427 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1428 of Explicit Congestion Notification (ECN) to IP", 1429 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1430 . 1432 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 1433 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 1434 . 1436 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 1437 Sooriyabandara, "TCP Performance Implications of Network 1438 Path Asymmetry", BCP 69, RFC 3449, DOI 10.17487/RFC3449, 1439 December 2002, . 1441 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1442 Jacobson, "RTP: A Transport Protocol for Real-Time 1443 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1444 July 2003, . 1446 [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D., 1447 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1448 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1449 RFC 3819, DOI 10.17487/RFC3819, July 2004, 1450 . 1452 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1453 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 1454 December 2005, . 1456 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1457 DOI 10.17487/RFC4302, December 2005, . 1460 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1461 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1462 . 1464 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1465 "Extended RTP Profile for Real-time Transport Control 1466 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 1467 DOI 10.17487/RFC4585, July 2006, . 1470 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1471 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 1472 DOI 10.17487/RFC4737, November 2006, . 1475 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 1476 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 1477 DOI 10.17487/RFC5236, June 2008, . 1480 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1481 (TLS) Protocol Version 1.2", RFC 5246, 1482 DOI 10.17487/RFC5246, August 2008, . 1485 [RFC5559] Eardley, P., Ed., "Pre-Congestion Notification (PCN) 1486 Architecture", RFC 5559, DOI 10.17487/RFC5559, June 2009, 1487 . 1489 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1490 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1491 June 2010, . 1493 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1494 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1495 January 2012, . 1497 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 1498 "IPv6 Flow Label Specification", RFC 6437, 1499 DOI 10.17487/RFC6437, November 2011, . 1502 [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., 1503 and K. Carlberg, "Explicit Congestion Notification (ECN) 1504 for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August 1505 2012, . 1507 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1508 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1509 2014, . 1511 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1512 "Recommendations for Secure Use of Transport Layer 1513 Security (TLS) and Datagram Transport Layer Security 1514 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1515 2015, . 1517 [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF 1518 Recommendations Regarding Active Queue Management", 1519 BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, 1520 . 1522 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1523 Trammell, B., Huitema, C., and D. Borkmann, 1524 "Confidentiality in the Face of Pervasive Surveillance: A 1525 Threat Model and Problem Statement", RFC 7624, 1526 DOI 10.17487/RFC7624, August 2015, . 1529 [RFC7713] Mathis, M. and B. Briscoe, "Congestion Exposure (ConEx) 1530 Concepts, Abstract Mechanism, and Requirements", RFC 7713, 1531 DOI 10.17487/RFC7713, December 2015, . 1534 [RFC7928] Kuhn, N., Ed., Natarajan, P., Ed., Khademi, N., Ed., and 1535 D. Ros, "Characterization Guidelines for Active Queue 1536 Management (AQM)", RFC 7928, DOI 10.17487/RFC7928, July 1537 2016, . 1539 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 1540 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 1541 . 1543 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1544 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1545 March 2017, . 1547 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1548 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1549 March 2017, . 1551 [RFC8087] Fairhurst, G. and M. Welzl, "The Benefits of Using 1552 Explicit Congestion Notification (ECN)", RFC 8087, 1553 DOI 10.17487/RFC8087, March 2017, . 1556 [Tor] The Tor Project, ., "https://www.torproject.org", June 1557 2017. 1559 Appendix A. Revision information 1561 -00 This is an individual draft for the IETF community 1563 -01 This draft was a result of walking away from the text for a few 1564 days and then reorganising the content. 1566 -02 This draft fixes textual errors. 1568 -03 This draft follows feedback from people reading this draft. 1570 Comments from the community are welcome on the text and 1571 recommendations. 1573 Author's Address 1575 Godred Fairhurst 1576 University of Aberdeen 1577 Department of Engineering 1578 Fraser Noble Building 1579 Aberdeen AB24 3UE 1580 Scotland 1582 Email: gorry@erg.abdn.ac.uk 1583 URI: http://www.erg.abdn.ac.uk/