begin quoting Andrew Lentvorski as of Sun, May 21, 2006 at 03:45:45PM -0700: > Stewart Stremler wrote: > > >'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. > > If we are arguing that the NAT programmers are lazy, we might have some > agreement. I don't have any good way of interrogating a NAT to ask > "what is your policy?".
Oh, I can agree that the programmers who build the interfaces to the NAT devices are lazy... The UI often leaves a lot to be desired. > >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. > > I don't want to do it *my* way. I want to do it the way that *the > majority of users want it*. I am willing to bend whichever direction is > necessary to make that happen. The problem is that current NATs give me > no direction I can take. I'm not aware of any NAT boxes that don't allow you to tunnel a port through the NAT device to a particular machine. "Port 1234 goes through to machine A, port 2345 goes to machine B, etc." is a minimal level of capability in the handful of NAT devices that I've seen. But a manual step -- it works, but it isn't sexy -- isn't quite what you want. > And, if you notice, most P2P programmers do offer that control. Take a > look at connection options in any piece of P2P software. They're > generally a huge mess. All to cope with NATs. Surely a url-style specification would suffice. Set _a_ port in the NAT device, and type that number in your application as well. > Most P2P software would work beautifully in a world without NATs. Most software works beautifully in a world without latency, too. And trusted networks. And a lack of malicious agents.... > The problem ain't with the application programmers. Depends on which ones you're dealing with. I'm probably a bit jaded at the moment, as I've been dealing with a lot of hard-coded ports and paths. (What good is an XML configuration file if the location is hardcoded, and it specifies the destination port number, but the local server-socket port number is hardcoded?) > In fact, I *could* use fixed ports if the blasted NATs would just tell > me what port they dumped me on. Ask the user. If they're allowed to run your software, this is information they should know. > >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. > > And what happens when the owner is the user and has said: "No fixed > ports, I'm not clueful enough to touch my router configuration, so I > want autoconfiguration of P2P". The flaw is that the owner/user wants > two conflicting goals. And, when that happens, the user identity wins > out over the owner identity. Owner desires trump user desires. *Always*. If the owner and the user are the SAME PERSON, the only conflict comes from the developer. (This is, in large part, my resistence to Javascript. The usability confict arises solely from the developer; the solution is for me the user to subvert the policy of me the owner. The same works for applications that demand I give them root access, or have unfettered access to the 'Net.) > When usability and security conflict, security loses. Period. Which is exactly opposite of good sense. :( > When the security people finally get that, we might finally get more > secure systems. But that's a different discussion. Granted. Designing security so that it's CLEAR what's happening, rather than relying on some opaque and rather magic incantations... is going to be an important hurdle. Non-security people need to be able to set their policy so that _they_ understand it. > >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. > > Absolutely, because the "owner" doesn't exist for 99.9% of these boxes. Well, the owner is the user. They're _roles_. > The "owner" only appears when he gets in the way of the "user". There > is no "owner" to please; there is only the "user". And the "user" has > said "Own my NAT, please!" The obvious approach, I think, would be to build a NAT-control library, like termcap and terminals. "Tell me what sort of NAT device you have, and where it's at." A beneficial side-effect would be to allow for the development of a set of open-source NAT-management tools built on top of such a library. [snip] > There are plenty of ways for an active owner to stop traversal. Even > with hole punching, there are still plenty of ways to stop this (RST any > incoming connection without a rule stops all TCP hole punching cold). By "active owner", I take it that you mean someone who explicitly allows incoming connections through a firewall? > However, the inverse is not true. There are no good ways for a passive > owner to enable traversal. Nor is there a good way for NAT companies to > enable some mechanism that isn't complete ownage. By "passive owner" you mean someone who relies on a default-allow configuration? > Anyhow, the longer I am at this, the less convinced I am about the > benefit of "default deny" in an end-user system. Even behind all these > "secure NATs", botnets thrive anyhow. But that's a different discussion. The longer I'm at this, the more I like "default deny". Installing 'little snitch' on my Mac has me realizing just how much communication some of these programs are engaged in when, so far as I'm concerned, they shouldn't even have network access. (Last one that got me was an attempt to use an XML parsing library with validation turned off... and the library *still* made attempts to access the network, and failed with a 'syntax error' when denied.) If we want to make that a separate discussion, well, I have opinions there, too. -- _ |\_ \| -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
