Network Working Group F. Baker
Request for Comments: 3924 B. Foster
Category: Informational C. Sharp
Cisco Systems
October 2004
Cisco Architecture for Lawful Intercept in IP Networks
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは、いかなる目的のために、このRFCのフィットネスの知識を否認し、特にノートに公開するという決定は、セキュリティ、輻輳制御または展開されたプロトコルとの不適切な相互作用のようなもののためにIETFレビューに基づいていないこと。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。
Abstract
抽象
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications. Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not attempt to address any of the specific legal requirements or obligations that may exist in a particular country.
本文書の目的のために、合法的傍受は、合法的に許可された傍受および通信の監視があります。サービスプロバイダは、世界中の国々のさまざまなIPネットワークでの法律および規制音声の傍受の要件だけでなく、データ通信を満たすために求められています。要件は国によって異なりますが、いくつかの要件は、このような配信形式などの詳細が異なっていても、共通のまま。この文書では、IPネットワークで合法的傍受をサポートするシスコのアーキテクチャについて説明します。これは、共通インターフェイスの最小セットを有する一般的な解決策を提供します。この文書は、特定の国で存在することができる特定の法的要件または義務のいずれかに対処しようとしません。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Motivating the Architecture . . . . . . . . . 3
1.2. Document Organization. . . . . . . . . . . . . . . . . . . 4
2. Reference Model . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Reference Model Components . . . . . . . . . . . . . . . . 6
2.2. Operational Considerations . . . . . . . . . . . . . . . . 7
3. Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Content Intercept Request Interface. . . . . . . . . . . . 9
3.2. Intercept Content Interface (f). . . . . . . . . . . . . . 10
4. Applying the Reference Model. . . . . . . . . . . . . . . . . . 11
4.1. Voice over IP networks . . . . . . . . . . . . . . . . . . 11
4.1.1. Interception of Voice over IP Services. . . . . . . 11
4.1.2. Local Voice Services. . . . . . . . . . . . . . . . 12
4.2. Data Services. . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 13
5.1. Content Request Interface (d) - SNMPv3 Control . . . . . . 14
6. Informative References. . . . . . . . . . . . . . . . . . . . . 14
7. Acronyms. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . 17
9. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 18
For the purposes of this document, lawful intercept is the lawfully authorized interception and monitoring of communications of an intercept subject. The term "intercept subject", "subject", "target subscriber" or "target" in this document refers to the subscriber of a telecommunications service whose communications and/or intercept related information (IRI) has been lawfully authorized to be intercepted and delivered to some agency. Note that although the term "Law Enforcement Agency" (LEA) is used throughout this document, this may refer to any agency that is able to request lawfully authorized interception.
本文書の目的のために、合法的傍受は、傍受対象の通信の合法的に許可された傍受および監視です。用語「傍受対象」、「患者」、「対象加入者」又は本書で「標的」は、通信および/または傍受関連情報（IRI）合法的傍受と送達されることを許可された通信サービスの加入者を指しいくつかの代理店へ。 「法執行機関」（LEA）用語は、この文書全体で使用されているが、これは合法的に許可傍受を要求することができる任意の機関を参照してもよいことに注意してください。
By intercept related information (IRI) we mean information related to the IP traffic of interest. There is currently no standardized definition for IRI for IP traffic. IRI has been defined for a few services that might run over IP (e.g., Voice over IP) or that IP runs on top of (e.g., GPRS). For example, IRI for voice over IP could be the called and calling phone numbers. The definition of IRI from [14] is shown below:
傍受関連情報（IRI）とは、関心のIPトラフィックに関連する情報を意味します。 IPトラフィックのIRIのための標準化された定義は現在ありません。 IRIは、IP上で動作するかもしれないいくつかのサービスのために定義されている（例えば、ボイスオーバーIP）またはそのIPは、（例えば、GPRS）の上で実行されます。例えば、ボイスオーバーIPのためのIRIが呼び出された電話番号を呼び出すことができます。 [14]からIRIの定義を以下に示します。
Intercept Related Information: collection of
information or data associated with
telecommunication services involving the target
identity, specifically communication associated
information or data (e.g., unsuccessful
communication attempts), service associated
information or data and location
information.
Service providers are being asked to meet legal and regulatory requirements for the interception of voice as well as data communications in IP networks in a variety of countries worldwide. Although requirements vary from country to country, some requirements remain common even though details such as delivery formats may differ. This document describes Cisco's Architecture for supporting lawful intercept in IP networks. It provides a general solution that has a minimum set of common interfaces. This document does not deal with legal requirements or obligations.
サービスプロバイダは、世界中の国々のさまざまなIPネットワークでの法律および規制音声の傍受の要件だけでなく、データ通信を満たすために求められています。要件は国によって異なりますが、いくつかの要件は、このような配信形式などの詳細が異なっていても、共通のまま。この文書では、IPネットワークで合法的傍受をサポートするシスコのアーキテクチャについて説明します。これは、共通インターフェイスの最小セットを有する一般的な解決策を提供します。この文書は、法的要件や義務を扱っていません。
This document describes one method for supporting lawful intercept. Other methods may be available.
この文書では、合法的傍受をサポートするための一つの方法を説明します。他の方法が利用可能であってもよいです。
The IESG wishes to draw the reader's attention to RFC 2804 [15] for a description of why architectures such as these are vendor-specific, rather than a topic of standardization for the IETF.
IESGは、このようなアーキテクチャは、ベンダー固有のではなく、IETFの標準の話題である理由の説明については、RFC 2804 [15]に読者の注意を引くことを望みます。
The purpose of the following list of requirements is to provide an understanding of the motivation behind the architecture and some of the requirements imposed on components and interfaces that are described in the later sections of the document. This does not imply any legal requirements on service providers or equipment vendors although such requirements may coincide.
要件の以下のリストの目的は、建築及び文書の以降のセクションで説明されるコンポーネントおよびインターフェイスに課される要件のいくつかの背後にある動機の理解を提供することです。このような要件が一致していてもよいが、これは、サービスプロバイダーや機器ベンダーの法的要件を意味するものではありません。
Note that there are a variety of requirements that have been defined for lawfully authorized intercept throughout the world. Some of these have been defined by standards bodies (e.g., [13]), while others are country specific. The following itemized list is a distillation of some of these, although a given item may or may not apply to a specific country:
世界中で合法的に許可された切片のために定義されている要件の様々ながあることに注意してください。これらのいくつかは、標準化団体によって定義されている（例えば、[13]）、他のものは、国特定されています。与えられたアイテムがたりない可能性のある特定の国に適用される場合がありますが、以下の項目別リストは、これらのいくつかの蒸留であります：
* Lawful Intercept (LI) should be undetectable by the intercept subject.
・合法的傍受（LI）は、インターセプト対象によって検出不能であるべきです。
* Mechanisms should be in place to limit unauthorized personnel from performing or knowing about lawfully authorized intercepts.
*メカニズムは、実行または合法的に許可を傍受について知るからの不正な人員を制限する場所にする必要があります。
* There is often a requirement (especially for telecommunications services) to provide intercept related information (IRI) separately from the actual Internet Protocol (IP) traffic (or content) of interest (Note: some authorizations may be restricted to IRI).
*興味の実際のインターネットプロトコル（IP）トラフィック（またはコンテンツ）（：一部の権限はIRIに制限される場合があります）とは別に傍受関連情報（IRI）を提供するために、（特に電気通信サービスのための）要件がしばしばあります。
* If IRI is delivered separately from content, there should be some means to correlate the IRI and the content with each other.
* IRIは、コンテンツとは別に配信されている場合は、IRIと相互にコンテンツを相関させるいくつかの手段があるはずです。
* If the information being intercepted is encrypted by the service provider and the service provider has access to the keys, then the information should be decrypted before delivery to the Law Enforcement Agency (LEA) or the encryption keys should be passed to the Law Enforcement Agency to allow them to decrypt the information.
*傍受されている情報は、サービスプロバイダによって暗号化され、サービスプロバイダは、キーへのアクセス権を持っている場合、その情報は、法執行機関（LEA）への配信前に復号化されなければならないか、暗号化キーは、法執行機関に渡す必要があります彼らは情報を復号化できるようにします。
* If the information being intercepted is encrypted by the intercept subject and its associate and the service provider has access to the keys, then the service provider may deliver the keys to the LEA.
*インターセプトの対象とその仲間とサービスプロバイダによって暗号化された傍受されている情報は、キーへのアクセス権を持っている場合は、サービスプロバイダは、LEAに鍵を配信することができます。
* There is often a requirement for a service provider to be able to do multiple simultaneous intercepts on a single subject. The fact that there are multiple intercepts should be transparent to the LEAs.
*一人の被験者に複数の同時インターセプトを行うことができるようにするサービスプロバイダのための要件がしばしばあります。複数のインターセプトがあるという事実は、のLEAに透明であるべきです。
* There is often a requirement that the service provider should not deliver any unauthorized information to the LEA.
*サービスプロバイダがLEAに不正な情報を提供してはならない要件がしばしばあります。
The architecture and interfaces described in this document attempts to address these requirements.
この文書に記載されアーキテクチャ及びインタフェースは、これらの要件に対処することを試みます。
Section 1 of this document lists requirements motivating the architecture. Section 2 of this document describes a reference model along with some operation considerations. Section 3 provides more detailed requirements on the interfaces related to content interception. Section 4 applies the reference model to voice over IP and data intercepts and Section 5 examines security considerations.
このドキュメントのセクション1は、アーキテクチャをやる気要件を示しています。本書の第2章では、いくつかの操作上の考慮事項と一緒に参照モデルを説明しています。セクション3は、コンテンツ傍受に関連するインターフェイスの詳細な要件を提供します。第4章では、IPおよびデータを傍受上で音声に参照モデルを適用し、第5節では、セキュリティ上の考慮事項を検討します。
This section describes a generic reference model (Figure 1) for lawful intercept.
このセクションでは、合法的傍受のための一般的な参照モデル（図1）が記載されています。
+--------------------+ +-----+
| LI Administration | HI1(a) | |
| Function |<--------------| |
+--------------------+ | |
| | |
| MD Provisioning | |
| Interface(b) | LEA |
v | |
+-----------+ +--------------------+ | |
| |<---(c)----| | | |
| IRI IAP |--IRI(e)-->| Mediation |----HI2(g)--->| |
| | | Device (MD) | | |
+-----------+ | |----HI3(h)--->| |
+--------------------+ +-----+
| ^
Intercept | | Intercepted
Request(d) | | Content(f)
| |
v |
+--------------------+
User | Content | User
------->| IAP |-------->
Content +--------------------+ Content
Figure 1: Intercept Architecture
図1：インターセプトアーキテクチャ
A brief description of the interfaces is included in table 1 below. For a more detailed description of the interfaces refer to section 3. For a description of the components refer to section 2.1.
インターフェースの簡単な説明は以下の表1に含まれています。インターフェイスのより詳細な説明のための構成要素の説明についてはセクション3を参照して、セクション2.1を参照します。
Table 1 LI Interfaces
表1 LIのインターフェイス
Interface Description
--------------------- -------------------------------------------
(a) HI1 Handover Interface 1 - Administration
Interface: The LEA provides intercept
information to the service provider
administration function.
(b) MD Provisioning Mediation Device provisioning interface. Parameters include: target identifier, duration of intercept, type of intercept, etc.
（b）は、MDプロビジョニング仲介デバイス・プロビジョニング・インターフェース。パラメータが含まれます：などのターゲット識別子、インターセプトの期間、インターセプトの種類、
(c) IRI IAP Provisioning Specifies Target identifier, duration, etc. for provisioning of delivery of Intercept Related Information (IRI).
インターセプト関連情報（IRI）の送達のプロビジョニングのために（C）等IRI IAPプロビジョニング指定ターゲット識別子、継続時間、。
(d) Content Intercept Provisioning of the Content IAP. Provisioning
（d）の含有量IAPのコンテンツインターセプトプロビジョニング。プロビジョニング
(e) IRI to MD Internal interface between IRI Intercept Access Point (IAP) and Mediation device (MD) for delivery of IRI.
IRIの送達のためのIRIインターセプトアクセスポイント（IAP）と仲介装置（MD）との間のMD内部インターフェースに（e）のIRI。
(f) Content to MD Internal interface between content IAP and MD for delivery of Content.
コンテンツの配信のためにコンテンツIAPとMDの間にMD内部インターフェース〜（f）のコンテンツ。
(g) HI2 Handover Interface 2: Interface between the MD and LEA for delivering IRI. This interface may vary from country to country.
（G）HI2ハンドオーバインタフェース2：IRIを送達するためのMDとLEAとの間のインターフェース。このインタフェースは、国によって異なる場合があります。
(h) HI3 Handover Interface 3: Interface between the MD and LEA for delivering Content. This interface may vary from country to country.
（H）HI3ハンドオーバインタフェース3：コンテンツを配信するためのMDとLEAとの間のインターフェース。このインタフェースは、国によって異なる場合があります。
A brief description of the key components in the reference model is as follows:
次のように参照モデルにおける主要なコンポーネントの簡単な説明です。
Lawful Intercept (LI) Administration Function: This function provides the (typically manual) provisioning interface for the intercept as a result of a court order or warrant delivered by the Law Enforcement Agency (LEA). It could involve separate provisioning interfaces for several components, but more typically is a single interface to the Mediation Device (MD), which then takes care of provisioning of other components in the network. Because of the requirement in some laws to limit accessibility to authorized personnel, the provisioning interface has to be strictly controlled. In many cases, the identity of the subject received from the LEA has to be translated into an identity that can be used by the network to enable the intercept.
合法的傍受（LI）の管理機能：この関数は、法施行機関（LEA）が提供する裁判所命令または令状の結果として、切片のための（通常は手動）のプロビジョニングインタフェースを提供します。これは、いくつかのコンポーネントのために別々のプロビジョニング・インターフェースを含み、より典型的には、ネットワーク内の他のコンポーネントのプロビジョニングの世話をする仲介装置（MD）への単一のインタフェースである可能性があります。そのため許可された人へのアクセスを制限するために、いくつかの法律では要件のため、プロビジョニング・インターフェースを厳密に制御する必要があります。多くの場合、LEAから受信した被写体の同一性は、インターセプトを有効にするためにネットワークによって使用することができるアイデンティティに翻訳されなければなりません。
Intercept Access Point (IAP): An IAP is a device within the network that is used for intercepting lawfully authorized intercept information. It may be an existing device that has intercept capability or it could be a special device that is provided for that purpose. Two types of IAP's are discussed here: IAP's that provide content; and IAP's that provide intercept related information (IRI).
インターセプトアクセスポイント（IAP）：IAPは合法的に許可された切片情報を傍受するために使用されるネットワーク内のデバイスです。これは、インターセプト能力を持っている既存のデバイスであってもよいし、その目的のために提供される特別なデバイスである可能性があります。 IAPの二つのタイプがここで説明されていますIAPのコンテンツを提供しています。そして、IAPのインターセプト関連情報（IRI）を提供します。
Content IAP: A content IAP is an IAP that is used to intercept the IP traffic of interest.
コンテンツIAP：コンテンツIAPは、関心のIPトラフィックを傍受するために使用されるIAPです。
IRI IAP: This is an IAP that is used to provide intercept related information (IRI).
IRI IAP：これは、インターセプト関連情報（IRI）を提供するために使用されるIAPです。
Law Enforcement Agency (LEA): This is the agency that has requested the intercept and to which the service provider delivers the information.
法執行機関（LEA）：これはインターセプトを要求していると、サービスプロバイダが情報を提供している機関です。
Mediation Device (MD): The MD requests intercepts from IAPs through interfaces (c) and (d) in Figure 1. The Mediation Device receives the data from the IAP, packages it in the correct format (which may vary from country to country) and delivers it to the LEA. In the case where multiple law enforcement agencies are intercepting the same subject, the mediation device may replicate the information multiple times. The assumption is that the service provider operates the MD (via specially authorized personnel) and that the LEA only has access to interfaces (a), (g) and (h) in Figure 1.
仲介装置（MD）は：MDは、（国によって異なり得る）正しい形式でパッケージ化し、仲介装置は、IAPからデータを受信する図1のインターフェース（c）および（d）を介してのIAPからインターセプトを要求しますそしてLEAに配信します。複数の法執行機関は、同じ主題を傍受している場合には、仲介装置は、情報を複数回複製し得ます。仮定は、サービスプロバイダは（特別に許可された人を介して）およびLEAのみ（A）、（g）及び（h）は図1のインターフェイスへのアクセスを有することMDを操作することです。
In a typical operation, a lawfully authorized surveillance request arrives for a specified intercept subject. Authorized personnel provision the intercept using interface (b) in Figure 1, which may be for content only, IRI only or both. Once the intercept is provisioned, the IAP's send the IRI and/or content to the MD, which formats the information into the appropriate format for delivery to the LEA. Some operational issues that need to be considered:
典型的な動作では、合法的に許可された監視要求は、指定された切片被験者について到来します。許可された人の提供のみ、IRIのみ、または両方のコンテンツであってよい。図1にインタフェース（B）を用いて切片。切片がプロビジョニングされると、IAPのはLEAへの配信に適したフォーマットに情報をフォーマットMDにIRI及び/又はコンテンツを送信します。検討する必要があるいくつかの運用上の問題：
* Location and Address Information for Content Intercepts: In some cases where the location and/or addressing information for the intercept is not known until the subject registers (or makes a call in the case of voice), the IRI may provide needed information in order to do the content tap (e.g., the IP address and port for the content streams).
*位置とコンテンツインターセプトするためのアドレス情報：切片の位置および/またはアドレス情報は、対象レジスタまで知られている（又は音声の場合にコールを行う）されていないいくつかのケースでは、IRIは、ために必要な情報を提供することができますコンテンツタップ（コンテンツストリームのための例えば、IPアドレスとポート）を行います。
* Content Encryption: If the intercept content is encrypted and the service provider has access to the encryption keys (e.g., receives keys in Session Description Protocol for Voice over IP), then the keys can be sent via IRI. It is, however, possible for end-users to exchange keys by some other means without any knowledge of the service provider in which case the service provider will not be able to provide the keys. Content transformations could make decryption at the LEA impossible. This is why the original packets are provided on interface (f) rather than attempting to convert them to some other format.
*コンテンツ暗号化：インターセプトコンテンツは暗号化され、サービスプロバイダは、暗号化キー（例えば、ボイスオーバーIPのためのセッション記述プロトコルのキーを受け取る）へのアクセス権を持っている場合は、そのキーがIRIを経由して送信することができます。エンドユーザは、サービスプロバイダがキーを提供することができなくなり、その場合、サービス・プロバイダの知識なしに、いくつかの他の手段によって鍵を交換することは、しかしながら、可能です。コンテンツ変換は不可能LEAで復号化を行うことができます。元のパケットがなく、いくつかの他の形式に変換しようとするよりも、インタフェース（F）上に設けられている理由です。
* Detection by the Intercept Subject: One requirement is to ensure that the intercept subject is unable to detect that they are being intercepted. This document assumes a sophisticated subject:
*インターセプト件名による検出：一つの要件は、インターセプト対象は、彼らが傍受されていることを検出することができないようにすることです。この文書では、洗練された主題を前提としています。
- Able to check IP addresses, use traceroute, etc.
- tracerouteを使用し、IPアドレスをチェックすることができる、など
- Able to check if any unusual signaling is occurring on their customer premises equipment (CPE).
- 異常なシグナル伝達は、顧客宅内機器（CPE）で発生しているかどうかを確認することできます。
- Able to detect degradation or interruptions in service.
- サービスの低下や中断を検出することができ。
This is why the intercept mechanism described here does not involve special requests to the CPE, re-routing of packets or end-to-end changes in IP addresses. Instead, content intercept is done on a device along the normal content path (i.e., no re-routing has occurred) that is within the service provider's network. A convenient content IAP is a router or switch at the edge of the service provider's network to which the intercept subject connects. This is illustrated in Figure 2.
ここで説明インターセプトメカニズムは、CPEへの特別なリクエスト、IPアドレスでパケットまたはエンド・ツー・エンドの変更の再ルーティングを必要としないのはこのためです。代わりに、コンテンツ・インターセプトは、サービスプロバイダのネットワーク内にある通常のコンテンツパス（すなわち、全く再ルーティングが発生していない）に沿って、デバイス上で行われます。便利コンテンツIAPは、インターセプト対象の接続にサービスプロバイダのネットワークのエッジにあるルータまたはスイッチです。これは、図2に示されています。
|
Customer Premises | Service Provider's Network
|
+-------+
+-----+ | |
| CPE |-------------| Router|----------
+-----+ | (IAP) |
| |
+-------+
Figure 2 Content IAP - Router
図2のContent IAP - ルータ
Another possibility of course is to provide a special device along the path to provide the content IAP capabilities.
もちろん、別の可能性は、コンテンツIAP機能を提供するために、パスに沿って特殊な装置を提供することです。
Note that in the case where there is multi-homing (two or more routers connected to provide access for the CPE), intercept taps may have to be installed on more than one access router. If the CPE is multi-homed to multiple service providers, then the intercept will have to be installed on each service provider separately and the LEA will have to correlate the data.
マルチホーミング（CPEのためのアクセスを提供するために接続された二つ以上のルータ）がある場合にはなお、インターセプト・タップは、複数のアクセスルータにインストールされなければなりません。 CPEは、複数のサービスプロバイダにマルチホームの場合、インターセプトは、別途各サービスプロバイダにインストールする必要がありますし、LEAは、データを相関させる必要があります。
* Unauthorized Creation and Detection: Another concern is the prevention of unauthorized creation and detection of intercepts. This is particularly important when a network element such as a router is used as a content IAP. Those routers that have the capability should be carefully controlled with access to intercept capability and information only via authorized personnel. In one approach using the reference model in Figure 1, the MD is in a controlled environment and the MD does the intercept request to the content IAP over an encrypted link. Logging and auditing are used to detect unauthorized attempts to access the intercept capability.
*不正な作成と検出：もう一つの懸念は、無許可の作成とインターセプトの検出の防止です。ルータなどのネットワーク要素は、コンテンツIAPとして使用される場合、これは特に重要です。能力を持つこれらのルータは慎重にのみ許可された人を経由してインターセプト能力と情報へのアクセスを制御する必要があります。図1の参照モデルを使用して1つのアプローチでは、MDは、制御された環境であり、MDは、暗号化されたリンクを介してコンテンツIAPにインターセプト要求を行います。ロギングおよび監査をインターセプト機能にアクセスする権限のない試みを検出するために使用されます。
* Capacity: Support for lawful intercept on a network element supporting customers consumes resources on that equipment. Therefore, support for lawful intercept requires capacity planning and engineering to ensure that revenue-producing services are not adversely affected.
*容量：顧客をサポートするネットワーク要素上の合法的傍受のサポートは、その機器上のリソースを消費します。したがって、合法的傍受のサポートが収益をもたらすサービスが悪影響を受けないことを保証するために、キャパシティプランニングとエンジニアリングが必要です。
This section provides a brief description of the interfaces in the reference model (Figure 1). A list of these interfaces is included in Table 1 in Section 2.
このセクションでは、参照モデルのインターフェイス（図1）の簡単な説明を提供します。これらのインタフェースのリストは、第2表1に含まれています。
One of the objectives in defining these interfaces is to keep the internal interfaces (b to f) the same regardless of country-specific requirements. The MD then formats the IRI and the content to meet the country specific requirements for interfaces (g) and (h).
これらのインタフェースを定義する目的の1つは、国固有の要件に関係なく同じ（Fに対するB）内部インターフェイスを維持することです。 MDは、次に国をインターフェイス（g）及び（h）のための特定の要件を満たすために、IRIとコンテンツをフォーマットします。
This section describes some of the requirements for the content intercept request interface (d) in Figure 1. It makes use of a common request protocol (SNMPv3) regardless of the type of application (e.g., voice, data) and suggests the usage of a TAP-MIB, which is defined in a separate document [1]. Some of the considerations that lead to the use of SNMPv3 and to the definition of the specific Management Information Base (MIB) defined in [1] are provided here.
このセクションでは、それは関係なく、アプリケーション（例えば、音声、データ）のタイプの一般的な要求プロトコル（SNMPv3の）を利用する図1のコンテンツインターセプト要求インターフェース（D）の要件のいくつかを説明し、の使用を示唆しています別の文書で定義されているTAP-MIB、[1]。 SNMPv3の使用にして、[1]ここで提供されている中で定義された特定の管理情報ベース（MIB）の定義につながる考慮事項の一部。
In order to provide a generic interface for intercepting, replicating, encapsulating and transporting content packets to the MD, the content intercept interface ((d) in Figure 1) should specify:
MDへのコンテンツパケットを傍受複製、カプセル化および輸送するための汎用インタフェースを提供するために、コンテンツ・インターセプト・インターフェース（図1の（D））を指定してください。
* A Filter specification for classifying the packets to be intercepted.
傍受するパケットを分類するための*フィルタ仕様。
* The destination address of the MD (where to send the packets).
* MDの宛先アドレスは、（ここで、パケットを送信するために）。
* Encapsulation and Transport parameters.
*カプセル化と輸送パラメータ。
In addition, a timeout value for the intercept should also be specified. This defines a limited lifetime for the intercept so that failures will not result in intercepts remaining beyond their authorized lifetime. If a failure of the MD occurs such that it is not able to supply the refresh to the timeout, then the intercept will cease to exist after the timeout expires. Similarly, if the IAP re-boots, then the intercept will not survive the re-boot unless the IAP is capable of ascertaining that the intercept lifetime requirements will continue to be met.
また、インターセプトのタイムアウト値も指定する必要があります。失敗が彼らの許可期間を超えて、残りのインターセプトにはなりませんように、これは、傍受のための限られた寿命を定義します。 MDの失敗はタイムアウトにリフレッシュを供給することができないように発生した場合、インターセプトは、タイムアウトの期限が切れた後に存在しなくなります。 IAPは、インターセプト寿命の要件が満たされていくことを確認することができない限り、同様に、IAPを再起動する場合は、その後、切片は再起動後も存続しません。
In order for this to work, it must be possible for the mediation device to realize that there is a failure in the IAP such that it must re-establish the intercept. This may be in the form of an audit (from the MD to the IAP), or in the form of a heartbeat mechanism in the content stream, or both.
仲介装置は、それがインターセプトを再確立しなければならないようなIAPに障害があることを実現するためにのために働くために、このためには、それが可能でなければなりません。これは、（IAPへMDから）監査の形態であっても、またはコンテンツストリーム、またはその両方にハートビート機構の形態でもよいです。
The encapsulation method should retain all of the information in the original packets (source and destination addresses as well as payload) and provide an identifier for correlating the packets with the IRI. One encapsulation that meets those requirements is described in Section 4 of [2]. For non-voice intercepts, the "Intercepted Information" field in Table 1 of [2] contains the original intercepted IP packet.
カプセル化方法は、元のパケット（ソースおよび宛先アドレス、ならびにペイロード）の情報の全てを保持し、IRIを有するパケットを関連付けるための識別子を提供しなければなりません。これらの要件を満たす一つのカプセル化[2]のセクション4に記載されています。非音声傍受するため、[2]原稿を含有する表1の「インターセプト情報」フィールドは、IPパケットを傍受しました。
Note, however, that the interface defined in [2] is based on UDP which is an unreliable and unordered transport protocol (i.e., provides neither retransmission on detection of errors nor ordering of data). If this transport is used, the underlying network (Layers 1 - - 3) should be engineered to meet the overall reliability requirements for delivery of content.
ただし、[2]で定義されたインターフェースを（すなわち、エラーの検出やデータの順序にも再送信を提供する）信頼できないと順序付けられていないトランスポートプロトコルであるUDPに基づくものであること。このトランスポートが使用される場合、基礎となるネットワーク（レイヤ1 - - 3）は、コンテンツの配信のための全体的な信頼性要件を満たすように設計するべきです。
If a more reliable transport protocol is required, then a mechanism that provides timely delivery as well as limits the burden (both processing and buffering) on the Content IAP should be used. One mechanism that meets these requirements is a NACK-oriented retransmission scheme based on [12].
より信頼性の高いトランスポートプロトコルが必要な場合は、タイムリーな配信を提供するだけでなく、コンテンツIAPの負担（処理及びバッファリングの両方）を制限するメカニズムを使用すべきです。これらの要件を満たしている1つのメカニズムは、[12]に基づいてNACK指向再送方式です。
If [12] is used, the call content channel identifier may be placed in the SSRC field of the encapsulating RTP packet. The payload type may be used to identify the type of packet encapsulated in RTP (e.g., IP, PPP, Ethernet MAC). Note that usage of [12] is still under investigation and may need further specification. Usage of [12] in the content IAP places more processing burden on the content IAP than a UDP-based intercept and can affect the capacity of the content IAP.
[12]が使用される場合、通話コンテンツチャネル識別子が封入RTPパケットのSSRCフィールドに配置することができます。ペイロードタイプは、RTP（例えば、IP、PPP、イーサネットMAC）にカプセル化されたパケットの種類を識別するために使用されてもよいです。 [12]の使用量はまだ調査中であり、さらに仕様を必要とするかもしれないことに留意されたいです。コンテンツ内[12]の使用方法は、IAPは、UDPベースの切片よりもコンテンツIAP上のより多くの処理負担を置き、コンテンツIAPの能力に影響を与えることができます。
This section applies the reference model to some example applications.
このセクションでは、いくつかのサンプルアプリケーションへの参照モデルを適用します。
This section will look at some of the issues surrounding interception of voice over IP calls, taking local voice services as a specific service example. The reference model from Figure 1 will be applied with the use of a common set of interfaces that are independent of the call signaling protocols in use.
このセクションでは、特定のサービスの例として、ローカル音声サービスを取って、IP通話、ボイスオーバーの傍受を取り巻く問題のいくつかを見ていきます。図1の参照モデルは、使用中のプロトコルシグナリングコールから独立しているインターフェイスの共通のセットを使用して適用されます。
There are a variety of architectures in use for voice over IP (e.g., centralized versus distributed) as well as various protocols (SIP [6], H.323 [9], MGCP [7], H.248 [8]). There are also a variety of services that may be offered:
IP上の音声に使用されているアーキテクチャの様々な（分散対例えば、集中型）ならびに様々なプロトコル（SIP [6]、323 [9]、MGCP [7]、H.248 [8]）が存在します。提供されるサービスの様々なもあります。
* Local Voice Services (i.e., service to a user that has an IP phone or a phone connected to a gateway)
*ローカル音声サービス（すなわち、IP電話またはゲートウェイに接続された電話機を持つユーザーへのサービス）
* Transit services
*トランジットサービス
* Long distance access services (e.g., calling/debit card).
*長距離アクセスサービス（例えば、通話/デビットカード）。
This document does not address any obligations that a service provider might or might not have to support intercepts. It simply describes how intercept might be done using the reference model in Figure 1.
このドキュメントでは、サービスプロバイダがまたはインターセプトをサポートするために持っていないかもしれない可能性のある義務を扱っていません。これは単に、切片が図1の参照モデルを使用して行われるかもしれない方法を説明します。
Note that in the case of services where the intercept subject accesses the network via a non-IP endpoint (e.g., TDM), the detectability issue is less acute (e.g., re-routing of packets to intercept them in a special device is a possible option), since the intercept subject does not have access to the IP addresses or to traceroute.
特殊なデバイスでそれらを傍受するパケットの例えば、再ルーティング（傍受対象者が非IPエンドポイントを介してネットワークにアクセスするサービスの場合（例えば、TDM）で、検出可能性の問題はそれほど深刻であることに注意してください可能ですオプション）、傍受対象者がIPアドレスまたはトレースルートへのアクセス権を持っていないので。
However, in the case of local services, this is a much more difficult problem. The intercept for a call originating and terminating on-net (i.e., a call that is voice over IP end-to-end) has to be intercepted along its normal route in order to be undetectable. In addition, the call-forwarding feature that is often provided as a local service feature makes interception even more difficult: If call forwarding is invoked, a call that was intended to terminate on the intercept subject may be forwarded anywhere in the network resulting in the media stream bypassing the original content IAP (since in voice over
しかし、ローカルサービスの場合には、これははるかに難しい問題です。オンネット発信および着信コールのための切片（すなわち、IPエンド・ツー・エンドのボイスオーバーである呼）は検出不可能であるためにその通常の経路に沿ってインターセプトされなければなりません。呼転送が起動された場合、意図されたコールは傍受対象で終端することで得られたネットワーク内の任意の場所に転送することができる。また、多くの場合、ローカルサービス機能として提供される呼転送機能がさらに困難傍受を行いますオリジナルコンテンツIAPをバイパスして、メディアストリーム（オーバー声で以来、
IP, the media stream goes directly from end-to-end). Also, since call forwarding can often be set up on a call-by-call basis, the location of the content IAP will often not be known until the call is set up.
IPは、メディアストリームは、エンド・ツー・エンド）から直接行きます。コール転送は、多くの場合、コールごとに設定することができますので、呼が設定されるまで、また、コンテンツIAPの場所は、多くの場合、知られることはありません。
This sub-section will look at the specific case in which the intercept subject under surveillance is being provided with a local voice service by the same provider that also provides the network access (e.g., controls the edge router or switch). This is an important assumption, since in VoIP the entity providing call control (e.g., SIP server) can be totally separate from the entity providing network access (e.g., operates edge routers).
このサブセクションでは、監視下の切片主題はまた、（例えば、エッジルータ又はスイッチを制御する）ネットワークアクセスを提供するのと同じプロバイダによって、ローカル音声サービスが提供されている特定の場合を見てみましょう。 VoIPの呼制御（例えば、SIPサーバ）を提供するエンティティは、ネットワークアクセスを提供するエンティティから完全に分離することができるので、これは（例えば、エッジルータを操作）、重要な仮定です。
Suppose that a subscriber that subscribes to a local (e.g., residential) voice service is a target for a lawfully authorized surveillance. Part of the system providing these services is a subscriber database that includes addressing information about the subscriber as well information on what features are in effect (e.g., call forwarding). Some call control entity (CCE) accesses that database in order to provide local services. For example, if the subject has call forwarding invoked, that fact (and where to forward the call) is indicated in the subscriber database. A call arriving at the CCE that "owns" that subscriber can then take the appropriate action (e.g., forward the call).
局所（例えば、住宅）の音声サービスに加入し、加入者が合法的に許可された監視の標的であると仮定する。これらのサービスを提供するシステムの一部は、（例えば、転送呼び出し）有効であるどのような機能に十分な情報として、加入者についてのアドレス情報を含む加入者データベースです。いくつかの呼制御エンティティ（CCE）は、ローカルサービスを提供するために、そのデータベースにアクセスします。被験者が呼び出さ呼転送を有する場合、例えば、その事実は、（どこコールを転送する）加入者データベースに示されています。 （例えば、コールを転送）は、加入者は、適切な行動を取ることができ、「所有する」ことをCCEに到着コール。
The CCE that "owns" the target subscriber (which could be an H.323 gatekeeper, a SIP proxy or a Media Gateway Controller) is provisioned with the intercept parameters (e.g., subject identification information such as the telephone number and where to deliver the IRI). The provisioning of this CCE could be through interface (c) in Figure 1. The CCE in question is the IRI IAP and once provisioned, it passes the IRI to the MD. In the scenario being discussed, the CCE typically remains in the signaling path throughout the call, even in the call-forwarding case. Part of the IRI it passes to the MD is the media signaling information (i.e., SDP [11] or H.245 [10]), which includes endpoint IP address and port information for the media (content) streams. Armed with this media address information, the MD can determine the content IAP (e.g., [5]) and make the request via interface (d). The request identifies the voice stream to be intercepted based on information received in the call signaling (i.e., IP addresses and UDP port numbers).
（H.323ゲートキーパーとすることができる、SIPプロキシまたはメディアゲートウェイコントローラ）対象加入者を「所有」は切片パラメータ（例えば、電話番号などの対象識別情報をプロビジョニングし、送達することであることCCE IRI）。このCCEのプロビジョニングは、図1、問題のCCEのインターフェイス（C）を介してであってもよいIRI IAPであり、一度にプロビジョニングは、MDにIRIを渡します。議論されているシナリオでは、CCEは、一般的にも、コールフォワーディングの場合に、コール全体を通してシグナリングパスに留まります。それはMDに渡すIRIの一部（すなわち、SDP [11]またはH.245 [10]）、メディア（コンテンツ）のエンドポイントのIPアドレスおよびポート情報を含むストリーム情報をメディアシグナリングです。このメディアのアドレス情報で武装し、コンテンツIAPを決定することができるMD（例えば、[5]）及びインターフェース（D）を介して要求を行います。要求は、呼シグナリング（すなわち、IPアドレスおよびUDPポート番号）で受信した情報に基づいて傍受される音声ストリームを識別する。
Note that the content IAP in the case of voice over IP could be an edge router or a PSTN gateway (e.g., a call from the PSTN forwarded to the PSTN). SIP, H.323, MGCP or H.248 call signaling protocols could be used. However, the protocol (SNMPv3 [1]) used for interface
ボイスオーバーIPの場合のコンテンツIAPがあり得ることに留意されたいエッジルータ又はPSTNゲートウェイ（例えば、PSTNに転送PSTNからの呼）。 SIP、H.323、MGCPまたはH.248コールシグナリングプロトコルを使用することができます。しかし、プロトコルは（SNMPv3の[1]）インタフェースのために使用しました
(d), is not dependent on the type of call signaling protocol used; nor is the encapsulation format and transport protocol (interface "f"). The same reference model (Figure 1) with the same interfaces can be used for lawfully authorized surveillance, regardless of the signaling protocol and regardless of the type of service being provided (Note: even though a local voice service was used in this example, other voice services could use the same model and interfaces).
（d）は、使用されるコールシグナリングプロトコルの種類に依存しません。カプセル化フォーマットおよびトランスポート・プロトコル（インタフェース「F」）です。ローカル音声サービスは、この例で使用したにもかかわらず、他の：同じインタフェースを持つ同一の参照モデル（図1）（注かかわらず、シグナリングプロトコルのと関係なく提供されるサービスのタイプの、合法的に許可された監視のために使用することができます音声サービスは、同じモデルとインタフェース）を使用することができます。
The same model (Figure 1) can also be used for data services. In this case the IRI IAP could be a server that acts as registration, authentication and authorization point for the data service (e.g., a RADIUS server). If a potential IRI IAP does not have the available interfaces (c) and (e), the MD may have to do a content tap on registration signaling in order to obtain the IRI.
同じモデル（図1）は、データサービスのために使用することができます。この場合、IRI IAPは、データサービス（例えば、RADIUSサーバ）の登録、認証および認可ポイントとして機能するサーバであってもよいです。電位IRI IAPが利用可能なインタフェース（c）および（e）を持っていない場合、MDは、IRIを得るために、登録シグナリングのコンテンツタップを実行する必要があります。
The IRI in the case of a data service could include:
データサービスの場合、IRIは含めることができます：
* The time that the user registered or de-registered for the service. * Addressing information (i.e., given the user identity, what IP address or other information is available that could be used in interface (d) to do the content tap).
*ユーザー登録やサービスの登録解除した時刻。 *アドレス情報（すなわち、ユーザのアイデンティティが与えられると、どのIPアドレスまたは他の情報は、コンテンツタップを行うためのインタフェース（d）で使用することができること入手可能です）。
Once suitable addressing information is available in order to do content tapping the MD can invoke the tap via interface (d).
一度、適切なアドレス情報は、インターフェース（D）を介してタップを呼び出すことができるMDをタップするコンテンツを実行するために利用可能です。
Clearly the IRI interfaces (c, e, g) are different for data than they are for voice services. However, the content IAP is typically the same (an edge router). Interfaces (d, f, and h) may also be the same.
明確IRIインタフェース（C、E、G）は、それらが音声サービスのためのものよりも、データのために異なっています。しかし、コンテンツIAPは、典型的には、（エッジルータ）と同じです。インターフェース（D、F、およびH）は、同じであってもよいです。
Given the sensitive nature of lawful intercept (LI) -- both from the standpoint of the need to protect sensitive data, as well as conceal the identities of the intercept subjects, the LI solution should have the ability to provide stringent security measures to combat threats such as impersonation of MD's, privacy and confidentiality breaches, as well as message forgery and replay attacks.
合法的傍受（LI）の敏感な性質を考える - 機密データを保護するだけでなく、傍受対象者の身元を隠すために必要という観点から、LIソリューションは、脅威に対抗するための厳格なセキュリティ対策を提供する能力を持っている必要があり、両方のMD等の、プライバシーや機密性侵害の偽装と同様に、メッセージ偽造やリプレイ攻撃など。
While this document doesn't discuss issues of physical security, operating system, or application hardening within the principals of the LI solution, they are clearly important. In particular, the MD server would be considered a prime target for attacks.
この文書は、LIソリューションのプリンシパル内硬化物理的なセキュリティ、オペレーティングシステム、またはアプリケーションの問題を議論しませんが、彼らは明らかに重要です。特に、MDサーバが攻撃の主なターゲットと考えられます。
In general, all interfaces should have the capability of providing strong cryptographic authentication to establish the identity of the principals, and be able to correlate the identity of the principal with the action they are attempting to perform. All interfaces should be capable of performing some sort of cryptographic message integrity checking such as, for example, HMAC-MD5. Message integrity checking can also be used to counter replay attacks. Privacy and confidentiality considerations, may also require the use of encryption.
一般的には、すべてのインターフェイスは、プリンシパルのアイデンティティを確立するための強力な暗号化認証を提供する能力を持っている、と彼らは実行しようとしている行動とのプリンシパルのIDを関連付けることができるはずです。すべてのインターフェイスは、例えば、HMAC-MD5、として確認暗号化メッセージ整合性のいくつかの並べ替えを行うことが可能であるべきです。メッセージの整合性チェックはまた、リプレイ攻撃対抗するために使用することができます。プライバシーと機密性の考慮事項は、また、暗号化を使用する必要があります。
The content and IRI IAPs also should also provide protection of the identity of the intercept subject and the existence of an intercept.
コンテンツおよびIRI IAPはまた、また、傍受対象のアイデンティティと切片の存在の保護を提供する必要があります。
For interface (d,) native SNMPv3 security module mechanism is used. The additional requirement is that the IAP should support the ability to protect the TAP MIB's [1] from disclosure or control by unauthorized USM [3] users. VACM [4] provides the necessary tools to limit the views to particular USM users, but there are also special considerations:
インターフェース（D）のネイティブSNMPv3セキュリティモジュール機構が使用されます。追加の要件は、IAPは、TAP MIBの[1]不正USMによって開示または制御[3]からユーザーを保護する機能をサポートしなければならないことです。 VACM [4]特定のUSMユーザにビューを制限するために必要なツールを提供するが、特別な配慮もあります。
* The ability to limit access to the appropriate TAP MIB's by only those SNMPv3 USM users which have keys established and the proper VACM views defined.
キーが確立し、適切なVACMビューが定義されているのみのSNMPv3 USMユーザーによって適切なTAP MIB年代へのアクセスを制限する*能力。
* Segregation of the TAP MIB such that only operators of sufficient privilege level can create VACM views that include the TAP MIB [1].
* TAP MIBの分離に十分な特権レベルのみオペレータがTAP MIB [1]を含むVACMビューを作成できるようにします。
[1] Baker, F., "Cisco Lawful Intercept Control MIB", Work in Progress, April 2004.
[1]ベイカー、F.、 "シスコ合法的傍受コントロールMIB"、進歩、2004年4月に作業。
[2] PacketCable(TM) Electronic Surveillance Specification, PKT-SP-ESP-I04-040723, http://www.packetcable.com/specifications/
[2]のPacketCable（商標）電子監視仕様、PKT-SP-ESP-I04-040723、http://www.packetcable.com/specifications/
[3] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[3]ブルーメンソール、U.とB. Wijnenの、 "ユーザベースセキュリティモデル（USM）簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のために"、STD 62、RFC 3414、2002年12月。
[4] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[4] Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、STD 62、RFC 3415、2002年12月。
[5] Warnicke, E., "A Suggested Scheme for DNS Resolution of Networks and Gateways", Work in Progress.
[5] Warnicke、E.、「DNSネットワークスの解像度およびゲートウェイの推奨制度」が進行中で働いています。
[6] 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.
[6]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[7]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（MGCP）バージョン1.0"、RFC 3435、2003年1月。
[8] ITU-T Recommendation H.248.1, Gateway Control Protocol: Version 2, May 2002.
[8] ITU-T勧告H.248.1、ゲートウェイ制御プロトコル：バージョン2、2002年5月。
[9] ITU-T Recommendation H.323, Packet-based Multimedia Communications Systems, July 2003.
[9] ITU-T勧告H.323、パケットベースのマルチメディア通信システム2003年7月を。
[10] ITU-T Recommendation H.245, Control Protocol for Multimedia Communications, July 2003.
[10] ITU-T勧告H.245、マルチメディア通信のための制御プロトコル、2003年7月。
[11] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[11]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[12] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenber, "RTP Retransmission Payload Format", Work in Progress.
[12]レイ、J.、レオン、D.、宮崎、A.、Varsa、V.、およびR. Hakenber、 "RTP再送信ペイロードフォーマット"、ProgressのWork。
[13] ETSI TS 101 331, Telecommunications security; Lawful Interception (LI); Requirements of law enforcement agencies.
[13] ETSI TS 101 331、通信セキュリティ、合法的傍受（LI）。法執行機関の要件。
[14] ETSI TS 33.108 v6.7.0, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Handover Interface for Lawful Interception (Release 6).
[14] ETSI TS 33.108 v6.7.0、第3世代パートナーシッププロジェクト。グループサービス及びシステムアスペクト技術仕様; 3Gセキュリティ;合法的傍受のためのハンドオーバ・インタフェース（リリース6）。
[15] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[15] IABとIESG、 "盗聴のIETF方針"、RFC 2804、2000年5月。
CCE Call Control Entity CMTS Cable Modem Termination System CPE Customer Premises Equipment ETSI European Telecommunications Standards Institute GPRS Generalized Packet Radio Service HMAC-MD5 Hash-based Message Authentication Code - Message Digest 5 IAP Intercept Access Point IETF Internet Engineering Task Force IRI Intercept Related Information ITU-T International Telecommunications Union - Telecommunications Sector LEA Law Enforcement Agency LI Lawful Intercept MGCP Media Gateway Control Protocol MD Mediation Device MIB Management Information Base NACK Negative Acknowledgement PSTN Public Switched Telecommunications Network RFC Request for Comment RTP Real-time Transport Protocol SDP Session Description Protocol SIP Session Initiation Protocol SSRC Synchronization Source TDM Time Division Multiplex UDP User Datagram Protocol USM User Service Model VACM View-based Access Control Model VoIP Voice over IP
CCEコール制御エンティティCMTSケーブルモデム終端システムのCPE顧客宅内機器ETSI欧州電気通信標準化協会GPRS汎用パケット無線サービスHMAC-MD5ハッシュベースメッセージ認証コード - メッセージダイジェスト5 IAPインターセプトアクセスポイントIETFインターネットエンジニアリングタスクフォースIRIインターセプト関連情報ITU -T国際電気通信連合 - 電気通信セクターLEA法執行機関LI合法的傍受MGCPメディアゲートウェイコントロールプロトコルMDの仲介装置MIB管理情報ベースNACK否定応答PSTNパブリック・コメントのRTPリアルタイム転送プロトコルSDPセッション記述プロトコルSIPのための通信ネットワークRFC要求を交換IP経由のセッション開始プロトコルSSRC同期ソースTDM時分割多重UDPユーザーデータグラムプロトコルUSMユーザーサービスモデルVACMビューベースアクセス制御モデルのVoIP音声
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッドベイカーシスコシステムズ1121ヴィアデル・レイサンタバーバラ、カリフォルニア州93117米国
Phone: +1-408-526-4257 Fax: +1-413-473-2403 EMail: fred@cisco.com
電話：+ 1-408-526-4257ファックス：+ 1-413-473-2403 Eメール：fred@cisco.com
Bill Foster Cisco Systems Suite 2150 1050 West Pender St. Vancouver, BC, V6E 3S7 Canada
ビル・フォスターシスコシステムズスイート2150 1050ウェスト・ペンダーセントバンクーバー、BC、V6E 3S7カナダ
Phone: +1-604-647-2315 EMail: bfoster@cisco.com
電話：+ 1-604-647-2315 Eメール：bfoster@cisco.com
Chip Sharp Cisco Systems 7025 Kit Creek Road RTP, NC 27709 USA
チップシャープシスコシステムズ7025キットクリーク道路RTP、NC 27709 USA
Tel:+1.919.392.3121 EMail: chsharp@cisco.com
電話：+1.919.392.3121電子メール：chsharp@cisco.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。