[Kamailio-Users] Accounting: How to avoid a fraudulent BYE with lower CSeq?
Klaus Darilion
klaus.mailinglists at pernau.at
Fri Dec 19 00:02:44 CET 2008
my 2 cents:
1. nice attack ;-)
2. perform accounting only on a dialog statefull node
2.1 the gateway is the most accurate accounting source
2.2 if you need proxy based accounting use a media relay which you
disable on BYE
regards
klaus
Iñaki Baz Castillo wrote:
> Hi, first of all I'm sorry for this cross-posting, but I think it
> could be interesting for any SIP proxy with accounting capabilities.
>
> I'm thinking in the following flow in which the caller/attacker would
> get an unlimited call (but a limited CDR duration):
>
> --------------------------------------------------------------------------
> attacker Kamailio (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 Kamailio has ended the accounting for
> this call since it received a BYE. And this BYE will generate a
> correct ACC Stop action (since it matches From_tag, To_tag and
> Call-ID).
>
> I think this is *VERY* dangerous and I hope I'm wrong.
>
> Would help the dialog module here? does the dialog module check the
> CSeq of the BYE in some way and could it prevent Kamailio from
> generating the ACC STOP action? (I don't think so).
>
> I've also asked in SIP-implementors and an idea could be generating
> the ACC STOP action when receiving the 200 OK for the BYE (and not
> when receiving the BYE itself). Of course this will be valid when the
> gateway is the recipient of the BYE (and we know the gateway is not an
> "attacker"), but this is not valid when the recipient of the BYE is an
> user since it could send no reply for the BYE.
>
> The only solution I see is:
>
> - Using the dialog module, Kamailio should check the CSeq value in the BYE.
> 1) Kamailio should forward the BYE just in case the CSeq is higher
> than the actual CSeq for this dialog direction.
> 2) Kamailio should generate the ACC STOP action just in case the CSeq
> is higher than the actual CSeq for this dialog direction.
>
> Both 1) and 2) are needed since a gateway could accept a BYE with
> wrong CSeq. In this case the call is ended but the accounting STOP
> action doesn't exist (infinite call).
>
> But I think this is too complex, isn't it?
>
>
>
More information about the Users
mailing list