22 Dec
2008
22 Dec
'08
4:33 p.m.
2008/12/22 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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@PSTN_GATEWAY SIP/2.0
Route: <sip:PROXY_IP>
Route: <sip:alice@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.
Well, now I'm designing it, not a real implementation now.
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. 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). 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(a)aliax.net>