RE: Middlebox introspection/self-describing packets

[Dave Dolson <[e-mail]>]

   > I've not thought (or know) about all the things that would break if the notion of flow was obliterated from public view.

Can we discuss it in the context of this draft?
https://tools.ietf.org/id/draft-dolson-plus-middlebox-benefits-01.txt

We have been thinking about the things that might break if various transport-layer info is not provided.

Here’s part of the table of contents:


   2.  Measurements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Packet Loss . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Round Trip Times  . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Measuring Packet Reordering . . . . . . . . . . . . . . .   5
     2.4.  Throughput and Bottleneck Identification  . . . . . . . .   5
     2.5.  DDoS Detection  . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Packet Corruption . . . . . . . . . . . . . . . . . . . .   6
     2.7.  Application-Layer Measurements  . . . . . . . . . . . . .   6
   3.  Actions . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  NAT . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Firewall  . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.3.  DDoS Scrubbing  . . . . . . . . . . . . . . . . . . . . .   7
     3.4.  Performance-Enhancing Proxies . . . . . . . . . . . . . .   8
     3.5.  Bandwidth Aggregation . . . . . . . . . . . . . . . . . .   9
     3.6.  Prioritization  . . . . . . . . . . . . . . . . . . . . .   9
     3.7.  Measurement-Based Shaping . . . . . . . . . . . . . . . .   9


-Dave



From: QUIC [mailto:[e-mail]] On Behalf Of Jana Iyengar
Sent: Thursday, March 09, 2017 2:52 PM
To: Eric Rescorla
Cc: Brian Trammell; IETF QUIC WG
Subject: Re: Middlebox introspection/self-describing packets

Why not? It's a connection identifier, like the TCP 4-tuple. What do you gain from middleboxes not using the connection ID to identify connections?

Yeah, I wish they wouldn't use the 4-tuple either. In fact much of this conversation is driven by them doing nonsense based on the 4-tuple.

I understand now. FWIW, the stuff they do, using 4-tuples, includes AQM (see FQ-CoDel)...  some of these things are useful. I'm not saying that's the only way to do it, and I've not thought (or know) about all the things that would break if the notion of flow was obliterated from public view.

If you don't have a bit, you can

- Look up the host/port
- If it's missing assume that there is a connection ID and look for it
- If that's missing, drop the packet

Yes, I was responding to Brian's email -- apologies for crossing the wires a bit. This method is plausible, but it increases the work per packet at load balancers by ~2x.

Not really, because you can check in either order, so unless it's 50/50 you usually get the fast-path.


Actually, no, I'm not persuaded by this as yet. I agree with the statement that NATs kill these bindings
faster, but it's not yet clear to me that connection IDs ameliorate these problems sufficiently to
improve the situation. I'd be happy to see any data you have that supports this point.

I don't follow. I think you're agreeing with what I said above, that NAT rebindings happen faster for UDP.  A QUIC packet post-rebinding for the same connection carries the same connection ID, which leads it back to the same server even if a NAT rebinding happened. Why do you think connection IDs don't ameliorate this problem (of NAT rebindings happen faster for UDP) sufficiently? In other words, what piece of this problem does connection ID not solve?

1. Anything where it's the server speaking first after the rebind.
2. Situations where the server or client would have GCed the state anyway.
I'm looking for data that indicates that the remaining cases are common enough to be
important enough to take the privacy hit. As I said in my response to Ian, I'll try to
figure out a more precise framing of the data that I would find persuasive.

That'd be helpful.


We'd all agree that connection ID use across client network changes is a new beast. To this end, I think we've generally agreed (informally anyways) that the client must use a new connection ID when it triggers connection migration to a different network.

The difficulty is that we do not presently know how to arrange that you always use a new conn id
on migration without using a new conn id on each packet.

That's not true. We can arrange for an active client-driven migration to use a new connection ID. It's the NAT rebinding case that we can't handle without a new connection ID per packet. The reason I separated the connection ID question into NAT rebinding vs client migration was to also separate the privacy considerations for these two cases. While there's a real concern of privacy leakage across active client migrations, privacy leakage due to a stable connection ID across NAT rebindings is not different than that due to a stable TCP connection for the same duration.

There are plenty of times when the client does a network change but doesn't know it
has. Tethering is one example. In such cases, continuing to use the same connection
ID presents a privacy threat.

The tethering case is real, but it's a corner case; connection migrations are dominated by untethered clients.

- jana

-Ekr




On Thu, Mar 9, 2017 at 8:09 AM, Brian Trammell <[e-mail]<mailto:[e-mail]>> wrote:
hi Ekr, all,

> > Well, with negotiation, someone has to decide. The bit just moves that to the client.
> > Except that if the load balancer *needs* it, then the client has to conform.
>
>> The load balancer needs it to balance load efficiently.
>>
> That's not entirely clear. Note that in the original QUIC design, the client supplied
> the connection ID, so the server side merely had to load balance based on some combination
> of a random value and the client's IP.

Right; should have said that "the assertion behind server-suggested Connection ID proposal is that it's needed for efficient load balancing". I'm taking that assertion at face value now, possibly because I'm convinced of the utility of one of its side-effects: providing some additional grade of assurance to a device on path that a given packet was not injected off-path, which is useful in in-network DoS mitigation (as in section 3.3 of the just-submitted manageability draft).

>> I presume that a client that was very interested in not providing tracking information could refuse to make Connection ID available, at the cost of degraded performance.

(I would like to reiterate that I do think that it's necessary to allow clients to veto server-proposed connection ID exposure.)

>> (f that's not the case, if failure to send connection ID leads to connection failure, then "negotiation" is a euphemism: the server informs the client whether it must send a connection ID, probably encrypted, and nobody needs any flags, unless the presence of connection ID changes the offsets of fields we *do* want to explicitly expose, such as packet number echo (https://github.com/quicwg/base-drafts/issues/269) or troubleshooting flags (https://github.com/quicwg/base-drafts/issues/279).
>
> Not to put too fine a point on it, but there's far from consensus that we want to expose
> either of these.

That's not too fine a point at all; I'm not presupposing consensus on either of these. All I'm saying here is, should consensus emerge that the benefits outweigh the costs (both in complexity and in risk) for certain kinds of exposure to the path -- which I think may be the case for some of the things under discussion in 279, and I'm obviously convinced of the utility of packet number echo as in 269 or I wouldn't have submitted two PRs on it -- we need to be clear that other choices we make about the layout of the header doesn't make that harder than it needs to be. Sticking variable-length/optional fields whose presence is dependent on endpoint-shared state after the exposed fields is probably sufficient for this.


Cheers,

Brian