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

[Ken Peterson]

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