Subject: RE: [Sip] Comments on Resource-priority-05

From: "Dolly, Martin C, ALABS" <[email-masked]>
Date: Wed, 17 Nov 2004 20:10:13 -0600

Dean,

The SIP behavior needs to be defined in this draft. A SIP stack developer should be able to read this draft and understand the desired SIP behavior, without knowledge of the application processing.

Cheers,

Martin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Dean Willis
Sent: Wednesday, November 17, 2004 8:17 PM
To: [email-masked]; [email-masked]
Subject: Re: [Sip] Comments on Resource-priority-05

[email-masked] wrote:

> Based on the contents of previous versions of this draft, and comments 
> I and others have made, I believe that the following are essential for 
> the next version of this draft.
>
> The only normative information included per namespace should be:
>
> - name of the namespace
> - names of the priority levels
> - order of the priority values
> - default priority level (may be used if the receiving end does not 
> recognize a valid priority value)
>
> While the draft could detail various procedures which might be 
> applied, such as "modes", it should not associate any specific 
> procedure with any specific namespace.
>
> There should not be any other normative, mandatory behavior associated 
> with the use of the Resoure-priority header, such as specific 
> authorization procedures.
>
> In general, the draft can be made much shorter by deletion of 
> irrelevant material. For example, Section 7 describes procedures for 
> "move to the head of the line" scenarios for processing of messages in 
> SIP servers or UAs. It has been proposed in 
> draft-pierce-tsvwg-pref-treat-examples since April 2002 (and never 
> commented on) that there is no need to do such a thing. In fact, it is 
> not a good idea to intentionally change the order of messages..
>
This is a useful start. I believe we agree that there may be some 
content in -05 that is not required for publication.

Let, me, however, assert requirements for publishing a standards-track 
SIP extension. These are the kind of things that I expect any such 
document to meet, above the obvious "must have boilerplate, IANA 
considerations" and so on.

1) The document must contain, or contain references to, all information 
that a reasonable developer would need to build an interoperable 
implementation of the specification. Any referenced specifications must 
be publicly accessible, under the IETF's general guidelines for such. 
Examples might include documents from ITU, IEEE, W3C, ANSI, ETSI, and 
similar public specification authorities.

2) The SIP behavior of the extension and how it influences SIP dialog 
states, transaction results, etc. must be fully documented within the 
specification.

3) A system built using the specification can be analyzed and debugged 
using the non-SIP parts as a "black box". That is, the impact of the 
non-SIP functions must be apparent at the SIP level. If a request is 
rejected because of an extension, I want to know which extension, and by 
whom.

4) The threat model for attacks on this extension is clearly elucidated, 
and that the usage of available SIP mechanisms such as authentication, 
identity representation,SIPS, S/MIME, etc. is demonstrated in the text 
as adequate to mitigate those  threats or that additional mechanisms are 
detailed within the text as needed to mitigate those threats.

5) The requirements for any "extension of the extension" must be clearly 
spelled out.

Now, let's apply that to what has to be in this draft.

If the presence of header FOO in a request can cause that request or any 
other extant request, transaction, or dialog to be treated differently 
by ANY SIP element, including the terminating and originating UA, then 
the related SIP messaging must be explicitly detailed.

For example, if  a resource-priority header field in one request causes 
another dialog to be preempted, I want to know  what SIP messaging is 
sent to the participant(s) in the terminated dialog. (Example: BYE, with 
a Reason header, and which specific reason?) If the lack of a 
resource-priority header field (or a low-value priority)  in a request 
causes that request to be rejected, I want to know what SIP messaging is 
sent in the rejection. If a request is carrying a resource-priority 
header field or value that it is not authorized to use, and that causes 
the request to be rejected, diverted, or otherwise treated differently, 
I want to know what SIP messaging is sent back indicating the special 
handling.

I do not care WHAT the priority order is in a namespace that is 
externally documented, as long as that external document defines the 
priority ordering in a manner sufficient for a SIP implementor to build 
an interoperable implementation, or for an administrator to be able to 
determine whether observed system behavior is correct.

I do not care what the relative priority between namespaces in a 
particular node is, as long as there is some way to indicate which 
namespace held priority in any SIP messaging resulting from a priority 
comparison.

I do care if  attackers can, by simply inserting this new header, cause 
preemption or rejection of other calls. If this is a possible threat, I 
want it analyzed, and I want to have an explanation of how this relates 
to the security model and how applications of our security tools can 
keep this from happening.

I do care that fallbacks to "normal" behavior be documented, and that 
such issues as "What happens when a priority-aware element doesn't 
recognize a namespace" are properly explained.

I do care that the requirements for registering additional namespaces 
are clearly spelled out, and that it indicates that such namespaces must 
be defined by a referenceable specification, and that any registration 
of additional namespaces must include thorough documentation of any new 
SIP behavior induced by the new namespace. To me, that means a new 
namespace registration will need at least an informational track RFC, 
with expert review to make sure it meets these requirements. Obviously, 
it also requires that any namespaces registered IN THIS DOCUMENT be 
documented in adequate fashion so as to serve as guides for the 
documentation of any namespaces to be registered in the future.

My position is that we WILL NOT publish a standards-track SIP 
specification that simply defines a new header and defines a series of 
namespaces and possible values without explaining the effect on SIP of 
the presence of that a header, namespace, and values. We wouldn't even 
publish a non-standard P-header with this level of guidance, and we 
expect much more from a standards-track document.

--
Dean Willis
SIP co-chair

_______________________________________________
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

_______________________________________________
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: Janet P Gunn <[email-masked]>
Date: Thu, 18 Nov 2004 11:01:44 -0500

Those sound like good guidelines to me.

Janet

----------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
----------------------------------------------------------------------------------------

                      Dean Willis                                                                                            
                      <dean.willis             To:      [email-masked], [email-masked]                                       
                      @softarmor.com>          cc:                                                                           
                      Sent by:                 Subject: Re: [Sip] Comments on Resource-priority-05                           
                      sip-bounces                                                                                            

                      11/17/2004 08:17                                                                                       
                      PM                                                                                                     

--
Dean Willis
SIP co-chair