TCP/UDP firewalls and routing idea

[padren]

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

[khaled]

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 March 7, 2012 by khaled

[Cap'n Refsmmat]

This idea sounds a bit like IGDP:

 

https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protocol

 

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.