Other OSS MASQUE implementations

[achernya]

Hi! I’m very excited to see more CONNECT-IP implementations out in the wild :)

One thing I noticed in your README was the note “connect-ip-go - The only open-source implementation for RFC 9484 I could find.” — as part of standardizing RFC 9484 we did a bunch of interop testing, and Google’s implementation is available at https://github.com/google/quiche/tree/main/quiche/quic/masque. This includes a “toy” (as in not focused on performance, but standards-complaint!) client and server implementation. It should be workable if you want to do interop testing, but won’t implement any of the quirks Cloudflare’s implementation has.

[Diniboy1123]

Hi,

Thanks for reaching out! I wouldn't want to spread misinformation, therefore I updated the docs and made a list of amazing resources I could find on the matter for the sake of clarity. When I started my research last year around October, I haven't found too many libraries out there.

On the other hand, I don't really know how this repository never made it it to my attention. Search engines don't treat Github too well... Just read through the code and it seems to be very easy to follow, it would have saved me from a lot of hassle. I like how you support multiple modes of operation within a single lib and even support CONNECT-ETHERNET. I will definitely consider this in the future if I decide to make this client non Cloudflare exclusive for interop testing. I find it strange that this comparison lacks mention of your project (besides the not to be confused with Google's implementation note).

PS: I haven't heard the term toy used in this context before, but I like that one.

[achernya]

Google's implementation there is listed under Chromium. It was extracted out as a separate repo much later, as it's not chromium specific.

If you do have any questions do feel free to reach out---I'm one of the authors or CONNECT-IP and am involved with the other masque documents.

[Diniboy1123]

Oh okay, that makes sense! Thanks for clarifying.

I might take up on that offer right away. What's your view on keepalives? I read many RFCs and at least one mentioned that those are usually unnecessary and discouraged. I don't have it quote ready, but I can look it up later if necessary. For regular "short lived" HTTP/3 traffic I agree, it isn't that useful. But with CONNECT-IP we are talking about potentially long sessions...

Cloudflare's own client seems to send keepalives every 2-3 seconds. The client works just fine without that as well, but I am not too sure what would be ideal. I find 2-3 seconds too much...

[achernya]

The original implementation (before CONNECT-IP standardization) didn't have explicit keepalives, but rather health checks. The goal was not to prolong the connection but to check to see if it was still alive and usable end to end, and restart it if not.

[Diniboy1123]

to check to see if it was still alive and usable end to end

That's exactly my goal as well as the remote end on Cloudflare's site seems to disconnect with a H3_NO_ERROR if there is no significant network activity or sometimes just breaks down without any error even. In this last scenario it's really hard to know what happened from the client side, I only see the issue if I send a datagram.

I haven't found any draft regarding these health checks, too bad they didn't make it to the final standard. Keepalives seem unnecessary to me, which is why I asked. As keepalives happen on QUIC level and not inside the tunnel and the remote end still disconnects with it often...

[achernya]

As is the case with many RFCs, they are a snapshot in time of what we had consensus to standardize. That doesn’t mean work is complete, and there are still extensions related drafts still being introduced and worked on.

[Diniboy1123]

Sounds reasonable. Thanks a lot once again for taking your time to explain this to me. I will close the issue for now, but will keep your contact in case I encounter questions.

Really glad you guys made this a thing, once I started this project I didn't know much about CONNECT-IP, but over time I started to like it more than one would consider healthy. 😄 I don't really understand how it didn't make it as a mainstream WireGuard competitor yet.