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

Dan Wing dwing at cisco.com
Tue Nov 15 15:14:46 CST 2005


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




More information about the Voipsec mailing list