Discuss loop attack prevention

[tfpauly]

If a proxy does not enforce the uniqueness of mappings from client-to-proxy connections and server CIDs to server-facing sockets, it is possible for a client to induce packet loops through the proxies. We should discuss this and explain in security considerations why this is critical to avoid.

I think this also means we should make the mapping requirement in Section 2.2 more stringent to be unique not only for the client-facing socket, but also the client QUIC connection.

[DavidSchinazi]

We should also add text to ensure that proxies MUST validate the source IP address of incoming packets when checking the CID mapping - that way a node can't cause a loop without being in the loop itself (which defeats the amplification purpose of creating a loop).

[tfpauly]

Great point!

[chris-wood]

It's probably worth clarifying -- beyond what's already there -- that sockets mean 5 tuples here, and maybe even removing the word socket altogether. That seems like an implementation detail. And I can definitely imagine implementations binding to * as their socket and determining the 5 tuple only upon reading a packet.

[DavidSchinazi]

Agree with Chris, perhaps the term "socket" in the draft is more confusing than just using "5-tuple"? Many people think of a socket as a non-connected socket.

[tfpauly]

Yeah, we can call it a 5-tuple, or just a tuple. My main concern is how easy to understand the terms "client-facing 5-tuple" and "server-facing 5-tuple" are.

[tfpauly]

I believe loops are handled now by #104