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:[EMAIL PROTECTED] > > 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 _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
