[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