Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Conceptual design of networking fundamentally flawed?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
ManDay
Apprentice
Apprentice


Joined: 22 Jan 2008
Posts: 209

PostPosted: Wed Jan 30, 2013 7:06 am    Post subject: Conceptual design of networking fundamentally flawed? Reply with quote

I can't help it but wonder whether the current design of TCP/IP et al is, given the possibilities we have, a rather obvious misdesign.

I'm specifically thinking of NAT and address-range limitation.

Reading about it on Wikipedia, the complexity of NAT appears somewhat unlimited.

In practice, the most commonly encountered problem is possibly that of me, being given one IP-address by my ISP and using that for a NAT router (+ modem + AP).

Now it becomes impossible for others to initiate connections to one of the computers behind the NAT without me explicitly forwarding the desired port(s) to that one host (if that's not true, I'd be keen to know what other possiblities I have). In any case, I'd need to configure the router specifically for that job (same here, if that's not true...).

Taking SIP (Session Protocol for Telephony), with which I was struggling last as an example:

Given an adequate transport, it should be no problem for Host A behind the NAT to speak to the SIP Service Provider, telling it "A registering for SIP at <public IP>. I am computer X behind that public IP". Other hosts should then, theoretically, have no problem to initiate a connection on their behalf (just as if A had been given an own IP).

Given an adequate transport, the amount of IPs should be unlimited.

But intead, to the present day, I haven't got SIP to work behind a router to which I do not have admin access - although that router is in no way meant to function as a firewall whatsoever. I must frankly say, I find that a rather pathetic design, given what should be possible with just a sufficiently designed (and implemented, of course) protocol.

Am I to blame here or is this really such fundamental shortcoming in design that still couldn't be alleviated?
Back to top
View user's profile Send private message
javeree
Apprentice
Apprentice


Joined: 29 Jan 2006
Posts: 285

PostPosted: Wed Jan 30, 2013 8:34 am    Post subject: Reply with quote

You're not to blame: it's a fundamental 'flaw' in the addressing scheme. It's as if you have many peole living in a building and only a single letterbox.
You cannot blame the mailman for not delivering each letter to the individual adressee. It's up to one of the inhabitants to look at the names on the envelopes (the ports) and decide who to give the letter to. If there happen to live two people with teh same name in the building, bad luck.

Is it a flaw ? Not really if you understand NAT as a workaround for something that was not initially foreseen in the protocol. It was assumed that each PC would get its own address, and that there were enough adresses.

IPV6 is supposed to cure this, but I would not be surprised if after moving to IPv6, you would still get a modem from your ISP that does some kind of NAT (just to keep you limited in what you can do and to guide you toward a more pricey upgrade :-))
Back to top
View user's profile Send private message
ManDay
Apprentice
Apprentice


Joined: 22 Jan 2008
Posts: 209

PostPosted: Wed Jan 30, 2013 8:46 am    Post subject: Reply with quote

Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?

Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.

Edit: And in cases where the router cannot be modified, a host within the adjacent net may receive all those packages and do the forwarding to the respective hosts.
_________________
PDF for documents is misused. Use HTML!
Math markup for HTML5
GCPM for Footnotes
Back to top
View user's profile Send private message
ManDay
Apprentice
Apprentice


Joined: 22 Jan 2008
Posts: 209

PostPosted: Wed Jan 30, 2013 8:52 am    Post subject: Reply with quote

Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?

Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.
_________________
PDF for documents is misused. Use HTML!
Math markup for HTML5
GCPM for Footnotes
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8931

PostPosted: Thu Jan 31, 2013 3:05 am    Post subject: Reply with quote

ManDay wrote:
Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).
The provision is to send a SYN to the IP+port pair representing the recipient. If the recipient does not have a publicly recognized IP+port pair, then the recipient cannot directly receive unsolicited traffic. This is a fundamental limitation of NAT. If the recipient takes actions which allow the NAT device to expect a response, then the NAT will route those responses.
ManDay wrote:
Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.
Could you explain why you think either TCP or IP is to blame here? Your ISP has intentionally supplied you with a broken configuration (one address, multiple machines), and now protocols which expect a working configuration (each Internet connected machine has a publicly unique address) fail. Adding another address within the frame is an ugly hack. Assigning a properly routable address at the IP layer is the correct solution. That is exactly what IPv6 promises to do.
ManDay wrote:
So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?

Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.

Edit: And in cases where the router cannot be modified, a host within the adjacent net may receive all those packages and do the forwarding to the respective hosts.
This is a terrible idea. Although NAT is not designed to act as a firewall, many users have come to rely on that behavior. Providing a way for external hosts to intentionally access specific internal machines breaks that assumption. Many users do not adequately firewall their internal machines, because they believe the edge device will keep them safe.
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Thu Jan 31, 2013 8:48 am    Post subject: Reply with quote

Quote:
Now it becomes impossible for others to initiate connections
to one of the computers behind the NAT without me explicitly
forwarding the desired port(s) to that one host


That is a feature, in my view. The last thing I want is external machines
being able to contact my workstation directly on their initiative. My cpu
load for iptables would be through the roof.

We don't typically see it on Linux, because our workstations do not
pop up windows whenever some remote host probes us with a udp
packet. I was helping someone with a new XP installation on a laptop
that had AOL installed and a dialup modem, however. The first time
he logged in, popups showed that probe packets from remote
spamhosts were coming several times a second, on all manner of
ports. (Finally I got zonealarm installed on it, blocked all that stuff,
and told it to lose the alerts on remotely initiated connect attempts,
which provided some relief.)

If I connect to a remote server first and expect an ack, that is a different
situation. The incoming packets are not unsolicited.

When I first read the IPv6 address spec in an RFC, it seemed like it
had a "DOS memory hole" in the address space, meaning that the
address bits in the IPv6 address were not contiguous. WTF?

Why not put the metadata for the packet at one end and the address
bits at the other? If we need to add more metadata for some as yet
unknown purpose, add another octet or two at that end, and if we need
more address space, add another octet at the other end.

Seemed obvious.
_________________
TIA
Back to top
View user's profile Send private message
Ant P.
Advocate
Advocate


Joined: 18 Apr 2009
Posts: 2333
Location: UK

PostPosted: Thu Jan 31, 2013 10:35 am    Post subject: Reply with quote

wcg wrote:
Quote:
Now it becomes impossible for others to initiate connections
to one of the computers behind the NAT without me explicitly
forwarding the desired port(s) to that one host


That is a feature, in my view. The last thing I want is external machines
being able to contact my workstation directly on their initiative. My cpu
load for iptables would be through the roof.

If you're concerned about TCP RST packets becoming an extreme CPU load on your PC, maybe it's time to upgrade it to something faster than that 100MHz router that's currently handling the same load for your entire LAN...
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Thu Jan 31, 2013 1:08 pm    Post subject: Reply with quote

Quote:
100MHz router that's currently handling the same load for your entire LAN


Right now my cpu load for iptables is microscopic, because the router is handling
all (ok, most; there are a couple of windows machines on the lan; when they get
cracked is unpredictable) of those unsolicited packets in hardware. Why throw away
cpu cycles on my workstation so that I can use a dumber router, no matter how
many cpu cycles it has to spare?
_________________
TIA
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9011
Location: beyond the rim

PostPosted: Fri Feb 01, 2013 10:21 am    Post subject: Reply with quote

ManDay wrote:
Thanks for reassuring me that this is not a mistake on my side. Going with the "letterbox" analogy (which, perhaps, you did not mean to go as far), the mailman *does* have means to "initiate" connections to the inhabitants. The inhabitant does not "reserve" himself a box in advance (as with forwarding ports).

The letterbox was an analogy for an IP address, not a port, but it's a bad analogy anyway.

Quote:
Equally, where is the problem in contriving a protocol within the TCP/IP frame (assuming we don't want to "fix" TCP/IP - which appears to be the actual thing that should be done) which allows to identify each host in the adjacent network by yet another unique ID.

TCP/IP has been "fixed" for that problem in the way of IPv6, however it's taking a long time for that to be rolled out (for various reasons). Changes to network protocols are a very sensitive subject due to the number of involved parties.

Quote:
So the TCP/IP is adressed at 1.2.3.4 and (again, unfamilar with the exact specs of TCP/IP, assuming that there is no way to convey the following information as part of the TCP/IP header) specifying, in a nested protocol, that the package is meant to go to a computer identified by an ID unique to the adjacent net, say 192.168.1.2 or "mandayPC"?

Of course, the router's firmware would need to be patched, but this would be the smallest of all problems.

The router firmware, the server OS, the client OS, and that for anyone/anything potentially using that extension. You start to see the not-so-small deployment problem now? Not even thinking about compability issues, added complexity causing more problems, special case handling, ....
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum