Subject: Re: [Sipping] Combining Proxy + Policy servers

From: Volker Hilt <[email-masked]>
Date: Thu, 29 Jun 2006 23:44:23 -0400

Hi Adam,

sorry for not responding that long. This email somehow fell through the 
cracks. So, sorry again, and thanks for the comments! More inline.

> To the authors of draft-ietf-sipping-session-policy-framework-00.txt:
> 
> Excellent work and very timely!  I would like to understand better the
> overall operation:
> 
>    The protocol defined in this specification clearly separates SIP
>    signaling and the exchange of policy information.  SIP signaling is
>    only used to rendezvous the UA with the policy server.  From this
>    point on, UA and policy server communicate directly with each other
>    over a separate policy channel.  This is opposed to a piggyback
>    model, where the exchange of policy information between endpoint and
>    a policy server in the network is piggybacked onto the SIP signaling
>    messages that are exchanged between endpoints.
> 
> I am approaching this line of questioning from an inter-domain message
> flow point of view.  Why not more emphasis of the policy server as a
> function that can be implemented on the proxy, instead of a separate
> device/channel, more so device.  

The policy server is a logical function that can be co-located with a 
proxy and implemented on the same device. However, on the SIP signaling 
level, it is a separate entity. There was quite some debate about 
whether a piggyback or a separate channel is more suitable. A summary of 
this discussion is in the draft.

> By mandating the delineation between
> the proxy server and the policy server, the number of transactions
> required to determine route or path selection seems greater than would
> be required in the "piggyback model".  

Yes, the separate channel model requires more messages to be exchanged 
than a piggyback solution. However, the actual overhead is usually a 
SUBSCRIBE/NOTIFY exchange between the UA and the local policy server 
(assuming the UA has already cached the policy server URI). Since the UA 
has the policies before actually setting up a call, this mechanism 
avoids the rejection of calls that violate policies and can therefore 
save a round trip in these cases.

> There's some session routing that
> an inter-domain proxy will be required to perform regardless of policy
> referral.  Using the Subscribe/Notify function between two edge proxies
> across domains is an excellent idea to exchange policy information.

Interesting thought. Although it was not designed that way, it seems 
very well possible to use a policy subscription between providers.

> Caching that policy information would help speed up the route-decision
> making process.  I am approaching this thinking that the policy exchange
> mechanisms would be more static in nature meaning done at inception of
> relationship with changes periodic, than dynamic, therefore the overhead
> on the proxy doesn't warrant offloading to a separate element
> altogether.  
> 
I guess this means essentially that a proxy in one domain would 
subscribe to the policies in another domain at startup and track the 
policies as they change over time. It seems that session-independent 
policies could be used for this purpose.

> As the draft defends the rationale 
> 
>    It enables the use of separate encryption mechanisms on the signaling
>    path (to secure the communication between endpoints) and on the
>    policy channel (to secure the communication between endpoint and
>    policy server). 
> 
> I am thinking that TLS for all signaling communications would handle
> this.
> 
No entirely. Take for example the scenario where a UA has a home domain 
A and is currently connected to domain B. The UA needs to disclose 
information to the policy server in A and receives policies from this 
server. If this is piggybacked onto signaling, domain B would be able to 
see all session information and policies. UA A could not disclose 
information specifically to a policy server and policies would be 
visible to all entities along the signaling path.

>    Policies can be submitted directly from the policy
>    server to the endpoint and never travel along the signaling path,
>    possibly crossing many domains.
> 
> Not sure why this is an advantage. The signaling path is already there,
> why not use it?  
> 
The key difference is that policy server and UA are both endpoints in 
the policy exchange and, therefore, they can use well known mechanisms 
to encrypt their data. The actual messages are SUBSCRIBE/NOTIFY based 
and still travel along the signaling path. However, their content is 
encrypted and, thus, policies are not visible to transit networks.

>    Endpoints set up a separate policy
>    channel to each policy server and can specifically decide which
>    information they want to disclose to which policy server.
> 
> Couldn't this be achieved also in the signaling path as well?
> 
No. This would require a mechanism for end-to-middle encryption (i.e. 
encryption between an endpoint and a signaling intermediary). RFC 4189 
has more on this.

>    Finally,
>    policy servers do not need to rely on a SIP signaling message flowing
>    by to send policies or policy updates to the endpoint.
> 
> Why exchange policies if there is no requirement for SIP signaling?
> 
With a subscription based mechanism, the policy server can update 
policies at any time. It does not need to wait until it gets a signaling 
message within the correct session so that it can piggyback the policy 
updates on (this may never get such a message until the session is 
terminated).

Volker

_______________________________________________
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