Subject: [Sip] Comments on Resource Priority -08

From: [email-masked]
Date: Thu, 19 May 2005 11:47:30 EDT

The following comments are submitted on draft-ietf-sip-resource-priority-08:

1 NITS

Section 1, 7th paragraph (beginning "This document defines...") needs to be 
rewritten to refer to the two headers which this document defines.

Section 4.6.5 wording of 2nd sentence is incomplete. I don't know what was 
intended, so I can not suggest new wording.

Section 10.4 reference to "multi-layer priority preemption" needs to be 
changed to "Multi-Level Precedence and Preemption".

2 Major problems

Section 4.2, rule 1 indicates that, if there is no resource shortage at the 
moment, the RP actor omits the following steps. However, the following steps 
are the authorization/authentication steps which must always be done first, 
since one of the results of requesting a priority level, even when there is no 
resource shortage at the moment, is to use the priority level during the 
remainder of the call and to provide it to the destination user. For example, the 
level requested may prevent a later preemption after a shortage of resources 
occurs. Rule 1 should simply be the final sentence in Rule 1. This rule was not in 
version -05 of this draft, and I am unaware of any e-mail or meeting 
discussion to add such a rule. Any attempt to explain or justify this rule as it is 
currently written will only add confusion.

Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC MAY 
attempt a subsequent request with the same or different resource value." This is 
contrary to the policies for using priority values and should not be 
mentioned. The user (human) is supposed to select the correct value before requested a 
call setup. A UAC must never automatically attempt another request using a 
different resource value upon receipt of a 417. Of course, a human user may 
choose to do whatever they are authorized to do when trying a new call, but no 
device can be allowed to do this automatically, since it would be violating the 
policies for the use of priority levels.

Section 10.2 states in the last sentence that the DSN (incorrectly written as 
"DRSN") uses preemption. This is misleading, since it may use other 
preferential treatment procedures as well. It is unnecessary for this document to state 
the algorithms/procedures used in each domain. Any mention of algorithms or 
procedures should only be as examples of what might occur in a domain.

Sections 10.2 and 10.3
Security concerns make it appear that the variable length priority names will 
be a problem. When individual SIP packets are encrypted for confidentiality, 
the lengths of signaling messages will be a function of the priority level, 
thereby letting an attacker know when the volume of high priority calls 
increases. It appears now that it would be preferable to use same-length names for all 
priority levels.

Section 12.1 2nd paragraph forbids adding a new priority value to a namespace 
(MUST NOT). Previous versions of this draft (-06 and before) allowed it, 
while advising against it (SHOULD NOT). For example, there is no reason why 
another value cannot be added to DSN later, if the operator of the DSN wishes to. If 
added, it is the responsibility of the operator of the DSN domain to figure 
out how to do it to avoid interoperability problems. For example, there is a 
possibility that the DSN will need to add a new level below Routine. The RFC can 
not forbid this.

3 Other problems

Section 1, paragraph beginning "Since calls may traverse..." states that "it 
is important that all such domains and elements apply the same algorithms for 
the same namespace as otherwise the end-to-end experience of privileged users 
may be compromised." While this may be true for some combinations of 
preemption followed by queuing, it is not necessarily true for all combinations and for 
any algorithm that might be added later. Suggest that this sentence be 
reworded to say: "It is important that careful consideration be made before 
different algorithms are used at different places within a single call."

Although section 7 only gives "examples", the use of "DSN" causes confusion 
since it shows an operation which would not be used in the DSN domain. 
Specifically, the inclusion of the R-P header in the 180 and 200 in 7.1 and the list 
of accepted values in the 417 in 7.2 would not be used in the DSN since this 
causes a security problem by telling the originator what precedence level call 
the called party is involved in. The example should use a domain that might use 
these techniques. Since there is none that is known to work this way, the 
examples should use "Foo" and "Bar" as in Section 8.2.

Section 8.1 causes confusion since it implies the existence of a relative 
order between different namespaces. It should instead say that there is no 
defined relationship between the values of different namespaces and that RP actors 
may apply whatever algorithms or procedures they wish when dealing with 
multiple namespaces, as long as the relative levels within each namespace are 
maintained.

Section 10.3
The final paragraph should be deleted, since it is not the responsibility of 
this document to describe the detailed operation within the DRSN, which could 
change at any time.

Section 11.3
The association of the requirement for confidentiality and integrity of the 
user's data with the Resource-Priority header leads to confusion. They are 
unrelated requirements. Other policies and requirements dictate whether there is a 
need for confidentiality and integrity of the user's data independently from 
the need for precedence levels. The first paragraph should be deleted so that 
this section only addresses the security of the R-P header itself, since that 
is the subject of this document. Security of the user's data is not the 
subject of this document.

Section 11.4
No system that allows the use of the R-P header should allow anonymity. In 
any case, the issue of anonymity is independent from the use of R-P header and 
should not be mentioned in this document.

Section 12.1
The purpose of IANA registration is to prevent conflicts in assignment of 
names and numbers, such as the namespace, and to ensure compatibility for things 
like the priority values. There is no need to include the "operation" 
(preemption or preferential queuing) in the IANA registration. It is described 
sufficiently in this document. In fact, the DSN uses other techniques besides 
preemption, such as exemption from network management controls, as described in 
draft-pierce-tsvwg-pref-treat-example, so it is wrong to register it as just 
"preemption". Likewise, ETS may use other techniques besides "queue", such as 
exemption from control restrictions and enhanced routing (See explanation at 
www.ncs.gov/docs/GETS overview brief).

Mike Pierce
Artel

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 17:23:52 -0400

My apologies for the delay in responding to these comments. I'll respond 
in several messages, just to avoid mile-long tripled-nested follow-up 
messages. I'll also add () notes to the subject header to make tracking 
any discussion easier.

[email-masked] wrote:
> Section 1, 7th paragraph (beginning "This document defines...") needs to 
> be rewritten to refer to the two headers which this document defines.

Changed.

> 
> Section 4.6.5 wording of 2nd sentence is incomplete. I don't know what 
> was intended, so I can not suggest new wording.

Fixed to

Insufficient resource conditions can occur on proxy servers and user
agent servers, typically trunk gateways, if an RP actor receives an
authorized request, has insufficient resources and the request neither
preempts another session nor is queued.

> changed to "Multi-Level Precedence and Preemption".

Changed.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 17:32:44 -0400

This is indeed an oversight. I agree that authorization is (almost) 
always needed. There are some cases where only the request, e.g., in a 
proxy, gets handling priority, i.e., there is no call state and thus the 
problem you mention doesn't occur. But it is probably not worth teasing 
out these special cases.

> Section 4.2, rule 1 indicates that, if there is no resource shortage at 
> the moment, the RP actor omits the following steps. However, the 
> following steps are the authorization/authentication steps which must 
> always be done first, since one of the results of requesting a priority 
> level, even when there is no resource shortage at the moment, is to use 
> the priority level during the remainder of the call and to provide it to 
> the destination user. For example, the level requested may prevent a 
> later preemption after a shortage of resources occurs. Rule 1 should 
> simply be the final sentence in Rule 1. This rule was not in version -05 
> of this draft, and I am unaware of any e-mail or meeting discussion to 
> add such a rule. Any attempt to explain or justify this rule as it is

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 17:39:32 -0400

A different reviewer has just requested on more detailed rules on what 
to do in this case, so one can't win, I suppose...

Note that it says "a subsequent request". This does not imply that the 
UAC "redials". It simply tells the UAC and its user what values are 
permitted for future calls, for example. A user agent could, for 
example, display such values where known. The user interface is clearly 
beyond the scope of the draft.

I don't see the need to change this.

> Section 4.7.1 2nd paragraph states that "Upon receiving a 417, the UAC 
> MAY attempt a subsequent request with the same or different resource 
> value." This is contrary to the policies for using priority values and 
> should not be mentioned. The user (human) is supposed to select the 
> correct value before requested a call setup. A UAC must never 
> automatically attempt another request using a different resource value 
> upon receipt of a 417. Of course, a human user may choose to do whatever 
> they are authorized to do when trying a new call, but no device can be 
> allowed to do this automatically, since it would be violating the

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 17:43:47 -0400

> Section 10.2 states in the last sentence that the DSN (incorrectly 
> written as "DRSN") uses preemption. This is misleading, since it may use

Typo fixed.

> other preferential treatment procedures as well. It is unnecessary for 
> this document to state the algorithms/procedures used in each domain. 
> Any mention of algorithms or procedures should only be as examples of 
> what might occur in a domain.

This information on "semantics" had, as far as I recall, been previously 
requested by the WG chair(s). The authors would appreciate guidance from 
the chairs, as removal would, in my opinion, contradict earlier advice 
from the WG chairs. Clearly, if a namespace does not specify any 
treatment in its defining documents, we should say so. I gather DSN is 
among those?

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 17:58:01 -0400

> Sections 10.2 and 10.3
> Security concerns make it appear that the variable length priority names 
> will be a problem. When individual SIP packets are encrypted for 
> confidentiality, the lengths of signaling messages will be a function of 
> the priority level, thereby letting an attacker know when the volume of 
> high priority calls increases. It appears now that it would be 
> preferable to use same-length names for all priority levels.

Should this be a concern, there is a trivial mechanism to solve the 
problem: just add some whitespace, as in

Resource-Priority:   routine
Resource-Priority:  priority
Resource-Priority: immediate
Resource-Priority:     flash
etc.

(I'm showing spaces before the r-value, but you can place these 
anywhere; they are just harder to see in email if I had put them after 
the label...)

Given this simple solution, I don't see a need for a change.

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 29 May 2005 17:02:58 -0500

At 05:43 PM 5/29/2005 -0400, Henning Schulzrinne wrote:
>>this document to state the algorithms/procedures used in each domain. Any 
>>mention of algorithms or procedures should only be as examples of what 
>>might occur in a domain.
>
>requested by the WG chair(s).

This was clearly pointed out by the SIP WG chair with the following message 
header:

Date: Wed, 17 Nov 2004 19:17:19 -0600
From: Dean Willis <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [Sip] Comments on Resource-priority-05

Mike - you did not comment on the list to this message from Dean, while 
others did.
References: <[email-masked]>
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>The authors would appreciate guidance from the chairs, as removal would, 
>in my opinion, contradict earlier advice from the WG chairs.

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

                      Alas, few *truths* exist without the math.

                             ...all else is a matter of perspective

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:07:21 -0400

> Section 12.1 2nd paragraph forbids adding a new priority value to a
 > namespace (MUST NOT). Previous versions of this draft (-06 and before)
 > allowed it, while advising against it (SHOULD NOT). For example, there
 > is no reason why another value cannot be added to DSN later, if the
 > operator of the DSN wishes to. If added, it is the responsibility of the
 > operator of the DSN domain to figure out how to do it to avoid
 > interoperability problems. For example, there is a possibility that the
 > DSN will need to add a new level below Routine. The RFC can not 
forbid this.

I'm happy to use SHOULD NOT, but I believe the MUST NOT reflected 
working group consensus, given that specs issues by the IETF have the 
obligation to avoid interoperability issues. A "SHOULD NOT" would only 
make sense, I believe, if we were to state when and where such additions 
are "safe". Just leaving the implementor, IANA and future standardizers 
with a vague "yellow flag" (SHOULD NOT) seems imprudent.

Earlier drafts had more unknown-namespace handling, so this might now 
have become simpler. Adding a new value in a namespace could, however, 
cause problems, for example, if a proxy ignored the namespace/priority 
value as being unknown, while a UAS relied on the proxy to have 
authenticated and authorized the request. That seems brittle.

In other words, before allowing a change, we need to understand whether 
this requires special care in IANA registration. If additions are 
allowed, we may have to change the proxy behavior description to be more 
picky for known namespaces and unknown labels. This error condition 
cannot occur at the moment.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:11:41 -0400

[email-masked] wrote:

> 
> Section 1, paragraph beginning "Since calls may traverse..." states that 
> "it is important that all such domains and elements apply the same 
> algorithms for the same namespace as otherwise the end-to-end experience 
> of privileged users may be compromised." While this may be true for some 
> combinations of preemption followed by queuing, it is not necessarily 
> true for all combinations and for any algorithm that might be added 
> later. Suggest that this sentence be reworded to say: "It is important 
> that careful consideration be made before different algorithms are used 
> at different places within a single call."

Noted and adjusted to simply say "It is strongly suggested ...". This is 
all non-normative in any event. Removed example to avoid giving offense.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:16:26 -0400

[email-masked] wrote:

> Although section 7 only gives "examples", the use of "DSN" causes 
> confusion since it shows an operation which would not be used in the DSN 
> domain. Specifically, the inclusion of the R-P header in the 180 and 200 
> in 7.1 and the list of accepted values in the 417 in 7.2 would not be 
> used in the DSN since this causes a security problem by telling the 
> originator what precedence level call the called party is involved in. 

There's a slightly different problem in that we decided, I believe, that 
the response header serves no particular purpose and can't be trusted by 
intermediaries, so the table in 3.3 doesn't specify its use. 
Unfortunately, this change didn't make it into the example. They are now 
gone.

> The example should use a domain that might use these techniques. Since 
> there is none that is known to work this way, the examples should use 
> "Foo" and "Bar" as in Section 8.2.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:24:17 -0400

[email-masked] wrote:

> Section 8.1 causes confusion since it implies the existence of a 
> relative order between different namespaces. It should instead say that 
> there is no defined relationship between the values of different 
> namespaces and that RP actors may apply whatever algorithms or 
> procedures they wish when dealing with multiple namespaces, as long as 
> the relative levels within each namespace are maintained.

As far as I can tell, the section does not imply any ordering beyond a 
single administrative domain. It simply says that

"If an *RP actor* understands multiple namespaces, it must create a 
*local* total ordering across all resource values from these namespaces" 
[emphasis added]

Maybe you can identify where such a namespace ordering is implied.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:27:27 -0400

Continuing to flood your mailbox (maybe this will convince the IESG of 
the need for an issue tracker for last-call comments :-)):

[email-masked] wrote:
> Section 10.3
> The final paragraph should be deleted, since it is not the 
> responsibility of this document to describe the detailed operation 
> within the DRSN, which could change at any time.

I'm happy to delete this, but this was inserted by request of working 
group members as it provides implementor information.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:33:47 -0400

[email-masked] wrote:

> Section 11.3
> The association of the requirement for confidentiality and integrity of 
> the user's data with the Resource-Priority header leads to confusion. 
> They are unrelated requirements. Other policies and requirements dictate 
> whether there is a need for confidentiality and integrity of the user's 
> data independently from the need for precedence levels. The first 
> paragraph should be deleted so that this section only addresses the 
> security of the R-P header itself, since that is the subject of this 
> document. Security of the user's data is not the subject of this document.

These requirements were, if I recall correctly, added based on either WG 
chair and/or AD suggestion. I await advice from the IESG whether this 
paragraph should be removed. They have been in the draft since 
draft-polk-sip-resource-03 (March 2003).

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:38:35 -0400

> Section 11.4
> No system that allows the use of the R-P header should allow anonymity. 
> In any case, the issue of anonymity is independent from the use of R-P 
> header and should not be mentioned in this document.

I don't know how you can know about all current and future R-P header 
deployments to make such a categorical statement.

Same considerations as discussed for Section 11.3. Nothing in this 
section requires the support of anonymity in RP systems. The section 
simply provides guidance to implementors should such support be desired.

Note, in paticular, that anonymity in the "do not know your name" does 
not imply lack of authentication or authorization. As the paragraph 
notes, capability-based certificates may well offer the functionality 
desired.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 29 May 2005 18:46:37 -0400

This is my final response to Mike's comments. I'd like to thank him for 
the careful reading of the document and his efforts to improve its 
clarity and technical correctness.

> Section 12.1
> The purpose of IANA registration is to prevent conflicts in assignment 
> of names and numbers, such as the namespace, and to ensure compatibility 
> for things like the priority values. There is no need to include the 
> "operation" (preemption or preferential queuing) in the IANA 
> registration. It is described sufficiently in this document. In fact, 
> the DSN uses other techniques besides preemption, such as exemption from 
> network management controls, as described in 
> draft-pierce-tsvwg-pref-treat-example, so it is wrong to register it as 
> just "preemption". Likewise, ETS may use other techniques besides 
> "queue", such as exemption from control restrictions and enhanced 
> routing (See explanation at www.ncs.gov/docs/GETS overview brief).
> 

Clearly, the draft and registration cannot and does not attempt to 
exhaustively specify all behaviors associated with a namespace. Any 
implementation will need to add, as per your example, description of the 
relationship to other aspects mentioned in the draft, such as routing 
and management controls.

Either we remove all useful descriptions of behavior, contradicting 
earlier SIP WG chair advice, or the IANA registration needs to carry 
forth the collection of this information where it is available.

I have added a disclaimer

"Other behavior, such as request routing or network management controls, 
is not defined by this specification."

earlier in the text.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 29 May 2005 17:53:50 -0500

At 06:27 PM 5/29/2005 -0400, Henning Schulzrinne wrote:
>Continuing to flood your mailbox (maybe this will convince the IESG of the 
>need for an issue tracker for last-call comments :-)):
>
>[email-masked] wrote:
>>Section 10.3
>>The final paragraph should be deleted, since it is not the responsibility 
>>of this document to describe the detailed operation within the DRSN, 
>>which could change at any time.
>

This was explicitly requested because this is a change in the operation 
from other namespaces in that the requesting priority level of FOO is 
defended at a lower level (FO). This is the only current known case of this 
operation, and implementors should have a hint at this operation.

cheers,
James

                                 *******************