The problem here is that you have a device that is trying to charge, but
controls nothing to enforce its charging. If it wants to charge, then it
ought to have something (e.g. the media stream) that it can "turn off"
when the call terminates. Then there won't be fraud.
If the proxy doesn't control the media path, then *what* is it charging
for? If it is providing no services after the call is set up, then it
should only charge for call setup, not call duration.
I realize many deployed systems do this anyway - its just popular to
charge for things that cost you nothing - its a good way to make money.
Paul
Iñaki Baz Castillo wrote:
> Hi, I really wonder how vulnerable can be a proxy for accounting
> purposes (even if I already know it's commonly implemented).
> Theorically a proxy doesn't need to be dialog aware, it must be
> transaction aware, so when an INVITE/CANCEL/BYE arrives it sends the
> accounting info (for example, using Radius).
>
> Let me explain the following case:
>
>
> --------------------------------------------------------------------------
> alice proxy (Acc) gateway
>
> INVITE (CSeq 12) ------>
> <-------- 407 Proxy Auth
>
> INVITE (CSeq 13) ------>
> INVITE (CSeq 13) ------>
> <------------------- 200 Ok
> <------------------- 200 Ok
> << Acc START >>
> ACK (CSeq 13) ----------->
> ACK (CSeq 13) ----------->
>
> <******************* RTP ************************>
>
> # Fraudulent BYE !!!
> BYE (CSeq 10) ----------->
> << Acc STOP >>
> BYE (CSeq 10) ----------->
> <-- 500 Req Out of Order
> <-- 500 Req Out of Order
> --------------------------------------------------------------------------
>
> The call hasn't finished, but the proxy has ended the accounting for
> this call since it received a BYE.
>
> So, the caller/attacker just needs to send a BYE with lower CSeq (or
> the same as the last in-dialog request) so the UAS will ignore it (500
> "Request Out Of Order"). But since the proxy doesn't know about
> dialogs, it will perform the Acc STOP action for that call (From_tag,
> To_tag, Call-ID).
>
>
> How could a non dialog awareness proxy solve it?
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
