Jump to content

TCP/UDP firewalls and routing idea


Recommended Posts

I'm curious if this general approach would be viable for UDP management:


Overview of current technology:


Long story short, it's pretty easy to open TCP connections (such as HTTP for web viewing) and have routers automatically ensure each system behind it can send and then receive data all properly addressed. All this is pretty much automatically handled between the browser, client systems, router, firewall, and the ultimate destination server without causing problems very often at all.


Being able to have multiple clients send UDP data through a router to a server is a configuration nightmare most of the time: they don't operate in streams, so they don't maintain connections, and you usually have to set specific ports to forward to specific client systems within the local network just to get any traffic to work at all.


Proposed solution:


If an industry standard could be established, I want to know if it is possible to setup a "standardized handshake exchange" over TCP in which a client requests a "clear UDP route" to the server, and the server responds with it's own parameters, and then they agree to the mutual set of data. Basically the client sends "Hey server, I want you to send me UDP data here on port [x]" and the server says "sure, they'll come from this range of IPs, on this range of ports, and if no traffic comes through in [x] amount we'll both agree the route has expired"


The handshake only exists to exchange any dynamic parameters (like port numbers, etc) between the client/server, but mostly so the firewall/router layers within the network can eavesdrop (which is how they route data with TCP/HTTP now, iirc) and create a temporary "port forwarding entry" and actually know how to route UDP data, and how long to maintain the exception.


The key difficulty I see is that firewall and router producers would have to implement the standard, and the only way to test if a route is successful is to "try" and send data via UDP. One firewall admin may have a different idea of what is an acceptable range of remote IPs to accept UDP data from or how long it can last idle before expiration. While these can be rejected and logged in some capacity, it makes determining the reason for rejecting the "port forwarding entry" at the firewall level somewhat difficult.


Lastly, there's the issue that whatever server you are connecting to and wanting UDP data from.... has to be designed to handle both TCP and UDP data, and ensure each remote client's total handshake data is managed. Some layer has to talk via TCP to get the port info of the client for instance, so the UDP layer can use it to communicate.





Is this a viable idea?

Did I miss solutions that already exist?

Did I use entirely too many words?


Btw - nice to be back on the forums, hopefully I'll be around more :)

Link to comment
Share on other sites

I'm not good in Networks, but I think you should learn more about the philosophy of Network models and the Internet


Because Computer Networks are built based on concepts such as Layering Concept (a concealed layer that offer services), Encapsulation


Concept (information are manipulated directly only through inside methods), Communication Theory (how humans communicate and its


randomness), Entropy Theory, Entity Independence Philosophy (building a system where every entity have independency "that it can functions


even when it's alone"), and the concept of mono-module entities (something is built just for one single job, in a system of these entities


maintenance, performance, and effectiveness can be high).




So, what I'm trying to say is, one should understand the ideas behind the technical details of these systems, instead of trying to


improve these systems from the technical side which might break its philosophy.




So, here is a simple way to try .. Try to design a method so that a group of humans can communicate in an effective way


-- Good Luck

Edited by khaled
Link to comment
Share on other sites

This idea sounds a bit like IGDP:




IPv6 will hopefully reduce the need for this. ISPs will be able to assign large blocks of IP addresses to individual customers, and so each client behind the router can get their own public IP. The router won't have to worry about port forwarding and NAT, since servers can address each of them individually.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.