[Masque] Forwarded Mode infinite loops

[Martin Duke <[e-mail]>]

Hello MASQUE,

(with no hats on)

I was playing with some annoying but manageable amplification attacks on
CONNECT-UDP forwarding mode. Those will have to wait for another day,
because the current draft has a fatal vulnerability, though one that we can
fix pretty easily.

If I've gotten something incorrect, please say so! It wouldn't be the first
time.

Recall that for forwarded mode, clients notify the proxy of the connection
ID they are advertising to the target, and in the same capsule propose a
"virtual connection ID" for use on the proxy-client path. (IIUC, this
virtual CID is to prevent association of the packets on either end of the
proxy).

I reiterate that we are talking about the CLIENT connection ID and
its virtual counterparts, not the target.

Consider the following very stupid topology that a client C could construct
to target T via various proxies. Crucially, P2 and P3 are from the same
provider and share a VIP.* This wrinkle eliminates some really simple
mitigations for what I'm about to describe.

C -> P1 -> P2 -> P1 -> P3 ->  T

An otherwise well-intentioned client would advertise client Connection ID
CID0 to T, and via REGISTER_CLIENT_CID capsules might set up the rest like
so:

Nodes        C     P1     P2    P1    P3     T
CID on wire    CID4   CID3  CID2  CID1   CID0

So far, so good. A packet that leaves T will be destined for CID0. The
destination CID will be rewritten in turn, arriving at C with CID4.

However, a malicious client can register CIDs with the proxies as follows:
Nodes        C     P1            P2      P1      P3     T
CID on wire    CID4   CID3 / CID1    CID2    CID1   CID0

The only change is that P2 is "incorrectly" configured by the client to
rewrite incoming CID2 as CID1. As far as P2 is concerned, everything is
seems legit unless it is sharing enormous amounts of CID state with its
partner P3. Everything else is unchanged.

Thus, a packet leaving T with CID0 will be rewritten to CID1 and routed to
P1;  P1 will then route it to P2 with CID2. Then that gets routed back to
P1 with CID1, and the P1-P2-P1 loop continues to infinity. The attacker can
put as many proxy hops as it likes in that chain.

There are a few pretty simple things that can break this doom loop.
- Do encryption at each MASQUE hop, as previously proposed. This verifies
the previous hop of the packet and drops those where the CID does not have
the correct origin.
- Have the proxy provide the virtual CID instead of the client. Client
control is the root of these problems.
- Eliminate virtual client CIDs and just take the L on linkability in that
case

Martin

* Interestingly, this attack requires at least one proxy in the path (P1 in
this case) to not be load balanced or have an easily manipulated load
balancer, so that two QUIC connection attempts can with high probability go
to the same device.