search

ietf-wg-masque / draft-ietf-masque-quic-proxy

Other
12 stars 7 forks source link

Discuss loop attack prevention #42

Closed tfpauly closed 1 month ago

tfpauly commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

Great point!

chris-wood commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 1 month ago

I believe loops are handled now by https://github.com/ietf-wg-masque/draft-ietf-masque-quic-proxy/pull/104