begin quoting Andrew Lentvorski as of Sat, Apr 08, 2006 at 04:57:08PM -0700: > Stewart Stremler wrote: > > >Only two downsides: (a) no ephermeral server ports on the 'Net, and > >(b) user-selectable server ports. But I see those as an application > >issue, and a _good_ thing. > > And what happens when two users both specify port 4000?
You do the same thing you do when there's a protocol conflict, or when you're on a multi-user system: you tell one of the users/programs "No, you _will_ use a different port." > What happens > when you have 8 dedicated ports and now you have a 9th user. You add a 9th dedicated port. I suspect where you're going is that you have in mind a limited NAT box, that can _only_ provide 8 pass-through ports. But this runs up against the same problem as a firewall, that can only pass through 8 connections, or have 8 iptables/ipchains/ipf rules, etc -- artificial limitations of one configuration don't necessarily indicate a flaw in the underlying approach. > Presumably you oppose DHCP as well. Why use ephemeral IP addresses when > we can just configure the hosts with fixed addresses? I'll pass. Oppose? For server machines, yes. For client machines, like laptops, DHCP is fine. (Also if you're trying to configure a large network automatically, without having to go to every machine to set the IP address, DHCP can be useful.) I _chose_ to spend a little extra money to get a pair of fixed ip addresses; even though I've helped people set up the DHCP-DNS dance, I didn't want to mess around with that myself. Not all possible solutions are necessarily a good idea, even if they are rather clever. > The problem is that you are conflating NAT with firewall. No, I'm not. But you're close. The problem is that you think I am. > I want an > application-level traversable NAT, period. I'm not asking you to open > ports on your firewall. I'm not asking you to allow traffic that you > don't want. If you want your firewall to block this, fine. I have no > problem with that. Once my firewall blocks your service, what does the rest of it matter? > However, you are arguing that NAT should never be traversable by > applications. Your same arguments of "should be user configurable" > argue against this. I'm trying to say (and not well, it seems) that any pain suffered by making NAT work with a reasonable protocol is _exactly_ _the_ _same_ _pain_ as making that protocol work with a default-deny protocol: you have to go poke the device to say "let connections through to _this_ machine at _this_ port". Consequently, NAT is just one extra step, or, if you have your firewall assume the responsibility, it's not even that. Complaints about NAT making things too hard to accomplish $FOO are so much smoke -- if taking that extra step to make NAT work is Too Much Effort, then it's also Too Much Effort to make it work with a firewall. > I'm not asking to take any control away from you. But you are asking to > take control away from *me*. No, I'm not. On your end of the connection, it's your network. On my end of the connection, it's _mine_. *I* get to set local policy, not you. (Likewise, I don't get to set _your_ local policy, and it's wrong of me to try.) > You can rail against this all you want. However, history shows that if > you don't provide a good solution for what people demand *now*, a bad > solution will arise and then you will have to live with it. Yes, I know, and I agree that workarounds will defeat otherwise well-meaning policies -- just look at all the crap that's getting shoved over port 80. We're moving towards a world where we HAVE to set up a stateful stream-inspecting firewall, or outright proxies. [snip] > Or worse, if people don't fix this NAT traversal problem soon, TCP > traffic will start to fall and be replaced with UDP. People will create > myriad different, incompatible, buggy replacements for TCP that run over > UDP. And UDP doesn't have to respect the TCP congestion algorithms. It > can be a bad citizen. Um.... No. UDP uses the same kind of 5-tuple that TCP uses, so you poke it through the firewall or a NAT box the same way -- with ports. Shifting to UDP doesn't get around the "problem". And UDP packets are dropped before TCP packets anyway. (I suppose that might result in lots more retries and resends, because acknowledgements won't get through... but any router that has a congestion problem has an easy solution: drop more UDP packets. No more congestion.) > All that would have to happen is for *one* BitTorrent application to > switch to a pure UDP solution that requires no user configuration of > ports and 25-30% of all Internet traffic would from switch from TCP to > UDP in *days*. Look how fast traffic encryption got picked up by > BitTorrent. I thought most of the Internet traffice was DNS, SMTP, and HTTP... when did BitTorrent become a major player? I think TCP will be suprisingly hard to kill. > After that, someone will get the bright idea to strap this into Apache > and Firefox because UDP traffic gets around traffic shaping by your ISP > because it looks like XBox Live, et al. Game over. TCP dies. Actually, I think there should be an HTTP-UDP service. It would be amusing. And your ISP would shortly implement traffic shaping if they found it needful. Life goes on. > The only thing stopping this is that designing a TCP replacement has > quite a bit of complexity (just ask the Nintendo DS wireless networking > guys <heh>). However, it only takes *one* good hacker to solve the > problem. After that, it all falls like dominoes. TCP is hard to replace ... you end up implementing something that looks an awful lot like TCP. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
