RE: On the passive measurability of QUIC

[Dave Dolson <[e-mail]>]

And I have just uploaded https://tools.ietf.org/html/draft-dolson-transport-middlebox-00

as an update to what I presented in Chicago, attempting to incorporate feedback from the microphone and email.



Abstract



   This document summarizes benefits that operators perceive to be

   provided by intermediary devices that provide functions apart from

   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.



   A primary goal of this document is to provide information to working

   groups developing new transport protocols, to aid understanding of

   what might be gained or lost by design decisions that may affect (or

   be affected by) middlebox operation.





Table of Contents



   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3

     1.1.  Operator Perspective  . . . . . . . . . . . . . . . . . .   3

     1.2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4

     1.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5

   2.  Measurements  . . . . . . . . . . . . . . . . . . . . . . . .   5

     2.1.  Packet Loss . . . . . . . . . . . . . . . . . . . . . . .   5

     2.2.  Round Trip Times  . . . . . . . . . . . . . . . . . . . .   6

     2.3.  Measuring Packet Reordering . . . . . . . . . . . . . . .   7

     2.4.  Throughput and Bottleneck Identification  . . . . . . . .   7

    2.5.  Congestion Responsiveness . . . . . . . . . . . . . . . .   7

     2.6.  Attack Detection  . . . . . . . . . . . . . . . . . . . .   8

     2.7.  Packet Corruption . . . . . . . . . . . . . . . . . . . .   8

     2.8.  Application-Layer Measurements  . . . . . . . . . . . . .   9

   3.  Functions Beyond Measurement: A Few Examples  . . . . . . . .   9

     3.1.  NAT . . . . . . . . . . . . . . . . . . . . . . . . . . .   9

     3.2.  Firewall  . . . . . . . . . . . . . . . . . . . . . . . .   9

     3.3.  DDoS Scrubbing  . . . . . . . . . . . . . . . . . . . . .  10

     3.4.  Implicit Identification . . . . . . . . . . . . . . . . .  11

     3.5.  Performance-Enhancing Proxies . . . . . . . . . . . . . .  11

     3.6.  Network Coding  . . . . . . . . . . . . . . . . . . . . .  12

     3.7.  Network-Assisted Bandwidth Aggregation  . . . . . . . . .  12

     3.8.  Prioritization and Differentiated Services  . . . . . . .  13

     3.9.  Measurement-Based Shaping . . . . . . . . . . . . . . . .  13

     3.10. Fairness to End-User Quota  . . . . . . . . . . . . . . .  14

   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14

   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14

   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14

     6.1.  Confidentiality . . . . . . . . . . . . . . . . . . . . .  14

     6.2.  Active Attacks  . . . . . . . . . . . . . . . . . . . . .  15

     6.3.  More Information Can Improve Security . . . . . . . . . .  15

   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15

     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  15

     7.2.  Informative References  . . . . . . . . . . . . . . . . .  16

   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19



-Dave







-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Brian Trammell (IETF)
Sent: Thursday, June 1, 2017 11:07 AM
To: Eric Rescorla
Cc: QUIC WG
Subject: Re: On the passive measurability of QUIC



hi ekr,



> On 01 Jun 2017, at 15:55, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:

>

> I like the general framing of these questions, but it's pretty hard to

> address them in the abstract. Rather, I think it would be more useful

> to start not with the specific properties but rather with the

> *services* that collecting these measurements is intended to

> facilitate and then work forward to the various baskets of

> measurements you would need to support said services and from that try to make a cost/benefit analysis [0]. Do you or someone else have such a list of services?



Sure. Here are the ones I know about off the top of my head. Note here, for "services", I understand "higher-level measurement activities", or what would be called "solutions" on the marketing-heavy websites of the vendors who build these boxes. Please correct me if I'm wrong here. "Service" is unfortunately so overloaded a term as to be unclear in many cases, even with context.





1. Access network performance measurement. This is largely the problem the LMAP WG is chartered to address, using IPPM metrics. Here, peak achievable throughput (of an access link), loss, latency, and (sometimes) jitter are the metrics of interest, both in controlled testing (active measurement) as well as passive measurement of user traffic, on the theory both that accidental and intentional differential treatment of measurement traffic will make active measurement unreliable, as well as to reduce network load due to unproductive active measurement traffic. Loss/congestion and latency are the primary passively measurable metrics of interest here. This measurement activity is used by network operators for capacity planning and troubleshooting purposes, as well as by national and supranational regulatory agencies to hold network operators within their jurisdictions accountable. The deployment location changes depending on who's performing the measurements, but it's generally run as close as possible to the access link (for broadband access) or on the handset itself (for mobile measurements).





2. Interdomain troubleshooting of network performance issues. See https://github.com/quicwg/base-drafts/issues/166. Though it proposes a mechanism, it clearly calls out the key metrics as packet loss and congestion, with the ability to localize congestion using multi-observation-point measurement as important.





3. Service performance monitoring (my example here was Boundary, which is apparently called bmc TrueSight Pulse (tm) now) uses passive network-level latency and throughput measurements to augment information collected by agents running on servers themselves to isolate performance issues on those servers.





4. Perimeter security monitoring of access and enterprise networks. Related to work in the DOTS WG, which focuses specifically on the DDoS mitigation aspect of this broad topic. This is largely concerned with detecting and blocking attack traffic. Most of the measurement task in this case is classifying traffic as benign or not, and it uses any input available to make that determination. None of the metrics I talk about in the previous message are really relevant here, though -- spoofed traffic detection is more useful in this context than latency. It's relevant to QUIC, though, in that one of the inputs to this classification is whether traffic is TCP or not: the more likely QUIC traffic is to be classified as default-benign, the better its deployability on networks employing this monitoring.





The obvious one mentioned in our charter, for completeness:



-1. Billing, both for metered consumer-grade access as well as transit contracts. This is -1 because it's not really relevant to transport protocol design, as it generally doesn't require anything beyond byte/packet count per billable user, where the billable user is usually associated with something that happens below layer 3, zero-rating and other such practices notwithstanding.





> -Ekr

>

> [0] Where the cost clearly has to include future unknown privacy risk.



Evaluating an unknown risk is a pretty cool trick. ;)



Seriously, though, I'd really appreciate any suggestions you would have as to how to concretely evaluate this risk, at least for purposes of comparison of proposals. Information theoretic metrics seem to me to be not very useful here, since they make the implicit (and false) assumption that all bits of entropy are equally potentially dangerous to privacy.



Thanks, cheers,



Brian