> By definition there are no "defined" ports. Because the UPnP
> device has to allocate ports out to a whole lan of clients
> wanting (for
> instance) a listener, the same port cannot be used by all
> listeners. From the previous definition of how Messenger uses
> UPnP, a broker on the .NET network is responsible for telling
> others what ports and addresses are listening.
.NET is responsible for telling the callee where the caller is expecting
to receive the intial SIP transfer at (ip and port). After that, the
entire voice/video connection is carried via RTP over the UDP (usually)
connection. .NET still sits there and relays all the text messages (and
connections setups for other things like file transfer, remote desktop,
etc.). The Messenger client on caller is sticking its ip that it thinks
it is and a random port in the HTML messages sent via TCP through the
.NET server to the callee who then reads this out of there and sends an
SIP INVITE to the callee without the intervention of the .NET server.
>
> If there are no "defined" ports then "users X & Y are allowed
> to punch such holes for port 456 under certain given
> conditions." becomes more difficult. As a security
> administrator what other "given conditions" are there?
>
> > UPnP is just the tool, not the policy on how it may be used.
>
> But the tool has to be capable of (being involved in)
> enforcing the policy. I see no way for the UPnP server of
> doing this at this point.
>
As a note on this point, yes what I've seen with Messenger is is does
provide both an application name and a GUID
{02D3C01F-BF30-4825-A83A-DE7AF41648AA} in its TCP packets. Of course I
haven't been able to sniff the SIP/SDP packets yet, but one would
surmise that its in them as well. Of course, as stated before in an
earlier post, it's relatively trivial for an application to fake this.
