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

[Simon Horne]

At 09:11 AM 17/11/2005, you wrote:


> > -----Original Message-----
> > From: Randell Jesup [mailto:rjesup at wgate.com]
> >         There are "facilities" service providers (cable co's, telco's,
> > etc)
> > who can put SBC's in the access path, and where there's an implicit
> > assumption that the ATA/etc is not mobile, and there are non-facility
> > service providers like Vonage, Packet8, etc who can at best install SBC's
> > moderately close to users, and quite possibly seriously far from users.
> > (Do you plan to have an SBC at a random DSL CO in Outer Nowhere, Poland?
> > Are you going to proxy all data through an SBC in the US if they're
> > calling
> > another VoIP subscriber travelling in Hungary?  Delay?  Loss?  Jitter?
> > Even ignoring travel, lots of Vonage/etc customers use SIP devices far
> > from any likely infrastructure.)
>
>Yup, I was generalizing to telco carriers, because I think you used that
>word and regarding their approach. (no?)  Many non-facility service
>providers also use SBCs, and their strategy is different.  As I said, some
>(most?) SBCs can release-media if they think they can.  The hard part is
>NAT-traversal, but even then they can sometimes do it.  I won't get into the
>heuristics of how they make such a decision, as it's probably
>vendor-specific.  If the clients do STUN, then media release is even easier.
>The goal, though, is usually to require no changes on the clients or NATs.
>Thus carrier SBCs don't need STUN/TURN/ICE/NSIS/MIDCOM/UPnP/... to do NAT
>traversal - they just use SIP.

In practise, there is really only a few alternative for symmetric NAT 
traversal. I think the solution is a combination of smart EP\UA's and 
cleaver external servers, The Nat'd UA/EP that can detect it is behind a 
NAT and choose an appropriate strategy to traverse the NAT. ie a strategy like.

For the UA/EP
if local address is RFC1918 (local address) and server is not then "We are 
Natted".
1. Use STUN to determine type of NAT, if anything other than symmetric then 
use, else.
2. Do we support UPnP or MIDCOM etc.. if yes use, if no then,
3. Do have manual port forwards set, if yes use, if no then,
4. Do we have a NAT Assist method provided by the SBC/proxy (generally 
involving media routing) then use, else.
5. OK we are in a bit of trouble so send a warning to the user.

For the SBC/Proxy
Compare what the UA/EP says its address is and what the socket says, if 
they are different and the UA/EP is RFC1918 then "this UA/EP is natted" and 
notify the UA/EP that they are Natted and what Public IP it was detected on 
and provide a proposed strategy to traverse the NAT (ie. "Keep Alive" TCP 
port for signalling)

Several proxies in SIP/ H.323/ IAX already support some type of NAT assist 
strategy, but there is no one standard way of doing it and all involve 
media routing,
FYI The ITU released 2 new standards to try and standardize methods for 
H.323 namely H460.18/19  You can download the drafts from 
http://www.packetizer.com/voip/h323/standards.html



>If the client needs TURN, then an SBC already does that function logically -
>much more cleanly than the TURN protocol.  And TURN also suffers the same
>issue you raise - where to locate the TURN servers.  TURN takes hardware
>(despite the RFC's apparent best efforts to make it difficult for hardware
>to do), and so non-facility vendors have to handle that.  Even if only 1-5%
>of NATs/FW are symmetric (and that percentage appears to be regionally
>specific), that's enough for major support headaches if you can't fix it.
>
>
> >         Right (though non-local SBCs cause significant pain/cost/scaling
> > issues when relaying).  IF you can find a way to get through the NAT,
> > then SBCs (and media proxies) become much less attractive unless you want
> > to enforce a telco-like model.
>
>For some reason this mailing list is fixated on SBCs purpose being for media
>relay for home NAT traversal.  That's not even in the top 3 feature list.
>(nor is their purpose to "enforce a telco-like model")  Any SBC vendor who
>plans their long-term strategy on NAT traversal as their reason for
>existence is in for a short ride.  Although at the rate the IETF is going
>with churning new ICE drafts, and the complexity of it, it may be a longer
>ride.

In reality you do not have much choice but to relay media for Home Nat 
Traversal since a heck of them are symmetric and it's near impossible to do 
it without routing media. The fact is that most of these home routers also 
support UPnP for gaming etc so we may end up with vendors asking their 
customers to just tick the box in the router that says "Enable UPnP" and of 
course the vendors are not responsible for the outcome.

Simon