Subject: Billing SIP proxy

From: Giuseppe Ricagni <[email-masked]>
Date: Tue, 28 Mar 2000 12:53:11 +0200

Dear All,

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.

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 ?

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: Jay Batson <[email-masked]>
Date: Mon, 27 Mar 2000 23:24:44 -0500

IMHO, there will always be UAs that do not want to be forced against their 
desire to use a particular proxy.  If I'm a died-in-the-wool Net-Head, I 
may very well be happy with:

- making a call from my Pingtel phone (at sip:[email-masked]) to 
Henning's SIP address ( at sip:[email-masked]);

- having my Pingtel phone sends the INVITE directly to Henning's proxy 
(without my service provider being involved);

- having everything going across the public Internet, getting "best 
efforts" delivery of everything;

- which doesn't require any service provider anywhere to know about or care 
about the call.

Which, of course, is exactly what SIP does now, thank you.  So I'll be very 
happy not to see us "break" the swell protocol we have... ;-)

I'm sympathetic to the problems of a service provider who wants to bill for 
connections.  But this question feels to me like a similar question I heard 
a few years ago when X.25 messaging vendors were asking the same question 
about SMTP/POP....  SMTP/POP kinda torpedoed existing business models (of 
charging for email transport).  SIP may pose similar challenges for 
"pay-for-connection" business models.  Fortunately, it gives service 
providers a nifty mechanism to create new services to replace that lost 
revenue....

Cheers
-jb

---

From: "David Oran" <[email-masked]>
Date: Mon, 27 Mar 2000 23:19:21 -0500

>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 ?

There's no way to prevent one "hacked terminal" from talking to another
"hacked terminal" directly, bypassing any proxy.

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. If they don't match, you know somebody is
trying to spoof you.

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)

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 27 Mar 2000 23:53:46 -0500 (EST)

> 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]

---

From: Francois Menard List Account <[email-masked]>
Date: Tue, 28 Mar 2000 00:22:47 -0500 (EST)

> them proper end-to-end IP service, and only bills for true value-added

There aren't too many options. Either you own the network, in which case
you firewall your users (i.e. a la PSTN STPs and CLASS5 firewalls, ahem,
switches) or you own the terminals (rent hardwired IP phones hooked to
your own proxy servers).  If an end-user hacks your phones, then you need
to own the network do do something.  I contend that most problems will
disappear as the speed of the access ramp increases significantly as to
make the issue of managing QoS a worthless exercise.  Then the only way to
assert vertical control over an ocean of bandwidth is to build the better
ships and the better docks. 

-=Francois=-
[email-masked]

---

From: Giuseppe Ricagni <[email-masked]>
Date: Tue, 28 Mar 2000 20:51:02 +0200

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 !)

---

From: Paul Sijben <[email-masked]>
Date: Tue, 28 Mar 2000 16:05:56 +0200

Jonathan,

There are some other issues involved here. 

It seems reasonnable to expect someone who put down a lot of money for a
QoS-enabled high-bandwidth network you can run SIP on (or any other
multi-media capable protocol) to want to give QoS access only to
authenticated and authorized users (so to get money from them)

Now a way to achieve this is to allow the QoS-SIP service on that network
by requiring that all users who use it to authenticate with the proxy
before using the service. That proxy can then open the firewall into the
QoS network 
and allow the (media of the) call to proceed.

BTW: Having the SIP proxy there anyway opens all kinds of options for value
added services for the service provider.

So the SIP proxy service is then bundled with the QoS service and the
firewall traversal. It may be hard to separate these issues from a business
perspective until authenticated QoS is viable.

Paul

-- 
Paul Sijben              Tel:+31 356874774 
Lucent Technologies      Message:+31 208702874			
Forward Looking Work     Fax: +31 208702874
Huizen, The Netherlands  http://voip.nl.lucent.com/~sijben (internal)

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 28 Mar 2000 16:26:16 -0600

Giuseppe,

If two parties have IP telephony clients, SIP phones for example, and the
caller knows the called IP address, nobody can prevent them legally to set
up a phone call. That phone call comes within the flat rate Internet access
charge. One way to find the the called IP address is using an instant
messenger package, or e-mail.

Henry

---

From: "David Oran" <[email-masked]>
Date: Tue, 28 Mar 2000 18:03:57 -0500

> -----Original Message-----
> From: Giuseppe Ricagni [mailto:[email-masked]]
> Sent: Tuesday, March 28, 2000 11:45 AM
> To: David Oran; Sip list
> Subject: Re: Billing SIP proxy
>
>
> David,
> David Oran wrote:
> 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.....
> source address of the SIP message.
> I assume you mean "Source address of the IP packet containing the
> SIP message", right ?
Yes.

> 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 ?
It doesn't work. Look at Jonathan's SIP with firewalls and NATs draft.
Something has to modify the DNS translations for the via's, or act as an ALG
to modify the IP addresses as they traverse the NAT so they match or the
base protocol does't work either. Any such box has to be trusted anyway.

> 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)
The only way you can authenticate something without resorting to end-to-end
autentcation is to trust your previous hop. If the previous hop isn't
trusted you have no idea if it isn't spoofing you that your billing server
is in the via list when it in fact isn't.

> 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".
You clearly need mutual autentication with your registration server or all
sorts of other security holes open up.

> 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 ?
>
Well, I think I agree with the folks wo think this is an long comlicated
road to close a hole that doesn't need to be closed. You have to bill for
something that adds value. Trying to force people to use your proxies just
so you can bill is ultimately futile in the Internet world.

|

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 Mar 2000 19:17:25 -0500

> so you can bill is ultimately futile in the Internet world.

I agree 100%. You cannot bill for services you don't actually provide.

Even blocking UDP packets at a firewall unless opened through control in
a SIP proxy will not force people to use the proxy. As long as there is
*any* service which you let out through your firewall (like HTTP), I can
tunnel my own service on top of that. HTTP decapsulating proxies
external to the firewall can unwrap the SIP and RTP, and send them to
the final destination. Thus, a "hacked" UA inside the firewall (where
that hacked UA is perhaps software downloaded from a "free SIP" provider
running this HTTP decapsulator) can still call any normal SIP UA outside
the firewall for free. 

Now, if you are providing some value add (such as QoS), requiring people
to call through your proxy to access that service is reasonable. If they
don't, well, they just won't get QoS.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Giuseppe Ricagni <[email-masked]>
Date: Tue, 28 Mar 2000 18:44:36 +0200

David,

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.....

> source address of the SIP message.

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

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