[asterisk-dev] SIP, NAT, security concerns, oh my!

[Simon Perreault]

First, thanks a lot for the interesting read! It must have taken a lot 
of time to write this is such detail.

On 10/21/2011 06:52 PM, Kevin P. Fleming wrote:
> Option 1:
>
> Recommend that all users to switch to TCP (or TLS) for SIP
> communications. If they have a version of Asterisk that supports TCP,
> and devices that also support it, they can disable UDP support and avoid
> this problem entirely (since TCP does not have these NAT traversal
> issues to deal with).

Not gonna happen. People need UDP for tons of good reasons, one of them, 
since we're already talking about NATs, being that hole punching works 
much more often for UDP than for TCP.

> Option 2:
>
> Change Asterisk to always act in 'force_rport' mode, period
> (non-configurable). It is possible that there may be some SIP UAs that
> would break if Asterisk did not respond to the port listed in the
> top-most Via header, but it seems rather unlikely at this point. Such
> UAs would almost never be able to be used successfully behind a NAT
> device. In addition, it is remotely possible that there are some SIP UAs
> that will break if they see 'rport=<xxxx>' in the Via header returned by
> Asterisk in its responses.

I agree with your assessment. It would fix the security issue but could 
cause interoperability issues.

> Option 3:
>
> Allow 'force_rport' mode to be disabled, but change the default to
> enable it, in all currently maintained branches (1.4, 1.6.2, 1.8, 10 and
> trunk). This has the same caveats as Option 2, but at least if a user
> *does* have one of these bizarre SIP UAs to deal with, they can set
> 'nat=no' for that device after carefully considering the ramifications
> of the change.

The security issue manifests itself when the general setting differs 
from the per-peer setting. So I don't see how option #3 fixes anything. 
Right now the default general and per-peer settings are identical (no). 
Changing them both to another value (yes) would leave us in the same 
situation. What value should be the default is orthogonal to the 
security issue. (FWIW, it should be "yes".)

Therefore, I propose Option 4:

Remove or strongly discourage the use of the per-peer setting. This 
would ensure consistent behaviour for every extension, and leave the 
behaviour configurable globally. I can live with that personally. 
Strongly discouraging could be accomplished by linking to this thread 
from the default config file comments.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca