Subject: Re: [Sipping] Comments on draft-ietf-sipping-session-policy-req-00

From: Volker Hilt <[email-masked]>
Date: Fri, 04 Jul 2003 14:44:27 -0400

Jonathan, Miguel,

Miguel A. Garcia wrote:
> First, I am missing a general requirement that describes the general
> mechanism that we want. If you consider the General Requirements,
> there are  many of them explaining different aspects of the solution,
> but none that describes generally what is needed. I would expect
> something on these lines:
> 
> "A mechanism that provides SIP proxies with the ability to convey
> session related policies to SIP User Agents".

The goals of the policy draft have been motivated quite nicely with a
number of very convincing examples. The requirements for these examples
are reflected in some of the Policy Requirements (examples are
REQ-POL-4, REQ-POL-5 and REQ-POL-7 to REQ-POL-13).

I was wondering if it is possible to separate the requirements specific
to these examples (e.g. requesting the use of a different codec,
different media addresses, firewalls, QoS) from requirements of the
general policy mechanism (the mechanism needed to exchange policy
information between UAC, proxies and UAS). This mechanism could be
defined independent of a certain use. It could enable a proxy to request
the modification of any aspect of a session description.

The requirements for certain use cases of the session policy mechanism
could then be defined in a separate section/document. This separation
seems to be more extendible than combining the requirements of the
policy exchange mechanism and use cases.

> The thing is that I don't foresee dynamic changes in policies,
> depending on the traffic in the network. One could do it, of course,
> but requires some extra administration or having some sort of monitor
> that acts upon thresholds.

How do you envision the proxy to change policies within an active call?
This sounds a little like re-INVITEs send out by the proxy (something a
proxy can't do!).

> Instead I foresee another scenario where the administrator has
> certain fixed policies that do not change often. For instance, an 
> administrator could permanently disallow the G.711 codec because of
> the high bandwidth. I think this is an important issue to discuss,
> because the solution may go in one or another direction depending on
> the rate of the changes in policy. I would suggest to add a
> requirement regarding the expected changes in the policies.

The session policies will probably not depend on highly dynamic factors
such a load (congestion control comes to mind here) but more on things
like network configuration and user preferences. These issues can easily
be considered by a proxy on a call to call basis.

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

_______________________________________________
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: Kumiko Ono <[email-masked]>
Date: Fri, 11 Jul 2003 09:01:15 +0900

Jonathan,

First of all, the approach of the session-policy is a good idea.
Proxies can express preferences for the use of codec during the 
codec negotiation between UAs. It seems that proxies join 
the offer-answer procedures.

I have a comment on your session-policy-requirement I-D.

REQ-CON-5,6 say 
the mechanism should allow the proxies to know whether or not
the UAC/UAS has accepted its policy requests.

I think this requirements imply another requirement that
the mechanism should allow proxies to verify the integrity of the 
acceptance of its policy requests. I would suggest add this 
as a security requirement.

Regards,

Kumiko

-----------------------------------
Kumiko Ono
NTT Network Service Systems Labs.
Tel +81 422 59 4508/Fax +81 422 60 4012
e-mail [email-masked]
-----------------------------------

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 05:13:54 -0400

inline.

> policy exchange mechanism and use cases.

I think that makes sense. I'll restructure the document so that there 
are some general mechanism requirements, indpendent of the particular 
policy type, and then some requirements for specific policies (codec 
policy, intermediary policy, etc.).

> This sounds a little like re-INVITEs send out by the proxy (something a

I think what Miguel is saying is that they wouldnt need to change in 
the middle of a call. In fact, the policies would be fairly static and 
would change infrequently. When they do change, they don't need to do 
so synchronous with any particular call attempt. In that case, you can 
use mechanisms totally outside of a call. It becomes more of a 
provisioning problem, and things like xcap would be more applicable.

> be considered by a proxy on a call to call basis.

The point Miguel is making, and its important one, is it wouldn't even 
be on a call-by-call basis.

This is really the first major issue we need to tackle (we'll discuss 
during the sipping meeting today). Do we think session policies need 
to be specified on a call-by-call basis? Certain policies tend to need 
to be call-by-call. For example, using an intermediary for relaying 
media. That needs to be call-by-call since the port to send to will be 
computed on a call-by-call basis. Other policies, such as codecs to 
use, arguably don't change much at all, and may not need to be 
computed on a call-by-call basis.

So, the question is whether we think there are two mechanisms - one 
outside of a call, and one inside, or just one. One point to be made 
is that, if you have a single in-call mechanism, that could be used to 
cover both static and dynamic requirements. Thus, you would have just 
one mechanism (thats good). But, it might be inefficient for wireless, 
sending the same policeis to the UA over and over again (thats bad). 
Then again, sigcomp might fix it (thats good).

So, its not obvious to me what the right direction is.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2003 05:18:19 -0400

> as a security requirement.

I would reword that slightly to "the mechanism SHOULD allow the proxy
to verify that the UAC/UAS has accepted its policy requests". Thats
because your wording implies that there is some kind of policy object
in the subsequent request which can have its integrity verified.
Verification that a policy has been implemented may be done, for
example, by using a firewall that blocks media from being sent
anywhere except the port specified by the proxy. In that case, there
isn't really a cryptographic integrity operation going on.

Thanks,
Jonathan R.

---

From: Volker Hilt <[email-masked]>
Date: Tue, 15 Jul 2003 00:20:31 -0400

Jonathan Rosenberg wrote:
> I think what Miguel is saying is that they wouldnt need to change in the 
> middle of a call. In fact, the policies would be fairly static and would 
> change infrequently. When they do change, they don't need to do so 
> synchronous with any particular call attempt. In that case, you can use 
> mechanisms totally outside of a call. It becomes more of a provisioning 
> problem, and things like xcap would be more applicable.

Yes, I totally agree.

> during the sipping meeting today). Do we think session policies need to 
> be specified on a call-by-call basis? Certain policies tend to need to 
> be call-by-call. For example, using an intermediary for relaying media. 
> That needs to be call-by-call since the port to send to will be computed 
> on a call-by-call basis. Other policies, such as codecs to use, arguably 
> don't change much at all, and may not need to be computed on a 
> call-by-call basis.
> 
> outside of a call, and one inside, or just one. One point to be made is 
> that, if you have a single in-call mechanism, that could be used to 

I haven't attended the SIPPING WG meeting so I apologize for raising 
something might have already been discussed.

The call-by-call mechanism seems to be crucial for the use of policies 
since it is the only mechanism that can operate end-to-end, considering 
the policies of transit and destination networks. Besides this, I agree 
that there might be call-by-call policies (for example, include my 
networked recording server in all calls to my favorite used car dealer).

A register-by-register mechanism seems to streamline the process in 
certain scenarios by supplying static policies. Since the destination of 
a call is unknown when the policy is set, the policies of transit or 
destination networks can't be taken into account and the call-by-call 
mechanism still needs to be invoked for all calls. However, the benefits 
of having this mechanism would be to avoid the repeated transmission of 
the same policy (although I agree that the gain can be rather small) and 
(maybe more important) to prevent the UAC from trying something that 
would be rejected anyway. This might save the client and the proxy an 
unsuccessful call attempt before the UAC considers the requested policy 
and call goes through.

-- Volker