Client port for new connections

[janaiyengar]

To minimize load on NATs, especially cone NATs, it might be a good idea to recommend using the same {IP + client port} on outgoing connections. An added value is that it makes any 2/4-tuple based side-channels less leaky.

Clients should not use the same port when using a new IP, to avoid correlation when migrating connections.

On a related note, none of the drafts talk about use of UDP ports on the client side. The -http draft talks about use of ports on the server side, but there's no mention of client side ports.

[marten-seemann]

This will also prevent you from using 0 byte connection IDs. 4 byte will be sufficient though, which might be good enough.

[martinthomson]

There are a whole bunch of trade-offs here that we need to be cognizant of. Using the same port could be a proxy for "same device" even in the presence of NAT, which is a nice linkability signal, where the NAT would otherwise create some uncertainty about that. For connections from the same host, same port indicates "same application". Using the same port also means that you need to use connection IDs, which is less efficient.

We do already have advice about changing source port after a period (along with a new connection ID), which addresses the final point. Combining that with advice on reusing ports complicates things a little because you need to observe quiescent period across multiple connections (maybe, I don't know how this might look).

All in, I think that it's probably best to let a system of best practices evolve around this rather than stipulate any specific behaviour.

[mirjak]

We basically have an open issue in the ops-draft (26) to figure out if want to say more. In any case I think it would belong in the applicability statement.

[ianswett]

The one thing that may be worth adding text for is not adding linkability at the IP/port layer, but otherwise I'd rather wait for best practices to evolve as @martinthomson said.

Currently, the transport draft spends a lot of text and effort on ensuring connection IDs don't create linkability, but no text on ensuring the routing layer(ie: IP and port) don't do the exact same thing. Possibly that belongs in security considerations?

[mikkelfj]

Agree with MT/Ian.

On recommendation to not use same port when on a different IP, that probably makes sense in some common scenarios, but there are others where it would be a pain, especially when you do not use the Berkely socket interface for outbound UDP: In a docker cloud deployment you might hardcode the port in the application or environment and let the IP sort itself runtime. If for some reason the IP changes in the surrounding NAT layer, you don't want to deal with that. Nor do you generally want to deal with generating random ports.

So I think it might be a good recommendation for migratory client use cases, but it should not be a general requirement.

[kazuho]

I think the fear we have with QUIC is that some NATs are going to run out of UDP ports, or that they would be reusing ports at a rate so fast that we would be seeing involuntary migrations with connections that are idle for just a small fraction of time.

Reusing the client-side tuple for multiple connections do mitigate the issue.

The trade-off here is the privacy concern that @martinthomson pointed out. I agree that it is a concern, however I might also argue that hiding who's behind does not have a practical benefit for small NATs (e.g. home routers). And huge NATs (e.g. carrier-grade) might have an observer within the NAT.

[hardie]

On Sun, Dec 2, 2018 at 5:34 PM Kazuho Oku ***@***.***> wrote: I think the fear we have with QUIC is that some NATs are going to run out of UDP ports, or that they would be reusing ports at a rate so fast that we would be seeing involuntary migrations with connections that are idle for just a small fraction of time. Given that there is sparse data on this, I tend to support

@martinthomson's view that we ought to let practice emerge here rather than trying to specify it. Getting the right behavior for small NATs, enterprises, and CGNs may not be one-size fits all for these trade offs. regards, Ted

…

Reusing the client-side tuple for multiple connections do mitigate the issue. The trade-off here is the privacy concern that @martinthomson <https://github.com/martinthomson> pointed out. I agree that it is a concern, however I might also argue that hiding who's behind does not have a practical benefit for small NATs (e.g. home routers). And huge NATs (e.g. carrier-grade) might have an observer within the NAT. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2061 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABVb5NX-YqodGcamKlUksQIS36HGa2Q_ks5u1H-pgaJpZM4Y29B6> .

[janaiyengar]

My concern was what @kazuho mentions. There's anecdotal data that NATs are less generous with UDP ports than they are with TCP ports, and there is a scaling concern with QUIC because of that.

I'm not particularly concerned about linkability concerns here because multiple connection IDs can be used within a connection, and that is something we might want to encourage in general.

That said, the counterpoints raised here are good ones. I am fine with not specifying this in the draft, and seeing how best practices evolve.

[janaiyengar]

I don't think there's interest in adding any recommendations, so I'll close this issue.