OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
NFR Wizards Archive: Re: Dealing with MS Netmeeting & H.323

Re: Dealing with MS Netmeeting & H.323

Jan.Bervarnil.si
Sun, 7 Jun 1998 19:26:31 +0200

Jan Jan BervarNIL
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

This archive was generated by hypermail 2.0b3 on Sat Jul 17 1999 - 07:11:22 CDT