[tsimionescu]

Peers connect to you by opening a connection to the advertised IP(s) and port. Bots connect to you by opening a connection to the advertised IP(s) and port. How do you tell which is which?

With hole punching, at least you have some amount of mutual recognition by using the same external server, and you get some amount of DoS protection from the server itself (though of course the server will likely support many more connections than your local system).

So in the end, aren't you more secure using a hole punch method for direct connections over the internet for P2P communication, even on IPv6?

[growse]

> So in the end, aren't you more secure using a hole punch method for direct connections over the internet for P2P communication, even on IPv6?

No?

It sounds like you're reinventing authentication, badly. If you want to control which clients are permitted to access a service available, we have well-established ways of doing that. Dynamically messing around with the network and "hole-punching" is not one of them (unless you broaden that to mean VPNs, but if you want a VPN, use a VPN!). If you don't want anyone on the internet to be able to SYN/ACK to a TCP service you put on the internet, don't put it on the internet.

Also, insert standard soapbox speech here about how the contextless phrase "more secure" is meaningless. More secure against what? What's the threat or risk you're trying to control?

[tsimionescu]

First of all, this wasn't about a service on the internet, but a P2P network. I want to download and upload data over BitTorrent, or to have conversations over TeamSpeak, but that doesn't mean I want to manage my PC like a public server.

Having a public server on the path, which is what hole-punching does, helps with this, especially in the area of DDoS, since attackers first have to fool the hole-punch server before attacking any specific peer directly.

[growse]

If one peer is only allowed to talk to another peer via a centralised "hole-punching" server, it isn't p2p.

There's nothing wrong with that topology, but the very original point was about how sometimes you want p2p and IPv6 helps enormously with this. If you think p2p topologies in general are "insecure" because the peers need to be directly reachable on the internet, then that's a different argument.

[tsimionescu]

If the vast majority of traffic flows directly between peers, with only an initial handshake requiring an external server, the system is somewhere between P2P and Client/Server. Depending on your goals this may be perfectly ok (e.g. if you want P2P connectivity for routing efficiency and throughput) or completely defeat the purpose (e.g. if you want P2P connectivity for censorship resistance).