[要約] RFC 6235は、IPフローの匿名化をサポートするためのガイドラインです。その目的は、ネットワークトラフィックのプライバシーを保護し、個人情報の漏洩を防ぐことです。
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
IPフローアノニマ化サポート
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.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6235.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction ....................................................4
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内の匿名化されたデータを表すメカニズムと、それを使用するためのガイドラインを提示します。特定のフローデータの適用性に関する一般的な声明として、特定の状況への匿名化手法、またはフローデータエクスポートへの匿名化の特定の適用の推奨事項として意図されていません。匿名化されたデータの輸出業者または出版社は、適用された匿名化手法が、特定のアプリケーションの二次化のリスクに適していることに注意する必要があります。
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フローデータの一般的に匿名化可能なフィールドへの各手法の適用性を説明します。該当する各匿名化手法で必要なパラメーターを列挙します。データ保護における現在のベストプラクティスに従って、これらの各手法を使用するためのガイドラインを提供します。最後に、匿名化されたデータをエクスポートし、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プロトコルでは、{type、length、value}タプルは{type、length}ペアを含むテンプレートで表現され、テンプレートに準拠したデータレコードに存在する{値}フィールドを指定し、データが送信されるデータの柔軟性を非常に提供します。。テンプレートはデータレコードと比較して非常にまれに送信されるため、これにより帯域幅の節約が大幅に節約されます。新しいデータ形式の{type、length}ペアを指定する新しいテンプレートを送信するだけで、さまざまな異なるデータ形式を送信できます。詳細については、[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.
「IPトラフィックフロー情報の交換用のIPフロー情報エクスポート（IPFIX）プロトコルの仕様[RFC5101]とその関連ドキュメントは、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.
さらに、「IPフロー情報エクスポート（IPFIX）ファイル形式の指定」[RFC5655]は、フローデータのストレージの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.
このドキュメントの意図は、匿名化されたデータの相互運用可能な交換、この分野での研究を促進するための共通の基礎を提供することです。匿名化技術自体と、ネットワーク測定への匿名化されたデータの適用の両方です。そのために、セクション3の分類とセクション6の匿名化エクスポートサポートを使用して、一般的なアプリケーションが生産データセットへの一般的なアプリケーションでは容認できないほど弱い技術を使用して、匿名化されたデータに関する情報を説明およびエクスポートすることができます。
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: 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.
IPFIXプロトコル[RFC5101]ドキュメントの用語セクションで定義されているこのドキュメントで使用される用語は、そこで定義されていると解釈されます。さらに、このドキュメントは次の用語を定義します。匿名化レコード：セクション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.
匿名化されたデータレコード：匿名値を持つ少なくとも1つの情報要素を含むデータセット内のデータレコード。このデータレコードを説明するテンプレートまたはオプションテンプレート内の情報要素には、対応する匿名化レコードが必要です。
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.
匿名化は、2つのプロパティに従って広く分類される場合があります。回復可能性とカスタマイティブルです。すべての匿名化手法では、識別子または値の実際の空間を、何らかの機能に従って別の匿名の空間にマッピングします。手法は、使用されている関数が反転可能であるか、そうでなければ逆になり、特定の交換用識別子から実際の識別子を回収できる場合に回復可能であると言われています。この分類で使用される「回復可能性」は、攻撃下での回復可能性を指しません。つまり、使用される関数は、暗号化キーやデータセット内の注入されたトラフィックの知識などの追加情報を使用してのみ逆転させることができる技術は、回復可能であるとは見なされません。
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.
カスタビリティは、匿名化された空間（n）の次元を実際の空間（m）の次元（m）と比較し、一意の値のカウントが匿名化関数によってどのように保持されるかを示します。匿名化されたスペースが実際の空間よりも小さい場合、関数は入力を一般化すると言われ、各匿名値に複数の入力ポイントをマッピングします（たとえば、集約など）。定義上、一般化は回復できません。
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フローデータの匿名化では、目標は一般に双方向のアドレスの不安定性です。エンドポイントXが時間Tで接触したエンドポイントYに接触することを主張する能力を削除することです。現実世界のエンティティを識別する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アドレスと同様に、Media Access Control（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.
Black-Markerの匿名化は、削除されたフィールドのデータを開示のリスクから完全に保護しますが、匿名化されたデータセット全体の有用性も低下させます。開示リスクを削減しながら（排除していないが）、いくつかの情報を保持する手法については、以下のセクションで広く議論されます。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ビットの切り捨てはA /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）の秘密キー。ハッシュ関数が既知である場合、パラメーターはブルートフォースによって逆転することができ、順列関数として使用すべきではありません。順列関数は、非衝突を保証する場合があります（つまり、各匿名のアドレスは一意の元のアドレスを表していることを表しますが、必要ではありません。ただし、衝突の確率は低いはずです。それでも、順列でさえ低いがゼロの衝突確率で直接的な置換として扱います。これらのガイドラインを超えて、特定の順列関数の推奨事項はこのドキュメントの範囲外です。
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アドレスを匿名化しながら各レベルでサブネットの構造が保存されるようにさらに制限されています。2つの実際の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.
インターネットのバックグラウンドトラフィックでスキャンすると、この手法で特定の問題を引き起こす可能性があります。スキャナーが予測可能で既知のアドレスシーケンスを使用する場合、この情報を使用して代替を逆転させることができます。アドレスの低次部分は、この攻撃に対する部分的な防御として匿名化されないままにすることができます。
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アドレスは、Link-Localアドレス指定の場合、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のビットを保持します。EAP-48または40ビットの24ビットのEAP-64アドレスの切り捨ては、OUIを保持しながらデバイス識別子のゼロをゼロにします。
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ミリ秒）を占めます。これは、多くのタイムスタンプを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).
列挙は、時間情報を排除しながらイベントが発生した時系列を保持する代替機能です。タイムスタンプは、ランダムに選択された開始値から始まる等距離のタイムスタンプ（または数字）に置き換えられます。結果のデータは、厳格なシーケンスを必要とするアプリケーションに役立ちますが、適切なタイミング情報（Quality-of-Service（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つは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.
Binningは、潜在的に不均一な範囲のセットを任意にラベル付けされたビンのセットにマッピングする一般化手法です。一般的なビンの配置は、フィールドタイプと分析アプリケーションに依存します。たとえば、IPプロトコルBINの配置は、ICMP、UDP、およびTCPトラフィックの1、6、および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.
順列は、各匿名化された値が一意の元の値を表すことを保証するのが理想的ですが、そのようなことは中間匿名化プロセスで重要な状態を必要とする場合があります。したがって、パフォーマンスの理由でハッシュすることにより、順列が実装される場合があり、比較的小さな衝突確率を持つ可能性のあるハッシュ関数があります。このような手法は、ゼロ以外の誤差確率にもかかわらず、依然として本質的に直接的な代替手法です。
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.
安定した匿名化は、実際のスペースの特定の値を匿名化された空間の特定の値に常にマッピングしますが、不安定な匿名化はこのマッピングを時間とともに変更します。完全に不安定な匿名化は、Black-Markerの匿名化と本質的に区別できません。与えられた匿名化手法は、さまざまな範囲の安定性で適用される場合があります。安定性は、異なるデータセット、または異なる期間にわたって同じデータセットで匿名化された情報の比較可能性を評価するために重要です。実際には、特定のプロデューサーが特定の消費者に公開したすべてのデータセットで匿名化が安定している場合も、データセット内またはデータセット全体で記載された期間安定したり、単一のデータセットでのみ安定したりする場合があります。
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.
ビンマッピング関数のビンマップは本質的にビンマッピングキーであるため、一般化の程度に応じて、ビンマッピング機能に関する情報をエクスポートすべきではありません。
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.
シフトには、各値をシフトする量が必要です。シフト量はシフト関数の唯一の鍵であり、シフトによって保護されたデータを簡単に拒否するために使用できるため、シフト量に関する情報をエクスポートしてはなりません。
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 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.
IPFIXを介してエクスポートされる匿名化されたデータは、匿名化メタデータを注釈する必要があります。これは、テンプレートが匿名化されたフィールドを詳述し、使用される匿名化手法に関する適切な情報を提供します。このメタデータは、このセクションで説明されている推奨オプションテンプレートで説明されているデータレコードにエクスポートする必要があります。これらのオプションテンプレートは、次のサブセクションで説明されている追加情報要素を使用します。
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.
Black-Marker（削除）手法を使用して匿名化されたフィールドには、特別なメタデータサポートは必要ありません。データセットを説明するテンプレートから対応する情報要素を省略して、ブラックマーカーの匿名フィールドをまったくエクスポートしないでください。アプリケーションの要件がブラックマーカーの匿名フィールドがテンプレートに残る必要があると指示する場合、エクスポートプロセスは、ネイティブの長さでブラックマーカーの匿名フィールドを全ゼロとしてエクスポートすることがありますが、十分なコンテキスト情報が存在する場合にのみ、この方法で実際のゼロ値からエクスポートされたブラックマーカーの匿名化されたフィールドを区別するレコード。
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 STREAMごとのエクスポート[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が参照する情報要素のゼロベースのインデックス。複数の同一の情報要素を含むテンプレートの範囲を明確にするために使用されます。
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）の場合、通常のポリシー（匿名化テクニックで説明されている）は、変更なしで適用されます。
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.
匿名化は、図1に示すように、コレクションインフラストラクチャ内の3つの段階でIPFIXデータに適用できます：初期エクスポート、調停者、またはコレクション後の録音時。これらの各場所には、特定の考慮事項と適用性があります。
+==========================================+
| 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）によって行われます。このIAPに出入りするデータは、以下の図2に示されています。
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 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]).
IAPを介して各データが流れた後、図3のこのフレームワーク内の5つの基本的なタイプの匿名化の取り決めについて説明します。上記の3つの取り決めに加えて、匿名化は、コロケートされた計量プロセス（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
図3：IPFIXアーキテクチャでの匿名化の可能性のある取り決め
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レベルの精度に分解されたタイムスタンプは、フロースタートアートマリ秒とフローエンドミリ秒ではなく、フロースタートセカンドとフローエンドセカンドを使用する必要があります。
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の匿名化テクニック情報要素の説明に記載されています。この説明では、タイムスタンプは、データ型DateTimeSeconds、Datatimemilliseconds、DateTimemicRoseconds、またはDatetimenananosocondsの情報要素です。アドレスは、データ型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のように、匿名化周辺の双方向フロー（BIFLOW）データをエクスポートする場合、この配置は、ソースエンドポイント情報の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.
ただし、単方向の流れ（UNIFLOW）または非透過計のビフローデータを使用した境界ベースの匿名化ポリシーを表すことも有用です。この場合、匿名化されたアドレス情報要素を説明する匿名化フラグ情報要素の匿名化匿名化ビット（ビット2）は、情報要素の「ソース」と「宛先」の意味を「外部」と「内部」を意味する「宛先」の意味を変更するように設定できます。ペリメーターの二胞体と同様に、匿名化ポリシーに関してのみ。
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メッセージには、メッセージヘッダーが含まれています。このメッセージ内には、特定の匿名化手法の破損に使用できる2つのフィールドが含まれています。エクスポート時間と観測ドメインIDです。
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メッセージのエクスポート元のエクスポート時間メッセージヘッダーが匿名化されたタイムスタンプと何らかの関係がある場合、エクスポート時間ヘッダーフィールドを匿名化して、エクスポート時間が匿名化されたタイムスタンプデータと一致するようにします。それ以外の場合、エクスポートとフロー時間の関係を使用して、タイムスタンプの匿名化を部分的または完全に逆転させることができます。タイムスタンプを匿名化する場合、エクスポートタイムヘッダーフィールドは、過去または未来の時間が遠すぎることを避ける必要があります。[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は、オプションメカニズムを使用して、とりわけエクスポートされたフローとフローコレクションインフラストラクチャに関するメタデータをエクスポートします。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 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.
[RFC5101]で推奨されるエクスポートプロセス信頼性統計オプションテンプレートには、エクスポートプロセスIDフィールドが含まれています。エクスポートプロセスアドレスがフローデータの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]に指定されたエクスポートセッションの詳細オプションテンプレートおよびメッセージ詳細オプションテンプレートには、エクスポートProcessIPv4Address情報要素またはエクスポートProcessIPv6Address情報要素が含まれる場合があります。要素または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情報要素も含まれています。エクスポートタイムメッセージヘッダーフィールドと同様に、エクスポートされたデータセットに匿名化されたタイムスタンプ情報が含まれている場合、特定のメッセージのコレクションTimeMilliseconds情報要素には匿名化されたタイムスタンプ情報と何らかの関係があり、この関係を悪用してタイムスタンプの匿名化を逆転させることができます。このオプションテンプレートは、主に監査、リプレイ、およびテスト目的のための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を使用してトランスポートまたはストレージのデータを匿名化する場合、および分析の目的により、そうすることができます。[RFC5156]に列挙されているアドレス。これらのアドレスを含むデータ（例：IPv4空間におけるLink-Local Autoconfigurationの0.0.0.0および169.254.0.0/16）は、特定のよく知られた行動パターンに関連していることがよくあります。匿名化されたデータでこれらのパターンを検出すると、これらの特別な使用アドレスの年間化につながる可能性があり、攻撃者による匿名化の完全な逆転、特にプレフィックス予約技術の完全な逆転の可能性が高まります。
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 他のすべてのフィールドは匿名化されていません。
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の各情報要素仕様のエントリがあります。このデータセットを図6に示します。SourityIPv4AddressとdestinationIPv4Addressには、匿名の匿名化（0x0004）フラグが匿名化されたフラグに設定されていることに注意してください。つまり、ソースアドレスはネットワーク外部として、宛先アドレスをネットワーク内部として扱う必要があります。
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.)
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ファイルの匿名データに関するメタデータを保存するためのガイドラインを提供します。特定のフローデータの匿名化手法の適用性に関する一般的な声明として意図されていません。匿名化されたデータの輸出業者または出版社は、適用された匿名化手法が、特定のアプリケーションの二次化のリスクに適していることに注意する必要があります。
Research in anonymization techniques, and techniques for deanonymization, is ongoing, and currently "safe" anonymization techniques may be rendered unsafe by future developments.
匿名化技術の研究、および長期化のための技術は継続的であり、現在「安全な」匿名化手法は、将来の開発によって安全ではないようになる可能性があります。
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]のセキュリティに関する考慮事項セクションのように、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.
可変マッピングを備えた仮名化手法を使用する場合、長期的な比較可能性とディアノニマ化に対するデータセットのセキュリティとの間のマップの安定性に固有のトレードオフがあります。一般に、より多くの情報を考えると、ディアノニマ化攻撃はより効果的であるため、特定のマッピングが有効になるほど、より多くの情報をディアノニマイズに適用できます。この詳細は、手法に依存するため、このドキュメントの範囲外です。
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.
匿名化されたデータをリリースする場合、出版社は、ディアノニマ化で使用できるデータがサイドチャネルを介して漏れないことを確認する必要があります。匿名化されたデータを処理するためのワークフロー全体（ハードウェア、ソフトウェア、運用ポリシー、手順など）は、データリークのリスクについて評価する必要があります。これらの可能なサイドチャネルのほとんどはこのドキュメントの範囲外ではありませんが、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]のセキュリティに関する考慮事項セクションは、匿名化されたデータのエクスポート、および[RFC5655]のセキュリティに関する考慮事項セクションに匿名化されたデータの保存、または匿名化されたトレースの公開にも適用されることに注意してください。
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 匿名化フラグ情報要素の情報要素番号285。
o Information Element number 286 for the anonymizationTechnique Information Element.
o 匿名化技術情報要素の情報要素番号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.
ポール・エイトケンとジョン・マクヒューのコメントと洞察に感謝し、カルステン・シュモル、ブノワ・クレイズ、ロサール・ブラウン、ダン・ロマスカヌ、スチュワート・ブライアント、ショーン・ターナーのレビューに感謝します。この作品を物質的にサポートしてくれたFP7 Prism and 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.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「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] Trammell、B。およびE. Boschi、「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] Trammell、B.、Boschi、E.、Mark、L.、Zseby、T。、およびA. Wagner、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735] Cotton、M。およびL. Vegoda、「Special Use IPv4アドレス」、BCP 153、RFC 5735、2010年1月。
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008.
[RFC5156] Blanchet、M。、「Special-Use 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.、Brownlee、N.、Claise、B。、およびJ. Quittek、「IPフロー情報エクスポートのアーキテクチャ」、RFC 5470、2009年3月。
[RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009.
[RFC5472] Zseby、T.、Boschi、E.、Brownlee、N。、およびB. Claise、「IP Flow Information Export（IPFIX）Applicability」、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. Ishibashi、「IP Flow Information Export（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.、Aitken、P.、Johnson、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] Boschi、E.、Mark、L.、Quittek、J.、Stiemerling、M。、およびP. Aitken、「IP Flow Information Export（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. Zander、「IP Flow Information Export（IPFIX）の要件」、RFC 3917、2004年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
[RFC4347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security」、RFC 4347、2006年4月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Burkhart、M.、Schatzmann、D.、Trammell、B。、およびE. Boschi、「攻撃下でのネットワークトレース匿名化の役割」、ACM Computer Communications Review、Vol。40、いいえ。1、pp。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] Murdoch、S。およびP. Zielinski、「インターネット交換レベルの敵によるトラフィック分析のサンプリング」、2007年6月、カナダ、オタワのプライバシー強化技術に関する第7回ワークショップの議事録。
Authors' Addresses
著者のアドレス
Elisa Boschi Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
Elisa Boschi Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092チューリッヒスイス
EMail: boschie@tik.ee.ethz.ch
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
ブライアン・トラメル・スイス連邦技術研究所チューリッヒ・グロリア・ストラス35 8092チューリッヒ・スイス
Phone: +41 44 632 70 13
EMail: trammell@tik.ee.ethz.ch