begin quoting Andrew Lentvorski as of Sun, May 21, 2006 at 03:19:50AM -0700: > Stewart Stremler wrote: > > >>our misery. But NAT is really only detrimental to the end-users and does > > > >...who use software written by incompetent and/or lazy programmers... > > You can keep saying that all you want, Stewart. Heh. I think I failed to follow up the last time we discussed this (damn life getting busy), and here this topic is being raised again. Apologies for not following that up.
> You are still wrong. 'Lazy programmers' in that they don't provide a way for me to spcify the IP address to be broadcast and the port number to use. Calling me wrong doesn't make 'em any less lazy. You're so caught up in doing it your own way, you're determining the choices the owners and the users get to make without consulting them. You're implying that the network belongs to the developers, not to the local policy-makers. > Just because you are incapable of conceiving of why people want to be > able to communicate peer-to-peer on dynamically allocatable IP/port > combinations does not make the concept wrong. There's no need to be insulting. I can conceive of why people might want to do P2P. I just think that _how_ some folks are trying to push a particular model down _everyone's_ throat is odious. I'm not saying everyone _should_ use NAT. I'm saying that all the developers should offer the appropriate level of control to the users and the owners so that they CAN use NAT. If you want dynamic port allocation and every machine on the network, fine, that's your choice. I have no beef with that. But don't go building systems where that's what *I* have to do, and expect me to like it. My network, not yours. Keep your grubby hands off of my machines, and I'll keep my grubby hands off of yours. > In fact, I am starting to reach the point that I would argue that > client-server is actually the broken model, not peer-to-peer. > Client-server is a premature performance/structure optimization that > then holds your thinking captive. That's a different issue. It's not performance that I care about. It's _control_. Most NAT boxes offering crappy controls to their users is (yet) another issue. :-/ I agree, there are a lot of crappy implementations. Why can't I assign a range 20 ports to each machine on my network, so that programs that want to dynamically assign ports (within a range) can do so? Because the NAT developers are lazy; why should they bother to offer that sort of control to me? What application would use it? Why can't I easily configure the OS to allocate dynmically-allocated ports in a range? Well, the configuration might get a bit messy. And then so long as I'm chopping up the port-allocation logic, do I want to further limit the space according to process owners? And/or program name/location? There are three actors/roles involved here: the owner, the user, and the developer. The owner sets policy. A violation of policy is, by definition, a security breach. The user runs the program. They're trying to get work done. If they can't get work done, they might as well not even be using a computer. The developer provides software. The developer has TWO masters: the owner, and the user. If the developer provides software that violates policy, it's a security flaw. If they provide software that fails if policy is enforced (but the owner has no objection to the software per se), it's a usability flaw. Either way, it's not a problem with the owner or the user. What we have with the anti-NAT sentiment is the developers are determining policy. They've taken sides with the user and against the owner, and are trying to usurp the role of "owner". They're designing systems to subvert the controls put in place to enforce policy. (And yes, I know that NAT isn't a firewall, but the same controls that one uses to get through a default-deny-for-incoming-connections firewall are exactly the same as one uses for NAT. Get around NAT, you also get around those (few) people who use the default-deny policies; even if you don't, they do, and who are you to tell 'em that they're wrong?) -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
