idnits 2.17.1 draft-dolson-plus-middlebox-benefits-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2017) is 2604 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-boucadair-mptcp-plain-mode-09 == Outdated reference: A later version (-18) exists of draft-ietf-dots-architecture-01 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-07 == Outdated reference: A later version (-04) exists of draft-trammell-plus-statefulness-02 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Dolson 3 Internet-Draft J. Snellman 4 Intended status: Informational Sandvine 5 Expires: September 10, 2017 M. Boucadair 6 C. Jacquenet 7 Orange 8 March 9, 2017 10 Beneficial Functions of Middleboxes 11 draft-dolson-plus-middlebox-benefits-03 13 Abstract 15 At IETF97, at a meeting regarding the Path Layer UDP Substrate (PLUS) 16 protocol, a request was made for documentation about the benefits 17 that might be provided by permitting middleboxes to have some 18 visibility to transport-layer information. 20 This document summarizes benefits provided to the Internet by 21 intermediary devices that provide functions apart from normal IP 22 forwarding. Such intermediary devices are often called 23 "middleboxes". 25 RFC3234 defines a taxonomy of middleboxes and issues in the Internet. 26 Most of those middleboxes utilize or modify application-layer data. 27 This document primarily focuses on devices that observe and act on 28 information carried in the transport layer, and especially 29 information carried in TCP packets. 31 A primary goal of this document is to provide information to working 32 groups developing new transport protocols, in particular the PLUS and 33 QUIC working groups, to aid understanding of what might be gained or 34 lost by design decisions that may affect (or be affected by) 35 middlebox operation. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 10, 2017. 54 Copyright Notice 56 Copyright (c) 2017 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 73 2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.2. Round Trip Times . . . . . . . . . . . . . . . . . . . . 5 76 2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 5 77 2.4. Throughput and Bottleneck Identification . . . . . . . . 6 78 2.5. DDoS Detection . . . . . . . . . . . . . . . . . . . . . 6 79 2.6. Packet Corruption . . . . . . . . . . . . . . . . . . . . 7 80 2.7. Application-Layer Measurements . . . . . . . . . . . . . 7 81 3. Functions Beyond Measurement: A Few Examples . . . . . . . . 7 82 3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 8 85 3.4. Implicit Identification . . . . . . . . . . . . . . . . . 9 86 3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 10 87 3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 10 88 3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 10 89 3.8. Prioritization and Differentiated Services . . . . . . . 11 90 3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 12 91 3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 12 92 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 95 6.1. Confidentiality . . . . . . . . . . . . . . . . . . . . . 12 96 6.2. Active Attacks . . . . . . . . . . . . . . . . . . . . . 13 97 6.3. More Information Can Improve Security . . . . . . . . . . 13 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 100 7.2. Informative References . . . . . . . . . . . . . . . . . 15 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 103 1. Introduction 105 From RFC3234 [RFC3234], "A middlebox is defined as any intermediary 106 device performing functions other than the normal, standard functions 107 of an IP router on the datagram path between a source host and 108 destination host." 110 Middleboxes are usually (but not exclusively) deployed at locations 111 permitting observation of bidirectional traffic flows. Such 112 locations are typically points where stub networks connect to the 113 Internet; e.g.,: 115 o Where a residential or business customer connects to its service 116 provider(s), which may include multi-homing. 118 o On the Gi interface where a GGSN connects to a PDN (see section 119 3.1 of [RFC6459]). 121 The QUIC working group and PLUS BoF are debating the appropriate 122 amount of information that end-points should expose to on-path 123 network middleboxes and human trouble-shooters. (Some information 124 used for debugging is discussed in .) This document itemizes a variety of 126 features provided by middleboxes and by ad hoc analysis performed by 127 operators using packet analyzers. 129 Many of the techniques described in this document require stateful 130 analysis of transport streams. A generic state machine is described 131 in [I-D.trammell-plus-statefulness]. 133 Although many middleboxes observe and manipulate application-layer 134 content (e.g., session boarder controllers [RFC5853]) they are out of 135 scope for this document, the aim being to describe benefits of 136 middleboxes using transport-layer features. An earlier document 137 [I-D.mm-wg-effect-encrypt] describes the impact of pervasive 138 encryption of application-layer data on network monitoring, 139 protecting and troubleshooting. 141 This document advocates for transport connections to be measured and 142 managed by the network for the benefit of both parties: for the end- 143 user to receive better quality of experience, and for the network 144 operator to improve resource usage, the former being a consequence of 145 the latter. 147 This document does not discuss whether exposing some data to on-path 148 devices for network assistance purposes can be achieved by using in- 149 band or out-of-band mechanisms. 151 1.1. Requirements Language 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 2. Measurements 159 A number of measurements can be made by network devices that are 160 either in-line with the traffic (responsible for forwarding) or 161 receiving off-line copy of traffic from a tap or file capture. These 162 measurements can be used either by automated systems, or for manual 163 network troubleshooting purposes (e.g., using packet analysis tools). 164 The automated systems can further be classified as monitoring systems 165 that compute performance indicators for large numbers of connections 166 and generate aggregated reports from them, and active systems that 167 make decisions on how to handle specific packets based on these 168 performance indicators. 170 Long-term trends in these measurements can aid an operator in 171 capacity planning. Short-term anomalies revealed by these 172 measurements can identify network breakages, attacks in progress, or 173 misbehaving devices/applications. 175 2.1. Packet Loss 177 Network problems and under-provisioning can be detected if packet 178 loss is measurable. TCP packet loss can be detected by observing 179 gaps in sequence numbers, retransmitted sequence numbers, and SACK 180 options. Packet loss can be detected per direction. 182 Gaps indicate loss upstream of the tap point; retransmissions 183 indicate loss downstream of the tap. Selective acknowledgements 184 (SACKs) can be used to detect either upstream or downstream packet 185 loss (although some care needs to be taken to avoid mis-identifying 186 packet reordering as packet loss), and to distinguish between 187 upstream vs. downstream losses. 189 Packet loss measurements on both sides of the measurement point are 190 an important component in precisely diagnosing insufficiently 191 dimensioned devices or links in networks. Additionally, since packet 192 losses are one of the two main ways for congestion to manifest (the 193 other being queueing delay), packet loss is an important measurement 194 for any middlebox that needs to make traffic handling decisions based 195 on observed levels of congestion. 197 2.2. Round Trip Times 199 A TCP packet stream can be used to measure the round-trip time on 200 each side of the measurement point. During the connection handshake, 201 the SYN, SYNACK, and ACK timings can be used to establish a baseline 202 RTT in each direction. Once the connection is established, the RTT 203 between the server and the measurement point can only reliably be 204 determined using TCP timestamps. On the side between the measurement 205 point and the client, the exact timing of data segments and ACKs can 206 be used as an alternative. For this latter method to be accurate 207 when packet loss is present, the connection must use selective 208 acknowledgements. 210 In many networks, congestion will show up as increasing packet 211 queueing, and congestion-induced packet loss will only happen in 212 extreme cases. RTTs will also show up as a much smoother signal than 213 the discrete packet loss events. This makes RTTs a good way to 214 identify individual subscribers for whom the network is a bottleneck 215 at a given time, or geographical sites (such as cellular towers) that 216 are experiencing large scale congestion. 218 The main limit of RTT measurement as a congestion signal is the 219 difficulty of reliably distinguishing between the data segments being 220 queued vs. the ACKs being queued. 222 2.3. Measuring Packet Reordering 224 If a network is reordering packets of transport connections, caused 225 perhaps by ECMP misconfiguration (e.g., described in [RFC2991] and 226 [RFC7690]), the end-points may react as if packet loss is occurring 227 and retransmit packets or reduce forwarding rates. It is therefore 228 beneficial to be able to diagnose packet reordering from within a 229 network. 231 For TCP, packet reordering can be detected by observing TCP sequence 232 numbers per direction. See for example a number of standard packet 233 reordering metrics in [RFC4737] and informational metrics in 234 [RFC5236]. 236 2.4. Throughput and Bottleneck Identification 238 Although throughput to or from an IP address can be measured without 239 transport-layer measurements, the transport layer provides clues 240 about what the end-points were attempting to do. 242 One way of quickly excluding the network as the bottleneck during 243 troubleshooting is to check whether the speed is limited by the 244 endpoints. For example, the connection speed might instead be 245 limited by suboptimal TCP options, the sender's congestion window, 246 the sender temporarily running out of data to send, the sender 247 waiting for the receiver to send another request, or the receiver 248 closing the receive window. 250 This data is also useful for middleboxes used to measure network 251 quality of service. Connections, or portions of connections, that 252 are limited by the endpoints do not provide an accurate measure of 253 network's speed, and can be discounted or completely excluded in such 254 analyses. 256 2.5. DDoS Detection 258 When an application or network resource is under attack, it is useful 259 to identify this situation from the network perspective, upstream of 260 the attacked resource. 262 Although detection methods tend to be proprietary, DDoS attack 263 detection is fundamentally one of: 265 o detecting protocol violations by tracking the transport-layer 266 state machine or application-layer messaging; or 268 o anomaly detection by noticing atypical traffic patterns taken from 269 measurements. 271 Two trends in protocol design will make DDoS detection more 272 difficult: 274 o the desire to encrypt transport-layer communication and sequence 275 numbers; 277 o the desire to avoid statistical fingerprinting by adding entropy 278 in various forms. 280 Those desires assist in the worthy goal of improved privacy, but also 281 serve to defeat DDoS detection. 283 2.6. Packet Corruption 285 One notable source of packet loss is packet corruption. This 286 corruption will generally not be detected until the checksums are 287 validated by the endpoint, and the packet is dropped. This means 288 that detecting the exact location where packets are lost is not 289 sufficient when troubleshooting networks. It should also be possible 290 to find out where packets are being corrupted. IP and TCP checksum 291 verification allows a measurement device to correctly distinguish 292 between upstream packet corruption and normal downstream packet loss. 294 Transport protocol designers should consider whether a middlebox will 295 be able to detect corrupted or tampered packets. 297 2.7. Application-Layer Measurements 299 Network health may also be gleaned from application-layer diagnosis. 300 E.g., 302 o DNS response times and retransmissions by correlating answers to 303 queries. 305 o Various protocol-aware voice and video quality analysis. 307 Could this type of information be provided in a transport layer? 309 3. Functions Beyond Measurement: A Few Examples 311 This section describes features provided by in-line devices that go 312 beyond measurement by modifying, discarding, delaying, or 313 prioritizing traffic. 315 3.1. NAT 317 Network Address Translators (NATs) allow multiple devices to share a 318 public address by dividing the transport-layer port space among the 319 devices. 321 NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] 322 and for TCP in BCP 142 [RFC7857]. 324 To support NAT, there must be transport-layer port numbers that can 325 be modified by the network. The application-layer must not assume 326 the port number was left unchanged (e.g., by including it in a 327 checksum or signing it). 329 Address sharing is also used in the context of IPv6 transition. For 330 example, DS-Lite AFTR [RFC6333], NAT64 [RFC6146], or MAP-* are 331 features that are enabled in the network to allow for IPv4 service 332 continuity over an IPv6 network. 334 Further, because of some multi-homing considerations, IPv6 prefix 335 translation may be enabled by some enterprises by means of NPTv6 336 [RFC6296]. 338 3.2. Firewall 340 Firewalls are pervasive and essential components that inspect 341 incoming and outgoing traffic. Firewalls are usually the cornerstone 342 of a security policy that is enforced in end-user premises and other 343 locations to provide strict guarantees about traffic that may be 344 authorized to enter/leave the said premises, as well as end-users who 345 may be assigned different clearance levels regarding which networks 346 and portions of the Internet they may acess. 348 Arguably many users within various types of organizations would not 349 have been granted Internet access if not for safety provided by 350 firewalls. 352 An important aspect of a firewall policy is differentiating 353 internally-initiated from externally-initiated communications. 355 For TCP, this is easily done by tracking the TCP state machine. 356 Furthermore, the ending of a TCP connection is indicated by RST or 357 FIN flags. 359 For UDP, the firewall can be opened if the first packet comes from 360 an internal user, but the closing is generally done by an idle 361 timer of arbitrary duration, which might not match the 362 expectations of the application. 364 Simple IPv6 firewall capabilities for customer premises equipment 365 (both stateless and stateful) are described in [RFC6092]. 367 A firewall functions better when it can observe the protocol state 368 machine, described generally by Transport-Independent Path Layer 369 State Management [I-D.trammell-plus-statefulness]. 371 3.3. DDoS Scrubbing 373 In the context of a distributed denial-of-service (DDoS) attack, the 374 purpose of a scrubber is to discard attack traffic while permitting 375 useful traffic. E.g., such a mitigator is described in 376 [I-D.ietf-dots-architecture]. 378 When attacks occur against constrained resources, there is obviously 379 a huge benefit in being able to scrub well. 381 Furthermore, this is solely a task for an on-path network device 382 because neither end-point of a legitimate connection has any control 383 over the source of the attack traffic. 385 Source-spoofed DDoS attacks can be mitigated at the source using BCP 386 38 ([RFC2827]), but it is more difficult if source address filtering 387 cannot be applied. 389 In contrast to devices in the core of the Internet, middleboxes 390 statefully observing bidirectional transport connections can reject 391 source-spoofed TCP traffic based on the inability to provide sensible 392 acknowledgement numbers to complete the three-way handshake. 393 Obviously this requires middlebox visibility into transport-layer 394 state machine. 396 Middleboxes may also scrub on the basis of statistical 397 classification: testing how likely a given packet is legitimate. As 398 protocol designers add more entropy to headers and lengths, this test 399 becomes less useful and the best scrubbing strategy becomes random 400 drop. 402 3.4. Implicit Identification 404 In order to enhance the end-user's quality of experience, some 405 operators deploy implicit identification features that rely upon the 406 correlation of network-related information to access some local 407 services. For example, service portals operated by some operators 408 may be accessed immediately by end-users without any explicit 409 identification for the sake of improved service availability. This 410 is doable thanks to on-path devices that inject appropriate metadata 411 that can be used by the remote server to enforce per-subscriber 412 policies. The information can be injected at the application layer 413 or at the transport layer (when an address sharing mechanism is in 414 use). 416 An experimental implementation using a TCP option is described in 417 [RFC7974]. 419 For the intended use of implicit identification, it is more secure to 420 have a trusted middlebox mark this traffic than to trust end-user 421 devices. 423 3.5. Performance-Enhancing Proxies 425 Performance-Enhancing Proxies (PEPs) can improve performance in some 426 types of networks by improving packet spacing or generating local 427 acknowledgements, and are most commonly used in satellite and 428 cellular networks. Transport-Layer PEPs are described in section 429 2.1.1 of [RFC3135]. 431 PEPs allow central deployment of congestion control algorithms more 432 suited to the specific network, most commonly use of delay-based 433 congestion control. More advanced TCP PEPs deploy congestion control 434 systems that treat all of a single end-user's TCP connections as a 435 single unit, improving fairness and allowing faster reaction to 436 changing network conditions. 438 Local acknowledgements generated by PEPs speed up TCP slow start by 439 splitting the effective latency, and allow for retransmissions to be 440 done from the PEP rather than from the actual sender, saving downlink 441 bandwidth on retransmissions. Local acknowledgements will also allow 442 a PEP to maintain a local buffer of data appropriate to the actual 443 network conditions, whereas the actual endpoints would often send too 444 much or too little. 446 A PEP function requires transport-layer fields that allow chunks of 447 data to be identified (e.g., TCP sequence numbers), acknowledgements 448 to be identified (e.g., TCP ACK numbers), and acknowledgements to be 449 created from the PEP. 451 Note that PEPs are only useful in some types of networks, and poor 452 design could make performance worse. 454 3.6. Network Coding 456 Network Coding is a technique for compressing traffic or adding 457 redundancy for transmission over low-bandwidth, long-latency links 458 such as satellite links. One method is to deploy network-coding 459 gateways at each end of those links, with a network-coding tunnel 460 between them via the slow/lossy/long-latency links. 462 The network coding gateways may employ some techniques of PEPs, such 463 as creating acknowledgements of queued data, removing retransmissions 464 and pacing data rates to reduce queue oscillation. 466 3.7. Network-Assisted Bandwidth Aggregation 468 The Hybrid Access Aggregation Point (HAAP) is a middlebox that allows 469 customers to aggregate the bandwidth of multiple access technologies 470 [I-D.zhang-banana-problem-statement]. 472 One of the approaches uses MPTCP proxies 473 [I-D.nam-mptcp-deployment-considerations] to forward traffic along 474 multiple paths. The MPTCP proxy operates at the transport layer 475 while being located in the operator's network. 477 The support of multipath transport capabilities by communicating 478 hosts remains a privileged target design so that such hosts can 479 directly use the available resources provided by a variety of access 480 networks they can connect to. Nevertheless, network operators do not 481 control end hosts while the support of MPTCP by content servers 482 remains marginal. 484 Network-Assisted MPTCP deployment models are designed to facilitate 485 the adoption of MPTCP for the establishment of multi-path 486 communications without making any assumption about the support of 487 MPTCP capabilities by communicating peers. Network-Assisted MPTCP 488 deployment models rely upon MPTCP Conversion Points (MCPs) that act 489 on behalf of hosts so that they can take advantage of establishing 490 communications over multiple paths [I-D.boucadair-mptcp-plain-mode]. 492 Note that an MPTCP proxy can be beneficial even if both the client 493 and the server are MPTCP-compliant. Examples of such cases are 494 listed below: 496 1. The use of private IPv4 addresses in some access networks. 497 Typically, additional subflows can not be added to the MPTCP 498 connection without the help of an MCP. 500 2. The assignment of IPv6 prefixes only by some networks. If the 501 server is IPv4-only, IPv6 subflows cannot be added to an MPTCP 502 connection established with that server, by definition. 504 3. Subscription to some service offerings is subject to volume 505 quota. 507 3.8. Prioritization and Differentiated Services 509 Bulk traffic may be served with a higher latency than interactive 510 traffic with no reduction in throughput. This fact allows a 511 middlebox function to improve response times in interactive 512 applications by prioritizing, policing, or remarking interactive 513 transport connections differently from bulk traffic transport 514 connections. E.g., gaming traffic may be prioritized over email or 515 software updates. 517 Middleboxes may identify different classes of traffic by inspecting 518 multiple layers of header and payload. 520 3.9. Measurement-Based Shaping 522 Basic traffic shaping functionality requires no transport-layer 523 information. All that is needed is a way of mapping each packet to a 524 traffic shaper quota. For example, there may be a rate limit per 525 5-tuple or per subscriber IP address. However, such fixed traffic 526 shaping rules are wasteful as they end up rate limiting traffic even 527 when the network has free resources available. 529 More advanced traffic shaping devices use transport layer metrics 530 described in Section 2 to detect congestion on either a per-site or 531 per-user level, and use different traffic shaping rules when 532 congestion is detected. This type of device can overcome limitations 533 of down-stream devices that behave poorly (e.g., by excessive 534 buffering or sub-optimally dropping packets). 536 3.10. Fairness to End-User Quota 538 Several service offerings rely upon a volume-based charging model. 539 Operators may assist end-users in conserving their data quota by 540 deploying on-path functions that shape traffic that would otherwise 541 be agressively transferred. 543 For example, a fast download of a video that won't be viewed 544 completely by the subscriber may lead to quick exhaustion of the data 545 quota. Limiting the video download rate conserves quota for the 546 benefit of the end-user. 548 4. Acknowledgements 550 The authors thank Brian Trammell and Brian Carpenter for their review 551 and suggestions. 553 5. IANA Considerations 555 This memo includes no request to IANA. 557 6. Security Considerations 559 6.1. Confidentiality 561 This document intentionally excludes middleboxes that observe or 562 manipulate application-layer data. 564 The benefits described in this document can all be implemented 565 without violating confidentiality. However, there is always the 566 question of whether the fields and packet properties used to achieve 567 these benefits may also be used for harm. 569 In particular, we want to ask what confidentiality is lost by 570 exposing transport-layer fields beyond what can be learned by 571 observing IP-layer fields. 573 Sequence numbers: an observer can learn how much data is transferred. 575 Start/Stop indicators: an observer can count transactions for some 576 applications. 578 Device fingerprinting: an observer may be more easily able to 579 identify a device type when different devices use different default 580 field values or options. 582 6.2. Active Attacks 584 Being able to observe sequence numbers or session identifiers may 585 make it easier to modify or terminate a transport connection. E.g., 586 observing TCP sequence numbers allows generation of a RST packet that 587 terminates the connection. However, signing transport fields 588 mitigates this attack. The attack and solution are described for the 589 TCP authentication option [RFC5925]. 591 6.3. More Information Can Improve Security 593 Proposition: network maintainability and security can be improved by 594 providing firewalls and DDoS mechanisms with some information about 595 transport connections. In contrast, it would be very difficult to 596 secure a network in which every packet appears unique and filled with 597 random bits. 599 For denial-of-service (DoS) attacks on bandwidth, the receiving end- 600 point is usually on the wrong side of the constrained network link. 601 This fact makes it seem reasonable to give some clues to allow a 602 middlebox device to help out before the constrained link. 604 E.g., in a blind attack, an attacker cannot receive data from the 605 target of the attack (section 4.6.3.2 of [RFC3552]). In the case of 606 TCP, the blind attacker cannot complete the three-way handshake. 608 In the balance, some features providing the ability to mitigate/ 609 filter attacks and fix broken networks will improve security vs. the 610 scenario when all packets are completely opaque. 612 7. References 613 7.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, 617 DOI 10.17487/RFC2119, March 1997, 618 . 620 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 621 Defeating Denial of Service Attacks which employ IP Source 622 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 623 May 2000, . 625 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 626 Text on Security Considerations", BCP 72, RFC 3552, 627 DOI 10.17487/RFC3552, July 2003, 628 . 630 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 631 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 632 DOI 10.17487/RFC4737, November 2006, 633 . 635 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address 636 Translation (NAT) Behavioral Requirements for Unicast 637 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 638 2007, . 640 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 641 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 642 June 2010, . 644 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 645 NAT64: Network Address and Protocol Translation from IPv6 646 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 647 April 2011, . 649 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 650 Stack Lite Broadband Deployments Following IPv4 651 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 652 . 654 [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., Sivakumar, 655 S., and K. Naito, "Updates to Network Address Translation 656 (NAT) Behavioral Requirements", BCP 127, RFC 7857, 657 DOI 10.17487/RFC7857, April 2016, 658 . 660 7.2. Informative References 662 [I-D.boucadair-mptcp-plain-mode] 663 Boucadair, M., Jacquenet, C., Bonaventure, O., Behaghel, 664 D., stefano.secci@lip6.fr, s., Henderickx, W., Skog, R., 665 Vinapamula, S., Seo, S., Cloetens, W., Meyer, U., 666 Contreras, L., and B. Peirens, "An MPTCP Option for 667 Network-Assisted MPTCP", draft-boucadair-mptcp-plain- 668 mode-09 (work in progress), October 2016. 670 [I-D.ietf-dots-architecture] 671 Mortensen, A., Andreasen, F., Reddy, T., 672 christopher_gray3@cable.comcast.com, c., Compton, R., and 673 N. Teague, "Distributed-Denial-of-Service Open Threat 674 Signaling (DOTS) Architecture", draft-ietf-dots- 675 architecture-01 (work in progress), October 2016. 677 [I-D.mm-wg-effect-encrypt] 678 Moriarty, K. and A. Morton, "Effect of Pervasive 679 Encryption", draft-mm-wg-effect-encrypt-07 (work in 680 progress), February 2017. 682 [I-D.nam-mptcp-deployment-considerations] 683 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 684 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 685 Deployment Scenarios and Operational Considerations", 686 draft-nam-mptcp-deployment-considerations-01 (work in 687 progress), December 2016. 689 [I-D.trammell-plus-statefulness] 690 Kuehlewind, M., Trammell, B., and J. Hildebrand, 691 "Transport-Independent Path Layer State Management", 692 draft-trammell-plus-statefulness-02 (work in progress), 693 December 2016. 695 [I-D.zhang-banana-problem-statement] 696 Cullen, M., Leymann, N., Heidemann, C., Boucadair, M., 697 Hui, D., Zhang, M., and B. Sarikaya, "Problem Statement: 698 Bandwidth Aggregation for Internet Access", draft-zhang- 699 banana-problem-statement-03 (work in progress), October 700 2016. 702 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 703 Multicast Next-Hop Selection", RFC 2991, 704 DOI 10.17487/RFC2991, November 2000, 705 . 707 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 708 Shelby, "Performance Enhancing Proxies Intended to 709 Mitigate Link-Related Degradations", RFC 3135, 710 DOI 10.17487/RFC3135, June 2001, 711 . 713 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 714 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 715 . 717 [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and R. 718 Whitner, "Improved Packet Reordering Metrics", RFC 5236, 719 DOI 10.17487/RFC5236, June 2008, 720 . 722 [RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., 723 Hawrylyshen, A., and M. Bhatia, "Requirements from Session 724 Initiation Protocol (SIP) Session Border Control (SBC) 725 Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, 726 . 728 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 729 Capabilities in Customer Premises Equipment (CPE) for 730 Providing Residential IPv6 Internet Service", RFC 6092, 731 DOI 10.17487/RFC6092, January 2011, 732 . 734 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 735 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 736 . 738 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 739 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 740 Partnership Project (3GPP) Evolved Packet System (EPS)", 741 RFC 6459, DOI 10.17487/RFC6459, January 2012, 742 . 744 [RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of 745 the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too 746 Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, 747 . 749 [RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental 750 TCP Option for Host Identification", RFC 7974, 751 DOI 10.17487/RFC7974, October 2016, 752 . 754 Authors' Addresses 756 David Dolson 757 Sandvine 758 408 Albert Street 759 Waterloo, ON N2L 3V3 760 Canada 762 Phone: +1 519 880 2400 763 Email: ddolson@sandvine.com 765 Juho Snellman 766 Sandvine 767 Seestrasse 5 768 Zurich 8002 769 Switzerland 771 Email: jsnellman@sandvine.com 773 Mohamed Boucadair 774 Orange 775 4 rue du Clos Courtel 776 Rennes 35000 777 France 779 Email: mohamed.boucadair@orange.com 781 Christian Jacquenet 782 Orange 783 4 rue du Clos Courtel 784 Rennes 35000 785 France 787 Email: christian.jacquenet@orange.com