Subject: [SIP] Re: Billing SIP proxy

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:29 +0530

Hi Scott,

Scott Bradner wrote:

> > The question is: is it posible to define, to any extent, a mechanism
> > capable of preventing the "hacked" terminal to bypass the proxy and
call
> > the "standard" endpoints witout being billed ?
>
> if they are not making any special use of the network (like QoS
> reservations or fancy proxy services ) why should they be billed
> in a way that is different than any other best-effort use of the
> network?
>

Some telephony applications are currently heavily billed, at a rate much
higher than the corresponding rate for pure best effort Internet access.

In some domains, network operators hold a kind of oligopoly, thanks to
government policies, that grant licencies only to a very restricted
number of
operators.
Please don' t quote me on this, but I would say that there is no real
competition between them, at least not harsh competition.

At the moment, they are deciding wheter to continue with circuit
switched
networks or whethether to adopt IP-based networks.

It is very likely that they make such a step *only* if they don' t see
their
revenues reduced (hopefully, they would like to increase them !)

A model where best effort calls are free and QOS calls are billed will
pobably
apply in the future, but not in the short run, at least IMHO.

Giuseppe

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:28 +0530

David,

David Oran wrote:

> capable >of preventing the "hacked" terminal to bypass the proxy and
> call
> the >"standard" endpoints witout being billed ?
>
> There's no way to prevent one "hacked terminal" from talking to
> another
> "hacked terminal" directly, bypassing any proxy.
>

Fine, this is just impossible to prevent.

Then, I had in mind some via-header based solutions but, eventually, I
managed to hack all of them. It looks like the one you propose requires
some more thinking.....

> You can, at some pain, protect against is having a "standard terminal"
>
> answer a call from a "hacked terminal". The way you do this is when a
> SIP
> message comes into the UAC, ou look at the last VIA on the via list.
> You
> then get the IP address of that machine (either because it was on the
> VIA
> istelf or you called DNS to get its address) and compare that with the
>
> source address of the SIP message.

I assume you mean "Source address of the IP packet containing the SIP
message", right ?

> If they don't match, you know somebody is
> trying to spoof you.

mmm, let me think....

got it !?!?!?

   * 1) what if there' s a NAT in between ?

   * 2) vhat if the proxy "must be in the list", but not necessarily as
     the last one ? (E.g. because the proxy that bills you is that of
     your "home network", and you have moved somewhere else)

   * 2) on the other hand, if you  want the billing proxy always to be
     the last one (apart from all the clearinghouse-related issues Henry
     was mentioning today), it must be communicated upon registration. I
     must think about this, but I have the feeling that a possibility
     might be that  I can fool the "standard" terminal to re-register
     with me (the hacked terminal) making him believe I am "the proxy".
     I would obviously be adding my address to the VIA header when
     inviting him.

   * 3) I will think a little bit more about it

   * 4) Anyway, do yo agree with me that the complexity of the "crack"
     required to "patch" such features on the "standard" terminal (going
     back therefore to the first case you mentioned) is definetly much
     smaller than that of installing a complete protocol from scratch on
     a device that was not designed to run it ?

Thank you very much and
Best Regards
Giuseppe

>
> If they DO match, then if the SIP UAC knows the list of SIP proxies
> which it
> trusts to deliver calls (and bill for them), the UAC either accepts or
>
> rejects the request appropriately.
>
> > Please CC replies to [email-masked] (it is easier for me to read
> email
> from > such mailbox here in Adelaide)
>
> >Please let me know
> >Best Regards
> >Giuseppe

---

From: S_S_Dinesh/India/[email-masked]
Date: Mon, 8 May 2000 14:10:03 +0530

Jonathan,

let me say that I' m a bit tired  but, I'll try anyway... (forgive me if I
say anything terribly
wrong)

Let' s even assume I can put each terminal behind a firewall, as you
described (which is
something that, in our architecture, might even be feasible):

+---+               +------------+
| te1 |--------->|FW+Proxy1|------->+
+--+        +------------+            |
                                                           |
                                                           |
+---+               +------------+            |
| te2 |<---------|FW+Proxy2 |<-------+
+--+        +------------+

Now, by assumption, TE1 is hacked: I can do whatever I want with it.

Well this network must be connected to the Internet: let's assume there is
a firewall3 towards
the Net.
It is configured to let HTTP pass through as well as incoming INVITE and
ACK messages (this is
necessary to interoperate with the other PNOs).

Now let me start my own business "freecalls Inc." (or, at least, "cut price
calls inc...."), also
selling  terminals that

   *  incapsulate SIP in HTTP ===> [FW+Proxy1] doesn't detect the INVITE
nor the ACK
   *  send the packetized voice via TCP to my magic server in the Net

+---+               +------------+
| te1 |--------->|FW+Proxy1|--------+
+--+        +------------+            |
                                                           |+-----+
+----------------------------+
                                                           | FW3
|--------->|Server (in the
public Internet)+
                             +-----+       +----------------------------+
                                                          |
                                                           |
+---+               +------------+            |
| te2 |<---------|FW+Proxy2 |--------+
+--+        +------------+

and that' s  it: the server performs all the required translatons and sends
all the SIP
signalling and an RTP stream to TE2.

Well, I have to admit it is not very optimized, but I designed it in half
an hour....
.....I' sure our crowds of estimed hackers will be able to devise some much
more efficient
solutions....

Ciao
Giuseppe

P.S.
1st optimization: you said that "This, of course, forces you to provide
application-level
gateways for every UDP-using protocol your customers want to use."
Instead of tunneling Firewall1 with HTTP+TCP, I could try with one of such
UDP-based protocols...
(much better !)

Jonathan Lennox wrote:

> On Tue, March 28 2000, "Giuseppe Ricagni" wrote to
"[email-masked]" saying:
>
> > during these days in Adelaide, I have already had the chance to discuss
> > with some well known SIP experts about this topic, nevertheless I would
> > like to pose the same question to the list: maybe someone has some
other
> > idea.
> >
> > Let' s assme that the scenaro is:
> >
> >    * there are a number of "standard" SIP terminals, whose software is
> >      not modifiable by the user (nor any other application can be
> >      installed)
> >    * such SIP softare forces SIP to work in proxy mode
> >    * the proxy actually bills the calls
> >
> > Now let' s introduce a "hacked" terminal, and lets' s say that the
> > software on such terminal is completely free, in the sense that
whatever
> > is needed we can modify it and install it.
> >
call
> > Please CC replies to [email-masked] (it is easier for me to read email
> > from such mailbox here in Adelaide)
>
> Put the terminals behind a firewall which doesn't allow random UDP
packets
> through.  Have the SIP proxy tell the firewall to open up the ports for
each
> call's RTP streams after it processes the corresponding INVITE.  Close
them
> when you see the BYE or when a session-timer expires (you'll need session
> timers for this to work).
>
> This, of course, forces you to provide application-level gateways for
every
> UDP-using protocol your customers want to use.  It also leads to the
> question of why your customers won't just decamp to a provider who gives
> them proper end-to-end IP service, and only bills for true value-added
> features.
>
> --
> Jonathan Lennox
> [email-masked]