Klaus Darilion wrote: > This is a different scenario. In this case of course I want the public > IP of the client, not of the load balancer. So, yes - in this case > nat=no is useful for Asterisk. Nevertheless I ignore the IP provided by > the client in the contact header completely - I always use the public IP > of the client. Thus, in a loadbalancer setup I would configure the load > balancer to ignore the advertised IP but use the "received" IP > (implementation depends on the actual setup and used components). > > But as a basic rule - never ever trust the client. Storing and using the > Contact provided by the client without any screening is dangerous.
Hm. Interesting. I am curious: I agree that validation should be in place, but why do you think that distrust of the client's contact URI should be elevated to a "basic rule?" What incentive do UACs have to provide an illegitimate contact URI? So the UAS will send responses somewhere else, to another UAC that will reject the request because it the dialog/transaction parameters do not match? Man-in-the-middle attacks from spoofed requests containing bogus contact domains? That can also be carried out with IP spoofing and other more traditional means on the IP layer itself. But there is a difference between screening and distrusting by default, particularly in scenarios where it may be explicitly undesirable for the received IP to be used as the contact, such as in switch assemblies where the signaling agents are partitioned somehow. I think the question here really is about good default behaviours and assumptions, not whether validation for security is a good idea, though. In the scenario in the last paragraph, I may wish to allow contact addresses from other hosts on the same originating subnet but not on foreign networks (validation), but not to use the received IP (assumption of NAT). -- 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