Firewall Wizards mailing list archives

Re: Dealing with MS Netmeeting & H.323


From: Jan.Bervar () nil si
Date: Sun, 7 Jun 1998 19:26:31 +0200



Jan Bervar@NIL
07.06.98 19:26


On 06/05/98 02:32:19 PM Frederick M Avolio  wrote:
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) ;)

Speed at the expense of security processing? I'm not sure what *can* be
usefully done with H.323, but outgoing calls, while probably at a lower

I tried to say that an application gateway cannot handle H.323 as a TRUE
app. gateway (remember the ~150ms latency barrier for VoIP) for many calls
without running on oversized hardware. In many situations it is *secure
enough* to
deploy H.323 over a SPF, because the usual policies don't allow arbitrary
H.323 calls anyway (for example, calling/voice trunking between VPN sites).

Perhaps it will turn out that most AG people are handling H.323 with a
plug-gw
on steroids (i.e. plug-gw plus a couple of dynamic udp forwarders), which
is
against all AG principles (like all plugged services - Lotus Notes RPC,
NNTP,
whatever). All the security you gain here is presumed robustness of the
gateways
TCP stack - you are basically emulating SPFs (at least you are very good at
 it <g>).

risk, are still at risk. Granted, the inside user is inviting a
connection
from the outside (which is what the SPF is using for decision making),
but
once that connection is established and allowed, any vulnerability would
still exist. If a vulnerability exists, the inside user is then in the

Agreed. But what would an AG do to secure H.323 in this case?

Best regards,
Jan




Current thread: