Subject: [Sipping] session-spec-policy-01 and session-indep-policy-01

From: Cullen Jennings <[email-masked]>
Date: Fri, 05 Nov 2004 09:15:08 -0800

My meta comments is that this seems to be getting close on many of the "how
the policy is moved around" issues but still seem like fairly early work on
the "what the policy document is" stuff.

Right now it is trying to be an incredibly flexible do anything type
framework and I think that is a mistake. I think we should limit it down to
being able to meet the requirements described mostly in
draft-ietf-sipping-session-policy-req-02 - particularly the stuff in section
3.3. 

In the session spec policy ...

This is session spec policy, so, when the UA goes to the policy server, I'm
sure it has to provide some information about the session so the server can
provide the policy. I can't figure out how this happens reading the draft.

You need to decide  if the policy server is just providing hints that all
the UA not to violate the policy or if it  is doing something more. It it is
just a hint, then I don't think you need the token - you just need a flag
that say's yes, I have talked to the appropriate policy server. This will be
much easier to secure than something where the token has security
properties.

I can't imagine how this will work without needing it for answers as well as
offers. The example in section 4.2 PS-A will need to know the port that UA-A
put  in the answer so that it can open an pin hole in a firewall to allow
media to UA-A. 

I think this could be improved by specifically saying that what is revealed
to the PS in both an offer and answer case and was clear how the PS would
tell the UA to change the offer or answer in the case where the RTP
port/address needed to be changed.

We need to say how the PS informs the UA of DSCP and other QOS parameters.

The PS should be able to add per codec bandwidth and pps limits.

I think that SUB/NOT is a reasonable approach to talk to the PS. The reason
why is that any other choice is going to get you into a very complicated
story on how to authenticate things back and forth.

Moving on to indep-policy ....

Again, I think we can meet the requirements with something much simpler that
avoids most of the problems I bring up below.

I would add a  packets per seconds max per stream and per session. This is
important on 802.11 networks.

We need more on what to do with conflicts. The idea that an UA should alert
on a conflict is not really enough. Should say the UA should attempt the
call if there is a conflict? What about if the conflict is during a 911
call?

In the example in 4.4.3, is has RTP/AVP in the set_all. Since I must set
this, I assume I can not set SRTP. I don't get how I can optional use that.

What is an implementation supposed to do if it says forbid X and set_all X.
Which wins? 

How do I say you can use 300kbps for video but only 30kbps for audio.

Basically I think the current scheme is going to be incredibly difficult to
implement with different corner cases on all the implementation that make it
easy to come up with "invalid" policies that get circumvented in weird ways.

This is the same problem we have with all merged policy - if we just had
positive permissions, or just had negative permissions, it would be easier.
I sort off doubt we can do that in this case but perhaps someone can figure
out how. If we can't do this, I think we can still easily solve the
requirements at hand with specific instead of general solutions with
specific advice on how to merge and deal with conflicts.

Consider something like the following.

  We have a list of allowed codec in preferred order and they merger based
on nearest proxy on the signaling path having priority.

  We have a list of forbidden codecs.

  We have max session/stream bandwidth and pps that merge in obvious way.

  We have that these are clearly hints and conflicts should be ignored for
emergency calls but call should not be made for non emergency calls.

  A min and max RTP port that is allowed - these merge in obvious way.

  A DSCP that should be used.

  For each codec, a DSCP that should be used.

The include/exclude target stuff is very confusing on how it relates to the
selection of rules - needs clarification.

I did not see requirement for transport or direction stuff. Or the protocol
stuff which seems really confusing right now.

The media policy address stuff does not make sense. This is an IP that the
UA uses in the SDP then just sends from it's normal IP? You won't have to do
things with the port on a per session basis? I am suspicions that this only
makes sense in the session dependent work.

_______________________________________________
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: Volker Hilt <[email-masked]>
Date: Sat, 06 Nov 2004 19:24:21 -0500

Cullen,

thanks much for the comments! I'll respond in different emails for the 
session-specific and the session-independent draft.

> provide the policy. I can't figure out how this happens reading the draft.
Yes, the UA needs to provide session information to the policy server. 
This is something that happens on the policy channel, which is the major 
open issue for this draft now and needs to be specified. The examples in 
section 4 provide an abstract view on how the UA provides session 
information to the PS over the policy channel in "InfoOffer" and 
"InfoAnswer".

> much easier to secure than something where the token has security
I agree that there are two choices here: the UA can include a flag, 
which says, yes I know this policy server. Or the UA can include a token 
it has received from the policy server which also indicates that the UA 
has actually talked to the server.

The draft currently makes use of a token but also allows the use of the 
PS URI, which is essentially a flag for one server (which is exactly 
what is needed by a proxy). I agree that a token might actually not 
provide too much extra value. It does indicate that the UA has talked to 
the server but it does not say that the UA has really used the received 
policies. For this reason, I'll remove the use of the token from the 
draft and simply keep the use of the PS URI.

> put  in the answer so that it can open an pin hole in a firewall to allow
The examples in section 4 illustrate the basic call flow - there is no 
deeper semantic behind them. I guess what you had in mind is the 
firewall traversal example, which would not work without providing the 
answer to the PS.

This was added as an open issue because the question came up whether it 
is possible/desirable to reduce the scope of session-specific policies 
to only policing the offer. A possible option could be that the policy 
server tells the UA in the offer cycle, whether it wants to be contacted 
for the answer and for the BYE.

> port/address needed to be changed.
Yes, the media routing policy still needs some more clarifications!

> story on how to authenticate things back and forth.
I agree.

Thanks,

Volker

---

From: Volker Hilt <[email-masked]>
Date: Sat, 06 Nov 2004 19:32:23 -0500

Cullen,

> draft-ietf-sipping-session-policy-req-02 - particularly the stuff in section
This issue is certainly the most important one to get resolved for the 
session-independent framework. Once the general structure of policies 
and the way constraints are specified is nailed down, it should be 
fairly easy to define XML schemas for policy documents.

The current framework is indeed quite flexible. I believe it is 
deterministic and UAs can calculate their working profile by processing 
a policy document step by step as described in the draft.

Having said this, I agree that it might make sense to reduce this 
flexibility and define something less general that only applies to the 
specific policies.  I'll try to put together an alternative proposal for 
the D.C. meeting.

> We need to say how the PS informs the UA of DSCP and other QOS parameters.
Do you have examples about what you would like to see in a QoS parameter 
policy?

> The PS should be able to add per codec bandwidth and pps limits.
I'll add a "type" and a "codec" attribute to the maxBandwidthStream and
the new maxPacketsStream (see below) elements.

> avoids most of the problems I bring up below.
As mentioned, I agree that there are simpler approaches that should be 
explored.

> important on 802.11 networks.
I'll add a maxPacketsStream and a maxPacketsSession element to the media
policy schema.

> call if there is a conflict? What about if the conflict is during a 911
I think the general question is if something useful can be done when 
policies conflict. When the conflicting policies are both enforced, 
there might be no resolution at all. The approach of the current draft 
is to have a section that defines conflict handling rules for each schema.

> this, I assume I can not set SRTP. I don't get how I can optional use that.
In the example, RTP/AVP MUST to be in the working profile. If it's the 
only transport in the working profile, the UA must use it.

If the policy has optional elements in the <set_any> container, the UA 
may add these element to the working profile. It can then choose between 
RTP and SRTP. If you want to force the UA to use RTP/SAVP, simply don't 
put a transport alternative in the <set_any> container.

> What is an implementation supposed to do if it says forbid X and set_all X.
Since forbid MUST be processed first, X is removed from the working
profile and then added again. The behavior is deterministic (although
it's not the most useful policy).

> How do I say you can use 300kbps for video but only 30kbps for audio.
Good point. I'll added a type attribute to maxBandwidthStream element.

>   For each codec, a DSCP that should be used.
These are very good points. Again, I'll try to put something together 
for the D.C. meeting.

> selection of rules - needs clarification.
The selection of the policies for a target needs more clarification in 
the draft. The idea is that it is possible to define a policy that, for 
example, only applies to non-local targets (e.g. a firewall traversal 
policy). I'll add some wording that clarifies the use of these elements.

> stuff which seems really confusing right now.
I'm ok with removing the transport and direction stuff if this is not 
needed. Regarding the protocol stuff, this could be move to a separate 
policy draft if people feel that it should not be part of the framework 
draft.

> makes sense in the session dependent work.
All XML schemas in this draft can also be used for session-specific 
policies. I agree that the media routing policies are more useful in 
conjunction with session-specific policies and should probably be 
separated out into a separate draft (this is listed as a work item). The 
media routing policies also need a lot more explanation about a UA 
should process them. This is on the to-do list for the next revision of 
the draft(s).

Thanks,

Volker

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