On Thu, Feb 12, 2009 at 9:26 AM, Scott Lawrence <[email protected]> wrote: > > On Wed, 2009-02-11 at 17:59 -0500, M. Ranganathan wrote: >> >> Currently, if I know your public IP address, I can simply send an >> INVITE to num...@sipxbridge-public-ip-address and right now (i.e. in >> sipxbridge today), that call will go through. You would not need to >> have an account with any ITSP or even be calling from a phone to make >> a call to sipxbridge. We will need to disallow this case as you state. > > I consider the fact that that works to be an acceptable side effect, but > not an essential feature.
It might in fact be an undesirable side effect ( given the fact that it exposes the PBX to DoS attacks ) :-) > >> We are, however, missing some configuration soupport. We would need to >> add some additional support in sipxconfig for cases that do not >> require registration but which do send INVITE from an Inbound Proxy ( >> not the same as the ITSP Registrar field that we have today). >> >> I have come across ITSPs that support redundancy where the IB proxy >> can be one of a list of addresses (an example of such a setup would be >> AT&T) which would require you to know all inbound proxy server >> addresses so this would imply we need to support a list of such >> addresses in the configuration field (AT&T does not support DNS SRV - >> they directly use IP addresses for configuration). > > I assume that by "Inbound Proxy" you mean "the Service Provider proxy > that sends calls to the PBX". > > Yes, _if_ you were to do this using source IP addresses as the filter, > you'd need to know the whole list (or, better, a name that could be > resolved via DNS to the whole list, which would let the provider change > the list without reconfiguring the PBXs). Correct. In particular this covers the AT&T requirements. > > As I said, it would be even better to insist on mutual TLS - don't > accept an INVITE unless it comes on a TLS connection whose peer has a > certificate that names it as the Service Provider. > Indeed! Given that most (all that I have tested in fact) do not even support TCP, I think we have some way to go on that score. > > -- 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
