On 7/18/06, Ivan Arce <[EMAIL PROTECTED]> wrote:
- Usually, use of UDP makes your application "firewall unfriendly". Most firewalls (all?) implement stateful inspection/filtering these days.
UDP is often a more reliable way to get through NAT without requiring the user to set up port forwarding. For many transfers, LimeWire is forced to fall back on UDP (with application-layer connection and congestion management) because both parties in the transfer are behind home NAT boxes without port forwarding or IP PnP.
For than the firewall can rely on a set of features of TCP itself (the state machine, ACK/seq numbers, etc). Int he case of UDP, a filtering firewall will only have the source and destination port fields data usable to track state (which are easily guessable or brute forceable 16bit values).
What is the threat model here? You want to punch a hole in your firewall to allow P2P access, but only for known trusted IPs? Ideally, all traffic would be restricted to trusted hosts, but for general purpose web traffic and general purpose P2P traffic, I don't think this is realistic. Your efforts are probably better spent code-reviewing your P2P application and allowing arbitrary IP addresses to contact your P2P app and implementing strong sanity checks and a strong security policy at the application layer. Presumably, one would use cryptographic message authentication codes, or at the very least some cryptographic way of getting some level of assurance that the sender can receive UDP packets on the given port (like Gnutella's QueryKeys), right? IMHO, it's really a question of if you need in-order and reliable delivery. If you're doing real-time audio and/or video, you probably want to do without the TCP overhead and would actually rather drop missed frames rather than delay newer frames while re-transmitting. Note also that many DHTs use UDP because the latency involved in TCP's 3-way handshake is rather large compared to the time required to send small messages used by the DHT. Parallel redundant lookup is also useful in many DHT implementations, so losing some reasonable percentage of the messages doesn't represent a problem. Cheers, -Karl _______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
