Network Working Group                                       G. Camarillo
Request for Comments: 5002                                     G. Blanco
Category: Informational                                         Ericsson
                                                             August 2007
        
Network Working Group                                       G. Camarillo
Request for Comments: 5002                                     G. Blanco
Category: Informational                                         Ericsson
                                                             August 2007
        

The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)

会话启动协议(SIP)P-Profile-Key专用头(P-Header)

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Abstract

摘要

This document specifies the SIP P-Profile-Key P-header. This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the key of the profile corresponding to the destination SIP URI of a particular SIP request.

本文档指定了SIP P-Profile-Key P-header。该报头字段用于第三代合作伙伴关系项目(3GPP)IMS(IP多媒体子系统),以向SIP注册器和SIP代理服务器提供与特定SIP请求的目的SIP URI相对应的配置文件密钥。

Table of Contents

目录

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Scenario ........................................................2
   4. Requirements ....................................................3
   5. P-Profile-Key Header Field Definition ...........................3
   6. Applicability ...................................................4
   7. IANA Considerations .............................................4
   8. Security Considerations .........................................5
   9. Acknowledgements ................................................5
   10. References .....................................................5
      10.1. Normative References ......................................5
      10.2. Informative References ....................................6
        
   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Scenario ........................................................2
   4. Requirements ....................................................3
   5. P-Profile-Key Header Field Definition ...........................3
   6. Applicability ...................................................4
   7. IANA Considerations .............................................4
   8. Security Considerations .........................................5
   9. Acknowledgements ................................................5
   10. References .....................................................5
      10.1. Normative References ......................................5
      10.2. Informative References ....................................6
        
1. Introduction
1. 介绍

The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses SIP [RFC3261] as its main signalling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [3GPP.23.228] and 3GPP TS 24.229 [3GPP.24.229]). 3GPP has identified a set of requirements that can be met, according to the procedures in [RFC3427], by defining a new SIP P-header.

第三代合作伙伴计划(3GPP)IMS(IP多媒体子系统)使用SIP[RFC3261]作为其主要信令协议。(有关IMS的更多信息,可在3GPP TS 23.228[3GPP.23.228]和3GPP TS 24.229[3GPP.24.229]中找到详细说明)。3GPP已根据[RFC3427]中的程序,通过定义新的SIP P-header确定了一组可以满足的需求。

The remainder of this document is organized as follows. Section 3 describes the scenario considered by 3GPP and Section 4 discusses the requirements derived from this scenario. Section 5 defines the P-Profile-Key header field, which meets those requirements, and Section 6 discusses the applicability and scope of this new header field. Section 7 registers the P-Profile-Key header field with the IANA and Section 8 discusses the security properties of the environment where this header field is intended to be used.

本文件的其余部分组织如下。第3节描述了3GPP考虑的场景,第4节讨论了由此场景衍生的需求。第5节定义了满足这些要求的P-Profile-Key标题字段,第6节讨论了这个新标题字段的适用性和范围。第7节向IANA注册P-Profile-Key头字段,第8节讨论打算使用该头字段的环境的安全属性。

2. Terminology
2. 术语

HSS: Home Subscriber Server.

HSS:家庭订户服务器。

I-CSCF: Interrogating - Call/Session Control Function.

I-CSCF:询问-呼叫/会话控制功能。

Public Service Identity: A SIP URI that refers to a service instead of a user.

公共服务标识:引用服务而不是用户的SIPURI。

S-CSCF: Serving - Call/Session Control Function.

S-CSCF:服务-呼叫/会话控制功能。

Wildcarded Public Service Identity: A set of Public Service Identities that match a regular expression and share the same profile.

通配符公共服务标识:与正则表达式匹配并共享相同配置文件的一组公共服务标识。

3. Scenario
3. 脚本

In the 3GPP IMS, there are scenarios where a set of proxies handling a request need to consult the same user database, as described in [RFC4457]. Those proxies typically use the destination SIP URI of the request as the key for their database queries. Nevertheless, when a proxy handles a Wildcarded Public Service Identity, the key to be used in its database query is not the destination SIP URI of the request, but a regular expression instead.

在3GPP IMS中,存在处理请求的一组代理需要咨询同一用户数据库的场景,如[RFC4457]中所述。这些代理通常使用请求的目标SIPURI作为其数据库查询的密钥。然而,当代理处理通配符公共服务标识时,其数据库查询中使用的密钥不是请求的目标SIPURI,而是正则表达式。

Public Service Identities are SIP URIs that refer to services instead of users. That is, they address a specific application in an Application Server. Wildcarded Public Service Identities are a set of Public Service Identities that match a regular expression and share the same profile. For example, the Public Service Identities

公共服务标识是指服务而不是用户的SIPURI。也就是说,它们处理应用服务器中的特定应用程序。通配符公共服务标识是一组与正则表达式匹配并共享相同配置文件的公共服务标识。例如,公共服务身份

'sip:chatroom-12@example.com' and 'sip:chatroom-657@example.com' would match the Wildcarded Public Service Identity 'sip:chatroom-!.*!@example.com'. For a description of Wildcarded Public Service Identities, see 3GPP TS 23.003 [3GPP.23.003].

啜一口:聊天室-12@example.com和“啜饮:聊天室”-657@example.com“将匹配通配符公共服务标识”sip:chatroom-!*@example.com’。有关通配符公共服务标识的描述,请参阅3GPP TS 23.003[3GPP.23.003]。

When a proxy queries the user database for a Public Service Identity for which there is no profile in the user database, the user database needs to find its matching Wildcarded Public Service Identity. For example, if the user database receives a query for 'sip:chatroom-657@example.com', the user database needs to go through all the Wildcarded Public Service Identity it has until it finds a matching one; in this case, 'sip:chatroom-!.*!@example.com'. The process to find a matching Wildcarded Public Service Identity can be computationally expensive, time consuming, or both.

当代理向用户数据库查询用户数据库中没有配置文件的公共服务标识时,用户数据库需要找到其匹配的通配符公共服务标识。例如,如果用户数据库接收到对“sip:chatroom”的查询-657@example.com,用户数据库需要检查它拥有的所有通配符公共服务标识,直到找到匹配的标识;在本例中,'sip:chatroom-!*@example.com’。查找匹配的通配符公共服务标识的过程可能在计算上很昂贵、很耗时,或者两者兼而有之。

When two proxies query the user database for the same Public Service Identity, which matches a Wildcarded Public Service Identity, the user database needs to perform the matching process twice. Having to perform that process twice can be avoided by having the first proxy obtain the Wildcarded Public Service Identity from the user database and transfer it, piggy-backed in the SIP message, to the second proxy. This way, the second proxy can query the user database using the Wildcarded Public Service Identity directly.

当两个代理向用户数据库查询与通配符公共服务标识匹配的相同公共服务标识时,用户数据库需要执行两次匹配过程。通过让第一个代理从用户数据库获取通配符公共服务标识,并在SIP消息中将其传输到第二个代理,可以避免必须执行该过程两次。这样,第二个代理可以直接使用通配符公共服务标识查询用户数据库。

An alternative, but undesirable, solution would consist of having the user database store every Public Service Identity and its matching Wildcarded Public Service Identity. The scalability and manageability properties of this approach are considerably worse than those of the approach described earlier.

另一种不受欢迎的解决方案是让用户数据库存储每个公共服务标识及其匹配的通配符公共服务标识。这种方法的可伸缩性和可管理性比前面描述的方法要差得多。

4. Requirements
4. 要求

This section lists the requirements derived from the previous scenario:

本节列出了从上一个场景派生的需求:

1. It is necessary to optimize the response time for session establishment in the 3GPP IMS.

1. 有必要优化3GPP IMS中会话建立的响应时间。

2. It is necessary to keep the user database's size and maintenance manageable (e.g., storing individual Public Service Identities matching a Wildcarded Public Service Identity in the user database is not believed to be an acceptable solution).

2. 有必要保持用户数据库的大小和维护可管理(例如,在用户数据库中存储与通配符公共服务标识匹配的单个公共服务标识被认为是不可接受的解决方案)。

5. P-Profile-Key Header Field Definition
5. P-Profile-Key头字段定义

This document defines the SIP P-Profile-Key P-header. The P-Profile-Key P-header contains the key to be used by a proxy to query the user database for a given profile.

本文档定义了SIP P-Profile-Key P-header。P-Profile-Key P-header包含代理用来查询用户数据库中给定配置文件的密钥。

The augmented Backus-Naur Form (BNF) [RFC4234] syntax of the P-Profile-Key header field is the following:

P-Profile-Key报头字段的增广巴科斯诺尔形式(BNF)[RFC4234]语法如下所示:

P-Profile-Key = "P-Profile-Key" HCOLON (name-addr / addr-spec) *( SEMI generic-param )

P-Profile-Key=“P-Profile-Key”HCOLON(名称addr/addr spec)*(半通用参数)

The format of HCOLON, name-addr, addr-spec, and generic-param are defined in [RFC3261]. The format of Wildcarded Public Service Identities is defined in 3GPP TS 23.003 [3GPP.23.003]. They take the form of Extended Regular Expressions (ERE) as defined in Chapter 9 of IEEE 1003.1-2004 Part 1 [IEEE.1003.1-2004].

[RFC3261]中定义了HCOLON、name addr、addr spec和generic param的格式。通配符公共服务标识的格式在3GPP TS 23.003[3GPP.23.003]中定义。它们采用IEEE 1003.1-2004第1部分[IEEE.1003.1-2004]第9章中定义的扩展正则表达式(ERE)形式。

The following is an example of a P-Profile-Key header field that contains a Wildcarded Public Service Identity:

以下是包含通配符公共服务标识的P-Profile-Key头字段的示例:

      P-Profile-Key: <sip:chatroom-!.*!@example.com>
        
      P-Profile-Key: <sip:chatroom-!.*!@example.com>
        
6. Applicability
6. 适用性

According to [RFC3427], P-headers have a limited applicability. Specifications of P-headers such as this RFC need to clearly document the useful scope of the proposal, and explain its limitations and why it is not suitable for the general use of SIP on the Internet.

根据[RFC3427],P-Header的适用性有限。该RFC等P-Header规范需要清楚地记录提案的有用范围,并解释其局限性以及为什么不适合在Internet上普遍使用SIP。

The P-Profile-Key header field is intended to be used in 3GPP IMS networks. This header field carries the key of a service profile, that is stored in a user database referred to as HSS, between two proxies, which are referred to as I-CSCF and S-CSCF. The I-CSCF and the S-CSCF belong to the same administrative domain and share a common frame of reference to the user database. The I-CSCF inserts the P-Profile-Key header field into a SIP request and the S-CSCF removes it before routing the request further. (For a description of how an I-CSCF and an S-CSCF query the same user database for a single request, see [RFC4457].)

P-Profile-Key报头字段旨在用于3GPP IMS网络中。该报头字段在两个代理(称为I-CSCF和S-CSCF)之间携带服务配置文件的密钥,该密钥存储在称为HSS的用户数据库中。I-CSCF和S-CSCF属于同一管理域,并共享用户数据库的公共参考框架。I-CSCF将P-Profile-Key报头字段插入到SIP请求中,S-CSCF在进一步路由请求之前将其删除。(有关I-CSCF和S-CSCF如何为单个请求查询同一用户数据库的说明,请参阅[RFC4457]。)

Typically, when SIP is used on the Internet, there are not multiple proxies with a trust relationship between them querying the same user database. Consequently, the P-Profile-Key header field does not seem useful in a general Internet environment.

通常,在Internet上使用SIP时,不会有多个代理在查询同一用户数据库时具有信任关系。因此,P-Profile-Key头字段在一般的Internet环境中似乎没有用处。

7. IANA Considerations
7. IANA考虑

This document defines a new SIP header field: P-Profile-Key. This header field has been registered by the IANA in the SIP Parameters registry under the Header Fields subregistry.

本文档定义了一个新的SIP头字段:P-Profile-Key。IANA已在SIP参数注册表的header Fields子区下注册了此header field。

8. Security Considerations
8. 安全考虑

The P-Profile-Key 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-Profile-Key header field will be used ensures the integrity and the confidentiality of the contents of this header field. The P-Profile-Key header field MUST NOT be used in environments that do not have these characteristics.

本文档中定义的P-Profile-Key用于元素受信任且攻击者不应访问这些元素之间的协议消息的环境中。网元之间的流量保护有时通过使用IPsec实现,有时通过物理保护网络实现。在任何情况下,使用P-Profile-Key头字段的环境都可以确保该头字段内容的完整性和机密性。在不具备这些特征的环境中,不得使用P-Profile-Key头字段。

The P-Profile-Key header field needs to be integrity protected to keep attackers from modifying its contents. An attacker able to modify the contents of this header field could make the network apply a different service than the one corresponding to the request carrying the P-Profile-Key header field.

P-Profile-Key头字段需要完整性保护,以防止攻击者修改其内容。能够修改此标头字段内容的攻击者可能会使网络应用与携带P-Profile-Key标头字段的请求对应的服务不同的服务。

The contents of the P-Profile-Key field need to be kept confidential. An attacker able to access the contents of this header field would obtain certain knowledge about the way services are structured in a given domain.

P-Profile-Key字段的内容需要保密。能够访问此标头字段内容的攻击者将获得有关给定域中服务结构方式的特定知识。

9. Acknowledgements
9. 致谢

Alf Heidermark and Timo Forsman provided input to this document. Miguel Angel Garcia-Martin performed an expert review on this document on behalf of the SIPPING working group. Jon Peterson provided comments on this document.

Alf Heidermark和Timo Forsman为本文件提供了信息。Miguel Angel Garcia Martin代表啜饮工作组对本文件进行了专家评审。乔恩·彼得森对此文件发表了评论。

10. References
10. 工具书类
10.1. Normative References
10.1. 规范性引用文件

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261]Rosenberg,J.,Schulzrinne,H.,Camarillo,G.,Johnston,A.,Peterson,J.,Sparks,R.,Handley,M.,和E.Schooler,“SIP:会话启动协议”,RFC 3261,2002年6月。

[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", BCP 67, RFC 3427, December 2002.

[RFC3427]Mankin,A.,Bradner,S.,Mahy,R.,Willis,D.,Ott,J.,和B.Rosen,“会话启动协议(SIP)的更改过程”,BCP 67,RFC 3427,2002年12月。

[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.

[RFC4234]Crocker,D.和P.Overell,“语法规范的扩充BNF:ABNF”,RFC 4234,2005年10月。

[3GPP.23.003] 3GPP, "Numbering, addressing and identification", 3GPP TS 23.003 3.15.0, October 2006.

[3GPP.23.003]3GPP,“编号、寻址和标识”,3GPP TS 23.003 3.15.012006年10月。

[IEEE.1003.1-2004] "Standard for information technology - portable operating system interface (POSIX). Base definitions", IEEE 1003.1-2004, 2004.

[IEEE.1003.1-2004]“信息技术标准-便携式操作系统接口(POSIX).基本定义”,IEEE 1003.1-2004,2004。

10.2. Informative References
10.2. 资料性引用

[RFC4457] Camarillo, G. and G. Blanco, "The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)", RFC 4457, April 2006.

[RFC4457]Camarillo,G.和G.Blanco,“会话启动协议(SIP)P-用户-数据库专用头(P-头)”,RFC 4457,2006年4月。

[3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 5.15.0, June 2006.

[3GPP.23.228]3GPP,“IP多媒体子系统(IMS);第2阶段”,3GPP TS 23.228 5.15.012006年6月。

[3GPP.24.229] 3GPP, "Internet Protocol (IP) multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 5.18.0, October 2006.

[3GPP.24.229]3GPP,“基于会话发起协议(SIP)和会话描述协议(SDP)的互联网协议(IP)多媒体呼叫控制协议;第3阶段”,3GPP TS 24.229 5.18.012006年10月。

Authors' Addresses

作者地址

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰

   EMail: Gonzalo.Camarillo@ericsson.com
        
   EMail: Gonzalo.Camarillo@ericsson.com
        

German Blanco Ericsson Via de los Poblados 13 Madrid 28033 Spain

德国布兰科爱立信Via de los Poblados 13马德里28033西班牙

   EMail: German.Blanco@ericsson.com
        
   EMail: German.Blanco@ericsson.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.