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

[Dan Wing]

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

You mean a SIP proxy that handles both media relaying and
modifies SDP, I believe.

...
> STUN is fine in the meantime until you adopt this model - you 
> can access "free" STUN servers. 

stun-server.org is free (without quotes).  Of course, it's a
free service and could go away, so perhaps that's why you put
free in quotes.

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

I don't know of any, either.  Similarly with a SIP proxy on
the Internet, or one integrated with your NAT/firewall, it
isn't "free" -- you're paying for that capability.

> STUN/TURN/ICE will fail when encrypted signaling and voice become common.

I'm not sure what problem you see with ICE with encrypted signaling, but it
works with TLS, S/MIME, and -sip-identity.  Working with encrypted and
integrity-protected signaling was one of ICE's design goals.

-d

> 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