[要約] 要約：RFC 3924は、IPネットワークでの合法的な傍受のためのシスコのアーキテクチャについての規格です。 目的：このRFCの目的は、法的な傍受要件を満たすために、IPネットワーク上での傍受機能を提供するためのガイドラインを提供することです。
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
IPネットワークにおける合法的な傍受のためのシスコアーキテクチャ
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）The Internet Society（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用などのIETFレビューに基づいていないことに注意してください。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。
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ネットワークでの合法的な傍受をサポートするためのCiscoのアーキテクチャについて説明しています。一般的なインターフェイスの最小セットを備えた一般的なソリューションを提供します。この文書は、特定の国に存在する可能性のある特定の法的要件または義務に対処しようとはしていません。
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を介して実行される可能性のあるいくつかのサービス（例：Voice over IP）またはIPが上（GPRSなど）で実行される可能性がある場合に定義されています。たとえば、Voice over 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.
関連する情報：ターゲットID、特に通信関連情報またはデータ（たとえば、通信の試みの失敗）、サービス関連情報またはデータおよび位置情報を含む電気通信サービスに関連する情報またはデータの収集。
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ネットワークでの合法的な傍受をサポートするためのCiscoのアーキテクチャについて説明しています。一般的なインターフェイスの最小セットを備えた一般的なソリューションを提供します。この文書は、法的要件や義務を扱っていません。
This document describes one method for supporting lawful intercept. Other methods may be available.
このドキュメントでは、合法的な傍受をサポートする1つの方法について説明します。他の方法が利用可能になる場合があります。
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.
* 多くの場合、サービスプロバイダーが単一の主題で複数の同時インターセプトを実行できる必要があります。複数のインターセプトがあるという事実は、LEASに対して透明でなければなりません。
* 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オーバー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).
(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.
(e) IRIインターセプトアクセスポイント（IAP）とMediation Device（MD）の間のIRIインターセプトアクセスポイント（MD）の間のIRIからMDインターフェイス。
(f) Content to MD Internal interface between content IAP and MD for delivery of Content.
(f) コンテンツの配信のためのコンテンツIAPとMD間のMD内部インターフェイスへのコンテンツ。
(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).
Intercept Access Point（IAP）：IAPは、合法的に認可されたインターセプト情報を傍受するために使用されるネットワーク内のデバイスです。インターセプト機能を備えた既存のデバイスであるか、その目的のために提供される特別なデバイスである可能性があります。ここでは、2種類のIAPについて説明します。コンテンツを提供するIAP。Interceptに関連する情報（IRI）を提供するIAP。
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は、図1のインターフェイス（c）および（d）を介してIAPからインターセプトを要求します。調停デバイスはIAPからデータを受信し、正しい形式でパッケージ化します（これは国によって異なる場合があります）そして、それをリーに届けます。複数の法執行機関が同じ主題を傍受している場合、調停装置は情報を複数回複製することができます。仮定は、サービスプロバイダーがMD（特別に認可された人員を介して）を運用し、LEAは図1のインターフェイス（a）、（g）、（h）にのみアクセスできることです。
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:
典型的な操作では、指定されたインターセプト被験者に対して合法的に承認された監視要求が届きます。承認された人員は、図1のインターフェイス（b）を使用してインターセプトを提供します。インターセプトがプロビジョニングされると、IAPはIRIおよび/またはコンテンツをMDに送信し、LEAへの配信のために情報を適切な形式にフォーマットします。考慮する必要があるいくつかの運用上の問題：
* 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.
* コンテンツの暗号化：インターセプトコンテンツが暗号化され、サービスプロバイダーが暗号化キーにアクセスできる場合（たとえば、Voice Over 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:
* インターセプト対象による検出：1つの要件は、インターセプトの被験者がインターセプトされていることを検出できないことを確認することです。このドキュメントは、洗練された主題を想定しています。
- Able to check IP addresses, use traceroute, etc.
- IPアドレスを確認したり、Tracerouteを使用したりできます。
- 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コンテンツIAP-ルーター
Another possibility of course is to provide a special device along the path to provide the content IAP capabilities.
もう1つの可能性は、コンテンツ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のアクセスを提供するために2つ以上のルーターが接続されている2つ以上のルーター）がある場合、インターセプトタップを複数のアクセスルーターにインストールする必要がある場合があることに注意してください。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.
* 許可されていない創造と検出：もう1つの懸念は、不正な創造とインターセプトの検出の防止です。これは、ルーターなどのネットワーク要素がコンテンツ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つは、国固有の要件に関係なく、内部インターフェイス（BからF）を同じに保つことです。次に、MDはIRIとコンテンツをフォーマットして、インターフェイス（G）および（H）の国固有の要件を満たします。
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.
このセクションでは、図1のコンテンツインターセプトリクエストインターフェイス（d）の要件の一部について説明します。アプリケーションの種類（音声、データなど）に関係なく、一般的なリクエストプロトコル（SNMPV3）を使用し、Aの使用法を示唆しています。TAP-MIB、これは別のドキュメント[1]で定義されています。[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にインターセプト、複製、カプセル化、および輸送するための一般的なインターフェイスを提供するために、コンテンツインターセプトインターフェイス（（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に障害があることを認識することが可能である必要があります。そのため、インターセプトを再確立する必要があります。これは、監査（MDからIAPまで）の形で、またはコンテンツストリームのハートビートメカニズム、またはその両方の形である場合があります。
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と相関させるための識別子を提供する必要があります。これらの要件を満たす1つのカプセル化は、[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]の使用はまだ調査中であり、さらに仕様が必要になる場合があることに注意してください。コンテンツIAPでの[12]の使用は、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:
Voice Over IP（たとえば、集中化対分布）とさまざまなプロトコル（SIP [6]、H.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)
* ローカル音声サービス（つまり、ゲートウェイに接続された電話または電話を持っているユーザーへのサービス）
* 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, 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をバイパスするメディアストリーム（Voice over 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のインターフェイス（c）を介して行うことができます。問題のCCEはIRI IAPであり、プロビジョニングが行われると、IRIをMDに渡します。議論されているシナリオでは、CCEは通常、コールフォーリングの場合でも、コール全体のシグナリングパスに残ります。IRIの一部は、MDに渡されます。メディアシグナリング情報（つまり、SDP [11]またはH.245 [10]）です。これには、エンドポイントIPアドレスとメディア（コンテンツ）ストリームのポート情報が含まれます。このメディアアドレス情報を使用して、MDはコンテンツIAP（[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 (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).
IP上の音声の場合のコンテンツIAPは、エッジルーターまたはPSTNゲートウェイ（たとえば、PSTNからのPSTNに転送された呼び出し）である可能性があることに注意してください。SIP、H.323、MGCPまたはH.248コールシグナリングプロトコルを使用できます。ただし、インターフェイス（d）に使用されるプロトコル（SNMPV3 [1]）は、使用されるコールシグナリングプロトコルのタイプに依存しません。また、カプセル化形式と輸送プロトコル（インターフェイス "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).
*ユーザーがサービスのために登録または解除した時間。
*アドレス指定情報（つまり、ユーザーのIDが与えられた場合、インターフェイス（d）で使用できるIPアドレスまたはその他の情報が利用可能であるかどうか）。
Once suitable addressing information is available in order to do content tapping the MD can invoke the tap via interface (d).
MDをタップするコンテンツを実行するために適切なアドレス指定情報が利用可能になると、インターフェイス（D）を介してTAPを呼び出すことができます。
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.
一般に、すべてのインターフェイスには、プリンシパルのアイデンティティを確立するために強力な暗号認証を提供する能力があり、プリンシパルのアイデンティティを実行しようとしているアクションと相関させることができます。すべてのインターフェイスは、たとえば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が不正なUSM [3]ユーザーによる開示または制御からTAP MIBの[1]を保護する機能をサポートする必要があることです。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 [1]を含むVACMビューを作成できるように、TAP MIBの分離。
[1] Baker, F., "Cisco Lawful Intercept Control MIB", Work in Progress, April 2004.
[1] Baker、F。、「Cisco Lawful Intercept Control MIB」、2004年4月、進行中の作業。
[2] PacketCable(TM) Electronic Surveillance Specification, PKT-SP-ESP-I04-040723, http://www.packetcable.com/specifications/
[2] PacketCable（TM）電子監視仕様、PKT-SP-ESP-I04-040723、http：//www.packetcable.com/spifications/
[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] Blumenthal、U.およびB. Wijnen、「Simple Network Management Protocol（SNMPV3）のバージョン3のユーザーベースのセキュリティモデル（USM）」、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、「シンプルネットワーク管理プロトコル（SNMP）のビューベースのアクセス制御モデル（VACM）」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[7] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[7] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（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] Handley、M。and 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] Rey、J.、Leon、D.、Miyazaki、A.、Varsa、V。、およびR. Hakenber、「RTP再送信ペイロード形式」、作業進行中。
[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
Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, CA 93117 US
フレッド・ベイカー・シスコ・システム1121
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: 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
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
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。