| Network Working Group | D. Dolson, Ed. |
| Internet-Draft | |
| Intended status: Informational | J. Snellman |
| Expires: June 9, 2019 | |
| M. Boucadair, Ed. | |
| C. Jacquenet | |
| Orange | |
| December 06, 2018 |
An Inventory of Transport-centric Functions Provided by Middleboxes: An Operator Perspective
draft-dolson-transport-middlebox-05
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".
RFC3234 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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2019.
Copyright (c) 2018 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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; e.g.,:
For the purposes of this document (and consistent with the RFC3234 definition), 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 [I-D.trammell-plus-statefulness].
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.
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.
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 protect 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 [I-D.ietf-sfc-use-case-mobility].
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 customer's 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 must support a plethora of services with different QoS, security, robustness, etc. requirements.
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. An earlier document [RFC8404] describes the impact of pervasive encryption of application-layer data on network monitoring, protecting, and troubleshooting.
This 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.
This document takes an operator perspective that measurement and management of transport connections is of benefit to both parties: for the end-user to receive better quality of experience, and for the network operator to improve 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.
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 as monitoring systems that compute performance indicators for single or aggregates of connections and generate aggregated reports from them, and 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.
It is very useful for an operator to be able to detect and isolate packet loss in a network.
Network problems and under-provisioning can be detected if packet loss is measurable. TCP packet loss can be detected by observing gaps in sequence numbers, retransmitted sequence numbers, and SACK options. 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. Selective acknowledgements (SACKs, [RFC2018]) can be used to detect either upstream or downstream packet loss (although some care needs to be taken to avoid mis-identifying packet reordering as packet loss), and to distinguish between upstream vs. downstream losses.
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, since packet losses are one of the two main ways for congestion to manifest (the others being queueing delay or Explicit Congestion Notification (ECN, [RFC3168])), packet loss is an important measurement for any middlebox that needs to make traffic handling decisions based on observed levels of congestion.
The ability to measure partial-path round-trip times 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 end-point, which can only observe full round-trip times.
For example, a TCP packet stream can be used to measure the round-trip time 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 Round-Trip Time (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 queueing, 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 vs. the ACKs being queued.
If a network is reordering packets of transport connections, caused perhaps by Equal-cost multi-path (ECMP) misconfiguration (e.g., described in [RFC2991] and [RFC7690]), the end-points 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.
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].
Although throughput to or from an IP address can be measured without transport-layer measurements, the transport layer provides clues about what the end-points 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 network's speed, and can be discounted or completely excluded in such analyses.
Congestion control mechanisms continue to evolve. Tools exist that can interpret protocol sequence numbers (e.g., from TCP, 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, analysing packet sequence numbers can be used to help understand whether an application flow backs-off its load in the face of persistent congestion (as TCP does), and hence to understand whether the behaviour 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]).
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:
Two trends in protocol design will make attack detection more difficult:
While improving privacy, those approaches may hinder attack detection.
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.
Network health may also be gleaned from application-layer diagnosis. E.g.,
Could this type of information be provided in a transport layer?
This section describes features provided by on-path devices that go beyond measurement by modifying, discarding, delaying, or prioritizing traffic.
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 AFTR, NAT64, 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 multi-homing considerations, IPv6 prefix translation may be enabled by some enterprises by means of NPTv6.
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.
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.
In the context of a DDoS attack, the purpose of a scrubber is to discard attack traffic while permitting useful traffic. E.g., such a mitigator is described in [I-D.ietf-dots-architecture].
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 end-point 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.
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 transport-layer state machine.
Middleboxes may also scrub on the basis of statistical classification: testing how likely a given packet is legitimate. As protocol designers add more entropy to headers and lengths, this test becomes less useful and the best scrubbing strategy becomes random drop.
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.
Performance-Enhancing Proxies (PEPs) can improve performance in some types of networks by improving packet spacing or generating local acknowledgements, and 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 use of 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 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 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.
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. 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 for more network coding in some specific networks is discussed in [I-D.irtf-nwcrg-network-coding-satellites].
Note: This is not to be confused with transcoding, which performs lossy compression on transmitted media streams, and not in scope for this document.
The Hybrid Access Aggregation Point is a middlebox that allows customers to aggregate the bandwidth of multiple access technologies.
One of the approaches uses MPTCP proxies 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 while 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 multi-path 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 [I-D.ietf-tcpm-converters].
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:
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 connections. E.g., 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.
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 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 sub-optimally dropping packets).
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 to be unfairly exhausted.
This memo includes no request to IANA.
This document intentionally excludes middleboxes that observe or manipulate application-layer data.
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:
Being able to observe sequence numbers or session identifiers by an on-path attacker may make it easier to modify or terminate a transport connection. E.g., 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.
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 will improve security (e.g., by means of DOTS signalling [I-D.ietf-dots-signal-channel]).
The authors thank Brian Trammell, Brian Carpenter, Mirja Kuehlewind, Kathleen Moriarty, Gorry Fairhurst, Adrian Farrel, and Nicolas Kuhn for their review and suggestions.