4 ms·

> What he really wants is a connection-oriented, TCP-like protocol with more flexible handling of missing/delayed packets. (As this is a frequent use-case in ga

> What he really wants is a connection-oriented, TCP-like protocol with more flexible handling of missing/delayed packets. (As this is a frequent use-case in game development). What I really want is the most UDP-like thing possible in the browser, that lets people build whatever higher level protocol they want on top of it, just like game developers do on every other platform. Being connection based is important because if it wasn't then it would quickly turn into a DDoS tool, or a security nightmare for probing internal networks for vulnerabilities. So clearly it needs to be connection based. And if it needs to be connection based, then that rules out broadcast packets too.

irq-1 10y ago
Would a clear-text token, in addition to an encrypted connect token, allow servers to drop packets faster (since it wouldn't require decryption)? A clear token could be changed (cached, expired) however the back-end wanted, which would include dropping all new connection attempts when under DDOS. I didn't see a port number anywhere. Shouldn't you define 443/UDP (or other) as the only connection port? This would allow networks to manage the traffic, for example dropping all UDP/443 traffic internally, or managing bandwidth at a firewall. Finally, shouldn't P2P be in the mix? If not now, won't we be doing this again in a few years? Thanks for taking on such a big challenge, and for listening to the peanut gallery.
- gafferongames 10y ago
  I actually do stuff like this, in the connection request packet a mix of "additional data" protected by the AEAD as well as encrypted data (keys), allows me to quickly reject stale tokens because the expire timestamp is public, but protected with signature check, vs. having to fully decrypt first to see the token is stale. I don't have any defined port because in the game industry we tend to run multiple game servers on the same box, so we take up a bunch of ports. I acknowledge that this could cause issues with corporate firewalls, and would be open to ideas how to solve this. Regarding P2P, I think WebRTC solves the problem of browser to browser communication just fine. Any attempt to support p2p this would just end up rewriting WebRTC. What I'm trying to do is solve just one small part of the problem, in a WebSockets like way, just one thing that would enable a lot of other cool things to be built on it, if it were adopted by browsers. cheers
  - irq-1 10y ago
    > quickly reject stale tokens because the expire timestamp is public, but protected with signature check A forged timestamp would still need a signature check, but a clear-text token would not. The speed difference would only be important with a flood of forged packets, each of which would need to have it's signature checked. Additionally, each system could implement a different type of defense: like issuing regional clear-text tokens, or A/B tokens to find which account is leaking a clear-text token, or giving each server it's own token so a DDOS attempt that wanted to force signature checks would need to get the right token (and get it again when an attacked system changes it.) Hosting providers that offer DDOS protection today could offer integrations based on clear-text tokens that wouldn't need any interaction from a game system (other than submitting the clear-text tokens.) I don't know if routers typically have the ability to check a signature, but they can probably drop packets that don't pass a (clear-text token) mask check. The port issue is interesting. Maybe a range of ports (44300-45100) would work for network administrators. Maybe there should be restrictions and a listing of uses like the first 1024 (this is voice, that port's video, file transfer, etc...) Browsers should also limit connections. Only 2 connections/IPs at a time? Only JavaScript from the origin domain (the address in the URL) can open connections, not advertisements or iframes. Maybe ask the user to open connections like browsers ask to use your location or audio/video. I wonder too if a browser should only open a connection when presented with a request signed using the (private) domain SSL cert? That would drastically reduce the ability of bad JavaScript to co-opt browsers of a website (into a DDOS of connection requests.) To use a websites traffic for a DDOS, you would need the SSL keys. Browsers could also be required to add the domain and verified domain sig to a connection request, so a website that cause a DDOS would be identified. I'm not sure identifying the website would lead to accountability since they may have been compromised, but it would prove which domain caused a browser based DDOS; reddit.com couldn't claim a bad advertisement caused their millions of browsers to open connections. This wouldn't stop forged packets, but it should stop innocent web-browsers from becoming a tool for DDOS.
BuuQu9hu 10y ago
Don't worry about mitigating DDoS beyond not exposing amplification weaknesses. At the end of the day, DDoS is an economic problem, not a technical one; it crucially hinges on scarcity of bandwidth. It's not your problem to solve. I understand that you love UDP and I won't try to move you on that. But can we avoid browsers? They're basically the worst things ever.
- gafferongames 10y ago
  Please list the DDoS concerns you have with the proposal and I'm happy to discuss them.
stcredzero 10y ago
You write that the big disadvantage of WebRTC is the complexity. There is a nice library named simple-peer that hides all of that. Using that and node-electron, I implemented a small server cluster that acts as a UDP to WebRTC proxy for my game. This gives you encryption and connection orientation. See my other comment for the downsides: https://news.ycombinator.com/item?id=13745055 https://news.ycombinator.com/item?id=13745055

irq-1 10y ago

Would a clear-text token, in addition to an encrypted connect token, allow servers to drop packets faster (since it wouldn't require decryption)? A clear token could be changed (cached, expired) however the back-end wanted, which would include dropping all new connection attempts when under DDOS. I didn't see a port number anywhere. Shouldn't you define 443/UDP (or other) as the only connection port? This would allow networks to manage the traffic, for example dropping all UDP/443 traffic internally, or managing bandwidth at a firewall. Finally, shouldn't P2P be in the mix? If not now, won't we be doing this again in a few years? Thanks for taking on such a big challenge, and for listening to the peanut gallery.

gafferongames 10y ago
I actually do stuff like this, in the connection request packet a mix of "additional data" protected by the AEAD as well as encrypted data (keys), allows me to quickly reject stale tokens because the expire timestamp is public, but protected with signature check, vs. having to fully decrypt first to see the token is stale. I don't have any defined port because in the game industry we tend to run multiple game servers on the same box, so we take up a bunch of ports. I acknowledge that this could cause issues with corporate firewalls, and would be open to ideas how to solve this. Regarding P2P, I think WebRTC solves the problem of browser to browser communication just fine. Any attempt to support p2p this would just end up rewriting WebRTC. What I'm trying to do is solve just one small part of the problem, in a WebSockets like way, just one thing that would enable a lot of other cool things to be built on it, if it were adopted by browsers. cheers
- irq-1 10y ago
  > quickly reject stale tokens because the expire timestamp is public, but protected with signature check A forged timestamp would still need a signature check, but a clear-text token would not. The speed difference would only be important with a flood of forged packets, each of which would need to have it's signature checked. Additionally, each system could implement a different type of defense: like issuing regional clear-text tokens, or A/B tokens to find which account is leaking a clear-text token, or giving each server it's own token so a DDOS attempt that wanted to force signature checks would need to get the right token (and get it again when an attacked system changes it.) Hosting providers that offer DDOS protection today could offer integrations based on clear-text tokens that wouldn't need any interaction from a game system (other than submitting the clear-text tokens.) I don't know if routers typically have the ability to check a signature, but they can probably drop packets that don't pass a (clear-text token) mask check. The port issue is interesting. Maybe a range of ports (44300-45100) would work for network administrators. Maybe there should be restrictions and a listing of uses like the first 1024 (this is voice, that port's video, file transfer, etc...) Browsers should also limit connections. Only 2 connections/IPs at a time? Only JavaScript from the origin domain (the address in the URL) can open connections, not advertisements or iframes. Maybe ask the user to open connections like browsers ask to use your location or audio/video. I wonder too if a browser should only open a connection when presented with a request signed using the (private) domain SSL cert? That would drastically reduce the ability of bad JavaScript to co-opt browsers of a website (into a DDOS of connection requests.) To use a websites traffic for a DDOS, you would need the SSL keys. Browsers could also be required to add the domain and verified domain sig to a connection request, so a website that cause a DDOS would be identified. I'm not sure identifying the website would lead to accountability since they may have been compromised, but it would prove which domain caused a browser based DDOS; reddit.com couldn't claim a bad advertisement caused their millions of browsers to open connections. This wouldn't stop forged packets, but it should stop innocent web-browsers from becoming a tool for DDOS.

BuuQu9hu 10y ago

Don't worry about mitigating DDoS beyond not exposing amplification weaknesses. At the end of the day, DDoS is an economic problem, not a technical one; it crucially hinges on scarcity of bandwidth. It's not your problem to solve. I understand that you love UDP and I won't try to move you on that. But can we avoid browsers? They're basically the worst things ever.

gafferongames 10y ago
Please list the DDoS concerns you have with the proposal and I'm happy to discuss them.

stcredzero 10y ago

You write that the big disadvantage of WebRTC is the complexity. There is a nice library named simple-peer that hides all of that. Using that and node-electron, I implemented a small server cluster that acts as a UDP to WebRTC proxy for my game. This gives you encryption and connection orientation. See my other comment for the downsides: https://news.ycombinator.com/item?id=13745055 https://news.ycombinator.com/item?id=13745055