On Fri, 2008-09-05 at 21:15 -0400, M. Ranganathan wrote: > On 9/5/08, Mark Gertsvolf <[EMAIL PROTECTED]> wrote: > > I noticed Scott's comments about the fact that we should not use IP > > address/port as an authenticator: > > http://list.sipfoundry.org/archive/sipx-dev/msg13439.html. > > With that in the past the best way I can think of to police PSTN calls > > via gateways would be to use IP address/port-based ACLs on the gateway > > to restrict calls to only those coming from (and > > authenticated/authorized by) sipXproxy. This ensures gateway calls can > > not be made by pointing a SIP endpoint directly to the gateway. > > > > sipXbridge is a new stand alone proxy server application, which is a > > gate for outgoing calls via ITSPs. I am wondering what can be done or is > > being considered as a solution to prevent people from sending calls > > directly to sipXbridge and bypassing the sipXproxy. > > > > Alternatively, are there mechanisms implemented in sipXbridge to reject > > calls from anywhere but the sipXproxy. I suppose logic that would use > > signed sipX-identity can be used to implement such a mechanism. > > > > This is a good point. Currently the sipx proxy does not seem to > challenge INVITE. However, it does challenge REGISTER and presumably > only accepts INVITE from previously REGISTERed Contacts.
Nope. Registration has NO effect other than to establish a contact for routing - it does not in any way effect what we accept FROM an address. Before yesterday, the strategy was to challenge only calls that require some permission (which should include ITSP calls, because they are probably billable). As of yesterday, calls From and locally defined user will be challenged and get a P-Assserted-Identity header added when they are authenticated. Mark makes an excellent point - sipXbridge should have the ability to restrict calls to those coming directly from the proxy, as we advise for any gateway. Doing this by IP address is the only way most gateways do it (I didn't say we never do this, only that we shouldn't). The right solution would be to use TLS both between the proxy and the sipXbridge, and between sipXbridge and the ITSP. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
