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