$Id$

Recollection of Messages on Policy
==================================

Jiri & Juha: sipping, private exchange:
(2003-02-24)
---------------------------------------

> for example, when someone calls me at sip:jh@sip.song.fi, the to header
> may include any local way to make a call to a phone number, for example,
> sip:0333983900@foo.bar;user=phone.  enum will then return for that
> number sip:jh@sip.song.fi.  in this case, neither to or from header is
> my sip uri.


Why do we need to authenticate? My understanding was that you would like
to challenge in case someone was claiming your domain in From and trying
to get it rubberstamped by your domain's proxy. Do we need to worry about
a BYE from 0123@foo to 0321@foo? Well, I think so, to avoid relaying
(spam). That could be accomplished by challenging any requests to outside 
domains. The question then is what realm should we use? We don't know
it any longer, and we don't want to keep sessions. Keeping it with
record-routing might be an option.

Juha:
yes, the proxy would not know the realm unless it keeps dialog state.
more that authentication, i'm worried about accounting.  if my policy is
to account dialogs (calls) that are initiated by my own users, how do i
know when i see a bye, if it terminates such a call or a call initiated
by non-local party?

Jiri: There are actually two issues: decide whether the subsequent BYE needs to
be authenticated, and if so, with what realm. There is no way around it
except keeping dialog state, better in record-routes rather than in
server's memory. If in record-routes, integrity needs to be preserved.
See my sipping posting (2003-03-04):
First of all, as said previously, live with realms from UAC. They
are as trustworthy as user's id -- all is supplied by user and what
really matters is whether the credentials are ok. (And again, forget
interfaces, please.)

The real questions is whether to authenticate at all, and if so
which realm the server should use to challenge.

Let me give an example. A proxy maintains a policy which is 
a no relaying: drop requests which neither have my domain 
  in r-uri nor have my domain in From
b verify from: if request originator claims to be a part of
  my domain in From of a request, authenticate
c watch all: sessions are record-routed

Scenario:
1) a@other calls b@other which gets forwarded to b@mine
2) b@mine sends a BYE, it looks like:

BYE sip:originator@1.2.3.4
From: b@other
To: a@other
Route: <proxy@mine;lr>

What will you do now? Well with the policy above you would drop
it (point a). If you are smarter, you will see your Route and
infer "that's my Route, I must have accepted the previous INVITE"
and will not drop it. The questions are now:
- should you authenticate? (remember, you can't authenticate
  request originators from other domains)
- if so, with what realm
- how far can you trust the information in Route (actually, not at all)

--

solution space? Well, it is actually about call-state policy. To enforce
it, we would have to maintain call state. That would be a way ugly and
we better put the call state somehow in Record-Routes. Doing so would
be a very useful thing anyway. That would be a useful thing for a dozen
of other cases too -- Frmo rewriting, or 200/ACK matching at an accounting
proxy.



Mike Graff, serusers
--------------------
I implemented something much like this:

if (to me):
        if register
                www_authorize or fail if not a valid register
                done
        if claiming to be "From" one of the domains I accept
        registrations for
                proxy_authorize
                done
if not to me (I'm relaying for a local phone to an external address)
        proxy_authorize (once again, based on from address)
        done


Another Concern Raised by Juha
------------------------------
What if users with valid credentials in a domain will call
someone, whose SIP address is rededirected/referred/forwarded
to an accounted PSTN destination? Callers will then "dial"
a sip URI (bob@iptel) which will be turned without their
awareness to (900-666666@iptel), challenged by gateway,
automatically answered by most of existing software today
and accounted then.

Solutions?
- don't submit credentials automatically in UAC if challenge uri!=
  dialing uri; pop up a confirmation prompt in UA
- challenge with a different realm which will take authentication
- be restrictive and ban forwarding, REFERs, 3xx