[要約] RFC 3327は、SIP拡張ヘッダーフィールドを使用して非隣接の連絡先を登録するための仕様です。目的は、SIPユーザーエージェントが非隣接の連絡先を登録できるようにすることです。
Network Working Group D. Willis
Request for Comments: 3327 dynamicsoft Inc.
Category: Standards Track B. Hoeneisen
Switch
December 2002
Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts
非隣接する連絡先を登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
The REGISTER function is used in a Session Initiation Protocol (SIP) system primarily to associate a temporary contact address with an address-of-record. This contact is generally in the form of a Uniform Resource Identifier (URI), such as Contact: <sip:alice@pc33.atlanta.com> and is generally dynamic and associated with the IP address or hostname of the SIP User Agent (UA). The problem is that network topology may have one or more SIP proxies between the UA and the registrar, such that any request traveling from the user's home network to the registered UA must traverse these proxies. The REGISTER method does not give us a mechanism to discover and record this sequence of proxies in the registrar for future use. This document defines an extension header field, "Path" which provides such a mechanism.
レジスタ関数は、セッション開始プロトコル（SIP）システムで使用され、主に一時的な連絡先住所を記録アドレスに関連付けます。この連絡先は一般に、連絡先などの均一なリソース識別子（URI）の形式であり、<sip：alice@pc33.atlanta.com>など、通常は動的であり、SIPユーザーエージェントのIPアドレスまたはホスト名に関連付けられています（UA）。問題は、ネットワークトポロジがUAとレジストラの間に1つ以上のSIPプロキシを持っている可能性があるため、ユーザーのホームネットワークから登録されたUAへの移動要求がこれらのプロキシを通過する必要があることです。登録法は、将来の使用のためにレジストラでこの一連のプロキシを発見して記録するメカニズムを提供しません。このドキュメントは、そのようなメカニズムを提供する拡張ヘッダーフィールド「パス」を定義します。
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statement . . . . . . . . . . . . . . . . . . 3
4. Path Header Field Definition and Syntax . . . . . . . . . . 3
5. Usage of Path Header Field . . . . . . . . . . . . . . . . . 5
5.1 Procedures at the UA . . . . . . . . . . . . . . . . . . . . 5
5.2 Procedures at Intermediate Proxies . . . . . . . . . . . . . 5
5.3 Procedures at the Registrar . . . . . . . . . . . . . . . . 6
5.4 Procedures at the Home Proxy . . . . . . . . . . . . . . . . 6
5.5 Examples of Usage . . . . . . . . . . . . . . . . . . . . . 7
5.5.1 Example of Mechanism in REGISTER Transaction . . . . . . . . 7
5.5.2 Example of Mechanism in INVITE Transaction . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . 13
6.1 Considerations in REGISTER Request Processing . . . . . . . 13
6.2 Considerations in REGISTER Response Processing . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
Normative References . . . . . . . . . . . . . . . . . . . . 16
Non-Normative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . 17
3GPP established a requirement for discovering intermediate proxies during SIP registration and published this requirement in [5].
3GPPは、SIP登録中に中間プロキシを発見するための要件を確立し、[5]でこの要件を公開しました。
Scenario:
シナリオ：
UA1----P1-----P2-----P3------REGISTRAR
UA1 wishes to register with REGISTRAR. However, due to network topology, UA1 must use P1 as an "outbound proxy", and all requests between UA1 and REGISTRAR must also traverse P1, P2, and P3 before reaching REGISTRAR. Likewise, all requests between REGISTRAR and UA1 must also traverse P3, P2, and P1 before reaching UA1.
UA1は、レジストラに登録したいと考えています。ただし、ネットワークトポロジのため、UA1はP1を「アウトバウンドプロキシ」として使用する必要があり、UA1とレジストラ間のすべての要求もレジストラに到達する前にP1、P2、およびP3を通過する必要があります。同様に、レジストラとUA1の間のすべての要求も、UA1に到達する前にP3、P2、およびP1を横断する必要があります。
UA1 has a standing relationship with REGISTRAR. How UA1 establishes this relationship is outside the scope of this document. UA1 discovers P1 as a result of configuration, DHCP assignment or other similar operation, also outside the scope of this document. REGISTRAR has a similar "default outbound proxy" relationship with P3.
UA1には、レジストラとの常設関係があります。UA1がこの関係を確立する方法は、このドキュメントの範囲外です。UA1は、このドキュメントの範囲外でも、構成、DHCP割り当て、またはその他の同様の操作の結果としてP1を発見します。レジストラには、P3と同様の「デフォルトのアウトバウンドプロキシ」関係があります。
Eventually, REGISTRAR or a "home proxy" (a proxy serving as the terminal point for routing an address-of-record) closely related to it will receive a request destined for UA1. It needs to know which proxies must be transited by that request in order to get back to UA1. In some cases, this information may be deducible from SIP routing configuration tables or from DNS entries. In other cases, such as that raised by 3GPP, the information is not readily available outside of the SIP REGISTER transaction.
最終的に、レジストラまたは「ホームプロキシ」（レコードアドレスをルーティングするための端末ポイントとして機能するプロキシ）に密接に関連している場合は、UA1向けのリクエストを受け取ります。UA1に戻るために、そのリクエストによってどのプロキシを輸送する必要があるかを知る必要があります。場合によっては、この情報は、SIPルーティング構成テーブルまたはDNSエントリから推定できる場合があります。他の場合、3GPPによって提起されたものなど、情報はSIPレジスタトランザクション以外で容易に入手できません。
The Path extension header field allows accumulating and transmitting the list of proxies between UA1 and REGISTRAR. Intermediate nodes such as P1 may statefully retain Path information if needed by operational policy. This mechanism is in many ways similar to the operation of Record-Route in dialog-initiating requests. The routing established by the Path header field mechanism applies only to requests transiting or originating in the home domain.
パス拡張ヘッダーフィールドにより、UA1とレジストラ間のプロキシのリストを蓄積して送信できます。P1などの中間ノードは、運用ポリシーで必要に応じてパス情報を状態に保持する場合があります。このメカニズムは、ダイアログ開始要求でのレコードルートの操作と多くの点で似ています。パスヘッダーフィールドメカニズムによって確立されたルーティングは、ホームドメインで通過または発信するリクエストにのみ適用されます。
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 [3].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [3]に記載されているように解釈される。
The Path mechanism is applicable whenever there are intermediate proxies between a SIP UA and a SIP Registrar used by that UA where the following conditions are true:
パスメカニズムは、SIP UAとそのUAが使用するSIPレジストラとの間に中間プロキシがある場合はいつでも適用されます。
1. One or more of the intermediate proxies are visited by registration requests from the UA to the Registrar. 2. The same intermediate proxies or a set of proxies known to the intermediate proxies must be traversed, in reverse order, by requests sent through a home proxy to the UA. In the simplest form, the route between the home proxy and the UA is the exact inverse of the route between the UA and the route between the UA and the registrar. 3. The network topology is such that the intermediate proxies which must be visited are NOT implied by SIP routing tables, DNS, or similar mechanisms.
1. 1つ以上の中間プロキシは、UAからレジストラへの登録要求によって訪問されます。2.中間プロキシに知られている同じ中間プロキシまたは一連のプロキシを、UAにホームプロキシを介して送信される要求によって、逆順序で通過する必要があります。最も単純な形式では、ホームプロキシとUAの間のルートは、UAとUAとレジストラの間のルートの間のルートの正確な逆です。3.ネットワークトポロジは、訪問する必要がある中間プロキシが、SIPルーティングテーブル、DNS、または同様のメカニズムによって暗示されないようなものです。
The Path header field is a SIP extension header field with syntax very similar to the Record-Route header field. It is used in conjunction with SIP REGISTER requests and with 200 class messages in response to REGISTER (REGISTER responses).
パスヘッダーフィールドは、レコードルートヘッダーフィールドに非常によく似た構文を備えたSIP拡張ヘッダーフィールドです。SIPレジスタリクエストと、レジスタ（レジスタ応答）に応じて200のクラスメッセージと組み合わせて使用されます。
A Path header field MAY be inserted into a REGISTER by any SIP node traversed by that request. Like the Route header field, sequential Path header fields are evaluated in the sequence in which they are present in the request, and Path header fields MAY be combined into compound Path header in a single Path header field. The registrar reflects the accumulated Path back into the REGISTER response, and intermediate nodes propagate this back toward the originating UA. The originating UA is therefore informed of the inclusion of nodes on its registered Path, and MAY use that information in other capacities outside the scope of this document.
パスヘッダーフィールドは、そのリクエストによって追跡されるSIPノードによってレジスタに挿入される場合があります。ルートヘッダーフィールドと同様に、シーケンシャルパスヘッダーフィールドは、リクエストに存在するシーケンスで評価され、パスヘッダーフィールドを単一のパスヘッダーフィールドの複合パスヘッダーに結合できます。レジストラは、レジスタ応答に戻る蓄積されたパスを反映し、中間ノードはこのバックを発生するUAに向けて伝播します。したがって、登録されているUAは、登録されたパスにノードを含めることを通知され、このドキュメントの範囲外の他の容量でその情報を使用する場合があります。
The difference between Path and Record-Route is that Path applies to REGISTER and 200 class responses to REGISTER. Record-Route doesn't, and can't be defined in REGISTER for reasons of backward compatibility. Furthermore, the vector established by Record-Route applies only to requests within the dialog that established that Record-Route, whereas the vector established by Path applies to future dialogs.
パスとレコードルートの違いは、パスが登録に適用され、200のクラスの応答が登録することです。Record-routeは、後方互換性の理由で登録で定義することはできません。さらに、レコードルートによって確立されたベクトルは、そのレコードルートを確立したダイアログ内のリクエストにのみ適用されますが、パスで確立されたベクトルは将来のダイアログに適用されます。
The syntax for Path is defined as follows:
パスの構文は次のように定義されます。
Path = "Path" HCOLON path-value *( COMMA path-value )
path = "path" hcolon path-value *（comma path-value）
path-value = name-addr *( SEMI rr-param )
path-value = name-addr *（semi rr-param）
Note that the Path header field values conform to the syntax of a Route element as defined in [1]. As suggested therein, such values MUST include the loose-routing indicator parameter ";lr" for full compliance with [1].
パスヘッダーフィールド値は、[1]で定義されているルート要素の構文に適合することに注意してください。そこに示唆されているように、そのような値は、[1]を完全に遵守するために、ルーズルーティングインジケーターパラメーター "; lr"を含める必要があります。
The allowable usage of header fields is described in Tables 2 and 3 of SIP [1]. The following additions to this table are needed for Path.
ヘッダーフィールドの許容使用量は、SIPの表2および3で説明されています[1]。このテーブルへの以下の追加は、パスに必要です。
Support for the Path header field MAY be indicated by a UA by including the option-tag "path" in a Supported header field.
パスヘッダーフィールドのサポートは、サポートされているヘッダーフィールドにオプションタグ「パス」を含めることにより、UAによって示される場合があります。
Addition of Path to SIP Table 3:
SIPへのパスの追加表3：
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Path R ar - - - - - o
Path 2xx - - - - - - o
The UA executes its register operation as usual. The response MAY contain a Path header field. The general operation of the UA is to ignore the Path header field in the response. It MAY choose to display the contents of the Path header field to the user or take other action outside the scope of this document. The Path information in the REGISTER response lets the UA know what intermediate proxies were added during registration. Examination of this information may be important from a security perspective, as such inspection might allow the UA to detect intermediate proxies that have inappropriately added themselves.
UAは、通常どおり登録操作を実行します。応答には、パスヘッダーフィールドが含まれる場合があります。UAの一般的な動作は、応答のパスヘッダーフィールドを無視することです。パスヘッダーフィールドのコンテンツをユーザーに表示するか、このドキュメントの範囲外で他のアクションを実行することを選択できます。レジスタ応答のパス情報により、登録中にどの中間プロキシが追加されたかをUAに知ることができます。この情報の調査は、セキュリティの観点から重要かもしれません。そのような検査により、UAは不適切にそれ自体を追加した中間プロキシを検出できるようになる可能性があるためです。
The UA SHOULD include the option tag "path" as a header field value in all Supported header fields, and SHOULD include a Supported header field in all requests.
UAには、サポートされているすべてのヘッダーフィールドのヘッダーフィールド値としてオプションタグ「パス」を含める必要があり、すべてのリクエストにサポートされているヘッダーフィールドを含める必要があります。
The UA MAY include a Path header field in a request. This is not broadly applicable and caution must be taken to insure proper function, as the Path header field inserted by the UA may have additional Path header field values appended by intermediate proxies. Such proxies are not aware that the Path header field value was inserted by a UA, and will treat it as if it had been inserted by a previously traversed proxy, which could result in unexpected routing behavior wherein the UA is asked to act as a proxy.
UAには、リクエストにパスヘッダーフィールドが含まれる場合があります。これは広く適用できません。適切な機能を保証するために注意する必要があります。これは、UAによって挿入されたパスヘッダーフィールドに、中間プロキシによって追加される追加のパスヘッダーフィールド値がある可能性があるためです。このようなプロキシは、パスヘッダーフィールド値がUAによって挿入されたことを認識しておらず、以前にトラバースされたプロキシによって挿入されたかのように扱います。。
When a proxy processing a REGISTER request wishes to be on the path for future requests toward the UA originating that REGISTER request, the proxy inserts a URI for that proxy as the topmost value in the Path header field (or inserts a new topmost Path header) before proxying that request. It is also possible for a proxy with specific knowledge of network topology to add a Path header field value referencing another node, thereby allowing construction of a Path which is discongruent with the route taken by the REGISTER request. Such a construction is implementation specific and outside the scope of this document.
プロキシ処理がレジスタのリクエストがそのレジスタリクエストを発信するUAに向けて将来のリクエストのパスにあることを望んでいる場合、プロキシはそのプロキシのURIをパスヘッダーフィールドの最上位値として挿入します（または新しい最上部パスヘッダーを挿入します）そのリクエストをプロキシする前。また、ネットワークトポロジの特定の知識を持つプロキシがパスヘッダーフィールド値を追加して別のノードを参照する可能性があります。このような構造は、実装固有であり、このドキュメントの範囲外です。
Intermediate proxies SHOULD NOT add a Path header field to a request unless the UA has indicated support for this extension with a Supported header field value. If the UA has indicated support and the proxy requires the registrar to support the Path extension, then the proxy SHOULD insert a Requires header field value for this extension. If the UA has not indicated support for the extension and the proxy requires support for it in the registrar, the proxy SHOULD reject the request with a 421 response indicating a requirement for the extension.
中間プロキシは、UAがサポートされているヘッダーフィールド値でこの拡張機能のサポートを示していない限り、リクエストにパスヘッダーフィールドを追加するべきではありません。UAがサポートを示しており、プロキシがレジストラにパス拡張機能をサポートする必要がある場合、プロキシはこの拡張機能にヘッダーフィールド値を必要とする必要があります。UAが拡張機能のサポートを示しておらず、プロキシがレジストラでのサポートを必要とする場合、プロキシは拡張の要件を示す421応答でリクエストを拒否する必要があります。
Proxies processing a REGISTER response SHOULD NOT alter any Path header field values that may be present in the response. The registrar MAY protect the Path header field in the response by including it in a protected S/MIME body, and alterations of the Path by an intermediate proxy can therefore be detected by the UA as man-in-the-middle attacks. Proxies SHOULD only consider altering the value of a Path header field in the REGISTER response if they have the credentials to correctly alter the S/MIME body to account for the change.
プロキシレジスタ応答の処理は、応答に存在する可能性のあるパスヘッダーフィールド値を変更してはなりません。レジストラは、保護されたS/MIME本体に含めることにより、応答のパスヘッダーフィールドを保護することができ、したがって、中間プロキシによるパスの変更は、中間攻撃としてUAによって検出できます。プロキシは、変更を説明するためにS/MIMEボディを正しく変更する資格情報がある場合にのみ、レジスタ応答のパスヘッダーフィールドの値を変更することを検討する必要があります。
If a Path header field exists in a successful REGISTER request, the registrar constructs an ordered list of route elements (a path vector) from the nodes listed in the Path header field values, preserving the order as indicated in the Path header field values. The registrar then stores this path vector in association with that contact and the address-of-record indicated in the REGISTER request (the "binding" as defined in [1]). The registrar copies the Path header field values into a Path header field in the successful (200 class) REGISTER response. In the event that the home proxy and registrar are not co-located, the registrar MAY apply a locally-determined transformation to the stored path vector.
パスヘッダーフィールドがレジスタリクエストの成功に存在する場合、レジストラはパスヘッダーフィールド値にリストされているノードからルート要素（パスベクトル）の順序付けられたリストを構築し、パスヘッダーフィールド値に示されているように順序を維持します。レジストラは、その連絡先とレジスタリクエスト（[1]で定義されている「バインディング」）に示されている記録アドレスに関連してこのパスベクトルを保存します。レジストラは、成功した（200クラス）レジスタ応答のパスヘッダーフィールド値をパスヘッダーフィールドにコピーします。ホームプロキシとレジストラが共同で協力されていない場合、レジストラは、保存されたパスベクトルに局所的に決定された変換を適用することができます。
If a registrar receives a REGISTER request containing a Path header field and there is no indication of support for the extension in the UA (via a Supported header field), the registrar must rely on local policy in determining how to treat this request. The recommended policy is for the registrar to reject the request with a 420 "Bad Extension" response indicating the Path extension. This approach allows the UA to detect that an intermediate proxy has inappropriately added a Path header field. However, the Path mechanism should technically work in the absence of UA support (at some compromise to security), so some registrars MAY choose to support the extension in the absence of a Supported header field value in the request.
レジストラがパスヘッダーフィールドを含むレジスタリクエストを受信し、UA（サポートされているヘッダーフィールドを介して）の拡張機能のサポートの兆候がない場合、レジストラはこのリクエストの扱い方を決定する際にローカルポリシーに依存する必要があります。推奨されるポリシーは、レジストラがパス拡張を示す420の「悪い拡張」応答でリクエストを拒否することです。このアプローチにより、UAは中間プロキシがパスヘッダーフィールドを不適切に追加したことを検出できます。ただし、パスメカニズムは、UAサポートがない場合に技術的に機能する必要があります（セキュリティに対する妥協点）。一部のレジストラは、リクエストにサポートされているヘッダーフィールド値がない場合に拡張機能をサポートすることを選択できます。
In the common SIP model, there is a home proxy associated with the registrar for a user. Each incoming request targeted to the public address-of-record for the user is routed to this proxy, which consults the registrar's database in order to determine the contact to which the request should be retargeted. The home proxy, in its basic mode of operation, rewrites the request-URI from the incoming request with the value of the registered contact and retransmits the request.
一般的なSIPモデルには、ユーザーのレジストラに関連付けられたホームプロキシがあります。ユーザーのパブリックアドレスアドレスをターゲットにした各受信要求は、このプロキシにルーティングされます。このプロキシは、リクエストのリターゲティングを行う連絡先を決定するためにレジストラのデータベースを参照します。Home Proxyは、その基本的な動作モードで、登録された連絡先の値で着信要求からリクエスト-URIを書き換え、リクエストを再送信します。
With the addition of Path, the home proxy also copies the stored path vector associated with the specific contact in the registrar database into the Route header field of the outgoing request as a preloaded route. This causes the outgoing request to transit the proxies that were included in the Path header field of the REGISTER request.
パスの追加により、ホームプロキシは、レジストラデータベース内の特定の連絡先に関連付けられた保存されたパスベクトルを、予選ルートとして発信要求のルートヘッダーフィールドにコピーします。これにより、レジスタリクエストのパスヘッダーフィールドに含まれていたプロキシを通過するという発信要求が発生します。
In normal processing, the home proxy is the "terminal point" for the user's address-of-record (AOR). Consequentially, the Route header field on the incoming request will have been exhausted in reaching the home proxy. If it isn't, then things get interesting. In the most common case, the home proxy generates the outgoing Route header field by inserting the stored path vector ahead of the Route header field values contained in the incoming request. This procedure may be altered by a local policy at the home proxy.
通常の処理では、ホームプロキシは、ユーザーの録音アドレス（AOR）の「端末ポイント」です。その結果、着信要求のルートヘッダーフィールドは、ホームプロキシに到達する際に使い果たされました。そうでない場合、物事は面白くなります。最も一般的なケースでは、ホームプロキシは、着信リクエストに含まれるルートヘッダーフィールド値の前に保存されたパスベクトルを挿入することにより、発信ルートヘッダーフィールドを生成します。この手順は、Home Proxyのローカルポリシーによって変更される場合があります。
Loose routes may interact with routing policy in interesting ways. The specifics of how the stored path vector integrates with any locally required default route and local policy are implementation dependent. For example, some devices will use locally-configured explicit loose routing to reach a next-hop proxy, and others will use a default outbound-proxy routing rule. However, for the result to function, the combination must provide valid routing in the local environment. In general, the stored path vector is appended to any locally configured route needed to egress the service cluster. The service proxy (or registrar, as noted earlier) MAY also transform the stored path vector as needed to provide correct functionality. Systems designers must match the Path recording policy of their nodes with the routing policy in order to get a workable system.
ルーズルートは、興味深い方法でルーティングポリシーと対話する場合があります。保存されたパスベクトルがどのように局所的に必要なデフォルトルートと統合され、ローカルポリシーが実装に依存するかの詳細。たとえば、一部のデバイスは、ローカルに構成された明示的なルーズルーティングを使用してNext-Hopプロキシに到達し、他のデバイスはデフォルトのアウトバウンドプロキシルーティングルールを使用します。ただし、機能するためには、組み合わせはローカル環境で有効なルーティングを提供する必要があります。一般に、保存されたパスベクトルは、サービスクラスターを脱出するために必要なローカル構成ルートに追加されます。サービスプロキシ（または前述のように、レジストラ）は、正しい機能を提供するために必要に応じて保存されたパスベクトルを変換する場合があります。システム設計者は、実行可能なシステムを取得するために、ノードのパス記録ポリシーをルーティングポリシーと一致させる必要があります。
Note that some header fields (e.g. Content-Length) and session descriptions are omitted to provide a shorter and hopefully more readable presentation. The node marked REGISTRAR is a registrar and a proxy and serves as a home proxy. Thus, in the DNS the domain EXAMPLEHOME.COM points to the same host as REGISTRAR.EXAMPLEHOME.COM.
一部のヘッダーフィールド（コンテンツレングスなど）とセッションの説明は、より短く、できれば読みやすいプレゼンテーションを提供するために省略されていることに注意してください。ノードマークされたレジストラはレジストラとプロキシであり、ホームプロキシとして機能します。したがって、DNSでは、ドメインexamplehome.comがRegistrar.examplehome.comと同じホストを指します。
As an example, we use the scenario from the Background section:
例として、背景セクションのシナリオを使用します。
UA1----P1-----P2----P3-----REGISTRAR
In this example, UA1 sends a REGISTER request to REGISTRAR. This
request transits its default outbound proxy P1, an intermediate proxy
P2, and the firewall proxy for the home domain, P3, before reaching
REGISTRAR. Due to network topology and operational policy, P1 and
and P3 need to be transited by requests from REGISTRAR or other nodes
in the home network targeted to UA1. P2 does not. P1 and P3 have
been configured to include themselves in Path header fields on
REGISTER requests that they process. UA1 has a current IP address of
"192.0.2.4".
Message sequence for REGISTER with Path:
パスに登録するためのメッセージシーケンス：
F1 Register UA1 -> P1
F1レジスタUA1-> P1
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path . . .
登録SIP：Registrar.examplehome.com SIP/2.0経由：SIP/2.0/UDP 192.0.2.4:5060; Branch=Z9Hg4BKNASHDS7 TO：UA1 <SIP：sip：ua1@examplehome.com>>; tag = 456248 call-id：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<sip：ua1@192.0.2.4>サポート：パス。。。
F2 Register P1 -> P2
F2レジスタP1-> P2
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P1.EXAMPLEVISITED.COM;lr> . . .
登録SIP：Registrar.examplehome.com SIP/2.0経由：SIP/2.0/UDP 112.68.155.4:5060; Branch=Z9HG4BK34GHI7AB04 VIA：SIP/2.0/UDP 192.0.2.4:5060;Branch = Z9HG4BKNASHDS7@examplehome.com> from：ua1 <sip：ua1@examplehome.com>; tag = 456248 call-id：843817637684230@998sdasdh09 cseq：1826レジスタ連絡先：<sip：ua1@192.0.2.4>：p1.examplevisited.com; lr>。。。
Note: P1 has added itself to the Path.
注：P1はパスに追加されました。
F3 Register P2 -> P3
F3レジスタP2-> P3
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P1.EXAMPLEVISITED.COM;lr> . . .
SIPの登録：Registrar.examplehome.com SIP/2.0経由：SIP/2.0/UDP 178.73.76.230:5060; Branch=Z9HG4BKIOKIOUKJU908 VIA：SIP/2.0/UDP 112.68.155.4:5060; BrandanChanch = Z9HG4K34GHI7AB04経由192.0.2.4:5060; branch=z9hg4bknashds7 to：ua1 <sip：ua1@examplehome.com> from：ua1 <sip：ua1@examplehome.com>; tag = 456248 call-id：843817637684230@998sdasdh09 csep@98sdasdh09 ceq：1826<sip：ua1@192.0.2.4>サポート：パスパス：<sip：p1.examplevisited.com; lr>。。。
Note: P2 did NOT add itself to the Path.
注：P2はパスに追加されませんでした。
F4 Register P3 -> REGISTRAR
F4レジスタP3->レジストラ
REGISTER sip:REGISTRAR.EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .
SIPの登録：Registrar.examplehome.com SIP/2.0経由：SIP/2.0/UDP 19.31.97.3:5060; Branch=Z9HG4BKP3WER654363 VIA：SIP/2.0/UDP 178.73.76.230:5060; Brandanch = Z9HHHHHHHHHHHHHHGIOKIOUKIOKIOKIOKIOUCJU908 VIA：112.68.155.4:5060; branch = z9hg4bk34ghi7ab04 via：sip/2.0/udp 192.0.2.4:5060; branch = z9hg4kknashds7から：ua1 <sip：ua1@examplehome.com>Tag = 456248 Call-ID：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<sip：ua1@192.0.2.4>パスパス：<sip：p3.examplehome.com; lr>、<sip：p1。; lr>。。。
Note: P3 added itself to the Path.
注：P3はパスに追加されました。
F5 REGISTRAR executes Register
F5レジストラはレジスタを実行します
REGISTRAR Stores:
For UA1@EXAMPLEHOME.COM
Contact: <sip:UA1@192.0.2.4>
Supported: path
Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr>
F6 Register Response REGISTRAR -> P3
F6レジスタ応答レジストラ - > P3
SIP/2.0 200 OK Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .
SIP/2.0 200 OK Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKp3wer654363 Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch = z9hg4bk34ghi7ab04 via：sip/2.0/udp 192.0.2.4:5060; branch = z9hg4bknashds7 to：ua1 <sip：ua1@examplehome.com>;タグ= 251077456248 Call-ID：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<SIP：<SIP：UA1@192.0.2.4>サポート：パスパス：<SIP：P3.ExampleHome.com; LR>、<SIP：P1.ExampleVisited.com; LR>。。。
Note: The Path header field in the response is identical to the one received in the REGISTER request.
注：応答のパスヘッダーフィールドは、レジスタリクエストで受信したものと同一です。
F7 Register Response P3 -> P2
F7レジスタ応答P3-> P2
SIP/2.0 200 OK Via: SIP/2.0/UDP 178.73.76.230:5060;branch=z9hG4bKiokioukju908 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .
SIP/2.0 200 OK Via：SIP/2.0/UDP 178.73.76.230:5060; Branch = Z9HG4BKIOKIOKJU908 VIA：SIP/2.0/UDP 112.68.155.4:5060; Branch=Z9HG4BK34GHI7AB04 192.0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0/UD0.branch = z9hg4bknashds7 to：ua1 <sip：ua1@examplehome.com>; tag = 251077 from：ua1 <sip：ua1@examplehome.com>; tag = 456248 call-id：843817637684230@998SDASDH09 CSEQ：<SIP QUSTIOM QUSTOM：ua1@192.0.2.4>サポート：パスパス：<sip：p3.examplehome.com; lr>、<sip：p1.examplevisited.com; lr>。。。
F8 Register Response P2 -> P1
F8レジスタ応答P2-> P1
SIP/2.0 200 OK Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bK34ghi7ab04 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .
sip/2.0 200 ok via：sip/2.0/udp 112.68.155.4:5060; branch = z9hg4bk34ghi7ab04 via：sip/2.0/udp 192.0.2.4:5060; branch = z9hg4knashds7 to：ua1 <sip：ua1@exappemaplehome>;Tag = 251077 from：ua1 <sip：ua1@examplehome.com>; tag = 456248 call-id：843817637684230@998SDASDH09 CSEQ：1826レジスタ連絡先：<sip：ua1@192.0.2.4>.examplehome.com; lr>、<sip：p1.examplevisited.com; lr>。。。
F9 Register Response P1 -> UA1
F9レジスタ応答P1-> UA1
SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 To: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=251077 From: UA1 <sip:UA1@EXAMPLEHOME.COM>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:UA1@192.0.2.4> Supported: path Path: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .
sip/2.0 200 ok via：sip/2.0/udp 192.0.2.4:5060; branch = z9hg4bknashds7 to：ua1 <sip：ua1@examplehome.com>;タグ= 251077Tag = 456248 Call-ID：843817637684230@998SDASDH09 CSEQ：1826登録連絡先：<sip：ua1@192.0.2.4>パスパス：<sip：p3.examplehome.com; lr>、<sip：p1。; lr>。。。
This example shows the message sequence for an INVITE transaction originating from UA2 eventually arriving at UA1. REGISTRAR inserts a preloaded Route toward UA1 and retargets the request by replacing the request URI with the registered Contact. It then sends the retargeted INVITE along the Path towards UA1. Note that this example introduces foreign user agent UA2 (address "71.91.180.10") and foreign domain FOREIGN.ELSEWHERE.ORG. We have extended the diagram from the previous example by adding UA2, and by showing P2 out-of-line indicating that it did not include itself in the path during registration.
この例は、最終的にUA1に到着するUA2から発生する招待トランザクションのメッセージシーケンスを示しています。レジストラは、UA1に向かってプリロードされたルートを挿入し、リクエストURIを登録済みの連絡先に置き換えることにより、リクエストをリクターゲットします。次に、UA1へのパスに沿ってリターゲティングされた招待状を送信します。この例では、外国人ユーザーエージェントUA2（アドレス "71.91.180.10"）と外国のドメインforeign.elsewhere.orgを紹介していることに注意してください。UA2を追加することにより、前の例から図を拡張し、登録中に自分自身がパスに含まれていないことを示すP2を示すことにより、図を拡張しました。
Scenario
シナリオ
UA1----P1---------P3-----REGISTRAR
| |
P2 |
|
UA2--------------------------
Message sequence for INVITE using Path:
パスを使用した招待のメッセージシーケンス：
F1 Invite UA2 -> REGISTRAR
F1招待UA2->レジストラ
INVITE UA1@EXAMPLEHOME.COM SIP/2.0 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> . . .
ua1@examplehome.com sip/2.0 via：sip/2.0/udp 71.91.180.10:5060; branch=z9hg4bke2i95c5st3r to：ua1 <sip：ua1@examplehome.com> from：ua2 <sip：ua2@foreign.else>; tag = 224497 call-id：48273181116@71.91.180.10 cseq：29招待連絡先：<sip：ua2@71.91.180.10>。。。
F2 REGISTRAR processing
F2レジストラ処理
REGISTRAR looks up name "UA1@EXAMPLEHOME.COM" and returns:
- Contact = <sip:UA1@192.0.2.4>
- Path vector = <sip:P3.EXAMPLEHOME.COM;lr>,
<sip:P1.EXAMPLEVISITED.COM;lr>
Note: The Contact replaces the request-URI. The path vector is pushed onto the Route stack (preloaded Route) of the outgoing INVITE request. The topmost Route is used for making the routing decision (in conjunction with local policy).
注：連絡先はリクエスト-URIを置き換えます。パスベクトルは、発信招待リクエストのルートスタック（プリロードルート）に押し込まれます。最上部のルートは、ルーティングの決定を行うために使用されます（ローカルポリシーと併せて）。
F3 Invite REGISTRAR -> P3
F3招待レジストラ - > P3
INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Route: <sip:P3.EXAMPLEHOME.COM;lr>,<sip:P1.EXAMPLEVISITED.COM;lr> . . .
ua1@192.0.2.4 sip/2.0 via：sip/2.0/udp 143.70.6.83:5060; branch = z9hg4bklj25c107a7b176 via：sip/2.0/udp 71.91.180.10:5060 ua1@examplehome.com> from：ua2 <sip：ua2@foreign.elsewhere.org>; tag = 224497 call-id：48273181116@71.91.180.10 CSEQ：29招待連絡先：<sip：ua2@71.91.180.10>ルート：<SIP：<SIP：<SIP：p3.examplehome.com; lr>、<sip：p1.examplevisited.com; lr>。。。
Note: In this example REGISTRAR does not want to stay on the Route and therefore does not insert a Record-Route.
注：この例では、レジストラはルートに留まりたくないため、記録的なルートを挿入しません。
F4 Invite P3 -> P1
F4招待P3-> P1
INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Record-Route: <sip:P3.EXAMPLEHOME.COM;lr> Route: <sip:P1.EXAMPLEVISITED.COM;lr> . . .
ua1@192.0.2.4 sip/2.0 via：sip/2.0/udp 19.31.97.3:5060; branch = z9hg4bkjasg7nc9e via：sip/2.0/udp 143.70.6.83:5060; branknanch = z9hhhg4bklj25a767avdip17avdippid17a p 71.91。180.10：5060; branch = z9hg4bke2i95c5st3r to：ua1 <sip：ua1@examplehome.com> from：ua2 <sip：ua2@foreign.else.org>; tag = 224497 call-id：48273181116@71.91.91.180.10.10連絡先：<sip：ua2@71.91.180.10>レコードルート：<sip：p3.examplehome.com; lr>ルート：<sip：p1.examplevisited.com; lr>。。。
Note: P3 has added a Record-Route entry, indicating that it wants to be traversed by future messages in this dialog.
注：P3には記録的なエントリが追加されており、このダイアログの将来のメッセージによって移動したいことを示しています。
F5 Invite P1 -> UA1
f5 P1-> UA1を招待します
INVITE UA1@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP 112.68.155.4:5060;branch=z9hG4bKk5l1833o43p Via: SIP/2.0/UDP 19.31.97.3:5060;branch=z9hG4bKjasg7li7nc9e Via: SIP/2.0/UDP 143.70.6.83:5060;branch=z9hG4bKlj25C107a7b176 Via: SIP/2.0/UDP 71.91.180.10:5060;branch=z9hG4bKe2i95c5st3R To: UA1 <sip:UA1@EXAMPLEHOME.COM> From: UA2 <sip:UA2@FOREIGN.ELSEWHERE.ORG>;tag=224497 Call-ID: 48273181116@71.91.180.10 CSeq: 29 INVITE Contact: <sip:UA2@71.91.180.10> Record-Route: <sip:P1.EXAMPLEVISITED.COM;lr> Record-Route: <sip:P3.EXAMPLEHOME.COM;lr> . . .
ua1@192.0.2.4 sip/2.0 via：sip/2.0/udp 112.68.155.4:5060; branch = z9hg4bkk5l1833o43p via：sip/2.0/udp 19.31.97.3:5060; branch = z9hhg4bk9eを介して143.70。6.83：5060; Branch = Z9HG4BKLJ25C107A7B176 VIA：SIP/2.0/UDP 71.91.180.10:5060; Branch=Z9HG4KKE2I95C5ST3R TO：UA1 <SIP：UA1@EXAMPAMPAMERHOME.com>Tag = 224497 Call-ID：48273181116@71.91.180.10 CSEQ：29招待連絡先：<sip：ua2@71.91.180.10>レコードルート：<sip：p1.examplevisited.com; lr> record-route：<sip：<sip：p3.examplehome.com; lr>。。。
Note: P1 has added a Record-Route entry, indicating that it wants to be traversed by future messages in this dialog.
注：P1はレコードルートエントリを追加しました。これは、このダイアログの将来のメッセージによって移動したいことを示しています。
There are few security considerations for this document beyond those in SIP [1]. From a security perspective, the Path extension and its usage are identical to the Record-Route header field of basic SIP. Note that the transparency of the user expectations are preserved by returning the final Path to the originating UA -- that is, the UA is informed which additional proxies have been inserted into the path for the registration associated with that response.
SIP [1]を超えて、このドキュメントについてはセキュリティ上の考慮事項はほとんどありません。セキュリティの観点から、パス拡張とその使用は、基本的なSIPのレコードルートヘッダーフィールドと同一です。ユーザーの期待の透明性は、発信されるUAへの最終パスを返すことによって保存されることに注意してください。つまり、UAは、その応答に関連する登録のパスに追加のプロキシが挿入された追加プロキシが通知されます。
The Path header field accumulates information in a hop-by-hop manner during REGISTER processing. The return information is essentially end-to-end, that is, it is not altered by intermediate proxies. This leads to two slightly different security approaches.
パスヘッダーフィールドは、レジスタ処理中にホップバイホップの方法で情報を蓄積します。返品情報は本質的にエンドツーエンドです。つまり、中間プロキシによって変更されません。これにより、2つのわずかに異なるセキュリティアプローチにつながります。
Information accumulated in REGISTER processing causes additional proxies to be included in future requests between the registrar's location and the UA. An attack that allowed an intruding proxy to add itself to this chain would allow the attacker to intercept future calls intended for the UA.
登録処理に蓄積された情報により、レジストラの場所とUAの間の将来の要求に追加のプロキシが含まれます。侵入するプロキシをこのチェーンに追加できる攻撃により、攻撃者はUA向けの将来の呼び出しを傍受することができます。
An attacker could conceivably alter the Path either by altering data "on the wire" or by other manipulations (such as impersonation) that would cause it to be included in the SIP routing chain (a "node insertion" attack). Altering data "on the wire" may be addressed adequately by the use of transport-layer integrity protection mechanisms such as TLS or IPSEC. Proxy insertion can be addressed by mutual authentication at the proxy layer, which can also be provided by TLS or IPSEC. The "sips:" URI class defined in [1] provides a mechanism by which a UA may request that intermediate proxies provide integrity protection and mutual authentication.
攻撃者は、「ワイヤー上の」データを変更するか、SIPルーティングチェーン（「ノード挿入」攻撃）に含まれる他の操作（なりすましなど）によってパスを変更する可能性があります。「ワイヤー上の」データを変更すると、TLSやIPSECなどの輸送層整合性保護メカニズムを使用することにより、適切に対処できます。プロキシ挿入は、プロキシ層での相互認証によって対処できます。これは、TLSまたはIPSECによっても提供できます。「SIPS：」では、[1]で定義されているURIクラスは、UAが中間プロキシが整合性保護と相互認証を提供することを要求するメカニズムを提供します。
Systems using the Path mechanism SHOULD use appropriate mechanisms (TLS, IPSEC, etc.) to provide message integrity and mutual authentication. UAs SHOULD use "sips:" to request transitive protection.
パスメカニズムを使用するシステムは、適切なメカニズム（TLS、IPSECなど）を使用して、メッセージの整合性と相互認証を提供する必要があります。UASは「SIP：」を使用して、推移的保護を要求する必要があります。
The registering UA SHOULD use S/MIME mechanisms to provide a protected copy of the original request to the registrar. In this case, the UA SHOULD include a Supported header field with a value indicating support for the Path extension in the protected copy. Registrars receiving such as request MUST honor the Path extension only if support is indicated in the protected header field. Further, they SHOULD compare the unprotected Supported header field with the protected Supported header field and take appropriate action in the event that an intermediate has altered the message to indicate support for Path when it was not indicated by the requesting UA.
登録UAは、S/MIMEメカニズムを使用して、元のリクエストの保護されたコピーをレジストラに提供する必要があります。この場合、UAには、保護されたコピーのパス拡張のサポートを示す値を持つサポートされたヘッダーフィールドを含める必要があります。リクエストなどのレジストラは、保護されたヘッダーフィールドにサポートが示されている場合にのみ、パス拡張を尊重する必要があります。さらに、保護されていないサポートされているヘッダーフィールドを保護されたサポートヘッダーフィールドと比較し、中級者がRequirenting UAで示されていない場合にパスのサポートを示すメッセージを変更した場合に適切なアクションを実行する必要があります。
The data returned to the UA by the Path header field in the response to the REGISTER request is there to provide openness to the UA. The registrar is telling the UA, "These are the intermediate proxies that will be included on future requests to you processed through me". By inspection of this header field, the UA may be able to detect node insertion attacks that involve inserting a proxy into the SIP routing chain. S/MIME techniques may be used to prevent alteration of this header field by intermediate proxies during response processing.
レジスタリクエストへの応答でパスヘッダーフィールドによってUAに返されたデータは、UAに開放性を提供するためにあります。レジストラは、UAに「これらは私を通して処理されたあなたへの将来のリクエストに含まれる中間のプロキシです」と言っています。このヘッダーフィールドを検査することにより、UAは、SIPルーティングチェーンにプロキシを挿入することを伴うノード挿入攻撃を検出できる可能性があります。S/MIME技術は、応答処理中の中間プロキシによるこのヘッダーフィールドの変更を防ぐために使用できます。
As specified, there is no requirement for arbitrary proxies between the UA and the registrar to modify the Path header field in the REGISTER response. Consequently, we may use an end-to-end protection technique. The S/MIME technique defined in [1] provides an effective mechanism. Using this technique, the registrar makes a copy of the complete response, signs it, and attaches it as a body to the response. The UA may then verify this response, assuring an unmodified Path header field is received.
指定されているように、レジスタ応答のパスヘッダーフィールドを変更するために、UAとレジストラの間に任意のプロキシの要件はありません。その結果、エンドツーエンドの保護技術を使用する場合があります。[1]で定義されているS/MIME技術は、効果的なメカニズムを提供します。この手法を使用して、レジストラは完全な応答のコピーを作成し、署名し、それを応答に本体として取り付けます。その後、UAはこの応答を検証し、変更されていないパスヘッダーフィールドが受信されることを保証します。
In addition to the hop-by-hop integrity protection and mutual authentication measures suggested for REGISTER request processing in the preceding section, systems using Path header fields SHOULD implement end-to-end protection using S/MIME. More specifically, registrars returning a Path header field SHOULD attach a signed S/MIME of the response, and UAs receiving a REGISTER response containing a Path header field SHOULD validate the message using the S/MIME technique. Furthermore, UAs receiving a Path header field in a REGISTER response SHOULD render it to the user, or (where feasible) check it programmatically.
前のセクションでレジスタリクエスト処理のために提案されたホップバイホップの整合性保護と相互認証測定に加えて、パスヘッダーフィールドを使用したシステムは、S/MIMEを使用してエンドツーエンドの保護を実装する必要があります。より具体的には、パスヘッダーフィールドを返すレジストラは、応答の署名されたS/MIMEを添付する必要があり、PATHヘッダーフィールドを含むレジスタ応答を受信するUASは、S/MIMEテクニックを使用してメッセージを検証する必要があります。さらに、レジスタ応答でパスヘッダーフィールドを受信するUASは、それをユーザーにレンダリングするか、（実行可能な場合）プログラムで確認する必要があります。
This document defines the SIP extension header field "Path", which the IANA has added to the registry of SIP header fields defined in SIP [1].
このドキュメントでは、SIP拡張ヘッダーフィールド「パス」を定義します。これは、IANAがSIPで定義されたSIPヘッダーフィールドのレジストリに追加した[1]。
This document also defines the SIP option tag "path" which IANA has added to the registry of SIP option tags defined in SIP [1].
このドキュメントでは、SIPオプションタグ「パス」も定義します。これは、SIP [1]で定義されたSIPオプションタグのレジストリに追加されたものです。
The following is the registration for the Path header field:
以下は、パスヘッダーフィールドの登録です。
RFC Number: RFC3327
RFC番号：RFC3327
Header Field Name: Path
ヘッダーフィールド名：パス
Compact Form: none
コンパクトフォーム：なし
The following is the registration for the path option tag:
以下は、パスオプションタグの登録です。
RFC Number: RFC3327
RFC番号：RFC3327
Option Tag: path
オプションタグ：パス
Min Huang and Stinson Mathai, who put together the original proposal in 3GPP for this mechanism, and worked out most of the 3GPP procedures in 24.229.
Min HuangとStinson Mathaiは、このメカニズムのために3GPPで元の提案をまとめ、24.229で3GPP手順のほとんどを策定しました。
Keith Drage, Bill Marshall, and Miguel Angel Garcia-Martin who argued with everybody a lot about the idea as well as helped refine the requirements.
キース・ドレイジ、ビル・マーシャル、ミゲル・エンジェル・ガルシア・マルティンは、要件の洗練を助け、そのアイデアについて多くの人と議論しました。
Juha Heinanen, who argued steadfastly against standardizing the function of discovering the home proxy with this technique in this document.
Juha Heinanenは、このドキュメントでこの手法でホームプロキシを発見する機能を標準化することに対してしっかりと主張しました。
Normative References
引用文献
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[2] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[4] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
Non-Normative References
非規範的な参照
[5] Garcia-Martin, MA., "3GPP Requirements On SIP", Work in Progress.
[5] マサチューセッツ州ガルシアマルティン、「SIPの3GPP要件」、進行中の作業。
[6] Mankin, A., "SIP Change Process", Work in Progress.
[6] マンキン、A。、「SIP変更プロセス」、進行中の作業。
Authors' Addresses
著者のアドレス
Dean Willis dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano, TX 75028 US
Dean Willis Dynamicsoft Inc. 5100 Tennyson Parkway Suite 1200 Plano、TX 75028 US
Phone: +1 972 473 5455
EMail: dean.willis@softarmor.com
URI: http://www.dynamicsoft.com/
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
Bernie Hoeneisen Switch Limmatquai 138 CH-8001 Zuerich Switzerland
Phone: +41 1 268 1515
EMail: hoeneisen@switch.ch, b.hoeneisen@ieee.org
URI: http://www.switch.ch/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。