[OpenSIPS-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?

[Victor Pascual Ávila]

On Wed, Jan 7, 2009 at 12:44 PM, Dan Pascu <dan at ag-projects.com> 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
>> > >
>> > > <bogdan at voice-system.ro> 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
>> > > Users at lists.opensips.org
>> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> --
> Dan
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>



-- 
Victor Pascual Ávila