[Sipping] Re: Expert review of draft-camarillo-sipping-profile-key-00.txt

[Miguel Garcia <[e-mail]>]

Hi:

I have no further comments on this revision. It addresses all my comments.

BR,

      Miguel

Gonzalo Camarillo wrote:
> Hi Miguel Angel,
> 
> thanks for your review. I have put together a new revision of the draft
> that addresses all your comments. Please, let me know if you have any
> further comments on this revision. Until it appears in the archives, you
> can fetch it from:
> 
> http://users.piuha.net/gonzalo/temp/draft-camarillo-sipping-profile-key-01.txt 
> 
> 
> Thanks,
> 
> Gonzalo
> 
> Miguel Garcia wrote:
>> Hi:
>>
>> I have been requested to perform an expert review, on behalf of
>> SIPPING, on the following draft:
>>
>> draft-camarillo-sipping-profile-key-00.txt
>>
>> Following the template in RFC 3427:
>>
>> 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.
>>
>> I am the designated expert and I am cc:ing the RAI ADs in this email.
>>
>>
>> 2.  The proposed extension MUST NOT define SIP option tags, response 
>> codes, or methods.
>>
>> The document defines the P-Profile-Key header field. No option tags, 
>> response codes, or methods, are defined. Thus, the requirement is
>> met.
>>
>> 3.  The function of the proposed header MUST NOT overlap with current
>>  or planned chartered extensions.
>>
>> The P-Profile-Key header field does not relate to any ongoing or
>> planned chartered extensions, 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 P-Profile-Key header field allows a first proxy to provide a
>> second proxy with the key to be used by this second proxy to query
>> the user database for a given profile. Therefore, it is an
>> optimization to avoid a second lookup in a database. Session
>> establishment is not affected by the presence or absence of this
>> header. Therefore, this header field does not contradict any
>> normative behavior defined somewhere else.
>>
>> 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 document indicates that the header is to be applied to the IMS 
>> environment, within trusted elements (e.g., belonging to the same 
>> administrative domain) where protection is achieved by means of IPsec
>> or physical protection of the network.
>>
>> It seems that the draft just merely indicates what the security 
>> considerations are when the header is applied to the initially
>> planned environment, namely, IMS. Perhaps the draft should discuss
>> the consequences of applying this header to a public environment,
>> where the data contents could be spoofed. It is my opinion than, even
>> if the contents of this header could be spoofed, it does not offer
>> any benefit for mounting an attack (e.g., against the database). In
>> other words, a malicious entity could equally mount the attack
>> without accessing to the P-Profile-Key header field value.
>>
>> 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, although 
>> merely indicates that it is believed that the header is only useful
>> in IMS due to the IMS architectural design. However, the document
>> does not discuss why this header is not applicable to the public
>> Internet, even there were a use case for it. I believe the
>> P-Profile-Key header field is not applicable to the Internet because
>> it requires the second proxy to trust the first, in that the value of
>> the header is accurate, and there isn't a general available mechanism
>> for proxies to trust other proxies. Luck of this trust would allow a
>> first proxy to forge the contents of the P-Profile-Key header so that
>> the second proxy either retrieves a wrong service profile from the
>> user database (if the key points to a different profile), or the
>> query to the user database fails (if the key does not exist).
>> Besides, the assumption is that the architecture provides for two
>> proxies accessing the same user database, something that may not be a
>> common scenario in the Internet.
>>
>> 8. Other comments
>>
>> I have also other technical comments.
>>
>> 8.1) The document introduces the concept of Public Service Identities
>>  and  Wildcarded Public Service Identities in Section 2, however, the
>>  definition of them occurs after its first usage. I would recommend
>> to expand these two terms prior to any usage, perhaps in a new
>> missing section: Terminology.
>>
>> 8.2) Section 2, 4th paragraph uses (twice) the term "Wildcarded
>> Public User Identity". I believe this is a typo and should instead
>> refer to "Wildcarded Public Service Identity".
>>
>> 8.3) The last paragraph in Section 4 provides an example of the 
>> P-Profile-Key database that misses the 'sip:' scheme part of the URI:
>>
>>
>> P-Profile-Key: <chatroom-!.*!@example.com>
>>
>> 8.3) The acronyms HSS, I-CSCF, S-CSCF, should be expanded at their
>> first occurrence (so, in the second paragraph in Section 5).
>>
>> 8.4) I believe reference [1] is available in a more updated version
>> than 3.14.0, January 2004. You should refer to version 7.0.0 dated
>> June 2006. The same also applies to other referred 3GPP
>> specifications.
>>
>>
>> Miguel Garcia Designated reviewer for
>> draft-camarillo-sipping-profile-key-00.txt
>>
>>
>>
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland

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