On Monday 08 April 2002 16:29, Brian J. Murrell wrote: > If it is indeed possible to do this. How does the UPnP determine > for what purposes a client request is being made? If the answer is > "well the client says what it is for" then again, that is useless.
There is multiple choices here. 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. 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. 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. How do you propose the applications should identify themselves to the UPnP device if you do not even trust the user? > When a certain application is excluded from the security policy it > will be changed to announce itself as something different -- > something that is allowed -- not at all unlike all of the > applications that were made to tunnel through HTTP to be able to > circumvent the firewall. Perhaps true if speaking about trojans. Not so if speaking about real programs. > I should read (or at least peruse) the spec. For some reason I > really doubt there is a trustworthy way of determining what the > client application is, and from the description given a few > messages ago about how Messenger works with UPnp, it seems like > there will be no "fixed" ports for anything, so using port numbers > to administer the security policy won't work either. 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 * Please forward ALL ports to me And any number of these mappings may be active at a given time, within the limits of the UPnP wan device. 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. For the sake of keeping this discussion on level think of UPnP as nothing more than NAT traversal. 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. 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. It is the responsibility of firewalling with connection tracking, IDS etc to ensure this is used in a manner conforming to your policy, also taking into account the information provided by UPnP such as - Intented use of the connection - User (if authentiated) Regards Henrik
