Subject: [Sipping] Draft: Analysis of draft-allen-sipping-poc-p-headers-01.txt (LONG!)

From: Dean Willis <[email-masked]>
Date: Mon, 21 Feb 2005 22:24:31 -0600

The following is a draft of my analysis of the Allen POC P-headers 
draft. It is generally favorable towards publication of the requested 
P-headers, although somewhat criticial of the presentation in the draft.

Please provide feedback.

I'm specifically concerned that I represented correctly our discussionos 
  of the proposed alternatives to P-Alerting-Mode.

I'm also concerned that the "presumption of function" for P-Asnwer-State 
is correct. I found the description of the function in the draft to be 
quite unclear, and this is my effort to state concisely what I think it 
is doing.

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

This document reports an analysis of the Internet Draft "Private Header 
(P-Header) Extensions to the Session Initiation Protocol (SIP) for the 
Open Mobile Alliance (OMA) Push to talk over Cellular (PoC)" as 
presented in draft-allen-sipping-poc-p-headers-01.txt

The author of this draft has requested publication of the draft as an 
informational RFC and concomitant registration of two new SIP extension 
headers in the "P-" header class.

Summary of review; The draft needs additional work in its security and 
applicability statement sections and could benefit greatly from 
increased clarity in its descriptive text, but is not fundamentally 
flawed with respect to the SIP model or the requirements for publication.

The material of this analysis was prepared by a "designated expert" 
(SIPPING co-chair Dean Willis) based on personal knowledge and review of 
the document on the SIPPING working group's email list, as well as 
consultations with other more specific subject experts. Numerous 
comments were received by the reviewer, including extensive discussion 
with Paul Kyzivat, Mike Hammer, and Jonathan Rosenberg. This review will 
be circulated on the SIPPING working group mailing list for 
consideration before submission to the Transport Area Director.

The procedure for registration of "P-" headers is documented in RFC3427.

This process includes the following elements:

-----------
    1.  A designated expert (as defined in RFC 2434 [4]) MUST review the
        proposal for applicability to SIP and conformance to these
        guidelines.  The Expert Reviewer will send email to the Transport
        Area Directors on this determination.  The expert reviewer can
        cite one or more of the guidelines that haven't been followed in
        his/her opinion.

    2.  The proposed extension MUST NOT define SIP option tags, response
        codes, or methods.

    3.  The function of the proposed header MUST NOT overlap with current
        or planned chartered extensions.

    4.  The proposed header MUST be of a purely informational nature, and
        MUST NOT significantly change the behavior of SIP entities which
        support it.  Headers which merely provide additional information
        pertinent to a request or a response are acceptable.  If the
        headers redefine or contradict normative behavior defined in
        standards track SIP specifications, that is what is meant by
        significantly different behavior.

    5.  The proposed header MUST NOT undermine SIP security in any sense.
        The Internet Draft proposing the new header MUST address security
        issues in detail as if it were a Standards Track document.  Note
        that, if the intended application scenario makes certain
        assumptions regarding security, the security considerations only
        need to meet the intended application scenario rather than the
        general Internet case.  In any case, security issues need to be
        discussed for arbitrary usage scenarios (including the general
        Internet case).

    6.  The proposed header MUST be clearly documented in an (Individual
        or Working Group) Informational RFC, and registered with IANA.

    7.  An applicability statement in the Informational RFC MUST clearly
        document the useful scope of the proposal, and explain its
        limitations and why it is not suitable for the general use of SIP
        in the Internet.

    Any implementation of a "P-" header (meaning "not specified by a
    standards-track RFC issued through the SIP Working Group") MUST
    include a "P-" prefix on the header, as in "P-Headername".  Note that
    "P-" extensions are not IETF standards of any kind, and MUST NOT be
    required by any production deployment considered compliant to IETF
    specifications.  Specifically, implementations are only SIP compliant
    if a) they fall back to baseline behavior when they ignore all P-
    headers, and b) when using P- headers they do not contradict any
    normative behavior.

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

The draft defines two "P-" headers which this review addresses on an 
individual basis.

Discussion of "P-Alerting-Mode" Header Field

Summary: A UAC optionally includes a P-Alerting-Mode header field in an 
INVITE request to "request that the terminating SIP UAS alert the user 
according to the mode indicated by the parameter contained in the 
header." The draft conflates "alerting" and "answering", as the expected 
behavior is that the UAS will either treat the INVITE request normally 
or  "auto answer" (return a 200 OK without user input) based on the 
value of the "P-Alerting-Mode" header field value. The draft defines 
three values of the  "P-Alerting-Mode" header field: one to request that 
the UAS answer only if a user actually responds, one to request 
automatic answer if the UAS's settings allow this option, and one to 
override the UAS's settings and force automatic answer.

Background of this topic in the IETF

There have been several discussions in the SIP and SIPPING working 
groups as to how a UAC might request automatic answer from a UAS that 
supports this function. Historically, the consensus has been that this 
should be a feature of a specific UAS implementation, and could be 
indicated in the request by a parameter on the request URI or some kind 
of header, although there was never consensus to pursue the "some kind 
of header" as a standard.

Point-by-point Analysis of Proposed "P-Alerting-Mode" Header Field

1) Rqmt: Expert review. This memo serves as the required report by the 
designated expert to the Transport Area Directors.

2) Rqmt: The proposed extension MUST NOT define SIP option tags, 
response codes, or methods. Review: This draft is compliant with this 
requirement.

3) Rqmt: The function of the proposed header MUST NOT overlap with 
current or planned chartered extensions. Review: Here, we have a 
discussion point: The proposed header indicates a caller's preference 
for specific handling of the request by the callee. This overlaps at a 
general level with RFC 3840 and 3841. The proposed header clearly 
provides an alternate mechanism for negotiation of caller preferences 
and callee capabilities. However, the specific capability being 
negotiated does NOT overlap with specific capabilities already 
registered for the mechanism established by RFC 3840 and RFC 3841. 
Further, the preference being negotiated does not apply at the request 
routing layer (e.g., "Send this request to all mobiles that are willing 
to auto-answer") but to the behavior of a UAS as it responds to a 
particular INVITE request. This appears to put the behavior under 
discussion outside the scope of RFC 3840 and RFC 3841 (although OMA 
SHOULD still use the 3840/3841 mechanism to select POC-capable endpoints 
from among the set of contacts registered to an AoR).

4) Rqmt: The proposed header MUST be of a purely informational nature 
and MUST NOT significantly change the behavior of SIP entities which 
     support it. Review: This aspect is somewhat debatable, and 
conflicting opinions were received by the reviewer. The general 
consensus seems to be that since the preferences indicated by this 
header could have been expressed using other mechanisms including 
caller-preferences and request-URI parameters, and the the fallback 
position is to ignore the header, that the proposed header is compliant 
with this requirement.

5) Rqmt: The proposed header MUST NOT undermine SIP security in any 
sense. Review: There is a potential issue with this draft. One of the 
values proposed for the "P-Alerting-Info" header is "MAO", meaning 
"manual answer override". This value indicates that the UAC is claiming 
a "privilege" level that the UAC should respect by forcing auto-answer 
mode, even if such operation is contrary to the user's settings in the 
UAS. This has a high abuse potential, potentially allowing things like 
unsolicited transmissions (i.e., "spam") to be broadcast out of the 
loud-speaker on a victimized UAS. Although the draft mentions that these 
requests may be subject to authorization policy on the UAS, it is 
markedly deficient in particulars for satisfying reasonable security 
requirements. Further, the draft clearly has a dependency on networks 
with trusted intermediaries that perform authentication and most aspects 
of authorization control, and a further dependency on trusted transport, 
in order to maintain appropriate security. These dependencies are not 
adequately discussed in the draft.

6) Rqmt: The proposed header MUST be clearly documented in an 
(Individual or Working Group) Informational RFC, and registered with 
IANA. Review: The internet-draft under consideration is an attempt to 
meet this requirement. While it has several editorial issues that would 
ostensibly preclude publication as an informational RFC in the current 
form, these could be addressed by the common editorial review process.

7) Rqmt: An applicability statement in the Informational RFC MUST 
clearly document the useful scope of the proposal, and explain its 
   limitations and why it is not suitable for the general use of SIP 
     in the Internet. Review: The draft contains an applicability 
statement that does refer to a dependency on trusted intermediaries. 
However, further discussion of this limitation and its impacts is 
warranted. Much of this material is evident in RFC 3455, and insertion 
of said material would be a straightforward editorial exercise.

Detailed Discussion of Alternatives for "P-Alerting-Mode" Header Field

The draft discusses several alternatives that were explored, and 
rejected by the OMA POC working group. Further discussion follows.

Alternative 1: Use of a Request URI parameter. The drafts states "There 
was a proposal to add a URI parameter to the request URI.  This was 
rejected because the answer mode of the terminating party is not an 
attribute of the Request-URI, but is an attribute of the session." In 
SIP, the request URI indicates a target point for a session. 
Consequently it may be extremely appropriate to include parameters that 
relate to a specific session in the request-URI. This modality is 
clearly demonstrated in RFC 3087, "Control of Service Context using SIP 
Request-URI". However, there is a limitation to the use of Request URI 
that may make it an innapropriate solution to the requirements indicated 
in this draft. Specifically, request-URI parameters may not traverse the 
  proxy retargeting used to bind a contact address to an address of 
record. Consequently, the proxies used by PoC would require special 
behavior, which would constitute a generally undesirable characteristic.

Alternative 2: Use of a media feature tag. The draft states "There was a 
proposal to add it as a feature tag in the Accept-Contact header.  This 
was rejected because it was not agreed that the answer mode is a 
different  feature or capability of the UA, but is an attribute of the 
session and can be applied to many different features.  There was also 
concern that frequent changes in the answer mode settings in the 
terminal and corresponding callee capabilities refresh registrations 
would provide a heavy load on the registrar."

This argument is partially erroneous. From the IETF perspective, media 
feature tags apply selectivity to the establishment (via routing) on a 
per-session basis. Media feature tags can be used to match on support 
for one or more given applications, media formats, control protocols, 
user-interface capabilities, and many more. However, media feature tags 
are primarily seen as a routing mechanism, i.e. "Please route this 
request to the set of contacts that support this  behavior'. Use of 
changes in the routing mechanism to reflect dynamic changes in user 
preference settings would seem to be potentially problematic from a 
performance perspective, and not consistent with the semantics of 
media-feature tags as generally understood.

Alternative 3: Use of additional SDP parameters or additional body 
parts. Use of an additional body part to influence SIP signaling and 
state machines in the absence of an associated media-feature or option 
tag to control routing is undesirable because the new body parts are 
likely to be received by UAS that do not know how to respond. An SDP 
parameter might work, but the semantic match is less than ideal.

Conclusion and Recommendation on "P-Alerting-Mode":

 From the perspective of the SIPPING working group, it does not appear 
that we have a better alternative to the mechanism proposed in this 
draft. Discussion of possible alternatives indicated significant gaps 
between different understandings of the caller preferences and callee 
capabilities mechanism (RFC 3840, RFC 3841), so further discussion of 
alternatives may be warranted.

The text of the reviewed drafts has significant weaknesses in its 
security considerations and applicability statements that preclude 
publication of the draft as presented as an RFC. It is the opinion of 
this reviewer that the draft could be revised with editorial assistance 
into a publishable state without significant alteration to the 
"P-Alerting-Mode" mechanism as defined in the draft. Consequently, this 
reviewer recommends to the Transport Area Directors that this draft  be 
revised and resubmitted as required, then allowed to proceed as an 
informational track RFC defining the P-Alerting-Mode header field.

Discussion of "P-Answer-State" Header Field

Summary: This header field with a value of "UNCONFIRMED" may be included 
in provisional or successful final (200 class) responses to an INVITE 
transaction to indicate that some presumably knowledgeable element is 
predicting that the final UAS will eventually respond with a 200 OK. The 
presumption is that either some element already has elected to buffer 
the resultant media pending acceptance by the final UAS, or that some 
element would like an upstream element to begin such buffering. A second 
value of "CONFIRMED" indicates normal semantics for the response.

Further analysis of function:

This reviewer and all respondents from the SIPPING working group found 
the discussion of functionality in this draft to be unclear.

The presumptive behavior is that a UAS B2BUA with knowledge of the 
user's selected answer mode (automatic or manual) and a presumption of 
knowledge about the reachability of a targeted UAS would respond with a 
"P-Answer-State" header field having a value of "UNCONFIRMED". If this 
B2BUA is willing to accept the responsibility of buffering the media 
flow on behalf of the user, it sends a 200 OK with the aforementioned 
header. From the UAC's perspective, the transaction proceeds normally, 
except that the user MAY be presented with an indicator telling them 
that their utterance is being buffered and might not actually be 
received by the target.

If the responding B2BUA is not capable of handling the media buffering 
but would like some upstream B2BUA to know that an eventual acceptance 
is likely such that the upstream B2BUA would be encouraged to offer 
buffering, the downstream B2BUA sends a 100-class provisional response 
with a "P-Answer-State" header field having a value of "UNCONFIRMED".

This behavior doesn't really change the semantics of the request or 
response, but provides additional information that application-specific 
B2BUAs may use to adapt their behavior to the current situation.

Background of this topic in the IETF: This material bears some 
relationship to the precondition work of RFC 3312 and its approved 
update, draft-ietf-sip-rfc3312-update-03.txt. With RFC 3312, the 
buffering B2BUA would return a 200 OK upstream either because it has 
elected to buffer OR because it has received a reliable provisional 
response indicating a "buffering precondition", and would begin playout 
of the buffer on receipt of a 200 OK indicating satisfied preconditions 
(final acceptance). Use of the RFC 3312 mechanism was discussed in OMA, 
with a consensus forming against both because of its perceived 
complexity and because of possible IPR restrictions. This material also 
relates in some ways to the "early media" work. However, none of these 
mechanisms extends into the discussion of predictive buffering in 
back-to-back user agents, so the proposed mechanism does not appear to 
conflict with existing or proposed IETF work.

1) Rqmt: Expert review. This memo serves as the required report by the 
designated expert to the Transport Area Directors.

2) Rqmt: The proposed extension MUST NOT define SIP option tags, 
response codes, or methods. Review: This "P-Answer-State" elements of 
this draft are compliant with this requirement.

3) Rqmt: The function of the proposed header MUST NOT overlap with 
current or planned chartered extensions. Review: The P-Answer-State 
header field mechanism appears to be compliant with this requirement.

4) Rqmt: The proposed header MUST be of a purely informational nature 
and MUST NOT significantly change the behavior of SIP entities which 
     support it. Review: This aspect is somewhat debatable, and 
conflicting opinions were received by the reviewer. Clearly, the 
proposed header IS significantly affecting the behavior of the SIP 
entities that support it. However, these behavioral changes are 
effectively transparent (that is, do not change the transparency 
characteristics of the supporting entities) and the fallback behavior is 
"completely normal SIP". Therefore, the position of this reviewer is 
that the proposed mechanism (P-Answer-State) is compliant with this 
requirement.

5) Rqmt: The proposed header MUST NOT undermine SIP security in any 
sense. Review: Given the trust assumptions and model of the underlying 
application, the proposed P-Answer-State header appears to be compliant 
with this requirement.

6) Rqmt: The proposed header MUST be clearly documented in an 
(Individual or Working Group) Informational RFC, and registered with 
IANA. Review: The internet draft under consideration is an attempt to 
meet this requirement. It is unclear, substantively lacking in its 
discussion of the behavior at buffering and non-buffering user agents, 
and generally quite painful to read in the absence of a detailed 
understanding of the OMA POC model. It is the opinion of this reviewer 
that these issues could be addressed in the editorial process without 
significantly impacting the proposed mechanism.

7) Rqmt: An applicability statement in the Informational RFC MUST 
clearly document the useful scope of the proposal, and explain its 
   limitations and why it is not suitable for the general use of SIP 
     in the Internet. Review: The draft contains an applicability 
statement that does refer to a dependency on trusted intermediaries. 
However, further discussion of this limitation and its impacts is 
warranted. Much of this material is evident in RFC 3455, and insertion 
of said material would be a straightforward editorial exercise.  The 
"P-Answer-State" section of the document needs to further explain its 
specific applicability in the context of asynchronously buffering B2BUAs 
and the OMA POC application.

Conclusion and Reccomendation on "P-Answer-State"

The portions of the draft defining  the "P-Answer-State" header field 
are reasonably compliant with the requirements for publication under RFC 
  3427, but need substandtial work in terms of clarity, security 
considerations, and applicability statement.

_______________________________________________
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