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

[Kevin P. Fleming]

OK, in order to bring this to a close (after the thread died a bit while 
many of us were at AstriCon and our post-AstriCon recovery locations), 
this is the current proposal on the table:

* Change the default for the sip.conf 'nat' configuration option to 
'force_rport' in versions of Asterisk that offer that value, and to 
'yes' in versions that do not.

* Add a strongly-worded warning in the sample sip.conf file (and on the 
wiki, and anywhere else that seems appropriate) about changing the 'nat' 
setting for a specific user/peer/friend to any value other than the one 
in the [general] section (or the default, if no value has been set in 
the [general] section). For some combinations of 'nat' settings, the 
user/peer/friend so configured could become discoverable through the 
method documented in this thread.

* For Asterisk trunk (and possibly Asterisk 10), consider sending 
failure responses to *both* the port the request was received from *and* 
the port listed in the top-most Via header. This would only be done for 
non-authenticated requests, e.g. any request that cannot be definitively 
associated with a user/peer/friend (through actual authentication, or IP 
address/port matching, or any other valid mechanism). A configuration 
option (valid only at the [general] level) would be provided to disable 
this behavior if necessary.

The first two changes would be made to the release branches for Asterisk 
1.4, 1.6.2, and 1.8, with a suitable security advisory published (and 
new releases made from those branches). These same changes would be made 
to the release branch for Asterisk 10 and trunk, along with 
investigating whether a patch to implement the dual-response mechanism 
would be feasible in a short time frame (less than two weeks). Based on 
the result of that process, a decision can be made whether it would be 
merged at all, and into the Asterisk 10 branch, or just trunk (depending 
on its risk of causing regressions).

If I've incorrectly represented the consensus here please speak up; I'd 
like to get moving on making these changes in the next few days so we 
can put this behind us. Thanks for all your input on this subject, it 
has been very valuable!

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org