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.....
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.
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.....