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