Subject: Re: Billing SIP proxy

From: Giuseppe Ricagni <[email-masked]>
Date: Tue, 28 Mar 2000 19:42:04 +0200

David,

David Oran 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 ?
>
> 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: Giuseppe Ricagni <[email-masked]>
Date: Tue, 28 Mar 2000 19:49:00 +0200

"Fairlie-Cuninghame, Robert" wrote:

> I agree with Jay that this is not a SIP protocol issue but a network issue.
> If you want to prevent hacked terminals located on your own network from
> accessing the Internet then simply use a SIP Proxy-Firewall solution.

 what if both terminals are on my same network ? Where do I put the
firewall ?

Cheers
Giuseppe

> Now
> UAC's cannot access the outside Internet unless they authenticate themselves
> to the proxy-firewall. Likewise, the proxy-firewall does not allow external
> clients to talk to internal terminals without authentication. The
> Authentication procedures are expressly designed to ensure that only valid
> users have access to the proxy, however, you can only ensure that hacked
> terminals do not _bypass_ the proxy by coupling the SIP proxy with a
> firewall.
>
> Cheers,
>
> Robert.

---

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

Hi Scott,

Scott Bradner wrote:

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

---

From: [email-masked]
Date: Tue, 28 Mar 2000 16:56:44 -0700

Well, I think that this discussion would benefit from a more detailed
description of the context. The problem will have  different ramifications
depending on whether a corporate network or a service providers network is
being considered.

It is not unreasonable to conceive that a service provider's network does
not have any end-points, just edge-elements that aid in 'carrying' the
call.In a service provider's network,  edge-elements MUST police the calls
that go through, both entering and leaving the network. Billing is obviously
an issue only at the edges, in this case. Appropriate filtering mechanisms
that reflect certain security policies may be embedded in these
edge-elements.

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

Service providers can not only provide directory services, for those who may
want to receive calls, but also guarantee QoS. And most importantly, they
allow  PSTN-access. And, BTW, such calls are not immune to the described
security threats either.

In an enterprise network where SIP services are available internally, calls
that do not straddle the boundaries of the network do not really pose a
problem. 

Aparna V.
Level (3) Communications.

-----Original Message-----
From: Jay Batson [mailto:[email-masked]]
Sent: Monday, March 27, 2000 9:25 PM
To: [email-masked]; [email-masked]
Subject: Re: Billing SIP proxy

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
Cheers
-jb

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