20 Dec
2008
20 Dec
'08
11:33 a.m.
Hello,
On 12/19/08 01:02, Klaus Darilion wrote:
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
I think that for some particular cases, a two-step accounting is a good
solution. Like:
- request fwd'ed
- reply fwd'ed
I am thinking when one is willing to account MESSAGEs for example. Once
forwarded, the service is delivered. If you restart the proxy, then
200OK won't match an active transaction.
The second step could be just a log message somewhere, when it happens a
corner case like no active transaction, so additional tools can recover
proper billing records (here special security checks have to be applied
anyhow).
I agree with you, that best place for acc is the gateway. Some times the
service involves more than audio calls, so more things need to be
accounted, on the proxy.
Cheers,
Daniel
regards
klaus
Iñaki Baz Castillo wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
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?
_______________________________________________
Users mailing list
Users(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users