Re: Dealing with MS Netmeeting & H.323

[Jan.Bervar () nil si]

On 06/03/98 08:18:41 PM "Ryan Russell"  wrote:
> I'll agree with Fred on this one... It's pratically impossible
> to really handle Netmeeting securely at this point, since the
application's
> purpose in life creates huge holes, even when functioning correctly.

I don't consider it a huge risk for outgoing calls, when handled *PROPERLY*
by a stateful filter. And to make it scalable, you would appreciate the low
 latency
and high throughput that SPFs tend to have. Of course, YCMMV (C=customer's)
 ;)

> At best at present, the main SPF products such as FW1 and PIX
> just open the minimum number of ports for the minimum amount
> of time.  It's a big impovement over Microsoft's instructions (
> Just let all UDP in... .yea, right) but the program itself is still
> pretty bad.

Yes, this is the way SPFs handle all the weird services. The obvious
problem
we have here is that we rely on a timeout to close the dynamically opened
ports if you cannot determine the end of the session from a control channel
(for example, if you are streaming UDP inbound). So you do have a little
race condition there.

Some strong authentication would solve a lot of problems here. For outgoing
 calls you would need
to authenticate incoming packets (IPsec-speaking firewalls come to mind) so
 you know who you
are talking to at all times. We still have a long way to go before IPsec
will be deployed
globally, however, for building up a more secure (and more or less closed)
conferencing system
you could deploy it in many real-life situations.

> You really need a dedicated H.323 conferencing system to
> even think about doing Netmeeting safely at this point.

The bigger problem is with incoming calls. For this you would need some
H.323 proxy to act as
a gatekeeper doing user/session/packet authentication for H.323 at your
firewall. Either you do that
or you require some out-of-band authentication to pass H.323 directly
through the firewall (the usual
SPF approach). Remember that SPFs have the ability to act as application
proxies when needed (like the
PIX and FW-1 are doing in-band user authentication) and the reverse is not
always true.

I don't know enough about H.323 to know how this could be done technically.
 Are the other vendors
just emulating SPFs for H.323 (a fancy plug-gw ;))) or are they actively
messing with the
application protocol?


Best regards,
Jan