Re: [quicwg/base-drafts] Coalescing different CIDs for same connection (#3800)

[hardie <[e-mail]>]

Hi Mike,

On Tue, Jul 14, 2020 at 2:01 PM Mike Bishop <[e-mail]>
wrote:

> Can you say more about why you don't see this as an issue? Is it because
> this use case is most likely during the handshake? Or is there some other
> linkability already present that makes this less of an issue? regards, Ted
>
> Both, actually. This occurs during the handshake, when addresses are
> required to be stable. Unless you're running a large number of parallel
> connections, all CIDs used on that 4-tuple during the handshake belong to
> the same connection with very high probability.
>
I think "high probability" is probably app-dependent, because there may be
cases where there are significant numbers of parallel connections.  In the
case of proxied queries, for example, the use of the same 4-tuple but a
different CID could turn out to be common, because the proxy may prefer to
keep traffic from its different clients separate even if they could be
served by the same upstream server.

A DNS example:  if you have an DNS resolver talking to an upstream proxy or
a common authoritative server, that resolver may want to set a different
Client Subnet for different query streams, so that input can be used to
determine the preferred reply.*

> You can break that linkage by deliberately changing CID and port at the
> same time, but you can't do that until the handshake is confirmed. If you
> want the linkage broken, you need to do that jump post-handshake anyway.
>
In the presence of a NAT or CGNAT, there could be interesting interaction
with the dwell timers in the state table of the middlebox.  If you change
it too late, the middlebox may recycle the most recently freed port, which
could result in you getting the same 4-tuple to an observer on that part of
the path.

Speaking strictly as an individual, I think using a single CID per
coalesced packet as Christian prefers is cleaner and leaves open app
behaviors we may not have yet identified.

regards

Ted

*I'm not a big fan of Client Subnet, and these particular parallel
connections may or may not pose a risk; it's just a proxy situation where
the parallelism might occur.



> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/3800#issuecomment-658411474>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAKVXZBEI4ITAAKO3YE2ARTR3TBUFANCNFSM4OMZFPYA>
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3800#issuecomment-658425864