In #2, why is the path hardcoded to /? One of the things I've considered somewhat important in my similar work (on Orchid, using HTTPS+WebRTC) is the ability to "embed" a VPN as a sub-resource on some existing website.
Machine learning has non-trivial false positives. We don't need firewalls launching denial of service attacks on legitimate traffic at random.
Blanket denying all traffic is a good first step to ensuring that the system is really, really secure :P
An IDS basing its fundamental action (detection) partly on ML can definitely be a good, valuable idea. An IPS basing its fundamental action (blocking traffic) partly on ML is the problem.
[1] https://github.com/DavidSchinazi/draft-cms-masque-connect-ip...
You could use the path to indicate different VPN endpoints, but ultimately the path isn’t needed at all.
Additionally all of this is gonna be inside a TLS session, so no external viewer will ever see any of the headers, including the path.
TL;DR the RFC doesn’t make this VPN endpoint a traditional http resource at all. It a special new HTTP method (like GET or POST) that indicates the client wants the server to treat the following data as an IP stream.
I guess I am also very curious why you aren't defining this over WebTransport (which would allow it to be usable from websites--verified by systems like IPFS--to build e2e-encrypted raw socket-like applications, as I imagine CONNECT-IP won't be something web pages will be able to use). (For anyone who reads this and finds this thought process "cool", talk to me about Orchid some time, where I do e2e multi-hop VPN over WebRTC ;P.)
As a possible solution for the discovery by authorization error problem, maybe a convention could be established where an authorization error is returned by default if CONNECT-* isn't configured.