Accounting: How to avoid a fraudulent BYE with lower CSeq?

classic Classic list List threaded Threaded
45 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
Hi, I'm thinking in the following flow in which the caller/attacker
would get an unlimited call (but a limited CDR duration):

--------------------------------------------------------------------------
attacker                     OpenSIPS (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 OpenSIPS 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 OpenSIPS from
generating the ACC STOP action? (I don't think so).

Any idea?




--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Raúl Alexis Betancor Santana
El Jueves, 18 de Diciembre de 2008 10:55, Iñaki Baz Castillo escribió:

> Any idea?

that's why we account based on gateways's CDR information and not on proxy
information ... ;-), if you send a fraudulent bye, gateway will not accept
it, and will not end the call.

Regards
--
Raúl Alexis Betancor Santana


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
In reply to this post by Iñaki Baz Castillo
2008/12/18 Iñaki Baz Castillo <[hidden email]>:

> The call hasn't finished, but OpenSIPS 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 OpenSIPS 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, OpenSIPS should check if the CSeq value in the BYE.
  1) OpenSIPs should forward the BYE just in case the CSeq is higher
than the actual CSeq for this dialog direction.
  2) OpenSIPs 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?



--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
I've received a solution in SIP-implementors that makes sense:

> The accounting should end when you received the BYE from your gateway.
> Regardless if or what the client answers, you know that the gateway has ended
> the media before it sends the BYE (it should).
>
> The other way around, you know the gateway will has ended the call if it sends
> out the 200 OK for a BYE.
>
> You can only trust the gateway, so you can stop accounting if you receive a
> BYE or a response on a BYE from your gateway, You shouldn't trust requests
> and responses from clients, only from your gateway.


I'll check if this behaviour is possible with OpenSIPS acc module (it
requires doing the ACC for BYE when receiving the 200 OK).


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Dan Pascu
On Thursday 18 December 2008, Iñaki Baz Castillo wrote:

> I've received a solution in SIP-implementors that makes sense:
> > The accounting should end when you received the BYE from your
> > gateway. Regardless if or what the client answers, you know that the
> > gateway has ended the media before it sends the BYE (it should).
> >
> > The other way around, you know the gateway will has ended the call if
> > it sends out the 200 OK for a BYE.
> >
> > You can only trust the gateway, so you can stop accounting if you
> > receive a BYE or a response on a BYE from your gateway, You shouldn't
> > trust requests and responses from clients, only from your gateway.
>
> I'll check if this behaviour is possible with OpenSIPS acc module (it
> requires doing the ACC for BYE when receiving the 200 OK).

This is how it actually works if you set the accounting flag (as opposed
to calling the acc functions yourself in the script on requests).

--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Bogdan-Andrei Iancu
In reply to this post by Iñaki Baz Castillo
Hi inaki,

Iñaki Baz Castillo wrote:

> I've received a solution in SIP-implementors that makes sense:
>
>  
>> The accounting should end when you received the BYE from your gateway.
>> Regardless if or what the client answers, you know that the gateway has ended
>> the media before it sends the BYE (it should).
>>
>> The other way around, you know the gateway will has ended the call if it sends
>> out the 200 OK for a BYE.
>>
>> You can only trust the gateway, so you can stop accounting if you receive a
>> BYE or a response on a BYE from your gateway, You shouldn't trust requests
>> and responses from clients, only from your gateway.
>>    
>
>
> I'll check if this behaviour is possible with OpenSIPS acc module (it
> requires doing the ACC for BYE when receiving the 200 OK).
>  
You can control this via the "failed_transaction_flag" =
http://www.opensips.org/html/docs/modules/1.4.x/acc.html#id2500684

If direction is from GW, set the flag and account BYE disregarding the
reply code; If direction is from client, do not set and acount BYE only
if reply is 200 OK

Regards,
Bogdan


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Bogdan-Andrei Iancu
In reply to this post by Iñaki Baz Castillo
Hi Iñaki,

Have you consider requesting auth for the BYE ? from SIP point of view
is perfectly valid....

Regards,
Bogdan

Iñaki Baz Castillo wrote:

> Hi, I'm thinking in the following flow in which the caller/attacker
> would get an unlimited call (but a limited CDR duration):
>
> --------------------------------------------------------------------------
> attacker                     OpenSIPS (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 OpenSIPS 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 OpenSIPS from
> generating the ACC STOP action? (I don't think so).
>
> Any idea?
>
>
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Victor Pascual Avila
On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu
<[hidden email]> wrote:
> Hi Iñaki,
>
> Have you consider requesting auth for the BYE ? from SIP point of view
> is perfectly valid....

I'm afraid this would only prevent external attackers but does not
protect you from your own customers-- guys who have the credentials
and wanna call for free.

Cheers,
--
Victor Pascual Ávila
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Bogdan-Andrei Iancu
Victor Pascual Ávila wrote:

> On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu
> <[hidden email]> wrote:
>  
>> Hi Iñaki,
>>
>> Have you consider requesting auth for the BYE ? from SIP point of view
>> is perfectly valid....
>>    
>
> I'm afraid this would only prevent external attackers but does not
> protect you from your own customers-- guys who have the credentials
> and wanna call for free
>  

I guess you are refering to attacks like sending to proxy BYEs with RURI
or Route info pointing somewhere else than the GW and the proxy will
record end of call, but the GW does not actually receive a BYE.

Is this correct?

Regads,
Bogdan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
In reply to this post by Bogdan-Andrei Iancu
El Viernes, 19 de Diciembre de 2008, Bogdan-Andrei Iancu escribió:

> > I'll check if this behaviour is possible with OpenSIPS acc module (it
> > requires doing the ACC for BYE when receiving the 200 OK).
>
> You can control this via the "failed_transaction_flag" =
> http://www.opensips.org/html/docs/modules/1.4.x/acc.html#id2500684
>
> If direction is from GW, set the flag and account BYE disregarding the
> reply code; If direction is from client, do not set and acount BYE only
> if reply is 200 OK

Ok, thanks a lot.


--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
In reply to this post by Bogdan-Andrei Iancu
El Viernes, 19 de Diciembre de 2008, Bogdan-Andrei Iancu escribió:
> I guess you are refering to attacks like sending to proxy BYEs with RURI
> or Route info pointing somewhere else than the GW and the proxy will
> record end of call, but the GW does not actually receive a BYE.

Victor just means that a real customer could authenticate his spoofed BYE but
this would be correctly handled with your suggestions in other mail:

--------------
You can control this via the "failed_transaction_flag" =
http://www.opensips.org/html/docs/modules/1.4.x/acc.html#id2500684

If direction is from GW, set the flag and account BYE disregarding the
reply code; If direction is from client, do not set and acount BYE only
if reply is 200 OK
----------------

But what you mean now is really worse than what I was thinking about XD
For example, a legitime user in a legitime call with the gateway could send a
spoofed BYE with RURI pointing to **himself** (and reply 200 to himself), so
the proxy would account this call as terminated !!!

There is no way to prevent it!!!

--
Iñaki Baz Castillo

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Victor Pascual Avila
In reply to this post by Bogdan-Andrei Iancu
On Fri, Dec 19, 2008 at 6:10 PM, Bogdan-Andrei Iancu
<[hidden email]> wrote:

> Victor Pascual Ávila wrote:
>>
>> On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu
>> <[hidden email]> wrote:
>>
>>>
>>> Hi Iñaki,
>>>
>>> Have you consider requesting auth for the BYE ? from SIP point of view
>>> is perfectly valid....
>>>
>>
>> I'm afraid this would only prevent external attackers but does not
>> protect you from your own customers-- guys who have the credentials
>> and wanna call for free
>>
>
> I guess you are refering to attacks like sending to proxy BYEs with RURI or
> Route info pointing somewhere else than the GW and the proxy will record end
> of call, but the GW does not actually receive a BYE.
>
> Is this correct?

Yes, indeed

--
Victor Pascual Ávila
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Jiri Kuthan
In reply to this post by Bogdan-Andrei Iancu
authentication does not provide actually value here. dialog would not
either, since
the same trick can be achieved for example by low max-forwards. IMO the
proper
choice is accounting from the gateway, which provides the actual service.
A proxy can only provide an approximation which is inherentely to some
extent
more error-prone than the box doing the actual job.

-jiri

Bogdan-Andrei Iancu wrote:

> Hi Iñaki,
>
> Have you consider requesting auth for the BYE ? from SIP point of view
> is perfectly valid....
>
> Regards,
> Bogdan
>
> Iñaki Baz Castillo wrote:
>> Hi, I'm thinking in the following flow in which the caller/attacker
>> would get an unlimited call (but a limited CDR duration):
>>
>> --------------------------------------------------------------------------
>> attacker                     OpenSIPS (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 OpenSIPS 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 OpenSIPS from
>> generating the ACC STOP action? (I don't think so).
>>
>> Any idea?
>>
>>
>>
>>
>>  
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Adrian Georgescu
I beg to differ, but this is just my humble opinion based on my experience with my particular customers.

The most economic and future-proof way to perform accounting for SIP sessions is the SIP Proxy server alone.

My personal experience is that gateways come and go in a provider configuration and they are in many cases under the control of a third-party that provides the PSTN termination service. When you do LCR across many different gateways, which are not even yours the only aggregation point for traffic is the SIP proxy that authenticates and authorizes the requests. Over time, the gateways change hands, get upgraded or removed much more often then the proxy itself, which maintains its central role over time. Secondly, once you do more the voice like video and other services that require billing and are not PSTN related, the SIP Proxy is the only network element that has access to the signalling and is able to generate accounting tickets.

Solving the accounting related problems at the SIP Proxy level is a worthwhile investment while other options are just temporary fixes that work in a particular case for a limited amount of time and that is a waste of money.

Adrian

On Jan 7, 2009, at 2:25 AM, Jiri Kuthan wrote:

authentication does not provide actually value here. dialog would not
either, since
the same trick can be achieved for example by low max-forwards. IMO the
proper
choice is accounting from the gateway, which provides the actual service.
A proxy can only provide an approximation which is inherentely to some
extent
more error-prone than the box doing the actual job.

-jiri

Bogdan-Andrei Iancu wrote:
Hi Iñaki,

Have you consider requesting auth for the BYE ? from SIP point of view
is perfectly valid....

Regards,
Bogdan

Iñaki Baz Castillo wrote:
Hi, I'm thinking in the following flow in which the caller/attacker
would get an unlimited call (but a limited CDR duration):

--------------------------------------------------------------------------
attacker                     OpenSIPS (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 OpenSIPS 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 OpenSIPS from
generating the ACC STOP action? (I don't think so).

Any idea?







_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Jiri Kuthan
Adrian Georgescu wrote:
> I beg to differ, but this is just my humble opinion based on my
> experience with my particular customers.
>
> The most economic and future-proof way to perform accounting for SIP
> sessions is the SIP Proxy server alone.

This may be probably ok, as long as you don't intend to use such accounting
data for billing. (which may be still useful)

The trouble is that proxy-produced accounting data is remarkable
incomplete and
inaccurate. It does not include QoS info, PSTN info, and they are
sensitive to
the attacks mentioned  before that make a BYE work for a GW but not for
a proxy
and vice versa, or other ways how BYE can be broken due to an error or
fraud.


>
> My personal experience is that gateways come and go in a provider
> configuration and they are in many cases under the control of a
> third-party that provides the PSTN termination service. When you do LCR
> across many different gateways, which are not even yours the
> only aggregation point for traffic is the SIP proxy
> that authenticates and authorizes the requests. Over time, the gateways
> change hands, get upgraded or removed much more often then the proxy
> itself, which maintains its central role over time.

There is certainly some invariable in a system but to my best knowledge
that's the DB backend (for example RADIUS) which gets almost never touched,
not a proxy server. The DB is the piece that is invariable, untouchable,
central in every respect, and therefore used for aggregation of usage data,
as directly as possible. I see little value on putting a SIP proxy on the
way from the service box knowing ALL call data and the final destination
of the usage data (some database).

(I agree proxy is the best place for authorization and authentication
but that's
a different story than accounting.)

> Secondly, once you
> do more the voice like video and other services that require billing and
> are not PSTN related, the SIP Proxy is the only network element that has
> access to the signalling and is able to generate accounting tickets.

That seems appealing indeed, it is just that I have encountered very few
(still some
though) who would be seriously billing for on-net calls on a per-minute
basis.
(they haven't found a way to do sell credibly a single usrloc lookup
on a per-minute basis or didn't consider the on-net share of traffic
significant or
thought the CDR producing expense was just not worth it) It makes sense
as you say
to produce CDRs in a proxy if termination is provided by a third party,
but to my
best knowledge these are based on their inaccuracy used for
reconciliation rather
than as source of authoritative data.


>
> Solving the accounting related problems at the SIP Proxy level is a
> worthwhile investment


Yes, but only if you don't care about accuracy and completeness of the
usage data,
i.e., you don't do billing. Otherwise the customer-care cost is
unpayable in addition
to the expense of doing it at all. The per-minute margins are so poor
and accurate
CDR processing is such an expense, that it alone explains the increasing
flat-rate
offerings. We have been doing it only in the reconciliation case you
mentioned,
merely as non-authoritative data.

If you however do have a scenario, in which accuracy and completeness
matters for
billing sake, investment in proxy-based CDR production seems to me only
likely to
produce liability.


-jiri

> while other options are just temporary fixes that
> work in a particular case for a limited amount of time and that is a
> waste of money.
>
> Adrian
>
> On Jan 7, 2009, at 2:25 AM, Jiri Kuthan wrote:
>
>> authentication does not provide actually value here. dialog would not
>> either, since
>> the same trick can be achieved for example by low max-forwards. IMO the
>> proper
>> choice is accounting from the gateway, which provides the actual service.
>> A proxy can only provide an approximation which is inherentely to some
>> extent
>> more error-prone than the box doing the actual job.
>>
>> -jiri
>>
>> Bogdan-Andrei Iancu wrote:
>>> Hi Iñaki,
>>>
>>> Have you consider requesting auth for the BYE ? from SIP point of view
>>> is perfectly valid....
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Iñaki Baz Castillo wrote:
>>>> Hi, I'm thinking in the following flow in which the caller/attacker
>>>> would get an unlimited call (but a limited CDR duration):
>>>>
>>>> --------------------------------------------------------------------------
>>>> attacker                     OpenSIPS (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 OpenSIPS 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 OpenSIPS from
>>>> generating the ACC STOP action? (I don't think so).
>>>>
>>>> Any idea?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email] <mailto:[hidden email]>
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Adrian Georgescu

On Jan 7, 2009, at 9:47 AM, Jiri Kuthan wrote:

Adrian Georgescu wrote:
I beg to differ, but this is just my humble opinion based on my experience with my particular customers.
The most economic and future-proof way to perform accounting for SIP sessions is the SIP Proxy server alone.

This may be probably ok, as long as you don't intend to use such accounting
data for billing. (which may be still useful)


I really mean accounting for billing purpose.

The trouble is that proxy-produced accounting data is remarkable incomplete and
inaccurate. It does not include QoS info, PSTN info, and they are sensitive to
the attacks mentioned  before that make a BYE work for a GW but not for a proxy
and vice versa, or other ways how BYE can be broken due to an error or fraud.

Again these are issue that need to be addressed and do not imply that SIP Proxy accounting is not possible or undesirable.

My personal experience is that gateways come and go in a provider configuration and they are in many cases under the control of a third-party that provides the PSTN termination service. When you do LCR across many different gateways, which are not even yours the only aggregation point for traffic is the SIP proxy that authenticates and authorizes the requests. Over time, the gateways change hands, get upgraded or removed much more often then the proxy itself, which maintains its central role over time.

There is certainly some invariable in a system but to my best knowledge
that's the DB backend (for example RADIUS) which gets almost never touched,
not a proxy server. The DB is the piece that is invariable, untouchable,
central in every respect, and therefore used for aggregation of usage data,
as directly as possible. I see little value on putting a SIP proxy on the
way from the service box knowing ALL call data and the final destination
of the usage data (some database).

When I referred to the accounting of the SIP Proxy server my intention was to denominate "The accounting server (like Radius) associated with the SIP Proxy and its DB backend" as in your example. So we talk about the same thing.

(I agree proxy is the best place for authorization and authentication but that's
a different story than accounting.)

Secondly, once you
do more the voice like video and other services that require billing and are not PSTN related, the SIP Proxy is the only network element that has access to the signalling and is able to generate accounting tickets.

That seems appealing indeed, it is just that I have encountered very few (still some
though) who would be seriously billing for on-net calls on a per-minute basis.
(they haven't found a way to do sell credibly a single usrloc lookup
on a per-minute basis or didn't consider the on-net share of traffic significant or
thought the CDR producing expense was just not worth it) It makes sense as you say
to produce CDRs in a proxy if termination is provided by a third party, but to my
best knowledge these are based on their inaccuracy used for reconciliation rather
than as source of authoritative data.

There are SIP service numbers that are not available on PSTN and charged per minute like PSTN destinations. Then there are peering agreements that allow calls to be routed based on results of ENUM lookups and still charged per minute. No gateway involved just an ENUM lookup. Only the SIP Proxy knows this information.

Solving the accounting related problems at the SIP Proxy level is a worthwhile investment


Yes, but only if you don't care about accuracy and completeness of the usage data,
i.e., you don't do billing. Otherwise the customer-care cost is unpayable in addition
to the expense of doing it at all. The per-minute margins are so poor and accurate
CDR processing is such an expense,

I beg to differ. The accounting can be as accurate as any other source like the PSTN gateway if you consider that a relevant comparison factor. The fact that a particular implementation does not address the flaws mentioned here does not rule out SIP Proxy accounting is not good. 

that it alone explains the increasing flat-rate
offerings. We have been doing it only in the reconciliation case you mentioned,
merely as non-authoritative data.

If you however do have a scenario, in which accuracy and completeness matters for
billing sake, investment in proxy-based CDR production seems to me only likely to
produce liability.


So is no debate here.


-jiri

while other options are just temporary fixes that
work in a particular case for a limited amount of time and that is a waste of money.
Adrian
On Jan 7, 2009, at 2:25 AM, Jiri Kuthan wrote:
authentication does not provide actually value here. dialog would not
either, since
the same trick can be achieved for example by low max-forwards. IMO the
proper
choice is accounting from the gateway, which provides the actual service.
A proxy can only provide an approximation which is inherentely to some
extent
more error-prone than the box doing the actual job.

-jiri

Bogdan-Andrei Iancu wrote:
Hi Iñaki,

Have you consider requesting auth for the BYE ? from SIP point of view
is perfectly valid....

Regards,
Bogdan

Iñaki Baz Castillo wrote:
Hi, I'm thinking in the following flow in which the caller/attacker
would get an unlimited call (but a limited CDR duration):

--------------------------------------------------------------------------
attacker                     OpenSIPS (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 OpenSIPS 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 OpenSIPS from
generating the ACC STOP action? (I don't think so).

Any idea?







_______________________________________________
Users mailing list
[hidden email] <[hidden email]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email] <[hidden email]>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Adrian Georgescu
In reply to this post by Victor Pascual Avila
The dialog module could eventually be used to detect out of sync Cseq and take decision to terminate the call. Is this feasible?

Adrian

On Dec 19, 2008, at 3:59 PM, Victor Pascual Ávila wrote:

On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu
<[hidden email]> wrote:
Hi Iñaki,

Have you consider requesting auth for the BYE ? from SIP point of view
is perfectly valid....

I'm afraid this would only prevent external attackers but does not
protect you from your own customers-- guys who have the credentials
and wanna call for free.

Cheers,
--
Victor Pascual Ávila
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Dan Pascu

There is more than one way to skin a cat as they say and this case is no
exception. There are multiple ways to send a BYE that will not be
accepted but still make the proxy end the session (at least in the
current implementation):

1. Lower CSEQ number
2. Low max forwards value, so the BYE doesn't reach the gateway
3. Invalid destination, so it gives timeout after a while
4. Wrong call-id, from-tag, to-tag which will make the BYE be rejected by
the gateway

All these have in common that they will get a negative reply to the BYE.
So the idea would be not to not the dialog unless a 200 OK for the BYE is
received.

This can be worked around however too. I can send the BYE with all the
dialog identification elements and the correct CSEQ number, but to a
different ruri, pointing back to myself, and I can reply with 200 OK to
the BYE. To avoid this the proxy would have to check the ruri as well.

But then I can send one with the proper ruri, but a different route set
that puts me in the front of the gateway, so when I receive the BYE,
instead of forwarding it to the gateway as the route set requests, I
reply myself with a 200 OK making it look like it came from the gateway.

In the end it means, the proxy will have to verify everything (dialog
identification elements, cseq, ruri, route set) to avoid fraud and also
wait for a 200 OK, which makes it look more like a b2bua after all

In the end the simplest solution is to eliminate the incentive for users
to fraud that system, not to put bigger or more locks on it. This can be
done by using a flat-fee model, but I agree that lobbying for this will
fell on deaf ears with the big players that own the gateways. Still this
is the simplest solution that not only eliminates the incentive for
fraud, but also simplifies the over complex billing system and eliminates
the burden the billing puts on a system with millions of users that have
to be accounted in realtime.

On Wednesday 07 January 2009, Adrian Georgescu wrote:

> The dialog module could eventually be used to detect out of sync Cseq
> and take decision to terminate the call. Is this feasible?
>
> Adrian
>
> On Dec 19, 2008, at 3:59 PM, Victor Pascual Ávila wrote:
> > On Fri, Dec 19, 2008 at 3:22 PM, Bogdan-Andrei Iancu
> >
> > <[hidden email]> wrote:
> >> Hi Iñaki,
> >>
> >> Have you consider requesting auth for the BYE ? from SIP point of
> >> view
> >> is perfectly valid....
> >
> > I'm afraid this would only prevent external attackers but does not
> > protect you from your own customers-- guys who have the credentials
> > and wanna call for free.
> >
> > Cheers,
> > --
> > Victor Pascual Ávila
> > _______________________________________________
> > Users mailing list
> > [hidden email]
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users



--
Dan

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
In reply to this post by Adrian Georgescu
2009/1/7 Adrian Georgescu <[hidden email]>:
> The dialog module could eventually be used to detect out of sync Cseq and
> take decision to terminate the call. Is this feasible?

IMHO it shouldn't terminate the call upon receiving an out of sync
Cseq. Maybe just replied the "Out of order" 4XX response (acting as an
UAS).

--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Accounting: How to avoid a fraudulent BYE with lower CSeq?

Iñaki Baz Castillo
In reply to this post by Dan Pascu
2009/1/7 Dan Pascu <[hidden email]>:

> But then I can send one with the proper ruri, but a different route set
> that puts me in the front of the gateway, so when I receive the BYE,
> instead of forwarding it to the gateway as the route set requests, I
> reply myself with a 200 OK making it look like it came from the gateway.

This could be avoiding by examinating the $dd value. If it's set it
means that a Route header exists, so we could reject the BYE. But this
would break a complex scenario with varios sequential proxies doing
loose-routing.


> In the end it means, the proxy will have to verify everything (dialog
> identification elements, cseq, ruri, route set) to avoid fraud and also
> wait for a 200 OK, which makes it look more like a b2bua after all

So the conclusion is: a secure CDR system can be only achieved in a
B2BUA between the proxy and the gateway. Is it?


--
Iñaki Baz Castillo
<[hidden email]>
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
123