[VOIPSEC] IPv6 and the demise (or not) of NAT (wasRe: Interactive Connectivity Establishment (ICE))

Tue Nov 15 17:02:18 CST 2005

I hadn't seen this product yet.

Essentially this is the same functionality that the other SIP Firewall 
Proxy (SFP) products perform.

The ALG is controlled by the signaling, so in essence it is very 
similar. My first attempts at SBC funcitonality was basically to place 
an SFP in a DMZ with VoIP clients pointed to the internal interface on 
the VoIP VLAN, and the external interface to the DMZ, which worked well 
and anchored the media to the SFP transparently.

The DMZ was not nat'ed so all I had to do was open a range of ports for 
media and the sip ports to the external interface of the SFP.

This allowed me to maintain the security enforcement and logging by the 
firewall as well as the SFP.

Chris

Dan Wing wrote:

>But the phones don't send media directly to it (which is a 'media relay' or
>'media proxy' or 'session border' function), which is what I thought
>Christopher was asking.  In that sense, it's an ALG (for media) that also
>includes SIP proxy and SIP registrar features (for SIP).
>
>-d
>
>  
>
>>-----Original Message-----
>>From: Ken Peterson [mailto:kapnet at mindspring.com] 
>>Sent: Tuesday, November 15, 2005 12:58 PM
>>To: Christopher A. Martin
>>Cc: Dan Wing; 'Randell Jesup'; Voipsec at voipsa.org
>>Subject: RE: [VOIPSEC] IPv6 and the demise (or not) of NAT 
>>(wasRe: Interactive Connectivity Establishment (ICE))
>>
>>It is performing SIP Proxy and Registrar roles...
>>
>>http://newsroom.cisco.com/dlls/2005/eKits/Statement_of_Direction.pdf
>>
>>also looks like it does PoE, voicemail, and autoattendant. 
>>Apparently this
>>isnt your $89 Linksys... price was anticipated to be $1200 or 
>>so in a couple
>>of press releases I saw...
>>
>>		Cheers,
>>		   Ken
>>
>>-----Original Message-----
>>From: Christopher A. Martin [mailto:chris at InfraVAST.com]
>>Sent: Tuesday, November 15, 2005 3:30 PM
>>To: kapnet at mindspring.com
>>Cc: Dan Wing; 'Randell Jesup'; Voipsec at voipsa.org
>>Subject: Re: [VOIPSEC] IPv6 and the demise (or not) of NAT (wasRe:
>>Interactive Connectivity Establishment (ICE))
>>
>>
>>Is the linksys proxy based?  I thought it was a simple alg, just like
>>cisco's ios and firewalls (I dont see the unit having enough steam to
>>support proxy).
>>
>>Also, I have to clarify, Ingate has been doing this far 
>>longer, in terms
>>of emergence...I would place them as the most mature SIP 
>>firewall proxy,
>>and I have worked with most of them from the inception.
>>
>>Chris
>>
>>
>>Ken Peterson wrote:
>>
>>    
>>
>>>I have come to the conclusion after writing and delivering a 
>>>      
>>>
>>3-day VoIPSec
>>    
>>
>>>course for the last year that the only feasible solution is 
>>>      
>>>
>>for the NATing
>>    
>>
>>>device to also be a SIP proxy.
>>>
>>>We are now seeing the emergence of this product. As Mikael 
>>>      
>>>
>>pointed out,
>>    
>>
>>>Ingate was the first (to my knowledge) to offer a combo 
>>>      
>>>
>>NAT/FW/SIP Proxy.
>>    
>>
>>>Today, Cisco jumped into this market with the LinksysOne initiative:
>>>
>>>see:
>>>http://prnewswire.com/cgi-bin/stories.pl?ACCT=104&STORY=/www/
>>>      
>>>
>>story/11-14-20
>>0
>>    
>>
>>>5/0004214551&EDATE=
>>>
>>>Before that was the similar underground "SIPatHome" project 
>>>      
>>>
>>on a Linksys.
>>    
>>
>>>STUN is fine in the meantime until you adopt this model - 
>>>      
>>>
>>you can access
>>    
>>
>>>"free" STUN servers. TURN requires someone outside the 
>>>      
>>>
>>firewall to dedicate
>>    
>>
>>>resources to "bounce" your media stream - there are no 
>>>      
>>>
>>"free" TURN servers
>>    
>>
>>>on the Internet to my knowledge. STUN/TURN/ICE will fail 
>>>      
>>>
>>when encrypted
>>    
>>
>>>signaling and voice become common.
>>>
>>>UPnP and Midcom seem to be doomed for the aformentioned reason that a
>>>non-administrator controls the firewall pinholes (manholes 
>>>      
>>>
>>in this case.)
>>    
>>
>>>For more scalable enterprise implementations, it seems most 
>>>      
>>>
>>likely that the
>>    
>>
>>>data firewall will remain in place and all voice will pass 
>>>      
>>>
>>through the new
>>    
>>
>>>"IP communicaions firewall" (aka Session Border Controller) 
>>>      
>>>
>>which will
>>proxy
>>    
>>
>>>all voice traffic and bearer channels leaving the 
>>>      
>>>
>>enterprise. Encryption
>>    
>>
>>>issues are solved, NATing issues are solved, lawful 
>>>      
>>>
>>intercept issues are
>>    
>>
>>>handled, and we may actually have a product to make money 
>>>      
>>>
>>with instead of a
>>    
>>
>>>"protocol."
>>>
>>>The whole thing seems black and white to me based on the 
>>>      
>>>
>>business case. I
>>    
>>
>>>would be interested to hear alternative opinions.
>>>
>>>	 	Cheers,
>>>	         Ken Peterson
>>>
>>>*************************************************************
>>>      
>>>
>>***********
>>    
>>
>>>*                             *
>>>*  Ken Peterson, CCIE 4297	*  Cisco Certified Security Professional
>>>*  PacketBrain, Inc.         	*  Cisco IP Telephony 
>>>      
>>>
>>Support Specialist
>>    
>>
>>>*  Cary, NC 27511            	*  Cisco Content 
>>>      
>>>
>>Networking Specialist
>>    
>>
>>>*                            	*
>>>*************************************************************
>>>      
>>>
>>***********
>>    
>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Voipsec-bounces at voipsa.org 
>>>      
>>>
>>[mailto:Voipsec-bounces at voipsa.org]On
>>    
>>
>>>Behalf Of Dan Wing
>>>Sent: Tuesday, November 15, 2005 2:22 PM
>>>To: 'Randell Jesup'
>>>Cc: Voipsec at voipsa.org
>>>Subject: Re: [VOIPSEC] IPv6 and the demise (or not) of NAT (wasRe:
>>>Interactive Connectivity Establishment (ICE))
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>"Dan Wing" <dwing at cisco.com> writes:
>>>>
>>>>
>>>>        
>>>>
>>>>>>>       Another big problem with UPnP is the double-nat problem.
>>>>>>>Put a device behind two UPnP NATs and you can't open a port
>>>>>>>through both.
>>>>>>>With STUN/etc, you can open ports through any number of NATs.
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Except if one of those NAT's is symmetric (which is 90% of
>>>>>>all routers are) then it maybe broke.
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>draft-jennings-behave-test-results,
>>>>><http://www.ietf.org/internet-drafts/draft-jennings-behave-te
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>st-results-01.t
>>>>
>>>>
>>>>        
>>>>
>>>>>xt>, shows test results of a couple dozen NATs.  Only one
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>NAT was found to
>>>>
>>>>
>>>>        
>>>>
>>>>>be symmetric.
>>>>>
>>>>>Do you have other data to share?
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>       That data is mostly from 2002/2003 NATs, and the 
>>>>        
>>>>
>>newer testing
>>    
>>
>>>>is almost all "odd" routers (not from the major players in 
>>>>        
>>>>
>>the retail
>>    
>>
>>>>market: Netgear, DLink, Linksys, Belkin, etc) - and the two
>>>>main retail
>>>>routers there (Netgear 814v2 and Linksys BEFSR81) aren't new.
>>>>
>>>>       It's nowhere near 90%, or even 50% - but the number
>>>>(especially in
>>>>"popular" routers) is climbing.  The Netgear WGR614 (not the
>>>>RP614 in the
>>>>draft) is symmetric in all of the recent variations
>>>>(v4/v5/v6), for example.
>>>>v2 was Cone I think.
>>>>
>>>>
>>>>        
>>>>
>>>Thanks.  I'll see if Cullen (the author of
>>>draft-jennings-behave-test-results) can get those routers 
>>>      
>>>
>>and do another
>>    
>>
>>>round of tests.  Having accurate information is useful for everyone.
>>>
>>>In any event, one of ICE's techniques is to use a media 
>>>      
>>>
>>relay (a "TURN
>>    
>>
>>>server") when necessary -- such as when you're behind a 
>>>      
>>>
>>symmetric NAT.  Of
>>    
>>
>>>course, somebody's bandwidth and CPU resources are being 
>>>      
>>>
>>used to provide
>>    
>>
>>>media relay services, so that someone will likely want to be 
>>>      
>>>
>>paid, somehow,
>>    
>>
>>>for providing that media relay service.  Depending on how 
>>>      
>>>
>>that service is
>>    
>>
>>>billed, it may be cheaper to purchase a NAT that doesn't require an
>>>      
>>>
>>external
>>    
>>
>>>media relay.  As media progresses from 100kb/sec of G.711 
>>>      
>>>
>>voice to 6Mb/sec
>>    
>>
>>>of high-definition multi-screen video, operating a media relay will
>>>      
>>>
>>continue
>>    
>>
>>>to be expensive.
>>>
>>>The IETF BEHAVE document draft-ietf-behave-nat-udp-04.txt specifies
>>>non-symmetric NAT behavior in order to avoid media relays.  When that
>>>document goes to RFC vendors can declare a NAT device to be 
>>>      
>>>
>>'compliance
>>with
>>    
>>
>>>RFCxxx' and consumers can decide to purchase those 
>>>      
>>>
>>RFC-compliant devices,
>>    
>>
>>>decide to pay (directly or indirectly) for a media relay 
>>>      
>>>
>>service with a
>>    
>>
>>>non-RFC-compliant device or with their RFC-compliant device 
>>>      
>>>
>>(if they feel
>>    
>>
>>>the media relay and symmetric NAT behavior offer 'better security').
>>>
>>>-d
>>>
>>>_______________________________________________
>>>Voipsec mailing list
>>>Voipsec at voipsa.org
>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>>
>>>
>>>
>>>_______________________________________________
>>>Voipsec mailing list
>>>Voipsec at voipsa.org
>>>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>>>
>>>
>>>
>>>
>>>      
>>>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>
>
>  
>