Internet Engineering Task Force (IETF) E. Boschi
Request for Comments: 6235 B. Trammell
Category: Experimental ETH Zurich
ISSN: 2070-1721 May 2011
IP Flow Anonymization Support
Abstract
抽象
This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options-based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files.
この文書では、IPフローデータとIPフロー情報のエクスポート（IPFIX）プロトコルを使用して、匿名データの輸出のための匿名化手法について説明します。これは、一般的な匿名化スキームを分類し、それらを記述するために必要なパラメータを定義します。それはIPFIX以上の匿名データのエクスポートおよび保管の実施のためのガイドラインを提供し、IPFIXファイル内のIPFIXプロトコルまたはストレージ内の匿名化メタデータのエクスポートのための情報モデルとオプションベースの方法を説明します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはインターネット標準化過程仕様ではありません。それは、検査、実験的な実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6235.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6235で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................4
1.1. IPFIX Protocol Overview ....................................4
1.2. IPFIX Documents Overview ...................................5
1.3. Anonymization within the IPFIX Architecture ................5
1.4. Supporting Experimentation with Anonymization ..............6
2. Terminology .....................................................6
3. Categorization of Anonymization Techniques ......................7
4. Anonymization of IP Flow Data ...................................8
4.1. IP Address Anonymization ..................................10
4.1.1. Truncation .........................................11
4.1.2. Reverse Truncation .................................11
4.1.3. Permutation ........................................11
4.1.4. Prefix-Preserving Pseudonymization .................12
4.2. MAC Address Anonymization .................................12
4.2.1. Truncation .........................................13
4.2.2. Reverse Truncation .................................13
4.2.3. Permutation ........................................14
4.2.4. Structured Pseudonymization ........................14
4.3. Timestamp Anonymization ...................................15
4.3.1. Precision Degradation ..............................15
4.3.2. Enumeration ........................................16
4.3.3. Random Shifts ......................................16
4.4. Counter Anonymization .....................................16
4.4.1. Precision Degradation ..............................17
4.4.2. Binning ............................................17
4.4.3. Random Noise Addition ..............................17
4.5. Anonymization of Other Flow Fields ........................18
4.5.1. Binning ............................................18
4.5.2. Permutation ........................................18
5. Parameters for the Description of Anonymization Techniques .....19
5.1. Stability .................................................19
5.2. Truncation Length .........................................19
5.3. Bin Map ...................................................20
5.4. Permutation ...............................................20
5.5. Shift Amount ..............................................20
6. Anonymization Export Support in IPFIX ..........................20
6.1. Anonymization Records and the Anonymization
Options Template ..........................................21
6.2. Recommended Information Elements for Anonymization
Metadata ..................................................23
6.2.1. informationElementIndex ............................23
6.2.2. anonymizationTechnique .............................23
6.2.3. anonymizationFlags .................................25
7. Applying Anonymization Techniques to IPFIX Export and Storage ..27
7.1. Arrangement of Processes in IPFIX Anonymization ...........28
7.2. IPFIX-Specific Anonymization Guidelines ...................30
7.2.1. Appropriate Use of Information Elements for
Anonymized Data ....................................30
7.2.2. Export of Perimeter-Based Anonymization Policies ...31
7.2.3. Anonymization of Header Data .......................32
7.2.4. Anonymization of Options Data ......................32
7.2.5. Special-Use Address Space Considerations ...........34
7.2.6. Protecting Out-of-Band Configuration and
Management Data ....................................34
8. Examples .......................................................34
9. Security Considerations ........................................39
10. IANA Considerations ...........................................41
11. Acknowledgments ...............................................41
12. References ....................................................41
12.1. Normative References .....................................41
12.2. Informative References ...................................42
The standardization of an IP Flow Information Export (IPFIX) protocol [RFC5101] and associated representations removes a technical barrier to the sharing of IP flow data across organizational boundaries and with network operations, security, and research communities for a wide variety of purposes. However, with wider dissemination comes greater risks to the privacy of the users of networks under measurement, and to the security of those networks. While it is not a complete solution to the issues posed by distribution of IP flow information, anonymization (i.e., the deletion or transformation of information that is considered sensitive and that could be used to reveal the identity of subjects involved in a communication) is an important tool for the protection of privacy within network measurement infrastructures.
IPフロー情報エクスポート（IPFIX）プロトコル[RFC5101]及び関連する表現の標準化は、組織の境界を横切るIPフローデータの共有および目的の多種多様なネットワーク操作、セキュリティ、および研究コミュニティと技術的障壁を除去します。しかし、より広い普及と被測定ネットワークのユーザのプライバシーに、そしてこれらのネットワークの安全保障に大きなリスクを付属しています。それはIPフロー情報の流通によってもたらされる問題の完全な解決策ではありませんが、匿名化（すなわち、情報の削除や変換が敏感であると考えられ、それがコミュニケーションに関わる科目の身元を明らかにするために使用することができること）でありますネットワーク測定インフラストラクチャ内のプライバシーの保護のための重要なツール。
This document presents a mechanism for representing anonymized data within IPFIX and guidelines for using it. It is not intended as a general statement on the applicability of specific flow data anonymization techniques to specific situations or as a recommendation of any particular application of anonymization to flow data export. Exporters or publishers of anonymized data must take care that the applied anonymization technique is appropriate for the data source, the purpose, and the risk of deanonymization of a given application.
このドキュメントは、IPFIXと、それを使用する際のガイドライン内の匿名データを表現するためのメカニズムを提供します。これは、特定の状況またはデータのエクスポートを流す匿名の任意の特定のアプリケーションの勧告などの特定のフローデータの匿名化技術の適用性に関する一般的な文として意図されていません。匿名データの輸出業者や出版社が適用される匿名化技術は、データソース、目的、および特定のアプリケーションのdeanonymizationのリスクのために適切であることに注意しなければなりません。
It begins with a categorization of anonymization techniques. It then describes the applicability of each technique to commonly anonymizable fields of IP flow data, organized by information element data type and semantics as in [RFC5102]; enumerates the parameters required by each of the applicable anonymization techniques; and provides guidelines for the use of each of these techniques in accordance with current best practices in data protection. Finally, it specifies a mechanism for exporting anonymized data and binding anonymization metadata to Templates and Options Templates using IPFIX Options.
これは、匿名化技術の分類から始まります。次に、[RFC5102]のような情報要素データ型およびセマンティクス主催IPフローデータの各技術に共通anonymizableフィールドの適用を記載します。適用可能な匿名化技術の各々によって必要なパラメータを列挙する。そして、データ保護の現在のベストプラクティスに従い、これらの技術のそれぞれの使用のためのガイドラインを提供します。最後に、匿名データをエクスポートし、IPFIXオプションを使用してテンプレートとオプションテンプレートに匿名化メタデータを結合するためのメカニズムを指定します。
In the IPFIX protocol, { type, length, value } tuples are expressed in Templates containing { type, length } pairs, specifying which { value } fields are present in data records conforming to the Template, giving great flexibility as to what data is transmitted. Since Templates are sent very infrequently compared with Data Records, this results in significant bandwidth savings. Various different data formats may be transmitted simply by sending new Templates specifying the { type, length } pairs for the new data format. See [RFC5101] for more information.
どのようなデータが送信されるようIPFIXプロトコルでは、{タイプ、長さ、値}の組は、大きな柔軟性を与える{値}のフィールドがテンプレートに準拠したデータレコードに存在する{タイプ、長さ}ペア、指定を含むテンプレートで表され。テンプレートは、データレコードと比較して非常に低い頻度で送信されているので、これはかなりの帯域幅の節約になります。様々な異なるデータ・フォーマットは、単に新たなデータ形式の{タイプ、長さ}ペアを指定する新しいテンプレートを送信することによって送信されてもよいです。詳細については、[RFC5101]を参照してください。
The IPFIX information model [RFC5102] defines a large number of standard Information Elements (IEs) that provide the necessary { type } information for Templates. The use of standard elements enables interoperability among different vendors' implementations. Additionally, non-standard enterprise-specific elements may be defined for private use.
IPFIX情報モデル[RFC5102]はテンプレートの必要{タイプ}の情報を提供する標準的な情報要素（IE）の多数を定義します。標準的な要素の使用は、異なるベンダーの実装間の相互運用を可能にします。また、非標準のエンタープライズ固有の要素は、私的使用のために定義することができます。
"Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information" [RFC5101] and its associated documents define the IPFIX protocol, which provides network engineers and administrators with access to IP traffic flow information.
[RFC5101]及びそれに関連する文書の「IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様は、」IPトラフィックフロー情報へのアクセスとネットワークエンジニアや管理者に提供IPFIXプロトコルを定義します。
"Architecture for IP Flow Information Export" [RFC5470] defines the architecture for the export of measured IP flow information out of an IPFIX Exporting Process to an IPFIX Collecting Process, and the basic terminology used to describe the elements of this architecture, per the requirements defined in "Requirements for IP Flow Information Export" [RFC3917]. The IPFIX Protocol document [RFC5101] then covers the details of the method for transporting IPFIX Data Records and Templates via a congestion-aware transport protocol from an IPFIX Exporting Process to an IPFIX Collecting Process.
「建築IPフロー情報エクスポートのために」[RFC5470]は要件に従って、IPFIX収集プロセスにIPFIXエクスポートプロセスのうち、測定IPフロー情報のエクスポートのためのアーキテクチャを定義し、このアーキテクチャの要素を記述するために使用される基本的な用語「IPフロー情報をエクスポートするための要件」[RFC3917]で定義されています。 IPFIXプロトコルドキュメント[RFC5101]は次いで、IPFIX収集プロセスにIPFIXエクスポートプロセスから渋滞認識トランスポートプロトコルを介してIPFIXデータレコードとテンプレートを輸送するための方法の詳細を覆います。
"Information Model for IP Flow Information Export" [RFC5102] describes the Information Elements used by IPFIX, including details on Information Element naming, numbering, and data type encoding. Finally, "IP Flow Information Export (IPFIX) Applicability" [RFC5472] describes the various applications of the IPFIX protocol and their use of information exported via IPFIX and relates the IPFIX architecture to other measurement architectures and frameworks.
「IPフロー情報のエクスポートのための情報モデル」[RFC5102]は情報要素の命名、番号付け、およびデータ型のエンコーディングの詳細を含め、IPFIXによって使用される情報要素について説明します。最後に、「IPフロー情報エクスポート（IPFIX）適用」[RFC5472]は、様々なIPFIXプロトコルのアプリケーションとIPFIXを介してエクスポートされた情報の使用を説明し、他の測定アーキテクチャおよびフレームワークにIPFIXアーキテクチャに関する。
Additionally, "Specification of the IP Flow Information Export (IPFIX) File Format" [RFC5655] describes a file format based upon the IPFIX protocol for the storage of flow data.
さらに、[RFC5655]「IPフロー情報のエクスポート（IPFIX）ファイルフォーマットの仕様は、」フローデータを格納するためのIPFIXプロトコルに基づくファイル形式について説明します。
This document references the Protocol and Architecture documents for terminology and extends the IPFIX Information Model to provide new Information Elements for anonymization metadata. The anonymization techniques described herein are equally applicable to the IPFIX protocol and data stored in IPFIX Files.
この文書では、専門用語のためのプロトコルとアーキテクチャのドキュメントを参照し、匿名化メタデータのための新しい情報要素を提供するために、IPFIX情報モデルを拡張します。本明細書に記載の匿名化技術は、IPFIXファイルに格納されたIPFIXプロトコルとデータに等しく適用可能です。
According to [RFC5470], IPFIX Message anonymization is optionally performed as the final operation before handing the Message to the transport protocol for export. While no provision is made in the architecture for anonymization metadata as in Section 6, this arrangement does allow for the rewriting necessary for comprehensive anonymization of IPFIX export as in Section 7. The development of the IPFIX Mediation [RFC6183] framework and the IPFIX File Format [RFC5655] expand upon this initial architectural allowance for anonymization by adding to the list of places that anonymization may be applied. The former specifies IPFIX Mediators, which rewrite existing IPFIX Messages, and the latter specifies a method for storage of IPFIX data in files.
[RFC5470]によれば、IPFIXメッセージ匿名化は、必要に応じて輸出用のトランスポートプロトコルにメッセージを渡す前に、最終的な操作として実行されます。何の規定は第6節のように匿名化メタデータのためのアーキテクチャで作られていないが、この構成は、第7のようIPFIX輸出の包括的な匿名化のために書き換える必要も認めていませんIPFIXの仲介[RFC6183]のフレームワークとIPFIXファイルフォーマットの開発[RFC5655]匿名化を適用することができる場所のリストに追加することによって、匿名化するためのこの最初の建築手当時広げます。前者を指定IPFIX既存IPFIXメッセージを書き換えるメディエータ、後者はファイル内のIPFIXデータを記憶するための方法を指定します。
More detail on the applicable architectural arrangements for anonymization can be found in Section 7.1
匿名化のための適用建築手配の詳細は、7.1節で見つけることができます
The status of this document is Experimental, reflecting the experimental nature of anonymization export support. Research on network trace anonymization techniques and attacks against them is ongoing. Indeed, there is increasing evidence that anonymization applied to network trace or flow data on its own is insufficient for many data protection applications as in [Bur10]. Therefore, this document explicitly does not recommend any particular technique or implementation thereof.
この文書のステータスは、匿名の輸出支援の実験的な性質を反映して、実験的です。それらに対するネットワークトレースの匿名化技術と攻撃に関する研究が進行中です。確かに、匿名化は、独自のトレースまたはフローデータをネットワークに適用すると、[Bur10]のように多くのデータ保護アプリケーションのために不十分であるという証拠が増えています。したがって、この文書は、明示的にそれらのいずれかの特定の技術や実装を推奨していません。
The intention of this document is to provide a common basis for interoperable exchange of anonymized data, furthering research in this area, both on anonymization techniques themselves as well as to the application of anonymized data to network measurement. To that end, the classification in Section 3 and anonymization export support in Section 6 can be used to describe and export information even about data anonymized using techniques that are unacceptably weak for general application to production datasets on their own.
このドキュメントの意図は、自分自身だけでなく、匿名データのアプリケーションへの匿名化技術の両方が測定をネットワークに、この分野の研究を進める、匿名データの相互運用性の交換のための共通基盤を提供することです。そのために、第6節では3節と匿名の輸出支援での分類も、データは自分で生産データセットへの一般的な用途のために許容できないほど弱いの技術を使用して匿名化に関する情報を記述して輸出するために使用することができます。
While the specification herein is designed to be independent of the anonymization techniques applied and the implementation thereof, open research in this area may necessitate future updates to the specification. Assuming the future successful application of this specification to anonymized data publication and exchange, it may be brought back to the IPFIX working group for further development and publication on the Standards Track.
明細書は、本明細書適用匿名化技術とその実装に依存しないように設計されているが、この分野におけるオープン研究は、本明細書に将来の更新を必要とすることができます。匿名データの公表と交換するこの仕様の将来の成功のアプリケーションを想定し、それが標準化過程のさらなる発展と出版のために戻ってIPFIXワーキンググループに提起することができます。
Terms used in this document that are defined in the Terminology section of the IPFIX Protocol [RFC5101] document are to be interpreted as defined there. In addition, this document defines the following terms:
IPFIXプロトコル[RFC5101]文書の用語のセクションで定義され、この文書で使用される用語が定義されるように解釈されるべきです。また、このドキュメントでは、次の用語を定義しています。
Anonymization Record: A record, defined by the Anonymization Options Template in Section 6.1, that defines the properties of the anonymization applied to a single Information Element within a single Template or Options Template.
匿名レコード：セクション6.1で匿名オプションテンプレートによって定義されたレコードは、それが単一の鋳型またはオプションテンプレート内の単一の情報要素に適用される匿名のプロパティを定義します。
Anonymized Data Record: A Data Record within a Data Set containing at least one Information Element with anonymized values. The Information Element(s) within the Template or Options Template describing this Data Record SHOULD have a corresponding Anonymization Record.
匿名データレコード：匿名化された値と少なくとも一つの情報要素を含むデータセット内のデータレコード。このデータレコードを記述するテンプレートまたはオプションテンプレート内の情報要素（単数または複数）は、対応する匿名のレコードを持っているべきです。
Intermediate Anonymization Process: An intermediate process that takes Data Records and transforms them into Anonymized Data Records.
中級匿名化プロセス：データレコードを取り、匿名データレコードに変換し、中間工程。
Note that there is an explicit difference in this document between a "Data Set" (which is defined as in [RFC5101]) and a "data set". When in lower case, this term refers to any collection of data (usually, within the context of this document, flow or packet data) that may contain identifying information and is therefore subject to anonymization.
（[RFC5101]のように定義される）「データセット」と「データセット」の間に、この文書で明示的違いがあることに留意されたいです。小文字で、この用語は、識別情報を含み、匿名化することが課題であることができるデータの任意の集合（通常、この文書のコンテキスト内で、流れまたはパケットデータ）を意味します。
Note also that when the term Template is used in this document, unless otherwise noted, it applies both to Templates and Options Templates as defined in [RFC5101]. Specifically, Anonymization Records may apply to both Templates and Options Templates.
注また用語テンプレートは、この文書で使用される場合、特に断りのない限り、[RFC5101]で定義されるように、それは両方のテンプレートとオプションテンプレートに適用されること。具体的には、匿名化のレコードは、テンプレートとオプションテンプレートの両方に適用される場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Anonymization, as described by this document, is the modification of a dataset in order to protect the identity of the people or entities described by the dataset from disclosure. With respect to network traffic data, anonymization generally attempts to preserve some set of properties of the network traffic useful for a given application or applications, while ensuring the data cannot be traced back to the specific networks, hosts, or users generating the traffic.
この文書で説明するように匿名化は、データセットの変更は、開示からのデータセットによって記述人またはエンティティのアイデンティティを保護するためにあります。データを確保しつつ、トラフィックデータをネットワークに対して、匿名化は、一般に、所与のアプリケーションまたはアプリケーションのために有用なネットワーク・トラフィックの特性のいくつかのセットを保持しようとバックトラフィックを生成する特定のネットワーク、ホスト、又はユーザーに追跡することができません。
Anonymization may be broadly classified according to two properties: recoverability and countability. All anonymization techniques map the real space of identifiers or values into a separate, anonymized space, according to some function. A technique is said to be recoverable when the function used is invertible or can otherwise be reversed and a real identifier can be recovered from a given replacement identifier. "Recoverability" as used within this categorization does not refer to recoverability under attack; that is, techniques wherein the function used can only be reversed using additional information, such as an encryption key, or knowledge of injected traffic within the dataset, are not considered to be recoverable.
回復及び可算：匿名化は、大きく二つの特性に応じて分類することができます。すべて匿名化技術は、いくつかの機能に応じて、独立した、匿名化された空間に識別子または値の実空間をマッピングします。技術が使用される関数が可逆であるか、そうでなければ逆にすることができ、実際の識別子が与えられた置換識別子から回収することができる場合に回復可能であると言われます。この分類の中で使用される「回収可能性は、」攻撃を受け、回復を指すものではありません。それは、唯一のそのようなデータセット内の暗号鍵、または注入されたトラフィックの知識などの追加情報を使用して逆にすることができる使用される関数は、回復可能であると見なされていない特徴的な技術です。
Countability compares the dimension of the anonymized space (N) to the dimension of the real space (M), and denotes how the count of unique values is preserved by the anonymization function. If the anonymized space is smaller than the real space, then the function is said to generalize the input, mapping more than one input point to each anonymous value (e.g., as with aggregation). By definition, generalization is not recoverable.
可算は、実空間（M）の次元に匿名化した空間（N）の大きさを比較し、ユニークな値の数が匿名化機能によって保存される方法を示しています。匿名空間が実空間よりも小さい場合、この関数は、（例えば、凝集のように）各匿名の値に複数の入力ポイントをマッピングする、入力を一般化すると言われています。定義によると、一般化は回復可能ではありません。
If the dimensions of the anonymized and real spaces are the same, such that the count of unique values is preserved, then the function is said to be a direct substitution function. If the dimension of the anonymized space is larger, such that each real value maps to a set of anonymized values, then the function is said to be a set substitution function. Note that with set substitution functions, the sets of anonymized values are not necessarily disjoint. Either direct or set substitution functions are said to be one-way if there exists no non-brute force method for recovering the real data point from an anonymized one in isolation (i.e., if the only way to recover the data point is to attack the anonymized data set as a whole, e.g., through fingerprinting or data injection).
匿名化と現実の空間の大きさが同じである場合は、一意の値の数が保存されるように、その関数は、直接置換機能であると言われています。匿名空間の寸法が大きい場合には、各実値は匿名の値のセットにマッピングするように、この関数は、設定された代替関数であると言われます。集合置換機能と、匿名の値のセットが必ずしも互いに素ではないことに留意されたいです。隔離（すなわち、データポイントを回復する唯一の方法である場合、攻撃に匿名一つから実際のデータポイントを回復するための非強引な方法が存在しない場合は、直接またはセットの置換関数は一方向であると言われています指紋やデータ注入による全体として設定匿名データ、例えば、）。
This classification is summarized in the table below.
この分類は、以下の表に要約されています。
+------------------------+-----------------+------------------------+
| Recoverability / | Recoverable | Non-recoverable |
| Countability | | |
+------------------------+-----------------+------------------------+
| N < M | N.A. | Generalization |
| N = M | Direct | One-way Direct |
| | Substitution | Substitution |
| N > M | Set | One-way Set |
| | Substitution | Substitution |
+------------------------+-----------------+------------------------+
In anonymizing IP flow data as treated by this document, the goal is generally two-way address untraceability: to remove the ability to assert that endpoint X contacted endpoint Y at time T. Address untraceability is important as IP addresses are the most suitable field in IP flow records to identify real-world entities. Each IP address is associated with an interface on a network host and can potentially be identified with a single user. Additionally, IP addresses are structured identifiers; that is, partial IP address prefixes may be used to identify networks just as full IP addresses identify hosts. This leads IP flow data anonymization to be concerned first and foremost with IP address anonymization.
本書で扱わとしてIPフローデータを匿名では、目標は、一般的に、双方向のアドレスアントレーサビリティです：時間T.アドレスアントレーサビリティの終点Yと接触し、そのエンドポイントXを主張する能力を取り除くためにされた重要なIPアドレスが最も適した分野であるとして実社会のエンティティを識別するためのIPフローレコード。各IPアドレスは、ネットワーク上のホストインターフェースに関連付けられており、潜在的に単一のユーザと識別することができます。また、IPアドレスが識別子を構造化しています。つまり、部分的なIPアドレスのプレフィックスは、完全なIPアドレスがホストを識別する同じようにネットワークを識別するために使用することができます。これは何よりもまずIPアドレス匿名化を気にするIPフローデータの匿名化をリードしています。
Any form of aggregation that combines flows from multiple endpoints into a single record (e.g., aggregation by subnetwork, aggregation removing addressing completely) may also provide address untraceability; however, anonymization by aggregation is out of scope for this document. Additionally, of potential interest in this problem space but out of scope are anonymization techniques that are applied over multiple fields or multiple records in a way that introduces dependencies among anonymized fields or records. This document is concerned solely with anonymization techniques applied at the resolution of single fields within a flow record.
単一のレコードに複数のエンドポイントからの流れを組み合わせた集合の任意の形態（サブネットワークによって例えば、凝集、凝集完全アドレッシング除去）は、アドレスアントレーサビリティを提供することができます。しかし、凝集による匿名化はこの文書の範囲外です。また、この問題空間での潜在的な関心がなく、スコープの外には、匿名化フィールドまたはレコード間の依存関係を紹介した方法で、複数のフィールドまたは複数のレコードの上に適用されている匿名化技術です。この文書は、フローレコード内の単一フィールドの解像度で適用される匿名化技術を用いてのみ関係しています。
Even so, attacks against these anonymization techniques use entire flows and relationships between hosts and flows within a given dataset. Therefore, fields that may not necessarily be identifying by themselves may be anonymized in order to increase the anonymity of the dataset as a whole.
たとえそうであっても、これらの匿名化技術に対する攻撃は、所与のデータセット内の全体の流れとホストと流れとの間の関係を使用します。そのため、必ずしも単独で識別されないことがフィールドは、全体として、データセットの匿名性を高めるために匿名化されてもよいです。
Due to the restricted semantics of IP flow data, there is a relatively limited set of specific anonymization techniques available on flow data, though each falls into the broad categories discussed in the previous section. Each type of field that may commonly appear in a flow record may have its own applicable specific techniques.
それぞれが前のセクションで説明幅広いカテゴリに分類されてもによるIPフローデータの制限された意味論に、フローデータに利用可能な特定の匿名化技術の比較的限定されたセットがあります。一般的に、フローレコードに表示されることがあり、フィールドの各タイプには、独自の該当する具体的な技術を有することができます。
As with IP addresses, Media Access Control (MAC) addresses uniquely identify devices on the network; while they are not often available in traffic data collected at Layer 3, and cannot be used to locate devices within the network, some traces may contain sub-IP data including MAC address data. Hardware addresses may be mappable to device serial numbers, and to the entities or individuals who purchased the devices, when combined with external databases. MAC addresses are also often used in constructing IPv6 addresses (see Section 2.5.1 of [RFC4291]) and as such may be used to reconstruct the low-order bits of anonymized IPv6 addresses in certain circumstances. Therefore, MAC address anonymization is also important.
IPアドレスと同様に、メディアアクセス制御（MAC）は、ネットワーク上のデバイスを識別する一意に対処します。彼らは、レイヤ3で収集したトラフィックデータでは、多くの場合、利用できない、ネットワーク内のデバイスの位置を特定するために使用することはできませんが、いくつかのトレースは、MACアドレスデータを含むサブIPデータが含まれていてもよいです。ハードウェアアドレスは、デバイスのシリアル番号、および外部データベースと組み合わせると、デバイスを購入したエンティティまたは個人にマップ可能かもしれません。 MACアドレスは、しばしばIPv6アドレスを構成する際に使用される（[RFC4291]のセクション2.5.1を参照）のような特定の状況において匿名化IPv6アドレスの下位ビットを再構成するために使用されてもよいです。そのため、MACアドレスの匿名化も重要です。
Port numbers identify abstract entities (applications) as opposed to real-world entities, but they can be used to classify hosts and user behavior. Passive port fingerprinting, both of well-known and ephemeral ports, can be used to determine the operating system running on a host. Relative data volumes by port can also be used to determine the host's function (workstation, web server, etc.); this information can be used to identify hosts and users.
実世界の実体とは対照的に、ポート番号は、抽象エンティティ（アプリケーション）を識別し、彼らはホストとユーザーの行動を分類するために使用することができます。パッシブポートフィンガープリント、よく知られており、エフェメラルポートの両方が、ホスト上で動作しているオペレーティングシステムを決定するために用いることができます。ポートによる相対データボリュームは、ホストの機能（などのワークステーション、Webサーバなど）を決定するために使用することができます。この情報は、ホストとユーザーを識別するために使用することができます。
While not identifiers in and of themselves, timestamps and counters can reveal the behavior of the hosts and users on a network. Any given network activity is recognizable by a pattern of relative time differences and data volumes in the associated sequence of flows, even without host address information. Therefore, they can be used to identify hosts and users. Timestamps and counters are also vulnerable to traffic injection attacks, where traffic with a known pattern is injected into a network under measurement, and this pattern is later identified in the anonymized dataset.
、それ自体のではない識別子が、タイムスタンプとカウンタは、ネットワーク上のホストとユーザーの行動を明らかにすることができます。任意のネットワーク活動もホストアドレス情報なし、フローの関連配列の相対的な時間差とデータボリュームのパターンによって認識可能です。そのため、彼らはホストとユーザーを識別するために使用することができます。タイムスタンプとカウンタはまた、既知のパターンを有するトラフィックは、被測定ネットワークに注入されたトラフィックインジェクション攻撃に対して脆弱であり、このパターンは、後に匿名データセット内で識別されます。
The simplest and most extreme form of anonymization, which can be applied to any field of a flow record, is black-marker anonymization, or complete deletion of a given field. Note that black-marker anonymization is equivalent to simply not exporting the field(s) in question.
フローレコードの任意のフィールドに適用することができる匿名の最も単純で最も極端な形態は、黒マーカー匿名、または指定されたフィールドの完全な欠失です。黒のマーカー匿名は、単に問題のフィールド（複数可）をエクスポートしないのと同じであることに注意してください。
While black-marker anonymization completely protects the data in the deleted fields from the risk of disclosure, it also reduces the utility of the anonymized dataset as a whole. Techniques that retain some information while reducing (though not eliminating) the disclosure risk will be extensively discussed in the following sections; note that the techniques specifically applicable to IP addresses, timestamps, ports, and counters will be discussed in separate sections.
黒マーカー匿名は完全開示のリスクから削除されたフィールド内のデータを保護しながら、それはまた、全体としての匿名データセットの有用性を低下させます。 （排除しないが）リスクが広く、次のセクションで説明される開示を低減しつつ、いくつかの情報を保持する技術。 IPアドレスに特異的に適用可能な技術、タイムスタンプ、ポート、およびカウンタが別のセクションで説明されることに注意。
Since IP addresses are the most common identifiers within flow data that can be used to directly identify a person, organization, or host, most of the work on flow and trace data anonymization has gone into IP address anonymization techniques. Indeed, the aim of most attacks against anonymization is to recover the map from anonymized IP addresses to original IP addresses thereby identifying the identified hosts. Therefore, there is a wide range of IP address anonymization schemes that fit into the following categories.
IPアドレスが直接、人、組織、またはホストを識別するために使用することができるフロー・データ内の最も一般的な識別子ですので、フローおよびトレースデータの匿名化に関する作業のほとんどは、IPアドレスの匿名化技術へ行ってきました。確かに、匿名化に対するほとんどの攻撃の目的は、それによって識別されるホストを識別する元のIPアドレスに匿名化したIPアドレスからのマップを回復することです。したがって、次のカテゴリに収まるIPアドレスの匿名化スキームの広い範囲があります。
+------------------------------------+---------------------+
| Scheme | Action |
+------------------------------------+---------------------+
| Truncation | Generalization |
| Reverse Truncation | Generalization |
| Permutation | Direct Substitution |
| Prefix-preserving Pseudonymization | Direct Substitution |
+------------------------------------+---------------------+
Truncation removes "n" of the least significant bits from an IP address, replacing them with zeroes. In effect, it replaces a host address with a network address for some fixed netblock; for IPv4 addresses, 8-bit truncation corresponds to replacement with a /24 network address. Truncation is a non-reversible generalization scheme. Note that while truncation is effective for making hosts non-identifiable, it preserves information that can be used to identify an organization, a geographic region, a country, or a continent.
トランケーションは、IPアドレスから最下位ビットの「n」は、ゼロで置き換えるを除去します。実際に、それはいくつかの固定されたネットブロックのネットワークアドレスとホストアドレスを置き換えます。 IPv4アドレスのために、8ビットの切り捨ては、/ 24ネットワークアドレスの置換に対応します。切り捨ては非可逆一般化スキームです。切り捨ては、非識別可能なホストを製造するために有効であるが、それは組織、地域、国、または大陸を識別するために使用できる情報を保存することに留意されたいです。
Truncation to an address length of 0 is equivalent to black-marker anonymization. Complete removal of IP address information is only recommended for analysis tasks that have no need to separate flow data by host or network; e.g., as a first stage to per-application (port) or time-series total volume analyses.
0のアドレスの長さに切り捨てが黒色マーカー匿名と等価です。 IPアドレス情報の完全な除去は、唯一のホストまたはネットワークによるフローデータを分離する必要がない分析作業のために推奨されます。例えば、アプリケーションごとの（ポート）への第一段階として、または時系列の総容積は分析。
Reverse truncation removes "n" of the most significant bits from an IP address, replacing them with zeroes. Reverse truncation is a non-reversible generalization scheme. Reverse truncation is effective for making networks unidentifiable, partially or completely removing information that can be used to identify an organization, a geographic region, a country, or a continent (or Regional Internet Registry (RIR) region of responsibility). However, it may cause ambiguity when applied to data collected from more than one network, since it treats all the hosts with the same address on different networks as if they are the same host. It is not particularly useful when publishing data where the network of origin is known or can be easily guessed by virtue of the identity of the publisher.
リバース切り捨てはゼロに置き換える、IPアドレスから最上位ビットの「n」を削除します。リバース切り捨てが非可逆一般化スキームです。逆トランケーションは、部分的に、ネットワークは識別不可能製造又は完全組織、地域、国、または大陸（または責任の地域インターネットレジストリ（RIR）領域）を識別するために使用できる情報を除去するのに有効です。複数のネットワークから収集されたデータに適用されたとき、彼らは同じホストであるかのように、それは異なるネットワーク上の同じアドレスを持つすべてのホストを扱いますので、しかし、それは、あいまいさを引き起こす可能性があります。起源のネットワークが知られているか、容易に、パブリッシャの識別によって推測することができるデータを公開する場合には特に有用ではありません。
Like truncation, reverse truncation to an address length of 0 is equivalent to black-marker anonymization.
切り捨てと同様に、0のアドレスの長さに逆切り捨てが黒色マーカー匿名と等価です。
Permutation is a direct substitution technique, replacing each IP address with an address selected from the set of possible IP addresses, such that each anonymized address represents a unique original address. The selection function is often random, though it is not necessarily so. Permutation does not preserve any structural information about a network, but it does preserve the unique count of IP addresses. Any application that requires more structure than host-uniqueness will not be able to use permuted IP addresses.
順列は各匿名アドレスが一意元のアドレスを表すように、可能なIPアドレスのセットから選択されたアドレスと各IPアドレスを交換、直接置換技術です。それは必ずしもそうではないですが、選択機能は、多くの場合、ランダムです。順列は、ネットワークに関するあらゆる構造情報を保存しませんが、IPアドレスのユニークな数を保持しません。ホスト・一意性よりも多くの構造を必要とするアプリケーションには、並べ替えられたIPアドレスを使用することはできません。
There are many variations of permutation functions, each of which has trade-offs in performance, security, and guarantees of non-collision; evaluating these trade-offs is implementation independent. However, in general, permutation functions applied to anonymization SHOULD be difficult to reverse without knowing the parameters (e.g., a secret key for Hashed Message Authentication Code (HMAC). Given the relatively small space of IPv4 addresses in particular, hash functions applied without additional parameters could be reversed through brute force if the hash function is known, and SHOULD NOT be used as permutation functions. Permutation functions may guarantee non-collision (i.e., that each anonymized address represents a unique original address), but need not; however, the probability of collision SHOULD be low. Nevertheless, we treat even permutations with low but nonzero collision probability as a direct substitution. Beyond these guidelines, recommendations for specific permutation functions are out of scope for this document.
非衝突のパフォーマンス、セキュリティ、および保証におけるトレードオフをそれぞれ有する置換機能、多くのバリエーションがあります。これらのトレードオフを評価することは、実装独立しています。しかし、一般的には、匿名に適用される順列関数は、パラメータ（例えば、ハッシュメッセージ認証コード（HMAC）用の秘密鍵を知らなくても、逆にすることは困難であるべきである。具体的にはIPv4アドレスの比較的小さなスペースを考えると、ハッシュ関数を追加することなく、適用しますパラメータは、ハッシュ関数が既知である場合、ブルートフォースを介して逆にすることができる、及び順列関数として使用することはできません順列関数は、非衝突を保証することができる（すなわち、それぞれの匿名アドレスは一意元のアドレスを表すこと）が、そうである必要はない;しかしながら、衝突の確率は低くなければならない。それにもかかわらず、私たちが直接置換として低いがゼロでない衝突確率でさえ順列を扱う。これらのガイドラインを超えて、特定の置換機能のための推奨事項は、この文書の範囲外です。
Prefix-preserving pseudonymization is a direct substitution technique, like permutation but further restricted such that the structure of subnets is preserved at each level while anonymizing IP addresses. If two real IP addresses match on a prefix of "n" bits, the two anonymized IP addresses will match on a prefix of "n" bits as well. This is useful when relationships among networks must be preserved for a given analysis task, but introduces structure into the anonymized data that can be exploited in attacks against the anonymization technique.
プレフィックス保存仮名化は順列のように、直接置換法であるが、さらにIPアドレスを匿名化しながら、サブネットの構造は、各レベルで保存されるように制限されました。二つの実IPアドレスが「N」ビットのプレフィックスに一致する場合、2つの匿名化IPアドレスは、同様の「n」ビットのプレフィックスに一致します。これは、ネットワーク間の関係が与えられた分析タスクのために保存しなければならない場合に便利ですが、匿名化技術に対する攻撃に悪用される可能性が匿名化データに構造を導入しています。
Scanning in Internet background traffic can cause particular problems with this technique: if a scanner uses a predictable and known sequence of addresses, this information can be used to reverse the substitution. The low-order portion of the address can be left unanonymized as a partial defense against this attack.
インターネットバックグラウンドトラフィックのスキャンは、この技術を用いて特定の問題を引き起こす可能性があります：スキャナはアドレスの予測可能と既知の配列を使用している場合、この情報は置換を逆転させるために使用することができます。アドレスの下位部分は、この攻撃に対する部分的な防御としてunanonymizedままにすることができます。
Flow data containing sub-IP information can also contain identifying information in the form of the hardware (MAC) address. While MAC address information cannot be used to locate a node within a network, it can be used to directly and uniquely identify a specific device. Vendors or organizations within the supply chain may then have the information necessary to identify the entity or individual that purchased the device.
サブIP情報を含むフローデータは、ハードウェア（MAC）アドレスの形式で識別情報を含むことができます。 MACアドレス情報は、ネットワーク内のノードを見つけるために使用することができないが、直接一意特定のデバイスを識別するために使用することができます。サプライチェーン内のベンダーや組織は、デバイスを購入したエンティティまたは個人を識別するために必要な情報を有していてもよいです。
MAC address information is not as structured as IP address information. EUI-48 and EUI-64 MAC addresses contain an Organizational Unique Identifier (OUI) in the three most significant bytes of the address; this OUI additionally contains bits noting whether the address is locally or globally administered. Beyond this, there is no standard relationship among the OUIs assigned to a given vendor.
MACアドレス情報は、IPアドレス情報として構成されていないよう。 EUI-48とEUI-64 MACアドレスは、アドレスの上位3バイトの組織固有識別子（OUI）を含みます。これはさらに、OUIアドレスがローカルまたはグローバルに投与されるかどうかを指摘ビットを含みます。これを越えて、与えられたベンダーに割り当てられたOUIの間には、標準的な関係はありません。
Note that MAC address information also appears within IPv6 addresses as the EAP-64 address, or EAP-48 address encoded as an EAP-64 address, is used as the least significant 64 bits of the IPv6 address in the case of link-local addressing or stateless autoconfiguration; the considerations and techniques in this section may then apply to such IPv6 addresses as well.
MACはまた、EAP-64アドレスとしてIPv6アドレス内に表示され、またはEAP-64アドレスとしてエンコードEAP-48アドレスは、リンクローカルアドレス指定の場合には、IPv6アドレスの最下位64ビットとして使用される情報をアドレスことに注意してくださいまたはステートレス自動設定。このセクションで考察および技術は、その後もこのようなIPv6のアドレスに適用することができます。
+-----------------------------+---------------------+
| Scheme | Action |
+-----------------------------+---------------------+
| Truncation | Generalization |
| Reverse Truncation | Generalization |
| Permutation | Direct Substitution |
| Structured Pseudonymization | Direct Substitution |
+-----------------------------+---------------------+
Truncation removes "n" of the least significant bits from a MAC address, replacing them with zeroes. In effect, it retains bits of OUI, which identifies the manufacturer, while removing the least significant bits identifying the particular device. Truncation of 24 bits of an EAP-48 or 40 bits of an EAP-64 address zeroes out the device identifier while retaining the OUI.
トランケーションは、MACアドレスから最下位ビットの「n」は、ゼロで置き換えるを除去します。実際には、特定のデバイスを識別するの最下位ビットを除去しながら、製造者を識別するOUIのビットを保持します。 OUIを保持しながらデバイス識別子うちEAP-64アドレスゼロのEAP-48又は40ビットの24ビットの切り捨て。
Truncation is effective for making device manufacturers partially or completely identifiable within a dataset while deleting unique host identifiers; this can be used to retain and aggregate MAC-layer behavior by vendor.
トランケーションは、一意のホスト識別子を削除しながら、部分的にまたは完全に識別可能なデータセット内のデバイスメーカーを製造するために有効です。これは、ベンダーによってMAC層の動作を保持し、集約するために使用することができます。
Truncation to an address length of 0 is equivalent to black-marker anonymization.
0のアドレスの長さに切り捨てが黒色マーカー匿名と等価です。
Reverse truncation removes "n" of the most significant bits from a MAC address, replacing them with zeroes. Reverse truncation is a non-reversible generalization scheme. This has the effect of removing bits of the OUI, which identify manufacturers, before removing the least significant bits. Reverse truncation of 24 bits zeroes out the OUI.
リバース切り捨てはゼロに置き換える、MACアドレスから最上位ビットの「n」を削除します。リバース切り捨てが非可逆一般化スキームです。これは、最下位ビットを除去する前に、メーカーを識別OUIのビットを除去する効果を有します。 24ビットの逆切り捨てはOUIをゼロに。
Reverse truncation is effective for making device manufacturers partially or completely unidentifiable within a dataset. However, it may cause ambiguity by introducing the possibility of truncated MAC address collision. Also, note that the utility of removing manufacturer information is not particularly well covered by the literature.
リバース切り捨ては、部分的または完全に識別不能なデータセット内のデバイスメーカーを作るために効果的です。しかし、それは切り捨てMACアドレスの衝突の可能性を導入することにより、曖昧さを引き起こす可能性があります。また、製造者情報を除去する有用性は、特に、文献によって覆われていないことに注意してください。
Reverse truncation to an address length of 0 is equivalent to black-marker anonymization.
0のアドレス長に逆切り捨てが黒色マーカー匿名と等価です。
Permutation is a direct substitution technique, replacing each MAC address with an address selected from the set of possible MAC addresses, such that each anonymized address represents a unique original address. The selection function is often random, though it is not necessarily so. Permutation does not preserve any structural information about a network, but it does preserve the unique count of devices on the network. Any application that requires more structure than host-uniqueness will not be able to use permuted MAC addresses.
順列は各匿名アドレスが一意元のアドレスを表すように、可能なMACアドレスのセットから選択されたアドレスで各MACアドレスを交換、直接置換技術です。それは必ずしもそうではないですが、選択機能は、多くの場合、ランダムです。順列は、ネットワークに関するあらゆる構造情報を保存しませんが、ネットワーク上のデバイスのユニークな数を保持しません。ホスト・一意性よりも多くの構造を必要とするアプリケーションには、並べ替えられたMACアドレスを使用することはできません。
There are many variations of permutation functions, each of which has trade-offs in performance, security, and guarantees of non-collision; evaluating these trade-offs is implementation independent. However, in general, permutation functions applied to anonymization SHOULD be difficult to reverse without knowing the parameters (e.g., a secret key for HMAC). While the EAP-48 space is larger than the IPv4 address space, hash functions applied without additional parameters could be reversed through brute force if the hash function is known, and SHOULD NOT be used as permutation functions. Permutation functions may guarantee non-collision (i.e., that each anonymized address represents a unique original address), but need not; however, the probability of collision SHOULD be low. Nevertheless, we treat even permutations with low but nonzero collision probability as a direct substitution. Beyond these guidelines, recommendations for specific permutation functions are out of scope for this document.
非衝突のパフォーマンス、セキュリティ、および保証におけるトレードオフをそれぞれ有する置換機能、多くのバリエーションがあります。これらのトレードオフを評価することは、実装独立しています。しかし、一般に、匿名化に適用される順列関数は、パラメータ（HMACのために例えば、秘密鍵）を知ることなく逆にすることは困難であるべきです。 EAP-48空間は、IPv4アドレス空間よりも大きいが、追加のパラメータを指定せずに適用されるハッシュ関数は、ハッシュ関数が既知である場合、ブルートフォースを介して逆にすることができる、及び順列関数として使用することはできません。順列関数は、（各匿名アドレスは一意元のアドレスを表すこと、すなわち、）非衝突を保証するものではなく、必要があるかもしれません。しかし、衝突の確率は低くなければなりません。それにもかかわらず、我々は直接の代替として低いがゼロでない衝突確率でさえ順列を扱います。これらのガイドラインを超えて、特定の置換機能のための推奨事項は、この文書の範囲外です。
Structured pseudonymization for MAC addresses is a direct substitution technique, like permutation, but restricted such that the OUI (the most significant three bytes) is permuted separately from the node identifier, the remainder. This is useful when the uniqueness of OUIs must be preserved for a given analysis task, but introduces structure into the anonymized data that can be exploited in attacks against the anonymization technique.
MACアドレスのための構造化された仮名は順列のような、直接置換技術であるが、OUI（最上位3バイト）は、ノード識別子、残りは別に置換されるように制限されました。これは、のOUIの一意性が与えられた分析タスクのために保存しなければならない場合に便利ですが、匿名化技術に対する攻撃に悪用される可能性が匿名化データに構造を導入しています。
The particular time at which a flow began or ended is not particularly identifiable information, but it can be used as part of attacks against other anonymization techniques or for user profiling, e.g., as in [Mur07]. Timestamps can be used in traffic injection attacks, which use known information about a set of traffic generated or otherwise known by an attacker to recover mappings of other anonymized fields, as well as to identify certain activity by response delay and size fingerprinting, which compares response sizes and inter-flow times in anonymized data to known values. Note that these attacks have been shown to be relatively robust against timestamp anonymization techniques (see [Bur10]), so the techniques presented in this section are relatively weak and should be used with care.
フローが開始又は終了した特定の時間は、特に特定できる情報はありませんが、[Mur07]のように、例えば、他の匿名化技術に対する攻撃の一部として、またはユーザプロファイリングのために使用することができます。タイムスタンプは、他の匿名のフィールドのマッピングを回復するために、ならびに応答を比較し、応答遅れおよびサイズフィンガープリントによって特定の活動を識別するために、攻撃者によって生成されるか、またはそうでなければ既知のトラフィックのセットに関する既知の情報を使用してトラフィックインジェクション攻撃で使用することができます既知の値への匿名データでサイズおよびインターフロー回。これらの攻撃は、（[Bur10]参照）タイムスタンプ匿名化技術に対して比較的ロバストであることが示されているので、このセクションで提示技術は比較的弱く、注意して使用すべきであることに留意されたいです。
+-----------------------+----------------------------+
| Scheme | Action |
+-----------------------+----------------------------+
| Precision Degradation | Generalization |
| Enumeration | Direct or Set Substitution |
| Random Shifts | Direct Substitution |
+-----------------------+----------------------------+
Precision Degradation is a generalization technique that removes the most precise components of a timestamp, accounting for all events occurring in each given interval (e.g., one millisecond for millisecond level degradation) as simultaneous. This has the effect of potentially collapsing many timestamps into one. With this technique, time precision is reduced and sequencing may be lost, but the information regarding at which time the event occurred is preserved. The anonymized data may not be generally useful for applications that require strict sequencing of flows.
精度の劣化は同時に、各所定の間隔（ミリ秒レベルの分解のため、例えば、1ミリ秒）で発生するすべてのイベントを占め、タイムスタンプの最も正確な成分を除去する一般化技術です。これは、潜在的に一つに多くのタイムスタンプを崩壊させる効果を有します。この手法では、時間精度が低下し、シーケンシングが失われることがありますが、イベントが発生した時点での情報が保存されています。匿名データは、フローの厳密な順序付けを必要とするアプリケーションのために一般に有用ではないかもしれません。
Note that flow meters with low time precision (e.g., second precision, or millisecond precision on high-capacity networks) perform the equivalent of precision degradation anonymization by their design.
その設計により精度劣化匿名の等価を行う（大容量ネットワーク上の例えば第2の精度、またはミリ秒の精度）が低い時間精度で流量計に注意してください。
Also, note that degradation to a very low precision (e.g., on the order of minutes, hours, or days) is commonly used in analyses operating on time-series aggregated data, and may also be described as binning; though the time scales are longer and applicability more restricted, in principle, this is the same operation.
また、一般に時系列集計データ上で動作解析に使用され、またビニングとして説明することができる（例えば、数分程度の、時間、または日）非常に低い精度劣化に注意してください。時間スケールは、原則的に、長く、適用性がより制限されたものの、これは同じ操作です。
Precision degradation to infinitely low precision is equivalent to black-marker anonymization. Removal of timestamp information is only recommended for analysis tasks that have no need to separate flows in time, for example, for counting total volumes or unique occurrences of other flow keys in an entire dataset.
無限に低い精度の精度劣化は黒マーカー匿名と等価です。タイムスタンプ情報の除去は、唯一のデータセット全体での総ボリュームまたは他の流れのキーの独特の発生をカウントするため、例えば、時間に流れを分離する必要がない分析作業のために推奨されます。
Enumeration is a substitution function that retains the chronological order in which events occurred while eliminating time information. Timestamps are substituted by equidistant timestamps (or numbers) starting from a randomly chosen start value. The resulting data is useful for applications requiring strict sequencing, but not for those requiring good timing information (e.g., delay- or jitter-measurement for quality-of-service (QoS) applications or service-level agreement (SLA) validation).
列挙は、時間情報を排除しながら、イベントが発生した時系列順を保持し、置換機能です。タイムスタンプは、ランダムに選択された開始値から開始して等距離にタイムスタンプ（または数字）で置換されています。得られたデータは、厳密な順序付けを必要とする用途のためにではなく、良好なタイミング情報（サービス品質（QoS）のアプリケーションまたはサービスレベルアグリーメント（SLA）の検証のために、例えば、遅延 - 又はジッタ測定）を必要とするために有用です。
Note that enumeration is functionally equivalent to precision degradation in any environment into which traffic can be regularly injected to serve as a clock at the precision of the frequency of the injected flows.
その列挙は、トラフィックを定期的に注入された流れの周波数の精度のクロックとして機能するように注入することができるその中に任意の環境の精度劣化と機能的に等価であることに注意してください。
Random time shifts add a random offset to every timestamp within a dataset. Therefore, this reversible substitution technique retains duration and inter-event interval information as well as the chronological order of flows. Random time shifts are quite weak and relatively easy to reverse in the presence of external knowledge about traffic on the measured network.
ランダムな時間シフトは、データセット内のすべてのタイムスタンプにランダムオフセットを追加します。したがって、この可逆置換技術は、持続時間及びイベント間間隔情報ならびにフローの時間的な順序を保持しています。ランダムな時間シフトは非常に弱く、測定、ネットワーク上のトラフィックに関する外部知識の存在下で逆転するのが比較的容易です。
Counters (such as packet and octet volumes per flow) are subject to fingerprinting and injection attacks against anonymization or for user profiling as timestamps are. Data sets with anonymized counters are useful only for analysis tasks for which relative or imprecise magnitudes of activity are useful. Counter information can also be completely removed, but this is only recommended for analysis tasks that have no need to evaluate the removed counter, for example, for counting only unique occurrences of other flow keys.
タイムスタンプがそうであるように（例えばフローごとのパケットとオクテットボリュームなど）のカウンタは匿名に対してまたはユーザプロファイリングのためのフィンガープリント及び注入攻撃の対象となっています。匿名化されたカウンタを使用したデータセットは、唯一の活性の相対または不正確な大きさが有用である解析作業に有用です。カウンター情報も完全に除去することができますが、これは唯一の他のフローキーの唯一のユニークな発生をカウントするため、例えば、削除カウンタを評価する必要がない分析作業のために推奨されます。
+-----------------------+----------------------------+
| Scheme | Action |
+-----------------------+----------------------------+
| Precision Degradation | Generalization |
| Binning | Generalization |
| Random noise addition | Direct or Set Substitution |
+-----------------------+----------------------------+
As with precision degradation in timestamps, precision degradation of counters removes lower-order bits of the counters, treating all the counters in a given range as having the same value. Depending on the precision reduction, this loses information about the relationships between sizes of similarly sized flows, but keeps relative magnitude information. Precision degradation to an infinitely low precision is equivalent to black-marker anonymization.
タイムスタンプの精度劣化と同様に、カウンタの精度劣化が同じ値を有するものとして指定された範囲内のすべてのカウンタを治療、カウンタの下位ビットを除去します。精度の低下に応じて、これは、同様の大きさの流れの大きさとの関係についての情報を失うが、相対的な大きさの情報を保持します。無限に低い精度の精度劣化は黒マーカー匿名と等価です。
Binning can be seen as a special case of precision degradation; the operation is identical, except for in precision degradation the counter ranges are uniform, and in binning, they need not be. For example, consider separating unopened TCP connections from potentially opened TCP connections. Here, packet counters per flow would be binned into two bins, one for 1-2 packet flows, and one for flows with 3 or more packets. Binning schemes are generally chosen to keep precisely the amount of information required in a counter for a given analysis task. Note that, also unlike precision degradation, the bin label need not be within the bin's range. Binning counters to a single bin is equivalent to black-marker anonymization.
ビニングは、精度劣化の特別なケースとして見ることができます。動作は精度劣化カウンタの範囲は均一であり、そしてビニングでは、それらはである必要はない点を除いて、同一です。例えば、潜在的に開かれたTCP接続から未開封のTCP接続を分離することを検討してください。ここでは、フローごとのパケットカウンタは2つのビン、1-2パケットフローのための1つ、および3つの以上のパケットとフローの一つにビニングされるだろう。ビニングスキームは、一般的に、正確に所定の解析タスクのカウンタに必要な情報の量を保つように選択されます。また、高精度の劣化とは異なり、ビンのラベルがビンの範囲内である必要がない、ということに注意してください。単一のビンにカウンタをビニングすることは黒のマーカー匿名に相当します。
Random noise addition adds a random amount to a counter in each flow; this is used to keep relative magnitude information and minimize the disruption to size relationship information while avoiding fingerprinting attacks against anonymization. Note that there is no guarantee that random noise addition will maintain ranking order by a counter among members of a set. Random noise addition is particularly useful when the derived analysis data will not be presented in such a way as to require the lower-order bits of the counters.
ランダムノイズ付加は、各フロー内のカウンタへのランダム量を加算します。これは、相対的な大きさの情報を保持し、匿名化に対する指紋攻撃を回避しながら、サイズ関係情報の混乱を最小限にするために使用されています。ランダムノイズの付加がセットのメンバー間でカウンタによって順位を維持するという保証がないことに注意してください。誘導された分析データがカウンタの下位ビットを必要とするような方法で提示されない場合にランダムノイズ付加は、特に有用です。
Other fields, particularly port numbers and protocol numbers, can be used to partially identify the applications that generated the traffic in a given flow trace. This information can be used in fingerprinting attacks, and may be of interest on its own (e.g., to reveal that a certain application with suspected vulnerabilities is running on a given network). These fields are generally anonymized using one of two techniques.
他の分野、特に、ポート番号、プロトコル番号は、部分的に所定のフロー・トレースのトラフィックを生成するアプリケーションを識別するために使用することができます。この情報は、（例えば、疑いのある脆弱性を有する特定のアプリケーションが特定のネットワーク上で実行されていることを明らかに）指紋攻撃に使用することができ、そしてそれ自体で関心対象のものであってもよいです。これらのフィールドは、一般に、2つの方法のいずれかを使用して匿名化されています。
+-------------+---------------------+
| Scheme | Action |
+-------------+---------------------+
| Binning | Generalization |
| Permutation | Direct Substitution |
+-------------+---------------------+
Binning is a generalization technique mapping a set of potentially non-uniform ranges into a set of arbitrarily labeled bins. Common bin arrangements depend on the field type and the analysis application. For example, an IP protocol bin arrangement may preserve 1, 6, and 17 for ICMP, UDP, and TCP traffic, and bin all other protocols into a single bin, to mitigate the use of uncommon protocols in fingerprinting attacks. Another example arrangement may bin source and destination ports into low (0-1023) and high (1024- 65535) bins in order to tell service from ephemeral ports without identifying individual applications.
ビニングは、潜在的に不均一のセットをマッピングする一般化技術を任意標識されたビンのセットに範囲です。一般的なビンの手配は、フィールドタイプおよび分析アプリケーションに依存します。例えば、IPプロトコルビン構成は、フィンガープリント攻撃に珍しいプロトコルの使用を軽減するために、単一のビンに1,6、およびICMP、UDP、およびTCPトラフィックの17、ビン、他のすべてのプロトコルを維持することができます。別の例示的な構成は、ビンの送信元ポートおよび宛先ポートは、個々のアプリケーションを特定することなく、エフェメラルポートからサービスを伝えるために、ロー（0〜1023）および（1024 65535）高いビンにしてもよいです。
Binning other flow key fields to a single bin is equivalent to black-marker anonymization. Removal of other flow key information is only recommended for analysis tasks that have no need to differentiate flows on the removed keys, for example, for total traffic counts or unique counts of other flow keys.
単一のビンに他の流れキーフィールドをビニングする黒マーカー匿名と等価です。他のフローキー情報の除去が唯一の総トラフィックカウントまたは他のフローキーのユニークなカウントのため、例えば、削除キーの流れを区別する必要がない分析作業のために推奨されます。
Permutation is a direct substitution technique, replacing each value with an value selected from the set of possible range, such that each anonymized value represents a unique original value. This is used to preserve the count of unique values without preserving information about, or the ordering of, the values themselves.
順列は各匿名化値が一意の元の値を表すように可能な範囲の集合から選択された値と各値を置換、直接置換技術です。これは、情報を保存せずにユニークな値のカウント、または値自体の順序を保持するために使用されます。
While permutation ideally guarantees that each anonymized value represents a unique original value, such may require significant state in the Intermediate Anonymization Process. Therefore, permutation may be implemented by hashing for performance reasons, with hash functions that may have relatively small collision probabilities. Such techniques are still essentially direct substitution techniques, despite the nonzero error probability.
順列は、理想的には各匿名化値が一意の元の値を表していることを保証しながら、このような中間匿名化プロセスの大幅な状態を必要とするかもしれません。したがって、順列は、比較的小さな衝突確率を有することができるハッシュ関数を用いて、パフォーマンス上の理由のためにハッシュすることによって実現されてもよいです。このような技術はまだ0以外のエラー確率にもかかわらず、基本的に直接の代替技術、です。
This section details the abstract parameters used to describe the anonymization techniques examined in the previous section, on a per-parameter basis. These parameters and their export safety inform the design of the IPFIX anonymization metadata export specified in the following section.
このセクションごとのパラメータに基づいて、前のセクションで検討匿名化技術を説明するために使用される抽象的パラメータを詳述します。これらのパラメータとその輸出の安全性については、次のセクションで指定されたIPFIX匿名化メタデータのエクスポートのデザインを知らせます。
A stable anonymization will always map a given value in the real space to a given value in the anonymized space, while an unstable anonymization will change this mapping over time; a completely unstable anonymization is essentially indistinguishable from black-marker anonymization. Any given anonymization technique may be applied with a varying range of stability. Stability is important for assessing the comparability of anonymized information in different datasets, or in the same dataset over different time periods. In practice, an anonymization may also be stable for every dataset published by a particular producer to a particular consumer, stable for a stated time period within a dataset or across datasets, or stable only for a single dataset.
不安定な匿名化が時間をかけて、このマッピングを変更する一方、安定匿名化は常に、匿名化された空間内で指定された値に実空間内の指定された値をマッピングします。完全に不安定な匿名は黒マーカー匿名から本質的に区別できません。任意の与えられた匿名化技術は、安定性の変化範囲で適用することができます。安定性は、または異なる期間にわたって同じデータセット内の異なるデータセットにおける匿名化情報の比較可能性を評価するために重要です。実際には、匿名化はまた、単一のデータセットのデータセット内のデータセット又は横切って規定の時間にわたって安定特定の消費者に特定のプロデューサによって公開されたすべてのデータセットの安定した、または安定であり得ます。
If no information about stability is available, users of anonymized data MAY assume that the techniques used are stable across the entire dataset, but unstable across datasets. Note that stability presents a risk-utility trade-off, as completely stable anonymization can be used for longer-term trend analysis tasks but also presents more risk of attack given the stable mapping. Information about the stability of a mapping SHOULD be exported along with the anonymized data.
安定性に関する情報がない場合は、匿名データの利用者は、使用される技術は、データセット全体にわたる安定したが、データセット全体では不安定であることを仮定してもよいです。完全に安定した匿名化は長期的な傾向の分析タスクのために使用することができるよう、リスク・ユーティリティのトレードオフを提示だけでなく、安定したマッピング与えられた攻撃のより多くのリスクを提示する安定性に注意してください。マッピングの安定性に関する情報は、匿名データと一緒にエクスポートする必要があります。
Truncation and precision degradation are described by the truncation length or the amount of data still remaining in the anonymized field after anonymization.
トランケーションと精度劣化が切り捨て長さや静止匿名化した後に匿名化フィールド内に残っているデータの量によって記載されています。
Truncation length can generally be inferred from a given dataset, and need not be specially exported or protected. For bit-level truncation, the truncated bits are generally inferable by the least significant bit set for an instance of an Information Element described by a given Template (or the most significant bit set, in the case of reverse truncation). For precision degradation, the truncation is inferable from the maximum precision given. Note that while this inference method is generally applicable, it is data dependent: there is no guarantee that it will recover the exact truncation length used to prepare the data.
切り捨て長さは、一般に、所与のデータセットから推測することができ、特別にエクスポートまたは保護する必要はありません。ビットレベルの切り捨てのため、切り捨てられたビット（逆トランケーションの場合に、または最上位ビットセット）指定されたテンプレートによって記述された情報要素のインスタンスの最下位ビットのセットによって、一般的に推論可能です。精度の劣化のため、切り捨てが所定の最大精度から推測できるです。この推定方法は、一般的に適用可能であるが、それはデータ依存であることに注意してください：それはデータを準備するために使用される正確な切り捨て長さを回復するという保証はありません。
In the special case of IP address export with variable (per-record) truncation, the truncation MAY be expressed by exporting the prefix length alongside the address.
変数を使用したIPアドレスの輸出（ごとの記録）切り捨ての特殊な場合には、切り捨てがアドレスと一緒にプレフィックス長をエクスポートすることにより発現させることができます。
Binning is described by the specification of a bin mapping function. This function can be generally expressed in terms of an associative array that maps each point in the original space to a bin, although from an implementation standpoint most bin functions are much simpler and more efficient.
ビニングは、ビンマッピング機能の仕様によって記述されます。この機能は、一般的な実装の観点から最もビン機能がはるかに簡単でより効率的であるが、ビンに元の空間内の各点をマッピング連想配列で表すことができます。
Since the bin map for a bin mapping function is in essence the bin mapping key, and can be used to partially deanonymize binned data, depending on the degree of generalization, information about the bin mapping function SHOULD NOT be exported.
ビンマッピング機能のためのビンマップは本質的に、ビンマッピングキーである、と一般化の程度に応じて、部分的にビニングされたデータをdeanonymizeするために使用することができますので、ビンマッピング機能についての情報は、エクスポートされるべきではありません。
Like binning, permutation is described by the specification of a permutation function. In the general case, this can be expressed in terms of an associative array that maps each point in the original space to a point in the anonymized space. Unlike binning, each point in the anonymized space corresponds to a single, unique point in the original space.
ビニングのように、置換は置換関数の仕様によって記述されます。一般的な場合では、これは匿名空間内の点に元の空間内の各点をマッピング連想配列で表すことができます。ビニングとは異なり、匿名空間内の各点は、元の空間内の単一の、ユニークな点です。
Since the parameters of the permutation function are in essence key-like (indeed, for cryptographic permutation functions, they are the keys themselves), information about the permutation function or its parameters SHOULD NOT be exported.
順列関数のパラメータは、（実際に、暗号順列機能のために、彼らは鍵そのものです）本質的には、キーのようなので、置換関数やそのパラメータに関する情報は、エクスポートされるべきではありません。
Shifting requires an amount by which to shift each value. Since the shift amount is the only key to a shift function, and can be used to trivially deanonymize data protected by shifting, information about the shift amount SHOULD NOT be exported.
シフトは、各値をシフトする量を必要とします。シフト量は、シフト機能にのみ鍵であり、シフトにより保護deanonymizeデータ自明にするために使用することができるので、シフト量の情報がエクスポートされるべきではありません。
Anonymized data exported via IPFIX SHOULD be annotated with anonymization metadata, which details which fields described by which Templates are anonymized, and provides appropriate information on the anonymization techniques used. This metadata SHOULD be exported in
IPFIXを介してエクスポートされた匿名化データは、テンプレートが匿名化される説明、および使用される匿名化技術に関する適切な情報を提供するフィールドを詳細匿名化メタデータで注釈されるべきです。このメタデータはでエクスポートされるべきである（SHOULD）
Data Records described by the recommended Options Templates described in this section; these Options Templates use the additional Information Elements described in the following subsection.
推奨オプションテンプレートで記述されたデータレコードは、このセクションで説明します。これらのオプションのテンプレートは以下のサブセクションで説明する追加の情報要素を使用します。
Note that fields anonymized using the black-marker (removal) technique do not require any special metadata support: black-marker anonymized fields SHOULD NOT be exported at all, by omitting the corresponding Information Elements from Template describing the Data Set. In the case where application requirements dictate that a black-marker anonymized field must remain in a Template, then an Exporting Process MAY export black-marker anonymized fields with their native length as all-zeros, but only in cases where enough contextual information exists within the record to differentiate a black-marker anonymized field exported in this way from a real zero value.
黒のマーカー匿名化フィールドは、データセットを記述したテンプレートからの対応する情報要素を省略することにより、すべてのエクスポートすべきではありません：フィールドは、特別なメタデータのサポートを必要としない黒のマーカー（除去）技術を使用して匿名化することに注意してください。アプリケーション要件は黒マーカー匿名フィールドテンプレートに維持しなければならないことを指示する場合には、次いで、エクスポートプロセスは、すべてゼロとして母国長さと黒のマーカー匿名フィールドをエクスポートでき、だけの場合に十分なコンテキスト情報は、内に存在する場合実際のゼロ値から、このようにエクスポートされた黒のマーカー匿名化フィールドを区別するために、レコード。
The Anonymization Options Template describes Anonymization Records, which allow anonymization metadata to be exported inline over IPFIX or stored in an IPFIX File, by binding information about anonymization techniques to Information Elements within defined Templates or Options Templates. IPFIX Exporting Processes SHOULD export anonymization records for any Template describing exported anonymized Data Records; IPFIX Collecting Processes and processes downstream from them MAY use anonymization records to treat anonymized data differently depending on the applied technique.
匿名化オプションテンプレートは、匿名化メタデータが定義されたテンプレートやオプションテンプレート内の情報要素への匿名化技術についての情報を結合することによって、IPFIXファイルにIPFIXの上にインラインでエクスポートまたは保存することを可能にする匿名化のレコード、説明します。 IPFIXのエクスポートプロセスがエクスポートされた匿名化されたデータレコードを記述するすべてのテンプレートの匿名レコードをエクスポートする必要があります。そこから下流のプロセスとプロセスを収集IPFIXが適用される技術に応じて異なる匿名データを処理するために匿名レコードを使用するかもしれません。
Anonymization Records contain ancillary information bound to a Template, so many of the considerations for Templates apply to Anonymization Records as well. First, reliability is important: an Exporting Process SHOULD export Anonymization Records after the Templates they describe have been exported, and SHOULD export anonymization records reliably if supported by the underlying transport (i.e., without partial reliability when using Stream Control Transmission Protocol (SCTP)).
匿名レコードテンプレートにバインドされた補助的な情報が含まれている、テンプレートの考慮事項の多くは、同様に匿名レコードに適用されます。まず、信頼性が重要である：エクスポートプロセスは、彼らが記述テンプレートがエクスポートされた後に匿名レコードをエクスポートする必要があり、基礎となるトランスポート（すなわち、ストリーム制御伝送プロトコル（SCTP）を使用した場合、部分的信頼性のない）でサポートされている場合は確実に匿名レコードをエクスポートする必要があります。
Anonymization Records MUST be handled by Collecting Processes as scoped to the Template to which they apply within the Transport Session in which they are sent. When a Template is withdrawn via a Template Withdrawal Message or expires during a UDP transport session, the accompanying Anonymization Records are withdrawn or expire as well and do not apply to subsequent Templates with the same Template ID within the Session unless re-exported.
匿名化のレコードは、それらが送信され、それらが交通セッション内で適用するテンプレートにスコープなどのプロセスを収集して処理する必要があります。テンプレートは、テンプレート無効化メッセージを経由して撤回またはUDPトランスポートセッション中に有効期限が切れている場合は、付属の匿名レコードは取り下げや、同様に期限切れと再輸出しない限り、セッション内で同じテンプレートIDを持つ以降のテンプレートには適用されませんされています。
The Stability Class within the anonymizationFlags IE can be used to declare that a given anonymization technique's mapping will remain stable across multiple sessions, but this does not mean that anonymization technique information given in the Anonymization Records themselves persist across Sessions. Each new Transport Session MUST contain new Anonymization Records for each Template describing anonymized Data Sets.
anonymizationFlags IE内の安定性クラスは、与えられた匿名化技術のマッピングは、複数のセッションにわたって安定したままであることを宣言するために使用することができますが、これは自身がセッション間で保持匿名レコードで与えられた匿名化技術の情報を意味するものではありません。それぞれの新しい交通のセッションは、匿名化データセットを記述し、各テンプレートの新しい匿名レコードを含まなければなりません。
SCTP per-stream export [IPFIX-PERSTREAM] may be used to ease management of Anonymization Records if appropriate for the application.
SCTPストリーム毎のエクスポート[IPFIX-PERSTREAM]は、適切な場合、アプリケーションのために匿名のレコードの管理を容易にするために使用されてもよいです。
The fields of the Anonymization Options Template are as follows:
次のように匿名化オプションテンプレートのフィールドは、次のとおりです。
+-------------------------+-----------------------------------------+
| IE | Description |
+-------------------------+-----------------------------------------+
| templateId [scope] | The Template ID of the Template or |
| | Options Template containing the |
| | Information Element described by this |
| | anonymization record. This Information |
| | Element MUST be defined as a Scope |
| | Field. |
| informationElementId | The Information Element identifier of |
| [scope] | the Information Element described by |
| | this anonymization record. This |
| | Information Element MUST be defined as |
| | a Scope Field. Exporting Processes |
| | MUST clear then Enterprise bit of the |
| | informationElementId and Collecting |
| | Processes SHOULD ignore it; information |
| | about enterprise-specific Information |
| | Elements is exported via the |
| | privateEnterpriseNumber Information |
| | Element. |
| privateEnterpriseNumber | The Private Enterprise Number of the |
| [scope] [optional] | enterprise-specific Information Element |
| | described by this anonymization record. |
| | This Information Element MUST be |
| | defined as a Scope Field if present. A |
| | privateEnterpriseNumber of 0 signifies |
| | that the Information Element is |
| | IANA-registered. |
| informationElementIndex | The Information Element index of the |
| [scope] [optional] | instance of the Information Element |
| | described by this anonymization record |
| | identified by the informationElementId |
| | within the Template. Optional; need |
| | only be present when describing |
| | Templates that have multiple instances |
| | of the same Information Element. This |
| | Information Element MUST be defined as |
| | a Scope Field if present. This |
| | Information Element is defined in |
| | Section 6.2. |
| anonymizationFlags | Flags describing the mapping stability |
| | and specialized modifications to the |
| | Anonymization Technique in use. SHOULD |
| | be present. This Information Element |
| | is defined in Section 6.2.3. |
| anonymizationTechnique | The technique used to anonymize the |
| | data. MUST be present. This |
| | Information Element is defined in |
| | Section 6.2.2. |
+-------------------------+-----------------------------------------+
Description: A zero-based index of an Information Element referenced by informationElementId within a Template referenced by templateId; used to disambiguate scope for templates containing multiple identical Information Elements.
説明：れるtemplateIdによって参照テンプレート内informationElementIdによって参照される情報要素の0から始まるインデックス。複数の同一の情報要素を含むテンプレートの適用範囲を明確にするために使用。
Abstract Data Type: unsigned16
抽象データ型：UNSIGNED16
Data Type Semantics: identifier
データ型の意味：識別子
ElementId: 287
ELEMENTID：287
Status: Current
ステータス：現在の
Description: A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements; these restrictions are noted in the table below.
説明：匿名化技術の説明が参照テンプレート内の参照情報要素に適用されます。それぞれの技術は、特定の情報要素に適用し、のみ特定の情報要素には推奨であってもよく、これらの制限は、以下の表に記載されています。
+-------+---------------------------+-----------------+-------------+
| Value | Description | Applicable to | Recommended |
| | | | for |
+-------+---------------------------+-----------------+-------------+
| 0 | Undefined: the Exporting | all | all |
| | Process makes no | | |
| | representation as to | | |
| | whether or not the | | |
| | defined field is | | |
| | anonymized. While the | | |
| | Collecting Process MAY | | |
| | assume that the field is | | |
| | not anonymized, it is not | | |
| | guaranteed not to be. | | |
| | This is the default | | |
| | anonymization technique. | | |
| 1 | None: the values exported | all | all |
| | are real. | | |
| 2 | Precision | all | all |
| | Degradation/Truncation: | | |
| | the values exported are | | |
| | anonymized using simple | | |
| | precision degradation or | | |
| | truncation. The new | | |
| | precision or number of | | |
| | truncated bits is | | |
| | implicit in the exported | | |
| | data and can be deduced | | |
| | by the Collecting | | |
| | Process. | | |
| 3 | Binning: the values | all | all |
| | exported are anonymized | | |
| | into bins. | | |
| 4 | Enumeration: the values | all | timestamps |
| | exported are anonymized | | |
| | by enumeration. | | |
| 5 | Permutation: the values | all | identifiers |
| | exported are anonymized | | |
| | by permutation. | | |
| 6 | Structured Permutation: | addresses | |
| | the values exported are | | |
| | anonymized by | | |
| | permutation, preserving | | |
| | bit-level structure as | | |
| | appropriate; this | | |
| | represents | | |
| | prefix-preserving IP | | |
| | address anonymization or | | |
| | structured MAC address | | |
| | anonymization. | | |
| 7 | Reverse Truncation: the | addresses | |
| | values exported are | | |
| | anonymized using reverse | | |
| | truncation. The number | | |
| | of truncated bits is | | |
| | implicit in the exported | | |
| | data, and can be deduced | | |
| | by the Collecting | | |
| | Process. | | |
| 8 | Noise: the values | non-identifiers | counters |
| | exported are anonymized | | |
| | by adding random noise to | | |
| | each value. | | |
| 9 | Offset: the values | all | timestamps |
| | exported are anonymized | | |
| | by adding a single offset | | |
| | to all values. | | |
+-------+---------------------------+-----------------+-------------+
Abstract Data Type: unsigned16
抽象データ型：UNSIGNED16
Data Type Semantics: identifier
データ型の意味：識別子
ElementId: 286
ELEMENTID：286
Status: Current
ステータス：現在の
Description: A flag word describing specialized modifications to the anonymization policy in effect for the anonymization technique applied to a referenced Information Element within a referenced Template. When flags are clear (0), the normal policy (as described by anonymizationTechnique) applies without modification.
説明：参照テンプレート内の参照情報要素に適用される匿名化技術のために有効に匿名ポリシーに特殊な変更を記述するフラグワード。フラグが（0）がクリアされている場合、通常のポリシーは、（anonymizationTechniqueによって記載されるように）変更することなく適用されます。
MSB 14 13 12 11 10 9 8 7 6 5 4 3 2 1 LSB
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Reserved |LOR|PmA| SC |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
anonymizationFlags IE
anonymizationFlags IE
+--------+----------+-----------------------------------------------+
| bit(s) | name | description |
| (LSB = | | |
| 0) | | |
+--------+----------+-----------------------------------------------+
| 0-1 | SC | Stability Class: see the Stability Class |
| | | table below, and Section 5.1. |
| 2 | PmA | Perimeter Anonymization: when set (1), source |
| | | Information Elements as described in |
| | | [RFC5103] are interpreted as external |
| | | addresses, and destination Information |
| | | Elements as described in [RFC5103] are |
| | | interpreted as internal addresses, for the |
| | | purposes of associating |
| | | anonymizationTechnique to Information |
| | | Elements only; see Section 7.2.2 for details. |
| | | This bit MUST NOT be set when associated with |
| | | a non-endpoint (i.e., source or destination) |
| | | Information Element. SHOULD be consistent |
| | | within a record (i.e., if a source |
| | | Information Element has this flag set, the |
| | | corresponding destination element SHOULD have |
| | | this flag set, and vice versa.) |
| 3 | LOR | Low-Order Unchanged: when set (1), the |
| | | low-order bits of the anonymized Information |
| | | Element contain real data. This modification |
| | | is intended for the anonymization of |
| | | network-level addresses while leaving |
| | | host-level addresses intact in order to |
| | | preserve host level-structure, which could |
| | | otherwise be used to reverse anonymization. |
| | | MUST NOT be set when associated with a |
| | | truncation-based anonymizationTechnique. |
| 4-15 | Reserved | Reserved for future use: SHOULD be cleared |
| | | (0) by the Exporting Process and MUST be |
| | | ignored by the Collecting Process. |
+--------+----------+-----------------------------------------------+
The Stability Class portion of this flags word describes the stability class of the anonymization technique applied to a referenced Information Element within a referenced Template. Stability classes refer to the stability of the parameters of the anonymization technique, and therefore the comparability of the mapping between the real and anonymized values over time. This determines which anonymized datasets may be compared with each other. Values are as follows:
このフラグワードの安定クラスの部分は、参照テンプレート内の参照情報要素に適用される匿名化技術の安定クラスを記載しています。安定クラスは、匿名化技術のパラメータ、したがって経時実数と匿名の値との間のマッピングの比較の安定性を指します。これは、データセットが互いに比較されてもよい匿名かを決定します。値は次のとおりです。
+-----+-----+-------------------------------------------------------+
| Bit | Bit | Description |
| 1 | 0 | |
+-----+-----+-------------------------------------------------------+
| 0 | 0 | Undefined: the Exporting Process makes no |
| | | representation as to how stable the mapping is, or |
| | | over what time period values of this field will |
| | | remain comparable; while the Collecting Process MAY |
| | | assume Session level stability, Session level |
| | | stability is not guaranteed. Processes SHOULD assume |
| | | this is the case in the absence of stability class |
| | | information; this is the default stability class. |
| 0 | 1 | Session: the Exporting Process will ensure that the |
| | | parameters of the anonymization technique are stable |
| | | during the Transport Session. All the values of the |
| | | described Information Element for each Record |
| | | described by the referenced Template within the |
| | | Transport Session are comparable. The Exporting |
| | | Process SHOULD endeavor to ensure at least this |
| | | stability class. |
| 1 | 0 | Exporter-Collector Pair: the Exporting Process will |
| | | ensure that the parameters of the anonymization |
| | | technique are stable across Transport Sessions over |
| | | time with the given Collecting Process, but may use |
| | | different parameters for different Collecting |
| | | Processes. Data exported to different Collecting |
| | | Processes are not comparable. |
| 1 | 1 | Stable: the Exporting Process will ensure that the |
| | | parameters of the anonymization technique are stable |
| | | across Transport Sessions over time, regardless of |
| | | the Collecting Process to which it is sent. |
+-----+-----+-------------------------------------------------------+
Abstract Data Type: unsigned16
抽象データ型：UNSIGNED16
Data Type Semantics: flags
データ型の意味：フラグ
ElementId: 285
ELEMENTID：285
Status: Current
ステータス：現在の
When exporting or storing anonymized flow data using IPFIX, certain interactions between the IPFIX protocol and the anonymization techniques in use must be considered; these are treated in the subsections below.
エクスポートまたはIPFIXを使用して匿名フローデータを格納する際に、IPFIXプロトコルと使用中の匿名化技術との間の特定の相互作用を考慮しなければなりません。これらは、以下のサブセクションで処理されています。
Anonymization may be applied to IPFIX data at three stages within the collection infrastructure: on initial export, at a mediator, or after collection, as shown in Figure 1. Each of these locations has specific considerations and applicability.
匿名は、収集インフラストラクチャ内の3つの段階でIPFIXデータに適用することができる：最初のエクスポートに、メディエータで、または収集後、図1に示すように、これらの位置の各々は、固有の考慮事項及び適用性を有しています。
+==========================================+
| Exporting Process |
+==========================================+
| |
| (Anonymized at Original Exporter) |
V |
+=============================+ |
| Mediator | |
+=============================+ |
| |
| (Anonymizing Mediator) |
V V
+==========================================+
| Collecting Process |
+==========================================+
|
| (Anonymizing CP/File Writer)
V
+--------------------+
| IPFIX File Storage |
+--------------------+
Figure 1: Potential Anonymization Locations
図1：潜在的な匿名の場所
Anonymization is generally performed before the wider dissemination or repurposing of a dataset, e.g., adapting operational measurement data for research. Therefore, direct anonymization of flow data on initial export is only applicable in certain restricted circumstances: when the Exporting Process (EP) is "publishing" data to a Collecting Process (CP) directly, and the Exporting Process and Collecting Process are operated by different entities. Note that certain guidelines in Section 7.2.3 with respect to timestamp anonymization may not apply in this case, as the Collecting Process may be able to deduce certain timing information from the time at which each Message is received.
匿名化は、一般的に研究するための動作の測定データを適合広い普及またはデータセットの再利用、例えば、前に行われます。したがって、最初のエクスポートのフローデータの直接匿名化は、特定の制限された状況においてのみ適用され：エクスポートプロセス（EP）を直接収集プロセス（CP）に「公開」データ、およびエクスポートプロセスと収集プロセスである場合、異なるによって操作されますエンティティ。収集プロセスは、各メッセージが受信された時刻から所定のタイミング情報を推定することができるかもしれないように、タイムスタンプ匿名に対して7.2.3で特定のガイドラインは、この場合には適用されないことに留意されたいです。
A much more flexible arrangement is to anonymize data within a Mediator [RFC6183]. Here, original data is sent to a Mediator, which performs the anonymization function and re-exports the anonymized data. Such a Mediator could be located at the administrative domain boundary of the initial Exporting Process operator, exporting anonymized data to other consumers outside the organization. In this case, the original Exporter SHOULD use TLS [RFC5246] as specified in [RFC5101] to secure the channel to the Mediator, and the Mediator should follow the guidelines in Section 7.2, to mitigate the risk of original data disclosure.
より柔軟な構成は、メディエータ[RFC6183]内のデータを匿名化することです。ここで、元のデータを匿名化機能を実行し、匿名化データを再エクスポートメディエータに送られます。このようなメディエータは、組織外の他の消費者に匿名データをエクスポートし、初期のエクスポートプロセスのオペレータの管理ドメインの境界に位置することができます。この場合には[RFC5101]で指定されるように、元の輸出業者は、メディエータにチャネルを確保するためにTLS [RFC5246]を使用する必要があり、メディエータは、元のデータの開示のリスクを軽減するために、セクション7.2のガイドラインに従うべきです。
When data is to be published as an anonymized dataset in an IPFIX File [RFC5655], the anonymization may be done at the final Collecting Process before storage and dissemination, as well. In this case, the Collector should follow the guidelines in Section 7.2, especially as regards File-specific Options in Section 7.2.4
データは、IPFIXファイル[RFC5655]に匿名のデータセットとして公開する場合、匿名化は、同様に、ストレージ・普及前の最終収集プロセスで行うことができます。この場合、コレクタは、第7.2.4項で、ファイル固有のオプションについて、特にとして、7.2節のガイドラインに従ってください
In each of these data flows, the anonymization of records is undertaken by an Intermediate Anonymization Process (IAP); the data flows into and out of this IAP are shown in Figure 2 below.
これらのデータフローの各々において、レコードの匿名化は、中間匿名化プロセス（IAP）によって行われます。データは、以下の図2に示されているにこのIAPの流出します。
packets --+ +- IPFIX Messages -+
| | |
V V V
+==================+ +====================+ +=============+
| Metering Process | | Collecting Process | | File Reader |
+==================+ +====================+ +=============+
| Non-anonymized | Records |
V V V
+=========================================================+
| Intermediate Anonymization Process (IAP) |
+=========================================================+
| Anonymized ^ Anonymized |
| Records | Records |
V | V
+===================+ Anonymization +=============+
| Exporting Process |<--- Parameters ------>| File Writer |
+===================+ +=============+
| |
+------------> IPFIX Messages <----------+
Figure 2: Data Flows through the Anonymization Process
図2：データは匿名化プロセスを流れます
Anonymization parameters must also be available to the Exporting Process and/or File Writer in order to ensure header data is also appropriately anonymized as in Section 7.2.3.
匿名化パラメータもまた、適切7.2.3項のように匿名化されたヘッダデータを確保するためにエクスポートプロセス及び/又はファイルライターに利用可能でなければなりません。
Following each of the data flows through the IAP, we describe five basic types of anonymization arrangements within this framework in Figure 3. In addition to the three arrangements described in detail above, anonymization can also be done at a collocated Metering
データのそれぞれはIAP流れる以下、我々は上で詳細に説明した3つの構成に加えて、図3に、このフレームワーク内で匿名化配列の5つの基本タイプについて説明し、匿名化はまた、並置メータで行うことができます
Process (MP) and File Writer (FW) (see Section 7.3.2 of [RFC5655]), or at a file manipulator, which combines a File Writer with a File Reader (FR) (see Section 7.3.7 of [RFC5655]).
プロセス（MP）とファイルライタ（FW）（[RFC5655]のセクション7.3.2を参照）、またはファイルリーダー（FR）とファイルライターを組み合わせたファイルマニピュレータ、で（[RFC5655]のセクション7.3.7を参照してください）。
+----+ +-----+ +----+
pkts -> | MP |->| IAP |->| EP |-> Anonymization on Original Exporter
+----+ +-----+ +----+
+----+ +-----+ +----+
pkts -> | MP |->| IAP |->| FW |-> Anonymizing collocated MP/File Writer
+----+ +-----+ +----+
+----+ +-----+ +----+
IPFIX -> | CP |->| IAP |->| EP |-> Anonymizing Mediator (Masq. Proxy)
+----+ +-----+ +----+
+----+ +-----+ +----+
IPFIX -> | CP |->| IAP |->| FW |-> Anonymizing collocated CP/File Writer
+----+ +-----+ +----+
+----+ +-----+ +----+
IPFIX -> | FR |->| IAP |->| FW |-> Anonymizing file manipulator
File +----+ +-----+ +----+
Figure 3: Possible Anonymization Arrangements in the IPFIX
Architecture
Note that anonymization may occur at more than one location within a given collection infrastructure, to provide varying levels of anonymization, disclosure risk, or data utility for specific purposes.
特定の目的のために匿名化、開示リスク、またはデータ・ユーティリティのさまざまなレベルを提供するために、指定されたコレクション・インフラストラクチャ内の複数の場所で発生する可能性があり、その匿名に留意されたいです。
In implementing and deploying the anonymization techniques described in this document, implementors should note that IPFIX already provides features that support anonymized data export, and use these where appropriate. Care must also be taken that data structures supporting the operation of the protocol itself do not leak data that could be used to reverse the anonymization applied to the flow data. Such data structures may appear in the header, or within the data stream itself, especially as options data. Each of these and their impact on specific anonymization techniques is noted in a separate subsection below.
この文書で説明匿名化技術を実装およびデプロイでは、実装者は、IPFIXが既に匿名データのエクスポートをサポートする機能を提供していることに注意し、適切な場合、これらを使用する必要があります。ケアは、プロトコル自体の動作をサポートするデータ構造は、フローデータに適用される匿名化を逆転するために使用することができるデータを漏れないように注意しなければなりません。そのようなデータ構造は、ヘッダに表示され、又はデータ・ストリーム自体の中、特にオプションのデータとしてもよいです。これらのそれぞれと特定の匿名化技術への影響を以下の別のサブセクションに留意されたいです。
Note, as in Section 6 above, that black-marker anonymized fields SHOULD NOT be exported at all; the absence of the field in a given Data Set is implicitly declared by not including the corresponding Information Element in the Template describing that Data Set.
黒マーカー匿名フィールドは全くエクスポートされるべきでないこと、上記第6のように、注意してください。与えられたデータセット内のフィールドが存在しないことが暗黙のうちにそのデータセットを記述するテンプレートに対応する情報要素を含めないで宣言されています。
When using precision degradation of timestamps, Exporting Processes SHOULD export timing information using Information Elements of an appropriate precision, as explained in Section 4.5 of [RFC5153]. For example, timestamps measured in millisecond-level precision and degraded to second-level precision should use flowStartSeconds and flowEndSeconds, not flowStartMilliseconds and flowEndMilliseconds.
[RFC5153]のセクション4.5で説明したようなプロセスをエクスポートする、タイムスタンプの精度劣化を使用する場合は、適切な精度の情報要素を使用してタイミング情報をエクスポートする必要があります。例えば、タイムスタンプは、ミリ秒レベルの精度で測定し、劣化への第2レベルの精度がflowStartSecondsとflowEndSeconds、ないflowStartMillisecondsとflowEndMillisecondsを使用すべきです。
When exporting anonymized data and anonymization metadata, Exporting Processes SHOULD ensure that the combination of Information Element and declared anonymization technique are compatible. Specifically, the applicable and recommended Information Element types and semantics for each technique are noted in the description of the anonymizationTechnique Information Element in Section 6.2.2. In this description, a timestamp is an Information Element with the data type dateTimeSeconds, dataTimeMilliseconds, dateTimeMicroseconds, or dateTimeNanoseconds; an address is an Information Element with the data type ipv4Address, ipv6Address, or macAddress; and an identifier is an Information Element with identifier data type semantics. Exporting Process MUST NOT export Anonymization Options records binding techniques to Information Elements to which they are not applicable, and SHOULD NOT export Anonymization Options records binding techniques to Information Elements for which they are not recommended.
匿名データと匿名のメタデータをエクスポートする場合、エクスポートプロセスは、情報要素の組み合わせと宣言した匿名化技術に互換性があることを確認する必要があります。具体的には、各技術に適用し、推奨情報要素の種類と意味は、6.2.2項でanonymizationTechnique情報要素の説明に記載されています。この説明では、タイムスタンプは、データ型dateTimeSeconds、dataTimeMilliseconds、dateTimeMicroseconds、又はdateTimeNanosecondsと情報要素です。アドレスは、データ型IPv4Addressを、ipv6Address、又はMACADDRESSと情報要素です。識別子は、識別子データ型のセマンティクスと情報要素です。匿名オプションをエクスポートしてはならないのエクスポートプロセスは、彼らが適用されないための情報要素への結合技術を記録し、匿名化オプションは、彼らが推奨されていないために情報要素への結合技術を記録エクスポートすべきではありません。
Data collected from a single network may require different anonymization policies for addresses internal and external to the network. For example, internal addresses could be subject to simple permutation, while external addresses could be aggregated into networks by truncation. When exporting anonymized perimeter bidirectional flow (biflow) data as in Section 5.2 of [RFC5103], this arrangement may be easily represented by specifying one technique for source endpoint information (which represents the external endpoint in a perimeter biflow) and one technique for destination endpoint information (which represents the internal address in a perimeter biflow).
単一のネットワークから収集されたデータは、ネットワークへの内部および外部アドレスごとに異なる匿名化政策が必要な場合があります。外部アドレスが切り捨てによってネットワークに集約することができるが、例えば、内部アドレスは、単純な置換を受けることができました。 [RFC5103]のセクション5.2のように双方向の流れ（バイフロー）周囲匿名データをエクスポートする場合、この構成が容易（境界バイフロー外部エンドポイントを表す）ソースエンドポイント情報のための1つの技術および宛先エンドポイントのための1つの技術を指定することによって表すことができます。情報（境界バイフローにおける内部アドレスを表します）。
However, it can also be useful to represent perimeter-based anonymization policies with unidirectional flow (uniflow), or non-perimeter biflow data. In this case, the Perimeter Anonymization bit (bit 2) in the anonymizationFlags Information Element describing the anonymized address Information Elements can be set to change the meaning of "source" and "destination" of Information Elements to mean "external" and "internal" as with perimeter biflows, but only with respect to anonymization policies.
しかし、また一方向流（ユニフロー）、または非周囲バイフローデータと境界ベースの匿名ポリシーを表現するために有用であり得ます。この場合、anonymizationFlags情報要素における境界匿名化ビット（ビット2）は、匿名アドレス情報要素は、「外部」及び「内部」を意味する「ソース」の意味と情報要素の「宛先」を変更するように設定することができる記述します周辺biflowsのように、だけ匿名化方針に関して。
Each IPFIX Message contains a Message Header; within this Message Header are contained two fields which may be used to break certain anonymization techniques: the Export Time, and the Observation Domain ID.
各IPFIXメッセージは、メッセージヘッダが含まれています。エクスポート時、および観測ドメインのID：このメッセージヘッダ内の2つの特定の匿名化技術を破るために使用することができるフィールドが含まれています。
Export of IPFIX Messages containing anonymized timestamp data where the original Export Time Message header has some relationship to the anonymized timestamps SHOULD anonymize the Export Time header field so that the Export Time is consistent with the anonymized timestamp data. Otherwise, relationships between export and flow time could be used to partially or totally reverse timestamp anonymization. When anonymizing timestamps and the Export Time header field SHOULD avoid times too far in the past or future; while [RFC5101] does not make any allowance for Export Time error detection, it is sensible that Collecting Processes may interpret Messages with seemingly nonsensical Export Times as erroneous. Specific limits are implementation dependent, but this issue may cause interoperability issues when anonymizing the Export Time header field.
IPFIXメッセージのエクスポートは、オリジナルのエクスポート時刻メッセージヘッダは、エクスポート時間が匿名タイムスタンプデータと一致するようにエクスポート時間ヘッダーフィールドを匿名SHOULD匿名タイムスタンプに何らかの関係を有するタイムスタンプデータを匿名含有します。それ以外の場合は、輸出とフロー時間との関係は、部分的または完全に逆転タイムスタンプの匿名化に使用することができます。匿名化すると、タイムスタンプとエクスポート時のヘッダフィールドは、過去や未来にすぎ回を避ける必要があります。 [RFC5101]はエクスポート時のエラー検出のための任意の手当をしない一方で、収集プロセスが誤ったとして、一見無意味なエクスポート・タイムズとのメッセージを解釈することが賢明です。具体的な制限は、実装に依存しているが、輸出時のヘッダフィールドを匿名化する場合、この問題は、相互運用性の問題が発生することがあります。
The similarity in size between an Observation Domain ID and an IPv4 address (32 bits) may lead to a temptation to use an IPv4 interface address on the Metering or Exporting Process as the Observation Domain ID. If this address bears some relation to the IP addresses in the flow data (e.g., shares a network prefix with internal addresses) and the IP addresses in the flow data are anonymized in a structure-preserving way, then the Observation Domain ID may be used to break the IP address anonymization. Use of an IPv4 interface address on the Metering or Exporting Process as the Observation Domain ID is NOT RECOMMENDED in this case.
観測ドメインID及びIPv4アドレス（32ビット）との間の大きさの類似性は、観測ドメインIDとして測光またはエクスポートプロセスにIPv4インタフェースアドレスを使用するように誘惑につながる可能性があります。このアドレスは、データが構造保存方法で匿名化されているフローのフローデータ内のIPアドレス（例えば、内部アドレスとネットワークプレフィックスを共有する）と、IPアドレスに何らかの関係を負担する場合には、観測ドメインIDを使用することができますIPアドレスの匿名化を破ります。観測ドメインIDとして測光またはエクスポートプロセスでIPv4インタフェースアドレスの使用は、この場合には推奨されません。
IPFIX uses the Options mechanism to export, among other things, metadata about exported flows and the flow collection infrastructure. As with the IPFIX Message Header, certain Options recommended in [RFC5101] and [RFC5655] containing flow timestamps and network addresses of Exporting and Collecting Processes may be used to break certain anonymization techniques. When using these Options along anonymized data export and storage, values within the Options that could be used to break the anonymization SHOULD themselves be anonymized or omitted.
IPFIXは、とりわけ、エクスポートされるフローとフロー収集インフラストラクチャーに関するメタデータをエクスポートするオプションメカニズムを使用しています。 [RFC5101]で推奨IPFIXメッセージヘッダーと同様に、特定のオプションと[RFC5655]プロセスのエクスポートおよび収集のフロータイムスタンプとネットワークアドレスを含む、特定の匿名化技術を破壊するために使用することができます。匿名データのエクスポートおよびストレージに沿ってこれらのオプションを使用する場合は、匿名を破るために使用することができオプション内の値自体は匿名化または省略する必要があります。
The Exporting Process Reliability Statistics Options Template, recommended in [RFC5101], contains an Exporting Process ID field, which may be an exportingProcessIPv4Address Information Element or an exportingProcessIPv6Address Information Element. If the Exporting
[RFC5101]で推奨エクスポートプロセス信頼性の統計オプションテンプレートは、exportingProcessIPv4Address情報要素またはexportingProcessIPv6Address情報要素であってもよいエクスポートプロセスIDフィールドを含んでいます。エクスポートする場合
Process address bears some relation to the IP addresses in the flow data (e.g., shares a network prefix with internal addresses) and the IP addresses in the flow data are anonymized in a structure-preserving way, then the Exporting Process address may be used to break the IP address anonymization. Exporting Processes exporting anonymized data in this situation SHOULD mitigate the risk of attack either by omitting Options described by the Exporting Process Reliability Statistics Options Template or by anonymizing the Exporting Process address using a similar technique to that used to anonymize the IP addresses in the exported data.
プロセスのアドレス（例えば、内部アドレスとネットワークプレフィックスを共有する）フローデータ内のIPアドレスに何らかの関係を負担し、フローデータにIPアドレスが構造保存方法で匿名化され、次いで、エクスポートプロセスアドレスに使用することができますIPアドレスの匿名化を破ります。このような状況での匿名データをエクスポートするエクスポートプロセスは、エクスポートプロセス信頼性の統計オプションテンプレートによって、またはエクスポートされたデータにIPアドレスを匿名化するために使用したのと同様の技術を使用してエクスポートプロセスのアドレスを匿名で記述オプションを省略することにより、どちらかの攻撃のリスクを軽減すべきです。
Similarly, the Export Session Details Options Template and Message Details Options Template specified for the IPFIX File Format [RFC5655] may contain the exportingProcessIPv4Address Information Element or the exportingProcessIPv6Address Information Element to identify an Exporting Process from which a flow record was received, and the collectingProcessIPv4Address Information Element or the collectingProcessIPv6Address Information Element to identify the Collecting Process which received it. If the Exporting Process or Collecting Process address bears some relation to the IP addresses in the dataset (e.g., shares a network prefix with internal addresses) and the IP addresses in the dataset are anonymized in a structure-preserving way, then the Exporting Process or Collecting Process address may be used to break the IP address anonymization. Since these Options Templates are primarily intended for storing IPFIX Transport Session data for auditing, replay, and testing purposes, it is NOT RECOMMENDED that storage of anonymized data include these Options Templates in order to mitigate the risk of attack.
同様に、エクスポートセッションの詳細オプションテンプレート及びメッセージの詳細オプションテンプレートは、IPFIXファイル形式[RFC5655] exportingProcessIPv4Address情報要素またはフローレコードを受信したエクスポートプロセスを識別するためexportingProcessIPv6Address情報要素、及びcollectingProcessIPv4Address情報を含むことができるために指定します要素又はcollectingProcessIPv6Address情報要素は、それを受信した収集プロセスを同定します。エクスポートプロセスまたはプロセスのアドレスを収集するには、データセット内のIPアドレスに何らかの関係を負担した場合（例えば、内部アドレスとネットワークプレフィックスを共有する）と、データセット内のIPアドレスは、構造保存方法で匿名化され、その後、エクスポートプロセスまたは収集プロセスのアドレスは、IPアドレスの匿名化を破るために使用することができます。これらのオプションのテンプレートは、主に監査、再生、およびテスト目的のためにIPFIX交通セッションデータを格納するために意図されているので、匿名データの保存が攻撃のリスクを軽減するために、これらのオプションのテンプレートが含まれていることをお勧めしません。
The Message Details Options Template specified for the IPFIX File Format [RFC5655] also contains the collectionTimeMilliseconds Information Element. As with the Export Time Message Header field, if the exported dataset contains anonymized timestamp information, and the collectionTimeMilliseconds Information Element in a given Message has some relationship to the anonymized timestamp information, then this relationship can be exploited to reverse the timestamp anonymization. Since this Options Template is primarily intended for storing IPFIX Transport Session data for auditing, replay, and testing purposes, it is NOT RECOMMENDED that storage of anonymized data include this Options Template in order to mitigate the risk of attack.
IPFIXファイル形式[RFC5655]に指定したメッセージの詳細オプションテンプレートもcollectionTimeMilliseconds情報要素が含まれています。エクスポートされたデータセットが与えられたメッセージにタイムスタンプ情報、およびcollectionTimeMilliseconds情報要素を匿名化が含まれている場合のエクスポート時間メッセージヘッダフィールドと同じように、匿名化されたタイムスタンプ情報に何らかの関係を持っている、そしてこの関係は、タイムスタンプの匿名化を逆転するために利用することができます。このオプションテンプレートは、主に監査、再生、およびテスト目的のためにIPFIX交通セッションデータを格納するためのものですので、匿名データの保存が攻撃のリスクを軽減するために、このオプションテンプレートを含めることはお勧めできません。
Since the Time Window Options Template specified for the IPFIX File Format [RFC5655] refers to the timestamps within the dataset to provide partial table of contents information for an IPFIX File, Options described by this Template SHOULD be written using the anonymized timestamps instead of the original ones.
時間ウィンドウオプションテンプレートは、IPFIXファイル形式[RFC5655]に指定されているのでIPFIXファイルのコンテンツ情報の部分的なテーブルを提供するデータセット内のタイムスタンプを参照して、このテンプレートによって記述されるオプションは、元の代わりに、匿名化タイムスタンプを使用して書かれるべきもの。
When anonymizing data for transport or storage using IPFIX containing anonymized IP addresses, and the analysis purpose permits doing so, it is RECOMMENDED to filter out or leave unanonymized data containing the special-use IPv4 addresses enumerated in [RFC5735] or the special-use IPv6 addresses enumerated in [RFC5156]. Data containing these addresses (e.g. 0.0.0.0 and 169.254.0.0/16 for link-local autoconfiguration in IPv4 space) are often associated with specific, well-known behavioral patterns. Detection of these patterns in anonymized data can lead to deanonymization of these special-use addresses, which increases the chance of a complete reversal of anonymization by an attacker, especially of prefix-preserving techniques.
匿名IPアドレス、及びそう分析目的許可を含むIPFIXを使用して輸送または保管のためにデータを匿名化するとき、[RFC5735]または特殊用途のIPv6に列挙特殊用途のIPv4アドレスを含むunanonymizedデータをフィルタリングまたはままに推奨されます[RFC5156]に列挙されたアドレス。これらのアドレス（IPv4の空間内のリンクローカル自動設定のための例えば0.0.0.0および169.254.0.0/16）を含むデータは、多くの場合、特定の、よく知られている行動パターンに関連付けられています。匿名データにおけるこれらのパターンの検出は、特にプレフィックス保存技術を、攻撃者が匿名の完全な逆転のチャンスを増加させ、これらの特殊用途のアドレスのdeanonymizationにつながることができます。
Special care should be taken when exporting or sharing anonymized data to avoid information leakage via the configuration or management planes of the IPFIX Device containing the Exporting Process or the File Writer. For example, adding noise to counters is useless if the receiver can deduce the values in the counters from Simple Network Management Protocol (SNMP) information, and concealing the network under test is similarly useless if such information is available in a configuration document. As the specifics of these concerns are largely implementation and deployment dependent, specific mitigation is out of scope for this document. The general ground rule is that information of similar type to that anonymized SHOULD NOT be made available to the receiver by any means, whether in the Data Records, in IPFIX protocol structures such as Message Headers, or out of band.
エクスポートまたはエクスポートプロセスやファイルのライターを含むIPFIXデバイスの構成や管理プレーンを介して情報漏洩を回避するために、匿名データを共有する場合には、特別な注意が必要です。例えば、受信機は、簡易ネットワーク管理プロトコル（SNMP）情報からカウンタの値を推定することができれば、カウンタにノイズを加えることは無駄であり、そのような情報は、構成ドキュメントに利用可能である場合、テスト中のネットワークを隠蔽することは、同様に無駄です。これらの懸念の仕様が大きく、実装と展開に依存しているとして、具体的な緩和策はこの文書の範囲外です。一般的なグランド・ルールは、匿名化と同様のタイプの情報は、データレコード内かどうか、そのようなメッセージのヘッダーとしてIPFIXプロトコル構造で、または帯域外、任意の手段によって受信機に利用可能にされるべきではないです。
In this example, consider the export or storage of an anonymized IPv4 dataset from a single network described by a simple Template containing a timestamp in seconds, a five-tuple, and packet and octet counters. The Template describing each record in this Data Set is shown in Figure 4.
この例では、秒、5タプル、及びパケット及びオクテットカウンタのタイムスタンプを含む単純なテンプレートによって記述単一のネットワークからの匿名のIPv4データセットのエクスポートまたは貯蔵を考えます。このデータセットの各レコードを記述するテンプレートが図4に示されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 2 | Length = 40 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 256 | Field Count = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| flowStartSeconds 150 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceIPv4Address 8 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationIPv4Address 12 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| sourceTransportPort 7 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| destinationTransportPort 11 | Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| packetDeltaCount 2 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| octetDeltaCount 1 | Field Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| protocolIdentifier 4 | Field Length = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Example Flow Template
図4：例フロー・テンプレート
Suppose that this Data Set is anonymized according to the following policy:
このデータセットは、以下の方針に従って、匿名化されているとします。
o IP addresses within the network are protected by reverse truncation.
Oネットワーク内のIPアドレスを逆切り捨てにより保護されています。
o IP addresses outside the network are protected by prefix-preserving anonymization.
Oネットワークの外部IPアドレスは、プレフィックス保存匿名で保護されています。
o Octet counts are exported using degraded precision in order to provide minimal protection against fingerprinting attacks.
Oオクテット数は指紋攻撃に対する最小限の保護を提供するために、劣化した精度を使用してエクスポートされます。
o All other fields are exported unanonymized.
O他のすべてのフィールドはunanonymizedエクスポートされます。
In order to export Anonymization Records for this Template and policy, first, the Anonymization Options Template shown in Figure 5 is exported. For this example, the optional privateEnterpriseNumber and informationElementIndex Information Elements are omitted, because they are not used.
このテンプレートとポリシーの匿名レコードをエクスポートするために、まず、図5に示す匿名化オプションテンプレートがエクスポートされます。彼らが使用されていないので、この例では、オプションのprivateEnterpriseNumberとinformationElementIndex情報要素は、省略されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 3 | Length = 26 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template ID = 257 | Field Count = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Field Count = 2 |0| templateID 145 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| informationElementId 303 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| anonymizationFlags 285 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |0| anonymizationTechnique 286 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example Anonymization Options Template
図5：例匿名化オプションテンプレート
Following the Anonymization Options Template comes a Data Set containing Anonymization Records. This dataset has an entry for each Information Element Specifier in Template 256 describing the flow records. This Data Set is shown in Figure 6. Note that sourceIPv4Address and destinationIPv4Address have the Perimeter Anonymization (0x0004) flag set in anonymizationFlags, meaning that source address should be treated as network-external, and the destination address as network-internal.
以下の匿名化オプションテンプレートは、匿名のレコードを含むデータセットを付属しています。このデータセットは、フローレコードを記述したテンプレート256の各情報要素指定子のためのエントリがあります。このデータセットはsourceIPv4AddressとdestinationIPv4Addressが境界匿名（0x0004は）フラグは送信元アドレスがネットワーク外部、およびネットワーク内部のような宛先アドレスとして扱われるべきであることを意味し、anonymizationFlagsに設定されていることを図6注記に示されています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Set ID = 257 | Length = 68 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | flowStartSeconds IE 150 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| no flags 0x0000 | Not Anonymized 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | sourceIPv4Address IE 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Perimeter, Session SC 0x0005 | Structured Permutation 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | destinationIPv4Address IE 12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Perimeter, Stable 0x0007 | Reverse Truncation 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | sourceTransportPort IE 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| no flags 0x0000 | Not Anonymized 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | dest.TransportPort IE 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| no flags 0x0000 | Not Anonymized 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | packetDeltaCount IE 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| no flags 0x0000 | Not Anonymized 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | octetDeltaCount IE 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stable 0x0003 | Precision Degradation 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Template 256 | protocolIdentifier IE 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| no flags 0x0000 | Not Anonymized 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Example Anonymization Records
図6：例匿名レコード
Following the Anonymization Records come the Data Sets containing the anonymized data, exported according to the Template in Figure 4. Bringing it all together, consider an IPFIX Message containing three real data records and the necessary templates to export them, shown in Figure 7. (Note that the scale of this message is 8-bytes per line, for compactness; lines of dots '. . . . . ' represent shifting of the example bit structure for clarity.)
匿名化のレコード、次のデータは、匿名データを含むすべて一緒にそれを持ち込み、図4にテンプレートに従ってエクスポートし、それらをエクスポートするために3枚の実データレコードと必要なテンプレートを含むIPFIXメッセージを考え、図7に示す（設定してきますドットのライン、明確にするために、例えばビット構造のシフト表す）「。。。。」;このメッセージのスケールは小型のため、ライン当たり8バイトであることに留意されたいです。
1 2 3 4 5 6
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000a | length 135 | export time 1271227717 | msg
| sequence 0 | domain 1 | hdr
| SetID 2 | length 40 | tid 256 | fields 8 | tmpl
| IE 150 | length 4 | IE 8 | length 4 | set
| IE 12 | length 4 | IE 7 | length 2 |
| IE 11 | length 2 | IE 2 | length 4 |
| IE 1 | length 4 | IE 4 | length 1 |
| SetID 256 | length 79 | time 1271227681 | data
| sip 192.0.2.3 | dip 198.51.100.7 | set
| sp 53 | dp 53 | packets 1 |
| bytes 74 | prt 17 | . . . . . . . . . . .
| time 1271227682 | sip 198.51.100.7 |
| dip 192.0.2.88 | sp 5091 | dp 80 |
| packets 60 | bytes 2896 |
| prt 6 | . . . . . . . . . . . . . . . . . . . . . . . . . . .
| time 1271227683 | sip 198.51.100.7 |
| dip 203.0.113.9 | sp 5092 | dp 80 |
| packets 44 | bytes 2037 |
| prt 6 |
+---------+
Figure 7: Example Real Message
図7：例リアルタイムメッセージ
The corresponding anonymized message is then shown in Figure 8. The Options Template Set describing Anonymization Records and the Anonymization Records themselves are added; IP addresses and byte counts are anonymized as declared.
対応する匿名化メッセージは、図8自体が追加される匿名レコードおよび匿名レコードを記述するオプションテンプレートセットに示されています。宣言されているIPアドレスおよびバイトカウントは匿名化されています。
1 2 3 4 5 6
0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x000a | length 233 | export time 1271227717 | msg
| sequence 0 | domain 1 | hdr
| SetID 2 | length 40 | tid 256 | fields 8 | tmpl
| IE 150 | length 4 | IE 8 | length 4 | set
| IE 12 | length 4 | IE 7 | length 2 |
| IE 11 | length 2 | IE 2 | length 4 |
| IE 1 | length 4 | IE 4 | length 1 |
| SetID 3 | length 30 | tid 257 | fields 4 | opt
| scope 2 | . . . . . . . . . . . . . . . . . . . . . . . . tmpl
| IE 145 | length 2 | IE 303 | length 2 | set
| IE 285 | length 2 | IE 286 | length 2 |
| SetID 257 | length 68 | . . . . . . . . . . . . . . . . anon
| tid 256 | IE 150 | flags 0 | tech 1 | recs
| tid 256 | IE 8 | flags 5 | tech 6 |
| tid 256 | IE 12 | flags 7 | tech 7 |
| tid 256 | IE 7 | flags 0 | tech 1 |
| tid 256 | IE 11 | flags 0 | tech 1 |
| tid 256 | IE 2 | flags 0 | tech 1 |
| tid 256 | IE 1 | flags 3 | tech 2 |
| tid 256 | IE41 | flags 0 | tech 1 |
| SetID 256 | length 79 | time 1271227681 | data
| sip 254.202.119.209 | dip 0.0.0.7 | set
| sp 53 | dp 53 | packets 1 |
| bytes 100 | prt 17 | . . . . . . . . . . .
| time 1271227682 | sip 0.0.0.7 |
| dip 254.202.119.6 | sp 5091 | dp 80 |
| packets 60 | bytes 2900 |
| prt 6 | . . . . . . . . . . . . . . . . . . . . . . . . . . .
| time 1271227683 | sip 0.0.0.7 |
| dip 2.19.199.176 | sp 5092 | dp 80 |
| packets 60 | bytes 2000 |
| prt 6 |
+---------+
Figure 8: Corresponding Anonymized Message
図8：対応する匿名化メッセージ
This document provides guidelines for exporting metadata about anonymized data in IPFIX, or storing metadata about anonymized data in IPFIX Files. It is not intended as a general statement on the applicability of specific flow data anonymization techniques. Exporters or publishers of anonymized data must take care that the applied anonymization technique is appropriate for the data source, the purpose, and the risk of deanonymization of a given application.
このドキュメントは、IPFIXに匿名データに関するメタデータをエクスポート、またはIPFIXファイルでの匿名データに関するメタデータを格納するためのガイドラインを提供します。これは、特定のフローデータの匿名化技術の適用性に関する一般的な文として意図されていません。匿名データの輸出業者や出版社が適用される匿名化技術は、データソース、目的、および特定のアプリケーションのdeanonymizationのリスクのために適切であることに注意しなければなりません。
Research in anonymization techniques, and techniques for deanonymization, is ongoing, and currently "safe" anonymization techniques may be rendered unsafe by future developments.
匿名化技術の研究、およびdeanonymizationのための技術は、現在進行中であり、現在は「安全」な匿名化技術は、将来の発展により、安全でないレンダリングすることができます。
We note specifically that anonymization is not a replacement for encryption for confidentiality. It is only appropriate for protecting identifying information in data to be used for purposes in which the protected data is irrelevant. Confidentiality in export is best served by using TLS [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347] as in the Security Considerations section of [RFC5101], and in long-term storage by implementation-specific protection applied as in the Security Considerations section of [RFC5655]. Indeed, confidentiality and anonymization are not mutually exclusive, as encryption for confidentiality may be applied to anonymized data export or storage, as well, when the anonymized data is not intended for public release.
私たちは、匿名の機密保持のための暗号化のための代替ではないことを、具体的に注意してください。これは、保護されたデータが無関係である目的のために使用されるデータに識別情報を保護するためにのみ適しています。輸出における機密性は最高のセキュリティのように適用される実装固有の保護により、長期保存に[RFC5101]のSecurity Considerations部のようにTLS [RFC5246]やデータグラムトランスポート層セキュリティ（DTLS）[RFC4347]を使用することによって提供されており、 [RFC5655]の問題部。匿名データを一般公開することを意図されていない場合に機密性のための暗号化は、同様に、匿名データのエクスポートやストレージに適用することができるよう実際に、機密性と匿名化は、相互に排他的ではありません。
We note as well that care should be taken even with well-anonymized data, and anonymized data should still be treated as privacy sensitive. Anonymization reduces the risk of misuse, but is not a complete solution to the problem of protecting end-user privacy in network flow trace analysis.
私たちは、ケアもよく匿名データで撮影する必要があることにも注意して、データがまだ敏感プライバシーとして扱われるべきである匿名化。匿名化は、誤用のリスクを低減しますが、ネットワークフローの微量分析にエンドユーザーのプライバシーを保護する問題の完全な解決策ではありません。
When using pseudonymization techniques that have a mutable mapping, there is an inherent trade-off in the stability of the map between long-term comparability and security of the dataset against deanonymization. In general, deanonymization attacks are more effective given more information, so the longer a given mapping is valid, the more information can be applied to deanonymization. The specific details of this are technique-dependent and therefore out of the scope of this document.
変更可能なマッピングを有する仮名化技術を使用する場合、deanonymizationに対するデータセットの長期的な比較とセキュリティとの間のマップの安定性に固有のトレードオフがあります。一般的には、deanonymization攻撃はより多くの情報を与え、より効果的であるので、与えられたマッピングが有効である長いが、より多くの情報がdeanonymizationに適用することができます。これの具体的な詳細は、技術に依存するため、この文書の範囲外です。
When releasing anonymized data, publishers need to ensure that data that could be used in deanonymization is not leaked through a side channel. The entire workflow (hardware, software, operational policies and procedures, etc.) for handling anonymized data must be evaluated for risk of data leakage. While most of these possible side channels are out of scope for this document, guidelines for reducing the risk of information leakage specific to the IPFIX export protocol are provided in Section 7.2.
匿名データを解放すると、出版社はサイドチャネルを介して漏れないdeanonymizationで使用することができ、そのデータを確認する必要があります。匿名データを処理するためのワークフロー全体（ハードウェア、ソフトウェア、運用ポリシーや手順など）は、データ漏洩のリスクを評価しなければなりません。これらの可能なサイドチャネルのほとんどは、このドキュメントの範囲外ですが、IPFIXのエクスポートプロトコルに固有の情報漏洩のリスクを低減するためのガイドラインは、セクション7.2で提供されています。
Note as well that the Security Considerations section of [RFC5101] applies as well to the export of anonymized data, and the Security Considerations section of [RFC5655] to the storage of anonymized data, or the publication of anonymized traces.
[RFC5101]のSecurity Considerations部は、匿名データの格納、または匿名トレースの出版物に匿名データのエクスポート、および[RFC5655]のSecurity Considerations部にも同様に適用されることにも注意してください。
This document specifies the creation of several new IPFIX Information Elements in the IPFIX Information Element registry available from the IANA site (http://www.iana.org), as defined in Section 6.2. IANA has assigned the following Information Element numbers for their respective Information Elements as specified below:
セクション6.2で定義されるようにこの文書は、IANAサイト（http://www.iana.org）から入手可能IPFIX情報エレメントのレジストリにいくつかの新しいIPFIX情報要素の作成を指定します。以下に指定としてIANAは、それぞれの情報要素は、以下の情報要素番号が割り当てられています：
o Information Element number 285 for the anonymizationFlags Information Element.
O情報要素anonymizationFlags情報要素のための数285。
o Information Element number 286 for the anonymizationTechnique Information Element.
O情報要素anonymizationTechnique情報要素のための数286。
o Information Element number 287 for the informationElementIndex Information Element.
O情報要素informationElementIndex情報要素のための数287。
We thank Paul Aitken and John McHugh for their comments and insight, and Carsten Schmoll, Benoit Claise, Lothar Braun, Dan Romascanu, Stewart Bryant, and Sean Turner for their reviews. Special thanks to the FP7 PRISM and DEMONS projects for their material support of this work.
私たちは、彼らのレビューのためにポール・エイトケンとジョン・マクヒュー彼らのコメントと洞察力のために、とカールステンSchmoll、ブノワClaise、ローター・ブラウン、ダンRomascanu、スチュワートブライアント、そしてショーン・ターナーに感謝します。この作品の彼らの物質的な支援のためのFP7 PRISMとDEMONSプロジェクトに感謝します。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B.、 "IPトラフィックフロー情報を交換するためのIPフロー情報のエクスポート（IPFIX）プロトコルの仕様"、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、 "IPフロー情報のエクスポートのための情報モデル"、RFC 5102、2008年1月。
[RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008.
[RFC5103]トラメル、B.およびE.ボスキ、 "IPフロー情報のエクスポートを使用した双方向フローのエクスポート（IPFIX）"、RFC 5103、2008年1月。
[RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, October 2009.
[RFC5655]トラメル、B.、ボスキ、E.、マーク、L.、Zseby、T.、およびA.ワグナー、 "IPフロー情報のエクスポート（IPFIX）ファイルフォーマットの仕様"、RFC 5655、2009年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156]ブランシェ、M.、 "特殊用途のIPv6アドレス"、RFC 5156、2008年4月。
[RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009.
[RFC5470] Sadasivan、G.、ブラウンリー、N.、Claise、B.、およびJ. Quittek、RFC 5470、2009年3月 "IPフロー情報のエクスポートのためのアーキテクチャ"。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、ボスキ、E.、ブラウンリー、N.、およびB. Claise、 "IPフロー情報のエクスポート（IPFIX）の適用"、RFC 5472、2009年3月。
[RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011.
[RFC6183]小林、A.、Claise、B.、Muenz、G.、及びK.石橋、 "IPフロー情報エクスポート（IPFIX）メディエーション：フレームワーク"、RFC 6183、2011年4月。
[IPFIX-PERSTREAM] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IPFIX Export per SCTP Stream", Work in Progress, May 2010.
[IPFIX-PERSTREAM] Claise、B.、エイトケン、P.、ジョンソン、A.、およびG. Muenz、 "SCTPストリームごとIPFIXエクスポート"、進歩、2010年5月ワーク。
[RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008.
[RFC5153]ボスキ、E.、マーク、L.、Quittek、J.、Stiemerling、M.、およびP.エイトケン、 "IPフロー情報のエクスポート（IPFIX）実装ガイドライン"、RFC 5153、2008年4月。
[RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004.
[RFC3917] Quittek、J.、Zseby、T.、Claise、B.、およびS.ザンダー、 "IPフロー情報エクスポート（IPFIX）のための要件"、RFC 3917、2004年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347]レスコラ、E.およびN. Modadugu、 "データグラムトランスポート層セキュリティ"、RFC 4347、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, "The Role of Network Trace Anonymization Under Attack", ACM Computer Communications Review, vol. 40, no. 1, pp. 6-11, January 2010.
【Bur10]バークハート、M.、Schatzmann、D.、トラメル、B.、およびE.ボスキ、 "攻撃を受けてネットワークトレース匿名の役割"、ACMコンピュータコミュニケーションレビュー、巻。 40、ありません。 1頁6-11、2010年1月。
[Mur07] Murdoch, S. and P. Zielinski, "Sampled Traffic Analysis by Internet-Exchange-Level Adversaries", Proceedings of the 7th Workshop on Privacy Enhancing Technologies, Ottawa, Canada, June 2007.
[Mur07]マードック、S.とP. Zielinskiは、プライバシー強化技術、オタワ、カナダ、2007年6月第7回ワークショップの議事録「インターネット取引所レベルの敵対者によるトラフィック分析をサンプリング」。
Authors' Addresses
著者のアドレス
Elisa Boschi Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
テクノロジーのエリサボスキスイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
EMail: boschie@tik.ee.ethz.ch
メールアドレス：boschie@tik.ee.ethz.ch
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
テクノロジーのブライアン・トラメル、スイス連邦工科大学チューリッヒGloriastrasse 35 8092チューリッヒスイス
Phone: +41 44 632 70 13 EMail: trammell@tik.ee.ethz.ch
電話：+41 44 632 70 13 Eメール：trammell@tik.ee.ethz.ch