Re: [Masque] Forwarded Mode infinite loops

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=40meta.com@dmarc.ietf.org> 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=40apple.com@dmarc.ietf.org <mailto:eric_rosenberg=40apple.com@dmarc.ietf.org>>
> Sent: Friday, October 20, 2023 1:15 PM
> To: Ben Schwartz <bemasc@meta.com <mailto:bemasc@meta.com>>
> Cc: Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>>; MASQUE <masque@ietf.org <mailto:masque@ietf.org>>
> 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=40meta.com@dmarc.ietf.org> 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 <masque-bounces@ietf.org <mailto:masque-bounces@ietf.org>> on behalf of Martin Duke <martin.h.duke@gmail.com <mailto:martin.h.duke@gmail.com>>
>> Sent: Wednesday, October 18, 2023 5:25 PM
>> To: MASQUE <masque@ietf.org <mailto:masque@ietf.org>>
>> 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
>> Masque@ietf.org
>> https://www.ietf.org/mailman/listinfo/masque
> 
> -- 
> Masque mailing list
> Masque@ietf.org <mailto:Masque@ietf.org>
> https://www.ietf.org/mailman/listinfo/masque