[要約] RFC 7316は、SIPメッセージにおけるP-Private-Network-Indicationプライベートヘッダ（Pヘッダ）の仕様を定義しています。このヘッダは、プライベートネットワーク内での通信を示すために使用されます。目的は、プライベートネットワーク内でのセッションの制御とセキュリティを向上させることです。
Internet Engineering Task Force (IETF) J. van Elburg
Request for Comments: 7316 Detecon International Gmbh
Category: Informational K. Drage
ISSN: 2070-1721 Alcatel-Lucent
M. Ohsugi
S. Schubert
K. Arai
NTT
July 2014
The Session Initiation Protocol (SIP) P-Private-Network-Indication Private Header (P-Header)
セッション開始プロトコル（SIP）P-Private-Network-Indicationプライベートヘッダー（P-Header）
Abstract
概要
This document specifies the SIP P-Private-Network-Indication P-header used by the 3GPP. The P-Private-Network-Indication indicates that the message is part of the message traffic of a private network and identifies that private network. A private network indication allows nodes to treat private network traffic according to a different set of rules than the set applicable to public network traffic.
このドキュメントでは、3GPPで使用されるSIP P-Private-Network-Indication Pヘッダーを指定します。 P-Private-Network-Indicationは、メッセージがプライベートネットワークのメッセージトラフィックの一部であることを示し、そのプライベートネットワークを識別します。プライベートネットワーク表示を使用すると、ノードはプライベートネットワークトラフィックを、パブリックネットワークトラフィックに適用できるルールとは異なるルールセットに従って処理できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7316.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7316で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Applicability ..............................................3
1.3. Background .................................................3
1.4. Business Communication .....................................3
1.5. Indication Types ...........................................4
2. Conventions .....................................................6
3. Definitions .....................................................6
3.1. Traffic ....................................................6
3.2. Public Network Traffic .....................................6
3.3. Private Network Traffic ....................................6
3.4. Break-In ...................................................6
3.5. Break-Out ..................................................6
3.6. Trust Domain ...............................................6
4. Application of Terminology ......................................7
5. Overview of Solution ...........................................10
6. Proxy Behavior .................................................11
6.1. P-Private-Network-Indication Generation ...................11
6.2. P-Private-Network-Indication Consumption ..................11
6.3. P-Private-Network-Indication Removal ......................11
6.4. P-Private-Network-Indication Verification .................11
7. P-Private-Network-Indication Header Field Definition ...........12
8. Security Considerations ........................................12
9. IANA Considerations ............................................13
10. Acknowledgments ...............................................13
11. References ....................................................13
11.1. Normative References .....................................13
11.2. Informative References ...................................14
ETSI TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) defined Next Generation Networks (NGNs), which use the 3GPP IP Multimedia Subsystem (IMS), which, in turn, uses SIP [RFC3261] as its main signaling 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 and ETSI TISPAN have identified a set of requirements that can be met by defining a new optional SIP header, according to the procedures in RFC 5727 [RFC5727].
ETSI TISPAN（通信とインターネット統合サービスと高度なネットワークのためのプロトコル）は、次世代のネットワーク（NGN）を定義しました。これは、3GPP IPマルチメディアサブシステム（IMS）を使用します。 IMSの詳細については、3GPP TS 23.228 [3GPP.23.228]および3GPP TS 24.229 [3GPP.24.229]に詳細な説明があります。 3GPPおよびETSI TISPANは、RFC 5727 [RFC5727]の手順に従って、新しいオプションのSIPヘッダーを定義することで満たすことができる一連の要件を識別しています。
The P-Private-Network-Indication header field is intended to be used in controlled closed networks like 3GPP IMS and ETSI TISPAN NGNs. The P-Private-Network-Indication header is not intended for the general Internet environment and is probably not suitable for such an environment.
P-Private-Network-Indicationヘッダーフィールドは、3GPP IMSやETSI TISPAN NGNなどの制御されたクローズドネットワークで使用することを目的としています。 P-Private-Network-Indicationヘッダーは、一般的なインターネット環境を対象としていないため、おそらくそのような環境には適していません。
For example, there are no mechanisms defined to prevent spoofing of this header. So, if a network were to accept calls carrying this header from the general Internet, an attacker would be able to inject information into private networks.
たとえば、このヘッダーのスプーフィングを防止するメカニズムは定義されていません。したがって、ネットワークがこのヘッダーを運ぶ呼び出しを一般的なインターネットから受け入れる場合、攻撃者はプライベートネットワークに情報を注入することができます。
The P-Private-Network-Indication header field has been referred to in 3GPP IMS specifications and has already been used in some networks as an indicator for a specific capability. The header field has already been implemented in some vendors' equipment in some countries. RFC 5727 [RFC5727] prohibits the new proposal of P-header "unless existing deployments or standards use the prefix already". The P-Private-Network-Indication header field is already used by existing deployments and 3GPP standards; therefore, this is exactly the case where the P-header is allowed as an exception.
P-Private-Network-Indicationヘッダーフィールドは3GPP IMS仕様で参照されており、特定の機能のインジケーターとして一部のネットワークですでに使用されています。ヘッダーフィールドは、一部の国の一部のベンダーの機器にすでに実装されています。 RFC 5727 [RFC5727]は、Pヘッダーの新しい提案を禁止します。 P-Private-Network-Indicationヘッダーフィールドは、既存の展開と3GPP標準ですでに使用されています。したがって、これは例外としてPヘッダーが許可されている場合とまったく同じです。
ETSI TISPAN has identified a framework, which was adopted by 3GPP as [3GPP.22.519], for the support of business communication capabilities by the NGN. In addition to the direct attachment of Next Generation Corporate Network (NGCN) equipment, this includes the capability to "host" functionality relating to an enterprise within the NGN itself.
ETSI TISPANは、NGPによるビジネス通信機能のサポートのために、3GPPによって[3GPP.22.519]として採用されたフレームワークを識別しました。これには、次世代企業ネットワーク（NGCN）機器の直接接続に加えて、NGN自体内の企業に関連する機能を「ホスト」する機能が含まれます。
These hosting arrangements are:
これらのホスティング契約は次のとおりです。
a) virtual leased line, where NGCN sites are interconnected through the NGN;
a) NGCNサイトがNGNを介して相互接続されている仮想専用回線。
b) business trunking application, where the NGN hosts transit capabilities between NGCN's; break-in capabilities, where the NGN converts public network traffic to private network traffic for delivery at a served NGCN; and break-out capabilities, where the NGN converts private network traffic from a served NGCN to public network traffic; and
b) NGNがNGCN間のトランジット機能をホストするビジネストランキングアプリケーション。侵入型機能。NGNは、サービスを提供するNGCNで配信するために、パブリックネットワークトラフィックをプライベートネットワークトラフィックに変換します。ブレークアウト機能。NGNは、プライベートネットワークトラフィックをサービス対象のNGCNからパブリックネットワークトラフィックに変換します。そして
c) hosted enterprise services, where an NGN hosts originating and/or terminating business communication capabilities for business communication users that are directly attached to an NGN.
c) ホストされたエンタープライズサービス。NGNは、NGNに直接接続されているビジネスコミュニケーションユーザーのために、ビジネスコミュニケーション機能の発信および/または終端をホストします。
ETSI TISPAN has requirements that can be met by the introduction of an explicit indication for private network traffic.
ETSI TISPANには、プライベートネットワークトラフィックの明示的な表示を導入することで満たすことができる要件があります。
The traffic generated or received by a public NGN on behalf of a private network can be either:
プライベートネットワークに代わってパブリックNGNによって生成または受信されるトラフィックは、次のいずれかです。
1) public network traffic: traffic sent to or received from an NGN for processing according to the rules for ordinary subscribers of a public telecommunication network. This type of traffic is known as public network traffic.
1）公衆ネットワークトラフィック：公衆通信ネットワークの通常の加入者のルールに従って処理するためにNGNとの間で送受信されるトラフィック。このタイプのトラフィックは、パブリックネットワークトラフィックと呼ばれます。
2) private network traffic: traffic sent to the NGN for processing according to an agreed set of rules specific to an enterprise. This type of traffic is known as private network traffic. Private network traffic is normally exchanged within a single enterprise, but private network traffic can also be exchanged between two or more different enterprises, based on some prior arrangements, if not precluded for regulatory reasons.
2）プライベートネットワークトラフィック：企業に固有の合意された一連のルールに従って処理するためにNGNに送信されるトラフィック。このタイプのトラフィックは、プライベートネットワークトラフィックと呼ばれます。通常、プライベートネットワークトラフィックは単一の企業内で交換されますが、規制上の理由で除外されない場合、事前の取り決めに基づいて、2つ以上の異なる企業間でプライベートネットワークトラフィックを交換することもできます。
A private network indication as proposed by this document indicates to the receiving network element (supporting this specification) that this request is related to private network traffic as opposed to public network traffic. This indication does not identify an end user on a private network and is not for delivery to an end user on the private network. It is an indication that special service arrangements apply (if such service is configured based on private network traffic) for an enterprise; therefore, it is an indication of service on behalf of an enterprise, not an indication of service to a private network's end user.
このドキュメントで提案されているプライベートネットワーク表示は、この要求がパブリックネットワークトラフィックではなくプライベートネットワークトラフィックに関連していることを（この仕様をサポートする）受信ネットワーク要素に示します。この表示は、プライベートネットワーク上のエンドユーザーを識別せず、プライベートネットワーク上のエンドユーザーへの配信用ではありません。これは、企業に対して特別なサービスの取り決めが適用されることを示しています（そのようなサービスがプライベートネットワークトラフィックに基づいて構成されている場合）。したがって、これは企業に代わるサービスの表示であり、プライベートネットワークのエンドユーザーへのサービスの表示ではありません。
In order to allow NGN IMS nodes to perform different processing, ETSI TISPAN formulated the following requirements for NGN. The NGN shall:
NGN IMSノードがさまざまな処理を実行できるようにするために、ETSI TISPANはNGNに関する次の要件を策定しました。 NGNは：
a) distinguish public network traffic from private network traffic; and
a) パブリックネットワークトラフィックとプライベートネットワークトラフィックを区別します。そして
b) distinguish private network traffic belonging to one enterprise from that belonging to another enterprise.
b) ある企業に属するプライベートネットワークトラフィックを別の企業に属するトラフィックと区別します。
To summarize, a few example reasons for a public NGN to make the distinction between the two types of traffic include:
要約すると、パブリックNGNが2つのタイプのトラフィックを区別するいくつかの理由の例は次のとおりです。
1) Different regulations apply to two types of traffic, for example, emergency calls may be handled differently depending on the type of traffic.
1）2つのタイプのトラフィックには異なる規制が適用されます。たとえば、緊急コールはトラフィックのタイプによって異なる方法で処理される場合があります。
2) Different charging regimes may apply.
2）異なる課金制度が適用される場合があります。
3) Call recording for business reasons (e.g., quality control, training, non-repudiation) might apply only to a specific type of traffic.
3）ビジネス上の理由（品質管理、トレーニング、否認防止など）による通話の録音は、特定の種類のトラフィックにのみ適用される場合があります。
4) Different levels of signaling and/or media transparency may apply to the different types of traffic.
4）異なるレベルのシグナリングおよび/またはメディア透過性が異なるタイプのトラフィックに適用される場合があります。
There are several reasons why there is a need for an explicit indication in the signaling:
シグナリングで明示的な表示が必要な理由はいくつかあります。
a) Caller and callee addresses cannot always be used to determine whether a certain call is to be treated as private or public network traffic.
a) 呼び出し元と呼び出し先のアドレスは、特定の呼び出しをプライベートネットワークトラフィックまたはパブリックネットワークトラフィックのどちらとして扱うかを決定するために常に使用できるわけではありません。
b) Nodes spanning multiple networks often need to have different behavior depending upon the type of traffic. When this is done using implicit schemes, enterprise-specific logic must be distributed across multiple nodes in multiple operators' networks. That is clearly not a manageable architecture and solution.
b) 複数のネットワークにまたがるノードは、多くの場合、トラフィックのタイプに応じて異なる動作をする必要があります。暗黙的なスキームを使用してこれを行う場合、企業固有のロジックを複数のオペレーターのネットワーク内の複数のノードに分散させる必要があります。それは明らかに管理しやすいアーキテクチャとソリューションではありません。
c) There may be cases where treating the call as a public network call although both participants are from the same enterprise is advantageous to the enterprise.
c) 両方の参加者が同じ企業の出身であるにもかかわらず、その呼び出しをパブリックネットワークコールとして扱うことが企業にとって有利である場合があります。
Based on the background provided, this document formulates requirements for SIP to support an explicit private network indication and defines a P-header, P-Private-Network-Indication, to support those requirements.
このドキュメントでは、提供された背景に基づいて、SIPが明示的なプライベートネットワーク表示をサポートするための要件を定式化し、それらの要件をサポートするためのPヘッダー、P-Private-Network-Indicationを定義します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈されます。
In the context of this document, the term "traffic" is understood as all communication pertaining to and/or controlled by a SIP transaction or dialog.
このドキュメントのコンテキストでは、「トラフィック」という用語は、SIPトランザクションまたはダイアログに関連する、および/またはSIPトランザクションまたはダイアログによって制御されるすべての通信として理解されます。
Traffic sent to or received from a public telecommunication network for processing according to the rules for ordinary subscribers of a public telecommunication network.
公衆通信ネットワークの通常の加入者の規則に従って処理するために、公衆通信ネットワークとの間で送受信されるトラフィック。
Traffic sent to or received from a public telecommunication network for processing according to an agreed set of rules specific to an enterprise or a community of closely related enterprises.
企業または密接に関連する企業のコミュニティに固有の合意された一連のルールに従って処理するために、公衆通信ネットワークとの間で送受信されるトラフィック。
Act of converting public network traffic to private network traffic. The header defined in this specification will be added to indicate the traffic is a private network traffic after conversion.
パブリックネットワークトラフィックをプライベートネットワークトラフィックに変換する行為。この仕様で定義されているヘッダーは、トラフィックが変換後のプライベートネットワークトラフィックであることを示すために追加されます。
Act of converting private network traffic to public network traffic. The header defined in this specification will be removed to indicate the traffic is a public network traffic after conversion.
プライベートネットワークトラフィックをパブリックネットワークトラフィックに変換する行為。この仕様で定義されたヘッダーは、トラフィックが変換後のパブリックネットワークトラフィックであることを示すために削除されます。
The term "trust domain" in this document is taken from P-Asserted-Identity [RFC3324]. A trust domain applies to the private network indication. The rules for specifying such a trust domain are specified in P-Asserted-Identity [RFC3324] and require the specification of a Spec(T) as covered in Section 2.4 of [RFC3324].
このドキュメントの「信頼ドメイン」という用語は、P-Asserted-Identity [RFC3324]から取られています。信頼ドメインは、プライベートネットワーク表示に適用されます。このような信頼ドメインを指定するためのルールは、P-Asserted-Identity [RFC3324]で指定されており、[RFC3324]のセクション2.4で説明されているSpec（T）の指定を必要とします。
The same information is required to specify a Spec(T) for purposes of P-Private-Network-Indication as for P-Asserted-Identity [RFC3324]. However, if a network is using P-Private-Network-Indication as well as other header fields subject to Spec(T) (such as P-Asserted-Identity), the Spec(T) for each header field will probably be different from the others.
P-Asserted-Identity [RFC3324]の場合と同じ情報が、P-Private-Network-Indicationの目的でSpec（T）を指定するために必要です。ただし、ネットワークがP-Private-Network-IndicationとSpec（T）の対象となる他のヘッダーフィールド（P-Asserted-Identityなど）を使用している場合、各ヘッダーフィールドのSpec（T）はおそらく他人。
Figure 1 shows the interconnection of sites belonging to two private networks using the public network. Traffic in the public network relating to the interconnection of the two sites of enterprise 1 are tagged as private network traffic relating to enterprise 1. In certain cases, an enterprise can also choose to send traffic from one enterprise site to another enterprise site as public network traffic when this is beneficial to the enterprise. Traffic in the public network relating to the interconnection of the two sites of enterprise 2 are tagged as private network traffic relating to enterprise 2. Enterprise 1 also generates traffic to public phones, and this is public network traffic (untagged in the public network). There may be circumstances where traffic in the public network between two different private networks is tagged as private network traffic using a pre-arranged domain name agreed by the two involved enterprises. This is illustrated by the interconnection of the site from enterprise 3 and the site from enterprise 4.
図1は、パブリックネットワークを使用した2つのプライベートネットワークに属するサイトの相互接続を示しています。企業1の2つのサイトの相互接続に関連するパブリックネットワークのトラフィックは、企業1に関連するプライベートネットワークトラフィックとしてタグ付けされます。特定のケースでは、企業はトラフィックを1つのエンタープライズサイトから別のエンタープライズサイトにパブリックネットワークとして送信することもできます。これが企業にとって有益な場合のトラフィック。エンタープライズ2の2つのサイトの相互接続に関連するパブリックネットワークのトラフィックは、エンタープライズ2に関連するプライベートネットワークトラフィックとしてタグ付けされます。エンタープライズ1も公衆電話へのトラフィックを生成します。これはパブリックネットワークトラフィックです（パブリックネットワークではタグなし）。 2つの異なるプライベートネットワーク間のパブリックネットワークのトラフィックが、関係する2つの企業によって合意された事前に設定されたドメイン名を使用してプライベートネットワークトラフィックとしてタグ付けされる場合があります。これは、企業3のサイトと企業4のサイトの相互接続によって示されています。
+------------------------------+
| private network |
+------------+ |<===========traffic==========>| +------------+
| enterprise | | (enterprise 1) | | enterprise |
| 1 +-----+------------------------------+-----+ 1 !
| site 1 | | | | site 2 |
+------------+ | +---+-----| |
| public | | | |
/--\ |<=========network========>| | +------------+
o /\ o | traffic | |
/ \----------+--------------------------+ |
+----+ | |
public | |
phone | |
| private network |
+------------+ |<===========traffic==========>| +------------+
| enterprise | | (enterprise 2) | | enterprise |
| 2 +-----+------------------------------+-----+ 2 !
| site 1 | | | | site 2 |
+------------+ | | +------------+
| |
| private network |
+------------+ |<===========traffic==========>| +------------+
| enterprise | | (pre-arranged domain name) | | enterprise |
| 3 +-----+------------------------------+-----+ 4 !
| site 1 | | | | site 1 |
+------------+ | | +------------+
| |
+------------------------------+
Figure 1: Two Private Networks
図1：2つのプライベートネットワーク
Figure 2 shows the interconnection of sites belonging to a private network using the public network and supported in the public network by a server providing a business trunking application. The business trunking application provides routing capabilities for the enterprise traffic and supports the identification of calls to and from public network users and routing of break-in and break-out of that traffic. (Note that the business trunking application may consist of a concatenation of application logic provided to the originating enterprise site and application logic that is provided to the terminating enterprise site.) Traffic in the public network relating to the interconnection of the two sites of enterprise 1 is tagged as private network traffic relating to enterprise 1. The business trunking application also routes traffic to public phones, and this is public network traffic (untagged in the public network).
図2は、パブリックネットワークを使用してプライベートネットワークに属し、ビジネストランキングアプリケーションを提供するサーバーによってパブリックネットワークでサポートされているサイトの相互接続を示しています。ビジネストランキングアプリケーションは、エンタープライズトラフィックにルーティング機能を提供し、パブリックネットワークユーザーとの間のコールの識別と、そのトラフィックの侵入およびブレークアウトのルーティングをサポートします。 （ビジネストランキングアプリケーションは、発信元のエンタープライズサイトに提供されるアプリケーションロジックと、終了するエンタープライズサイトに提供されるアプリケーションロジックの連結で構成される場合があります。）エンタープライズの2つのサイトの相互接続に関連するパブリックネットワークのトラフィック1は、企業1に関連するプライベートネットワークトラフィックとしてタグ付けされています。ビジネストランキングアプリケーションは、トラフィックを公衆電話にもルーティングします。これはパブリックネットワークトラフィックです（パブリックネットワークではタグなし）。
+-------------------------------------------------+
| private network |
+------------+ |<===========traffic============>+------------+ |
| enterprise | | (enterprise 1) | | |
| 1 +-----+--------------------------------+ | |
| site 1 | | | business | |
+------------+ | +-----+ trunking | |
| public | | application| |
/--\ |<=========network========>| +--+ | |
o /\ o | traffic | | | | |
/ \----------+--------------------------+ | | | |
+----+ | | +------------+ |
public | | |
phone | | |
| private network | |
+------------+ |<===========traffic=========>| |
| enterprise | | (enterprise 1) | |
| 1 +-----+-----------------------------+ |
| site 2 | | |
+------------+ | |
| |
+-------------------------------------------------+
Figure 2: Private Network and Business Trunking
図2：プライベートネットワークとビジネストランキング
Figure 3 shows the interconnection of sites belonging to a private network on a server providing a hosted enterprise service application (also known as Centrex). The hosted enterprise service application supports phones belonging to the enterprise and is also able to route traffic to and from public network phones using break-in or break-out functionality. Traffic in the public network relating to the interconnection of the site of enterprise 1 and the hosted enterprise service belonging to enterprise 1 is tagged as private network traffic relating to enterprise 1. The hosted enterprise service application also routes traffic to public phones, and this is public network traffic (untagged in the public network). Traffic from the enterprise phones would not normally be tagged, but it can be tagged as private network traffic. (Note that the hosted enterprise service logic may precede or succeed a business trunking application that offers services on behalf of an enterprise site.)
図3は、ホステッドエンタープライズサービスアプリケーション（Centrexとも呼ばれる）を提供するサーバー上のプライベートネットワークに属するサイトの相互接続を示しています。ホステッドエンタープライズサービスアプリケーションは、企業に属する電話をサポートし、ブレークインまたはブレークアウト機能を使用して、パブリックネットワーク電話との間でトラフィックをルーティングすることもできます。エンタープライズ1のサイトとエンタープライズ1に属するホステッドエンタープライズサービスの相互接続に関連するパブリックネットワークのトラフィックは、エンタープライズ1に関連するプライベートネットワークトラフィックとしてタグ付けされます。ホステッドエンタープライズサービスアプリケーションは、トラフィックを公衆電話にルーティングします。パブリックネットワークトラフィック（パブリックネットワークではタグなし）。企業電話からのトラフィックは通常タグ付けされませんが、プライベートネットワークトラフィックとしてタグ付けできます。 （ホスティングされたエンタープライズサービスロジックは、エンタープライズサイトに代わってサービスを提供するビジネストランキングアプリケーションの前または後になる場合があります。）
+-------------------------------------------------+
| private network |
+------------+ |<===========traffic============>+------------+ |
| enterprise | | (enterprise 1) | | |
| 1 +-----+--------------------------------+ hosted | |
| site 1 | | | enterprise | |
+------------+ | +-----+ service | |
| public | | enterprise | |
/--\ |<=========network========>| +--+ 1 | |
o /\ o | traffic | | | | |
/ \----------+--------------------------+ | | | |
+----+ | | +------------+ |
public | | |
phone | | |
| private network | |
/--\ |<===========traffic=========>| |
o /\ o | (enterprise 1) | |
/ \----------+-----------------------------+ |
+----+ | |
enterprise | |
phone | |
+-------------------------------------------------+
Figure 3: Hosted Service and Private Network
図3：ホストされたサービスとプライベートネットワーク
The mechanism proposed in this document relies on a new header field called 'P-Private-Network-Indication' that contains a private network identifier expressed as a domain name, for example:
このドキュメントで提案されているメカニズムは、ドメイン名として表現されたプライベートネットワーク識別子を含む「P-Private-Network-Indication」と呼ばれる新しいヘッダーフィールドに依存しています。次に例を示します。
P-Private-Network-Indication: example.com
P-Private-Network-Indication：example.com
A proxy server that handles a message MAY insert such a P-Private-Network-Indication header field into the message based on authentication of the source of a message, configuration, or local policy. A proxy server MAY forward the message to other proxies in the same administrative domain or proxies in a trusted domain to be handled as private network traffic. A proxy that forwards a message to a proxy server or user agent (UA) that it does not trust MUST remove the P-Private-Network-Indication header field before forwarding the message.
メッセージを処理するプロキシサーバーは、メッセージのソース、構成、またはローカルポリシーの認証に基づいて、そのようなP-Private-Network-Indicationヘッダーフィールドをメッセージに挿入してもよい（MAY）。プロキシサーバーは、メッセージを同じ管理ドメイン内の他のプロキシまたは信頼できるドメイン内のプロキシに転送して、プライベートネットワークトラフィックとして処理する場合があります。信頼できないプロキシサーバーまたはユーザーエージェント（UA）にメッセージを転送するプロキシは、メッセージを転送する前にP-Private-Network-Indicationヘッダーフィールドを削除する必要があります。
The private network identifier expressed as a domain name allows it to be a globally unique identifier, associated with the originating and/or terminating enterprise(s). Domain name is used, as it allows reuse of a company-owned Internet domain name without requiring an additional private network identifier registry. When the enterprise needs more than one identifier, it can freely add subdomains under its own control.
ドメイン名として表現されたプライベートネットワーク識別子は、発信元および/または終了企業に関連付けられたグローバルに一意の識別子になることを可能にします。追加のプライベートネットワーク識別子レジストリを必要とせずに、会社所有のインターネットドメイン名を再利用できるため、ドメイン名が使用されます。企業が複数の識別子を必要とする場合、独自の制御下でサブドメインを自由に追加できます。
The formal syntax for the P-Private-Network-Indication header is presented in Section 7.
P-Private-Network-Indicationヘッダーの正式な構文は、セクション7に示されています。
Proxies that are responsible for determining certain traffic to be treated as private network traffic or contain a break-in function that converts incoming public network traffic to private network traffic MUST insert a P-Private-Network-Indication header field into incoming or outgoing requests for a dialog or for a standalone transaction. The value MUST be set to the private network identifier corresponding to the enterprise(s) to which the traffic belongs.
特定のトラフィックをプライベートネットワークトラフィックとして扱うか、着信パブリックネットワークトラフィックをプライベートネットワークトラフィックに変換する侵入機能を含むかを決定するプロキシは、P-Private-Network-Indicationヘッダーフィールドを着信または発信リクエストに挿入する必要があります。ダイアログまたはスタンドアロントランザクション用。値は、トラフィックが属する企業に対応するプライベートネットワーク識別子に設定する必要があります。
Proxies that are responsible for applying different processing behaviors to specific private network traffic MUST support this extension. The P-Private-Network-Indication header field MUST NOT be used by a proxy in case it is received in a request from an entity that it does not trust; in such a case, it MUST be removed before the request is forwarded.
特定のプライベートネットワークトラフィックにさまざまな処理動作を適用する責任があるプロキシは、この拡張機能をサポートする必要があります。 P-Private-Network-Indicationヘッダーフィールドは、信頼できないエンティティからのリクエストで受信された場合に備えて、プロキシで使用してはなりません（MUST NOT）。このような場合、リクエストが転送される前に削除する必要があります。
Proxies that are at the edge of the trust domain or contain a break-out function that converts incoming private network traffic to public network traffic MUST remove the P-Private-Network-Indication header field before forwarding a request that contains such a header field.
信頼ドメインのエッジにあるプロキシ、または着信プライベートネットワークトラフィックをパブリックネットワークトラフィックに変換するブレークアウト機能を含むプロキシは、そのようなヘッダーフィールドを含むリクエストを転送する前に、P-Private-Network-Indicationヘッダーフィールドを削除する必要があります。
When proxies supporting this specification receive a P-Private-Network-Indication header field in a SIP request from a trusted node, proxies MUST check whether the received domain name in the request is the same as the domain name associated with the provisioned domain name. If the received domain name does not match, proxies MUST remove the P-Private-Network-Indication header field.
この仕様をサポートするプロキシが信頼できるノードからのSIPリクエストでP-Private-Network-Indicationヘッダーフィールドを受信する場合、プロキシはリクエストで受信したドメイン名がプロビジョニングされたドメイン名に関連付けられたドメイン名と同じかどうかを確認する必要があります。受信したドメイン名が一致しない場合、プロキシはP-Private-Network-Indicationヘッダーフィールドを削除する必要があります。
This document defines the SIP P-Private-Network-Indication header field. This header field can be added by a proxy to initial requests for a dialog or standalone requests. The presence of the P-Private-Network-Indication header field signifies to proxies that understand the header field that the request is to be treated as private network traffic. The P-Private-Network-Indication header field contains a domain name value that allows the private network traffic to be associated with an enterprise to which it belongs and allows proxies that understand this header field to process the request according to the local policy configured for a specific enterprise(s).
このドキュメントでは、SIP P-Private-Network-Indicationヘッダーフィールドを定義します。このヘッダーフィールドは、ダイアログの初期リクエストまたはスタンドアロンリクエストにプロキシによって追加できます。 P-Private-Network-Indicationヘッダーフィールドの存在は、リクエストがプライベートネットワークトラフィックとして扱われることをヘッダーフィールドを理解しているプロキシを意味します。 P-Private-Network-Indicationヘッダーフィールドには、プライベートネットワークトラフィックを所属する企業に関連付けることができ、このヘッダーフィールドを理解するプロキシが、構成されたローカルポリシーに従って要求を処理できるようにするドメイン名の値が含まれています特定の企業。
The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P-Private-Network-Indication header field is described below:
P-Private-Network-IndicationヘッダーフィールドのAugmented Backus-Naur Form（ABNF）[RFC5234]の構文は次のとおりです。
P-Private-Network-Indication = "P-Private-Network-Indication" HCOLON PNI-value *(SEMI PNI-param) PNI-param = generic-param PNI-value = hostname
P-Private-Network-Indication = "P-Private-Network-Indication" HCOLON PNI-value *（SEMI PNI-param）PNI-param = generic-param PNI-value = hostname
EQUAL, HCOLON, SEMI, hostname, and generic-param are defined in RFC 3261 [RFC3261].
EQUAL、HCOLON、SEMI、ホスト名、およびgeneric-paramは、RFC 3261 [RFC3261]で定義されています。
The following is an example of a P-Private-Network-Indication header field:
以下は、P-Private-Network-Indicationヘッダーフィールドの例です。
P-Private-Network-Indication: example.com
P-Private-Network-Indication：example.com
The private network indication defined in this document MUST only be used in the traffic transported between network elements that are mutually trusted. Traffic protection between network elements can be achieved by using security protocols such as IP Encapsulating Security Payload (ESP) [RFC4303] or SIP / Transport Layer Security (SIP/TLS) or sometimes by physical protection of the network. In any case, the environment where the private network indication will be used needs to ensure the integrity and the confidentiality of the contents of this header field.
このドキュメントで定義されているプライベートネットワークインジケータは、相互に信頼されているネットワーク要素間で転送されるトラフィックでのみ使用する必要があります。ネットワーク要素間のトラフィック保護は、IPカプセル化セキュリティペイロード（ESP）[RFC4303]やSIP /トランスポート層セキュリティ（SIP / TLS）などのセキュリティプロトコルを使用するか、ネットワークの物理的な保護によって実現できます。いずれの場合でも、プライベートネットワーク表示が使用される環境では、このヘッダーフィールドの内容の完全性と機密性を確保する必要があります。
A private network indication received from an untrusted node MUST NOT be used, and the information MUST be removed from a request or response before it is forwarded to entities in the trust domain. Additionally, local policies may be in place that ensure that all requests entering the trust domain for private network indication from untrusted nodes with a private network indication will be discarded.
信頼されていないノードから受信したプライベートネットワークの表示は使用してはならず（MUST NOT）、信頼できるドメイン内のエンティティに転送される前に、情報を要求または応答から削除する必要があります。さらに、ローカルポリシーが設定されている可能性があり、プライベートネットワークを示す信頼できないノードからプライベートネットワークを示すために信頼ドメインに入るすべての要求が確実に破棄されます。
There is a security risk if a private network indication is allowed to propagate out of the trust domain where it was generated. The indication may reveal information about the identity of the caller, i.e., the organization that he belongs to. That is sensitive information. It also reveals to the outside world that there is a set of rules that this call is subject to that is different then the rules that apply to public traffic. That is sensitive information too. To prevent such a breach from happening, proxies MUST NOT insert the information when forwarding requests to a next hop located outside the trust domain. When forwarding the request to a trusted node, proxies MUST NOT insert the header field unless they have sufficient knowledge that the route set includes another proxy in the trust domain that understands this header field. However, how to learn such knowledge is out of the scope of this document. Proxies MUST remove the information when forwarding requests to untrusted nodes or when the proxy does not have knowledge of any other proxy in the route set that is able to understand this header field.
プライベートネットワーク表示が生成された信頼ドメインの外に伝播することが許可されている場合、セキュリティ上のリスクがあります。この表示により、発信者の身元、つまり発信者が所属する組織に関する情報が明らかになる場合があります。それは機密情報です。また、この呼び出しの対象となる一連のルールがあり、それが公共交通に適用されるルールとは異なることを外部に明らかにします。それも機密情報です。このような違反が発生するのを防ぐために、信頼ドメインの外部にある次のホップに要求を転送するときに、プロキシは情報を挿入してはなりません（MUST NOT）。信頼されたノードに要求を転送するとき、ルートセットにこのヘッダーフィールドを理解する信頼ドメイン内の別のプロキシが含まれていることを十分に理解していない限り、プロキシはヘッダーフィールドを挿入してはなりません。ただし、そのような知識を習得する方法は、このドキュメントの範囲外です。プロキシは、信頼できないノードにリクエストを転送するとき、またはプロキシがこのヘッダーフィールドを理解できるルートセット内の他のプロキシを認識していないときに、情報を削除する必要があります。
This document defines a new SIP header field: P-Private-Network-Indication. This header field has been registered by the IANA in the "SIP Parameters" registry under the "Header Fields" subregistry.
このドキュメントは新しいSIPヘッダーフィールドを定義します：P-Private-Network-Indication。このヘッダーフィールドは、IANAによって「Header Fields」サブレジストリの下の「SIP Parameters」レジストリに登録されています。
RFC Number: [RFC7316]
RFC番号：[RFC7316]
Header Field Name: P-Private-Network-Indication
ヘッダーフィールド名：P-Private-Network-Indication
Compact Form: none
コンパクトフォーム：なし
The authors would like to thank Richard Barnes, Mary Barnes, Atle Monrad, Bruno Chatras, John Elwell, and Salvatore Loreto for providing comments on an early version of this document. Further, we thank John Elwell for performing the expert review.
このドキュメントの初期バージョンにコメントを提供してくれたRichard Barnes、Mary Barnes、Atle Monrad、Bruno Chatras、John Elwell、およびSalvatore Loretoに感謝します。さらに、専門家によるレビューを行ってくれたJohn Elwellに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002.
[RFC3324] Watson、M.、「ネットワークアサートされたIDの短期要件」、RFC 3324、2002年11月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、Ed。、およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[3GPP.22.519] 3GPP, "Business Communication Requirements", TS 22.519.
[3GPP.22.519] 3GPP、「ビジネス通信要件」、TS 22.519。
[3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 V8, July 2007.
[3GPP.23.228] 3GPP、「IP Multimedia Subsystem（IMS）; Stage 2」、3GPP TS 23.228 V8、2007年7月。
[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 V8, July 2007.
[3GPP.24.229] 3GPP、「インターネットプロトコル（IP）マルチメディアコール制御プロトコル、セッション開始プロトコル（SIP）およびセッション記述プロトコル（SDP）、ステージ3に基づく」、3GPP TS 24.229 V8、2007年7月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727] Peterson、J.、Jennings、C。、およびR. Sparks、「Session Initiation Protocol（SIP）およびReal-time Applications and Infrastructure Areaの変更プロセス」、BCP 67、RFC 5727、2010年3月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
Authors' Addresses
著者のアドレス
Hans Erik van Elburg Detecon International Gmbh Oberkasselerstrasse 2 Bonn 53227 Germany
Hans Erik van Elburg Detecon International GmbH Oberkasselerstrasse 2ボン53227ドイツ
EMail: ietf.hanserik@gmail.com
Keith Drage Alcatel-Lucent The Quadrant, Stonehill Green, Westlea Swindon SN5 7DJ UK
キースドラゲアルカテルルーセントザクアドラント、ストーンヒルグリーン、ウェストリースウィンドンSN5 7DJ英国
EMail: drage@alcatel-lucent.com
Mayumi Ohsugi NTT Corporation
まゆみ おｈすぎ んっｔ こｒぽらちおん
Phone: +81 422 36 7502
EMail: mayumi.ohsugi@ntt-at.co.jp
Shida Schubert NTT Corporation
バートNTT株式会社
Phone: +1 415 323 9942
EMail: shida@ntt-at.com
Kenjiro Arai NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan
けんじろ あらい んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Phone: +81 422 59 3518
EMail: arai.kenjiro@lab.ntt.co.jp
URI: http://www.ntt.co.jp