[要約] RFC 8055は、SIPのViaヘッダーフィールドパラメータを使用して受信した領域を示すための仕様です。このRFCの目的は、SIPメッセージの経路情報に受信した領域を含めることで、セキュリティやトラブルシューティングのための情報を提供することです。
Internet Engineering Task Force (IETF) C. Holmberg
Request for Comments: 8055 Ericsson
Category: Standards Track Y. Jiang
ISSN: 2070-1721 China Mobile
January 2017
Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm
受信したレルムを示すヘッダーフィールドパラメータを介したセッション開始プロトコル（SIP）
Abstract
概要
This specification defines a new Session Initiation Protocol (SIP) Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.
この仕様では、新しいSIP（Session Initiation Protocol）のヘッダーフィールドパラメーター 'received-realm'を定義しています。これにより、SIPエンティティがトランジットネットワークへのエントリポイントとして機能し、隣接するアップストリームネットワークからSIP要求を受信することを指定できます。隣接ネットワークに関連付けられたネットワークレルム値。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8055.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8055で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. General . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Use Case: Transit Network Application Services . . . . . 3
1.3. Use Case: Transit Network Routing . . . . . . . . . . . . 4
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Via 'received-realm' Header Field Parameter . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Operator Identifier . . . . . . . . . . . . . . . . . . . 5
5.3. JWS Header . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. JWS Payload . . . . . . . . . . . . . . . . . . . . . . . 6
5.5. JWS Serialization . . . . . . . . . . . . . . . . . . . . 7
5.6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
5.6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . 8
5.7. Example: SIP Via Header Field . . . . . . . . . . . . . . 8
6. User Agent and Proxy Behavior . . . . . . . . . . . . . . . . 8
6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Behavior of a SIP Entity Acting as a Network Entry Point 8
6.3. Behavior of a SIP Entity Consuming the 'received-realm'
Value . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Example: SIP INVITE Request and Response . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. 'received-realm' Via Header Field Parameter . . . . . . . 10
8.2. JSON Web Token Claims Registration . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
When Session Initiation Protocol (SIP) [RFC3261] sessions are established between networks belonging to different operators or between interconnected networks belonging to the same operator (or enterprise), the SIP requests associated with the session might traverse transit networks.
セッション開始プロトコル（SIP）[RFC3261]セッションが、異なる事業者に属するネットワーク間、または同じ事業者（または企業）に属する相互接続されたネットワーク間で確立されると、セッションに関連付けられたSIPリクエストがトランジットネットワークを通過する場合があります。
Such transit networks might provide different kinds of services. In order to provide such services, a transit network often needs to know to which operator (or enterprise) the adjacent upstream network from which the SIP session initiation request is received belongs.
このようなトランジットネットワークは、さまざまな種類のサービスを提供する可能性があります。このようなサービスを提供するために、トランジットネットワークは多くの場合、SIPセッション開始要求の送信元である隣接するアップストリームネットワークがどの事業者（または企業）に属しているかを知る必要があります。
This specification defines a new SIP Via header field parameter, 'received-realm', which allows a SIP entity acting as an entry point to a transit network to indicate from which adjacent upstream network a SIP request is received by using a network realm value associated with the adjacent network.
この仕様は、新しいSIP Viaヘッダーフィールドパラメータ「received-realm」を定義します。これにより、トランジットネットワークへのエントリポイントとして機能するSIPエンティティが、関連するネットワークレルム値を使用してSIPリクエストを隣接するアップストリームネットワークから受信することを示すことができます。隣接ネットワークと。
NOTE: As the adjacent network can be an enterprise network, an Inter Operator Identifier (IOI) cannot be used to identify the network because IOIs are not defined for enterprise networks.
注：隣接ネットワークはエンタープライズネットワークである可能性があるため、IOIはエンタープライズネットワークに対して定義されていないため、Inter Operator Identifier（IOI）を使用してネットワークを識別することはできません。
The following sections describe use cases where the information is needed.
次のセクションでは、情報が必要なユースケースについて説明します。
The Third Generation Partnership Project (3GPP) TS 23.228 [TS.3GPP.23.228] specifies how an IP Multimedia Subsystem (IMS) network can be used to provide transit functionality. An operator can use its IMS network to provide transit functionality, e.g., to non-IMS customers, to enterprise networks, and to other network operators.
第3世代パートナーシッププロジェクト（3GPP）TS 23.228 [TS.3GPP.23.228]は、IPマルチメディアサブシステム（IMS）ネットワークを使用してトランジット機能を提供する方法を指定しています。事業者は、IMSネットワークを使用して、非IMS顧客、企業ネットワーク、および他のネットワーク事業者などに輸送機能を提供できます。
The transit network operator can provide application services to the networks for which it is providing transit functionality. Transit application services are typically not provided on a per user basis, as the transit network does not have access to the user profiles of the networks for which the application services are provided. Instead, the application services are provided per served network.
トランジットネットワークオペレータは、トランジット機能を提供するネットワークにアプリケーションサービスを提供できます。トランジットネットワークは、アプリケーションサービスが提供されるネットワークのユーザープロファイルにアクセスできないため、トランジットアプリケーションサービスは通常、ユーザーごとに提供されません。代わりに、アプリケーションサービスは提供されたネットワークごとに提供されます。
When a SIP entity that provides application services (e.g., an Application Server) within a transit network receives a SIP request, in order to apply the correct services, it needs to know the adjacent upstream network from which the SIP request is received.
トランジットネットワーク内でアプリケーションサービス（アプリケーションサーバーなど）を提供するSIPエンティティがSIP要求を受信すると、正しいサービスを適用するために、SIP要求の送信元である隣接するアップストリームネットワークを知る必要があります。
A transit network operator normally interconnects to many different operators, including other transit network operators, and provides transit routing of SIP requests received from one operator network towards the destination. The destination can be within an operator network to which the transit network operator has a direct interconnect or within an operator network that only can be reached via one or more interconnected transit operators.
トランジットネットワークオペレーターは通常、他のトランジットネットワークオペレーターを含む多くの異なるオペレーターに相互接続し、1つのオペレーターネットワークから受信したSIP要求の宛先へのトランジットルーティングを提供します。宛先は、トランジットネットワークオペレーターが直接相互接続しているオペレーターネットワーク内、または1つ以上の相互接続されたトランジットオペレーターを介してのみ到達できるオペレーターネットワーク内にあります。
For each customer (i.e., interconnected network operator) for which the transit network operator routes SIP requests towards the requested destination, a set of transit routing policies are defined. These policies are used to determine how a SIP request shall be routed towards the requested destination to meet the agreement the transit network operator has with its customer.
トランジットネットワークオペレーターがSIP要求を要求された宛先にルーティングする各顧客（つまり、相互接続されたネットワークオペレーター）に対して、一連のトランジットルーティングポリシーが定義されます。これらのポリシーは、SIP要求が要求された宛先にルーティングされる方法を決定するために使用され、トランジットネットワークオペレーターは顧客との合意を満たします。
When a SIP entity that performs the transit routing functionality receives a SIP request, in order to apply the correct set of transit routing policies, it needs to know from which of its customers (i.e., adjacent upstream network) the SIP request is received.
トランジットルーティング機能を実行するSIPエンティティがSIPリクエストを受信すると、正しいトランジットルーティングポリシーのセットを適用するために、どの顧客（つまり、隣接するアップストリームネットワーク）からSIPリクエストを受信するかを知る必要があります。
The mechanism defined in this specification MUST only be used by SIP entities that are able to verify from which adjacent upstream network a SIP request is received.
この仕様で定義されたメカニズムは、SIP要求がどの隣接する上流ネットワークから受信されたかを検証できるSIPエンティティによってのみ使用されなければなりません（MUST）。
The mechanism for verifying from which adjacent upstream network a SIP request is received is outside the scope of this specification. Such a mechanism might be based on, for instance, receiving the SIP request on an authenticated Virtual Private Network (VPN), on a specific IP address, or on a specific network access.
SIP要求が受信された隣接するアップストリームネットワークから確認するメカニズムは、この仕様の範囲外です。このようなメカニズムは、たとえば、認証された仮想プライベートネットワーク（VPN）、特定のIPアドレス、または特定のネットワークアクセスでのSIP要求の受信に基づいている場合があります。
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]で説明されているように解釈されます。
SIP entity: A SIP User Agent (UA), or SIP proxy, as defined in RFC 3261.
SIPエンティティ：RFC 3261で定義されているSIPユーザーエージェント（UA）、またはSIPプロキシ。
Adjacent upstream SIP network: The adjacent SIP network in the direction from which a SIP request is received.
隣接するアップストリームSIPネットワーク：SIP要求を受信する方向の隣接するSIPネットワーク。
Network entry point: A SIP entity on the border of the network, which receives SIP requests from adjacent upstream networks.
ネットワークエントリポイント：隣接する上流ネットワークからSIPリクエストを受信する、ネットワークの境界にあるSIPエンティティ。
Inter Operator Identifier (IOI): A globally unique identifier to correlate billing information generated within the IP Multimedia Subsystem (IMS).
Inter Operator Identifier（IOI）：IPマルチメディアサブシステム（IMS）内で生成された請求情報を関連付けるグローバルに一意の識別子。
JWS: A JSON Web Signature, as defined in [RFC7515].
JWS：[RFC7515]で定義されているJSON Web署名。
The Via 'received-realm' header field parameter value is represented as a combination of an operator identifier whose value represents the adjacent network and a serialized JSON Web Signature (JWS) [RFC7515]. The JWS Payload consists of the operator identifier and other SIP information element values.
Via 'received-realm'ヘッダーフィールドのパラメーター値は、値が隣接ネットワークを表すオペレーター識別子とシリアル化されたJSON Web Signature（JWS）[RFC7515]の組み合わせとして表されます。 JWSペイロードは、オペレーターIDおよびその他のSIP情報要素の値で構成されます。
The procedures for encoding the JWS and calculating the signature are defined in [RFC7515]. As the JWS Payload information is found in other SIP information elements, the JWS Payload is detached from the serialized JWS conveyed in the header field parameter, as described in Appendix F of [RFC7515]. The operator identifier and the serialized JWS are separated using a colon character.
JWSをエンコードして署名を計算する手順は、[RFC7515]で定義されています。 [RFC7515]の付録Fで説明されているように、JWSペイロード情報は他のSIP情報要素にあるため、JWSペイロードは、ヘッダーフィールドパラメータで伝達されるシリアル化されたJWSから切り離されます。オペレーターIDとシリアライズされたJWSは、コロン文字を使用して区切られます。
The operator identifier is a token value that represents the adjacent operator. The scope of the value is only within the network that inserts the value.
オペレーターIDは、隣接するオペレーターを表すトークン値です。値のスコープは、値を挿入するネットワーク内のみです。
The operator identifier value is case insensitive.
オペレーターIDの値では、大文字と小文字が区別されません。
The following header parameters MUST be included in the JWS.
JWSには、次のヘッダーパラメータを含める必要があります。
o The "typ" parameter MUST have a "JWT" value.
o 「typ」パラメータには「JWT」値が必要です。
o The "alg" parameter MUST have the value of the algorithm used to calculate the JWS.
o 「alg」パラメータには、JWSの計算に使用されるアルゴリズムの値が必要です。
NOTE: Operators need to agree on the set of supported algorithms for calculating the JWT signature.
注：オペレーターは、JWT署名を計算するためにサポートされている一連のアルゴリズムについて合意する必要があります。
NOTE: The "alg" parameter values for specific algorithms are listed in the IANA JSON Web Signature and Encryption Algorithms sub-registry of the JSON Object Signing and Encryption (JOSE) registry. Operators need to use algorithms for which an associated "alg" parameter value has been registered. The procedures for defining new values are defined in [RFC7518].
注：特定のアルゴリズムの「alg」パラメーター値は、JSON Object Signing and Encryption（JOSE）レジストリのIANA JSON Web Signature and Encryption Algorithmsサブレジストリにリストされています。オペレーターは、関連する「alg」パラメーター値が登録されているアルゴリズムを使用する必要があります。新しい値を定義する手順は、[RFC7518]で定義されています。
Example:
例：
{
"typ":"JWT",
"alg":"HS256"
}
The following claims MUST be included in the JWS Payload:
次のクレームは、JWSペイロードに含まれている必要があります。
o The "sip_from_tag" claim has the value of the From 'tag' header field parameter of the SIP message.
o 「sip_from_tag」クレームには、SIPメッセージのFrom 'tag'ヘッダーフィールドパラメータの値があります。
o The "sip_date" claim has the value of the Date header field in the SIP message, encoded in JSON NumericDate format [RFC7519].
o 「sip_date」クレームには、JSON NumericDate形式[RFC7519]でエンコードされた、SIPメッセージのDateヘッダーフィールドの値があります。
o The "sip_callid" claim has the value of the Call-ID header field in the SIP message.
o 「sip_callid」クレームには、SIPメッセージのCall-IDヘッダーフィールドの値があります。
o The "sip_cseq_num" claim has the numeric value of the CSeq header field in the SIP message.
o 「sip_cseq_num」クレームには、SIPメッセージのCSeqヘッダーフィールドの数値が含まれます。
o The "sip_via_branch" claim has the value of the Via branch header field parameter of the Via header field, in the SIP message, to which the 'received-realm' header field parameter is attached.
o 「sip_via_branch」クレームには、SIPメッセージ内のViaヘッダーフィールドのViaブランチヘッダーフィールドパラメーターの値が含まれ、これに「received-realm」ヘッダーフィールドパラメーターが付加されます。
o The "sip_via_opid" claim has the value of the operator identifier part of the Via 'received-realm' header field parameter of the Via header field, in the SIP message, to which the 'received-realm' header field parameter is attached.
o 「sip_via_opid」クレームには、SIPメッセージのViaヘッダーフィールドのVia 'received-realm'ヘッダーフィールドパラメーターのオペレーター識別子部分の値が含まれます。このパラメーターには、 'received-realm'ヘッダーフィールドパラメーターが付加されます。
Example:
例：
{
"sip_from_tag":"1928301774",
"sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159",
"sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"
}
As the JWS Payload is not carried in the 'received-realm' parameter, in order to make sure that the sender and the receiver construct the JWS Payload object in the same way, the JSON representation of the JWS Payload object MUST be computed as follows:
JWSペイロードは「received-realm」パラメーターに含まれていないため、送信者と受信者が同じ方法でJWS Payloadオブジェクトを構築することを確認するには、JWS PayloadオブジェクトのJSON表現を次のように計算する必要があります。 ：
o All claims MUST be encoded using lowercase characters.
o すべての申し立ては小文字を使用してエンコードする必要があります。
o The claims MUST be in the same order as listed in Section 5.4.
o クレームは、セクション5.4にリストされているのと同じ順序でなければなりません。
o All claims except "sip_date" MUST be encoded as StringOrURI JSON string value [RFC7519].
o 「sip_date」を除くすべてのクレームは、StringOrURI JSON文字列値[RFC7519]としてエンコードする必要があります。
o The "sip_date" claim MUST be encoded as a JSON NumericDate value [RFC7519].
o 「sip_date」クレームは、JSON NumericDate値[RFC7519]としてエンコードする必要があります。
o The JWS Payload MUST follow the rules for the construction of the thumbprint of a JSON Web Key (JWK) as defined in Section 3, Step 1 only, of [RFC7638].
o [WSCペイロード]は、[RFC7638]のセクション3、ステップ1のみで定義されている、JSON Webキー（JWK）のサムプリントの構築に関するルールに従う必要があります。
Example:
例：
{"sip_from_tag":"1928301774","sip_date":1472815523,
"sip_callid":"a84b4c76e66710@pc33.atlanta.com",
"sip_cseq_num":"314159","sip_via_branch":"z9hG4bK776asdhds",
"sip_via_opid":"myoperator"}
NOTE: Line breaks are for display purposes only.
注：改行は表示のみを目的としています。
This section describes the syntax extensions to the ABNF syntax defined in [RFC3261] by defining a new Via header field parameter, 'received-realm'. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. "EQUAL", "LDQUOT", "RDQUOT", and "ALPHA" are defined in [RFC3261]. "DIGIT" is defined in [RFC5234].
このセクションでは、新しいViaヘッダーフィールドパラメータ 'received-realm'を定義することにより、[RFC3261]で定義されているABNF構文の構文拡張について説明します。この仕様で定義されているABNFは、RFC 5234 [RFC5234]に準拠しています。 「EQUAL」、「LDQUOT」、「RDQUOT」、および「ALPHA」は、[RFC3261]で定義されています。 「DIGIT」は[RFC5234]で定義されています。
via-params =/ received-realm
received-realm = "received-realm" EQUAL LDQUOT op-id COLON jws RDQUOT
op-id = token
jws = header ".." signature
header = 1*base64-char
signature = 1*base64-char
base64-char = ALPHA / DIGIT / "/" / "+"
EQUAL, COLON, token, LDQUOT, RDQUOT, ALPHA, and DIGIT are as defined in [RFC3261].
EQUAL、COLON、トークン、LDQUOT、RDQUOT、ALPHA、およびDIGITは、[RFC3261]で定義されています。
NOTE: The two adjacent dots in the 'jws' part are due to the detached payload being replaced by an empty string [RFC7515].
注：「jws」部分の2つの隣接するドットは、分離されたペイロードが空の文字列[RFC7515]に置き換えられるためです。
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJhbGciOiJIUzI1N..
dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk"
NOTE: Line breaks are for display purposes only.
注：改行は表示のみを目的としています。
This section describes how a SIP entity, acting as an entry point to a network, uses the 'received-realm' Via header field parameter.
このセクションでは、ネットワークへのエントリポイントとして機能するSIPエンティティが「received-realm」Viaヘッダーフィールドパラメータを使用する方法について説明します。
When a SIP entity acting as a network entry point forwards a SIP request or initiates a SIP request on its own (e.g., a Public Switched Telephone Network (PSTN) gateway), the SIP entity adds a Via header field to the SIP request, according to the procedures in RFC 3261 [RFC3261]. In addition, if the SIP entity is able to assert the adjacent upstream network and if the SIP entity is aware of a network realm value defined for that network, the SIP entity can add a 'received-realm' Via header field parameter conveying the network realm value as the operator identifier (Section 5.2) part of the header field parameter, to the Via header field added to the SIP request.
ネットワークエントリポイントとして機能するSIPエンティティがSIP要求を転送するか、それ自体でSIP要求を開始すると（たとえば、公衆交換電話網（PSTN）ゲートウェイ）、SIPエンティティはViaヘッダーフィールドをSIP要求に追加します。 RFC 3261 [RFC3261]の手順を参照してください。さらに、SIPエンティティが隣接するアップストリームネットワークをアサートでき、SIPエンティティがそのネットワークに定義されたネットワークレルム値を認識している場合、SIPエンティティは、ネットワークを伝達する「受信レルム」のViaヘッダーフィールドパラメータを追加できます。ヘッダーフィールドパラメーターのオペレーター識別子（セクション5.2）部分としてのレルム値。SIPリクエストに追加されたViaヘッダーフィールドに。
In addition, the SIP entity MUST also calculate a JWS (Section 5.4) and add the calculated JWS Header and JWS Signature as the 'jws' part of the Via header field parameter.
さらに、SIPエンティティは、JWSを計算し（セクション5.4）、Viaヘッダーフィールドパラメータの「jws」部分として、計算されたJWSヘッダーとJWS署名を追加する必要があります。
When a SIP entity receives a Via 'received-realm' header field parameter and intends to perform actions based on the header field parameter value, it MUST first recalculate the JWS and check whether the result matches the JWS received. If there is not a match, the SIP entity MUST discard the received 'received-realm' header field parameter. The SIP entity MAY also take additional actions (e.g., rejecting the SIP request) based on local policy.
SIPエンティティがVia 'received-realm'ヘッダーフィールドパラメーターを受信し、ヘッダーフィールドパラメーター値に基づいてアクションを実行する場合、最初にJWSを再計算し、結果が受信したJWSと一致するかどうかを確認する必要があります。一致がない場合、SIPエンティティは受信した 'received-realm'ヘッダーフィールドパラメータを破棄する必要があります。 SIPエンティティは、ローカルポリシーに基づいて追加のアクション（SIPリクエストの拒否など）を行うこともできます（MAY）。
This section shows an example of a SIP INVITE request and the associated response, which contains a Via header field (inserted into the request and removed from the response by the T_EP SIP proxy) with a 'received-realm' header field parameter.
このセクションでは、SIP INVITE要求とそれに関連する応答の例を示します。これには、「received-realm」ヘッダーフィールドパラメーターを持つViaヘッダーフィールド（要求に挿入され、T_EP SIPプロキシによって応答から削除されます）が含まれます。
Operator 1 T_EP T_AS
オペレーター1 T_EP T_AS
- INVITE ------> Via: SIP/2.0/UDP IP_UA -- INVITE ----------------------------> Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776; received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW 1gFWFOEjXk" Via: SIP/2.0/UDP IP_UA; received=IP_UA
- INVITE ------> Via：SIP / 2.0 / UDP IP_UA-INVITE ----------------------------> Via： SIP / 2.0 / UDP IP_TEP; branch = z9hG4bK776; received-realm = "myoperator：eyJ0eXAiOiJKV1QiLA0KICJh bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW 1gFWFOEjXk" Via：SIP / 2.0 / UDP IP_UA; received = IP_UA
<- 200 OK ----------------------------
Via: SIP/2.0/UDP IP_TEP;branch=z9hG4bK776;
received-realm="myoperator:eyJ0eXAiOiJKV1QiLA0KICJh
bGciOiJIUzI1N..dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW
1gFWFOEjXk"
Via: SIP/2.0/UDP IP_UA; received=IP_UA
<- 200 OK------
Via: SIP/2.0/UDP IP_UA; received=IP_UA
This specification defines a new Via header field parameter called 'received-realm' in the "Header Field Parameters and Parameter Values" sub-registry created by [RFC3968]. The syntax is defined in Section 5.6. The required information is:
この仕様は、[RFC3968]によって作成された「Header Field Parameters and Parameter Values」サブレジストリで、「received-realm」と呼ばれる新しいViaヘッダーフィールドパラメータを定義します。構文はセクション5.6で定義されています。必要な情報は次のとおりです。
Predefined
Header Field Parameter Name Values Reference
---------------------- --------------------- ---------- ---------
Via received-realm No RFC 8055
This specification defines new JSON Web Token claims in the "JSON Web Token Claims" sub-registry created by [RFC7519].
この仕様は、[RFC7519]によって作成された「JSON Web Token Claims」サブレジストリで新しいJSON Web Tokenクレームを定義します。
Claim Name: sip_from_tag Claim Description: SIP From tag header field parameter value Change Controller: IESG Reference: RFC 8055, RFC 3261
クレーム名：sip_from_tagクレーム説明：SIP Fromタグヘッダーフィールドのパラメーター値変更コントローラー：IESGリファレンス：RFC 8055、RFC 3261
Claim Name: sip_date Claim Description: SIP Date header field value Change Controller: IESG Reference: RFC 8055, RFC 3261
クレーム名：sip_dateクレーム説明：SIP日付ヘッダーフィールド値変更コントローラー：IESGリファレンス：RFC 8055、RFC 3261
Claim Name: sip_callid Claim Description: SIP Call-Id header field value Change Controller: IESG Reference: RFC 8055, RFC 3261
クレーム名：sip_callidクレーム説明：SIP Call-Idヘッダーフィールド値変更コントローラー：IESGリファレンス：RFC 8055、RFC 3261
Claim Name: sip_cseq_num Claim Description: SIP CSeq numeric header field parameter value Change Controller: IESG Reference: RFC 8055, RFC 3261
クレーム名：sip_cseq_numクレーム説明：SIP CSeq数値ヘッダーフィールドパラメーター値変更コントローラー：IESGリファレンス：RFC 8055、RFC 3261
Claim Name: sip_via_branch Claim Description: SIP Via branch header field parameter value Change Controller: IESG Reference: RFC 8055, RFC 3261
クレーム名：sip_via_branchクレーム説明：SIP Viaブランチヘッダーフィールドのパラメーター値変更コントローラー：IESGリファレンス：RFC 8055、RFC 3261
As the 'received-realm' Via header field parameter can be used to trigger applications, it is important to ensure that the parameter has not been added to the SIP message by an unauthorized SIP entity.
'received-realm' Viaヘッダーフィールドパラメーターはアプリケーションをトリガーするために使用できるため、パラメーターが無許可のSIPエンティティによってSIPメッセージに追加されていないことを確認することが重要です。
The 'received-realm' Via header field parameter is inserted, signed, verified, and consumed within an operator network. The operator MUST discard parameters received from another network, and the parameter MUST only be inserted by SIP entities that are able to verify from which adjacent upstream network a SIP request is received.
'received-realm' Viaヘッダーフィールドパラメーターは、オペレーターネットワーク内で挿入、署名、検証、および消費されます。オペレーターは別のネットワークから受信したパラメーターを破棄する必要があり、パラメーターはSIP要求が受信された隣接する上流ネットワークから検証できるSIPエンティティーによってのみ挿入される必要があります。
The operator also needs to take great care in ensuring that the key used to calculate the JWS Signature value is only known by the network entities signing and adding the JWS Signature to the 'received-realm' Via header field parameter of a SIP message and to network entities verifying and consuming the parameter value.
オペレーターは、JWS署名の値を計算するために使用されるキーが、ネットワークエンティティによってのみ認識され、JWS署名をSIPメッセージの「received-realm」経由ヘッダーフィールドパラメーターに追加することでのみ確実に認識されるように細心の注意を払う必要もあります。パラメータ値を検証および消費するネットワークエンティティ。
The operator MUST use a key management policy that protects against unauthorized access to the stored keys within nodes where the keys associated with the JWS Signature are stored and that protects against cryptoanalysis attacks using captured data sent on the wire.
オペレーターは、JWS署名に関連付けられたキーが保存されているノード内の保存されたキーへの不正アクセスから保護し、ワイヤーで送信されたキャプチャデータを使用した暗号分析攻撃から保護するキー管理ポリシーを使用する必要があります。
A SIP entity MUST NOT use the adjacent network information if there is a mismatch between the JWS Signature received in the SIP header field and the JWS Signature calculated by the receiving entity.
SIPヘッダーフィールドで受信したJWS署名と受信エンティティによって計算されたJWS署名の間に不一致がある場合、SIPエンティティは隣接ネットワーク情報を使用してはなりません（MUST NOT）。
Generic security considerations for JWS are defined in [RFC7515].
JWSの一般的なセキュリティの考慮事項は、[RFC7515]で定義されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.
[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<http://www.rfc-editor.org / info / rfc7515>。
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <http://www.rfc-editor.org/info/rfc7519>.
[RFC7519]ジョーンズ、M。、ブラッドリー、J.、N。崎村、「JSON Web Token（JWT）」、RFC 7519、DOI 10.17487 / RFC7519、2015年5月、<http://www.rfc-editor.org / info / rfc7519>。
[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <http://www.rfc-editor.org/info/rfc7638>.
[RFC7638]ジョーンズ、M。およびN.崎村、「JSON Web Key（JWK）Thumbprint」、RFC 7638、DOI 10.17487 / RFC7638、2015年9月、<http://www.rfc-editor.org/info/rfc7638> 。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>.
[RFC3968] Camarillo、G。、「セッション開始プロトコル（SIP）のインターネット割り当て番号機関（IANA）ヘッダーフィールドパラメータレジストリ」、BCP 98、RFC 3968、DOI 10.17487 / RFC3968、2004年12月、<http：// www.rfc-editor.org/info/rfc3968>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.
[RFC7518]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。
[TS.3GPP.23.228] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 14.1.0, September 2016, <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>.
[TS.3GPP.23.228] 3GPP、「IPマルチメディアサブシステム（IMS）;ステージ2」、3GPP TS 23.228 14.1.0、2016年9月、<http://www.3gpp.org/ftp/Specs/html-info/ 23228.htm>。
Acknowledgements
謝辞
Thanks to Adam Roach and Richard Barnes for providing comments and feedback on the document. Francis Dupoint performed the Gen-ART review.
ドキュメントに関するコメントとフィードバックを提供してくれたAdam RoachとRichard Barnesに感謝します。 Francis DupointがGen-ARTレビューを行いました。
Authors' Addresses
著者のアドレス
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
Email: christer.holmberg@ericsson.com
Yi Jiang China Mobile No.32 Xuanwumen West Street Beijing Xicheng District 100053 China
Y i Jiang China Mobile no.32 X u Press no door west street Beijing X I Cheng District 100053 China
Email: jiangyi@chinamobile.com