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

Ken Peterson kapnet at mindspring.com
Tue Nov 15 14:58:03 CST 2005


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