[asterisk-users] Why Nat=yes Nat=no Option?

[Alex Balashov]

Klaus Darilion wrote:

> Very often the authentication between gateway and proxy is done based on 
> IP address.
> 
> Now, the customers SIP client at 3.3.3.3 REGISTERs to the proxy with 
> Contact: sip:0900123456 at 2.2.2.2.
> 
> If now there is an incoming call to the customer, the Proxy/Asterisk 
> will send the INVITE to 2.2.2.2 = the gateway. The gateway happily 
> accepts the call - as you see there is lots of fraud possibilities.

This is true and a very good observation!  This kind of tomfoolery seems 
to be among the numerous pitfalls that come with trusted-IP SIP trunks.

I am persuaded by your suggestion that in a typical ITSP scenario it may 
be wise to restrict the contact domain provided that the end-users are 
understood to be end-user phone devices/CPE.  If, however, there are 
wholesale / multichannel operations where the far-side equipment and 
network topology can operate according to various principles, that may 
not be wise.

And in any case, to go back to the original question, I am not sure that 
the most practical thing to do is to simply ignore the contact domain; 
it is better to restrict it to ensure that the user does not attempt to 
route calls over your trusted IP trunks, if you have them.  It seems to 
me that there are far too many possible IP telephony applications where 
the contact address may differ from the proximate sender of the request 
on the IP level.  It would not work in almost any multilateral 
peering/clearing/settlement setup.

No, as you and Steve rightly point out, IP phones on simple home LANs 
fronted by consumer broadband routers in a many-to-one NAT scenario do 
not fall into that category.

But we're talking about what is reasonable to assume here for every 
single installation by default.  It was said recently in this thread 
that Asterisk is designed to be a PBX, but asterisk.org says "Asterisk 
is the world's leading open source PBX, telephony engine, and telephony 
applications toolkit."

That should give a lot of pause and be carefully reflected on.

> There are some methods to prevent this (like e.g. blacklists in openser) 
> but a simple workaround which works fine in most ITSP setups is to 
> ignore the user provided contact.

I would insist it is more parsimonious and even-handed to "restrict" 
than to "ignore."

>> I think the question here really is about good default behaviours and 
>> assumptions, not whether validation for security is a good idea, though. 
> 
> I think the default value is ok. I works for 99% and it increases 
> security. If someone has a big complex setup he probably has the 
> knowledge of the nat= setting and knows the impacts of changing the value.

The question is one of principle:  whether they should have to deal with 
nonstandard behaviour by default. or enable it explicitly.

I am also not sure it works for 99%.  Perhaps in the restricted context 
you specified - ITSPs providing POTS replacement services to end users, 
or companies using Asterisk as an internal PBX open to the outside with 
mobile users.  But I don't think that's anywhere near 99%.  Just about 
any scenario inside an ITSP where Asterisk would be used as a feature 
server, voicemail server, or other application element and receive calls 
via a proxy would not invite this behaviour.

Perhaps a reasonable compromise would be to follow the general logic 
that seems to be behind OpenSER's nathelper module's nat_uac_test() or 
nat_traversal's client_nat_test() function parameters and enable NAT 
behaviour by default for RFC 1918 contact addresses, but not others.  I 
could get behind that.

-- Alex

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599