On Wed, Jan 7, 2009 at 12:44 PM, Dan Pascu <[email protected]> wrote: > > On second thought, I think there is a simple way to avoid any fraud > attempt, without checking anything in the BYE message. If the system can > be instructed that for every BYE that is received to also generate itself > a pair of BYEs from the dialog module, then even if the sender did send > an invalid BYE that attempts to fraud the system, the BYEs generated by > the dialog module will be correct and end the session or in the worst > case they will receive a "session does not exist" reply that is ignored > anyway.
It sounds good but I'm not sure about the scalability of this. Naive question- Is it better (wrt performance metrics) generating a couple of BYEs for every single dialog rather than checking the original BYE request? -Victor > > Also if one uses the mediaproxy module on top of the dialog, then even if > the BYE is not accepted by the gateway, if it is accepted by the proxy > and ends the dialog it will also close the media session rendering the > fraud attempt pointless as even though the PSTN gateway didn't close the > call, there is no media path anymore forcing them to hang-up anyway. > Same is true even if mediaproxy doesn't run on top of the dialog module, > as long as end_media_session is called on BYEs > > On Wednesday 07 January 2009, Dan Pascu wrote: >> There is more than one way to skin a cat as they say and this case is >> no exception. There are multiple ways to send a BYE that will not be >> accepted but still make the proxy end the session (at least in the >> current implementation): >> >> 1. Lower CSEQ number >> 2. Low max forwards value, so the BYE doesn't reach the gateway >> 3. Invalid destination, so it gives timeout after a while >> 4. Wrong call-id, from-tag, to-tag which will make the BYE be rejected >> by the gateway >> >> All these have in common that they will get a negative reply to the >> BYE. So the idea would be not to not the dialog unless a 200 OK for the >> BYE is received. >> >> This can be worked around however too. I can send the BYE with all the >> dialog identification elements and the correct CSEQ number, but to a >> different ruri, pointing back to myself, and I can reply with 200 OK to >> the BYE. To avoid this the proxy would have to check the ruri as well. >> >> But then I can send one with the proper ruri, but a different route set >> that puts me in the front of the gateway, so when I receive the BYE, >> instead of forwarding it to the gateway as the route set requests, I >> reply myself with a 200 OK making it look like it came from the >> gateway. >> >> In the end it means, the proxy will have to verify everything (dialog >> identification elements, cseq, ruri, route set) to avoid fraud and also >> wait for a 200 OK, which makes it look more like a b2bua after all >> >> In the end the simplest solution is to eliminate the incentive for >> users to fraud that system, not to put bigger or more locks on it. This >> can be done by using a flat-fee model, but I agree that lobbying for >> this will fell on deaf ears with the big players that own the gateways. >> Still this is the simplest solution that not only eliminates the >> incentive for fraud, but also simplifies the over complex billing >> system and eliminates the burden the billing puts on a system with >> millions of users that have to be accounted in realtime. >> >> On Wednesday 07 January 2009, Adrian Georgescu wrote: >> > The dialog module could eventually be used to detect out of sync Cseq >> > and take decision to terminate the call. Is this feasible? >> > >> > Adrian >> > >> > On Dec 19, 2008, at 3:59 PM, Victor Pascual Ávila wrote: >> > > On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu >> > > >> > > <[email protected]> wrote: >> > >> Hi Iñaki, >> > >> >> > >> Have you consider requesting auth for the BYE ? from SIP point of >> > >> view >> > >> is perfectly valid.... >> > > >> > > I'm afraid this would only prevent external attackers but does not >> > > protect you from your own customers-- guys who have the credentials >> > > and wanna call for free. >> > > >> > > Cheers, >> > > -- >> > > Victor Pascual Ávila >> > > _______________________________________________ >> > > Users mailing list >> > > [email protected] >> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > -- > Dan > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > -- Victor Pascual Ávila _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
