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