Internet Engineering Task Force (IETF) J. Hautakorpi, Ed.
Request for Comments: 5853 G. Camarillo
Category: Informational Ericsson
ISSN: 2070-1721 R. Penfield
Acme Packet
A. Hawrylyshen
Skype, Inc.
M. Bhatia
3CLogic
April 2010
Requirements from Session Initiation Protocol (SIP)
Session Border Control (SBC) Deployments
Abstract
抽象
This document describes functions implemented in Session Initiation Protocol (SIP) intermediaries known as Session Border Controllers (SBCs). The goal of this document is to describe the commonly provided functions of SBCs. A special focus is given to those practices that are viewed to be in conflict with SIP architectural principles. This document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.
この文書では、セッションボーダーコントローラー（SBCは）として知られているセッション開始プロトコル（SIP）の仲介で実現される機能について説明します。このドキュメントの目標は、SBCでの、一般的に提供される機能を記述することです。特別な焦点は、SIPアーキテクチャの原則と矛盾にあるとみなされるもの慣行に与えられます。この文書はまた、プロトコル要件を特定し、これらの要件は、既存の仕様によって満たされるか、追加的な標準化作業が必要な場合かどうかを確認するために、これらの機能や慣行の利用につながっているネットワークオペレータの基礎となる要件を探ります。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5853.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5853で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
2. Background on SBCs ..............................................4
2.1. Peering Scenario ...........................................6
2.2. Access Scenario ............................................6
3. Functions of SBCs ...............................................8
3.1. Topology Hiding ............................................8
3.1.1. General Information and Requirements ................8
3.1.2. Architectural Issues ................................9
3.1.3. Example .............................................9
3.2. Media Traffic Management ..................................11
3.2.1. General Information and Requirements ...............11
3.2.2. Architectural Issues ...............................12
3.2.3. Example ............................................13
3.3. Fixing Capability Mismatches ..............................14
3.3.1. General Information and Requirements ...............14
3.3.2. Architectural Issues ...............................14
3.3.3. Example ............................................15
3.4. Maintaining SIP-Related NAT Bindings ......................15
3.4.1. General Information and Requirements ...............15
3.4.2. Architectural Issues ...............................16
3.4.3. Example ............................................17
3.5. Access Control ............................................18
3.5.1. General Information and Requirements ...............18
3.5.2. Architectural Issues ...............................19
3.5.3. Example ............................................19
3.6. Protocol Repair ...........................................20
3.6.1. General Information and Requirements ...............20
3.6.2. Architectural Issues ...............................21
3.6.3. Examples ...........................................21
3.7. Media Encryption ..........................................21
3.7.1. General Information and Requirements ...............21
3.7.2. Architectural Issues ...............................22
3.7.3. Example ............................................22
4. Derived Requirements for Future SIP Standardization Work .......23
5. Security Considerations ........................................23
6. Acknowledgements ...............................................24
7. References .....................................................25
7.1. Normative References ......................................25
7.2. Informative References ....................................25
In the past few years, there has been a rapid adoption of the Session Initiation Protocol (SIP) [1] and deployment of SIP-based communications networks. This has often outpaced the development and implementation of protocol specifications to meet network operator requirements. This has led to the development of proprietary solutions. Often, these proprietary solutions are implemented in network intermediaries known in the marketplace as Session Border Controllers (SBCs) because they typically are deployed at the border between two networks. The reason for this is that network policies are typically enforced at the edge of the network.
過去数年間では、セッション開始プロトコル（SIP）SIPベースの通信ネットワークの[1]と展開の急速な普及がありました。これは、多くの場合、ネットワークオペレータの要件を満たすために、プロトコル仕様の開発と実装を上回っています。これは、独自のソリューションの開発につながっています。それらは一般的に2つのネットワーク間の境界に配備されているので、多くの場合、これらの独自のソリューションは、セッションボーダーコントローラー（SBCは）として市場で知られているネットワークの仲介で実現されています。この理由は、ネットワークポリシーは、通常はネットワークのエッジに施行されていることです。
Even though many SBCs currently behave in ways that can break end-to-end security and impact feature negotiations, there is clearly a market for them. Network operators need many of the features current SBCs provide, and often there are no standard mechanisms available to provide them.
多くのSBCは現在、エンドツーエンドのセキュリティを破ると機能の交渉に影響を与えることができる方法で動作しても、それらの市場は明らかに存在します。ネットワークオペレータは、現在のSBCが提供する機能の多くを必要とし、多くの場合、それらを提供するために利用可能な標準メカニズムはありません。
The purpose of this document is to describe functions implemented in SBCs. A special focus is given to those practices that conflict with SIP architectural principles in some way. The document also explores the underlying requirements of network operators that have led to the use of these functions and practices in order to identify protocol requirements and determine whether those requirements are satisfied by existing specifications or if additional standards work is required.
このドキュメントの目的はのSBCに実装された機能を記述することです。特別な焦点は、そのいくつかの方法で、SIP建築原則に抵触これらの慣行に与えられています。文書はまた、プロトコル要件を特定し、これらの要件は、既存の仕様によって満たされるか、追加的な標準化作業が必要な場合かどうかを確認するために、これらの機能や慣行の利用につながっているネットワークオペレータの基礎となる要件を探ります。
The term SBC is relatively non-specific, since it is not standardized or defined anywhere. Nodes that may be referred to as SBCs but do not implement SIP are outside the scope of this document.
それが標準化やどこにも定義されていないので、用語SBCは、比較的非特異的です。 SBCと呼ぶことができるが、SIPを実装していないノードは、この文書の範囲外です。
SBCs usually sit between two service provider networks in a peering environment, or between an access network and a backbone network to provide service to residential and/or enterprise customers. They provide a variety of functions to enable or enhance session-based multi-media services (e.g., Voice over IP). These functions include: a) perimeter defense (access control, topology hiding, and denial-of-service prevention and detection); b) functionality not available in the endpoints (NAT traversal, protocol interworking or repair); and c) traffic management (media monitoring and Quality of Service (QoS)). Some of these functions may also get integrated into other SIP elements (like pre-paid platforms, Third Generation Partnership Project (3GPP) Proxy CSCF (P-CSCF) [6], 3GPP I-CSCF, etc.).
SBCは通常、住宅および/または企業の顧客にサービスを提供するために、ピアリング環境で、またはアクセスネットワークとバックボーンネットワーク間の2つのサービスプロバイダーのネットワークの間に座ります。彼らは、セッションベースのマルチメディアサービス（IPオーバー例えば、音声）を有効または増強する様々な機能を提供します。これらの機能は、a）防御境界（アクセス制御、トポロジ隠蔽、及びサービス拒否防止および検出）。 B）エンドポイント（NATトラバーサル、プロトコルインターワーキングまたは修復）で利用できない機能。そしてc）トラフィック管理（メディア・モニタリング・サービスの品質（QoS））。これらの機能のいくつかは、他のSIP要素に統合されるかもしれません（プリペイド式のプラットフォームのように、第三世代パートナーシッププロジェクト（3GPP）プロキシCSCF（P-CSCF）[6]、3GPP I-CSCF、など）。
SIP-based SBCs typically handle both signaling and media and can implement behavior that is equivalent to a "privacy service" (as described in [2]) performing both Header Privacy and Session Privacy). SBCs often modify certain SIP headers and message bodies that proxies are not allowed to modify. Consequently, they are, by definition, B2BUAs (Back-to-Back User Agents). The transparency of these B2BUAs varies depending on the functions they perform. For example, some SBCs modify the session description carried in the message and insert a Record-Route entry. Other SBCs replace the value of the Contact header field with the SBCs' address and generate a new Call-ID and new To and From tags.
SIPベースのSBCは、典型的には、（[2]に記載のように）ヘッダプライバシーおよびセッションプライバシーの両方を行うシグナリングおよびメディアの両方を処理し、「プライバシーサービス」に相当する動作を実装することができます）。 SBCは、多くの場合、プロキシが変更を許可されていない特定のSIPヘッダとメッセージ本文を変更します。その結果、彼らは、定義、型B2BUA（バックツーバックユーザエージェント）によって、あります。これらの型B2BUAの透明性は、彼らが実行する機能によって異なります。例えば、いくつかのSBCは、メッセージで運ばれるセッション記述を変更し、レコードルートエントリを挿入します。その他のSBCは、SBCでアドレスでContactヘッダーフィールドの値を交換し、新しいコールIDとタグにしてから、新しいを生成します。
+-----------------+
| SBC |
[signaling] | +-----------+ |
<------------|->| signaling |<-|---------->
outer | +-----------+ | inner
network | | | network
| +-----------+ |
<------------|->| media |<-|---------->
[media] | +-----------+ |
+-----------------+
Figure 1: SBC Architecture
図1：SBCアーキテクチャ
Figure 1 shows the logical architecture of an SBC, which includes a signaling and a media component. In this document, the terms outer and inner network are used for describing these two networks. An SBC is logically associated with the inner network, and it typically provides functions such as controlling and protecting access to the inner network from the outer network. The SBC itself is configured and managed by the organization operating the inner network.
図1は、シグナリングおよびメディアコンポーネントを含むSBCの論理アーキテクチャを示しています。この文書では、ネットワークの外側および内側の用語は、これら2つのネットワークを記述するために使用されます。 SBCは、論理的に内部ネットワークに関連付けられ、それは典型的には、外のネットワークから内部ネットワークへのアクセスを制御し、保護などの機能を提供しています。 SBC自体が設定され、内部ネットワークを運営する組織によって管理されています。
In some scenarios, SBCs operate with users' (implicit or explicit) consent; while in others, they operate without users' consent (this latter case can potentially cause problems). For example, if an SBC in the same administrative domain as a set of enterprise users performs topology hiding (see Section 3.1), the enterprise users can choose to route their SIP messages through it. If they choose to route through the SBC, then the SBC can be seen as having the users' implicit consent. Another example is a scenario where a service provider has broken gateways and it deploys an SBC in front of them for protocol repair reasons (see Section 3.6). Users can choose to configure the SBC as their gateway and, so, the SBC can be seen as having the users' implicit consent.
いくつかのシナリオでは、SBCでは、ユーザーの（暗黙的または明示的な）同意を得て動作します。他の人に、彼らは、ユーザーの同意なしに動作しながら、（この後者の場合には、潜在的な問題を引き起こす可能性があります）。エンタープライズユーザのセットと同じ管理ドメイン内のSBCは、トポロジー隠蔽（セクション3.1を参照）を行う場合、例えば、企業ユーザがそれを介してルーティングするために、それらのSIPメッセージを選択することができます。彼らはSBC経由でルーティングするように選択した場合、SBCは、ユーザーの暗黙の同意を有していると見ることができます。別の例では、サービスプロバイダがゲートウェイを壊れていると、それは（セクション3.6を参照）プロトコル修復の理由から、それらの前にSBCを展開シナリオです。ユーザーは、自分のゲートウェイとしてSBCを設定することを選択することができますと、そう、SBCは、ユーザーの暗黙の同意を有していると見ることができます。
A typical peering scenario involves two network operators who exchange traffic with each other. An example peering scenario is illustrated in Figure 2. An originating gateway (GW-A1) in Operator A's network sends an INVITE that is routed to the SBC in Operator B's network. Then, the SBC forward it to the softswitch (SS-B). The softswitch responds with a redirect (3xx) message back to the SBC that points to the appropriate terminating gateway (GW-B1) in Operator B's network. If Operator B does not have an SBC, the redirect message would go to the Operator A's originating gateway. After receiving the redirect message, the SBC sends the INVITE to the terminating gateway.
典型的なピアリングシナリオは、相互にトラフィックを交換2ネットワークオペレータを必要とします。例えばピアリングシナリオが図2に示されているオペレータAのネットワーク内の発信ゲートウェイ（GW-A1）は、そのオペレータBのネットワーク内のSBCにルーティングされるINVITEを送信します。その後、SBCは、ソフトスイッチ（SS-B）に転送します。ソフトスイッチは、オペレータBのネットワーク内の適切な終端ゲートウェイ（GW-B1）を指すバックSBCへのリダイレクト（3XX）メッセージで応答します。オペレータBは、SBCを持っていない場合は、リダイレクトメッセージは、オペレータAの発信ゲートウェイに行くだろう。リダイレクトメッセージを受信した後、SBCは、終端ゲートウェイにINVITEを送信します。
Operator A . Operator B
.
. 2) INVITE
+-----+ . /--------------->+-----+
|SS-A | . / 3) 3xx (redir.) |SS-B |
+-----+ . / /---------------+-----+
. / /
+-----+ 1) INVITE +-----+--/ / +-----+
|GW-A1|---------------->| SBC |<---/ 4) INVITE |GW-B1|
+-----+ +-----+---------------------->+-----+
.
+-----+ . +-----+
|GW-A2| . |GW-B2|
+-----+ . +-----+
Figure 2: Peering with SBC
図2：SBCとのピアリング
From the SBC's perspective the Operator A is the outer network, and Operator B is the inner network. Operator B can use the SBC, for example, to control access to its network, protect its gateways and softswitches from unauthorized use and denial-of-service (DoS) attacks, and monitor the signaling and media traffic. It also simplifies network management by minimizing the number of ACL (Access Control List) entries in the gateways. The gateways do not need to be exposed to the peer network, and they can restrict access (both media and signaling) to the SBCs. The SBC helps ensure that only media from sessions the SBC authorizes will reach the gateway.
SBCの観点からオペレータAは外側のネットワークであり、オペレータBは、内部ネットワークです。オペレータBは、そのネットワークへのアクセスを制御するために、例えば、SBCを使用し、不正使用やサービス拒否（DoS）攻撃からそのゲートウェイとソフトスイッチを保護し、シグナリングおよびメディアトラフィックを監視することができます。それはまた、ゲートウェイにACL（アクセス制御リスト）エントリの数を最小化することによって、ネットワーク管理を簡素化します。ゲートウェイは、ピアネットワークに公開する必要はありません、そして、彼らはのSBCに（メディアとシグナリングの両方）のアクセスを制限することができます。 SBCは、SBCは、ゲートウェイに到達します許可のセッションからそれだけメディアを確保することができます。
In an access scenario, presented in Figure 3, the SBC is placed at the border between the access network (outer network) and the operator's network (inner network) to control access to the operator's network, protect its components (media servers, application servers, gateways, etc.) from unauthorized use and DoS attacks, and monitor the signaling and media traffic. Also, since the SBC is call stateful, it may provide access control functions to prevent over-subscription of the access links. Endpoints are configured with the SBC as their outbound proxy address. The SBC routes requests to one or more proxies in the operator network.
図3に示すアクセスシナリオでは、SBCは、その構成要素（メディアサーバー、アプリケーション・サーバーを保護する、オペレータのネットワークへのアクセスを制御するアクセスネットワーク（外側のネットワーク）とオペレータのネットワーク（内部ネットワーク）との間の境界に配置されています不正使用やDoS攻撃から、ゲートウェイなど）、およびシグナリングおよびメディアトラフィックを監視します。 SBCは、コールステートフルであることからも、それはアクセスリンクのオーバーサブスクリプションを防ぐために、アクセス制御機能を提供することができます。エンドポイントは、そのアウトバウンドプロキシアドレスとしてSBCで構成されています。 SBCルートは、オペレータのネットワーク内の1つまたは複数のプロキシに要求します。
Access Network Operator Network
アクセスネットワークオペレータネットワーク
+-----+
| UA1 |<---------\
+-----+ \
\
+-----+ \------->+-----+ +-------+
| UA2 |<-------------------->| SBC |<----->| proxy |<-- -
+-----+ /--->+-----+ +-------+
/
+-----+ +-----+ /
| UA3 +---+ NAT |<---/
+-----+ +-----+
Figure 3: Access Scenario with SBC
図3：SBCとのアクセスのシナリオ
The SBC may be hosted in the access network (e.g., this is common when the access network is an enterprise network), or in the operator network (e.g., this is common when the access network is a residential or small business network). Despite where the SBC is hosted, it is managed by the organization maintaining the operator network.
SBCは（アクセスネットワークは、住宅や小規模ビジネスネットワークである場合、例えば、これは一般的である）、アクセスネットワーク（アクセスネットワークは、企業ネットワークである場合、例えば、これは一般的である）、またはオペレータネットワークでホストされてもよいです。 SBCがホストされている場所にもかかわらず、それは、オペレータのネットワークを維持する組織によって管理されています。
Some endpoints may be behind enterprise or residential NATs. In cases where the access network is a private network, the SBC is a NAT for all traffic. It is noteworthy that SIP traffic may have to traverse more than one NAT. The proxy usually does authentication and/or authorization for registrations and outbound calls. The SBC modifies the REGISTER request so that subsequent requests to the registered address-of-record are routed to the SBC. This is done either with a Path header field [3] or by modifying the Contact to point at the SBC.
いくつかのエンドポイントは、企業や住宅のNATの背後にあります。アクセスネットワークは、プライベートネットワークであるケースでは、SBCは、すべてのトラフィックのためのNATです。 SIPトラフィックが複数のNATを通過する必要があることは注目すべきです。プロキシは、通常の登録およびアウトバウンドコールのための認証および/または認可を行います。登録されたアドレスのレコードに後続の要求は、SBCにルーティングされるように、SBCは、REGISTERリクエストを変更します。これは、パスヘッダフィールド[3]またはSBCを指すように連絡先を変更することのいずれかによって行われます。
The scenario presented in this section is a general one, and it applies also to other similar settings. One example from a similar setting is the one where an access network is the open internet, and the operator network is the network of a SIP service provider.
このセクションで提示シナリオは一般的なものであり、それは他の同様の設定にも適用されます。同様の設定の一例は、アクセスネットワークがオープンインターネットであり、オペレータネットワークは、SIPサービスプロバイダのネットワークであるものです。
This section lists those functions that are used in SBC deployments in current communication networks. Each subsection describes a particular function or feature, the operators' requirements for having it, explanation of any impact to the end-to-end SIP architecture, and a concrete implementation example. Each section also discusses potential concerns specific to that particular implementation technique. Suggestions for alternative implementation techniques that may be more architecturally compatible with SIP are outside the scope of this document.
このセクションでは、現在の通信ネットワークにおけるSBCの展開で使用されているこれらの機能を示しています。各サブセクションは、特定の機能または機能を記述し、それを持つため、オペレータの要求、エンドツーエンドのSIPアーキテクチャへの影響の説明、および具体的な実施例を示します。各セクションは、その特定の実装技術に固有の潜在的な懸念事項について説明します。 SIPとよりアーキテクチャ互換性がある代替実装技術のための提案は、この文書の範囲外です。
All the examples given in this section are simplified; only the relevant header lines from SIP and SDP (Session Description Protocol) [7] messages are displayed.
このセクションに記載されたすべての実施例が簡略化されます。 SIP及びSDP（セッション記述プロトコル）からのみ関連するヘッダー行は、[7]のメッセージが表示されています。
Topology hiding consists of limiting the amount of topology information given to external parties. Operators have a requirement for this functionality because they do not want the IP addresses of their equipment (proxies, gateways, application servers, etc.) to be exposed to outside parties. This may be because they do not want to expose their equipment to DoS attacks, they may use other carriers for certain traffic and do not want their customers to be aware of it, or they may want to hide their internal network architecture from competitors or partners. In some environments, the operator's customers may wish to hide the addresses of their equipment or the SIP messages may contain private, non-routable addresses.
トポロジ隠蔽は、外部の第三者に与えられたトポロジー情報の量を制限で構成されています。彼らは彼らの機器のIPアドレス（プロキシ、ゲートウェイ、アプリケーションサーバなど）が外部の第三者にさらされたくないので、オペレータは、この機能のための要件があります。彼らはDoS攻撃に、自社の機器を公開したくないので、これは、かもしれ彼らは、特定のトラフィックのために他のキャリアを使用することができますし、顧客がそれを認識することにしたくない、またはそれらは、競合他社やパートナーから社内ネットワークアーキテクチャを非表示にすること。一部の環境では、オペレータの顧客は、民間、非ルーティング可能なアドレスを含むことができ、自社の機器やSIPメッセージのアドレスを非表示にすることもできます。
The most common form of topology hiding is the application of header privacy (see Section 5.1 of [2]), which involves stripping Via and Record-Route headers, replacing the Contact header, and even changing Call-IDs. However, in deployments that use IP addresses instead of domain names in headers that cannot be removed (e.g., From and To headers), the SBC may replace these IP addresses with its own IP address or domain name.
トポロジー隠蔽の最も一般的な形態は、ビアとレコードルートヘッダを除去Contactヘッダを置き換え、さらにはコールIDを変更することを含む、（[2]のセクション5.1を参照）ヘッダプライバシーの適用です。しかし、IP（例えば、FromおよびToヘッダを）削除することはできません、ヘッダー内のドメイン名ではなくアドレスを使用する展開では、SBCは、独自のIPアドレスまたはドメイン名を使用してこれらのIPアドレスを交換することができます。
For a reference, there are also other ways of hiding topology information than inserting an intermediary, like an SBC, to the signaling path. One of the ways is the UA-driven privacy mechanism [8], where the UA can facilitate the concealment of topology information.
参考のために、シグナル伝達経路に、SBCのような中間体を挿入するよりも、トポロジ情報を隠蔽する他の方法もあります。方法の一つは、UAは、トポロジ情報の隠蔽を容易にすることができるUA-駆動プライバシーメカニズム[8]です。
Performing topology hiding, as described above, by SBCs that do not have the users' consent presents some issues. This functionality is based on a hop-by-hop trust model as opposed to an end-to-end trust model. The messages are modified without the subscriber's consent and could potentially modify or remove information about the user's privacy, security requirements, and higher-layer applications that are communicated end-to-end using SIP. Neither user agent in an end-to-end call has any way to distinguish the SBC actions from a man-in-the-middle (MITM) attack.
利用者の同意を持っていないのSBCにより、前述したように、トポロジ隠蔽を実行すると、いくつかの問題を提示します。この機能は、エンドツーエンドの信頼モデルとは対照的に、ホップバイホップ信頼モデルに基づいています。メッセージは、加入者の同意なしに変更され、潜在的に、ユーザーのプライバシー、セキュリティ要件に関する情報を変更または削除することができ、およびSIPを使用して、エンドツーエンドの通信され、上位層のアプリケーションに最適です。エンド・ツー・エンドの呼び出しでもないユーザエージェントは、のman-in-the-middle（MITM）攻撃からSBCアクションを区別するためにどのような方法があります。
The topology hiding function does not work well with Authenticated Identity Management [4] in scenarios where the SBC does not have any kind of consent from the users. The Authenticated Identity Management mechanism is based on a hash value that is calculated from parts of From, To, Call-ID, CSeq, Date, and Contact header fields plus from the whole message body. If the authentication service is not provided by the SBC itself, the modification of the aforementioned header fields and the message body is in violation of [4]. Some forms of topology hiding are in violation, because they are, e.g., replacing the Contact header of a SIP message.
トポロジ隠蔽機能は、SBCは、ユーザーからの同意のいずれかの種類を持っていないシナリオで認証されたアイデンティティ管理[4]とうまく動作しません。認証されたアイデンティティ管理機構は、コールID、のCSeq、日付、およびContactヘッダーフィールドに加えて、全体のメッセージ本体から、からの部分から計算されたハッシュ値に基づいています。認証サービスは、SBC自体によって提供されていない場合は、前述のヘッダフィールドと、メッセージボディの変形は、[4]に違反しています。それらがあるため、トポロジ隠蔽のいくつかの形態は、SIPメッセージのContactヘッダを置換、例えば、違反しています。
The current way of implementing topology hiding consists of having an SBC act as a B2BUA (Back-to-Back User Agent) and remove all traces of topology information (e.g., Via and Record-Route entries) from outgoing messages.
トポロジー隠蔽を実現する現在の方法は、B2BUA（バックツーバックユーザエージェント）としてSBC作用を有するから成り、送信メッセージからトポロジー情報（例えば、ビアおよびレコードルートエントリ）のすべての痕跡を除去します。
Imagine the following example scenario: the SBC (p4.domain.example.com) receives an INVITE request from the inner network, which in this case is an operator network. The received SIP message is shown in Figure 4.
次の例のシナリオを想像：SBC（p4.domain.example.com）は、この場合にはオペレータネットワークである内部ネットワークからINVITE要求を受信します。受信されたSIPメッセージは、図4に示されています。
INVITE sip:callee@u2.domain.example.com SIP/2.0 Via: SIP/2.0/UDP p3.middle.example.com;branch=z9hG4bK48jq9w174131.1 Via: SIP/2.0/UDP p2.example.com;branch=z9hG4bK18an6i9234172.1 Via: SIP/2.0/UDP p1.example.com;branch=z9hG4bK39bn2e5239289.1 Via: SIP/2.0/UDP u1.example.com;branch=z9hG4bK92fj4u7283927.1 Contact: sip:caller@u1.example.com Record-Route: <sip:p3.middle.example.com;lr> Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p1.example.com;lr>
SIP INVITE：callee@u2.domain.example.comをSIP / 2.0経由：SIP / 2.0 / UDP p3.middle.example.com;ブランチ= z9hG4bK48jq9w174131.1経由：SIP / 2.0 / UDP p2.example.com;ブランチ= z9hG4bK18an6i9234172.1経由：SIP / 2.0 / UDP p1.example.com;ブランチ= z9hG4bK39bn2e5239289.1経由：SIP / 2.0 / UDP u1.example.com;ブランチ= z9hG4bK92fj4u7283927.1連絡先：SIP：caller@u1.example.comレコードルート<SIP：p3.middle.example.com; LR>レコードルート<SIP：p2.example.com; LR>レコードルート<SIP：p1.example.com; LR>
Figure 4: INVITE Request Prior to Topology Hiding
図4：トポロジ隠蔽する前INVITEリクエスト
Then, the SBC performs a topology hiding function. In this scenario, the SBC removes and stores all existing Via and Record-Route headers, and then inserts Via and Record-Route header fields with its own SIP URI. After the topology hiding function, the message could appear as shown in Figure 5.
その後、SBCは、トポロジ隠蔽機能を実行します。このシナリオでは、SBCは削除され、格納すべての既存のViaおよびRecord-Routeヘッダを、その後、独自のSIP URIとビアとのRecord-Routeヘッダーフィールドを挿入します。図5に示すように、トポロジ隠蔽機能の後に、メッセージが表示される可能性があります。
INVITE sip:callee@u2.domain.example.com SIP/2.0 Via: SIP/2.0/UDP p4.domain.example.com;branch=z9hG4bK92es3w230129.1 Contact: sip:caller@u1.example.com Record-Route: <sip:p4.domain.example.com;lr>
callee@u2.domain.example.com SIP / 2.0経由：SIPのINVITE SIP / 2.0 / UDP p4.domain.example.com;ブランチ= z9hG4bK92es3w230129.1連絡先：SIP：caller@u1.example.com録音-ルート： <一口：p4.domain.example.com; LR>
Figure 5: INVITE Request after Topology Hiding
図5：トポロジ隠蔽後にINVITEリクエスト
Like a regular proxy server that inserts a Record-Route entry, the SBC handles every single message of a given SIP dialog. If the SBC loses state (e.g., SBC restarts for some reason), it may not be able to route messages properly (note: some SBCs preserve the state information also on restart). For example, if the SBC removes Via entries from a request and then restarts, thus losing state; the SBC may not be able to route responses to that request, depending on the information that was lost when the SBC restarted.
レコード・ルートエントリを挿入し、通常のプロキシサーバのように、SBCは、与えられたSIPダイアログのすべての単一のメッセージを処理します。 SBCは、状態を失った場合（例えば、SBCが何らかの理由で再起動します）、それが適切にメッセージをルーティングするために（：一部のSBCは、再起動時にも、状態情報を保存するノート）できないことがあります。例えば、SBCは、要求からエントリを介して除去した後に再起動し、このような状態を失う場合、 SBCは、SBCが再起動時に失われた情報に応じて、その要求にルート応答にできないことがあります。
This is only one example of topology hiding. Besides topology hiding (i.e., information related to the network elements is being hidden), SBCs may also do identity hiding (i.e., information related to identity of subscribers is being hidden). While performing identity hiding, SBCs may modify Contact header field values and other header fields containing identity information. The header fields containing identity information is listed in Section 4.1 of [2]. Since the publication of [2], the following header fields containing identity information have been defined: "P-Asserted-Identity", "Referred-By", "Identity", and "Identity-Info".
これは、トポロジ隠蔽の一例に過ぎません。トポロジー隠蔽（ネットワーク要素に関連する、すなわち、情報が隠されている）に加えて、のSBCは、また、同一の隠蔽（加入者のアイデンティティに関連する、すなわち、情報が隠されている）を実行してもよいです。アイデンティティ隠蔽を行いながら、のSBCは、識別情報を含むContactヘッダフィールド値および他のヘッダフィールドを変更することができます。識別情報を含むヘッダフィールドは、[2]のセクション4.1に記載されています。 「呼ぶバイ」、「同一性」、「P-アサート - アイデンティティ」、および「アイデンティティ-INFO」の出版以来、[2]、識別情報を含む次のヘッダーフィールドが定義されています。
Media traffic management is the function of controlling media traffic. Network operators may require this functionality in order to control the traffic being carried on their network on behalf of their subscribers. Traffic management helps the creation of different kinds of billing models (e.g., video telephony can be priced differently than voice-only calls) and it also makes it possible for operators to enforce the usage of selected codecs.
メディアトラフィック管理は、メディアトラフィックを制御する機能です。ネットワークオペレータは、加入者に代わって、ネットワーク上で実行されるトラフィックを制御するために、この機能が必要な場合があります。トラフィック管理は、課金モデルの異なる種類の作成に役立ちます（例えば、ビデオ電話が異なり、音声のみの通話よりも価格することができます）、それはまたそれが可能事業者が選択されたコーデックの使用を強制できるようになります。
One of the use cases for media traffic management is the implementation of intercept capabilities that are required to support audit or legal obligations. It is noteworthy that the legal obligations mainly apply to operators providing voice services, and those operators typically have infrastructure (e.g., SIP proxies acting as B2BUAs) for providing intercept capabilities even without SBCs.
メディアトラフィック管理のためのユースケースの一つは、監査や法的義務をサポートするために必要なインターセプト機能の実装です。それは法的義務は主に音声サービスを提供する事業者に適用されることに注目すべきである、とこれらの事業者は、一般的にインフラを持っている（例えば、型B2BUAとして動作するSIPプロキシ）でもSBCでなくてインターセプト機能を提供します。
Since the media path is independent of the signaling path, the media may not traverse through the operator's network unless the SBC modifies the session description. By modifying the session description, the SBC can force the media to be sent through a media relay which may be co-located with the SBC. This kind of traffic management can be done, for example, to ensure a certain QoS level, or to ensure that subscribers are using only allowed codecs. It is noteworthy that the SBCs do not have direct ties to routing topology and they do not, for example, change bandwidth reservations on Traffic Engineering (TE) tunnels, nor do they have direct interaction with routing protocol.
メディアパスは、シグナリングパスとは独立しているので、SBCは、セッション記述を変更しない限り、メディアは、オペレータのネットワークを横断しないことができます。セッション記述を変更することによって、SBCは、SBCと同じ場所に配置することができるメディアリレーを介して送信されるメディアを強制することができます。トラフィック管理のこの種は、特定のQoSレベルを確保するために、または加入者のみが許可されたコーデックを使用していることを確認するために、例えば、行うことができます。 SBCでは、ルーティングトポロジへの直接のつながりを持っていないと、そうではない、例えば、トラフィックエンジニアリング（TE）トンネル上の変更帯域幅の予約、また彼らは、ルーティングプロトコルとの直接的な相互作用を持っていないことは注目に値します。
Some operators do not want to manage the traffic, but only to monitor it to collect statistics and make sure that they are able to meet any business service level agreements with their subscribers and/or partners. The protocol techniques, from the SBC's viewpoint, needed for monitoring media traffic are the same as for managing media traffic.
いくつかの演算子は、トラフィックを管理する必要はありませんが、唯一の統計を収集し、彼らは彼らの加入者および/またはパートナーとのあらゆるビジネス・サービス・レベル・アグリーメントを満たすことができていることを確認するために、それを監視すること。メディアトラフィックを監視するために必要なSBCの視点からプロトコル技術は、メディアトラフィックを管理するためのと同じです。
SBCs on the media path are also capable of dealing with the "lost BYE" issue if either endpoint dies in the middle of the session. The SBC can detect that the media has stopped flowing and issue a BYE to both sides to clean up any state in other intermediate elements and the endpoints.
メディアパス上のSBCはまた、いずれかのエンドポイントがセッションの途中で死亡した場合、「失われたBYE」の問題に対処することができます。 SBCは、メディアが流れ停止したことを検出し、他の中間要素及びエンドポイントの任意の状態をクリーンアップするために両側にBYEを発行することができます。
One possible form of media traffic management is that SBCs terminate media streams and SIP dialogs by generating BYE requests. This kind of procedure can take place, for example, in a situation where the subscriber runs out of credits. Media management is needed to ensure that the subscriber cannot just ignore the BYE request generated by the SBC and continue its media sessions.
メディアトラフィック管理の一つの可能な形式は、のSBCはBYE要求を生成することによってメディアストリームとSIPダイアログを終了することです。手順のこの種は、加入者がクレジットを使い果たしたような状況で、例えば、場所を取ることができます。メディア管理は、加入者がちょうどSBCによって生成されたBYE要求を無視し、そのメディアセッションを継続することができないことを保証するために必要とされます。
Implementing traffic management in this manner requires the SBC to access and modify the session descriptions (i.e., offers and answers) exchanged between the user agents. Consequently, this approach does not work if user agents encrypt or integrity-protect their message bodies end-to-end. Again, messages are modified without subscriber consent, and user agents do not have any way to distinguish the SBC actions from an attack by a MITM. Furthermore, this is in violation of Authenticated Identity Management [4], see Section 3.1.2.
このように、トラフィック管理を実装するセッション記述（すなわち、オファーとアンサー）にアクセスし、変更するSBCを必要とするユーザー・エージェント間で交換。ユーザーエージェントは暗号化したり、メッセージ本文は、エンドツーエンドの完全性、保護あれば結果的に、このアプローチは動作しません。ここでも、メッセージは、加入者の同意なしに変更され、ユーザエージェントはMITMによる攻撃からSBCアクションを区別するためにどのような方法を持っていません。さらに、これは認証されたアイデンティティ管理に違反している[4]、セクション3.1.2を参照してください。
The insertion of a media relay can prevent "non-media" uses of the media path, for example, the media path key agreement. Sometimes this type of prevention is intentional, but it is not always necessary. For example, if an SBC is used just for enabling media monitoring, but not for interception.
メディアリレーの挿入は「非メディア」とは、例えば、メディアパスのメディアパス鍵合意を使用して防ぐことができます。時には、予防のこのタイプは意図的なものであるが、それは必ずしも必要ではありません。例えば、SBC場合なく傍受するため、単にメディア監視を可能にするために使用されます。
There are some possible issues related to the media relaying. If the media relaying is not done in the correct manner, it may break functions like Explicit Congestion Notification (ECN) and Path MTU Discovery (PMTUD), for example. The media relays easily break such IP and transport layer functionalities that rely on the correct handling of the protocol fields. Some especially sensitive fields are, for example, ECN and Type of Service (ToS) fields and the Don't Fragment (DF) bit.
メディア中継に関連するいくつかの可能性の問題があります。メディア中継が正しい方法で行われていない場合、それは、例えば、明示的輻輳通知（ECN）とパスMTU探索（PMTUD）、等の機能を破壊することができます。メディアリレーは簡単にプロトコルフィールドの正しい取り扱いに依存している、そのようなIPとトランスポート層の機能を破ります。いくつかの特に敏感な分野は、例えば、ECNとするToS（Type of Service）フィールドおよびフラグメント不可（DF）ビットです。
The way in which media traffic management functions impedes innovation. The reason for the impediment is that in many cases, SBCs need to be able to support new forms of communication (e.g., extensions to the SDP protocol) before new services can be put into use, which slows the adoption of new innovations.
でメディアトラフィック管理機能の方法は、技術革新を妨げます。障害の原因は、多くの場合、SBCでは、コミュニケーションの新しい形をサポートできるようにする必要があるということです（例えば、SDPプロトコルの拡張）新しいサービスの前には、新たな技術革新の採用を遅らせる使用、に入れることができます。
If an SBC directs many media streams through a central point in the network, it is likely to cause a significant amount of additional traffic to a path to that central point. This might create possible bottleneck in the path.
SBCは、ネットワークの中心点を通る多くのメディアストリームを指示した場合は、その中心点へのパスに追加トラフィックのかなりの量を引き起こす可能性があります。これは、パス内の可能なボトルネックを作成することがあります。
In this application, the SBC may originate messages that the user may not be able to authenticate as coming from the dialog peer or the SIP Registrar/Proxy.
このアプリケーションでは、SBCは、ユーザが対話ピアまたはSIPレジストラ/プロキシから来るとして認証することができない可能性がメッセージを発信することができます。
Traffic management may be performed in the following way: The SBC behaves as a B2BUA and inserts itself, or some other entity under the operator's control, in the media path. In practice, the SBC modifies the session descriptions carried in the SIP messages. As a result, the SBC receives media from one user agent and relays it to the other user agent and performs the identical operation with media traveling in the reverse direction.
トラフィック管理は、以下のように行われてもよい：SBCはB2BUAとして動作し、メディアパスに、オペレータの制御下で、それ自体、またはいくつかの他のエンティティを挿入します。実際には、SBCは、SIPメッセージで運ばれたセッション記述を変更します。結果として、SBCは、一人のユーザエージェントからメディアを受信し、他のユーザエージェントに中継し、逆方向に進行するメディアと同じ動作を行います。
As mentioned in Section 3.2.1, codec restriction is a form of traffic management. The SBC restricts the codec set negotiated in the offer/ answer exchange [5] between the user agents. After modifying the session descriptions, the SBC can check whether or not the media stream corresponds to what was negotiated in the offer/answer exchange. If it differs, the SBC has the ability to terminate the media stream or take other appropriate (configured) actions (e.g., raise an alarm).
3.2.1項で述べたように、コーデックの制限は、トラフィック管理の一形態です。 SBCは、ユーザエージェント間のオファー/アンサー交換[5]で交渉コーデックセットを制限します。セッション記述を変更した後、SBCは、メディアストリームがオファー/アンサー交換で交渉されたものに該当するかどうかを確認することができます。それが異なる場合、SBCは（例えば、アラームを上げる）メディアストリームを終了または他の適切な（設定）アクションを取る能力を持っています。
Consider the following example scenario: the SBC receives an INVITE request from the outer network, which in this case is an access network. The received SIP message contains the SDP session descriptor shown in Figure 6.
次の例のシナリオを考える：SBCは、この場合には、アクセスネットワーク外のネットワークからINVITE要求を受信します。受信したSIPメッセージは、図6に示したSDPセッション記述を含んでいます。
v=0 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 m=audio 49230 RTP/AVP 96 98 a=rtpmap:96 L8/8000 a=rtpmap:98 L16/16000/2
V = 0 0 =所有者2890844526 2890842807 IN IP4 192.0.2.4 C = IN IP4 192.0.2.4のM =オーディオ49230 RTP / AVP 96 98 = rtpmap：96 L8 / 8000 = rtpmap：98 L16 / 2分の16000
Figure 6: Request Prior to Media Management
図6：以前のメディア管理への要求
In this example, the SBC performs the media traffic management function by rewriting the "m=" line, and removing one "a=" line according to some (external) policy. Figure 7 shows the session description after the traffic management function.
この例では、SBCは、「M =」行を書き換え、およびいくつかの（外部の）ポリシーに従ってつの「A =」行を除去することによりメディアトラフィック管理機能を実行します。図7は、トラフィック管理機能の後にセッション記述を示しています。
v=0 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000
V = 0 0 =所有者2890844526 2890842807 IN IP4 192.0.2.4 C = IN IP4 192.0.2.4のM =オーディオ49230 RTP / AVP 96 = rtpmap：96 L8 / 8000
Figure 7: Request Body After Media Management
図7：メディア管理の後にリクエストボディ
Media traffic management has a problem where the SBC needs to understand the session description protocol and all extensions used by the user agents. This means that in order to use a new extension (e.g., an extension to implement a new service) or a new session description protocol, SBCs in the network may need to be upgraded in conjunction with the endpoints. It is noteworthy that a similar problem, but with header fields, applies to, for example, topology hiding function, see Section 3.1. Certain extensions that do not require active manipulation of the session descriptors to facilitate traffic management will be able to be deployed without upgrading existing SBCs, depending on the degree of transparency the SBC implementation affords. In cases requiring an SBC modification to support the new protocol features, the rate of service deployment may be affected.
メディアトラフィック管理は、SBCは、セッション記述プロトコルとユーザエージェントによって使用されるすべての拡張を理解する必要があるという問題がありました。これは、新しい拡張機能を使用するために、または新しいセッション記述プロトコル（例えば、拡張子が新しいサービスを実装する）ことを意味し、ネットワーク内のSBCは、エンドポイントに関連してアップグレードする必要があるかもしれません。これは注目すべきである同様の問題が、ヘッダフィールドとは、例えば、トポロジ隠蔽機能に適用されること、第3.1節を参照します。トラフィック管理を容易にするために、セッション記述子のアクティブな操作を必要としない特定の拡張子は、SBCの実装がもたらす透明性の程度に応じて、既存のSBCをアップグレードせずに展開することができるようになります。新しいプロトコル機能をサポートするために、SBCの修正を必要と場合には、サービス展開の速度が影響を受ける可能性があります。
SBCs fixing capability mismatches enable communications between user agents with different capabilities or extensions. For example, an SBC can enable a plain SIP [1] user agent to connect to a 3GPP network, or enable a connection between user agents that support different IP versions, different codecs, or that are in different address realms. Operators have a requirement and a strong motivation for performing capability mismatch fixing, so that they can provide transparent communication across different domains. In some cases, different SIP extensions or methods to implement the same SIP application (like monitoring session liveness, call history/diversion etc.) may also be interworked through the SBC.
能力不一致を固定のSBCは、異なる機能や拡張機能とのユーザエージェント間の通信を可能にします。例えば、SBCは、3GPPネットワークに接続するために普通SIP [1]ユーザエージェントを有効にする、または異なるIPバージョン、異なるアドレスレルムにある異なるコーデック、またはをサポートするユーザエージェントとの間の接続を可能にすることができます。それらは、異なるドメイン間で透過的な通信を提供することができるように、オペレータは、能力ミスマッチ固定を行うための要件と強い意欲を持っています。いくつかのケースでは、異なるSIP拡張または方法はまた、SBCを介してインターワーキングすることができる（等履歴/転用を呼び出し、セッションの生存性をモニタリングなど）は、同じSIPアプリケーションを実装します。
SBCs that are fixing capability mismatches do it by inserting a media element into the media path using the procedures described in Section 3.2. Therefore, these SBCs have the same concerns as SBCs performing traffic management: the SBC may modify SIP messages without consent from any of the user agents. This may break end-to-end security and application extensions negotiation.
能力不一致を固定しているのSBCは、セクション3.2に記載の手順を用いて、媒体経路内にメディア要素を挿入することによってそれを行います。したがって、これらのSBCは、トラフィック管理を行うのSBCと同じ懸念を持っている：SBCは、ユーザエージェントのいずれかからの同意なしにSIPメッセージを変更することがあります。これは、エンドツーエンドのセキュリティとアプリケーション拡張交渉を壊すことがあります。
The capability mismatch fixing is a fragile function in the long term. The number of incompatibilities built into various network elements is increasing the fragility and complexity over time. This might lead to a situation where SBCs need to be able to handle a large number of capability mismatches in parallel.
機能の不一致固定は、長期的に脆弱な機能です。様々なネットワーク要素に組み込まれた非互換性の数は、経時もろさおよび複雑さを増加しています。これは、SBCでは、並行して、能力ミスマッチの大規模な数を処理できるようにする必要がある状況につながる可能性があります。
Consider the following example scenario where the inner network is an access network using IPv4 and the outer network is using IPv6. The SBC receives an INVITE request with a session description from the access network:
内部ネットワークは、IPv4を使用して、アクセスネットワークであり、外側のネットワークがIPv6を使用している次の例のシナリオを考えます。 SBCは、アクセスネットワークからのセッション記述でINVITEリクエストを受信します。
INVITE sip:callee@ipv6.domain.example.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4 Contact: sip:caller@u1.example.com
callee@ipv6.domain.example.com SIP / 2.0経由：SIP / 2.0 / UDP 192.0.2.4お問い合わせ：SIP：caller@u1.example.com SIPのINVITE
v=0 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP4 192.0.2.4 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000
V = 0 0 =所有者2890844526 2890842807 IN IP4 192.0.2.4 C = IN IP4 192.0.2.4のM =オーディオ49230 RTP / AVP 96 = rtpmap：96 L8 / 8000
Figure 8: Request Prior to Capabilities Match
図8：前のCapabilitiesマッチする要求
Then, the SBC performs a capability mismatch fixing function. In this scenario, the SBC inserts Record-Route and Via headers and rewrites the "c=" line from the sessions descriptor. Figure 9 shows the request after the capability mismatch adjustment.
その後、SBCは、能力ミスマッチ固定機能を実行します。このシナリオでは、SBCは、レコードルートを介してヘッダを挿入し、セッション記述子から、「C =」行を書き換えます。図9は、能力のミスマッチ調整後の要求を示しています。
INVITE sip:callee@ipv6.domain.com SIP/2.0 Record-Route: <sip:[2001:DB8::801:201:2ff:fe94:8e10];lr> Via: SIP/2.0/UDP sip:[2001:DB8::801:201:2ff:fe94:8e10] Via: SIP/2.0/UDP 192.0.2.4 Contact: sip:caller@u1.example.com
callee@ipv6.domain.com SIP / 2.0レコードルート：SIP INVITE <一口：[2001：DB8 :: 801：201：2FF：fe94：8e10]; LR>のVia：SIP / 2.0 / UDP SIP：[2001 ：DB8 :: 801：201：2FF：fe94：8e10]ビア：SIP / 2.0 / UDP 192.0.2.4お問い合わせ：SIP：caller@u1.example.com
v=0 o=owner 2890844526 2890842807 IN IP4 192.0.2.4 c=IN IP6 2001:DB8::801:201:2ff:fe94:8e10 m=audio 49230 RTP/AVP 96 a=rtpmap:96 L8/8000
V = 0 0 = IP6 2001 IN IP4 192.0.2.4のCに所有者2890844526 2890842807 = DB8 :: 801：201：2FF：fe94：8e10 M =オーディオ49230 RTP / AVP 96 = rtpmap：/ 8000 96 L8
Figure 9: Request after Capability Match
図9：能力試合後のリクエスト
This message is then sent by the SBC to the onward IPv6 network.
このメッセージは、その後、以降IPv6ネットワークにSBCによって送信されます。
NAT traversal in this instance refers to the specific message modifications required to assist a user agent in maintaining SIP and media connectivity when there is a NAT device located between a user agent and a proxy/registrar and, possibly, any other user agent. The primary purpose of NAT traversal function is to keep up a control connection to user agents behind NATs. This can, for example, be achieved by generating periodic network traffic that keeps bindings in NATs alive. SBCs' NAT traversal function is required in scenarios where the NAT is outside the SBC (i.e., not in cases where SBC itself acts as a NAT).
この場合のNATトラバーサルは、ユーザエージェントとプロキシ/レジストラと、おそらく、他のユーザエージェントとの間に位置するNATデバイスがある場合、SIPおよびメディア接続を維持する上でユーザエージェントを支援するために必要な特定のメッセージの変更を指します。 NATトラバーサル機能の主な目的は、NATの背後にあるユーザエージェントへの制御接続を維持することです。これは、例えば、NATの中のバインディングが生き続けて定期的なネットワークトラフィックを生成することによって達成することができます。 SBC NATトラバーサル機能は、NATは、SBC（即ち、ケースにSBC自体がNATとして作用しない）の外にあるシナリオで必要とされます。
An SBC performing a NAT (Network Address Translator) traversal function for a user agent behind a NAT sits between the user agent and the registrar of the domain. NATs are widely deployed in various access networks today, so operators have a requirement to support it. When the registrar receives a REGISTER request from the user agent and responds with a 200 (OK) response, the SBC modifies such a response decreasing the validity of the registration (i.e., the registration expires sooner). This forces the user agent to send a new REGISTER to refresh the registration sooner that it would have done on receiving the original response from the registrar. The REGISTER requests sent by the user agent refresh the binding of the NAT before the binding expires.
NATの背後にあるユーザエージェントのためのNAT（ネットワークアドレス変換）トラバーサル機能を実行するSBCは、ユーザーエージェントとドメインのレジストラの間に位置します。事業者はそれをサポートするための要件を持っているので、NATのは広く、今日の様々なアクセスネットワークに配置されています。レジストラは、ユーザエージェントからの登録要求を受信し、200（OK）応答で応答する場合に、SBC（すなわち、登録が早く満了する）登録の有効性を減少させるような応答を改変します。これは、すぐにそれがレジストラから元の応答を受けて行っているであろうと登録をリフレッシュするために、新しいREGISTERを送信するためにユーザーエージェントを強制します。結合の有効期限が切れる前にユーザエージェントによって送信されたREGISTER要求は、NATの結合を更新します。
Note that the SBC does not need to relay all the REGISTER requests received from the user agent to the registrar. The SBC can generate responses to REGISTER requests received before the registration is about to expire at the registrar. Moreover, the SBC needs to deregister the user agent if this fails to refresh its registration in time, even if the registration at the registrar would still be valid.
SBCは、レジストラへのユーザーエージェントから受信したすべてのREGISTER要求を中継する必要がないことに注意してください。 SBCは、登録はレジストラで期限切れになる前に受信要求を登録するには、応答を生成することができます。また、SBCは、レジストラで登録がまだ有効だろうしても、この時間内にその登録をリフレッシュするために失敗した場合、ユーザーエージェントの登録を解除する必要があります。
SBCs can also force traffic to go through a media relay for NAT traversal purposes (more about media traffic management in Section 3.2). A typical call has media streams to two directions. Even though SBCs can force media streams from both directions to go through a media relay, in some cases, it is enough to relay only the media from one direction (e.g., in a scenario where only the other endpoint is behind a NAT).
SBCはまた、NATトラバーサル目的（3.2節でメディアトラフィック管理の詳細）のためのメディアリレーを通過するトラフィックを強制することができます。典型的な呼び出しは、二つの方向にメディアストリームを持っています。 SBCは、メディアリレーを通過する両方向からメディアストリームを強制することができるにもかかわらず、いくつかのケースでは、（唯一の他のエンドポイントがNATの背後にあるシナリオでは、例えば）一方向からのみメディアを中継するのに十分です。
This approach to NAT traversal does not work if end-to-end confidentiality or integrity-protection mechanisms are used (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME)). The SBC would be seen as a MITM modifying the messages between the user agent and the registrar.
エンドツーエンドの機密性や完全性保護のメカニズムが使用されている場合、NATトラバーサルにこのアプローチは動作しません（例えば、/セキュア多目的インターネットメール拡張（S / MIME））。 SBCは、ユーザエージェントとレジストラとの間でメッセージを修正MITMとして見られます。
There is also a problem related to the method of how SBCs choose the value for the validity of a registration period. This value should be as high as possible, but it still needs to be low enough to maintain the NAT binding. Some SBCs do not have any deterministic method for choosing a suitable value. However, SBCs can just use a sub-optimal, relatively small value that usually works. An example from such value is 15 seconds (see [9]).
SBCは、登録期間の妥当性の値を選択する方法の方法に関連する問題もあります。この値は、可能な限り高くなければならないが、それはまだ結合NATを維持するのに十分低くする必要があります。いくつかのSBCは、適切な値を選択するための任意の決定論的方法を持っていません。しかし、のSBCは、ちょうど通常動作します次善の、比較的小さな値を使用することができます。そのような値の一例は、15秒（[9]参照します）。
NAT traversal for media using SBCs poses few issues as well. For example, an SBC normally guesses the recipient's public IP address on one of the media streams relayed by the SBC by snooping on the source IP address of another media stream relayed by the same SBC. This causes security and interoperability issues since the SBC can end up associating wrong destination IP addresses on media streams it is relaying. For example, an attacker may snoop on the local IP address and ports used by the SBC for media relaying the streams and send a few packets from a malicious IP address to these destinations. In most cases, this can cause media streams in the opposite directions to divert traffic to the attacker resulting in a successful MITM or DoS attack. A similar example of an interoperability issue is caused when an endpoint behind a NAT attempts to switch the IP address of the media streams by using a re-INVITE. If any media packets are re-ordered or delayed in the network, they can cause the SBC to block the switch from happening even if the re-INVITE successfully goes through.
SBCを使用したメディアのNATトラバーサルは、同様にいくつかの問題を提起します。たとえば、SBCは通常、同じSBCによって中継された別のメディアストリームの送信元IPアドレスをスヌーピングによりSBCによって中継されたメディアストリームの1つに、受信者の公開IPアドレスを推測します。 SBCは、それが中継されるストリームのメディアに誤った宛先のIPアドレスを関連付けて終了することができるので、これはセキュリティと相互運用性の問題が発生します。例えば、攻撃者は、メディアがストリームを中継するためのSBCが使用するローカルIPアドレスとポートをスヌープしてもよいし、これらの宛先に悪意のあるIPアドレスからいくつかのパケットを送信します。ほとんどの場合、これは成功したMITMまたはDoS攻撃が生じ、攻撃者にトラフィックをそらすために反対方向にメディアストリームを引き起こす可能性があります。相互運用性の問題の同様の例は、NATの背後にあるエンドポイントが使用してメディアストリームのIPアドレスを切り替えしようとしたときに再-INVITE引き起こされます。任意のメディアパケットを再注文やネットワークが遅れている場合は、再INVITEに成功を経由する場合、SBCも起こってからスイッチをブロックすることがあります。
Consider the following example scenario: The SBC resides between the UA and Registrar. Previously, the UA has sent a REGISTER request to the Registrar, and the SBC receives the registration response shown in Figure 10.
次の例のシナリオを考えてみましょう：SBCは、UAとレジストラの間に存在します。以前に、UAがレジストラにREGISTER要求を送信しており、SBCは、図10に示す登録応答を受信します。
SIP/2.0 200 OK From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh CSeq: 1 REGISTER Contact: <sips:bob@client.biloxi.example.com>;expires=3600
SIP / 2.0 200 OKから：ボブ<SIP：bob@biloxi.example.com>;タグ= a73kszlfl：をボブ<SIP：bob@biloxi.example.com>;タグ= 34095828jhのCSeq：1つのレジスタとの接触：<一口： bob@client.biloxi.example.com>; = 3600期限が切れます
Figure 10: Response Prior to NAT Maintenance Function
図10：前NATメンテナンス機能への対応
When performing the NAT traversal function, the SBC may rewrite the expiry time to coax the UA to re-register prior to the intermediating NAT deciding to close the pinhole. Figure 11 shows a possible modification of the response from Figure 10.
NATトラバーサル機能を実行する場合、SBCは、ピンホールを閉鎖することを決定する前に仲介NATに再登録するUAを同軸にする有効期限を書き換えることがあります。図11は、図10からの応答の可能な変形例を示しています。
SIP/2.0 200 OK From: Bob <sip:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sip:bob@biloxi.example.com>;tag=34095828jh CSeq: 1 REGISTER Contact: <sips:bob@client.biloxi.example.com>;expires=60
SIP / 2.0 200 OKから：ボブ<SIP：bob@biloxi.example.com>;タグ= a73kszlfl：をボブ<SIP：bob@biloxi.example.com>;タグ= 34095828jhのCSeq：1つのレジスタとの接触：<一口： bob@client.biloxi.example.com>; = 60の有効期限が切れます
Figure 11: Manipulated Response for NAT Traversal
図11：NATトラバーサルのために操作レスポンス
Naturally, other measures could be taken in order to enable the NAT traversal (e.g., non-SIP keepalive messages), but this example illustrates only one mechanism for preserving the SIP-related NAT bindings.
当然のことながら、他の対策は、NATトラバーサル（例えば、非SIPキープアライブメッセージ）を可能にするために取ることができるが、この例では、SIP関連のNATバインディングを維持するための唯一のメカニズムを示します。
Network operators may wish to control what kind of signaling and media traffic their network carries. There is strong motivation and a requirement to do access control on the edge of an operator's network. Access control can be based on, for example, link-layer identifiers, IP addresses or SIP identities.
ネットワークオペレータは、そのネットワークが運ぶシグナリングおよびメディアトラフィックの種類を制御することを望むかもしれません。強い動機と事業者のネットワークのエッジ上のアクセス制御を行うための要件があります。アクセス制御は、例えば、リンク層識別子、IPアドレスまたはSIPアイデンティティに基づくことができます。
This function can be implemented by protecting the inner network with firewalls and configuring them so that they only accept SIP traffic from the SBC. This way, all the SIP traffic entering the inner network needs to be routed though the SBC, which only routes messages from authorized parties or traffic that meets a specific policy that is expressed in the SBC administratively.
この機能は、ファイアウォールと内部ネットワークを保護し、彼らは唯一のSBCからSIPトラフィックを受け入れるようにそれらを設定することで実現できます。この方法は、内部ネットワークに入るすべてのSIPトラフィックが管理SBCで発現される特定のポリシーを満たしている認可の当事者またはトラフィックのルートだけメッセージSBC、しかしルーティングする必要があります。
Access control can be applied to either only the signaling or both the signaling and media. If it is applied only to the signaling, then the SBC might behave as a proxy server. If access control is applied to both the signaling and media, then the SBC behaves in a similar manner as explained in Section 3.2. A key part of media-layer access control is that only media for authorized sessions is allowed to pass through the SBC and/or associated media relay devices.
アクセス制御は、シグナリングのいずれか又はシグナリングおよびメディアの両方に適用することができます。それは、シグナリングのみに適用されている場合、SBCは、プロキシサーバーとして動作をする可能性があります。アクセス制御は、シグナリングおよびメディアの両方に適用されている場合は、セクション3.2で説明したように、SBCは同様に挙動します。メディア層のアクセス制御の重要な部分は、許可セッションのメディアだけが、SBCおよび/または関連するメディア中継装置を通過させることです。
Operators implement some functionalities, like NAT traversal for example, in an SBC instead of other elements in the inner network for several reasons: (i) preventing packets from unregistered users to prevent chances of DoS attack, (ii) prioritization and/or re-routing of traffic (based on user or service, like E911) as it enters the network, and (iii) performing a load balancing function or reducing the load on other network equipment.
（I）DoS攻撃の可能性を防止するために、未登録のユーザからのパケットを阻止する、（ii）の優先順位付け及び/又は再：オペレータは、SBCの代わりに、いくつかの理由のために内部ネットワーク内の他の要素に、例えばNATトラバーサルのようないくつかの機能を実装します（E911のようなユーザまたはサービスに基づいて）トラフィックのルーティングがネットワークに入るとき、および（iii）ロード・バランシング機能を実行またはその他のネットワーク機器の負荷を低減することができます。
In environments where there is limited bandwidth on the access links, the SBC can compute the potential bandwidth use by examining the codecs present in SDP offers and answers. With this information, the SBC can reject sessions before the available bandwidth is exhausted to allow existing sessions to maintain acceptable quality of service. Otherwise, the link could become over-subscribed and all sessions would experience a deterioration in quality of service. SBCs may contact a policy server to determine whether sufficient bandwidth is available on a per-session basis.
アクセスリンク上の限られた帯域幅がある環境では、SBCは、SDPのオファーとアンサーに存在するコーデックを調べることによって潜在的な帯域幅の使用を計算することができます。利用可能な帯域幅は、既存のセッションがサービスの許容可能な品質を維持できるようにするために排出される前に、この情報を使用して、SBCは、セッションを拒否することができます。それ以外の場合は、リンクがオーバーサブスクライブになる可能性があり、すべてのセッションは、サービスの質の低下を経験するでしょう。 SBCは、十分な帯域幅がセッションごとに利用可能であるかどうかを判断するためにポリシーサーバに連絡することができます。
Since the SBC needs to handle all SIP messages, this function has scalability implications. In addition, the SBC is a single point of failure from an architectural point of view. Although, in practice, many current SBCs have the capability to support redundant configuration, which prevents the loss of calls and/or sessions in the event of a failure on a single node.
SBCは、すべてのSIPメッセージを処理する必要があるため、この機能はスケーラビリティに影響します。加えて、SBCは、アーキテクチャの観点から、単一障害点です。が、実際には、多くの現在のSBCは、コールおよび/または単一ノードで障害が発生した場合のセッションの損失を防止する冗長構成をサポートする能力を有します。
If access control is performed only on behalf of signaling, then the SBC is compatible with general SIP architectural principles, but if it is performed for signaling and for media, then there are similar problems as described in Section 3.2.2.
アクセス制御のみシグナリングの代わりに実行されている場合、SBCは、一般的なSIPアーキテクチャの原則と互換性があり、それは、シグナリングおよびメディアのために行われた場合、その後、セクション3.2.2に記載したのと同様の問題があります。
Figure 12 shows a callflow where the SBC is providing both signaling and media access control (ACKs omitted for brevity).
図12は、SBCは、両方のシグナリングおよびメディアアクセス制御（簡潔にするために省略ACKを）提供しているcallflowを示しています。
caller SBC callee
| | |
| Identify the caller | |
|<- - - - - - - - - - - >| |
| | |
| INVITE + SDP | |
|----------------------->| |
| [Modify the SDP] |
| | INVITE + modified SDP |
| |----------------------->|
| | |
| | 200 OK + SDP |
| |<-----------------------|
| [Modify the SDP] |
| | |
| 200 OK + modified SDP | |
|<-----------------------| |
| | |
| Media [Media inspection] Media |
|<======================>|<======================>|
| | |
Figure 12: Example Access Callflow
図12：例アクセスCallflow
In this scenario, the SBC first identifies the caller, so it can determine whether or not to give signaling access to the caller. This might be achieved using information gathered during registration, or by other means. Some SBCs may rely on the proxy to authenticate the user agent placing the call. After identification, the SBC modifies the session descriptors in INVITE and 200 OK messages in a way so that the media is going to flow through the SBC itself. When the media starts flowing, the SBC can inspect whether the callee and caller use the codec(s) upon which they had previously agreed.
このシナリオでは、SBCは、最初の発信者を識別し、それは、呼び出し元へのアクセスを与えるシグナル伝達するか否かを判断することができます。これは、登録時、または他の手段によって収集された情報を使用して達成される可能性があります。いくつかのSBCは電話をかけるユーザーエージェントを認証するためのプロキシに依存してもよいです。同定後、SBCは、メディアがSBC自体を通って流れるように起こっているような方法でセッションINVITEにおける記述子と200 OKメッセージを変更します。メディアが流れ始めると、SBCは、呼び出し先と呼び出し側は、彼らが以前に合意した、その上にコーデック（複数可）を使用するかどうかを調べることができます。
SBCs are also used to repair protocol messages generated by not-fully-standard-compliant or badly implemented clients. Operators may wish to support protocol repair, if they want to support as many clients as possible. It is noteworthy that this function affects only the signaling component of an SBC, and that the protocol repair function is not the same as protocol conversion (i.e., making translation between two completely different protocols).
SBCはまた、完全に標準に準拠していないか、ひどく実装クライアントによって生成されたプロトコルメッセージを修復するために使用されています。オペレータは、彼らができるだけ多くのクライアントをサポートする場合、プロトコルの修復をサポートすることを望むかもしれません。 （すなわち、2つの完全に異なるプロトコル間の変換を行う）この機能は、SBCの唯一信号成分に影響を与えること、およびプロトコル修復機能は、プロトコル変換と同じではないことは注目に値します。
In many cases, doing protocol repair for SIP header fields can be seen as being compatible with SIP architectural principles, and it does not violate the end-to-end model of SIP. The SBC repairing protocol messages behaves as a proxy server that is liberal in what it accepts and strict in what it sends.
多くの場合、SIPヘッダフィールドのプロトコル修復を行うSIPアーキテクチャの原則と適合性であるとみなすことができ、そしてそれは、SIPのエンドツーエンドモデルに違反していません。プロトコルメッセージを修復SBCは、それが受け入れ何でリベラル、それが送信するもので厳格であるプロキシサーバとして動作します。
However, protocol repair may break security mechanism that do cryptographical computations on SIP header values. Attempting protocol repair for SIP message bodies (SDP) is incompatible with Authenticated Identity Management [4] and end-to-end security mechanisms such as S/MIME.
しかしながら、プロトコルの修復は、SIPヘッダ値に暗号学的計算を行うセキュリティメカニズムを破ることができます。 SIPメッセージボディのプロトコル修復（SDP）をしようとすると、認証されたアイデンティティ管理[4]このようなS / MIMEなどのエンドツーエンドのセキュリティメカニズムと互換性がありません。
A similar problem related to increasing complexity, as explained in Section 3.3.2, also affects protocol repair function.
3.3.2項で説明したように、複雑さを増加させるに関連する同様の問題は、また、プロトコル修復機能に影響を与えます。
The SBC can, for example, receive an INVITE message from a relatively new SIP UA as illustrated in Figure 13.
SBCは、例えば、図13に示すように比較的新しいSIP UAからINVITEメッセージを受信することができます。
INVITE sip:callee@sbchost.example.com Via: SIP/2.0/UDP u1.example.com:5060;lr From: Caller <sip:caller@one.example.com> To: Callee <sip:callee@two.example.com> Call-ID: 18293281@u1.example.com CSeq: 1 INVITE Contact: sip:caller@u1.example.com
ビアcallee@sbchost.example.com：からSIP / 2.0 / UDP u1.example.com:5060;lr：一口を招待する：<caller@one.example.com一口>：呼び出し先<一口：発信者を呼び出し先を2 @。 example.com>コールID：18293281@u1.example.comのCSeq：連絡先を1 INVITE：SIP：caller@u1.example.com
Figure 13: Request from a Relatively New Client
図13：比較的新しいクライアントからの要求
If the SBC does protocol repair, it can rewrite the 'lr' parameter on the Via header field into the form 'lr=true' in order to support some older, badly implemented SIP stacks. It could also remove excess white spaces to make the SIP message more human readable.
SBCは、プロトコルの修理をしている場合、それはいくつかの古い、ひどく実装SIPスタックをサポートするために、フォーム「真LR =」へのViaヘッダーフィールド上の「LR」パラメータを書き換えることができます。また、SIPメッセージより人間読みやすくするために余分な空白を削除することができます。
SBCs are used to perform media encryption/decryption at the edge of the network. This is the case when media encryption (e.g., Secure Real-time Transport Protocol (SRTP)) is used only on the access network (outer network) side and the media is carried unencrypted in the inner network. Some operators provide the ability to do legal interception while still giving their customers the ability to encrypt media in the access network. One possible way to do this is to perform media encryption function.
SBCは、ネットワークのエッジでメディア暗号化/復号化を実行するために使用されています。これは、メディア暗号化が（例えば、セキュアリアルタイムトランスポートプロトコル（SRTP））がアクセスネットワーク（外ネットワーク）側でのみ使用され、メディアが内部ネットワークに暗号化されずに行われる場合です。一部の事業者はまだ彼らの顧客にアクセスネットワーク内のメディアを暗号化する機能を与えながら、法的傍受を行う機能を提供します。これを行うための1つの可能な方法は、メディア暗号化機能を実行することです。
While performing a media encryption function, SBCs need to be able to inject either themselves, or some other entity to the media path. It must be noted that this kind of behavior is the same as a classical MITM attack. Due to this, the SBCs have the same architectural issues as explained in Section 3.2.
メディア暗号化機能を実行している間、のSBCは、メディアパスに自分自身、または他のエンティティのいずれかを注入できるようにする必要があります。行動のこの種は、古典的なMITM攻撃と同じであることに留意しなければなりません。 3.2節で説明したようにこのため、SBCでは、同じアーキテクチャの問題を抱えています。
Figure 14 shows an example where the SBC is performing media-encryption-related functions (ACKs omitted for brevity).
図14は、SBCは、メディア暗号化関連機能（簡潔にするために省略のACK）を行っている例を示しています。
caller SBC#1 SBC#2 callee
| | | |
| INVITE + SDP | | |
|------------------->| | |
| [Modify the SDP] | |
| | | |
| | INVITE + mod. SDP | |
| |------------------->| |
| | [Modify the SDP] |
| | | |
| | | INVITE + mod. SDP |
| | |------------------->|
| | | |
| | | 200 OK + SDP |
| | |<-------------------|
| | [Modify the SDP] |
| | | |
| | 200 OK + mod. SDP | |
| |<-------------------| |
| [Modify the SDP] | |
| | | |
| 200 OK + mod. SDP | | |
|<-------------------| | |
| | | |
| Encrypted | Plain | Encrypted |
| media [enc./dec.] media [enc./dec.] media |
|<==================>|<- - - - - - - - ->|<==================>|
| | | |
Figure 14: Media Encryption Example
図14：メディア暗号化の例
First, the UAC sends an INVITE request, and the first SBC modifies the session descriptor in a way that it injects itself to the media path. The same happens in the second SBC. Then, the User Agent Server (UAS) replies with a 200 OK response and the SBCs inject themselves in the returning media path. After signaling, the media starts flowing, and both SBCs perform media encryption and decryption.
まず、UACは、INVITEリクエストを送信し、最初のSBCは、メディアパスに自分自身を挿入する方法でセッション記述を変更します。同じことが二SBCに起こります。次に、ユーザエージェントサーバ（UAS）は、200 OK応答で応答とのSBCは戻ってメディアパスで自分自身を注入します。シグナリングの後、メディアが流れ始めると、両方のSBCは、メディアの暗号化と復号化を行います。
Some of the functions listed in this document are more SIP-unfriendly than others. This list of requirements is derived from the functions that break the principles of SIP in one way or another when performed by SBCs that do not have the users' consent. The derived requirements are:
この文書に記載されている機能の一部は、より多くのSIP-よそよそしい他よりあります。要件のこのリストは、ユーザーの同意を持っていないのSBCによって実行時に何らかの形でSIPの原則を破る関数から導出されます。派生要件は次のとおりです。
Req-1: There should be a SIP-friendly way to hide network topology information. Currently, this is done by stripping and replacing header fields, which is against the principles of SIP on behalf of some header fields (see Section 3.1).
REQ-1：ネットワークトポロジ情報を非表示にするには、SIP-優しい方法があるはずです。現在、このストリッピングし、いくつかのヘッダフィールドの代わりにSIPの原理に反しているヘッダフィールドを置き換えることによって行われる（セクション3.1参照）。
Req-2: There should be a SIP-friendly way to direct media traffic through intermediaries. Currently, this is done by modifying session descriptors, which is against the principles of SIP (see Sections 3.2, 3.4, 3.5, and 3.7).
REQ-2：仲介を介してメディアトラフィックを指示するSIP-優しい方法があるはずです。現在、これは（セクション3.2、3.4、3.5、および3.7を参照）SIPの原則に反している、修正セッション記述子によって行われます。
Req-3: There should be a SIP-friendly way to fix capability mismatches in SIP messages. This requirement is harder to fulfill on complex mismatch cases, like the 3GPP/SIP [1] network mismatch. Currently, this is done by modifying SIP messages, which may violate end-to-end security (see Sections 3.3 and 3.6), on behalf of some header fields.
REQ-3：SIPメッセージの機能の不一致を修正するためのSIP-優しい方法があるはずです。この要件は、3GPP / SIP [1]ネットワークミスマッチのような、複雑な不一致の場合に満たすことが困難です。現在、これは、いくつかのヘッダフィールドの代わりに、（セクション3.3および3.6を参照）エンドツーエンドのセキュリティを侵害する可能性がある、SIPメッセージを変更することによって行われます。
Req-1 and Req-3 do not have an existing, standardized solution today. There is ongoing work in the IETF for addressing Req-2, such as SIP session policies [10], Traversal Using Relays around NAT (TURN) [11], and Interactive Connectivity Establishment (ICE) [12]. Nonetheless, future work is needed in order to develop solutions to these requirements.
REQ-1およびREQ-3は、今日、既存の、標準化されたソリューションを持っていません。が進行中の作業は、トラバーサルは[11]、[10]そのようなSIPセッションポリシーとして、REQ-2をアドレス指定するためのIETFにNAT（TURN）の周りにリレーを使用して、インタラクティブ接続確立（ICE）[12]。それにもかかわらず、今後の作業は、これらの要件へのソリューションを開発するために必要とされています。
Many of the functions this document describes have important security and privacy implications. One major security problem is that many functions implemented by SBCs (e.g., topology hiding and media traffic management) modify SIP messages and their bodies without the user agents' consent. The result is that the user agents may interpret the actions taken by an SBC as a MITM attack. SBCs modify SIP messages because it allows them to, for example, protect elements in the inner network from direct attacks.
機能の多くは、この文書では、重要なセキュリティとプライバシーの意味を持って説明しています。一つの主要なセキュリティ上の問題は、SBCで（例えば、トポロジ隠蔽とメディアトラフィック管理）によって実装される多くの機能は、ユーザーエージェントの同意なしにSIPメッセージと自分の体を変更することです。その結果、ユーザエージェントは、MITM攻撃とSBCが取る行動を解釈するかもしれないということです。それは彼らが、例えば、直接の攻撃から内部ネットワーク内の要素を保護することを可能にするためのSBCは、SIPメッセージを変更します。
SBCs that place themselves (or another entity) on the media path can be used to eavesdrop on conversations. Since, often, user agents cannot distinguish between the actions of an attacker and those of an SBC, users cannot know whether they are being eavesdropped on or if an SBC on the path is performing some other function. SBCs place themselves on the media path because it allows them to, for example, perform legal interception.
メディアパスに自分自身（または他のエンティティ）を置くのSBCは、会話を盗聴するために使用することができます。 、多くの場合、ユーザーエージェントは、攻撃者の行動やSBCのものと区別することができないので、ユーザーは、彼らが上か、パス上のSBCは、いくつかの他の機能を実行している場合は盗聴されているかどうかを知ることはできません。それは彼らが、例えば、法的傍受を実行することを可能にするためのSBCは、メディアパスに自分自身を配置します。
On a general level, SBCs prevent the use of end-to-end authentication. This is because SBCs need to be able to perform actions that look like MITM attacks, and in order for user agents to communicate, they must allow those type of attacks. It other words, user agents cannot use end-to-end security. This is especially harmful because other network elements, besides SBCs, are then able to do similar attacks. However, in some cases, user agents can establish encrypted media connections between one another. One example is a scenario where SBC is used for enabling media monitoring but not for interception.
一般的なレベルで、のSBCは、エンドツーエンド認証の使用を防ぎます。 SBCは、MITM攻撃のように見えるのアクションを実行できるようにする必要があり、ユーザエージェントが通信するために、彼らは攻撃のこれらのタイプを許可する必要があるためです。それはつまりは、ユーザエージェントは、エンドツーエンドのセキュリティを使用することはできません。他のネットワーク要素は、SBCでのほか、その後、同様の攻撃を行うことができますので、これは特に有害です。しかし、いくつかのケースでは、ユーザエージェントは、互いの間で暗号化されたメディア接続を確立することができます。一例では、SBCは、メディア監視を可能にするためではなく、傍受のために使用されるシナリオです。
An SBC is a single point of failure from the architectural point of view. This makes it an attractive target for DoS attacks. The fact that some functions of SBCs require those SBCs to maintain session-specific information makes the situation even worse. If the SBC crashes (or is brought down by an attacker), ongoing sessions experience undetermined behavior.
SBCは、アーキテクチャの観点から、単一障害点です。これは、DoS攻撃のための魅力的な標的になります。 SBCの一部の機能は、セッション固有の情報を維持するために、これらのSBCを必要とするという事実は、状況はさらに悪化します。 SBCがクラッシュ（または攻撃者によって倒される）場合は、進行中のセッションは未定動作が発生します。
If the IETF decides to develop standard mechanisms to address the requirements presented in Section 4, the security and privacy-related aspects of those mechanisms will, of course, need to be taken into consideration.
IETFは、第4節で提示要件に対応するための標準的なメカニズムを開発することを決定した場合、それらのメカニズムのセキュリティとプライバシー関連の側面には、当然、考慮される必要があります。
The ad hoc meeting about SBCs, held on November 9, 2004 in Washington DC during the 61st IETF meeting, provided valuable input to this document. The authors would also like to thank Sridhar Ramachandran, Gaurav Kulshreshtha, and Rakendu Devdhar. Reviewers Spencer Dawkins and Francois Audet also deserve special thanks.
第61回IETF会議中にワシントンDCで2004年11月9日に開催されたのSBCに関するアドホック会議では、この文書に貴重な入力を提供します。著者らはまたシュリダールラマチャンドラン、のGaurav Kulshreshtha、およびラケンドゥDevdharに感謝したいと思います。レビュアースペンサードーキンスとフランソワAudetも特別な感謝に値します。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、2002年11月。
[3] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[3]ウィリス、D.およびB. Hoeneisenを、 "セッション開始プロトコル（SIP）拡張ヘッダフィールドは非隣接コンタクトを登録するための"、RFC 3327、2002年12月。
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[4]ピーターソン、J.とC.ジェニングスを、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[6] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2", 3GPP TS 23.228 10.0.0, March 2010.
[6] 3GPP、 "IPマルチメディア・サブシステム（IMS）、ステージ2"、3GPP TS 23.228 10.0.0 2010年3月。
[7] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[7]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[8] Munakata, M., Schubert, S., and T. Ohba, "User-Agent-Driven Privacy Mechanism for SIP", RFC 5767, April 2010.
[8]宗像、M.、シューベルト、S.、およびT.大場、 "SIPのためのユーザーエージェントドリブンプライバシーメカニズム"、RFC 5767、2010年4月。
[9] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[9]エッゲルト、L.とG. Fairhurst、BCP 145、RFC 5405 "アプリケーションデザイナーのためのユニキャストUDPの使用上のガイドライン"、2008年11月。
[10] Hilt, V., Camarillo, G., and J. Rosenberg, "A Framework for Session Initiation Protocol (SIP) Session Policies", Work in Progress, February 2010.
[10]柄、V.、カマリロ、G.、およびJ.ローゼンバーグ、 "セッション開始プロトコル（SIP）セッションポリシーのフレームワーク"、進歩、2010年2月ワーク。
[11] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[11]マーイ、R.、マシューズ、P.、およびJ.ローゼンバーグ、 "トラバーサルは、NATの周りにリレーを使用して（TURN）：NAT（STUN）のセッショントラバーサルユーティリティにリレー拡張機能"、RFC 5766、2010年4月。
[12] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, MonthTBD 2010.
[12]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/アンサープロトコルのネットワークアドレス変換（NAT）トラバーサルのためのプロトコル"、RFC 5245、2010 MonthTBD。
Authors' Addresses
著者のアドレス
Jani Hautakorpi (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ヤニHautakorpi（エディタ）エリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
メールアドレス：Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Robert F. Penfield Acme Packet 71 Third Avenue Burlington, MA 01803 US
ロバート・F・ペンフィールドアクメパケット71 Third Avenueのバーリントン、MA 01803米国
EMail: bpenfield@acmepacket.com
メールアドレス：bpenfield@acmepacket.com
Alan Hawrylyshen Skype, Inc. 2055 E. Hamilton Ave San Jose, CA 95125 US
アランHawrylyshenスカイプ社2055 E・ハミルトンアベニューサンノゼ、CA 95125米国
EMail: alan.ietf@polyphase.ca
メールアドレス：alan.ietf@polyphase.ca
Medhavi Bhatia 3CLogic 9700 Great Seneca Hwy. Rockville, MD 20850 US
Medhaviバティア3CLogic 9700グレートセネカハイウェイ。ロックビル、MD 20850米国
EMail: mbhatia@3clogic.com
メールアドレス：mbhatia@3clogic.com