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

[Iñaki Baz Castillo]

2008/12/22 Daniel-Constantin Mierla <miconda at gmail.com>:
>> Well, as I said I don't need dealing with it if I use radius ACC since
>> only one BYE matching the dialog can trigger a SQL STOP action (other BYE's
>> matching this dialog will trigger radius STOP action, but not SQL action due
>> to "WHERE" clausules the SQL query).
>>
>> So the only I need is the proxy ensures that the BYE is not fraudulent,
>> for example, it's not a spoofed BYE from the user with RURI=same_user.
>>
>
> accounting only 200ok-ed BYEs will ensure that.
>
> By the way, are you accounting all session updates, e.g., re-INVITE, or just
> first INVITE and the BYE. There are billing systems that use the re-INVITEs
> due to session timers to estimate the duration when BYE is missing.

Well, except in the case of BYE sent by the gateway (since the
attacker could reply non-200 to the BYE and mantain the session open).
But anyway, I imagine this exotica case:

- alice (attacker) speaking with the PSTN gateway.

- alice sends this BYE:

  BYE sip:PSTN_NUMBER at PSTN_GATEWAY SIP/2.0
  Route: <sip:PROXY_IP>
  Route: <sip:alice at ALICE_PHONE_IP>

The proxy could check the RURI to know that the destination in the
gateway, so to account a BYE the gateway must reply 200 OK to the BYE.
The first route is the proxy, so there is loose routing (as expected
and required).
But there is other Route pointing to alice again, so the BYE would be
sent to alice who will reply 200 OK to this spoofed BYE.
The proxy would trigger STOP action but the call session remains.


>> Anyway, it seems really complex and a post-accounting process should be
>> needed as you say. I will try to avoid needing it doing the billing in a
>> B2BUA.
>>
>
> Don't you have a rating engine to compute the costs? Also, I assume you have
> a tool to aggregate the cdrs from your providers with what you get on proxy.
> Indeed, accounting/billing is quite complex, depending also on what type of
> charging you have (e.g., time of the day based charging).

Well, now I'm designing it, not a real implementation now.


> Would be interesting to see what would be more efficient, a b2bua that may
> give better CDRs or a stand alone application that digest the accounting
> events. It is clear that a b2bua introduces delays, therefore reduces the
> processing capacity -- probably difference is not that big.

I think (but not 100% sure) that a B2BUA could check all the requests
in both legs to ensure that no spoofed accounting action is performed,
so the accounting would be in realtime (without the need of an
external application re-checking it).
But this is just theory XD


Thanks a lot for your comments.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>