[要約] RFC 5853は、SIPセッションボーダーコントロール（SBC）展開に関する要件を定義しています。その目的は、SBCの設計と展開に関するガイドラインを提供し、ネットワークのセキュリティと信頼性を向上させることです。
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
セッション開始プロトコル（SIP）セッションボーダーコントロール（SBC）展開からの要件
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.
このドキュメントは、セッションボーダーコントローラー（SBCS）として知られるセッション開始プロトコル（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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）[1]の迅速な採用とSIPベースの通信ネットワークの展開がありました。これにより、ネットワークオペレーターの要件を満たすために、プロトコル仕様の開発と実装を上回ることがよくあります。これにより、独自の解決策が開発されました。多くの場合、これらの独自のソリューションは、通常、2つのネットワーク間の境界線に展開されるため、セッションボーダーコントローラー（SBCS）として市場で知られているネットワーク仲介業者に実装されています。この理由は、ネットワークポリシーが通常、ネットワークの端で実施されるためです。
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.
このドキュメントの目的は、SBCSで実装されている機能を記述することです。何らかの形で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つのサービスプロバイダーネットワーク間、またはアクセスネットワークとバックボーンネットワークの間にあり、住宅および/またはエンタープライズの顧客にサービスを提供します。セッションベースのマルチメディアサービス（例：Voice over IP）を有効または強化するためのさまざまな機能を提供します。これらの機能には、a）周囲防御（アクセス制御、トポロジの隠れ、およびサービス拒否予防と検出）が含まれます。b）エンドポイントでは利用できない機能（NATトラバーサル、プロトコルインターワーキングまたは修理）。c）トラフィック管理（メディア監視とサービス品質（QOS））。これらの機能の一部は、他のSIP要素（プリペイドプラットフォーム、第3世代パートナーシッププロジェクト（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は、コンタクトヘッダーフィールドの値をSBCSアドレスに置き換え、新しいコールIDとタグから新しいCall-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はユーザーの暗黙の同意を持っていると見なすことができます。別の例は、サービスプロバイダーがゲートウェイを壊し、プロトコル修復の理由でSBCを前に展開するシナリオです（セクション3.6を参照）。ユーザーは、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にルーティングされる招待を送信します。次に、SBCはそれをSoftSwitch（SS-B）に転送します。SoftSwitchは、オペレーターBのネットワークの適切な終端ゲートウェイ（GW-B1）を指すSBCにリダイレクト（3xx）メッセージを返します。オペレーターBにSBCがない場合、リダイレクトメッセージはオペレーターAの発信ゲートウェイに送信されます。リダイレクトメッセージを受信した後、SBCは招待状を終了ゲートウェイに送信します。
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（アクセス制御リスト）エントリの数を最小化することにより、ネットワーク管理を簡素化します。ゲートウェイはピアネットワークにさらされる必要はなく、SBCSへのアクセス（メディアとシグナリングの両方）を制限できます。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はCallfulであるため、アクセスリンクの過剰サブスクリプションを防ぐためのアクセス制御機能を提供する場合があります。エンドポイントは、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にルーティングされるようにします。これは、パスヘッダーフィールド[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.
このセクションで紹介するシナリオは一般的なものであり、他の同様の設定にも適用されます。同様の設定の1つの例は、アクセスネットワークがオープンなインターネットであり、オペレーターネットワークが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.
トポロジーの最も一般的な形式は、ヘッダープライバシーの適用です（[2]のセクション5.1を参照）。ただし、削除できないヘッダーのドメイン名の代わりにIPアドレスを使用する展開（例えば、ヘッダーから）では、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のような仲介者をシグナリングパスに挿入するよりも、トポロジー情報を隠す他の方法もあります。方法の1つは、UA駆動型プライバシーメカニズム[8]であり、UAはトポロジー情報の隠蔽を促進できます。
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を使用してエンドツーエンドで通信されるユーザーのプライバシー、セキュリティ要件、および高層アプリケーションに関する情報を変更または削除する可能性があります。エンドツーエンドの呼び出しのどちらのユーザーエージェントも、SBCアクションを中間（MITM）攻撃と区別する方法を持っていません。
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がユーザーからの同意を持たないシナリオでは、認証されたID管理[4]ではうまく機能しません。認証されたアイデンティティ管理メカニズムは、from、call-id、cseq、date、およびcontact headerフィールドの一部から、メッセージ本体全体の一部から計算されるハッシュ値に基づいています。認証サービスがSBC自体によって提供されていない場合、前述のヘッダーフィールドとメッセージ本文の変更は[4]に違反しています。たとえば、SIPメッセージのコンタクトヘッダーを置き換えるため、いくつかの形式のトポロジーが隠れています。
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.
トポロジー隠蔽を実装する現在の方法は、SBCがB2BUA（連続したユーザーエージェント）として機能することで構成され、発信メッセージからトポロジ情報（たとえば、経由およびレコードルートエントリなど）のすべてのトレースを削除します。
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）は、この場合はオペレーターネットワークであるインナーネットワークから招待リクエストを受け取ります。受信した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>
Figure 4: INVITE Request Prior to Topology Hiding
図4：トポロジーが隠れる前にリクエストを招待します
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でヘッダーフィールドを介して挿入します。トポロジーの非表示関数の後、メッセージは図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>
Figure 5: INVITE Request after Topology Hiding
図5：トポロジーが隠れている後にリクエストを招待します
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".
これは、トポロジーが隠れている例の1つにすぎません。トポロジーの隠れ（つまり、ネットワーク要素に関連する情報が非表示になっている）に加えて、SBCはアイデンティティを隠すこともできます（つまり、加入者のIDに関連する情報が非表示になっています）。IDの隠蔽を実行している間、SBCはコンタクトヘッダーフィールド値とID情報を含む他のヘッダーフィールドを変更する場合があります。ID情報を含むヘッダーフィールドは、[2]のセクション4.1にリストされています。[2]の公開以来、アイデンティティ情報を含む次のヘッダーフィールドが定義されています：「p-asserted-Identity」、「referend-by」、「Identity」、および「IDINFO」。
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.
メディアトラフィック管理のユースケースの1つは、監査または法的義務をサポートするために必要なインターセプト機能の実装です。法的義務は主に音声サービスを提供するオペレーターに適用され、それらのオペレーターは通常、SBCSがなくてもインターセプト機能を提供するためのインフラストラクチャ（たとえば、SIPプロキシ）を持っていることは注目に値します。
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は、いずれかのエンドポイントがセッションの途中で死んだ場合、「失われたさようなら」問題にも対処できます。SBCは、メディアが流れを止めていることを検出し、他の中間要素とエンドポイントのどの状態をクリーンアップするために両側にさようならを発行します。
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.
メディアトラフィック管理の考えられる形式の1つは、SBCがByeリクエストを生成することによりメディアストリームを終了し、Dipを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がユーザーエージェント間でセッションの説明（つまり、オファーと回答）にアクセスして変更する必要があります。その結果、ユーザーエージェントがメッセージ本文をエンドツーエンドで暗号化または保護する場合、このアプローチは機能しません。繰り返しますが、メッセージはサブスクライバーの同意なしに変更され、ユーザーエージェントにはSBCアクションをMITMによる攻撃と区別する方法はありません。さらに、これは認証されたアイデンティティ管理に違反しています[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）やPATH MTU発見（PMTUD）などの関数を破る可能性があります。メディアは、プロトコルフィールドの正しい取り扱いに依存するこのようなIPおよび輸送層の機能を簡単に破壊します。特に敏感なフィールドには、たとえば、ECNおよびタイプのサービス（TOS）フィールド、およびDONT FRAGMENT（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は1つのユーザーエージェントからメディアを受信し、他のユーザーエージェントにリレーし、逆方向に移動するメディアと同一の操作を実行します。
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は、アウターネットワークから招待リクエストを受信します。この場合、アクセスネットワークです。受信した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
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 =」行を書き直し、一部の（外部）ポリシーに従って1つの「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 O =所有者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
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.
SBCS修正機能の不一致により、異なる機能または拡張機能を備えたユーザーエージェント間の通信が可能になります。たとえば、SBCは、プレーンSIP [1]ユーザーエージェントが3GPPネットワークに接続できるか、異なるIPバージョン、異なるコーデック、または異なるアドレスレルムにあるユーザーエージェント間の接続を有効にすることができます。オペレーターには、異なるドメイン間で透明な通信を提供できるように、能力の不一致の修正を実行するための要件と強い動機があります。場合によっては、同じSIPアプリケーションを実装するための異なるSIP拡張またはメソッド（監視セッションの活性、呼び出し履歴/転用など）もSBCを介してインターワークされる場合があります。
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.
セクション3.2で説明されている手順を使用して、メディア要素をメディアパスに挿入することにより、機能の不一致を修正しているSBCはそれを行います。したがって、これらの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 sip:callee@ipv6.domain.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.4
Contact: sip:caller@u1.example.com
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 O =所有者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
Figure 8: Request Prior to Capabilities Match
図8：機能が一致する前のリクエスト
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
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
Figure 9: Request after Capability Match
図9：機能の一致後のリクエスト
This message is then sent by the SBC to the onward IPv6 network.
このメッセージは、SBCによって以前のIPv6ネットワークに送信されます。
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のバインディングを生かし続ける定期的なネットワークトラフィックを生成することで実現できます。SBCSの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は登録の有効性を減らすそのような応答を変更します（つまり、登録はより早く期限切れになります）。これにより、ユーザーエージェントは新しいレジスタを送信して、レジストラから元の応答を受信する際に登録をより早く更新するようにします。ユーザーエージェントから送信されたレジスタリクエストは、バインディングが期限切れになる前に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は、ユーザーエージェントから受信したすべてのレジスタリクエストをレジストラに中継する必要がないことに注意してください。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).
SBCSは、NATトラバーサルの目的でトラフィックにメディアリレーを通過させることもできます（セクション3.2のメディアトラフィック管理の詳細）。典型的な呼び出しには、メディアストリームが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トラバーサルへのこのアプローチは、エンドツーエンドの機密性または整合性保護メカニズムが使用されている場合には機能しません（たとえば、Secure/Multipurpose Internet Mail Extensions（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には、適切な値を選択するための決定論的な方法がありません。ただし、SBCSは、通常機能する最適で比較的小さな値を使用するだけです。そのような値の例は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.
SBCSを使用するメディアのNATトラバーサルは、ほとんど問題もありません。たとえば、SBCは通常、同じSBCによって中継された別のメディアストリームのソースIPアドレスをスヌーピングすることにより、SBCによって中継されたメディアストリームの1つの受信者のパブリックIPアドレスを推測します。これにより、SBCが中継しているメディアストリーム上の間違った宛先IPアドレスを関連付けることができるため、セキュリティと相互運用性の問題が発生します。たとえば、攻撃者は、SBCが使用するローカルIPアドレスと、ストリームを中継するメディアに使用するポートを覗き見し、悪意のあるIPアドレスからこれらの宛先にいくつかのパケットを送信する場合があります。ほとんどの場合、これにより、メディアストリームが反対方向にストリームを引き起こし、トラフィックを攻撃者に迂回させ、MITMまたはDOS攻撃が成功します。相互運用性の問題の同様の例が、NATの背後にあるエンドポイントが、再インベンタルを使用してメディアストリームのIPアドレスを切り替えようとする場合に発生します。ネットワーク内でメディアパケットが再注文または遅延されている場合、Re 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はレジスタリクエストをレジストラに送信し、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
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
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 Keepaliveメッセージなど）を有効にするために他の測定値をとることができますが、この例は、SIP関連NATバインディングを保存するための1つのメカニズムのみを示しています。
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 IDに基づいています。
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または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はプロキシサーバーとして動作する可能性があります。シグナル伝達とメディアの両方にアクセス制御が適用される場合、SBCはセクション3.2で説明したように同様の方法で動作します。メディア層アクセス制御の重要な部分は、認定セッションのメディアのみが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.
オペレーターは、たとえば、いくつかの理由で内部ネットワーク内の他の要素の代わりにSBCでNAT Traversalのようないくつかの機能を実装します。（i）未登録のユーザーからのパケットを防止して、DOS攻撃の可能性を防ぐ、（ii）優先順位付けおよび/またはネットワークに入るときのトラフィック（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は、利用可能な帯域幅が使い果たされる前にセッションを拒否でき、既存のセッションが許容できるサービス品質を維持できるようにします。そうしないと、リンクが過剰に登録される可能性があり、すべてのセッションはサービス品質の劣化を経験します。SBCSは、ポリシーサーバーに連絡して、設備ごとに十分な帯域幅が利用可能かどうかを判断する場合があります。
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がシグナル伝達とメディアアクセス制御の両方を提供しているコールフローを示しています（BrevityのためにACKが省略）。
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自体を通過するように、招待状と200のOKメッセージのセッション記述子を変更します。メディアが流れ始めると、SBCはCalleeとCallerが以前に同意したコーデックを使用するかどうかを調べることができます。
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は、標準に準拠していない、または実装されていないクライアントによって生成されたプロトコルメッセージの修復にも使用されます。オペレーターは、できるだけ多くのクライアントをサポートしたい場合、プロトコルの修理をサポートしたい場合があります。この関数はSBCのシグナル伝達コンポーネントのみに影響し、プロトコル修復関数がプロトコル変換と同じではないことは注目に値します（つまり、2つのまったく異なるプロトコル間の翻訳を作成します）。
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 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
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がプロトコルの修復を行う場合、viaヘッダーフィールドの「lr」パラメーターをフォーム「lr = true」に書き換えて、古くて実装された古いSIPスタックをサポートします。また、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攻撃と同じであることに注意する必要があります。このため、SBCにはセクション3.2で説明されているのと同じアーキテクチャの問題があります。
Figure 14 shows an example where the SBC is performing media-encryption-related functions (ACKs omitted for brevity).
図14は、SBCがメディア暗号化関連の機能を実行している例を示しています（Brevityのために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は招待リクエストを送信し、最初のSBCはメディアパスに注入する方法でセッション記述子を変更します。2番目のSBCでも同じことが起こります。次に、ユーザーエージェントサーバー（UAS）が200のOK応答で応答し、SBCSは返されるメディアパスに自分自身を注入します。シグナリングの後、メディアは流れ始め、両方の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に適していません。この要件のリストは、ユーザーの同意がないSBCSによって実行された場合、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フレンドリーな方法があるはずです。現在、これはSIPの原則に反するセッション記述子を変更することによって行われます（セクション3.2、3.4、3.5、および3.7を参照）。
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には、今日既存の標準化されたソリューションはありません。SIPセッションポリシー[10]、NAT（ターン）の周りのリレーを使用したトラバーサル[11]、およびインタラクティブ接続確立（ICE）[12]など、REQ-2に対処するためのIETFで進行中の作業があります。それにもかかわらず、これらの要件の解決策を開発するためには、将来の作業が必要です。
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.
このドキュメントが説明する機能の多くは、重要なセキュリティとプライバシーへの影響を持っています。主要なセキュリティの問題の1つは、SBCS（たとえば、トポロジの隠れやメディアトラフィック管理など）によって実装された多くの機能が、ユーザーエージェントの同意なしにSIPメッセージとその身体を変更することです。その結果、ユーザーエージェントは、SBCがMITM攻撃として取得したアクションを解釈できます。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以外の他のネットワーク要素が同様の攻撃を行うことができるため、特に有害です。ただし、場合によっては、ユーザーエージェントが暗号化されたメディア接続を互いに確立することができます。1つの例は、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.
2004年11月9日に第61回IETF会議中にワシントンDCで開催されたSBCに関するアドホック会議は、この文書に貴重な情報を提供しました。著者は、Sridhar Ramachandran、Gaurav Kulshreshtha、Rakendu Devdharにも感謝したいと思います。レビュアーのスペンサー・ドーキンスとフランソワ・オーデットも特別な感謝に値します。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[2] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[2] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、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] Willis、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] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[5] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、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] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Munakata、M.、Schubert、S。、およびT. Ohba、「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] Eggert、L。and G. Fairhurst、「アプリケーションデザイナー向けのUnicast UDP使用ガイドライン」、BCP 145、RFC 5405、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] Hilt、V.、Camarillo、G。、およびJ. Rosenberg、「セッション開始プロトコル（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] Mahy、R.、Matthews、P。、およびJ. Rosenberg、「NATの周りのリレーを使用したトラバーサル：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] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：Network Address Translator（NAT）Traversal for Offer/Answer Protocolsのプロトコル」、RFC 5245、MonthTBD 2010。
Authors' Addresses
著者のアドレス
Jani Hautakorpi (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
Jani Hautakorpi（編集者）Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Jani.Hautakorpi@ericsson.com
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Robert F. Penfield Acme Packet 71 Third Avenue Burlington, MA 01803 US
ロバートF.ペンフィールドACMEパケット71サードアベニューバーリントン、マサチューセッツ州01803 US
EMail: bpenfield@acmepacket.com
Alan Hawrylyshen Skype, Inc. 2055 E. Hamilton Ave San Jose, CA 95125 US
Alan Hawrylyshen Skype、Inc。2055 E. Hamilton Ave San Jose、CA 95125 US
EMail: alan.ietf@polyphase.ca
Medhavi Bhatia 3CLogic 9700 Great Seneca Hwy. Rockville, MD 20850 US
Medhavi Bhatia 3Clogic 9700 Great Seneca Hwy。ロックビル、メリーランド州20850米国
EMail: mbhatia@3clogic.com