On Wed, Dec 9, 2009 at 12:13 PM, Scott Lawrence wrote: > >> well, the error response is not correct... the sipXbridge thinks that > >> the message has not been through the proxy, but it clearly has. > >> > >> Ranga - can you take a quick look at the trace and see if you see why > >> the INVITE in frame 33 is rejected?
On Wed, Dec 9, 2009 at 12:46 PM, M. Ranganathan <[email protected]> wrote: > > It is rejected because that topmost via header has an address of > > 127.0.0.1 in the sent-by. > > > > Here is the algorithm that is currently used to determine whether a > > request originated from the sipx proxy server. > > > > SipXbridge does a DNS lookup for the proxy domain name and keeps a > > list of IP addresses corresponding to the Proxy Domain. > > SipXbridge looks at the address in the topmost via header sent-by > > field and compares that address to the set of addresses determined in > > the previous step. > > I agree that I ought to be using the received parameter for this test > > and I will revise it accordingly in 4.1. On Wed, 2009-12-09 at 14:47 -0500, M. Ranganathan wrote: > Sorry I made a mistake. > > The logic right now checks that both the following conditions are true: > > 1. The topmost via header address resolves to an address that the > proxy domain resolves to. > 2. If a received parameter is presen in the topmost via header then > that should be address that the proxy domain resolves to > I have just committed a fix in 4.1 that just uses the recceived > parameter to make that check if it is present. Using Via header addresses even with the received parameter is ultimately making a security-critical decision based on an IP address, which is very weak. I think we should strengthen this test. There are two possibilities that I can see now: A. Use TLS between the proxy and the bridge and insist on authenticated connections. We're putting TLS support into the bridge now anyway, and it's on the roadmap for the proxy soon. B. Have the bridge look for the 'auth' indication in the sipXecs-rs attribute of a Record-Route or Route header. That indication is what the authorization function of the proxy inserts to verify for itself that the dialog has been authorized - the route state incorporates a signed hash, so it's hard to forge (harder than an IP source address, certainly). the latter is much lighter weight and, I think, sufficiently secure for our purposes (though we might want to modify the signature to also incorporate the url that is in the route... have to think about the implications of that). Thoughts? Also, as I said in the thread on the user list, the bridge should return the rejected request in a message/sipfrag body for this error. Usually, this error will be the result of some misbehaving or misconfigured component skipping the proxy, and having the request message in the response would make it easier to diagnose without looking into the sipXecs logs. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
