idnits 2.17.1 draft-dolson-transport-middlebox-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 (June 20, 2018) is 2130 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3552' is defined on line 768, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-06 == Outdated reference: A later version (-41) exists of draft-ietf-dots-signal-channel-20 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-08 == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-01 -- Obsolete informational reference (is this intentional?): RFC 3272 (Obsoleted by RFC 9522) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dolson 3 Internet-Draft 4 Intended status: Informational J. Snellman 5 Expires: December 22, 2018 6 M. Boucadair 7 C. Jacquenet 8 Orange 9 June 20, 2018 11 An Inventory of Transport-centric Functions Provided by Middleboxes 12 draft-dolson-transport-middlebox-03 14 Abstract 16 This document summarizes benefits that operators perceive to be 17 provided by intermediary devices that execute functions beyond normal 18 IP forwarding. Such intermediary devices are often called 19 "middleboxes". 21 RFC3234 defines a taxonomy of middleboxes and issues in the Internet. 22 Most of those middleboxes utilize or modify application-layer data. 23 This document primarily focuses on devices that observe and act on 24 information carried in the transport layer, and especially 25 information carried in TCP packets. 27 A primary goal of this document is to provide information to working 28 groups developing new transport protocols, to aid understanding of 29 what might be gained or lost by design decisions that may affect (or 30 be affected by) middlebox operation. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 22, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Operator Perspective . . . . . . . . . . . . . . . . . . 3 68 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5 71 2.2. Round Trip Times . . . . . . . . . . . . . . . . . . . . 6 72 2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 6 73 2.4. Throughput and Bottleneck Identification . . . . . . . . 7 74 2.5. Congestion Responsiveness . . . . . . . . . . . . . . . . 7 75 2.6. Attack Detection . . . . . . . . . . . . . . . . . . . . 7 76 2.7. Packet Corruption . . . . . . . . . . . . . . . . . . . . 8 77 2.8. Application-Layer Measurements . . . . . . . . . . . . . 8 78 3. Functions Beyond Measurement: A Few Examples . . . . . . . . 9 79 3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 9 81 3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 10 82 3.4. Implicit Identification . . . . . . . . . . . . . . . . . 11 83 3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 11 84 3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 12 85 3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 12 86 3.8. Prioritization and Differentiated Services . . . . . . . 13 87 3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 13 88 3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 14 89 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 5.1. Confidentiality & Privacy . . . . . . . . . . . . . . . . 14 92 5.2. Active On-Path Attacks . . . . . . . . . . . . . . . . . 15 93 5.3. Improved Security . . . . . . . . . . . . . . . . . . . . 15 94 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 95 7. Informative References . . . . . . . . . . . . . . . . . . . 15 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 From [RFC3234], "A middlebox is defined as any intermediary device 101 performing functions other than the normal, standard functions of an 102 IP router on the datagram path between a source host and destination 103 host." 105 Middleboxes are usually (but not exclusively) deployed at locations 106 permitting observation of bidirectional traffic flows. Such 107 locations are typically points where leaf networks connect to the 108 Internet; e.g.,: 110 o Where a residential or business customer connects to its service 111 provider(s), which may include multi-homing. 113 o On the Gi interface where a Gateway GPRS Support Node (GGSN) 114 connects to a Packet Data Network (PDN) (Section 3.1 of 115 [RFC6459]). 117 For the purposes of this document (and consistent with the RFC3234 118 definition), middlebox functions may be found in routers and switches 119 in addition to dedicated devices. 121 This document itemizes a variety of features provided by middleboxes 122 and by ad hoc analysis performed by operators using packet analyzers. 124 Many of the techniques described in this document require stateful 125 analysis of transport streams. A generic state machine is described 126 in [I-D.trammell-plus-statefulness]. 128 1.1. Operator Perspective 130 Network operators are often the ones first called upon when 131 applications fail to function properly, often with user reports about 132 application behaviors (not about packet behaviors). Therefore it 133 isn't surprising that operators (wanting to be helpful) desire some 134 visibility into flow information to identify how well the problem 135 flows are progressing and how well other flows are progressing. 137 Advanced service functions (e.g., Network Address Translators (NATs), 138 firewalls, etc.) [RFC7498] are widely used to achieve various 139 objectives such as IP address sharing, firewalling, avoiding covert 140 channels, detecting and protect against ever increasing Distributed 141 Denial of Service (DDoS) attacks, etc. For example, environment- 142 specific designs may require a number of service functions, such as 143 those needed at the Gi interface of a mobile infrastructure 144 [I-D.ietf-sfc-use-case-mobility]. 146 These sophisticated service functions are located in the network but 147 also in service platforms, or intermediate entities (e.g., Content 148 Delivery Networks (CDNs)). Network maintenance and diagnostic 149 operations are complicated, particularly when responsibility is 150 shared among various players. 152 Network Providers are challenged to deliver differentiated services 153 as a competitive business advantage, while mastering the complexity 154 of the applications, (continuously) evaluating the impacts on 155 middleboxes, and enhancing customer's quality of experience. 157 Despite the complexity, removing all those service functions is not 158 an option because they are used to address constraints that are often 159 typical of the current (and changing) Internet. Operators must deal 160 with constraints such as global IPv4 address depletion and must 161 support a plethora of services with different QoS, security, 162 robustness, etc. requirements. 164 1.2. Scope 166 Although many middleboxes observe and manipulate application-layer 167 content (e.g., session boarder controllers [RFC5853]) they are out of 168 scope for this document, the aim being to describe middleboxes using 169 transport-layer features. An earlier document 170 [I-D.mm-wg-effect-encrypt] describes the impact of pervasive 171 encryption of application-layer data on network monitoring, 172 protecting, and troubleshooting. 174 This document is not intended to recommend (or prohibit) middlebox 175 deployment. Many operators have found the value provided by 176 middleboxes to outweigh the added cost and complexity; this document 177 attempts to provide that perspective as a reference in discussion of 178 protocol design trade-offs. 180 This document is not intended to discuss issues related to 181 middleboxes. These issues are well-known and are recorded in 182 existing documents such as [RFC3234] and [RFC6269]. This document 183 aims to elaborate on the motivations leading operators to enable such 184 functions in spite of complications. 186 This document takes an operator perspective that measurement and 187 management of transport connections is of benefit to both parties: 188 for the end-user to receive better quality of experience, and for the 189 network operator to improve resource usage, the former being a 190 consequence of the latter. 192 This document does not discuss whether exposing some data to on-path 193 devices for network assistance purposes can be achieved by using in- 194 band or out-of-band mechanisms. 196 2. Measurements 198 A number of measurements can be made by network devices that are 199 either on-path or off-path. These measurements can be used either by 200 automated systems, or for manual network troubleshooting purposes 201 (e.g., using packet analysis tools). The automated systems can 202 further be classified as monitoring systems that compute performance 203 indicators for single or aggregates of connections and generate 204 aggregated reports from them, and active systems that make decisions 205 also on how to handle packet flows based on these performance 206 indicators. 208 Long-term trends in these measurements can aid an operator in 209 capacity planning. Short-term anomalies revealed by these 210 measurements can identify network breakages, attacks in progress, or 211 misbehaving devices/applications. 213 2.1. Packet Loss 215 It is very useful for an operator to be able to detect and isolate 216 packet loss in a network. 218 Network problems and under-provisioning can be detected if packet 219 loss is measurable. TCP packet loss can be detected by observing 220 gaps in sequence numbers, retransmitted sequence numbers, and SACK 221 options. Packet loss can be detected per direction. 223 Gaps indicate loss upstream of the traffic observation point; 224 retransmissions indicate loss downstream of the traffic observation 225 point. Selective acknowledgements (SACKs, [RFC2018]) can be used to 226 detect either upstream or downstream packet loss (although some care 227 needs to be taken to avoid mis-identifying packet reordering as 228 packet loss), and to distinguish between upstream vs. downstream 229 losses. 231 Packet loss measurements on both sides of the measurement point are 232 an important component in precisely diagnosing insufficiently 233 dimensioned devices or links in networks. Additionally, since packet 234 losses are one of the two main ways for congestion to manifest (the 235 others being queueing delay or Explicit Congestion Notification (ECN, 236 [RFC3168])), packet loss is an important measurement for any 237 middlebox that needs to make traffic handling decisions based on 238 observed levels of congestion. 240 2.2. Round Trip Times 242 The ability to measure partial-path round-trip times is valuable in 243 diagnosing network issues (e.g., abnormal latency, abnormal packet 244 loss). Knowing if latency is poor on one side of the observation 245 point or the other provides more information than is available at 246 either end-point, which can only observe full round-trip times. 248 For example, a TCP packet stream can be used to measure the round- 249 trip time on each side of the measurement point. During the 250 connection handshake, the SYN, SYN/ACK, and ACK timings can be used 251 to establish a baseline Round-Trip Time (RTT) in each direction. 252 Once the connection is established, the RTT between the server and 253 the measurement point can only reliably be determined using TCP 254 timestamps [RFC7323]. On the side between the measurement point and 255 the client, the exact timing of data segments and ACKs can be used as 256 an alternative. For this latter method to be accurate when packet 257 loss is present, the connection must use selective acknowledgements. 259 In many networks, congestion will show up as increasing packet 260 queueing, and congestion-induced packet loss will only happen in 261 extreme cases. RTTs will also show up as a much smoother signal than 262 the discrete packet loss events. This makes RTTs a good way to 263 identify individual subscribers for whom the network is a bottleneck 264 at a given time, or geographical sites (such as cellular towers) that 265 are experiencing large scale congestion. 267 The main limit of RTT measurement as a congestion signal is the 268 difficulty of reliably distinguishing between the data segments being 269 queued vs. the ACKs being queued. 271 2.3. Measuring Packet Reordering 273 If a network is reordering packets of transport connections, caused 274 perhaps by Equal-cost multi-path (ECMP) misconfiguration (e.g., 275 described in [RFC2991] and [RFC7690]), the end-points may react as if 276 packet loss is occurring and retransmit packets or reduce forwarding 277 rates. Therefore a network operator desires the ability to diagnose 278 packet reordering. 280 For TCP, packet reordering can be detected by observing TCP sequence 281 numbers per direction. See for example a number of standard packet 282 reordering metrics in [RFC4737] and informational metrics in 283 [RFC5236]. 285 2.4. Throughput and Bottleneck Identification 287 Although throughput to or from an IP address can be measured without 288 transport-layer measurements, the transport layer provides clues 289 about what the end-points were attempting to do. 291 One way of quickly excluding the network as the bottleneck during 292 troubleshooting is to check whether the speed is limited by the 293 endpoints. For example, the connection speed might instead be 294 limited by suboptimal TCP options, the sender's congestion window, 295 the sender temporarily running out of data to send, the sender 296 waiting for the receiver to send another request, or the receiver 297 closing the receive window. 299 This data is also useful for middleboxes used to measure network 300 quality of service. Connections, or portions of connections, that 301 are limited by the endpoints do not provide an accurate measure of 302 network's speed, and can be discounted or completely excluded in such 303 analyses. 305 2.5. Congestion Responsiveness 307 Congestion control mechanisms continue to evolve. Tools exist that 308 can interpret protocol sequence numbers (e.g., from TCP, RTP) to 309 infer the congestion response of a flow. Such tools can be used by 310 operators to help understand the impact of specific transport 311 protocols on other traffic that shares their network. For example, 312 analysing packet sequence numbers can be used to help understand 313 whether an application flow backs-off its load in the face of 314 persistent congestion (as TCP does), and hence to understand whether 315 the behaviour is appropriate for sharing limited network capacity. 317 These tools can also be used to determine whether mechanisms are 318 needed in the network to prevent flows from acquiring excessive 319 network capacity under severe congestion (e.g., by deploying rate- 320 limiters or network transport circuit breakers [RFC8084]). 322 2.6. Attack Detection 324 When an application or network resource is under attack, it is useful 325 to identify this situation from the network perspective, upstream of 326 the attacked resource. 328 Although detection methods tend to be proprietary, attack detection 329 from within the network may comprise: 331 o Identifying uncharacteristic traffic volumes or sources; 332 o Identifying congestion, possibly using techniques in Section 2.1 333 and Section 2.2; 335 o Identifying incomplete connections or transactions, from attacks 336 which attempt to exhaust server resources; 338 o Fingerprinting based on whatever available fields are determined 339 to be useful in discriminating an attack from desirable traffic. 341 Two trends in protocol design will make attack detection more 342 difficult: 344 o the desire to encrypt transport-layer fields; 346 o the desire to avoid statistical fingerprinting by adding entropy 347 in various forms. 349 While improving privacy, those approaches may hinder attack 350 detection. 352 2.7. Packet Corruption 354 One notable source of packet loss is packet corruption. This 355 corruption will generally not be detected until the checksums are 356 validated by the endpoint, and the packet is dropped. This means 357 that detecting the exact location where packets are lost is not 358 sufficient when troubleshooting networks. An operator would like to 359 find out where packets are being corrupted. IP and TCP checksum 360 verification allows a measurement device to correctly distinguish 361 between upstream packet corruption and normal downstream packet loss. 363 Transport protocol designers should consider whether a middlebox will 364 be able to detect corrupted or tampered packets. 366 2.8. Application-Layer Measurements 368 Network health may also be gleaned from application-layer diagnosis. 369 E.g., 371 o DNS response times and retransmissions by correlating answers to 372 queries. 374 o Various protocol-aware voice and video quality analysis. 376 Could this type of information be provided in a transport layer? 378 3. Functions Beyond Measurement: A Few Examples 380 This section describes features provided by on-path devices that go 381 beyond measurement by modifying, discarding, delaying, or 382 prioritizing traffic. 384 3.1. NAT 386 Network Address Translators (NATs) allow multiple devices to share a 387 public address by dividing the transport-layer port space among the 388 devices. 390 NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] 391 and for TCP in BCP 142 [RFC7857]. 393 To support NAT, there must be transport-layer port numbers that can 394 be modified by the NAT. Note that required fields (e.g., port 395 numbers) are visible in all IETF-defined transport protocols. 397 The application-layer must not assume the port number was left 398 unchanged (e.g., by including it in a checksum or signing it). 400 Address sharing is also used in the context of IPv6 transition. For 401 example, DS-Lite AFTR [RFC6333], NAT64 [RFC6146], or MAP-* are 402 features that are enabled in the network to allow for IPv4 service 403 continuity over an IPv6 network. 405 Further, because of some multi-homing considerations, IPv6 prefix 406 translation may be enabled by some enterprises by means of NPTv6 407 [RFC6296]. 409 3.2. Firewall 411 Firewalls are pervasive and essential components that inspect 412 incoming and outgoing traffic. Firewalls are usually the cornerstone 413 of a security policy that is enforced in end-user premises and other 414 locations to provide strict guarantees about traffic that may be 415 authorized to enter/leave the said premises, as well as end-users who 416 may be assigned different clearance levels regarding which networks 417 and portions of the Internet they access. 419 An important aspect of a firewall policy is differentiating 420 internally-initiated from externally-initiated communications. 422 For TCP, this is easily done by tracking the TCP state machine. 423 Furthermore, the ending of a TCP connection is indicated by RST or 424 FIN flags. 426 For UDP, the firewall can be opened if the first packet comes from 427 an internal user, but the closing is generally done by an idle 428 timer of arbitrary duration, which might not match the 429 expectations of the application. 431 Simple IPv6 firewall capabilities for customer premises equipment 432 (both stateless and stateful) are described in [RFC6092]. 434 A firewall functions better when it can observe the protocol state 435 machine, described generally by Transport-Independent Path Layer 436 State Management [I-D.trammell-plus-statefulness]. 438 3.3. DDoS Scrubbing 440 In the context of a DDoS attack, the purpose of a scrubber is to 441 discard attack traffic while permitting useful traffic. E.g., such a 442 mitigator is described in [I-D.ietf-dots-architecture]. 444 When attacks occur against constrained resources, some traffic will 445 be discarded before reaching the intended destination. A user 446 receives better experience and a server runs more efficiently if a 447 scrubber can discard attack traffic, leaving room for legitimate 448 traffic. 450 Scrubbing must be provided by an on-path network device because 451 neither end-point of a legitimate connection has any control over the 452 source of the attack traffic. 454 Source-spoofed DDoS attacks can be mitigated at the source using BCP 455 38 ([RFC2827]), but it is more difficult if source address filtering 456 cannot be applied. 458 In contrast to devices in the core of the Internet, middleboxes 459 statefully observing bidirectional transport connections can reject 460 source-spoofed TCP traffic based on the inability to provide sensible 461 acknowledgement numbers to complete the three-way handshake. 462 Obviously this requires middlebox visibility into transport-layer 463 state machine. 465 Middleboxes may also scrub on the basis of statistical 466 classification: testing how likely a given packet is legitimate. As 467 protocol designers add more entropy to headers and lengths, this test 468 becomes less useful and the best scrubbing strategy becomes random 469 drop. 471 3.4. Implicit Identification 473 In order to enhance the end-user's quality of experience, some 474 operators deploy implicit identification features that rely upon the 475 correlation of network-related information to access some local 476 services. For example, service portals operated by some operators 477 may be accessed immediately by end-users without any explicit 478 identification for the sake of improved service availability. This 479 is doable thanks to on-path devices that inject appropriate metadata 480 that can be used by the remote server to enforce per-subscriber 481 policies. The information can be injected at the application layer 482 or at the transport layer (when an address sharing mechanism is in 483 use). 485 An experimental implementation using a TCP option is described in 486 [RFC7974]. 488 For the intended use of implicit identification, it is more secure to 489 have a trusted middlebox mark this traffic than to trust end-user 490 devices. 492 3.5. Performance-Enhancing Proxies 494 Performance-Enhancing Proxies (PEPs) can improve performance in some 495 types of networks by improving packet spacing or generating local 496 acknowledgements, and are most commonly used in satellite and 497 cellular networks. Transport-Layer PEPs are described in 498 Section 2.1.1 of [RFC3135]. 500 PEPs allow central deployment of congestion control algorithms more 501 suited to the specific network, most commonly use of delay-based 502 congestion control. More advanced TCP PEPs deploy congestion control 503 systems that treat all of a single end-user's TCP connections as a 504 single unit, improving fairness and allowing faster reaction to 505 changing network conditions. 507 Local acknowledgements generated by PEPs speed up TCP slow start by 508 splitting the effective latency, and allow for retransmissions to be 509 done from the PEP rather than from the actual sender, saving downlink 510 bandwidth on retransmissions. Local acknowledgements will also allow 511 a PEP to maintain a local buffer of data appropriate to the actual 512 network conditions, whereas the actual endpoints would often send too 513 much or too little. 515 A PEP function requires transport-layer fields that allow chunks of 516 data to be identified (e.g., TCP sequence numbers), acknowledgements 517 to be identified (e.g., TCP ACK numbers), and acknowledgements to be 518 created from the PEP. 520 Note that PEPs are only useful in some types of networks, and poor 521 design could make performance worse. 523 3.6. Network Coding 525 Network Coding is a technique for improving transmission performance 526 over low-bandwidth, long-latency links such as some satellite links. 527 Coding may involve lossless compression and/or adding redundancy to 528 headers and payload. A Network Coding Taxonomy is provided by 529 [I-D.irtf-nwcrg-network-coding-taxonomy]; an example of End-to-End 530 Coding is FECFRAME [RFC6363]. It is typically deployed with network- 531 coding gateways at each end of those links, with a network-coding 532 tunnel between them via the slow/lossy/long-latency links. 534 Network coding implementations may be specific to TCP, taking 535 advantage of known properties of the protocol. 537 The network coding gateways may employ some techniques of PEPs, such 538 as creating acknowledgements of queued data, removing retransmissions 539 and pacing data rates to reduce queue oscillation. 541 Note: this is not to be confused with transcoding, which performs 542 lossy compression on transmitted media streams, and not in scope for 543 this document. 545 3.7. Network-Assisted Bandwidth Aggregation 547 The Hybrid Access Aggregation Point is a middlebox that allows 548 customers to aggregate the bandwidth of multiple access technologies. 550 One of the approaches uses MPTCP proxies [I-D.ietf-tcpm-converters] 551 to forward traffic along multiple paths. The MPTCP proxy operates at 552 the transport layer while being located in the operator's network. 554 The support of multipath transport capabilities by communicating 555 hosts remains a privileged target design so that such hosts can 556 directly use the available resources provided by a variety of access 557 networks they can connect to. Nevertheless, network operators do not 558 control end hosts while the support of MPTCP by content servers 559 remains marginal. 561 Network-Assisted MPTCP deployment models are designed to facilitate 562 the adoption of MPTCP for the establishment of multi-path 563 communications without making any assumption about the support of 564 MPTCP capabilities by communicating peers. Network-Assisted MPTCP 565 deployment models rely upon MPTCP Conversion Points (MCPs) that act 566 on behalf of hosts so that they can take advantage of establishing 567 communications over multiple paths [I-D.ietf-tcpm-converters]. 569 Note there are cases when end-to-end MPTCP cannot be used even though 570 both client and server are MPTCP-compliant. An MPTCP proxy can 571 provide multipath utilization in these cases. Examples of such cases 572 are listed below: 574 1. The use of private IPv4 addresses in some access networks. 575 Typically, additional subflows can not be added to the MPTCP 576 connection without the help of an MCP. 578 2. The assignment of IPv6 prefixes only by some networks. If the 579 server is IPv4-only, IPv6 subflows cannot be added to an MPTCP 580 connection established with that server, by definition. 582 3. Subscription to some service offerings is subject to volume 583 quota. 585 3.8. Prioritization and Differentiated Services 587 Bulk traffic may be served with a higher latency than interactive 588 traffic with no reduction in throughput. This fact allows a 589 middlebox function to improve response times in interactive 590 applications by prioritizing, policing, or remarking interactive 591 transport connections differently from bulk traffic transport 592 connections. E.g., gaming traffic may be prioritized over email or 593 software updates. Configuration guidelines for DiffServ service 594 classes are discussed in [RFC4594]. 596 Middleboxes may identify different classes of traffic by inspecting 597 multiple layers of header and length of payload. 599 3.9. Measurement-Based Shaping 601 Basic traffic shaping functionality requires no transport-layer 602 information. All that is needed is a way of mapping each packet to a 603 traffic shaper quota. For example, there may be a rate limit per 604 5-tuple or per subscriber IP address. However, such fixed traffic 605 shaping rules are wasteful as they end up rate limiting traffic even 606 when the network has free resources available. 608 More advanced traffic shaping devices use transport layer metrics 609 described in Section 2 to detect congestion on either a per-site or 610 per-user level, and use different traffic shaping rules when 611 congestion is detected [RFC3272]. This type of device can overcome 612 limitations of downstream devices that behave poorly (e.g., by 613 excessive buffering or sub-optimally dropping packets). 615 3.10. Fairness to End-User Quota 617 Several service offerings rely upon a volume-based charging model 618 (e.g., volume-based data plans offered by cellular providers). 619 Operators may assist end-users in conserving their data quota by 620 deploying on-path functions that shape traffic that would otherwise 621 be aggressively transferred. 623 For example, a fast download of a video that won't be viewed 624 completely by the subscriber may lead to quick exhaustion of the data 625 quota. Limiting the video download rate conserves quota for the 626 benefit of the end-user. 628 4. IANA Considerations 630 This memo includes no request to IANA. 632 5. Security Considerations 634 5.1. Confidentiality & Privacy 636 This document intentionally excludes middleboxes that observe or 637 manipulate application-layer data. 639 The measurements and functions described in this document can all be 640 implemented without violating confidentiality [RFC6973]. However, 641 there is always the question of whether the fields and packet 642 properties used to achieve operational benefits may also be used for 643 harm. 645 In particular, the question is what confidentiality is lost by 646 exposing transport-layer fields beyond what can be learned by 647 observing IP-layer fields: 649 o Sequence numbers: an observer can learn how much data is 650 transferred. 652 o Start/Stop indicators: an observer can count transactions for some 653 applications. 655 o Device fingerprinting: an observer may be more easily able to 656 identify a device type when different devices use different 657 default field values or options. 659 5.2. Active On-Path Attacks 661 Being able to observe sequence numbers or session identifiers by an 662 on-path attacker may make it easier to modify or terminate a 663 transport connection. E.g., observing TCP sequence numbers allows 664 generation of a RST packet that terminates the connection. However, 665 signing transport fields softens this attack. The attack and 666 solution are described for the TCP authentication option [RFC5925]. 667 Still, an on-path attacker can also drop the traffic flow. 669 5.3. Improved Security 671 Network maintainability and security can be improved by providing 672 firewalls and DDoS mechanisms with some information about transport 673 connections. In contrast, it would be very difficult to secure a 674 network in which every packet appears unique and filled with random 675 bits (from the perspective of an on-path device). 677 Some features providing the ability to mitigate/filter attacks owing 678 to a network-assisted mechanism will therefore will improve security 679 (e.g., by means of DOTS signalling [I-D.ietf-dots-signal-channel]). 681 6. Acknowledgements 683 The authors thank Brian Trammell, Brian Carpenter, Mirja Kuehlewind, 684 Kathleen Moriarty, and Gorry Fairhurst for their review and 685 suggestions. 687 7. Informative References 689 [I-D.ietf-dots-architecture] 690 Mortensen, A., Andreasen, F., Reddy, T., 691 christopher_gray3@cable.comcast.com, c., Compton, R., and 692 N. Teague, "Distributed-Denial-of-Service Open Threat 693 Signaling (DOTS) Architecture", draft-ietf-dots- 694 architecture-06 (work in progress), March 2018. 696 [I-D.ietf-dots-signal-channel] 697 Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. 698 Teague, "Distributed Denial-of-Service Open Threat 699 Signaling (DOTS) Signal Channel Specification", draft- 700 ietf-dots-signal-channel-20 (work in progress), May 2018. 702 [I-D.ietf-sfc-use-case-mobility] 703 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 704 J. Uttaro, "Service Function Chaining Use Cases in Mobile 705 Networks", draft-ietf-sfc-use-case-mobility-08 (work in 706 progress), May 2018. 708 [I-D.ietf-tcpm-converters] 709 Bonaventure, O., Boucadair, M., Peirens, B., Seo, S., and 710 A. Nandugudi, "0-RTT TCP Convert Protocol", draft-ietf- 711 tcpm-converters-01 (work in progress), March 2018. 713 [I-D.irtf-nwcrg-network-coding-taxonomy] 714 Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, 715 F., samah.ghanem@gmail.com, s., Lochin, E., Masucci, A., 716 Montpetit, M., Pedersen, M., Peralta, G., Roca, V., 717 Saxena, P., and S. Sivakumar, "Taxonomy of Coding 718 Techniques for Efficient Network Communications", draft- 719 irtf-nwcrg-network-coding-taxonomy-08 (work in progress), 720 March 2018. 722 [I-D.mm-wg-effect-encrypt] 723 Moriarty, K. and A. Morton, "Effects of Pervasive 724 Encryption on Operators", draft-mm-wg-effect-encrypt-25 725 (work in progress), March 2018. 727 [I-D.trammell-plus-statefulness] 728 Kuehlewind, M., Trammell, B., and J. Hildebrand, 729 "Transport-Independent Path Layer State Management", 730 draft-trammell-plus-statefulness-04 (work in progress), 731 November 2017. 733 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 734 Selective Acknowledgment Options", RFC 2018, 735 DOI 10.17487/RFC2018, October 1996, 736 . 738 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 739 Defeating Denial of Service Attacks which employ IP Source 740 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 741 May 2000, . 743 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 744 Multicast Next-Hop Selection", RFC 2991, 745 DOI 10.17487/RFC2991, November 2000, 746 . 748 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 749 Shelby, "Performance Enhancing Proxies Intended to 750 Mitigate Link-Related Degradations", RFC 3135, 751 DOI 10.17487/RFC3135, June 2001, 752 . 754 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 755 of Explicit Congestion Notification (ECN) to IP", 756 RFC 3168, DOI 10.17487/RFC3168, September 2001, 757 . 759 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 760 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 761 . 763 [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and X. 764 Xiao, "Overview and Principles of Internet Traffic 765 Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, 766 . 768 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 769 Text on Security Considerations", BCP 72, RFC 3552, 770 DOI 10.17487/RFC3552, July 2003, 771 . 773 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 774 Guidelines for DiffServ Service Classes", RFC 4594, 775 DOI 10.17487/RFC4594, August 2006, 776 . 778 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 779 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 780 DOI 10.17487/RFC4737, November 2006, 781 . 783 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 784 Translation (NAT) Behavioral Requirements for Unicast 785 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 786 2007, . 788 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 789 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 790 DOI 10.17487/RFC5236, June 2008, 791 . 793 [RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., 794 Hawrylyshen, A., and M. Bhatia, "Requirements from Session 795 Initiation Protocol (SIP) Session Border Control (SBC) 796 Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, 797 . 799 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 800 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 801 June 2010, . 803 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 804 Capabilities in Customer Premises Equipment (CPE) for 805 Providing Residential IPv6 Internet Service", RFC 6092, 806 DOI 10.17487/RFC6092, January 2011, 807 . 809 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 810 NAT64: Network Address and Protocol Translation from IPv6 811 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 812 April 2011, . 814 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and 815 P. Roberts, "Issues with IP Address Sharing", RFC 6269, 816 DOI 10.17487/RFC6269, June 2011, 817 . 819 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 820 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 821 . 823 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 824 Stack Lite Broadband Deployments Following IPv4 825 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 826 . 828 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 829 Correction (FEC) Framework", RFC 6363, 830 DOI 10.17487/RFC6363, October 2011, 831 . 833 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 834 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 835 Partnership Project (3GPP) Evolved Packet System (EPS)", 836 RFC 6459, DOI 10.17487/RFC6459, January 2012, 837 . 839 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 840 Morris, J., Hansen, M., and R. Smith, "Privacy 841 Considerations for Internet Protocols", RFC 6973, 842 DOI 10.17487/RFC6973, July 2013, 843 . 845 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 846 Scheffenegger, Ed., "TCP Extensions for High Performance", 847 RFC 7323, DOI 10.17487/RFC7323, September 2014, 848 . 850 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 851 Service Function Chaining", RFC 7498, 852 DOI 10.17487/RFC7498, April 2015, 853 . 855 [RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of 856 the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too 857 Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, 858 . 860 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 861 S., and K. Naito, "Updates to Network Address Translation 862 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 863 DOI 10.17487/RFC7857, April 2016, 864 . 866 [RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental 867 TCP Option for Host Identification", RFC 7974, 868 DOI 10.17487/RFC7974, October 2016, 869 . 871 [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", 872 BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, 873 . 875 Authors' Addresses 877 David Dolson 879 Email: ddolson@acm.org 881 Juho Snellman 883 Email: jsnell@iki.fi 885 Mohamed Boucadair 886 Orange 887 4 rue du Clos Courtel 888 Rennes 35000 889 France 891 Email: mohamed.boucadair@orange.com 892 Christian Jacquenet 893 Orange 894 4 rue du Clos Courtel 895 Rennes 35000 896 France 898 Email: christian.jacquenet@orange.com