RFC3924 日本語訳

3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker,B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                           F. Baker
Request for Comments: 3924                                     B. Foster
Category: Informational                                         C. Sharp
                                                           Cisco Systems
                                                            October 2004

コメントを求めるワーキンググループF.ベイカー要求をネットワークでつないでください: 3924年のB.フォスターカテゴリ: 情報の鋭いC.シスコシステムズ2004年10月

        Cisco Architecture for Lawful Intercept in IP Networks

IPネットワークにおける合法的なインタセプトのためのコクチマスアーキテクチャ

Status of this Memo

この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).

Copyright(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はどんな目的、および発行するという決定が配布しているプロトコルとのセキュリティのようなもの、輻輳制御または不適当な相互作用のためのIETFレビューに基づいていないという特定のメモでもこのRFCのフィットネスに関するどんな知識も放棄します。 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ネットワークで合法的なインタセプトをサポートするためにシスコのArchitectureについて説明します。 それは最小のセットの一般的なインタフェースを持っている一般解を提供します。 このドキュメントは、特定の国に存在するかもしれない特定の法的必要条件か義務のどれかを扱うのを試みません。

Baker, et al.                Informational                      [Page 1]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[1ページ]のRFC3924アーキテクチャ

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

1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. アーキテクチャ. . . . . . . . . 3 1.2を動機づける要件。 組織を記録してください。 . . . . . . . . . . . . . . . . . . 4 2. 規範モデル. . . . . . . . . . . . . . . . . . . . . . . . 5 2.1。 規範モデルの部品. . . . . . . . . . . . . . . . 6 2.2。 操作上の問題. . . . . . . . . . . . . . . . 7 3。 インタフェース。 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. 満足しているインタセプト要求インタフェース。 . . . . . . . . . . . 9 3.2. 満足しているインタフェース(f)を妨害してください。 . . . . . . . . . . . . . 10 4. 規範モデルを適用します。 . . . . . . . . . . . . . . . . . 11 4.1. IPの上で.1にネットワーク. . . . . . . . . . . . . . . . . . 11 4.1を声に出してください。 ボイス・オーバー IPサービスの妨害。 . . . . . . 11 4.1.2. 地方のボイスサービス。 . . . . . . . . . . . . . . . 12 4.2. データサービス。 . . . . . . . . . . . . . . . . . . . . . . 13 5. セキュリティ問題. . . . . . . . . . . . . . . . . . . . 13 5.1。 満足している要求インタフェース(d)--SNMPv3は.146を制御します。 有益な参照。 . . . . . . . . . . . . . . . . . . . . 14 7. 頭文字語… 16 8。 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 17 9. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . 18

1.  Introduction

1. 序論

   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の定義は以下に示されます:

Baker, et al.                Informational                      [Page 2]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[2ページ]のRFC3924アーキテクチャ

         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ネットワークで合法的なインタセプトをサポートするためにシスコのArchitectureについて説明します。 それは最小のセットの一般的なインタフェースを持っている一般解を提供します。 このドキュメントは法的必要条件か義務に対処しません。

   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のためにこれらなどのアーキテクチャがベンダー標準化の話題よりむしろ特有である理由に関する記述のためのRFC2804[15]に読者の注意を引きつけたがっています。

1.1.  Requirements Motivating the Architecture

1.1. アーキテクチャを動機づける要件

   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.

* 合法的なIntercept(LI)はインタセプト対象で検知されないはずです。

Baker, et al.                Informational                      [Page 3]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[3ページ]のRFC3924アーキテクチャ

   *  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.

* 傍受される情報がサービスプロバイダーによって暗号化されて、サービスプロバイダーがキーに近づく手段を持っているなら、法の執行Agency(LEA)か暗号化キーへの配送が情報を解読するのを許容するために法の執行Agencyに通過されるべき前に情報は解読されるべきです。

   *  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.

アーキテクチャとインタフェースはこれらの要件を扱う本書では試みるのについて説明しました。

1.2.  Document Organization

1.2. ドキュメント組織

   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はセキュリティ問題を調べます。

Baker, et al.                Informational                      [Page 4]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[4ページ]のRFC3924アーキテクチャ

2.  Reference Model

2. 規範モデル

   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

+--------------------+ +-----+ | LI政権| HI1(a)| | | 機能| <、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +--------------------+ | | | | | | MDの食糧を供給すること| | | インタフェース(b)| 草地| v| | +-----------+ +--------------------+ | | | | <、-、--(c)----| | | | | イリIAP|--IRI(e)-->| 仲介|----HI2(g)--->|、|、|、|、| デバイス(MD)| | | +-----------+ | |----HI3(h)--->|、| +--------------------+ +-----+ | ^インタセプト| | 妨害された要求(d)| | 内容(f)| | v| +--------------------+ ユーザ| 内容| ユーザ------->| IAP|-------->内容+--------------------+ 内容

      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.

インタフェース記述--------------------- ------------------------------------------- (a) HI1引き渡しインタフェース1--政権インタフェース: LEAはサービスプロバイダー管理機能にインタセプト情報を提供します。

   (b) MD Provisioning       Mediation Device provisioning interface.
                             Parameters include: target identifier,
                             duration of intercept, type of intercept,
                             etc.

(b) インタフェースに食糧を供給するMD Provisioning Mediation Device。 パラメタは: 目標識別子、インタセプトの持続時間、インタセプトのタイプなど

Baker, et al.                Informational                      [Page 5]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[5ページ]のRFC3924アーキテクチャ

   (c) IRI IAP Provisioning  Specifies Target identifier, duration,
                             etc. for provisioning of delivery of
                             Intercept Related Information (IRI).

(c) IRI IAP Provisioning Specifies Target識別子、Interceptの関連情報(IRI)の配送の食糧を供給する持続時間など。

   (d) Content Intercept     Provisioning of the Content IAP.
       Provisioning

満足しているIAPの(d)内容インタセプトの食糧を供給すること。 食糧を供給すること

   (e) IRI to MD             Internal interface between IRI Intercept
                             Access Point (IAP) and Mediation device
                             (MD) for delivery of IRI.

(e) MD InternalへのIRIはIRIの配送のためにIRI Intercept Access Point(IAP)とMediationデバイス(MD)の間で連結します。

   (f) Content to MD         Internal interface between content
                             IAP and MD for delivery of Content.

(f) Contentの配送のための満足しているIAPとMDとのMD Internalインタフェースへの内容。

   (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: Contentを提供するためにMDとLEAの間で連結してください。 このインタフェースは国によって違うかもしれません。

2.1.  Reference Model Components

2.1. 規範モデルの部品

   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)政権機能: この機能は法の執行Agency(LEA)によって提供された裁判所命令か証明書の結果、(通常手動)の食糧を供給するインタフェースをインタセプトに提供します。 それは、いくつかのコンポーネントのために別々の食糧を供給するインタフェースにかかわることができましたが、Mediation Device(MD)への、より典型的に単一のインタフェースです。(次に、Mediation Deviceはネットワークにおける他のコンポーネントの食糧を供給することの世話をします)。 アクセシビリティを任命された者に制限するいくつかの法による要件のために、食糧を供給するインタフェースは厳密に制御されなければなりません。 多くの場合、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

アクセスポイント(IAP)を妨害してください: IAPは合法的に認可されたインタセプト情報を傍受するのに使用されるネットワークの中のデバイスです。 それはインタセプト能力を持っている既存のデバイスであるかもしれませんかそれがaであるかもしれません。

Baker, et al.                Informational                      [Page 6]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[6ページ]のRFC3924アーキテクチャ

      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の2つのタイプについて議論します: 提供するIAPは満足しています。 そして、インタセプト関連情報(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).

イリ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.

警察機関(草地): これはインタセプトを要求して、サービスプロバイダーが情報を提供する政府機関です。

   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はIAPsから図1のインタフェース(c)と(d)のインタセプトを要求します。 Mediation DeviceはLEAにIAPからデータを受信して、正しい書式で(国によって違うかもしれない)それをパッケージして、それを提供します。 複数の警察機関が同じ対象を傍受している場合では、仲介デバイスは情報を複数の回模写するかもしれません。 仮定はサービスプロバイダーがMD(特に認可された人員を通した)を運用して、LEAが図1のインタフェース(a)、(g)、および(h)に近づく手段を持っているだけであるということです。

2.2.  Operational Considerations

2.2. 操作上の問題

   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:

典型的な操作に、合法的に認可された監視要求は指定されたインタセプト対象のために到達します。 (b) 図1か支給について任命された者ともにインタセプト使用が連結する。(それは、内容IRIだけのためのものであるかもしれません)。 インタセプトがいったん食糧を供給されると、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

* 満足している暗号化: インタセプト内容が暗号化されていて、サービスプロバイダーが暗号化キー(例えば、ボイス・オーバー IPのためにSession記述プロトコルでキーを受ける)に近づく手段を持っているなら、IRIを通してキーを送ることができます。 しかしながら、エンドユーザが少しも知識なしである他の手段でキーを交換するのにおいてそれは可能です。

Baker, et al.                Informational                      [Page 7]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[7ページ]のRFC3924アーキテクチャ

      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.

どれがサービスプロバイダーをケースに入れるかでサービスプロバイダーはキーを提供できないでしょう。 満足している変換で、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:

* インタセプトSubject:による検出 1つの要件はインタセプト対象が確実にそれを検出できないようになるようにするために、それらが妨害されているということです。 このドキュメントは精巧な対象を仮定します:

      -  Able to check IP addresses, use traceroute, etc.

- 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) |
                                |       |
                                +-------+

| 顧客構内| サービスプロバイダーのネットワーク| +-------+ +-----+ | | | CPE|-------------| ルータ|---------- +-----+ | (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.

別の可能性は満足している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.

マルチホーミングがある(2つ以上のルータがアクセスをCPEに供給するために接続しました)場合では、インタセプト消灯ラッパが1つ以上のアクセスルータにインストールされなければならないかもしれないことに注意してください。 CPEがそうである、マルチ、家へ帰り、複数のサービスプロバイダー(インタセプトが別々に各サービスプロバイダーにインストールされるために持って、LEAがデータを関連させるように持っているその時)

Baker, et al.                Informational                      [Page 8]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[8ページ]のRFC3924アーキテクチャ

   *  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.

* 容量: 顧客をサポートするネットワーク要素における合法的なインタセプトのサポートはその設備に関するリソースを消費します。 したがって、合法的なインタセプトのサポートは、収入を生産するサービスが悪影響を受けないのを保証するためにキャパシティプランニングと工学を必要とします。

3.  Interfaces

3. インタフェース

   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にTable1に含まれています。

   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は、インタフェース(g)と(h)のための国の決められた一定の要求を満たすためにIRIと内容をフォーマットします。

3.1.  Content Intercept Request Interface

3.1. 満足しているインタセプト要求インタフェース

   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)を利用して、TAP-MIBの使用法を示します。(TAP-MIBは別々のドキュメント[1]で定義されます)。 SNMPv3の使用と、そして、[1]で定義された特定のManagement Information基地(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.

* 妨害されるためにパケットを分類するためのFilter仕様。

   *  The destination address of the MD (where to send the packets).

* MDの送付先アドレス、(パケットをどこに送るか、)

Baker, et al.                Informational                      [Page 9]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[9ページ]のRFC3924アーキテクチャ

   *  Encapsulation and Transport parameters.

* カプセル化とTransportパラメタ。

   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のa失敗が起こるのでそれが供給にできない、タイムアウトにリフレッシュしてください、そして、次に、インタセプトは、タイムアウトが期限が切れた後に存在するのをやめるでしょう。 同様に、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までの)の形、または満足しているストリーム、または両方の鼓動メカニズムの形にあるかもしれません。

3.2.  Intercept Content Interface (f)

3.2. 満足しているインタフェースを妨害してください。(f)

   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]のTable1の「妨害された情報」分野はオリジナルの妨害された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].

より信頼できるトランスポート・プロトコルが必要であるなら、Content IAPでの負担(処理とバッファリングの両方)を限界と同様にタイムリーな配送に提供するメカニズムは使用されるべきです。 これらの必要条件を出迎える1つのメカニズムが[12]に基づくナック指向の「再-トランスミッション」体系です。

   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の容量に影響できます。

Baker, et al.                Informational                     [Page 10]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[10ページ]のRFC3924アーキテクチャ

4.  Applying the Reference Model

4. 規範モデルを適用します。

   This section applies the reference model to some example
   applications.

このセクションはいくつかの例のアプリケーションに規範モデルを適用します。

4.1.  Voice over IP networks

4.1. ボイス・オーバー IPネットワーク

   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からの規範モデルは一般的なセットの使用中の呼び出しシグナリングプロトコルから独立しているインタフェースの使用で適用されるでしょう。

4.1.1.  Interception of Voice over IP Services

4.1.1. ボイス・オーバー IPサービスの妨害

   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]、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)

* 地方のボイスサービス(すなわち、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を迂回させるメディアストリームをもたらすネットワークでどこでもインタセプト問題に関して終わることを意図した呼び出しを送るかもしれない、(以来中で声に出す、終わっている。

Baker, et al.                Informational                     [Page 11]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[11ページ]のRFC3924アーキテクチャ

   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の位置はしばしば知られているというわけではないでしょう。

4.1.2.  Local Voice Services

4.1.2. 地方のボイスサービス

   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).

この小区分は地方のボイスサービスがまた、ネットワークアクセス(例えば、縁のルータかスイッチを制御する)を提供するのと同じプロバイダーによって監視でのインタセプト対象に提供されている特定の場合を見るでしょう。 これは重要な仮定です、呼び出しコントロール(例えば、SIPサーバ)を提供する実体がVoIPでネットワークアクセス(例えば、縁のルータを操作する)を提供する実体から完全に別々である場合があるので。

   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).

ローカルに加入するそのa加入者を仮定してください、(例えば、住宅、)、声のサービスは合法的に認可された監視のための目標です。 これらのサービスを提供するシステムの一部がどんな特徴が有効であるかの井戸情報(例えば、自動転送)として加入者に関するアドレス指定情報を含んでいる加入者データベースです。 何らかの呼び出しコントロール実体(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プロキシまたはメディアゲートウェイControllerであるかもしれない)を「所有している」CCEはインタセプトパラメタで食糧を供給されます(例えば、電話番号などの対象の識別情報とIRIをどこに提供しますか)。 このCCEの食糧を供給することが図1にインタフェース(c)を通してあるかもしれません。 問題のCCEはIRI IAPです、そして、いったん食糧を供給されると、それはIRIをMDに渡します。 議論するシナリオでは、CCEは呼び出しの間中シグナリング経路に通常留まります、自動転送場合でさえ。 それがMDに渡すIRIの一部が情報に合図することでのメディアです。すなわち、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

IPの上の声の場合における満足しているIAPが縁のルータかPSTNゲートウェイであるかもしれないこと(例えば、PSTNに送られたPSTNからの呼び出し)に注意してください。 SIP、H.323、MGCPまたはH.248呼び出しシグナリングプロトコルを使用できました。 しかしながら、プロトコル、(SNMPv3[1])はインタフェースに使用しました。

Baker, et al.                Informational                     [Page 12]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[12ページ]のRFC3924アーキテクチャ

   (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)を使用できます(地方のボイスサービスはこの例で使用されましたが、以下に注意してください、他であり、ボイスサービスは同じモデルとインタフェースを使用するかもしれません)。

4.2.  Data Services

4.2. データサービス

   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)も同じであるかもしれません。

5.  Security Considerations

5. セキュリティ問題

   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サーバは攻撃のための主要な目標であると考えられるでしょう。

Baker, et al.                Informational                     [Page 13]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[13ページ]のRFC3924アーキテクチャ

   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 IAPsもインタセプト対象のアイデンティティの保護とインタセプトの存在を提供するはずです。

5.1.  Content Request Interface (d) - SNMPv3 Control

5.1. 満足している要求インタフェース(d)--SNMPv3コントロール

   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.

* アクセスをそれらのSNMPv3 USMユーザだけによるキーを設立する適切なTAP MIBのものと視点が定義した適切なVACMに制限する能力。

   *  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では、十分な特権レベルのオペレータだけがVACM視点を作成できるように、それはTAP MIB[1]を含んでいます。

6.  Informative References

6. 有益な参照

   [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(TM)電子監視仕様、PKT-SP超能力-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、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、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)について議定書の中で述べます」、STD62、RFC3415、2002年12月。

Baker, et al.                Informational                     [Page 14]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[14ページ]のRFC3924アーキテクチャ

   [5]  Warnicke, E., "A Suggested Scheme for DNS Resolution of Networks
        and Gateways", Work in Progress.

[5] E.、「ネットワークとゲートウェイのDNS解決の提案された体系」というWarnickeは進行中で働いています。

   [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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [7]  Andreasen, F. and B. Foster, "Media Gateway Control Protocol
        (MGCP) Version 1.0", RFC 3435, January 2003.

[7] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。

   [8]  ITU-T Recommendation H.248.1, Gateway Control Protocol: Version
        2, May 2002.

[8] ITU-T推薦H.248.1、ゲートウェイ制御プロトコル: 2002年5月のバージョン2。

   [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.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。

   [12] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenber,
        "RTP Retransmission Payload Format", Work in Progress.

レイとJ.とレオンとD.と宮崎とA.とVarsa、V.とR.Hakenber、「RTP Retransmission有効搭載量形式」が進行中で扱う[12]。

   [13] ETSI TS 101 331, Telecommunications security; Lawful
        Interception (LI); Requirements of law enforcement agencies.

[13] ETSI TS101 331、Telecommunicationsセキュリティ。 合法的な妨害(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 TS33.108v6.7.0、第3Generation Partnership Project。 仕様書グループサービスとシステム局面。 3Gセキュリティ。 合法的な妨害(リリース6)のための引き渡しインタフェース。

   [15] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.

[15] IABとIESG(「盗聴に関するIETF方針」、RFC2804)は2000がそうするかもしれません。

Baker, et al.                Informational                     [Page 15]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[15ページ]のRFC3924アーキテクチャ

7.  Acronyms

7. 頭文字語

   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のCPEの顧客端末のETSIのヨーロッパのテレコミュニケーション呼び出しコントロール実体CMTSケーブルモデム終了システム規格研究所GPRSは合法的にパケットラジオのサービスのHMAC-MD5のハッシュベースの通報認証コード--メッセージダイジェスト5IAPインタセプトアクセスポイントIETFインターネット・エンジニアリング・タスク・フォースIRIインタセプト関連情報ITU-T国際電気通信組合--通信分野草地警察機関LIを一般化しました; Gateway制御プロトコルMD仲介デバイスMIB Management Information BaseナックNegativeの承認PSTN公衆切り換えられたテレコミュニケーションネットワークRFCがリアルタイムのコメントのVACM視点ベースのアクセス制御モデルVoIP RTPトランスポート・プロトコルSDPセッション記述プロトコル一口セッション開始プロトコルSSRC同期ソースTDM時分割多重UDPユーザー・データグラム・プロトコルUSMユーザサービスモデルボイス・オーバー IPのために要求するMGCPメディアを傍受してください。

Baker, et al.                Informational                     [Page 16]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[16ページ]のRFC3924アーキテクチャ

8.  Authors' Addresses

8. 作者のアドレス

   Fred Baker
   Cisco Systems
   1121 Via Del Rey
   Santa Barbara, CA  93117
   US

デル・レイカリフォルニア93117サンタバーバラ(米国)経由でフレッドベイカーシスコシステムズ1121

   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   EMail: fred@cisco.com

以下に電話をしてください。 +1-408-526-4257 Fax: +1-413-473-2403 メールしてください: fred@cisco.com

   Bill Foster
   Cisco Systems
   Suite 2150
   1050 West Pender St.
   Vancouver, BC, V6E 3S7
   Canada

ビルフォスターシスコシステムズSuite2150 1050の西ペンダー通りバンクーバー、紀元前、V6E 3S7カナダ

   Phone: +1-604-647-2315
   EMail: bfoster@cisco.com

以下に電話をしてください。 +1-604-647-2315 メールしてください: bfoster@cisco.com

   Chip Sharp
   Cisco Systems
   7025 Kit Creek Road
   RTP, NC 27709  USA

急シスコシステムズ7025キットクリーク道路RTP、NC27709米国を欠いてください。

   Tel:+1.919.392.3121
   EMail: chsharp@cisco.com

.3121がメールするTel:+1.919.392: chsharp@cisco.com

Baker, et al.                Informational                     [Page 17]

RFC 3924           Architecture for Lawful Intercept        October 2004

ベイカー、他 合法的なインタセプト2004年10月のための情報[17ページ]のRFC3924アーキテクチャ

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).

Copyright(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.

このドキュメントはBCP78と、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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Baker, et al.                Informational                     [Page 18]

ベイカー、他 情報[18ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

unset 変数の定義を解除する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る