diff options
Diffstat (limited to 'doc/rfc/rfc8517.txt')
| -rw-r--r-- | doc/rfc/rfc8517.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc8517.txt b/doc/rfc/rfc8517.txt new file mode 100644 index 0000000..9172116 --- /dev/null +++ b/doc/rfc/rfc8517.txt @@ -0,0 +1,1179 @@ + + + + + + +Independent Submission D. Dolson, Ed. +Request for Comments: 8517 +Category: Informational J. Snellman +ISSN: 2070-1721 + M. Boucadair, Ed. + C. Jacquenet + Orange + February 2019 + + + An Inventory of Transport-Centric Functions Provided by Middleboxes: + An Operator Perspective + +Abstract + + This document summarizes an operator's perception of the benefits + that may be provided by intermediary devices that execute functions + beyond normal IP forwarding. Such intermediary devices are often + called "middleboxes". + + RFC 3234 defines a taxonomy of middleboxes and issues in the + Internet. Most of those middleboxes utilize or modify application- + layer data. This document primarily focuses on devices that observe + and act on information carried in the transport layer, and especially + information carried in TCP packets. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This is a contribution to the RFC Series, independently of any other + RFC stream. The RFC Editor has chosen to publish this document at + its discretion and makes no statement about its value for + implementation or deployment. Documents approved for publication by + the RFC Editor are not candidates for any level of Internet Standard; + see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8517. + + + + + + + + + + +Dolson, et al. Informational [Page 1] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +Copyright Notice + + Copyright (c) 2019 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Operator Perspective . . . . . . . . . . . . . . . . . . 3 + 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Measurements . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 6 + 2.3. Measuring Packet Reordering . . . . . . . . . . . . . . . 6 + 2.4. Throughput and Bottleneck Identification . . . . . . . . 7 + 2.5. Congestion Responsiveness . . . . . . . . . . . . . . . . 7 + 2.6. Attack Detection . . . . . . . . . . . . . . . . . . . . 8 + 2.7. Packet Corruption . . . . . . . . . . . . . . . . . . . . 8 + 2.8. Application-Layer Measurements . . . . . . . . . . . . . 9 + 3. Functions beyond Measurement: A Few Examples . . . . . . . . 9 + 3.1. NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.2. Firewall . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.3. DDoS Scrubbing . . . . . . . . . . . . . . . . . . . . . 10 + 3.4. Implicit Identification . . . . . . . . . . . . . . . . . 11 + 3.5. Performance-Enhancing Proxies . . . . . . . . . . . . . . 11 + 3.6. Network Coding . . . . . . . . . . . . . . . . . . . . . 12 + 3.7. Network-Assisted Bandwidth Aggregation . . . . . . . . . 13 + 3.8. Prioritization and Differentiated Services . . . . . . . 13 + 3.9. Measurement-Based Shaping . . . . . . . . . . . . . . . . 14 + 3.10. Fairness to End-User Quota . . . . . . . . . . . . . . . 14 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 5.1. Confidentiality and Privacy . . . . . . . . . . . . . . . 14 + 5.2. Active On-Path Attacks . . . . . . . . . . . . . . . . . 15 + 5.3. Improved Security . . . . . . . . . . . . . . . . . . . . 15 + 6. Informative References . . . . . . . . . . . . . . . . . . . 16 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + + + + + + +Dolson, et al. Informational [Page 2] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +1. Introduction + + From [RFC3234], "A middlebox is defined as any intermediary device + performing functions other than the normal, standard functions of an + IP router on the datagram path between a source host and destination + host." + + Middleboxes are usually (but not exclusively) deployed at locations + permitting observation of bidirectional traffic flows. Such + locations are typically points where leaf networks connect to the + Internet, for example: + + o Where a residential or business customer connects to its service + provider(s), which may include multihoming; + + o On the Gi interface where a Gateway General Packet Radio Service + (GPRS) Support Node (GGSN) connects to a Packet Data Network (PDN) + (Section 3.1 of [RFC6459]). + + For the purposes of this document (and to be consistent with the + definition in RFC 3234), middlebox functions may be found in routers + and switches in addition to dedicated devices. + + This document itemizes a variety of features provided by middleboxes + and by ad hoc analysis performed by operators using packet analyzers. + + Many of the techniques described in this document require stateful + analysis of transport streams. A generic state machine is described + in [PATH-STATE]. + + This document summarizes an operator's perception of the benefits + that may be provided by middleboxes. A primary goal is to provide + information to the Internet community to aid understanding of what + might be gained or lost by decisions that may affect (or be affected + by) middlebox operation in the design of new transport protocols. + See Section 1.1 for more details. + +1.1. Operator Perspective + + Network operators are often the ones first called upon when + applications fail to function properly, often with user reports about + application behaviors (not about packet behaviors). Therefore, it + isn't surprising that operators (wanting to be helpful) desire some + visibility into flow information to identify how well the problem + flows are progressing and how well other flows are progressing. + + + + + + +Dolson, et al. Informational [Page 3] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + Advanced service functions (e.g., Network Address Translators (NATs), + firewalls, etc.) [RFC7498] are widely used to achieve various + objectives such as IP address sharing, firewalling, avoiding covert + channels, detecting and protecting against ever-increasing + Distributed Denial of Service (DDoS) attacks, etc. For example, + environment-specific designs may require a number of service + functions, such as those needed at the Gi interface of a mobile + infrastructure [USE-CASE]. + + These sophisticated service functions are located in the network but + also in service platforms or intermediate entities (e.g., Content + Delivery Networks (CDNs)). Network maintenance and diagnostic + operations are complicated, particularly when responsibility is + shared among various players. + + Network Providers are challenged to deliver differentiated services + as a competitive business advantage while mastering the complexity of + the applications, (continuously) evaluating the impacts on + middleboxes, and enhancing customers' quality of experience. + + Despite the complexity, removing all those service functions is not + an option because they are used to address constraints that are often + typical of the current (and changing) Internet. Operators must deal + with constraints such as global IPv4 address depletion and support a + plethora of services with different requirements for QoS, security, + robustness, etc. + +1.2. Scope + + Although many middleboxes observe and manipulate application-layer + content (e.g., session boarder controllers [RFC5853]), they are out + of scope for this document, the aim being to describe middleboxes + using transport-layer features. [RFC8404] describes the impact of + pervasive encryption of application-layer data on network monitoring, + protecting, and troubleshooting. + + The current document is not intended to recommend (or prohibit) + middlebox deployment. Many operators have found the value provided + by middleboxes to outweigh the added cost and complexity; this + document attempts to provide that perspective as a reference in + discussion of protocol design trade-offs. + + This document is not intended to discuss issues related to + middleboxes. These issues are well known and are recorded in + existing documents such as [RFC3234] and [RFC6269]. This document + aims to elaborate on the motivations leading operators to enable such + functions in spite of complications. + + + + +Dolson, et al. Informational [Page 4] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + This document takes an operator perspective that measurement and + management of transport connections is of benefit to both parties: + the end user receives a better quality of experience, and the network + operator improves resource usage, the former being a consequence of + the latter. + + This document does not discuss whether exposing some data to on-path + devices for network-assistance purposes can be achieved by using + in-band or out-of-band mechanisms. + +2. Measurements + + A number of measurements can be made by network devices that are + either on-path or off-path. These measurements can be used either by + automated systems or for manual network troubleshooting purposes + (e.g., using packet-analysis tools). The automated systems can + further be classified into two types: 1) monitoring systems that + compute performance indicators for single connections or aggregates + of connections and generate aggregated reports from them; and 2) + active systems that make decisions also on how to handle packet flows + based on these performance indicators. + + Long-term trends in these measurements can aid an operator in + capacity planning. + + Short-term anomalies revealed by these measurements can identify + network breakages, attacks in progress, or misbehaving devices/ + applications. + +2.1. Packet Loss + + It is very useful for an operator to be able to detect and isolate + packet loss in a network. + + Network problems and underprovisioning can be detected if packet loss + is measurable. TCP packet loss can be detected by observing gaps in + sequence numbers, retransmitted sequence numbers, and selective + acknowledgement (SACK) options [RFC2018]. Packet loss can be + detected per direction. + + Gaps indicate loss upstream of the traffic observation point; + retransmissions indicate loss downstream of the traffic observation + point. SACKs can be used to detect either upstream or downstream + packet loss (although some care needs to be taken to avoid + misidentifying packet reordering as packet loss) and to distinguish + between upstream versus downstream losses. + + + + + +Dolson, et al. Informational [Page 5] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + Packet-loss measurements on both sides of the measurement point are + an important component in precisely diagnosing insufficiently + dimensioned devices or links in networks. Additionally, packet + losses are one of the two main ways for congestion to manifest, the + others being queuing delay or Explicit Congestion Notification (ECN) + [RFC3168]; therefore, packet loss is an important measurement for any + middlebox that needs to make traffic handling decisions based on + observed levels of congestion. + +2.2. Round-Trip Times + + The ability to measure partial-path round-trip times (RTTs) is + valuable in diagnosing network issues (e.g., abnormal latency, + abnormal packet loss). Knowing if latency is poor on one side of the + observation point or the other provides more information than is + available at either endpoint, which can only observe full RTTs. + + For example, a TCP packet stream can be used to measure the RTT on + each side of the measurement point. During the connection handshake, + the SYN, SYN/ACK, and ACK timings can be used to establish a baseline + RTT in each direction. Once the connection is established, the RTT + between the server and the measurement point can only reliably be + determined using TCP timestamps [RFC7323]. On the side between the + measurement point and the client, the exact timing of data segments + and ACKs can be used as an alternative. For this latter method to be + accurate when packet loss is present, the connection must use + selective acknowledgements. + + In many networks, congestion will show up as increasing packet + queuing, and congestion-induced packet loss will only happen in + extreme cases. RTTs will also show up as a much smoother signal than + the discrete packet-loss events. This makes RTTs a good way to + identify individual subscribers for whom the network is a bottleneck + at a given time or geographical sites (such as cellular towers) that + are experiencing large-scale congestion. + + The main limit of RTT measurement as a congestion signal is the + difficulty of reliably distinguishing between the data segments being + queued versus the ACKs being queued. + +2.3. Measuring Packet Reordering + + If a network is reordering packets of transport connections, caused + perhaps by Equal-Cost Multipath (ECMP) misconfiguration (described in + [RFC2991] and [RFC7690], for example), the endpoints may react as if + packet loss is occurring and retransmit packets or reduce forwarding + rates. Therefore, a network operator desires the ability to diagnose + packet reordering. + + + +Dolson, et al. Informational [Page 6] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + For TCP, packet reordering can be detected by observing TCP sequence + numbers per direction. See, for example, a number of standard + packet-reordering metrics in [RFC4737] and informational metrics in + [RFC5236]. + +2.4. Throughput and Bottleneck Identification + + Although throughput to or from an IP address can be measured without + transport-layer measurements, the transport layer provides clues + about what the endpoints were attempting to do. + + One way of quickly excluding the network as the bottleneck during + troubleshooting is to check whether the speed is limited by the + endpoints. For example, the connection speed might instead be + limited by suboptimal TCP options, the sender's congestion window, + the sender temporarily running out of data to send, the sender + waiting for the receiver to send another request, or the receiver + closing the receive window. + + This data is also useful for middleboxes used to measure network + quality of service. Connections, or portions of connections, that + are limited by the endpoints do not provide an accurate measure of + the network's speed and can be discounted or completely excluded in + such analyses. + +2.5. Congestion Responsiveness + + Congestion control mechanisms continue to evolve. Tools exist that + can interpret protocol sequence numbers (e.g., from TCP or RTP) to + infer the congestion response of a flow. Such tools can be used by + operators to help understand the impact of specific transport + protocols on other traffic that shares their network. For example, + packet sequence numbers can be analyzed to help understand whether an + application flow backs off its load in the face of persistent + congestion (as TCP does) and, hence, whether the behavior is + appropriate for sharing limited network capacity. + + These tools can also be used to determine whether mechanisms are + needed in the network to prevent flows from acquiring excessive + network capacity under severe congestion (e.g., by deploying rate + limiters or network transport circuit breakers [RFC8084]). + + + + + + + + + + +Dolson, et al. Informational [Page 7] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +2.6. Attack Detection + + When an application or network resource is under attack, it is useful + to identify this situation from the network perspective, upstream of + the attacked resource. + + Although detection methods tend to be proprietary, attack detection + from within the network may comprise: + + o Identifying uncharacteristic traffic volumes or sources; + + o Identifying congestion, possibly using techniques in Sections 2.1 + and 2.2; + + o Identifying incomplete connections or transactions, from attacks + that attempt to exhaust server resources; + + o Fingerprinting based on whatever available fields are determined + to be useful in discriminating an attack from desirable traffic. + + Two trends in protocol design will make attack detection more + difficult: + + o The desire to encrypt transport-layer fields; + + o The desire to avoid statistical fingerprinting by adding entropy + in various forms. + + While improving privacy, those approaches may hinder attack + detection. + +2.7. Packet Corruption + + One notable source of packet loss is packet corruption. This + corruption will generally not be detected until the checksums are + validated by the endpoint and the packet is dropped. This means that + detecting the exact location where packets are lost is not sufficient + when troubleshooting networks. An operator would like to find out + where packets are being corrupted. IP and TCP checksum verification + allows a measurement device to correctly distinguish between upstream + packet corruption and normal downstream packet loss. + + Transport protocol designers should consider whether a middlebox will + be able to detect corrupted or tampered packets. + + + + + + + +Dolson, et al. Informational [Page 8] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +2.8. Application-Layer Measurements + + Information about network health may also be gleaned from + application-layer diagnosis, such as: + + o DNS response times and retransmissions calculated by correlating + answers to queries; + + o Various protocol-aware voice and video quality analyses. + + Could this type of information be provided in a transport layer? + +3. Functions beyond Measurement: A Few Examples + + This section describes features provided by on-path devices that go + beyond measurement by modifying, discarding, delaying, or + prioritizing traffic. + +3.1. NAT + + Network Address Translators (NATs) allow multiple devices to share a + public address by dividing the transport-layer port space among the + devices. + + NAT behavior recommendations are found for UDP in BCP 127 [RFC4787] + and for TCP in BCP 142 [RFC7857]. + + To support NAT, there must be transport-layer port numbers that can + be modified by the NAT. Note that required fields (e.g., port + numbers) are visible in all IETF-defined transport protocols. + + The application layer must not assume the port number was left + unchanged (e.g., by including it in a checksum or signing it). + + Address sharing is also used in the context of IPv6 transition. For + example, DS-Lite Address Family Transition Router (AFTR) [RFC6333], + NAT64 [RFC6146], or A+P [RFC7596][RFC7597] are features that are + enabled in the network to allow for IPv4 service continuity over an + IPv6 network. + + Further, because of some multihoming considerations, IPv6 prefix + translation may be enabled by some enterprises by means of IPv6-to- + IPv6 Network Prefix Translation (NPTv6) [RFC6296]. + + + + + + + + +Dolson, et al. Informational [Page 9] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +3.2. Firewall + + Firewalls are pervasive and essential components that inspect + incoming and outgoing traffic. Firewalls are usually the cornerstone + of a security policy that is enforced in end-user premises and other + locations to provide strict guarantees about traffic that may be + authorized to enter/leave the said premises, as well as end users who + may be assigned different clearance levels regarding which networks + and portions of the Internet they access. + + An important aspect of a firewall policy is differentiating + internally initiated from externally initiated communications. + + For TCP, this is easily done by tracking the TCP state machine. + Furthermore, the ending of a TCP connection is indicated by RST or + FIN flags. + + For UDP, the firewall can be opened if the first packet comes from + an internal user, but the closing is generally done by an idle + timer of arbitrary duration, which might not match the + expectations of the application. + + Simple IPv6 firewall capabilities for customer premises equipment + (both stateless and stateful) are described in [RFC6092]. + + A firewall functions better when it can observe the protocol state + machine, described generally by "Transport-Independent Path Layer + State Management" [PATH-STATE]. + +3.3. DDoS Scrubbing + + In the context of a DDoS attack, the purpose of a scrubber is to + discard attack traffic while permitting useful traffic. Such a + mitigator is described in [DOTS]. + + When attacks occur against constrained resources, some traffic will + be discarded before reaching the intended destination. A user + receives better experience and a server runs more efficiently if a + scrubber can discard attack traffic, leaving room for legitimate + traffic. + + Scrubbing must be provided by an on-path network device, because + neither endpoint of a legitimate connection has any control over the + source of the attack traffic. + + Source-spoofed DDoS attacks can be mitigated at the source using BCP + 38 [RFC2827], but it is more difficult if source address filtering + cannot be applied. + + + +Dolson, et al. Informational [Page 10] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + In contrast to devices in the core of the Internet, middleboxes + statefully observing bidirectional transport connections can reject + source-spoofed TCP traffic based on the inability to provide sensible + acknowledgement numbers to complete the three-way handshake. + Obviously, this requires middlebox visibility into a transport-layer + state machine. + + Middleboxes may also scrub on the basis of statistical + classification: testing how likely a given packet is to be + legitimate. As protocol designers add more entropy to headers and + lengths, this test becomes less useful, and the best scrubbing + strategy becomes random drop. + +3.4. Implicit Identification + + In order to enhance the end user's quality of experience, some + operators deploy implicit identification features that rely upon the + correlation of network-related information to access some local + services. For example, service portals operated by some operators + may be accessed immediately by end users without any explicit + identification for the sake of improved service availability. This + is doable thanks to on-path devices that inject appropriate metadata + that can be used by the remote server to enforce per-subscriber + policies. The information can be injected at the application layer + or at the transport layer (when an address-sharing mechanism is in + use). + + An experimental implementation using a TCP option is described in + [RFC7974]. + + For the intended use of implicit identification, it is more secure to + have a trusted middlebox mark this traffic than to trust end-user + devices. + +3.5. Performance-Enhancing Proxies + + Performance-Enhancing Proxies (PEPs) can improve performance in some + types of networks by improving packet spacing or generating local + acknowledgements; they are most commonly used in satellite and + cellular networks. Transport-Layer PEPs are described in + Section 2.1.1 of [RFC3135]. + + PEPs allow central deployment of congestion control algorithms more + suited to the specific network, most commonly for delay-based + congestion control. More advanced TCP PEPs deploy congestion control + systems that treat all of a single end user's TCP connections as a + single unit, improving fairness and allowing faster reaction to + + + + +Dolson, et al. Informational [Page 11] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + changing network conditions. For example, it was reported that + splitting the TCP connections in some network accesses can result in + a halved page downloading time [ICCRG]. + + Local acknowledgements generated by PEPs speed up TCP slow start by + splitting the effective latency, and they allow for retransmissions + to be done from the PEP rather than from the actual sender. Local + acknowledgements will also allow a PEP to maintain a local buffer of + data appropriate to the actual network conditions, whereas the actual + endpoints would often send too much or too little. + + A PEP function requires transport-layer fields that allow chunks of + data to be identified (e.g., TCP sequence numbers), acknowledgements + to be identified (e.g., TCP ACK numbers), and acknowledgements to be + created from the PEP. + + Note that PEPs are only useful in some types of networks. In + particular, PEPs are very useful in contexts wherein the congestion + control strategies of the endpoints are inappropriate for the network + connecting them. That being said, poor design can result in degraded + performances when PEPs are deployed. + +3.6. Network Coding + + Network Coding is a technique for improving transmission performance + over low-bandwidth, long-latency links such as some satellite links. + Coding may involve lossless compression and/or adding redundancy to + headers and payload. A Network Coding Taxonomy is provided by + [RFC8406]; an example of end-to-end coding is FECFRAME [RFC6363]. It + is typically deployed with network-coding gateways at each end of + those links, with a network-coding tunnel between them via the + slow/lossy/long-latency links. + + Network-coding implementations may be specific to TCP, taking + advantage of known properties of the protocol. + + The network-coding gateways may employ some techniques of PEPs, such + as creating acknowledgements of queued data, removing + retransmissions, and pacing data rates to reduce queue oscillation. + + The interest in more network coding in some specific networks is + discussed in [SATELLITES]. + + Note: This is not to be confused with transcoding, which performs + lossy compression on transmitted media streams and is not in scope + for this document. + + + + + +Dolson, et al. Informational [Page 12] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +3.7. Network-Assisted Bandwidth Aggregation + + The Hybrid Access Aggregation Point is a middlebox that allows + customers to aggregate the bandwidth of multiple access technologies. + + One of the approaches uses Multipath TCP (MPTCP) proxies + [TCP-CONVERT] to forward traffic along multiple paths. The MPTCP + proxy operates at the transport layer while being located in the + operator's network. + + The support of multipath transport capabilities by communicating + hosts remains a privileged target design so that such hosts can + directly use the available resources provided by a variety of access + networks they can connect to. Nevertheless, network operators do not + control end hosts, whereas the support of MPTCP by content servers + remains marginal. + + Network-assisted MPTCP deployment models are designed to facilitate + the adoption of MPTCP for the establishment of multipath + communications without making any assumption about the support of + MPTCP capabilities by communicating peers. Network-assisted MPTCP + deployment models rely upon MPTCP Conversion Points (MCPs) that act + on behalf of hosts so that they can take advantage of establishing + communications over multiple paths [TCP-CONVERT]. + + Note there are cases when end-to-end MPTCP cannot be used even though + both client and server are MPTCP-compliant. An MPTCP proxy can + provide multipath utilization in these cases. Examples of such cases + are listed below: + + 1. The use of private IPv4 addresses in some access networks. + Typically, additional subflows cannot be added to the MPTCP + connection without the help of an MCP. + + 2. The assignment of IPv6 prefixes only by some networks. If the + server is IPv4-only, IPv6 subflows cannot be added to an MPTCP + connection established with that server, by definition. + + 3. Subscription to some service offerings is subject to volume + quota. + +3.8. Prioritization and Differentiated Services + + Bulk traffic may be served with a higher latency than interactive + traffic with no reduction in throughput. This fact allows a + middlebox function to improve response times in interactive + applications by prioritizing, policing, or remarking interactive + transport connections differently from bulk-traffic transport + + + +Dolson, et al. Informational [Page 13] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + connections. For example, gaming traffic may be prioritized over + email or software updates. Configuration guidelines for Diffserv + service classes are discussed in [RFC4594]. + + Middleboxes may identify different classes of traffic by inspecting + multiple layers of header and length of payload. + +3.9. Measurement-Based Shaping + + Basic traffic-shaping functionality requires no transport-layer + information. All that is needed is a way of mapping each packet to a + traffic shaper quota. For example, there may be a rate limit per + 5-tuple or per subscriber IP address. However, such fixed traffic + shaping rules are wasteful as they end up rate-limiting traffic even + when the network has free resources available. + + More advanced traffic-shaping devices use transport-layer metrics + described in Section 2 to detect congestion on either a per-site or a + per-user level and use different traffic-shaping rules when + congestion is detected [RFC3272]. This type of device can overcome + limitations of downstream devices that behave poorly (e.g., by + excessive buffering or suboptimally dropping packets). + +3.10. Fairness to End-User Quota + + Several service offerings rely upon a volume-based charging model + (e.g., volume-based data plans offered by cellular providers). + Operators may assist end users in conserving their data quota by + deploying on-path functions that shape traffic that would otherwise + be aggressively transferred. + + For example, a fast download of a video that won't be viewed + completely by the subscriber may lead to quick exhaustion of the data + quota. Limiting the video download rate conserves quota for the + benefit of the end user. Also, discarding unsolicited incoming + traffic prevents the user's quota from being unfairly exhausted. + +4. IANA Considerations + + This document has no IANA actions. + +5. Security Considerations + +5.1. Confidentiality and Privacy + + This document intentionally excludes middleboxes that observe or + manipulate application-layer data. + + + + +Dolson, et al. Informational [Page 14] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + The measurements and functions described in this document can all be + implemented without violating confidentiality [RFC6973]. However, + there is always the question of whether the fields and packet + properties used to achieve operational benefits may also be used for + harm. + + In particular, the question is what confidentiality is lost by + exposing transport-layer fields beyond what can be learned by + observing IP-layer fields: + + o Sequence numbers: an observer can learn how much data is + transferred. + + o Start/Stop indicators: an observer can count transactions for some + applications. + + o Device fingerprinting: an observer may be more easily able to + identify a device type when different devices use different + default field values or options. + +5.2. Active On-Path Attacks + + An on-path attacker being able to observe sequence numbers or session + identifiers may make it easier to modify or terminate a transport + connection. For example, observing TCP sequence numbers allows + generation of a RST packet that terminates the connection. However, + signing transport fields softens this attack. The attack and + solution are described for the TCP authentication option [RFC5925]. + Still, an on-path attacker can also drop the traffic flow. + +5.3. Improved Security + + Network maintainability and security can be improved by providing + firewalls and DDoS mechanisms with some information about transport + connections. In contrast, it would be very difficult to secure a + network in which every packet appears unique and filled with random + bits (from the perspective of an on-path device). + + Some features providing the ability to mitigate/filter attacks owing + to a network-assisted mechanism will therefore improve security -- + e.g., by means of Distributed-Denial-of-Service Open Threat Signaling + (DOTS) [DOTS-SIGNAL]. + + + + + + + + + +Dolson, et al. Informational [Page 15] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +6. Informative References + + [DOTS] Mortensen, A., Andreasen, F., Reddy, T., Compton, R., and + N. Teague, "Distributed-Denial-of-Service Open Threat + Signaling (DOTS) Architecture", Work in Progress, + draft-ietf-dots-architecture-07, September 2018. + + [DOTS-SIGNAL] + Reddy, T., Boucadair, M., Patil, P., Mortensen, A., and N. + Teague, "Distributed Denial-of-Service Open Threat + Signaling (DOTS) Signal Channel Specification", Work in + Progress, draft-ietf-dots-signal-channel-25, September + 2018. + + [ICCRG] Kuhn, N., "MPTCP and BBR performance over Internet + satellite paths", IETF 100, 2017, + <https://datatracker.ietf.org/meeting/100/materials/ + slides-100-iccrg-mptcp-and-bbr-performance-over-satcom- + links-00>. + + [PATH-STATE] + Kuehlewind, M., Trammell, B., and J. Hildebrand, + "Transport-Independent Path Layer State Management", Work + in Progress, draft-trammell-plus-statefulness-04, November + 2017. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, + DOI 10.17487/RFC2018, October 1996, + <https://www.rfc-editor.org/info/rfc2018>. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, + May 2000, <https://www.rfc-editor.org/info/rfc2827>. + + [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and + Multicast Next-Hop Selection", RFC 2991, + DOI 10.17487/RFC2991, November 2000, + <https://www.rfc-editor.org/info/rfc2991>. + + [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and + Z. Shelby, "Performance Enhancing Proxies Intended to + Mitigate Link-Related Degradations", RFC 3135, + DOI 10.17487/RFC3135, June 2001, + <https://www.rfc-editor.org/info/rfc3135>. + + + + + +Dolson, et al. Informational [Page 16] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, DOI 10.17487/RFC3168, September 2001, + <https://www.rfc-editor.org/info/rfc3168>. + + [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and + Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, + <https://www.rfc-editor.org/info/rfc3234>. + + [RFC3272] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and + X. Xiao, "Overview and Principles of Internet Traffic + Engineering", RFC 3272, DOI 10.17487/RFC3272, May 2002, + <https://www.rfc-editor.org/info/rfc3272>. + + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + DOI 10.17487/RFC4594, August 2006, + <https://www.rfc-editor.org/info/rfc4594>. + + [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, + S., and J. Perser, "Packet Reordering Metrics", RFC 4737, + DOI 10.17487/RFC4737, November 2006, + <https://www.rfc-editor.org/info/rfc4737>. + + [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for Unicast + UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January + 2007, <https://www.rfc-editor.org/info/rfc4787>. + + [RFC5236] Jayasumana, A., Piratla, N., Banka, T., Bare, A., and + R. Whitner, "Improved Packet Reordering Metrics", + RFC 5236, DOI 10.17487/RFC5236, June 2008, + <https://www.rfc-editor.org/info/rfc5236>. + + [RFC5853] Hautakorpi, J., Ed., Camarillo, G., Penfield, R., + Hawrylyshen, A., and M. Bhatia, "Requirements from Session + Initiation Protocol (SIP) Session Border Control (SBC) + Deployments", RFC 5853, DOI 10.17487/RFC5853, April 2010, + <https://www.rfc-editor.org/info/rfc5853>. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, <https://www.rfc-editor.org/info/rfc5925>. + + + + + + + + +Dolson, et al. Informational [Page 17] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security + Capabilities in Customer Premises Equipment (CPE) for + Providing Residential IPv6 Internet Service", RFC 6092, + DOI 10.17487/RFC6092, January 2011, + <https://www.rfc-editor.org/info/rfc6092>. + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, + April 2011, <https://www.rfc-editor.org/info/rfc6146>. + + [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and + P. Roberts, "Issues with IP Address Sharing", RFC 6269, + DOI 10.17487/RFC6269, June 2011, + <https://www.rfc-editor.org/info/rfc6269>. + + [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix + Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, + <https://www.rfc-editor.org/info/rfc6296>. + + [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- + Stack Lite Broadband Deployments Following IPv4 + Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, + <https://www.rfc-editor.org/info/rfc6333>. + + [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error + Correction (FEC) Framework", RFC 6363, + DOI 10.17487/RFC6363, October 2011, + <https://www.rfc-editor.org/info/rfc6363>. + + [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, + T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation + Partnership Project (3GPP) Evolved Packet System (EPS)", + RFC 6459, DOI 10.17487/RFC6459, January 2012, + <https://www.rfc-editor.org/info/rfc6459>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <https://www.rfc-editor.org/info/rfc6973>. + + [RFC7323] Borman, D., Braden, B., Jacobson, V., and + R. Scheffenegger, Ed., "TCP Extensions for High + Performance", RFC 7323, DOI 10.17487/RFC7323, September + 2014, <https://www.rfc-editor.org/info/rfc7323>. + + + + + +Dolson, et al. Informational [Page 18] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for + Service Function Chaining", RFC 7498, + DOI 10.17487/RFC7498, April 2015, + <https://www.rfc-editor.org/info/rfc7498>. + + [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and + I. Farrer, "Lightweight 4over6: An Extension to the Dual- + Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, + July 2015, <https://www.rfc-editor.org/info/rfc7596>. + + [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., + Murakami, T., and T. Taylor, Ed., "Mapping of Address and + Port with Encapsulation (MAP-E)", RFC 7597, + DOI 10.17487/RFC7597, July 2015, + <https://www.rfc-editor.org/info/rfc7597>. + + [RFC7690] Byerly, M., Hite, M., and J. Jaeggli, "Close Encounters of + the ICMP Type 2 Kind (Near Misses with ICMPv6 Packet Too + Big (PTB))", RFC 7690, DOI 10.17487/RFC7690, January 2016, + <https://www.rfc-editor.org/info/rfc7690>. + + [RFC7857] Penno, R., Perreault, S., Boucadair, M., Ed., + Sivakumar, S., and K. Naito, "Updates to Network Address + Translation (NAT) Behavioral Requirements", BCP 127, + RFC 7857, DOI 10.17487/RFC7857, April 2016, + <https://www.rfc-editor.org/info/rfc7857>. + + [RFC7974] Williams, B., Boucadair, M., and D. Wing, "An Experimental + TCP Option for Host Identification", RFC 7974, + DOI 10.17487/RFC7974, October 2016, + <https://www.rfc-editor.org/info/rfc7974>. + + [RFC8084] Fairhurst, G., "Network Transport Circuit Breakers", + BCP 208, RFC 8084, DOI 10.17487/RFC8084, March 2017, + <https://www.rfc-editor.org/info/rfc8084>. + + [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of + Pervasive Encryption on Operators", RFC 8404, + DOI 10.17487/RFC8404, July 2018, + <https://www.rfc-editor.org/info/rfc8404>. + + [RFC8406] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek, + F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J., + Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and + S. Sivakumar, "Taxonomy of Coding Techniques for Efficient + Network Communications", RFC 8406, DOI 10.17487/RFC8406, + June 2018, <https://www.rfc-editor.org/info/rfc8406>. + + + + +Dolson, et al. Informational [Page 19] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + + [SATELLITES] + Kuhn, N. and E. Lochin, "Network coding and satellites", + Work in Progress, draft-irtf-nwcrg-network-coding- + satellites-02, November 2018. + + [TCP-CONVERT] + Bonaventure, O., Boucadair, M., Gundavelli, S., and S. + Seo, "0-RTT TCP Convert Protocol", Work in Progress, + draft-ietf-tcpm-converters-04, October 2018. + + [USE-CASE] Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, + "Service Function Chaining Use Cases in Mobile Networks", + Work in Progress, draft-ietf-sfc-use-case-mobility-08, + May 2018. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dolson, et al. Informational [Page 20] + +RFC 8517 Transport-Centric Middlebox Functions February 2019 + + +Acknowledgements + + The authors thank Brian Trammell, Brian Carpenter, Mirja Kuehlewind, + Kathleen Moriarty, Gorry Fairhurst, Adrian Farrel, and Nicolas Kuhn + for their review and suggestions. + +Authors' Addresses + + David Dolson (editor) + + Email: ddolson@acm.org + + + Juho Snellman + + Email: jsnell@iki.fi + + + Mohamed Boucadair (editor) + Orange + 4 rue du Clos Courtel + Rennes 35000 + France + + Email: mohamed.boucadair@orange.com + + + Christian Jacquenet + Orange + 4 rue du Clos Courtel + Rennes 35000 + France + + Email: christian.jacquenet@orange.com + + + + + + + + + + + + + + + + + +Dolson, et al. Informational [Page 21] + |