[asterisk-dev] STUN support in chan_sip revisited

[Robert Hoffmann]

Somehow I stumbled across your discussion of STUN via voip-info.org. I recently 
finished a work about NAT-Traversal Techniques at my university. As this is 
quite an important topic for asterisk, I wanted to give my two cents:

- As you have already concluded, STUN cannot be used to safely obtain a working 
public IP address and port (a "public endpoint"). This is because STUN has no 
means to safely find out behind what kind of NAT it sits.

- Therefore, you can obtain *some* public endpoint with STUN, but you have to 
assume that this endpoint is only valid for the current connection between the 
PBX and the STUN server. The worst-case NAT performs connection-dependent 
mapping. In this case, every outgoing connection will be mapped to a new public 
endpoint. 

- Also a restrictive NAT could enforce endpoint-dependant filtering. That means 
that even if you know an active public endpoint it can only be used by the 
remote host you initially contacted (the STUN server).

- Therefore, you could say that STUN is only intended for P2P communication. 
Because you have to assume that a public endpoint is only open for the one 
remote host you initially connected to, you can only use this public endpoint 
for communication with this one host. Any other remote host trying to use the 
mapping will likely fail due to filtering. This is, by the way, how stateful 
firewalls filter, too. This behaviour fits P2P communication but does not enable 
asterisk to obtain a static "port fowarding" (i.e. for incoming SIP signaling) 
which is free for any outsider to use.

- As you already suggested you could use STUN to obtain a valid public IP 
address *only*. For anything else, there must be static port forwardings 
configured in your middlebox (router / firewall / whatever you want to call it).
 
- There is one evil catch: The public IP address obtained by STUN will *only* be 
valid if your middlebox is configured so that the PBX consistently receives the 
same public IP address for all active sessions. In IETF jargon this is called 
Paired IP Address Pooling. If a NAT has several public IP addresses to choose 
from, it *may* choose a different IP for *every* single session. This is an 
attempt to do security by obscurity. For a consumer environment with only a 
single public IP address there will be no problem and STUN will prevent people 
from having to rewrite their config every day. In a corporate environment, 
additional configuration at the middlebox is necessary. This point should go 
somewhere in the manual.

- As a reference, what I just described is how the SIP PBX sipxecs is tackling 
the problem. sipxecs expects you to statically forward port 5060 for signaling 
and port 30000 - 31000 for media to the local host it is running on. To obtain a 
public IP address you can either choose to provide it manually or let sipxecs 
use STUN.

BR Robert