[Sip] Expert review of draft-camarillo-sipping-user-database-01.txt: Revision required

[Dean Willis <[e-mail]>]

SIPPING Working Group: Please consider the following "P-header expert  
review" and let us know if you have any issues with it or further  
suggestions to make.

----------

Publication of draft-camarillo-sipping-user-database-01.txt as an  
informational document defining P-headers has been requested. Under  
the terms of RFC 3427, this requires addressing the following 7  
requirements:


   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.

Dean Willis was selected as the designated expert for this review. As  
per the current practice, the resulting review will have been  
discussed in the SIP community via the SIPPING working group's  
mailing list and evaluated for rough technical consensus before  
reporting a conclusive positive review to the Area Directors.

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

The reviewed document defines one "P-header" without an option tag,  
response code, or method, and therefore satisfies this requirement.

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

The proposed header provides for the communication of locally-valid  
state information between two proxies in the IMS environment as  
defined by 3GPP. It does not appear to relate in any significant way  
to any ongoing, planned, proposed, or even whimsically discussed work  
of the IETF known to the reviewer, and therefore satisfies this  
requirement.


    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.

The proposed header conveys information about the back-end database  
used by the originating proxy to a receiving proxy in the same IMS  
operator domain. This prevents the receiving proxy from having to  
repeat the resolution process used by the first proxy. In the absence  
of this extension, the resulting call flow would be identical, but  
would require one additional database operation. Consequently, the  
proposed extension appears to be consistent with the intent of this  
requirement.

    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).

The proposed extension header, "P-User-Database" applies only in IMS  
environments where the originating proxy (The P-CSCF) and the  
terminating proxy (the S-CSCF) exist in a protected environment  
sharing a mutual frame of reference to the database in question. The  
security relationship between these elements is defined by the IMS  
sprcifications.

The text given as the "Security Consideration" section of the  
reviewed document follows:

    "The P-User-Database defined in this document is to be used in an
    environment where elements are trusted and where attackers are not
    supposed to have access to the protocol messages between those
    elements.  Traffic protection between network elements is sometimes
    achieved by using IPsec and sometimes by physically protecting the
    network.  In any case, the environment where the P-User-Database
    header field will be used ensures the integrity and the
    confidentiality of the contents of this header field."

While the above text is believed correct, this reviewer finds these  
considerations to provide inadequate guidance to future readers of  
this specification who may not be conversant with the characteristics  
of IMS. No explicit reference to IMS is made by the reviewed  
document, and the characteristics of IMS that make the proposed  
extension viable are not elucidated by the reviewed document. This  
could be corrected by an explicit reference to IMS specifications,  
and by the inclusion in the revisions to the reviewed document of a  
summary elucidation of the relevant characteristics of IMS:

* The "P-User-Database" header field is inserted by a proxy element  
referred to as P-CSCF.

* The "P-User-Database" header field is consumed and removed by a  
proxy element referred to as S-CSCF.

* Both P-CSCF and S-CSCF are under the administrative control of a  
single operator, and share a common frame of reference to the  
database indicated by the P-User-Database header field.

The preceding elucidations or equivalent material should be contained  
in the "Applicability Statement" section of the final RFC.

* There is a slight security risk if the the P-User-Database header  
field is allowed is allowed to propagate out of the domain bounded by  
the administrative control of that operator. No user-sensitive  
information would be revealed by such a breach, but this could result  
in disclosure of information about the topology of the operator  
network that goes beyond the level of disclosure explicit in SIP  
messages without this extension. Consequently, operators my wish to  
be diligent about removal of the P-User-Database header field before  
sending a request containing it to other network operators or to user  
equipment.

The preceding elucidation or equivalent material should be contained  
in the "Security Considerations" section of the final RFC.


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

The reviewed document is intended to become the informational RFC  
required by this consideration. Acceptance of this document for  
publication as an informational RFC will address this requirement.

    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.

The reviewed document contains an applicability statement. This  
reviewer finds he current applicability statement inadequate, and has  
discussed additional material earlier in this review that if added  
should make the applicability statement adequate to address this  
consideration.



Note: It has been suggested to this reviewer that the proposed  
extension header field would benefit from the inclusion of extension  
parameter syntax, which has become the common practice for SIP  
extensions. Therefore it is suggested that the syntax be amended as  
follows:

OLD:
P-User-Database     = "P-User-Database" HCOLON database

NEW:
P-User-Database     = "P-User-Database" HCOLON database
                       *( SEMI generic-param )

Further note:

The document makes explicit reference to RFC 2119, but does not  
invoke any of the language of that RFC. For consistency with the  
current practices relating to informational-track documents,  
reference to RFC 2119 and the associated language definition section  
should be removed from revisions to the reviewed document.


Conclusion: While the proposed extension header is consistent with  
the requirements of RFC 3427, the document as reviewed fails to  
satisfactorily address the "Applicability Statement" and "Security  
Considerations" requirements of that RFC, requires two additional  
content modifications (syntax change and removal of RFC 2119  
references) and is therefore remanded to the author for revision.


--
Dean Willis
designated reviewer for draft-camarillo-sipping-user-database-01.txt

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