3 ms·

In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy. The two biggest use cases

by nikanj 4y ago

In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy. The two biggest use cases for direct p2p connections are multiplayer games and video calling. Latency is unavoidable if your traffic has to bounce around a third-party

throwaway894345 4y ago
> In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy. Not at all--end-to-end encryption is still a very desirable property. I certainly don't want a consumer router decrypting my browser traffic even if it is re-encrypting it to send to my device. I'll tolerate HTTP proxies on the server side when I'm administering the proxy and I need layer 7 routing, but I want to avoid it wherever possible. > The two biggest use cases for direct p2p connections are multiplayer games and video calling. You still have to punch a hole in your firewall either way. The only advantage ipv6 has is that you can have two hosts listening on the same port (whereas port-forwarding in a NAT context only works for 1-host-per-port). Tangentially, I was never a big fan of player-hosted games anyway because they tended to be more vulnerable to cheating and the host always had an unfair advantage (or else a dramatic penalty in the case of lag compensation). Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit (although a poorly written game server might still do just that).
- _carbyau_ 4y ago
  I love player hosted gaming. But the people I game with are looking for "fun experiences" (kinda like going to a movie as a group, but more interactive) rather than competitively climbing a leaderboard. Different use cases beget different requirements.
- anthropodie 4y ago
  > You still have to punch a hole in your firewall either way. No you don't have to do hole punching.
  - zekica 4y ago
    You have to do hole punching, but with IPv6, you just send packets from both ends to each other and it just works. With IPv4 it is much much harder.
  - throwaway894345 4y ago
    How do you have a direct connection between peers without one of them allowing ingress?
- aaaaaaaaaaab 4y ago
  >Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit What prevents you from putting the same validation logic into the client, thus rejecting malicious packets at the destination?
  - throwaway894345 4y ago
    I mean, correct validation logic is always ideal, but I'm positing a world in which software doesn't always get intentional validation logic. In particular, an intermediate server might prevent packets from flowing to the target client for any number of reasons which aren't intended as "validation". It's just harder to hack through an intermediary.
    - aaaaaaaaaaab 4y ago
      Ok, but I still don't see why you can't move that intermediary to the client. Spin up a docker container and run the game server there. Ta-da! You have the same security as with a remote server. My point is that IPv6 restoring the end-to-end principle need not jeopardise the - real or perceived - security of multiplayer games.
      - throwaway894345 4y ago
        It’s not clear to me who “you” is meant to refer to in this scenario. If “you” refers to the user, then because the game isn’t architected to have a server running next to each client if the server binary is even distributed to users at all. If “you” refers to the game publisher, then because they aren’t architecting it that way to begin with, because they aren’t thinking about running the server as a security feature. Moreover, a game developer has incentives to protect its own servers; it has much less incentive to protect its end users. You might argue that it’s end users being hacked is bad for business, but most end users wouldn’t be able to attribute a hack to a particular piece of software or infrastructure if they even know they’re hacked in the first place (consider the rampant insecurity in the consumer router and iot spaces).

by nikanj 4y ago

throwaway894345 4y ago

> In most cases no, but then again in most cases you would be perfectly happy with all your traffic going through a http(s) only proxy. Not at all--end-to-end encryption is still a very desirable property. I certainly don't want a consumer router decrypting my browser traffic even if it is re-encrypting it to send to my device. I'll tolerate HTTP proxies on the server side when I'm administering the proxy and I need layer 7 routing, but I want to avoid it wherever possible. > The two biggest use cases for direct p2p connections are multiplayer games and video calling. You still have to punch a hole in your firewall either way. The only advantage ipv6 has is that you can have two hosts listening on the same port (whereas port-forwarding in a NAT context only works for 1-host-per-port). Tangentially, I was never a big fan of player-hosted games anyway because they tended to be more vulnerable to cheating and the host always had an unfair advantage (or else a dramatic penalty in the case of lag compensation). Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit (although a poorly written game server might still do just that).

_carbyau_ 4y ago
I love player hosted gaming. But the people I game with are looking for "fun experiences" (kinda like going to a movie as a group, but more interactive) rather than competitively climbing a leaderboard. Different use cases beget different requirements.
anthropodie 4y ago
> You still have to punch a hole in your firewall either way. No you don't have to do hole punching.
- zekica 4y ago
  You have to do hole punching, but with IPv6, you just send packets from both ends to each other and it just works. With IPv4 it is much much harder.
- throwaway894345 4y ago
  How do you have a direct connection between peers without one of them allowing ingress?
aaaaaaaaaaab 4y ago
>Moreover, it's much easier to send a malicious packet directly to another player than it would be to send it to the server and convince the server to proxy it through bit-for-bit What prevents you from putting the same validation logic into the client, thus rejecting malicious packets at the destination?
- throwaway894345 4y ago
  I mean, correct validation logic is always ideal, but I'm positing a world in which software doesn't always get intentional validation logic. In particular, an intermediate server might prevent packets from flowing to the target client for any number of reasons which aren't intended as "validation". It's just harder to hack through an intermediary.
  - aaaaaaaaaaab 4y ago
    Ok, but I still don't see why you can't move that intermediary to the client. Spin up a docker container and run the game server there. Ta-da! You have the same security as with a remote server. My point is that IPv6 restoring the end-to-end principle need not jeopardise the - real or perceived - security of multiplayer games.
    - throwaway894345 4y ago
      It’s not clear to me who “you” is meant to refer to in this scenario. If “you” refers to the user, then because the game isn’t architected to have a server running next to each client if the server binary is even distributed to users at all. If “you” refers to the game publisher, then because they aren’t architecting it that way to begin with, because they aren’t thinking about running the server as a security feature. Moreover, a game developer has incentives to protect its own servers; it has much less incentive to protect its end users. You might argue that it’s end users being hacked is bad for business, but most end users wouldn’t be able to attribute a hack to a particular piece of software or infrastructure if they even know they’re hacked in the first place (consider the rampant insecurity in the consumer router and iot spaces).