4 ms·

TCP gives you a superset of information than what you get with UDP, so consequently you get a superset of options. There is no method of nat punching that will

TCP gives you a superset of information than what you get with UDP, so consequently you get a superset of options. There is no method of nat punching that will work on UDP that will not work on TCP. The reverse is not true.

JoeAltmaier 13y ago
It works; its just far more complicated. Because its not about the IP stack at all. Its about the routers/firewalls and NAT. It goes something like this. Something called 'pinholes' are created in your router - a map between an internal address-triplet (IP:Port:Protocol) and an external address-triplet. Messages arriving from one are mapped to the other and forwarded. In addition, a third address-triplet can be used to guard against port-scanning and malicious bots etc. It's used on external (public) packets to test the Source of the packet. Its built from the 1st packet send out that created the NAT entry, from the public address target of that packet. In other words, incoming traffic is only translated and forwarded to your computer/port if it came from somebody you previously SENT a packet to, such that your NAT entry has that address as its 'filter' triplet. UDP can send arbitrary packets to anybody. TCP MUST start with a connection exchange where a client first tries to contact a server. But in our case we want them to be peers; both 'clients'. So, TCP 'pinhole' creation involves both clients simultaneously attempting to open a socket to each other. Both clients must be prepared to accept (listen) for that attempt. Initially each outgoing client connection attempt may be rejected by the peer's router - if it hasn't previously attempted to talk back to that peer yet, there is no NAT entry with a matching filter triplet. It has to be nearly simultaneous because TCP connection retry can be large, and it takes a minimum of 2 tries (one to create the NAT entry but fail arriving at the peer, the 2nd MAY succeed if the peer has also created a NAT entry at exactly the same time). Add to that, learning your public address Requires contacting some STUN/ICE style public server, which creates your NAT entry but marks it with the STUN server filter triplet. So the peer connection is actually a 2nd attempt to create a pinhole. If your router doesn't overwrite that NAT entry's STUN triplet with the peer triplet, or create a multi-way associative table entry, or incompletely updates the triplet (IP but not port or IP/Port but not protocol) then the peer's incoming client-connect will be rejected anyway. Since port-scanning and malicious bots are not in any way an official protocol, every router manufacturer invents their own algorithm for defending against them. There is no guarantee that any particular NAT-pinhole-creation technique will work every time with any particular router. So no, TCP isn't really a superset; in a real way its a much more restricted set, and p2p TCP works far less often in practice than UDP. Because for UDP you control every packet, and send to exactly the addresses in exactly the order you wish. So you have far more control over the initial exchange content and timing, and thus have more control over pinhole creation.
- einhverfr 13y ago
  It is not more complicated. Let me repeat: Anything you can do to make UDP work will make TCP work. The problem with NATs is that if you are behind one, you are not at your supposed public IP address. This means effectively you have two options: 1. Forward all packets that come in on a specific port to a specific machine, or 2. Forward all packets that come in that are on an established connection to a specific machine. Both work with TCP. The latter works with TCP but not UDP because as you point out UDP doesn't have the concept of an established connection. So basically you can look at host/port, or you can look at host/port/status. The former works for both. The latter works only for TCP, or by a NAT which understands your connection syntax (e.g. an H.323 gatekeeper, though this is iirc TCP). > So no, TCP isn't really a superset; in a real way its a much more restricted set My point is the router has a superset of information to address things in TCP, so anything you do to make UDP work will work if you do the same for TCP. You have a superset of options on a pure networking level. I think what you are arguing is something else, because you say: "Since port-scanning and malicious bots are not in any way an official protocol, every router manufacturer invents their own algorithm for defending against them." In other words, it is not that TCP NATting doesn't give you a superset of options, it is that routers are typically configured to address these issues by being a lot more lenient on UDP packets than TCP packets. However, this in no way addresses the question as to how things work on a pure network level. In other words, as I understand your complaint, it is not that TCP doesn't support a superset of natting options relative to UDP, but rather that NATs/routers are more permissive regarding UDP packets because they try to restrain TCP packets to a much larger extent. If that is indeed your position then I think it is worth bringing up with routers as well. If routers and nats are natting purely based on the port on the router, and not the IP address/port of the router, then there is significant room for better security there.....
  - JoeAltmaier 13y ago
    I was being entirely practical, not theoretical. In a theoretic (non-existant) internet then TCP/UDP can work similarly. But in the internet as deployed in the world, TCP is very hard to get through a P2P connection, and works infrequently. Because of firewalls and routers.

JoeAltmaier 13y ago

It works; its just far more complicated. Because its not about the IP stack at all. Its about the routers/firewalls and NAT. It goes something like this. Something called 'pinholes' are created in your router - a map between an internal address-triplet (IP:Port:Protocol) and an external address-triplet. Messages arriving from one are mapped to the other and forwarded. In addition, a third address-triplet can be used to guard against port-scanning and malicious bots etc. It's used on external (public) packets to test the Source of the packet. Its built from the 1st packet send out that created the NAT entry, from the public address target of that packet. In other words, incoming traffic is only translated and forwarded to your computer/port if it came from somebody you previously SENT a packet to, such that your NAT entry has that address as its 'filter' triplet. UDP can send arbitrary packets to anybody. TCP MUST start with a connection exchange where a client first tries to contact a server. But in our case we want them to be peers; both 'clients'. So, TCP 'pinhole' creation involves both clients simultaneously attempting to open a socket to each other. Both clients must be prepared to accept (listen) for that attempt. Initially each outgoing client connection attempt may be rejected by the peer's router - if it hasn't previously attempted to talk back to that peer yet, there is no NAT entry with a matching filter triplet. It has to be nearly simultaneous because TCP connection retry can be large, and it takes a minimum of 2 tries (one to create the NAT entry but fail arriving at the peer, the 2nd MAY succeed if the peer has also created a NAT entry at exactly the same time). Add to that, learning your public address Requires contacting some STUN/ICE style public server, which creates your NAT entry but marks it with the STUN server filter triplet. So the peer connection is actually a 2nd attempt to create a pinhole. If your router doesn't overwrite that NAT entry's STUN triplet with the peer triplet, or create a multi-way associative table entry, or incompletely updates the triplet (IP but not port or IP/Port but not protocol) then the peer's incoming client-connect will be rejected anyway. Since port-scanning and malicious bots are not in any way an official protocol, every router manufacturer invents their own algorithm for defending against them. There is no guarantee that any particular NAT-pinhole-creation technique will work every time with any particular router. So no, TCP isn't really a superset; in a real way its a much more restricted set, and p2p TCP works far less often in practice than UDP. Because for UDP you control every packet, and send to exactly the addresses in exactly the order you wish. So you have far more control over the initial exchange content and timing, and thus have more control over pinhole creation.

einhverfr 13y ago
It is not more complicated. Let me repeat: Anything you can do to make UDP work will make TCP work. The problem with NATs is that if you are behind one, you are not at your supposed public IP address. This means effectively you have two options: 1. Forward all packets that come in on a specific port to a specific machine, or 2. Forward all packets that come in that are on an established connection to a specific machine. Both work with TCP. The latter works with TCP but not UDP because as you point out UDP doesn't have the concept of an established connection. So basically you can look at host/port, or you can look at host/port/status. The former works for both. The latter works only for TCP, or by a NAT which understands your connection syntax (e.g. an H.323 gatekeeper, though this is iirc TCP). > So no, TCP isn't really a superset; in a real way its a much more restricted set My point is the router has a superset of information to address things in TCP, so anything you do to make UDP work will work if you do the same for TCP. You have a superset of options on a pure networking level. I think what you are arguing is something else, because you say: "Since port-scanning and malicious bots are not in any way an official protocol, every router manufacturer invents their own algorithm for defending against them." In other words, it is not that TCP NATting doesn't give you a superset of options, it is that routers are typically configured to address these issues by being a lot more lenient on UDP packets than TCP packets. However, this in no way addresses the question as to how things work on a pure network level. In other words, as I understand your complaint, it is not that TCP doesn't support a superset of natting options relative to UDP, but rather that NATs/routers are more permissive regarding UDP packets because they try to restrain TCP packets to a much larger extent. If that is indeed your position then I think it is worth bringing up with routers as well. If routers and nats are natting purely based on the port on the router, and not the IP address/port of the router, then there is significant room for better security there.....
- JoeAltmaier 13y ago
  I was being entirely practical, not theoretical. In a theoretic (non-existant) internet then TCP/UDP can work similarly. But in the internet as deployed in the world, TCP is very hard to get through a P2P connection, and works infrequently. Because of firewalls and routers.