[VOIPSEC] VPNs and VoIP (was: Re: VoIP Attack : How feasible)

[Simon Horne]

At 10:13 PM 29/07/2006, Michael Slavitch wrote:
>That is good to know, thank you for bringing it up.  I knew of the
>standards but it is encouraging to see shipping product.  Hopefully
>this lights a fire under the feet of standards bodies elsewhere.  If
>SIP doesn't follow through H.323 could make a comeback, at least on
>the terminal side.

There is has been a lot of movement back in H.323 in video and these 
companies have been the main driving force for the instigation of NAT 
traversal standards. Along with the existing players a number of new 
entrants have entered the space heating up competition further which has 
sped up NAT support deployment.


>However it is my personal opinion that it will be P2PSIP that ends
>being the most successful option due to its self-scaling nature and
>minimal requirement for IMS-like infrastructure. P2PSIP of course
>requires that NAT traversal problem be solved using methods that cause
>minimal pain. This eventually will be solved because there is no other
>option.

Point to point is always going to be more efficient than peering (proxying 
media) through a third party. It also doesn't play well with corporate 
security as you allow others to proxy media on your network, it suffers 
from exactly the same issues I raised with SKYPE.  The basic principle of 
standards based VoIP is point to point however NATs made things a lot more 
complicated.  ICE to it's credit in theory attempts to address the problem 
of point to point with NAT however with a lot of things in SIP the 
execution is where it let's itself down. We are busy doing a lot of work in 
the area of Point to Point in H.323.

Simon


>M
>
>
>On 7/29/06, Simon Horne <s.horne at packetizer.com> wrote:
>>At 09:21 AM 29/07/2006, Michael Slavitch wrote:
>>
>> > > VPNs are workarounds to bring the SIP/H.323 protocols back into a
>> > > protected/friendly network where you hope such forgings will not happen.
>> > >
>> >
>> >Indeed. Simplicity is better. SIP/H.323 had no solution. ICE is still
>> >a pain. Session border controllers are useless and a pain.  VPN's work
>> >for all and are a simple easy commodity.
>> >Why sniff?
>>
>>Don't lose site that ICE has very important functionality as it attempts to
>>find ways to traverse a NAT without proxying media. The idea is very good
>>but the practical execution is a little painful. To correct your comment,
>>in H.323, you are actual spoilt for choice for NAT Traversal. I know of 3
>>methods, 2 standards and one non-standard. There are two standard methods,
>>H.460.17/19 which Radvision uses and H.460.18/19 which has been adopted as
>>the preferred method of traversal.  Both require no special end user
>>configuration and have no media startup delay. A lot of video terminals
>>have recently been release or are currently under development that support
>>H.460.18/19. There is also the non-standard GnuGK method which you can find
>>software and hardware (IP Phones and Gateways) devices can support. We are
>>currently doing a lot of development on extending NAT support in H.323 to
>>allow functional point to point calling (avoiding the need to proxy, much
>>like what ICE attempts to do).
>>
>>Given that H.323 already contains an end-to-end security framework (H.235),
>>it's quite possible to add secure NAT support to existing deployed networks
>>without having to force the installation of a VPN or requiring network
>>upgrades. (except deploy a server to assist NAT Traversal which is
>>available for free and open source ) .
>>
>>My point is that these solutions do exist in a standards based VoIP
>>protocol, they work and they can be deployed today,  just they are not
>>available in SIP.
>>
>>Simon
>>
>>