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

[Simon Horne]

At 01:21 PM 17/11/2005, you wrote:


> > -----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 SIP packet used.  The UA can 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 frequently, instead of STUN/TURN
>messages frequently.  So the only missing piece, and the hardest, is for the
>UA to learn its public media address/ports.
>
>If the UA used TLS there is already a ietf draft mechanism for a keep alive
>in that, and re-using it for bi-directional signaling, so it works through
>NATs.
>
> > 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
>change, thus no standard.  But of course media needs to be relayed - there
>actually is a way around that relaying still without the endpoint being
>smart, but it adds a bit of complexity (still less than ICE) but carrier
>call models really show very few calls voip-to-voip.  The vast majority of
>calls are to the PSTN/off-net and so media relaying adds no delay.

Yeah, calling out to a PSTN from behind a symmetric NAT is supported in a 
lot of protocols, H.323 and IAX too. The problem is calling in, if we just 
say heck let''s not worry about that then we are really putting our head in 
the sand. My point, AFAIK, there is no standard method to do this in SIP or 
MGCP, there needs to be one.


> > 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 was 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 PBX or cisco CCM (where the
>enterprise opens holes for it), or peering.  Consumer or enterprise
>phones/IADs always seem to be SIP or MGCP, which can be through NATs.

Again only in 1 direction OUT. What about IN? So we don't worry about that? 
We'll just tell the customers you want to call your friend on the PC? Use 
SKYPE? Oh well then they might as well use SKYPEOUT too!  Oops no more 
customers!  The customer does not care what the protocol is, all they care 
is that it works and the moment it doesn't fully or adhoc with symmetric 
NAT's. Lets work together to find a standard way of doing it.


> > 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.
>
>I'm actually really hoping either that happens, or a STUN-like solution pans
>out.  The ICE concept has been a disaster - Cisco has had to significantly
>rewrite it 4 times, and no one knows if the latest one will work.  Meanwhile
>the KISS principle seems to be completely foreign to the working group, who
>are so focused on not wanting an SBC involved, they don't seem to realize
>what many of the STUN and TURN servers will be: the SBCs!  And we'd rather
>it not consume all our resources.  The funny thing is none of the SBC
>vendors charge for NAT traversal fixing - our money comes from securing
>signaling and off-net calls, so if endpoints can fix themselves, all the
>better.

Well this perfectly illustrates my point. There is no money in routing 
media, let the customer wear the risk, saves us money. :)

Simon

>-hadriel

Simon Horne
Director
Packetizer Labs
www.packetizer.com/labs