Subject: RE: [Sip] Re: [Sipping] New version of the SIP-AAA reqs draft

From: [email-masked]
Date: Thu, 27 Feb 2003 14:39:24 +0200

Beck01, Wolfgang writes:

 > What kind of accounting information do we want to collect: The number
 > > of SIP messages per user? This is possible with an accounting
 > proxy.

unfortunately not.

-- juha

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

---

From: "Beck01, Wolfgang" <[email-masked]>
Date: Thu, 27 Feb 2003 10:59:04 +0100

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, February 27, 2003 9:28 AM
> To: Jiri Kuthan
>
> Juha,
>
> Do you mean that you would like to see a note along these 
> lines added to
> the draft?
> 
> "Note that, in order to perform accounting, a SIP proxy server should
> see and authenticate every message sent over the dialog."
> 
I don't think it's possible to do reliable accounting within a proxy
if any or both of the UAs are cheating. The caller can deliberately
ignore Record-Route and bypass the proxy when sending an INVITE. The
callee can send broken BYEs that will be discarded by the caller but
will be accepted by the accounting proxy. 

What kind of accounting information do we want to collect: The number
of SIP messages per user? This is possible with an accounting proxy.
Call minutes? How does the proxy know what kind of session is being
established if the SDP is encrypted? Only the endpoints and the bandwidth
reservation infrastructure can do this kind of accounting.

The only way I see is to include some form of micropayment tokens ("postage stamps")
in SIP messages. draft-johnston-sip-osp-token-04.txt describes such a token.
Periodical session updates containing tokens prevent disputes about the actual
length of the call. If the callee has tokens, he can charge for the call. The
trusted third party that generates those tokens can be an OSP server or may be
a proxy that inserts some header.

(see http://www.ietf.org/internet-drafts/draft-beck-sipping-svc-charging-req-01.txt)

--
Wolfgang Beck
T-Systems Nova GmbH

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Feb 2003 12:35:21 +0200

Juha,

I still do not quite understand your arguments. Could you please
elaborate on why a proxy cannot know that a message comes from a
particular UA?

Thanks,

Gonzalo

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 28 Feb 2003 14:44:58 +0200

> elaborate on why a proxy cannot know that a message comes from a

for example, i can send an invite where To header looks like this:

To: <sip:[email-masked]>

my proxy can then map it via enum, for example, to a request uri

sip:[email-masked]

which the proxy of tutpro.com then delivers to me.

when i send a bye to my proxy to close this call, from header has the
above To uri that my proxy can't use to determine that it should
challenge the request,

my current understanding is that in order to be able to challenge the
request, the proxy should keep dialog state.  if you know some other way
for the proxy to determine from the bye request alone that its own user
has sent it, please let me know and i'll instantly add that capability
to my proxy.

-- juha

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Feb 2003 12:54:23 +0200

Juha,

Here you have a figure of the scenario you have just described:

                       alice.com   . . .   bob.com
                 .       proxy              proxy     .
               .                                       .
         Alice  . . . . . . . . . . . . . . . . . . . .  Bob
      
We have an INVITE from [email-masked] to [email-masked]

Now, you have a BYE from Bob to Alice. In your scenario, which proxy is
doing accounting, alice.com or bob.com?

Thanks for the clarification,

Gonzalo

---

From: [email-masked]
Date: Fri, 28 Feb 2003 13:44:12 +0200

> We have an INVITE from [email-masked] to [email-masked]

no, originally, we have an invite from [email-masked] to
[email-masked] that gets translated by enum to [email-masked].
 > doing accounting, alice.com or bob.com?

both proxies account both placed and received calls of their own users.

-- juha

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Feb 2003 14:26:56 +0200

Juha,

OK, now I understand what you mean. Your proxy decides to perform or to
not perform accounting for a particular request based on the From header
field of the request. That is a poor choice. The proxy should challenge
the request (e.g., using digest). This way, the proxy can ensure that
the request comes from that particular user.

Your proxy can keep from challenging a particular request if the request
carries a P-asserted-identity, for instance.

Your proxy can refuse to route any request unless the user has provided
proper credentials or the network has provided credentials for the user.

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Fri, 28 Feb 2003 14:45:01 +0200

> the request comes from that particular user.

so are you saying that a user cannot place a call to the user of my
proxy unless the user is also a user of the same proxy or has been
challenged by someone else that my proxy trusts?  if so, we'll have very
little sip traffic in our networks.  it would be the same as disallowing
a user of an email server from receiving email unless it was sent by
another email server that the email server trusts.

also, if the proxy serves multiple realms, how can it know which realm
the user that send the request within a dialog belongs to so that it can
insert the proper realm in the digest challenge?  today there is no
header in the request where the user could tell that it belongs to a
certain realm.  the from header is the only one, but it only works for
sure for initial requests.

 > carries a P-asserted-identity, for instance.

as i said, there would be very little sip traffic if you impose such a
rule.  besides it is a p header and not part of sip.  if you remember i
tried to make it a real header, but failed to convince people.  now you
make the whole accounting process to depend on it.  i don't think we
should accept as working group documents anything that depends on p
headers.

 > proper credentials or the network has provided credentials for the user.

see above.  with today's means, i don't even know which realm the user
is supposed to belong to.

-- juha

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Feb 2003 15:14:42 +0200

Juha,

> another email server that the email server trusts.

Everything depends on your trust model. If your proxy is performing some
type of accounting that you (the user) wants it to perform (e.g., some
type of service), the proxy will accept "anonymous" and no password as
credentials, because the proxy is not concerned with UAs trying to
cheat. Therefore, external users will be able to call you.

And if you are not concerned about security either and you want to base
your service in the contents of the To (or From) fields, then your UA
can actually modify the To field. What it cannot modify is the tag.

If your proxy does not trust the UA because it is a billing proxy, for
instance, your proxy will only accept requests with proper credentials
or requests that are going to be routed to a known (by the proxy) UA.
But ensuring that the UA does not cheat is outside of the scope of the
requirements, and it can be done in several ways.

> sure for initial requests.

You can change the contents of the From field. No problem. In fact, one
of the reasons we removed the To and From URIs from the dialog
identifiers (only the tags remain) was to address this type of
situation.

Gonzalo

---

From: [email-masked]
Date: Fri, 28 Feb 2003 15:45:27 +0200

> identifiers (only the tags remain) was to address this type of

currently your text says:

The From URI of the request MUST be set to the local URI from the dialog
state.

...

It is expected that mandatory reflection of the original To and From URI
in mid-dialog requests will be deprecated in a subsequent revision of
this specification.

so before that is done and the text is changed so that the from uri MUST
be the from uri of the user sending the request, there can't be any
challenging or accounting of requests within the dialog.

alternatively, we must add another header or field to the request that
tells what realm the ua sending the request claims to belong to.

for example, take a look at eap/tls.  there the user has a means to tell
what realm he/she wants to authenticate with.  currently we are lacking
this possibility in sip, which is a major shortcoming.

-- juha