Re: [Masque] Forwarded Mode infinite loops

[Martin Duke <[e-mail]>]

Yes, if the forwarder's don't share a VIP, then the packets at P1 can be
distinguished by source IP address. I'm not sure if the draft requires that
today, but it is a simple mitigation.

If they share a VIP, the packet has no distinguishing features.

On Fri, Oct 20, 2023 at 11:02 AM Eric Rosenberg <[e-mail]>
wrote:

> I think the loop Martin is describing is only possible when forwarders
> share a VIP - so not quite unrelated. There may be other loop attacks, but
> I believe this particular one would be mitigated if all proxies sharing a
> VIP constructed virtual client CIDs to guarantee no overlap.
>
> Eric
>
> On Oct 20, 2023, at 10:44, Ben Schwartz <bemasc=[e-mail]>
> wrote:
>
> They could, but AFAIK they aren't obligated to. If a client has access to
> several unrelated QUIC Forwarders, it could theoretically set up a loop
> among them unless they decide to generate long, un-collidable Connection
> IDs.
>
> --Ben
> ------------------------------
> *From:* Eric Rosenberg <eric_rosenberg=[e-mail]>
> *Sent:* Friday, October 20, 2023 1:15 PM
> *To:* Ben Schwartz <[e-mail]>
> *Cc:* Martin Duke <[e-mail]>; MASQUE <[e-mail]>
> *Subject:* Re: [Masque] Forwarded Mode infinite loops
>
> This Message Is From an External Sender
>
> Changing who chooses the Connection IDs could help, but proxy-chosen CIDs
> are not necessarily high entropy, so there's no clear guarantee.
>
>
> Do you mind elaborating here? If the proxy chooses the virtual client
> connection ID, P2 and P3 can pick virtual client connection IDs that don’t
> overlap. For example, they could do something like virtual client CID =
> {server_id}{random_bytes}.
>
> Eric Rosenberg
>
>
> On Oct 20, 2023, at 09:53, Ben Schwartz <bemasc=[e-mail]>
> wrote:
>
> Loops!  This is a fun attack.  It seems like there are probably lots of
> loopy configurations if you have access to two or more proxies.
>
> Most of the encryption discussion for forwarded mode has focused on
> unauthenticated encryption, which wouldn't help here.
>
> Changing who chooses the Connection IDs could help, but proxy-chosen CIDs
> are not necessarily high entropy, so there's no clear guarantee.
>
> Ultimately, I'm not sure this matters.  A hostile client can impose pretty
> much arbitrarily amplified load on the forwarder anyway, e.g. by
> downloading a large file and forging ACKs to dropped packets so that
> congestion control ramps up to infinity.  Forwarders will need defenses to
> rate-limit or cap abusive clients.  That said, it's probably worth fixing
> if there's an easy solution.
>
> --Ben
> ------------------------------
> *From:* Masque <[e-mail]> on behalf of Martin Duke <
> [e-mail]>
> *Sent:* Wednesday, October 18, 2023 5:25 PM
> *To:* MASQUE <[e-mail]>
> *Subject:* [Masque] Forwarded Mode infinite loops
>
> 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.
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>
>
> --
> Masque mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/masque
>
>
>