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

[Olle E. Johansson]

25 okt 2011 kl. 15:03 skrev Kevin P. Fleming:

> On 10/25/2011 01:53 AM, Olle E. Johansson wrote:
>> I think we need to divide this discussion into two parts:
>> 
>> 1) NAT handling for SIP
>> 2) NAT handling for media
> 
> This discussion has only been about SIP signaling, not media. If there are security issues related to NAT settings for media handling, please bring those up in a separate thread.
> 
>> We should also discuss
>> 
>> a) NAT handling before authentication
>> b) NAT handling after authentication and device matching
>> c) NAT handling with peer matching on IP and no AUTH
>> d) NAT handling with user matching on name and no AUTH
> 
> That's what this entire thread is about.
Good, then we're in agreement. I guess I was confused by some of the comments and just wanted to clear up things.

> 
>> I think 2d - media handling for users matching on username and no auth is where we really end up in dangerous waters.
>> The SIP part is much easier to handle and say
>>  -  if we match a peer on IP and port, follow those settings
>>  - otherwise always follow [general] settings before auth
> 
> I've received an email (not to the list) from a user who has a set of devices that will not work with 'nat=force_rport' or 'nat=yes' in place (they send their SIP requests from a random port number but require replies to the port included in the top-most Via header). These devices would be unable to authenticate with a [general] setting that forced rport-style behavior. The devices in question are recent-model Cisco phones with SIP firmware; Olle, since you are at SIPit 29 right now, can you ask the Cisco guys there if this behavior is configurable or optional?
Those Cisco guys are not the Cisco guys I have around the table, sorry. 

> As I've thought about Tilghman's proposal to reply to *both* ports in cases where we cannot be sure which one we should reply to, I'm starting to think that might be a good option (but optional... we'd need a configuration item to disable it). Yes, it is a small traffic amplification attack vector, but a very small one (and SIP over UDP is already a traffic amplification attack vector by its very nature anyway).
I don't really see the point, but I must be missing something here. I'll check around and see if we can get help cracking this nut.

The problem is still 2d - not doing IP matching but username matching. And actually 2e - registrations from peers. At that point we can't match on IP, because we still don't have it, so we match on the To: uri.

/O