Subject: RE: [SIP] Authentication and billing through proxy/re-direct ser v er

From: David Schwartz <[email-masked]>
Date: Thu, 21 Jun 2001 16:29:49 +0300

I have not been in on this entire thread so excuse me if I say things that
have been said but I would like to throw in my 2 cents.

It is important to distiguish between the 3 "A's" as well as the CDR
creation process. To often we say that AAA/CDR should be here or there as if
it is one big object when in reality it does not have to be. In other words
there are things that probably should be in the gateway while there are
others that cannot. One such thing is A1 or Authentication.

I for one would not want anyone getting to my gateway (even to be rejected)
who is not authenticated. By authentication I mean "Who are you" and not "Do
you have enough money to make this call". So instead I put up an
authenticating proxy at the border of my network to filter out those that I
shouldn't be speaking with. 

Next we look at call start (A2 and A3) and call stop (CDR creation)
requests.

Here to it is important to look at the pros and cons in doing this in an
internal proxy Vs. using the gateway. The big con in using the proxy is that
it causes another statefull element in the network and since the VG must be
statefull anyway why have another statefull element. In addition when it
comes to the call stop (CDR creation) there is some information that might
be needed about the user (e.g. internal username) that may only be available
from the call start response. So the typical solution is to use the VG. The
con with using the VG is that you must own the VG. If you wish to terminate
on someone elses network it can be tricky retrieving the CDR's. 

One possible stateless solution might be to use the proxy for call start and
call stop. The Record-Route header is used to ensure that the proxy sees the
BYE message. Any proxy that gets an invite generates a call start (on
receiving the 200 OK) which writes to some file that a particular callID has
started a call at this particular time, and any proxy getting a BYE
generates a call stop which writes to a file (potentialy on a different
machine) that a particular callID has stopped a call at a different time.
There is no state that needs to be saved. Instead, a different process
constantly moniters these files and correlates the call starts with the call
stops. This seperate process is the one that generates the CDR's. This also
reduces the load on the VG's enabling them to focus on the call setup and
teardown.

One issue with this approach is what if the proxy that added the
Record-Route falls down the message has routing problems. This problem can
be solved in many ways and is out of the scope of this discussion.

David Schwartz

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jiri Kuthan
Sent: Wed, June 20, 2001 8:33 PM
To: Rosen, Brian; 'Jay Batson'; Ashhar Farhan; [email-masked]
Subject: RE: [SIP] Authentication and billing through proxy/re-direct
serv er

At 03:01 PM 6/20/2001, Rosen, Brian wrote:
[...]
>I myself am not wild about UAs doing CDR generation.  I think proxy servers

>can do that.  The piece of information the PS doesn't have is the exact
connection
>time information.  

My opinion on network configuration is that CDR/AAA functionality 
is best hooked to the same place where the particular AAA-fizied 
service is actually provided. 

If we speak about PSTN call termination service, I think gateways 
would be a better place to hook AAA than proxies. A particular advantage 
of gateways (i.e., UAs from SIP perspective) doing the AAA job is it 
works even if subsequent SIP requests take a different path and do not
hit the same proxy. It sounds better to me than attempts to force 
routes by RR or B2B.

If transport services were hooked to AAA systems somehow (e.g., premium 
PSTN termination service incl. RSVP), it would be probably also easier 
to do the AAA job in gateways rather than in SIP proxies.

Note that having gateways done the AAA job from SIP perspective does not 
necessarily imply that the entire AAA functionality resides in gateways. 
More likely, it would be outsourced to a AAA server.

Jiri

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 Jun 2001 12:50:55 -0400

> From: David Schwartz [mailto:[email-masked]]
> Sent: Thursday, June 21, 2001 9:30 AM
> To: 'Jiri Kuthan'; 'Rosen, Brian'; 'Jay Batson'; 'Ashhar Farhan';
> [email-masked]'
> ser v er

Using a proxy to generate minutes of usage is very hard. Ultimately, the
gateway knows the call call duration, as it is the arbiter of whether the
call is still in progress with the PSTN. For proxy-based duration to work,
you need to be able to prove that the proxy is always in continuous
synchronization (in terms of call state) with the gateway, within a
reasonable time lag. So, can you prove that an attacker cannot force the
proxy and gateway to go out of sync? I know of several attacks that are
possible in order to convince the proxy that the call is down, but the
gateway that the call is up (Max-Forwards values which cause the BYE to pass
the proxy but fail at the gateway, for example). This results in free
service. Someone more creative than I might come up with a few more.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Jun 2001 18:07:05 -0400

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Tuesday, June 26, 2001 1:25 PM
> To: Arnoud van Wijk (ELN)
> Cc: [email-masked]'
> Arnoud van Wijk (ELN) writes:
>  > Yup. And that is now exactly my problem with Charging and Billing.
>  > The signalling and the bearer traverse different nodes/servers and
> >  pathways. So, SIP is currently unreliable to obtain exact call
> > duration.
> 
>   This isn't a SIP problem, per se; it's an inherent information
>   problem where a potentially untrusted device(s) is the only
>   thing in possession of the necessary information for which it
>   has high incentive to withhold/lie. The reason that this doesn't
>   come up in the PSTN is because the things beyond the trust 
>   boundary of the provider aren't the sole keepers of that
>   information. 

I would assert that if you are trying to reconstruct call duration at some
element B (a proxy or B2BUA) outside of the gateway which terminates the
call, this process is provably impossible if there is no trust relationship
between the gateway and B.

Now, if a trust relationship exists, the trick is just making sure that any
changes in call state detected by the gateway are reliably sent to B. If B
and the gateway communicate through a series of trusted peering connections
(i.e., TLS connections), AND the gateway only accepts and sends messages
over this connection, AND we can avoid attacks that cause the message to be
dropped or misrouted between the gateway and B (like Max-Forwards attacks)
we can be sure that any messages seen by the gateway are seen by B, and vice
a versa. The final trick is that the gateway needs to send a BYE if it
determines that the call has failed for some reason, such as a media
failure. We've been talking about that possibility on another thread (where
a re-INVITE 481 causes the server to generate a BYE).

One can ensure state synchronization through other means, like NOTIFYs, but
that seems silly. Rather, just ensure that the messages which affect state
changes at the gateway are always seen by element B. 

Given these constraints, one can reconstruct call duration in remote element
B within a time granularity on the order of magnitude of SIP message
transmit times, which are going to be seconds (32s being the maximum
transaction duration). Of course, network failures may cause
desynchronization as well, and this problem is unavoidable.

These contraints are significant, and hard to meet, but not insurmoutable.
The trick is the realization that a trust relationship through something
like TLS is a requirement. Of course, if at all possible, duration based
billing in the gateway is the best place. However, there are definitely
legitimate architectures and business models where it is not possible for
the call duration and billing information to be determined from the gateway.

-Jonathan R.

---

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip