<snip> > I am not sure I see it as being more "flexible" but rather lax. > > > allowing use of various kinds of protocols > > But it's not a choice of "various" protocols. From my understanding, > once you turn on UPnP, any application that knows how to ask the > server can have whatever access (listening ports, sending port, any > numbers of these) it wants gets it. So if a single UPnP using > application has been determined to have a vulnerability, there is no > way to disable the use of that one application without disabling all > UPnP enabled apps. That does not seem flexible to me. > > > without > > having to have each of these protocols fully understood by your > > security gateway. >
Okay, I haven't read the spec either (geez, I hope someone does ;) but I suspect that the UPnP request contains some kind of "service-type" field in the request, so you can allow (for example) VoIP but not Computer games (previous emails described it using soap, and soap is great at having millions of fields). Without this service type field you are correct, UPnP sounds bloody useless. With it however, it could provide an easy way to firewall a network from baddies outside but people you "trust" inside (perhaps a good halfway house, paranoid, but not overly so ;) Am I right in assuming that once you have a UPnP service running you no longer need conntracks? The programs themselves will poke holes in the firewall and understand how to use them, so the SIP program (for a topical example) would correctly reformat the SIP command stream to handle the firewall as the external interface. If it doesn't do this, it should :) It sounds like a great way to get around the whole NAT problem (yeah, I know, you have to re-tool all your apps, but at least new systems can make use of it). Alfred
