On Tue, Apr 09, 2002 at 01:04:30AM +0200, Henrik Nordstrom wrote: > > a) The NAT defice fully trusts the client and opens whatever the > client requests it to without asking.
:-( > b) Authentication, requiring the user to identify himself before > allowing the request and you trust the user. Possibly not supported > by all applications however as the standard does not mention this > explicitly, but is available due to the use of HTTP as transport > protocol. It's not the "user" (the person) I don't trust (as much anyway) but the software the user is using. If the user is a problem, that is a social issue and needs to be addressed with social measures. I am addressing the technical issue that UPnP raises. > c) Firewalling, where you firewall the ports as if the client had > opened them directly with no NAT. Requires connection tracking > support for the protocols the client is speaking. I must be missing something here because we seem be going around and around on this issue. There are no "defined" ports that you can discern what gets opened and what doesn't. It sounds to me like all ports are ephemeral, which makes sense because one TCP/UDP device is mapping ports for a whole network of clients. They can't all ask for port 80. It sounds like once a client has gotten a port, .NET acts as a "lookup" service so that parties wishing to meet can find out what ports their friends are on. So if client software is asking for ephemeral (non-predictable) ports how can you use the port number to "firewall" what they are doing? To put another way, an ISP could try to stop users from setting up web servers but that is futile because as a protocol, HTTP allows the specification of a port. > In case 'c', UPnP's main purpose if to advertise the external IP > address to the client, and optionally prepare (but not open/accept) > the reverse-NAT sessions. Well, yes, UPnP could refuse to open the requested ports but then it's pointless. See this is the problem. Other than trusting the client software to announce who it is, truthfully, there does not seem to be any way to determine one access reqeust from another. > How do you propose the applications should identify themselves to the > UPnP device if you do not even trust the user? Like I said, it's not so much the user as the actual software I don't trust. And I don't have a proposal for how it should be done. This is my issue. I guess we will just have to agree that UPnP has no place in an environment where security is an issue. i.e. I had better not find out that any company I hold stock in is using this thing! :-) > Perhaps true if speaking about trojans. Not so if speaking about > real programs. Oh no? So there are no "real programs" that have been designed to tunnel through HTTP in order to circumvent firewalls?. "Real program" developers do not give two hoots about network security as much as they wanna provide the "ultimate user experience" and will circumvent whatever measures they can to do so. Trojans will most certainly do so. > Almost correct. From my understanding UPnP portmapping is very > simplistic and only operates using fixed ports. There is two types of > mapping requests > * Please forward THIS port to me Where "THIS port" is what? Unless it's a predictable value, you can't base access control on it. > This protocol is really not intended for concurrent use on a large > network, but to allow a small network (i.e. home network) to get out > from inside a NAT gateway in a seemless manner. As such it is quite > reasonable. But you know that it will not be limited to environments where the primary concern is access and not security, but will be deployed by unknowing/security ignorant network admins when the <choose your favourite computer-toy liking executive> of the company sees he can use MS IM and NetMeeting (and who knows what is to come) if they install it. > For the sake of keeping this discussion on level think of UPnP as > nothing more than NAT traversal. That is exactly what I am thinking of it as. But unlike netfilter's NAT, it seems I have to take it all or leave it. I can't choose what I will NAT for and what I won't. > Firewalling is then applied ontop > of this just as if your network was "Internet <-> Firewall <-> NAT > device <-> client". UPnP allows this to be done in a somewhat more > controlled manner than if the firewall and NAT device was separate as > there is some information in the UPnP protocol identifying the > intended use of the reverse-NAT channels which can be used to aid > firewalling decisions. Well, I guess we will have to wait and see how it rolls out. > My view of things: > > It is the UPnP daemons responsibility to set up a policy on what the > user may request, filters on intended uses etc, and to integrate this > with the firewalling in a sensible manner. If it can be done, then hooray. I am not hopeful it has this sophistication -- that can be trusted. I think we are likely converging on parallel thoughts. "In violent agreement" as the saying goes. :-) b. -- Brian J. Murrell
msg00621/pgp00000.pgp
Description: PGP signature
