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. SipXbridge is not a Registrar and hence cannot follow that approach. A signed sipX identity seems like a reasonable approach to authenticate requests orignating from the proxy. For the ITSP facing side, an ITSP may not support a challenge originating from SIPXbridge. Indeed, some ITSPs simply rely on IP address for authentication (without any prior Registration) and I have to support such cases. I cannot, in fact always identify the ITSP on the basis of the inbound request. Ranga > > Thanks, > Mark. > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev > -- M. Ranganathan _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
