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)
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-プロフィールキーP-ヘッダーを指定します。このヘッダーフィールドは、特定のSIPリクエストの送信先SIP URIに対応するプロファイルの鍵とSIPレジストラと、SIPプロキシサーバを提供するために、第3世代パートナーシッププロジェクト（3GPP）は、IMS（IPマルチメディアサブシステム）で使用されています。
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
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.
第3世代パートナーシッププロジェクト（3GPP）は、IMS（IPマルチメディアサブシステム）は、その主シグナリングプロトコルとしてSIP [RFC3261]を使用します。 （IMSの詳細については、詳細な説明は、3GPP TS 23.228 [3GPP.23.228]および3GPP TS 24.229 [3GPP.24.229]に見出すことができます）。 3GPPは、新しいSIP P-ヘッダを定義することによって、[RFC3427]の手順に従って、満たすことができる要件のセットを同定しました。
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-プロフィールキーヘッダーフィールドを定義し、セクション6は、この新しいヘッダーフィールドの適用性と範囲を説明します。 IANAとセクション8のセクション7つのレジスタP-プロフィールキーヘッダーフィールドは、このヘッダフィールドを使用することが意図されている環境のセキュリティ特性を論じています。
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.
公共サービスアイデンティティ：SIP URIではなく、ユーザのサービスを指します。
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.
ワイルドカード化パブリック・サービス・アイデンティティ：正規表現に一致し、同じプロファイルを共有するパブリック・サービス・アイデンティティのセット。
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]に記載されるように要求を処理するプロキシのセットは、同じユーザデータベースを参照する必要があるシナリオがあります。これらのプロキシは、典型的には、そのデータベースクエリのキーとして要求先SIP URIを使用します。プロキシはワイルドカードを使用パブリック・サービス・アイデンティティを処理する際にもかかわらず、そのデータベースのクエリで使用する鍵ではなく、要求の送信先SIP URIが、正規表現ではありません。
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
パブリック・サービス・アイデンティティ・サービスの代わりに、ユーザーを参照するSIP URIのです。それは、彼らがアプリケーションサーバーで特定のアプリケーションを扱う、です。ワイルドカード化パブリック・サービス・アイデンティティの正規表現に一致し、同じプロファイルを共有するパブリック・サービス・アイデンティティのセットです。例えば、公共サービスアイデンティティ
'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].
'！：チャットルーム - * @ example.com一口。！' '一口：chatroom-12@example.com' と '一口chatroom-657@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：！。チャットルーム - * @ 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.
2つのプロキシは、ワイルドカードを使用パブリック・サービス・アイデンティティと一致し、同じ公共サービスアイデンティティのためのユーザデータベースを照会すると、ユーザーデータベースは二回マッチング処理を実行する必要があります。二回そのプロセスを実行するために有する第二のプロキシに、ピギーバックSIPメッセージ内の、最初のプロキシがユーザデータベースからワイルドカードを使用パブリックサービスIDを取得し、それを転送有することによって回避することができます。この方法では、第二プロキシは、直接、ワイルドカードを使用し、公共サービスのアイデンティティを使用してユーザーデータベースを照会することができます。
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.
代替は、望ましくない、ソリューションは、ユーザデータベースストアすべてのパブリック・サービス・アイデンティティとその一致するワイルドカードを使用パブリック・サービス・アイデンティティを持つことからなります。この手法のスケーラビリティと管理特性は、前述のアプローチのものよりもかなり悪いです。
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.（例えば、ユーザ・データベース内のワイルドカードを使用パブリックサービスアイデンティティに一致するが、受け入れ可能な解決策ではないと考えられる個体パブリックサービスアイデンティティを格納する）ユーザデータベースのサイズおよび保守管理を維持する必要があります。
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-プロファイルキーP-ヘッダを定義しています。 P-プロファイルキーP-ヘッダは、特定のプロファイルのためのユーザ・データベースを照会するためにプロキシによって使用されるキーを含みます。
The augmented Backus-Naur Form (BNF) [RFC4234] syntax of the P-Profile-Key header field is the following:
拡張バッカスナウア記法（BNF）P-プロフィールキーヘッダーフィールドの[RFC4234]の構文は次のとおりです。
P-Profile-Key = "P-Profile-Key" HCOLON (name-addr / addr-spec) *( SEMI generic-param )
P-プロファイルキー= "P-プロファイルキー" HCOLON（名前-addrに/ ADDR-SPEC）*（SEMIジェネリック-PARAM）
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].
HCOLON、名前-ADDR、ADDR仕様、および一般的な-PARAMのフォーマットは、[RFC3261]で定義されています。ワイルドカードを使用し公共サービスアイデンティティの形式は、3GPP TS 23.003 [3GPP.23.003]で定義されています。 IEEE 1003.1から2004の第9章で定義されるように、それらは[IEEE.1003.1-2004】第1拡張正規表現（ERE）の形をとります。
The following is an example of a P-Profile-Key header field that contains a Wildcarded Public Service Identity:
以下は、ワイルドカードを使用し、公共サービスのアイデンティティが含まれているP-プロフィールキーヘッダーフィールドの例です。
P-Profile-Key: <sip:chatroom-!.*!@example.com>
P-プロファイルキー：<一口：！。！チャットルーム - * @ example.com>
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-ヘッダは限られた適用性を有します。など、このRFCとしてP-ヘッダの仕様は明らかに提案の有益な範囲を文書化する必要があり、その限界を説明し、それがインターネット上で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-プロフィールキーヘッダーフィールドは、3GPP IMSネットワークで使用されることが意図されます。このヘッダーフィールドは、I-CSCFとS-CSCFと呼ばれる2つのプロキシの間、それはHSSと呼ばれるユーザ・データベースに格納され、サービスプロファイルのキーを運びます。 I-CSCFおよびS-CSCFは、同じ管理ドメインに属し、ユーザーのデータベースへの参照の共通フレームを共有します。 I-CSCFは、SIP要求にP-プロフィールキーヘッダーフィールドを挿入し、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.
SIPは、インターネット上で使用される場合、典型的には、同じユーザデータベースを照会それらの間の信頼関係を持つ複数のプロキシが存在しません。その結果、P-プロフィールキーヘッダーフィールドは、一般的なインターネット環境で有用でいないようです。
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.
P-プロファイルキー：この文書は、新しいSIPヘッダフィールドを定義します。このヘッダーフィールドは、ヘッダフィールド副登録下SIPパラメータレジストリにIANAによって登録されています。
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-プロファイルキーは、要素が信頼されていると、攻撃者がこれらの要素間のプロトコルメッセージへのアクセス権を持っていることになっていないところの環境で使用されるべきです。ネットワーク要素間のトラフィック保護は、時々、IPsecを使用して、時には物理的にネットワークを保護することにより達成されます。いずれにしても、P-プロフィールキーヘッダーフィールドが使用される環境では、整合性と、このヘッダフィールドの内容の機密性を確保します。 P-プロフィールキーヘッダーフィールドは、これらの特性を持っていない環境で使用してはいけません。
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-プロフィールキーヘッダーフィールドは、整合性がその内容を変更することから、攻撃者を保つために保護する必要があります。このヘッダフィールドの内容を変更することができ、攻撃者は、ネットワークがP-プロフィールキーヘッダーフィールドを搬送する要求に対応するものとは異なるサービスを適用することができました。
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-プロファイルキーフィールドの内容は秘密にする必要があります。このヘッダフィールドの内容にアクセスすることができ、攻撃者は、サービスが特定のドメインで構成されている方法についての一定の知識を得るでしょう。
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.
アルフHeidermarkとティモForsmanは、この文書に入力を提供します。ミゲル・アンヘル・ガルシア・マーティンはSIPPINGワーキンググループを代表して、この文書に専門家の審査を行いました。ジョンピーターソンは、この文書にコメントを提供しました。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、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.0、2006年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。
[RFC4457] Camarillo, G. and G. Blanco, "The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)", RFC 4457, April 2006.
[RFC4457]キャマリロ、G.とG.ブランコ、 "セッション開始プロトコル（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.0、2006年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.0、2006年10月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
German Blanco Ericsson Via de los Poblados 13 Madrid 28033 Spain
ドイツのホワイトエリクソン経由・デ・ロス・Poblados 13マドリード28033スペイン
EMail: German.Blanco@ericsson.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。