There is a lot more to security than transport-layer encryption and authentication.
> Connection based
UDP is too hard, so re-inventing TCP?
> p2p is not reliable ... monetization
Oh, you want require the SAaSS[1] model.
> Simple to use
The already-stated "requirements" are asking for something more complex than WebRTC.
> Minimum header overhead
Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is?
> WebRTC suffers from complexity
That complexity exists for reason. Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors.
> There is a lot more to security than transport-layer encryption and authentication.
You are welcome to PR.
> Connection based
This could be explored: starting from simple handshake, all the way to fully connection based protocol. Open for discussion based on developer needs.
> The already-stated "requirements" are asking for something more complex than WebRTC.
You are welcome to highlight specifics that makes you think that way.
> Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is?
UDP is not streamed but message based protocol. As WebSockets implement their transport layer over pure TCP, WebUDP could implement it's own layer over pure UDP for various reasons.
> > WebRTC suffers from complexity
> That complexity exists for reason.
For P2P type communications, this complexity is perhaps reasonable.
For Server-Client type communications not at all.
> Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors.
This document is initial effort to bring public discussion to form a reasonable shape of what WebUDP could look like. You are welcome to participate.
This seems to come up every now and then, and I see the same arguments, and they're still not compelling.
WebRTC data channels in unreliable mode will work just fine. Is it as easy as opening up a WebSocket connection? No, it's not. Is it as easy on the server side as accepting a WebSocket connection? Also no.
But it really isn't that hard[0], and people have built libraries to help you out. So just use one, and move on with your life.
And you also benefit from a standard that has been fleshed out over multiple years by some very smart (if imperfect) people.
On the browser side, it's already supported by all major browsers, with the notable exception of iOS Safari (which should change this fall with the release of iOS 11)[1]. Even though it's not ideal, you can fall back to WebSocket for the few holdouts.
[0] Source: I've done it before, building it from scratch.
Posted this recently in another thread, but maybe someone will find https://github.com/seemk/WebUdp useful as there have been many WebRTC threads lately. It's a WebRTC DataChannel server implementation for out of order, unreliable UDP traffic for browsers that has built-in SDP signaling and STUN.
Anyone interested in this might find some enlightenment in Glenn Fiddler's whitepaper. [1] It talks about the issues with TCP-based connections, WebSockets, QUIC, WebRTC and provides a solution (with code) to doing UDP in browser.
I think you're going to need a stronger argument for "Why not WebRTC", or at least concrete proposals about what parts of the API you would change. For example, "SDP parsing is too complex, have a JS API to set up a client-server connection without a SDP".
IMO the most complex parts of WebRTC are the SRTP-DTLS encryption (except you also specified TLS as a requirement for Web UDP), and STUN/TURN (which are optional and not required for client-server).
Firefox OS had TCP[0] and UDP[1] sockets as Web APIs. They were quite pleasant to use as a developer and the only way to create a real mail client (needs TCP to implement POP, IMAP, SMTP in JS).
I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs.
> Firefox OS had TCP[0] and UDP[1] sockets as Web APIs. They were quite pleasant to use as a developer and the only way to create a real mail client (needs TCP to implement POP, IMAP, SMTP in JS).
The biggest problem with Firefox OS's TCP standard is that it used an event-driven model, which is somewhat at odds with more current promise-based thinking. The more natural version is to use something based on WHATWG Streams, but that spec has been stuck in vaporware-land for years.
> I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs.
The TCP specification actually was undergoing standardization (reformatted to use the streams API): https://www.w3.org/TR/tcp-udp-sockets/ . The problem was the working group ended up closing down, and since the specification wasn't suitable for use on webpages, it ended up with nobody to host it.
Those implementations were created to be utilised within FirefoxOS where applications are granted permissions by user when installing them. And access to several API would be strictly regulated by OS it self.
In Web context this approach wouldn't work and would lead to security issues. Just like there was need or WebSockets (TCP), there is need for similar API for UDP but it cannot be pure access for creating UDP connections as this leads to many security concerns.
For this to be taken seriously, I think you need to demonstrate that you're capable of using WebRTC to do what you need. Without a decent nod in that direction, people are going to think that you're just not aware of the potential complexities.
Worth mentioning again: this effort is to explore server-client low-latency, not peer-to-peer scenarios which WebRTC solves well.
And this is collaborative effort, not personal. So all input is welcome.
I've used WebRTC for p2p and server-client cases, and it is nightmare for later. And many other developers have expressed very similar experience when it comes to server-client cases.
Even more, after many years we see very little adoption of WebRTC for server-client cases due to it's complexity. WebSockets on the other hand took very little time to get adopted by many back-end platforms as well as browser vendors.
I wrote my own WebSockets solution long time ago on .Net before 4.5 .Net was released (includes own WebSockets implementation).
Using UDP with the web on a wide scale will either replicate everything in TCP, inside UDP wrapping, or else cause big problems all over the Internet.
It will be fast only in the beginning when a few clients are participating, but then screw over the infrastructure with degenerative congestive behaviors when "everyone" is on it. And by then, it will be a standard everyone is stuck with, with the only way out being to complicate it with a tirade of hacky refinements based on guesswork combined with crossed fingers.
That's not even considering malicious interference: what sorts of attacks will be discovered on this new UDP based shit, and what sorts of hacks will be required to mitigate them.
I know that was the conventional wisdom, from back when backbone links were the bottleneck. But in the modern internet, almost all the congestion is at the edges.
Since most traffic for games is server->client, most of the congestion will happen when several users are competing for the same customer link (DSL or cable modem). This already happens with streaming services, and people just yell at each other to stop downloading updates while I'm watching Netflix.
SCTP would be the logical choice for supporting both streams and messages.
No one really wants to support a network with the evil of arbitrary UDP from the browser. In SCTP, the handshake combined with crypto tricks can allows a server to make sure the initiator stores a larger cookie than it needs to hold for verification, throttling the DDOS riffraff.
So many of these comments are like "UDP is not TCP!" or "Muh TCP guarantees!", then they go on to mention WebRTC?!!!
I mean, if you're streaming audio and video Real Time, is there really any point to TCP? If a few frames get dropped, then bursted back once the connection stabilizes, does that improve the user experience in any way?
WebRTC seems like a perfect candidate for UDP communications for the actual media streams.
WebRTC is best option for media streams today for peer-to-peer cases.
The goal of the topic is to explore simple option for server-client communication using low-latency communication, without reliability and without ordered delivery.
WebRTC can be used for such case, although it is not designed for it. Due to that implementation is very complex and not much adopted. This is something we trying to explore, either new API or simplifications to WebRTC to make it simple choice for UDP in server-client scenarios.
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.
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.
So if the main justification of this proposal is "WebRTC is too complicated", wouldn't that more speak for a WebRTC library and/or server geared towards games?
WebRTC doesn't work for browser control of a lot of IoT type stuff. The really high volume cheapo devices speak things like CoAP or DTLS, and they don't have the horsepower to run something like WebRTC. You'd need a level of control similar to the berkeley socket API to get the browser to speak those protocols.
At the moment, I see a lot of ridiculous stuff like phone apps talking to some cloud instance which tries to jam the packets back through your firewall into your Internet light bulbs. Congratulations, you literally just used thousands of kilometers of fiber and billions of dollars of routing infrastructure to make the world's most expensive how many... light bulb joke.
Last time I checked on WebRTC tutorials and examples was either too old and deprecated, or required the latest Chrome with some flags enabled. The best we have right now for real time streaming is HLS with up to 20 seconds or more delay. We had real time video chat 20 years ago, why can't we have it in the browser today !?
Yes, it seems like a server side complexity issue should be a fixable problem without updating the standards.
I suppose you'll still need to deploy a stun/turn server to deal with the NAT issues unless you're happy with IPv6 only, but that's not really something the standard can fix.
As mentioned in the doc, one of the options is to simplify WebRTC by making some components optional to enable it's better adoption and easier to implement on the back-end as well as on front-end.
This seems to propose that you can only connect to a certain server, similar to the same-origin-policy. What I would really love instead is the possibility to connect to arbitrary IPs to be able to implement real P2P. The linked posts dismiss this early because of the possibility to cause DDOS, but really, you can already do that from a hacked desktop "Quake", so there is no harm in being able to do it from a browser-based "Quake". What you'd have to prevent is drive-by use of UDP, not use of UDP period.
I would propose having two HTML profiles in future, HTML document, and HTML application (and maybe HTML legacy). HTML document would be restricted in what you can do, and would be primarily for reading Hypertext. For HTML application you would have to go through a few clicks to install or activate it - now you are going to say that people will just click it away, but that is already the case with current desktop app installers, so it is not more insecure! An application profile page will be able to access the net just like any other native application. Most importantly, it will be able to bypass same-origin policy and send UDP and TCP anywhere - but not with credientials of course.
You'd still have the problem of being able to probe internal networks, and being able to manipulate UPnP routers. For the first, the network admin could have a group profile setting or similar to disable this kind of access. For the second, browsers could selectively block this on a case-by-case basis if needed.
For the problem of DDOS, I think we should not let that restrict us from implementing useful technologies. Rather we should fix it at the source. For example, maybe one could lock down certain routes if an attack is detected. All traffic along these routes is throttled, unless you send along a proof-of-work token. I'm just making this up, but my point is that I think we haven't exhausted all options here.
For p2p, you already have the webrtc data channel which handles all the nasty NAT traversal and DDoS issues. Its browser API should be less volatile now than it has been in the past.
Implementing a WebRTC data channel endpoint in a server is not for the faint of heart, though. You would have to implement a lot of complex RfCs.
"The linked posts dismiss this early because of the possibility to cause DDOS, but really, you can already do that from a hacked desktop "Quake", so there is no harm in being able to do it from a browser-based "Quake"."
No same-origin-policy would be lovely combined with XSS vulnerabilities.
Suddenly all the visitors of that website would be doing DDOS on a random host.
I've written a WebRTC "server" that can establish such a connection (and also acts as it's own STUN/TURN server) and hand off sockets to a local process.
WebRTC isn't very complicated.
The hardest part is probably ICE, which basically involves each point telling eachother what they see, and potentially consulting a third party (STUN/TURN). I'd love to see more magic there, but once that's in-place, I don't see what's so hard about just using DataChannels.
One idea might be to put signalling into HTTP headers, e.g. have the client and server introduce something like:
ICE: sdp-desc...
and if so, allow WebRTC to skip the ICE negotiation step if speaking to the server.
This proposal lacks challenge/response and makes game server vulnerable to being used in DDoS amplification attacks if they use request/response pattern. Also, a proposal without packet encryption in 2017, seriously?!
That doesn't necessarily solve the problem which is in focus here. The QUIC version which is available in browsers (ok, Chrome only) is not only the QUIC stream layer, but also the QUIC HTTP adaption layer. From javascript side you just interact with HTTP and use QUIC under the hood. However with HTTP you also get all HTTP semantics (headers, reliability, ordering inside of request/response streams, etc.). What is requested is an additional protocol and API which avoids all the overhead and just allows to send and receive messages with best effort - because games and other realtime applications may prefer to build their own reliability mechanism on top.
The only way to use HTTP/QUIC for packetlike communication might be to send each packet inside a seperate HTTP request. But I guess that will have a super high overhead (lifecycle of a whole stream must be managed for a packet which actually has no lifecycle) and will most likely also not deliever the expected results (afaik HTTP on top of QUIC still has head-of-line blocking for request/stream establishment. Request headers must be received in order).
New javascript APIs which are utilizing QUIC could work. However one would need to explore if QUIC is actually helpful for target applications, since it provides a stream semantic, whereas UDP is purely packet based. QUIC might also introduce similar issues like WebRTC to the server side: It's a complex protocol spanning multiple layers (everything from flow-control to encrytion). Therefore it will be hard to integrate into environments where no QUIC library is available. But that's only a feeling, since I haven't yet reviewed the QUIC specification in detail.
One thing that I do not see mentioned here is multicast. Are there any advantages? Watching a live sports game, for instance. Since multicast is connection-less and sent only over UDP, the more distant discussion about introducing multicast into browsers never takes place. Having used a multicast video stream for many years in an enterprise setting I can unequivocally state that this would decrease network utilization. Especially in the years to come as the interwebs get clogged up with broadcast-type data.
[+] [-] pdkl95|8 years ago|reply
> 1. Security - it has to benefit from SSL.
There is a lot more to security than transport-layer encryption and authentication.
> Connection based
UDP is too hard, so re-inventing TCP?
> p2p is not reliable ... monetization
Oh, you want require the SAaSS[1] model.
> Simple to use
The already-stated "requirements" are asking for something more complex than WebRTC.
> Minimum header overhead
Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is?
> WebRTC suffers from complexity
That complexity exists for reason. Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors.
[1] Service as a Software Substitute
[+] [-] mrmoka|8 years ago|reply
You are welcome to PR.
> Connection based
This could be explored: starting from simple handshake, all the way to fully connection based protocol. Open for discussion based on developer needs.
> The already-stated "requirements" are asking for something more complex than WebRTC.
You are welcome to highlight specifics that makes you think that way.
> Wait, are you thinking about using UDP to transport HTTP?! Do you even know what your MTU is?
UDP is not streamed but message based protocol. As WebSockets implement their transport layer over pure TCP, WebUDP could implement it's own layer over pure UDP for various reasons.
> > WebRTC suffers from complexity
> That complexity exists for reason.
For P2P type communications, this complexity is perhaps reasonable.
For Server-Client type communications not at all.
> Nowhere in this document is a discussion of the potential problems of using UDP or the ways tthe new service might be exploited by malicious actors.
This document is initial effort to bring public discussion to form a reasonable shape of what WebUDP could look like. You are welcome to participate.
[+] [-] kelnos|8 years ago|reply
WebRTC data channels in unreliable mode will work just fine. Is it as easy as opening up a WebSocket connection? No, it's not. Is it as easy on the server side as accepting a WebSocket connection? Also no.
But it really isn't that hard[0], and people have built libraries to help you out. So just use one, and move on with your life.
And you also benefit from a standard that has been fleshed out over multiple years by some very smart (if imperfect) people.
On the browser side, it's already supported by all major browsers, with the notable exception of iOS Safari (which should change this fall with the release of iOS 11)[1]. Even though it's not ideal, you can fall back to WebSocket for the few holdouts.
[0] Source: I've done it before, building it from scratch.
[1] https://caniuse.com/#feat=rtcpeerconnection
[+] [-] lxtx|8 years ago|reply
[+] [-] mrmoka|8 years ago|reply
[+] [-] Wofiel|8 years ago|reply
[1] https://gafferongames.com/post/why_cant_i_send_udp_packets_f...
[+] [-] gafferongames|8 years ago|reply
[+] [-] TD-Linux|8 years ago|reply
IMO the most complex parts of WebRTC are the SRTP-DTLS encryption (except you also specified TLS as a requirement for Web UDP), and STUN/TURN (which are optional and not required for client-server).
[+] [-] mrmoka|8 years ago|reply
[+] [-] soapdog|8 years ago|reply
I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs.
[0]: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/... [1]: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/...
[+] [-] jcranmer|8 years ago|reply
The biggest problem with Firefox OS's TCP standard is that it used an event-driven model, which is somewhat at odds with more current promise-based thinking. The more natural version is to use something based on WHATWG Streams, but that spec has been stuck in vaporware-land for years.
> I wish more Firefox OS APIs had become web standards. They would allow for some very powerful PWAs.
The TCP specification actually was undergoing standardization (reformatted to use the streams API): https://www.w3.org/TR/tcp-udp-sockets/ . The problem was the working group ended up closing down, and since the specification wasn't suitable for use on webpages, it ended up with nobody to host it.
[+] [-] mrmoka|8 years ago|reply
In Web context this approach wouldn't work and would lead to security issues. Just like there was need or WebSockets (TCP), there is need for similar API for UDP but it cannot be pure access for creating UDP connections as this leads to many security concerns.
[+] [-] geofft|8 years ago|reply
The SSH and mosh apps use a binding between the POSIX socket interface on the Native Client side and these APIs on the JS side.
[+] [-] mnarayan01|8 years ago|reply
[+] [-] mrmoka|8 years ago|reply
And this is collaborative effort, not personal. So all input is welcome.
I've used WebRTC for p2p and server-client cases, and it is nightmare for later. And many other developers have expressed very similar experience when it comes to server-client cases.
Even more, after many years we see very little adoption of WebRTC for server-client cases due to it's complexity. WebSockets on the other hand took very little time to get adopted by many back-end platforms as well as browser vendors. I wrote my own WebSockets solution long time ago on .Net before 4.5 .Net was released (includes own WebSockets implementation).
[+] [-] kazinator|8 years ago|reply
It will be fast only in the beginning when a few clients are participating, but then screw over the infrastructure with degenerative congestive behaviors when "everyone" is on it. And by then, it will be a standard everyone is stuck with, with the only way out being to complicate it with a tirade of hacky refinements based on guesswork combined with crossed fingers.
That's not even considering malicious interference: what sorts of attacks will be discovered on this new UDP based shit, and what sorts of hacks will be required to mitigate them.
[+] [-] tlb|8 years ago|reply
Since most traffic for games is server->client, most of the congestion will happen when several users are competing for the same customer link (DSL or cable modem). This already happens with streaming services, and people just yell at each other to stop downloading updates while I'm watching Netflix.
[+] [-] xxgreg|8 years ago|reply
[+] [-] remline|8 years ago|reply
No one really wants to support a network with the evil of arbitrary UDP from the browser. In SCTP, the handshake combined with crypto tricks can allows a server to make sure the initiator stores a larger cookie than it needs to hold for verification, throttling the DDOS riffraff.
[+] [-] mrmoka|8 years ago|reply
[+] [-] fulafel|8 years ago|reply
[+] [-] jstewartmobile|8 years ago|reply
I mean, if you're streaming audio and video Real Time, is there really any point to TCP? If a few frames get dropped, then bursted back once the connection stabilizes, does that improve the user experience in any way?
WebRTC seems like a perfect candidate for UDP communications for the actual media streams.
[+] [-] mrmoka|8 years ago|reply
The goal of the topic is to explore simple option for server-client communication using low-latency communication, without reliability and without ordered delivery.
WebRTC can be used for such case, although it is not designed for it. Due to that implementation is very complex and not much adopted. This is something we trying to explore, either new API or simplifications to WebRTC to make it simple choice for UDP in server-client scenarios.
[+] [-] topranks|8 years ago|reply
With UDP you have to create your own feedback mechanism to find the optimal bitrate to stream to the far side at.
[+] [-] justsomedood|8 years ago|reply
[+] [-] feross|8 years ago|reply
WebUDP wouldn't necessarily make the situation any worse.
[+] [-] TD-Linux|8 years ago|reply
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.
[+] [-] dsl|8 years ago|reply
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.
[+] [-] mrmoka|8 years ago|reply
[+] [-] xg15|8 years ago|reply
[+] [-] trelliscoded|8 years ago|reply
At the moment, I see a lot of ridiculous stuff like phone apps talking to some cloud instance which tries to jam the packets back through your firewall into your Internet light bulbs. Congratulations, you literally just used thousands of kilometers of fiber and billions of dollars of routing infrastructure to make the world's most expensive how many... light bulb joke.
[+] [-] TD-Linux|8 years ago|reply
[+] [-] z3t4|8 years ago|reply
[+] [-] nitwit005|8 years ago|reply
I suppose you'll still need to deploy a stun/turn server to deal with the NAT issues unless you're happy with IPv6 only, but that's not really something the standard can fix.
[+] [-] mrmoka|8 years ago|reply
[+] [-] captainmuon|8 years ago|reply
I would propose having two HTML profiles in future, HTML document, and HTML application (and maybe HTML legacy). HTML document would be restricted in what you can do, and would be primarily for reading Hypertext. For HTML application you would have to go through a few clicks to install or activate it - now you are going to say that people will just click it away, but that is already the case with current desktop app installers, so it is not more insecure! An application profile page will be able to access the net just like any other native application. Most importantly, it will be able to bypass same-origin policy and send UDP and TCP anywhere - but not with credientials of course.
You'd still have the problem of being able to probe internal networks, and being able to manipulate UPnP routers. For the first, the network admin could have a group profile setting or similar to disable this kind of access. For the second, browsers could selectively block this on a case-by-case basis if needed.
For the problem of DDOS, I think we should not let that restrict us from implementing useful technologies. Rather we should fix it at the source. For example, maybe one could lock down certain routes if an attack is detected. All traffic along these routes is throttled, unless you send along a proof-of-work token. I'm just making this up, but my point is that I think we haven't exhausted all options here.
[+] [-] bewo001|8 years ago|reply
Implementing a WebRTC data channel endpoint in a server is not for the faint of heart, though. You would have to implement a lot of complex RfCs.
[+] [-] pheres|8 years ago|reply
No same-origin-policy would be lovely combined with XSS vulnerabilities.
Suddenly all the visitors of that website would be doing DDOS on a random host.
[+] [-] geocar|8 years ago|reply
WebRTC isn't very complicated.
The hardest part is probably ICE, which basically involves each point telling eachother what they see, and potentially consulting a third party (STUN/TURN). I'd love to see more magic there, but once that's in-place, I don't see what's so hard about just using DataChannels.
One idea might be to put signalling into HTTP headers, e.g. have the client and server introduce something like:
and if so, allow WebRTC to skip the ICE negotiation step if speaking to the server.[+] [-] Matheus28|8 years ago|reply
[+] [-] gafferongames|8 years ago|reply
[+] [-] znpy|8 years ago|reply
[+] [-] Matthias247|8 years ago|reply
The only way to use HTTP/QUIC for packetlike communication might be to send each packet inside a seperate HTTP request. But I guess that will have a super high overhead (lifecycle of a whole stream must be managed for a packet which actually has no lifecycle) and will most likely also not deliever the expected results (afaik HTTP on top of QUIC still has head-of-line blocking for request/stream establishment. Request headers must be received in order).
New javascript APIs which are utilizing QUIC could work. However one would need to explore if QUIC is actually helpful for target applications, since it provides a stream semantic, whereas UDP is purely packet based. QUIC might also introduce similar issues like WebRTC to the server side: It's a complex protocol spanning multiple layers (everything from flow-control to encrytion). Therefore it will be hard to integrate into environments where no QUIC library is available. But that's only a feeling, since I haven't yet reviewed the QUIC specification in detail.
[+] [-] RajuVarghese|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] LinuxBender|8 years ago|reply
Will the documentation/RFC's encourage folks to fail gracefully if UDP is not supported in their network?
Could this spec include support for SRV records? It isn't allowed in http/1.1.
[+] [-] eecc|8 years ago|reply
... /s (hopefully)
[+] [-] trelliscoded|8 years ago|reply
http://jslinux.org/
[+] [-] pdkl95|8 years ago|reply
[+] [-] nomadlogic|8 years ago|reply