This is nothing new. It's trivial to make website visitors DoS a target IP address using XHR requests, WebRTC, <img> tags, etc.

WebUDP wouldn't necessarily make the situation any worse.

Like the attack on GitHub a few years ago: https://www.eff.org/deeplinks/2015/04/china-uses-unencrypted...

Seems to me that one key difference would be that giving javascript access to UDP sockets easily enables a single browser to send huge amounts of traffic since there's no ACK to wait for. With anything based on TCP, the attacker at least has to put some effort in to achieve that.

You could easily design it so that you can only send UDP packets to hosts you already have a TCP connection with.

It's definitely a concern! WebRTC solves this in two different ways:

1. The receiving end must consent to receiving packets by completing the DTLS handshake required by WebRTC.

2. The browser enforces SCTP congestion control to avoid spamming large numbers of UDP packets. Basically, it'll start throttling you when it detects packet loss.

This sounds like a bad option for games played over wireless connections.

Yes.

The only way this could be done safely is if you are required to establish a TCP connection, and then "upgrade" it to UDP. There are too many pointy sticks that developers could impale themselves on, with the side effect of creating DDoS vectors.

Can you do it safely if you're required to make an HTTPS request to the same hostname with some standardized request (a la CORS preflight) and get an answer back saying "Yes, this origin may connect to me on these UDP ports", and then hang onto that permission indefinitely? The nice thing about having a persistent permission instead of an upgrade on each request is that a service worker that's woken up by a push notification or similar can immediately send UDP traffic instead of doing a TCP (+ HTTPS?) handshake.

Since it's restricted by origin (probably using literally the same mechanism CORS uses) and over HTTPS, a malicious actor can't DDoS anyone but themselves.

If you're really worried, maybe extend it to allow the server to limit the duration of the permission and the maximum bandwidth, but I think you don't need that.

EDIT: Oh, oops, binding to the hostname doesn't help because you can just repoint your hostname in DNS at someone else. You'd ideally need to bind it to the IP, in which case you definitely want it to be a time-limited permission. (But I think that attack is also feasible, though a bit harder, with the handshake-before-each-UDP-connection model. Just have the attacker set up a custom DNS server for their domain, which for any hostname sends you a low-TTL response pointing to the attacker's HTTPS server, and then a higher-TTL response to the victim. Each user gets pointed at a random hostname within that domain.)

That model tends to be hell on firewall appliances and NAT/load balancing devices.

I'm not sure I follow - how is this different from, say, a native app (desktop or mobile) that's just using UDP like normal? There's a single preflight request per client device, which can usually be satisfied when you load the website itself.

It's different because a load balancer will send your initial HTTPS request to one application server, but when you're switching protocols (to UDP) you'll then want that traffic directed the same place. Or need some way to share session data across multiple app servers.

You could handle it with some kind of cookie/token that enables the LB to route to the right place, but that opens a whole bunch of other complicated logic too.

Whereas if the UDP application/server were able to handle it independently of HTTP(S), you wouldn't need any of that.

Either I'm not following you or I'm being unclear - it doesn't matter what HTTPS server the load balancer sends it to, all that you need is a reply saying "Yes, in general, sending UDP to my IP on this port is fine with me." You don't need to send it any other application-level data, and frankly the load balancer itself could send that static reply. So you don't care what application server it's sent to.

And once you have that permission, you never need to make an HTTPS connection again.

What you do care is that your actual application traffic, such as your login session, and your UDP traffic have some way of being associated with each other, but you have that problem regardless of how the client (whether it's a browser client or a normal desktop/mobile app) gets permission to send UDP.

As an example, the user could visit example.com, load some HTML and JS, send a request to login.example.com, get a session key, send a single HTTPS request to data.example.com exactly once, and then send UDP to data.example.com protected by that session key. You never send HTTPS to data.example.com again; from this point onwards you only send UDP. Coordination between your HTTPS login server and your UDP data server is no different in this model from the native app model.

I think we're on the same page. My point was I think it's too complicated to do all of those steps (and likely more) just to "switch" to UDP. You could instead make all of that part of the Web UDP application, which is no less complicated, but then you are removing one step of switching applications/protocols midway through.

I guess what I'm trying to say is UDP could work, but I think trying to bootstrap the initial connection/session info with HTTP is probably going to be FAR more trouble than it's worth.

UDP over IPv4 and IPv6 has source IP and source Port in header. This can be used for sticky routing through Load Balancers.

Sure, but in this context, unless you are able to use the same source port for TCP and UDP (and likely from the load balancer to the application server too) you'll still need another way to identify a client/session when switching from TCP to UDP.

Doing that with NAT is even trickier. Take a look at the way some firewalls need to configure a DMZ for gaming, or SIP for some examples.

I'd like to point out that getting SIP through firewalls is a massive headache even today. If you're embedding connection information into a control channel, then the firewall needs to do DPI to figure out what is a valid communication stream vs. some attacker. And then people start encrypting the control channel and it's game over unless you can hook your firewall up to whatever the controlling software is or your firewall is super fancy and can MITM the control channel traffic because you've installed the cert chain on the firewall.

You could also handle the "handshake" elsewhere, like the application layer. This type of identification is already done in other UDP-based protocols, like RADIUS.

UDP is arguably faster in some ways that is handled, provided the application load is managed well.

Putting UDP on top of TCP eliminates any possible benefit of using UDP.

If it is implemented with handshake mechanics same as WebSockets, then it would be no more harmful than WebSockets.

This is demonstrably not true.