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

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 10 Dec 2005 10:51:58 +0200

Folks,

I have put together a new revision of this draft that addresses all the 
comments in this expert review. Until it appears in the archives, you 
can fetch it from:
http://users.piuha.net/gonzalo/temp/draft-camarillo-sipping-user-database-02.txt

Cheers,

Gonzalo

Dean Willis wrote:
> 
> I'd meant to send this to SIPPING, but somehow it went to SIP with a  
> display-name of SIPPING the first time. Odd.
> 
> 
> 
> 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
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Arjun Roychowdhury <[email-masked]>
Date: Sat, 10 Dec 2005 13:55:20 -0500

Minor Nit: Shouldn't the example of the P-User-Database be

P-User-Database: <aaa://host.example.com>;transport=tcp
instead of
P-User-Database: <aaa://host.example.com;transport=tcp>

Also, which version of IMS is this header going to be introduced and is the
presence of this header optional or MUST the be inserted by the I-CSCF ?

regds
arjun

--
Arjun Roychowdhury

---

From: Arjun Roychowdhury <[email-masked]>
Date: Sat, 10 Dec 2005 14:25:01 -0500

Never mind my Q on the example - its correct as it is.

The additional Qs on IMS version and strength hold.

regds
arjun

On 12/10/05, Arjun Roychowdhury <[email-masked]> wrote:
> Also, which version of IMS is this header going to be introduced and is
> the presence of this header optional or MUST the be inserted by the I-CSCF ?
>
> regds
> arjun
>
>