Privacy considerations

[huitema]

@martinthomson has prepared PR #25 to add a "privacy analysis", but I think the discussion of that matter would be better done in an issue than in a PR.

[huitema]

My first step in the analysis would be to check on models of "the system". PR #25 considers a simple client-network-server model, but when it comes to real time communication we may want to also consider peer-network-peer (e.g., a web RTC call after doing ICE, etc.) and peer-network-relay-(relays)-relay-network-peer (the MoQ model). And of course the VPN model: client - VPN - network - server. We may also want to consider what happens in the emerging oblivious model: client to first relay (knows the client, does not know the activity), client to second relay through first relay (knows the activity, does not know the client)

Then I would look at the privacy assets in these model. I think I can list (and maybe exclude) the following: identity of parties, activities in which they engage.

And I would look at the avenue of attacks. I think that we are mostly concerned by passive observation of traffic, and I can think about a series of attacks on privacy:

• Client identity. It is not a concern for TRAIN in the models in which the IP addresses are exposed, but what of the VPN or Oblivious model? Is the TRAIN activity somehow observable through a VPN? Can it be used to correlate clear text traffic with a source?
• Client capability (and thus identity): Supposing that at least in a deployment phase TRAIN will be rare, TRAIN usage reveals that the client is part of the early deployment. That can be part of fingerprinting.
• Client activity: using TRAIN may reveal that the endpoints are engaged in some form of realtime application. Is that more information than already available?
• Client RTT, thus revealing usage of a VPN at cleint or server side -- the attack that is most concerning with the Spin bit. Can attackers measure the time between action (TRAIN packet) and reaction (traffic is reshaped to meet suggested bandwidth)?

Maybe we can brainstorm some more and think of more of such attacks.

And then, if we do find some of those attacks convincing, maybe we can start thinking of countermeasures. Maybe some form of greasing, e.g., sending TRAIN packets occasionally even if the application is not trying to shape video. Or, deliberately injecting wrong valued TRAIN packets end-to-end, with fake limits that are then ignored. Maybe doing that will require making the payload of train a bit more complex.

[martinthomson]

Hmm. I had thought this easier originally, then the PR got long. And I clearly missed a few things.

As for deployment scenarios, I know that there are many options here, but really the only one that seems likely to result in action is server-to-client flows. That's where the bulk of the data flows. That's why I started with that framing. #25 does talk about other interaction models, but spending too much effort on those seems less useful.

I don't see the identity thing as an issue. Same for leaking capability. There is a segregation effect here that might apply in that it creates a discriminator that might separate flows into groups. Where a set of flows might have previously been homogeneous, markings will separate them out. More so past the point that rate limit signals are applied, but that very much depends on the deployment scenarios.

If this goes ahead, then some client software will turn this on and it will be visible. Hopefully, that is a popular stack. Hopefully that stack just turns this on always, not conditionally based on the application. Then the privacy risk is negligible. If all flows from all browsers had this enabled, there is no distinguishing value to the signal being present. It will only be used by a limited number of services, but those services would be identifiable from IP, so no big deal there either. That eliminates any concerns about whether this being on or off leaks information.

Maybe that's the part that needs highlighting. That this leaks information if it is exceptional, so don't make it exceptional.

The RTT thing seems like it isn't even worth mentioning. There are much, much better passive RTT leaks in QUIC. The reaction to a signal is not unambiguous. It's also only really going to be effective if the flow is isolated, such that the congestion control response doesn't suppress it instead. In that case, the congestion control response carries the signal anyway.

[huitema]

I agree that "sticking out" is the first concern, and that we should encourage stacks to turn it on.

I think there is also some value in scrambling the signal, i.e., originating occasional TRAIN packets in which the VN is set to "10 Mbps" or "20 Mbps" instead of just TRAIN. Both for detecting possible misbehaving middle boxes, and for scrambling the signals that can be snooped.

I disagree that "bits are coming from the server". In the videoconference use case, bits are coming from the client as well.

I think we should think a little more about "client -- VPN -- network -- server". Assume an attacker that sees the traffic in and out of the VPN. Does TRAIN >VPN provide information to tie the VPN -- server traffic to a specific client -- VPN flow?

[martinthomson]

I've added a paragraph about adding some chaff. That won't be 100% effective (any rate limit that is applied will establish a ceiling).

As for videoconferencing, I'm not saying that we don't have something, but that it is not a dominant scenario and the privacy/utility trade-off is not ideal. There is text on that point already, but it doesn't make a simple recommendation.

Before we talk about VPNs, do you think that this only makes sense for single-subscriber connections to access networks? That is, a major transit provider probably won't be doing this for the interconnect flows that move from one ISP to another.

Separately, anything inside the VPN tunnel will be protected completely (I hope), so it is only the marking that is applied outside the tunnel that matters. The real risk there, as already identified, is the upstream marking (client-to-server).

[martinthomson]

Oh, and 🤦, me. A local ISP won't be able to apply signals to VPN traffic, because the endpoint that receives them is the VPN host. I doubt that the unprotected link (VPN -> server) will need or want to apply markings, but if they do it will be without information about the client.

So I think that VPNs aren't that big of a deal. The only scenario that bothers me is maybe draft-ietf-masque-quic-proxy, but even that looks good if encryption is used (which it should be).

[huitema]

I was concerned about a third party inserting fake TRAINs in the "network" section to check whether effects are noticeable in the "vpn" section. Suppose VPN serves clients A, B, C. Attacker sets a TRAIN mark on traffic on 5-tuple S-D-s-d-udp between the server and the VPN. A receives it, passes it to the server, and now traffic between VPN and A drops to 5 Mps. Attacker confirms by setting another mark at 10 Mbps, and observes a bit later traffic between VPN and A increase to 10 Mbps. Attacker concludes that outside address D matches A.

[martinthomson]

Oh, that's potentially scary, but isn't that possible with packet dropping as well? The congestion response from the affected connection is fairly easy to trigger.

[huitema]

I guess there are multiple attack vectors. ECN bits could also be used that way. Should we recommend that VPN just wash out the signal? (And ECN bits, of course.) OTOH TRAIN is a much more powerful signal than ECN. With ECN, you will need to re-mark pretty much all packets.

[huitema]

Generally the pattern is "sneak signal into encrypted VPN, correlate with encrypted changes in VPN." Of course, there is a converse issue. What if there is a TRAIN signal on the outer envelope of the VPN. Should it be copied to the packets exiting the VPN?

[martinthomson]

The default, and safe, answer there is that the TRAIN signal is absorbed by the VPN. I realize that there is some value in having that information available, but it might be better to look for the VPN to provide feedback to the client, rather than propagate it end-to-end in that case.

[huitema]

I think that I could make the privacy text shorter and simpler.

We may be concerned that the values advertised by TRAIN are leaking the network preferences for some servers or applications. This leaking out part is largely by design: networks that advertise a specific supported rate are revealing that they are configured to do so. The actual throughput can of course be measured by on path observers, so we can argue that advertising a TRAIN parameter does not provide any information that is not already observable. It may be more convenient for observers to capture a few TRAIN packets than to keep counters of all traffic seen, but not by much -- Cisco's NetFlow, for example, does this measurement already. Maybe say that in the introduction of the privacy section.

After that there are just a few important issues, and we should stick to that:

• sticking out
• compromising metadata protected by VPN

[martinthomson]

Do you want to suggest something?

[huitema]

I took a first shot with PR #27