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

[Hadriel Kaplan]

> -----Original Message-----
> From: Simon Horne [mailto:s.horne at packetizer.com]
>
> 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)

Ironically this information is already conveyed to the UA.  The Register
response's Via header (the UA's own Via coming back in the 200ok for a
Register) usually has a received= parameter, with the real public ip/port
their Register used.  The UA could then use that in all subsequent SIP
messages for its via and contact headers.  It also needs to keep the pinhole
open, which it can do by sending Registers or Options periodically, just as
it would have to send STUN/TURN messages periodically.  But the missing
piece, and the hardest, is for the UA to learn its public media
address/ports.  

There have been a couple softphone makers who tried fixing things themselves
based on the SIP received info, but they ended up screwing themselves up.
It doesn't bode well for umpteen endpoint vendors implementing ICE.  It also
doesn't help that the draft has been significantly changing every IETF
meeting or so. 

If the UA used TLS there is already an ietf draft mechanism for a keep alive
in that, and re-using it for bi-directional signaling, so it works through
NATs. (they just happened to choose a bad keep-alive mechanism in my
opinion, but it will work)

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

Yes, but the current solutions for SIP and MGCP don't require any
protocol/interop changes, thus no standards.  But of course media needs to
be relayed - there actually is a way around that relaying still without the
endpoint needing to be too smart, but it adds a bit of complexity (still
less than ICE).  But most carrier call models really show very few calls
voip-to-voip.  The vast majority of calls are to the PSTN/off-net anyway
today, and so media relaying would be done anyway.

> 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

Ya, H.323 is tough to support NAT traversal without help. :)  I don't know
about the other vendors, but we rarely see H.323 in homes (except Asia).
Most of the time it's for supporting enterprise PBXs or peering.  Consumer
or enterprise phones/IADs always seem to be SIP or MGCP.

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

I'm actually really hoping a STUN-like solution pans out that is viable.
UPnP is ok for the home, but people take PCs into hotels, cafes, etc.  The
funny thing is I don't think most SBC vendors charge for NAT traversal
fixing - our money comes from other things - so if endpoints can fix
themselves, all the better in my opinion.  It just needs to be in a way a
service provider can scale, secure, and troubleshoot.  Using 15-30
STUN+TURN+SIP packets just to make one simple direct call isn't going to be
it, IMHO.

-hadriel