Re: On the passive measurability of QUIC

[Gorry Fairhurst <[e-mail]>]

See my little postscript at the end.

On 06/06/2017 10:19, Mike Bishop wrote:
> Regarding the billing question….  For mobile devices, I believe the 
> major OSes support pushing policies to the clients that 
> differently-billed traffic should be sent over a different APN.  We’re 
> doing work in RS3 to enable more apps to hook into these policies and 
> have their traffic correctly routed to the right APN.  (In previous 
> versions, it was implemented in our HTTP stack and required extra work 
> if you were using your own stack.) This might just be a problem that 
> gets solved at a different layer, rather than via traffic inspection, 
> and not something we need to cater to in QUIC (or TLS).
> 
> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Spencer 
> Dawkins at IETF
> *Sent:* Tuesday, June 6, 2017 6:33 AM
> *To:* Brian Trammell <[e-mail]>
> *Cc:* Eric Rescorla <[e-mail]>; IETF QUIC WG <[e-mail]>
> *Subject:* Re: On the passive measurability of QUIC
> 
> So a couple of things, while wearing a couple of hats.
> 
> On Jun 1, 2017 10:07, "Brian Trammell (IETF)" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     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.
> 
> As AD: this thread, like the spoofing thread, is the type of discussion 
> on the management deliverable I was hoping the working group would have, 
> when I agreed to approve the QUIC charter. Thank you.
> 
> I know this conversation isn't easy, and so does the rest of the IESG, 
> and so does the IAB. We had high level discussions in this space on the 
> joint IAB-IESG day of our retreat a couple of weeks ago, and the ADs 
> continued that discussion during both days of the IESG retreat.
> 
>     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
>     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissues%2F166&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C88ec89b10e6644f53c1908d4ac952076%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636323203891635662&sdata=NzTkpTK%2FUwRJx695JPDH4WY6C7%2FEY0ikKVz2OD5Sd6Q%3D&reserved=0>.
>     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.
> 
> As a possibly helpful individual, this list seems to include implicitly 
> what Erik mentioned explicitly in the spoofing thread - thinking about 
> what trusts what, and what controls what. I thought that explictness 
> would be helpful.
> 
>     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.
> 
> As AD: this would be an especially useful assertion to converge on 
> (after the interim, of course).
> 
> If QUIC isn't able to help with billing(*), that needs to not be a Late 
> Surprise (tm).
> 
> Spencer
> 
> (*) Back to speaking as an individual, one of the responses that would 
> not surprise me is "applications using QUIC aren't much harder to bill 
> for than applications using TLS or TCPINC, so, whatever you do for 
> those, do it for QUIC". If something like that turns out to be the 
> answer, people who care about billing need to be figuring out what Plan 
> B is ...
> 
>      > -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
> 

I wrote this draft also:
https://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-transport-encrypt-01.txt

- It's not so much about middleboxes that change things, as about boxes 
that look at things. Some of this may be relevant to this thread. It's 
not specifically about QUIC, but I suspect that was what I had partly in 
mind as I tried to understand the implications of encrypting teh cntrol 
information.

Gorry