Network Working Group G. Camarillo
Request for Comments: 4457 G. Blanco
Category: Informational Ericsson
April 2006
The Session Initiation Protocol (SIP)
P-User-Database 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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (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 address of the database that contains the user profile of the user that generated a particular request.
この文書では、セッション開始プロトコル（SIP）P-ユーザーデータベースのプライベートヘッダ（P-ヘッダ）を指定します。このヘッダーフィールドは、特定の要求を生成したユーザのユーザプロファイルを含むデータベースのアドレスとSIPレジストラと、SIPプロキシサーバを提供するために、第3世代パートナーシッププロジェクト（3GPP）は、IMS（IPマルチメディアサブシステム）で使用されています。
Table of Contents
目次
1. Introduction ....................................................2
2. Scenarios .......................................................2
2.1. User Registering to the IMS ................................2
2.2. Incoming Request for an Unregistered User ..................3
3. Requirements ....................................................4
4. P-User-Database Header Field Definition .........................4
5. Applicability ...................................................5
6. IANA Considerations .............................................5
7. Security Considerations .........................................5
8. Acknowledgements ................................................6
9. References ......................................................6
9.1. Normative References .......................................6
9.2. Informative References .....................................6
The 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) uses the Session Initiation Protocol (SIP) [2] as its main signalling protocol. (For more information on the IMS, a detailed description can be found in 3GPP TS 23.228 [5] and 3GPP TS 24.229 [6].) 3GPP has identified a set of requirements that can be met, according to the procedures in RFC 3427 [3], by defining a new SIP Private-Header (P-header).
第3世代パートナーシッププロジェクト（3GPP）は、IMS（IPマルチメディアサブシステム）は、セッション開始プロトコル（SIP）を使用する[2]主シグナリングプロトコルとして。 （IMSの詳細については、詳細な説明は、3GPP TSに見出すことができる23.228 [5] 3GPP TS 24.229 [6]。）3GPPは、[RFC 3427の手順に従って、満たすことができる要件のセットを識別しました3]、新しいSIPプライベートヘッダ（P-ヘッダ）を定義すること。
The remainder of this document is organized as follows. Section 2 describes the scenarios considered by 3GPP and Section 3 discusses the requirements derived from these scenarios. Section 4 defines the P-User-Database header field, which meets those requirements, and Section 5 discusses the applicability and scope of this new header field. Section 6 registers the P-User-Database header field with the IANA and Section 7 discusses the security properties of the environment where this header field is intended to be used.
このドキュメントの残りは以下の通り構成されています。セクション2は、3GPPで検討シナリオを説明し、第3節では、これらのシナリオに由来する要件について説明します。セクション4は、これらの要件を満たすP-ユーザデータベースヘッダーフィールドを定義し、セクション5は、この新しいヘッダーフィールドの適用性と範囲を説明します。セクションIANAとセクション7と6つのレジスタP-ユーザデータベースヘッダーフィールドは、このヘッダフィールドを使用することが意図されている環境のセキュリティ特性を論じています。
In the 3GPP IMS, there are two scenarios where a set of proxies handling a request need to consult the same user database. These scenarios consist of a user registering to the IMS network and an unregistered user receiving an incoming request that triggers a service (e.g., a voice mail service).
3GPP IMSにおいて、要求を処理するプロキシのセットは、同じユーザデータベースを参照する必要がある2つのシナリオがあります。これらのシナリオは、IMSネットワークとサービス（例えば、ボイスメールサービス）をトリガする着信要求を受信した未登録のユーザにユーザ登録から成ります。
In the 3GPP IMS, SIP REGISTER requests generated by a User Agent (UA) traverse a set of SIP proxy servers before reaching the SIP registrar. A REGISTER request sent by a UA is routed to the outbound proxy of the UA, which is referred to as the P-CSCF (Proxy-Call/Session Control Function).
3GPP IMSでは、ユーザエージェント（UA）によって生成されたSIP REGISTERリクエストは、SIPレジストラに到達する前に、SIPプロキシサーバーのセットを横断します。 UAによって送信されたREGISTER要求はP-CSCF（プロキシ呼/セッション制御機能）と呼ばれるUAのアウトバウンドプロキシにルーティングされます。
The P-CSCF routes the REGISTER request to another proxy, which is referred to as the I-CSCF (Interrogating-CSCF) and is always located in the home domain of the user. The I-CSCF consults the user database of the domain, which is referred to as the Home Subscriber Server (HSS), in order to choose the registrar that will process the REGISTER request.
P-CSCFルートI-CSCF（ゲー-CSCF）と呼ばれ、常にユーザのホームドメインに位置する別のプロキシへREGISTERリクエスト。 I-CSCFは、REGISTERリクエストを処理するレジストラを選択するために、ホーム加入者サーバ（HSS）と呼ばれているドメインのユーザーデータベースを参照します。
With the information received from the HSS, the I-CSCF routes the REGISTER request to the appropriate registrar, which is referred to as the S-CSCF (Serving-CSCF). At this point, the S-CSCF needs to contact the same HSS that was previously contacted by the I-CSCF in order to fetch the user profile of the user that generated the REGISTER request.
情報をHSS、I-CSCFルートS-CSCF（-CSCFサービング）と呼ばれる適切なレジストラにREGISTERリクエストから受け取りました。この時点で、S-CSCFは、以前に登録要求を生成したユーザのユーザプロファイルを取得するためにI-CSCFによって接触されたのと同じHSSに連絡する必要があります。
The interface between the I-CSCF and the HSS and between the S-CSCF and the HSS is called Cx interface and is based on Diameter [4].
I-CSCFとHSSとの間及びS-CSCFとHSSとの間のインターフェースは、Cxのインタフェースと呼ばれ、直径に基づいている[4]。
When there is a single HSS (i.e., user database) handling all the users in the domain, both the I-CSCF and the S-CSCF can be configured with its address so that they contact it when necessary. However, some domains have several HSSs, each of which handles a particular set of users. When dealing with a REGISTER request, the I-CSCF and the S-CSCF need to discover which is the HSS that contains the profile of the user that generated the REGISTER request.
ドメイン内のすべてのユーザを取り扱う単一HSS（すなわち、ユーザ・データベース）がある場合、必要な場合、彼らはそれに接触するように、I-CSCFおよびS-CSCFの両方は、そのアドレスを使用して設定することができます。しかし、いくつかのドメインは、ユーザの特定のセットを処理それぞれがいくつかのHSSを有します。 REGISTERリクエストを扱う場合、I-CSCFおよびS-CSCFは、REGISTERリクエストを生成し、ユーザのプロファイルが含まれているHSSである発見する必要があります。
In networks with more than one HSS, a Diameter redirect agent referred to as the Subscription Locator Function (SLF) is implemented. The interface between the I-CSCF and the SLF and between the S-CSCF and the SLF is called Dx interface and, like the CX interface, is based on Diameter. The SLF provides the I-CSCF and the S-CSCF with the address of the HSS that handles the user they are dealing with.
複数のHSSを有するネットワークでは、直径リダイレクトエージェントは、サブスクリプションロケータ機能（SLF）が実装されていると称される。 I-CSCFとSLF間S-CSCFとSLFとの間のインタフェースは、Dxのインターフェースと呼ばれ、CXインタフェースと同様に、直径に基づいています。 SLFは、彼らが扱っているユーザーを扱うHSSのアドレスをI-CSCFおよびS-CSCFを提供します。
Therefore, in a network with more than one HSS, the SLF is consulted twice per REGISTER request, first by the I-CSCF, and later by the S-CSCF. If the I-CSCF could provide the S-CSCF with the address of the HSS handling the user that generated the REGISTER request, the S-CSCF could contact directly that HSS. That is, the S-CSCF would not need to contact the SLF in order to obtain the address of the HSS.
したがって、複数のHSSを有するネットワークにおいて、SLFは、第I-CSCFによって、REGISTERリクエストごとに二回参照され、以降のS-CSCFによって。 I-CSCFは、REGISTERリクエストを生成し、ユーザを扱うHSSのアドレスをS-CSCFを提供することができれば、S-CSCFは、HSSことに直接お問い合わせください可能性があります。つまり、S-CSCFは、HSSのアドレスを取得するためにSLFに連絡する必要はありません。
In the 3GPP IMS, incoming requests for a user traverse an I-CSCF in the home domain of the user. This I-CSCF consults the HSS, using the Diameter-based Cx interface, in order to decide which S-CSCF should handle the request. After consulting the HSS, the I-CSCF forwards the request to a S-CSCF, which is also located in the home domain of the user.
3GPP IMSでは、ユーザのための着信要求は、ユーザのホームドメインにI-CSCFを通過します。このI-CSCFは、S-CSCFは、要求を処理すべきかを決定するためには、直径ベースのCxインタフェースを使用して、HSSを参照します。 HSSを相談した後、I-CSCFは、ユーザーのホームドメインに位置しているS-CSCFに要求を転送します。
If the user the request is addressed to is registered to the IMS network, the S-CSCF receiving the request knows which HSS handles the user. The S-CSCF stored this information when the user registered. However, if the user is not registered, the S-CSCF needs to consult the SLF (assuming more than one HSS in the network) in order to discover the HSS handling the user.
ユーザー要求が宛れるがIMSネットワークに登録されている場合は、要求を受信したS-CSCFは、HSSは、ユーザを扱うかを知っています。 S-CSCFは、ユーザが登録し、この情報を記憶します。ユーザが登録されていない場合には、S-CSCFは、ユーザを処理するHSSを発見するために、（ネットワーク内に複数のHSSを想定）SLFを参照する必要があります。
Therefore, like in the previous scenario, in a network with more than one HSS, the SLF is consulted twice per incoming request addresses to an unregistered user. First by the I-CSCF, and later by the S-CSCF. If the I-CSCF could provide the S-CSCF with the address of the HSS handling the user that generated the request, the S-CSCF could contact directly that HSS. That is, the S-CSCF would not need to contact the SLF in order to obtain the address of the HSS.
したがって、前のシナリオと同様に、複数のHSSを有するネットワークにおいて、SLFは、未登録のユーザに二回着信要求アドレスごとに参照されます。まず、I-CSCFによって、後にS-CSCFによります。 I-CSCFは、要求を生成し、ユーザを扱うHSSのアドレスをS-CSCFを提供することができれば、S-CSCFは、HSSことに直接お問い合わせください可能性があります。つまり、S-CSCFは、HSSのアドレスを取得するためにSLFに連絡する必要はありません。
This section lists the requirements derived from the previous scenarios:
このセクションでは、前のシナリオから派生要件を示しています：
1. It is necessary to optimize the registration process in the 3GPP IMS by reducing the time it takes for a UA to register to the IMS network.
1. UAは、IMSネットワークに登録するのにかかる時間を減少させることによって、3GPP IMSへの登録処理を最適化する必要があります。
2. It is necessary to optimize the handling of incoming requests to unregistered users in the 3GPP IMS by reducing the time it takes for a domain to handle these requests.
2.これらの要求を処理するために、ドメインのにかかる時間を短縮することによって、3GPP IMSに未登録のユーザーに着信要求の処理を最適化する必要があります。
3. It is necessary to improve the scalability of SLFs in the 3GPP IMS by reducing the amount of traffic the SLF of a network needs to handle.
3.ネットワークのSLFを処理する必要があるトラフィックの量を減らすことによって、3GPP IMSにおけるSLFsのスケーラビリティを向上させる必要があります。
This document defines the SIP P-User-Database P-header. This header field can be added to requests routed from an I-CSCF to an S-CSCF. The P-User-Database P-header contains the address of the HSS handling the user that generated the request.
この文書は、SIP P-ユーザデータベースP-ヘッダを定義しています。このヘッダーフィールドは、S-CSCFにI-CSCFからルーティングされたリクエストに追加することができます。 P-ユーザデータベースP-ヘッダは、要求を生成したユーザを扱うHSSのアドレスを含みます。
The augmented Backus-Naur Form (BNF) [1] syntax of the P-User-Database header field is the following:
拡張バッカスナウア記法（BNF）[1] P-ユーザデータベースヘッダフィールドの構文は以下の通りです。
P-User-Database = "P-User-Database" HCOLON database *( SEMI generic-param ) database = LAQUOT DiameterURI RAQUOT
P-ユーザーデータベース= "P-ユーザーデータベース" HCOLONデータベース*（SEMIジェネリック-PARAM）データベース= LAQUOT DiameterURI RAQUOT
DiameterURI is defined in RFC 3588 [4]. HCOLON, LAQUOT, RAQUOT, and generic-param are defined in RFC 3261 [2].
DiameterURIは、RFC 3588で定義されている[4]。 HCOLON、LAQUOT、RAQUOT、および汎用-PARAMは、RFC 3261で定義されている[2]。
The following is an example of a P-User-Database header field:
以下ではP-ユーザデータベースヘッダフィールドの例です。
P-User-Database: <aaa://host.example.com;transport=tcp>
P-ユーザーデータベース：<AAA：//host.example.com;運輸= TCP>
According to RFC 3427 [3], 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.
RFC 3427によれば[3]、P-ヘッダは限られた適用性を有します。など、このRFCとしてP-ヘッダの仕様は明らかに提案の有益な範囲を文書化する必要があり、その限界を説明し、それがインターネット上でSIPの一般的な使用に適していない理由。
The P-User-Database header field is intended to be used in 3GPP IMS networks. This header field carries the address of a user database, which is 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-User-Database header field into a SIP request and the S-CSCF removes it before routing the request further.
P-ユーザデータベースヘッダフィールドは、3GPP IMSネットワークで使用されることが意図されます。このヘッダーフィールドは、I-CSCFとS-CSCFと呼ばれる2つのプロキシ間で、HSSと呼ばれるユーザ・データベースのアドレスを運びます。 I-CSCFおよびS-CSCFは、同じ管理ドメインに属し、ユーザーのデータベースへの参照の共通フレームを共有します。 I-CSCFは、SIP要求にP-ユーザデータベースヘッダーフィールドを挿入し、S-CSCFは、さらに、要求をルーティングする前にそれを除去します。
When SIP is used on the Internet, there are typically no proxies querying a user database between the UA sending a REGISTER request and the registrar. Consequently, the P-User-Database header field does not seem useful in a general Internet environment.
SIPは、インターネット上で使用される場合、典型的には、REGISTERリクエストとレジストラを送信UAの間のユーザ・データベースを照会ないプロキシが存在しません。その結果、P-ユーザーデータベースのヘッダフィールドは、一般的なインターネット環境で有用でいないようです。
This document defines a new SIP header field: P-User-Database. 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-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 IP Security (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.
この文書で定義されたP-ユーザーデータベースは、要素が信頼されていると、攻撃者がこれらの要素間のプロトコルメッセージへのアクセス権を持っていることになっていないところの環境で使用されるべきです。ネットワーク要素間のトラフィック保護は時々物理的にネットワークを保護することにより、時にはIPセキュリティ（IPSec）とを使用することによって達成されます。いずれにしても、P-ユーザーデータベースのヘッダーフィールドが使用される環境では、整合性と、このヘッダフィールドの内容の機密性を確保します。
There is a slight security risk if a P-User-Database header field is allowed to propagate out of the administrative domain where it was generated. 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 need to ensure that the P-User-Database header field is removed from requests before these are sent to another administrative domain.
P-ユーザーとデータベースのヘッダフィールドは、それが生成された管理ドメインの外に伝播する許可されている場合、わずかなセキュリティ上のリスクがあります。ユーザーが機密情報には、このような違反によって明らかにされないであろうが、これは、この拡張子を除いたSIPメッセージ内の明示的な開示のレベルを超えた事業者ネットワークのトポロジに関する情報の開示につながる可能性があります。このため、事業者はこれらを別の管理ドメインに送信される前に、P-ユーザーデータベースのヘッダーフィールドはリクエストから削除されていることを確認する必要があります。
Nuria Esteban, Stephen Terrill, and Jeroen van Bemmel provided comments on this document. Dean Willis performed a thorough review of this document.
ヌリアエステバン、スティーブン・テリル、およびイェルーンバンBemmelは、この文書にコメントを提供しました。ディーン・ウィリスは、この文書の徹底的な見直しを行いました。
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[2] 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.
[2]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[3] 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.
[3]マンキン、A.、ブラドナー、S.、マーイ、R.、ウィリス、D.、オット、J.、およびB.ローゼン、 "セッション開始プロトコル（SIP）のための変更処理"、BCP 67、RFC 3427、2002年12月。
[4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[4]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。
[5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 5.14.0, October 2005.
[5] 3GPP、 "IPマルチメディアサブシステム（IMS）;ステージ2"、3GPP TS 23.228 5.14.0、2005年10月。
[6] 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.14.0, October 2005.
[6] 3GPP、 "セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）に基づく、インターネットプロトコル（IP）マルチメディア呼制御プロトコル;ステージ3"、3GPP TS 24.229 5.14.0 2005年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 28035 Spain
ドイツのホワイトエリクソン経由・デ・ロス・Poblados 13マドリード28035スペイン
EMail: german.blanco@ericsson.com
メールアドレス：german.blanco@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。