RFC 6235
IP Flow Anonymization Support
RFC 6235: IP Flow Anonymization Support 🦋
okay bestie, this one is RFC 6235, titled "IP Flow Anonymization Support" 🎀. It was written by E. Boschi and B. Trammell, both from ETH Zurich 🇨🇭. It came out in May 2011 and is categorized as Experimental 🧪, so it's a "try it and see" doc, not a full Internet Standard. Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing alone 💅.
Abstract ✨
this doc is all about how to anonymize IP flow data 🫶 and how to export that anonymized data using the IP Flow Information Export (IPFIX) protocol. it sorts the common anonymization techniques into categories and defines the parameters you need to describe each one 📋. it also gives implementation guidelines for exporting and storing anonymized data over IPFIX, and it describes an information model plus an Options-based method for exporting anonymization metadata inside the IPFIX protocol or storing it in IPFIX Files 💜.
Status of This Memo 📜
this document is not an Internet Standards Track specification 🙅♀️. it's published so people can examine it, try it out in experimental implementations, and evaluate it 🔍.
it defines an Experimental Protocol for the Internet community 🧪. it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🤝. it went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full story 🧐.
info about the current status of this doc, any errata, and how to send feedback lives at 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. 🌈
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 📑. please read these carefully, because they spell out your rights and restrictions for this document 👀. any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⚖️.
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 ...................................421. Introduction 🌸
The standardization of an IP Flow Information Export (IPFIX) protocol [RFC5101] and its associated representations removes a technical barrier to sharing IP flow data across organizational boundaries 🌐. it also makes sharing easier with network operations, security, and research communities, for all kinds of purposes 📊. but here's the catch: wider dissemination means greater risks to the privacy of the users of the networks being measured, and to the security of those networks 😬. it's not a complete solution to the problems that come with distributing IP flow information, but anonymization is an important tool for protecting privacy inside network measurement infrastructures 🛡️. anonymization here means deleting or transforming information that's considered sensitive and that could be used to reveal the identity of the subjects involved in a communication 🫥.
this document presents a mechanism for representing anonymized data within IPFIX, plus guidelines for using it 🎀. it is not meant as a general statement about when specific flow data anonymization techniques fit specific situations, and it's not a recommendation for any particular way of applying anonymization to flow data export 🙅♀️. exporters or publishers of anonymized data must take care that the technique they apply is appropriate for their data source, their purpose, and the risk of deanonymization for their application 🧐.
the big warning: picking an anonymization technique is not a one-size-fits-all thing. the technique has to match the data source, the purpose, and the deanonymization risk, or the whole thing can backfire 💀.
the doc starts with a categorization of anonymization techniques 🗂️. then it covers how each technique applies to commonly anonymizable fields of IP flow data, organized by information element data type and semantics as in [RFC5102] 🔍. it also lists the parameters each applicable technique needs, and gives guidelines for using each one in line with current best practices in data protection 🔐. last but not least, it specifies how to export anonymized data and bind anonymization metadata to Templates and Options Templates using IPFIX Options 💅.
1.1. IPFIX Protocol Overview 🧚
in the IPFIX protocol, { type, length, value } tuples are expressed in Templates containing { type, length } pairs. those pairs specify which { value } fields are present in data records that follow the Template 🍓. this gives you tons of flexibility over what data gets sent 🙌. Templates are sent way less often than Data Records, so this means real bandwidth savings 💰. you can send different data formats just by sending new Templates that specify the { type, length } pairs for the new format ✨. see [RFC5101] for more info 📚.
the IPFIX information model [RFC5102] defines a huge number of standard Information Elements (IEs) that supply the { type } info Templates need 🧩. using standard elements is what makes implementations from different vendors interoperate 🤝. non-standard, enterprise-specific elements can also be defined for private use 🔒.
1.2. IPFIX Documents Overview 📚
"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 🌊. it gives network engineers and administrators access to IP traffic flow information 👩💻.
"Architecture for IP Flow Information Export" [RFC5470] defines the architecture for exporting measured IP flow information from an IPFIX Exporting Process to an IPFIX Collecting Process 🏗️. it also covers the basic terminology used to describe the elements of that architecture, following the requirements in "Requirements for IP Flow Information Export" [RFC3917] 📝. then the IPFIX Protocol document [RFC5101] gets into the details of transporting IPFIX Data Records and Templates from an IPFIX Exporting Process to an IPFIX Collecting Process, using a congestion-aware transport protocol 🚚.
"Information Model for IP Flow Information Export" [RFC5102] describes the Information Elements used by IPFIX, including details on how they're named, numbered, and how their data types are encoded 🔢. and "IP Flow Information Export (IPFIX) Applicability" [RFC5472] covers the different applications of IPFIX, how they use the exported information, and how the IPFIX architecture relates to other measurement architectures and frameworks 🗺️.
also, "Specification of the IP Flow Information Export (IPFIX) File Format" [RFC5655] describes an IPFIX-based file format for storing flow data 💾.
this document leans on the Protocol and Architecture documents for terminology 🤓. it also extends the IPFIX Information Model with new Information Elements for anonymization metadata 💜. the anonymization techniques described here apply equally to the IPFIX protocol and to data stored in IPFIX Files 🫶.
that's part 1 done, bestie 🌈💖
1.3. Anonymization within the IPFIX Architecture ✨
okay so according to [RFC5470], IPFIX Message anonymization is optional 🫶 and it's applied as the very last step before the Message gets handed off to the transport protocol for export. the architecture doesn't have a spot for anonymization metadata (that's Section 6 bestie), but this setup still lets you do the rewriting you need for full, comprehensive anonymization of IPFIX export, which is Section 7 🦋. then two other specs came along and added more places where anonymization can happen. the IPFIX Mediation [RFC6183] framework brings in IPFIX Mediators, which rewrite IPFIX Messages that already exist, and the IPFIX File Format [RFC5655] gives a way to store IPFIX data in files 💅. so it's giving expanded anonymization options, iykyk.
if you want more detail on the architectural stuff for anonymization, check out Section 7.1 💖
1.4. Supporting Experimentation with Anonymization 🧪
the status of this document is Experimental, and that's on purpose because anonymization export support is still experimental, lowkey so 🌸. research on network trace anonymization techniques, and on attacks against them, is still going strong. and honestly there's growing evidence that anonymizing network trace or flow data by itself just isn't enough for a lot of data protection jobs, as shown in [Bur10] 💀. so this document explicitly does not recommend any particular technique or implementation of one 🙈.
the whole point is to give everyone a shared base for interoperable exchange of anonymized data, which helps research move forward, both on the anonymization techniques themselves and on using anonymized data for network measurement 🍓. that's why the classification in Section 3 and the anonymization export support in Section 6 can be used to describe and export info even about data anonymized with techniques that are way too weak for general production datasets on their own 😭.
the spec is designed to be independent of the anonymization techniques used and how they're implemented, but since open research is still going, this may need future updates 🌈. if the spec gets successfully applied to anonymized data publishing and exchange in the future, it may be brought back to the IPFIX working group for further development and publication on the Standards Track 👑.
2. Terminology 📚
so terms that are defined in the Terminology section of the IPFIX Protocol [RFC5101] document are to be interpreted as defined there 💜. this document also defines these terms, bestie:
- 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 ✨.
- Anonymized Data Record: a Data Record within a Data Set containing at least one Information Element with anonymized values. the Information Element(s) within the Template or Options Template describing this Data Record SHOULD have a corresponding Anonymization Record 🎀.
- Intermediate Anonymization Process: an intermediate process that takes Data Records and transforms them into Anonymized Data Records 🦋.
note that there's an explicit difference in this document between a "Data Set" (defined as in [RFC5101]) and a "data set". when it's lowercase, "data set" refers to any collection of data (usually, in this document, flow or packet data) that may contain identifying info and is therefore subject to anonymization 🫶.
also, when this document says Template, unless noted otherwise, it applies to both Templates and Options Templates as defined in [RFC5101]. so Anonymization Records may apply to both 💅.
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] 🔥.
3. Categorization of Anonymization Techniques 🧩
okay so anonymization, as this document describes it, is changing a dataset so that the identity of the people or entities it describes can't be disclosed 🌸. for network traffic data, anonymization usually tries to keep certain properties of the traffic that are useful for whatever the application is, while making sure the data can't be traced back to the specific networks, hosts, or users that generated it 💖.
anonymization can be broadly classified by two properties: recoverability and countability 🦋. all anonymization techniques map the real space of identifiers or values into a separate anonymized space using some function 🍓. a technique is called recoverable when the function is invertible, or can otherwise be reversed so a real identifier can be recovered from its replacement 💅. "Recoverability" in this categorization does NOT mean recoverability under attack 🙈. so techniques where the function can only be reversed with extra info, like an encryption key or knowledge of injected traffic in the dataset, are not considered recoverable 🔐.
countability compares the dimension of the anonymized space (N) to the dimension of the real space (M), and shows how the count of unique values is preserved by the anonymization function ✨. if the anonymized space is smaller than the real space, the function is said to generalize the input, mapping more than one input point to each anonymous value (like with aggregation, for example) 🌈. by definition, generalization is not recoverable 😭.
if the dimensions of the anonymized and real spaces are the same, so the count of unique values is preserved, the function is a direct substitution function 👑. if the anonymized dimension is larger, so each real value maps to a set of anonymized values, the function is a set substitution function 🎀. with set substitution functions, the sets of anonymized values are not necessarily disjoint, which is wild 🤯. either direct or set substitution functions are called one-way if there's no non-brute-force method for recovering the real data point from an anonymized one in isolation. (basically, the only way to recover it is to attack the anonymized data set as a whole, like 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 |
+------------------------+-----------------+------------------------+4. Anonymization of IP Flow Data ✨
okay so this is where it gets fun, bestie 💖 When we anonymize IP flow data (the stuff this doc is about), the goal is basically two-way address untraceability 🕵️♀️. That means nobody can claim that endpoint X contacted endpoint Y at time T. No receipts, no proof 💅. IP addresses are the big one because they're the most useful field in a flow record for figuring out who's who 😭. Each IP address is tied to an interface on a network host and can potentially be pinned to one single user. Plus, IP addresses are structured, so a partial prefix can point at a whole network the same way a full address points at one host 🧚. So IP flow anonymization is mainly about IP address anonymization, periodt.
Any form of aggregation that combines flows from multiple endpoints into one record (like aggregating by subnetwork, or removing addressing completely) may also give you address untraceability 🌸. But aggregation is out of scope for this doc, sorry not sorry. Also out of scope are techniques applied across multiple fields or multiple records that create dependencies between anonymized fields or records. This doc is only about techniques applied to single fields within one flow record 🎀.
BUT ngl, attacks on these techniques use whole flows and the relationships between hosts and flows in a dataset 👀. So fields that aren't identifying on their own might still get anonymized to boost the anonymity of the whole dataset. It's giving teamwork 🫶.
Because flow data has pretty restricted semantics, there aren't that many specific techniques. Each one still fits into the broad categories from the last section, though. Each type of field that often shows up in a flow record can have its own specific techniques 🦋.
Next up: MAC addresses. They're kind of like IP addresses in that they uniquely identify devices. They're not usually in Layer 3 traffic data and can't be used to locate devices within the network, but some traces contain sub-IP data that includes MAC addresses 🤓. Hardware addresses can be mapped to device serial numbers, and to whoever bought the devices, when you combine them with external databases. MAC addresses are also often used to build IPv6 addresses (see Section 2.5.1 of [RFC4291]), so in certain circumstances they can help reconstruct the low-order bits of anonymized IPv6 addresses. So yeah, MAC address anonymization matters too 💜.
Ports identify abstract entities (applications) instead of real-world ones, but they can still classify hosts and user behavior 🎮. Passive port fingerprinting, of both well-known and ephemeral ports, can reveal the operating system running on a host. Relative data volumes by port can hint at a host's job (workstation, web server, etc.), and that info can identify hosts and users 👑.
Timestamps and counters aren't identifiers in and of themselves, but they reveal how hosts and users behave 🕰️. Any network activity has a recognizable pattern of relative time differences and data volumes across its flows, even without host address information. So they can identify hosts and users too. They're also vulnerable to traffic injection attacks, where traffic with a known pattern gets injected into the network under measurement and then spotted in the anonymized dataset. Yikes 💀.
The simplest and most extreme form of anonymization is black-marker anonymization, which can be applied to any field: complete deletion. Note that black-marker anonymization is equivalent to simply not exporting the field(s) in question 🖤.
Black-marker anonymization completely protects the data in deleted fields from disclosure, but it also tanks the utility of the anonymized dataset as a whole 😤. Techniques that keep some information while reducing (though not eliminating) disclosure risk get extensively discussed in the following sections. The techniques for IP addresses, timestamps, ports, and counters each get their own separate section 🌈.
4.1. IP Address Anonymization
IP addresses are the most common identifiers in flow data that can be used to directly identify a person, organization, or host, so most of the work on flow and trace anonymization has gone into IP address techniques 💅. Honestly, the aim of most attacks is to recover the map from anonymized IP addresses back to the original ones, and thereby identify the hosts. So there's a wide range of IP address anonymization schemes that fit into the following categories:
+------------------------------------+---------------------+
| Scheme | Action |
+------------------------------------+---------------------+
| Truncation | Generalization |
| Reverse Truncation | Generalization |
| Permutation | Direct Substitution |
| Prefix-preserving Pseudonymization | Direct Substitution |
+------------------------------------+---------------------+4.1.1. Truncation
Truncation removes "n" of the least significant bits from an IP address and replaces them with zeroes 🧸. In effect, it swaps a host address for 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. It's super effective for making hosts non-identifiable, but it still preserves info that can identify an organization, a geographic region, a country, or a continent 🌍.
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 📊.
4.1.2. Reverse Truncation
Reverse truncation removes "n" of the most significant bits from an IP address and replaces them with zeroes 🙃. It's a non-reversible generalization scheme. It's effective for making networks unidentifiable, partially or completely removing info that can 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're the same host. It's not particularly useful when publishing data where the network of origin is known, or can be easily guessed, from the identity of the publisher.
Like truncation, reverse truncation to an address length of 0 is equivalent to black-marker anonymization.
4.1.3. Permutation
Permutation is a direct substitution technique 🔀. It replaces each IP address with an address selected from the set of possible IP addresses, so that each anonymized address represents a unique original address. The selection function is often random, though it doesn't have to be. Permutation doesn't preserve any structural info about a network, but it does preserve the unique count of IP addresses. Any application that needs more structure than host-uniqueness won't be able to use permuted IP addresses 😭.
There are lots of variations of permutation functions, and each one has trade-offs in performance, security, and guarantees of non-collision. Evaluating those trade-offs is implementation independent. In general, though, 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, so they 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 they don't need to; 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 🎀.
4.1.4. Prefix-Preserving Pseudonymization
Prefix-preserving pseudonymization is a direct substitution technique, like permutation but further restricted, so that the structure of subnets is preserved at each level while IP addresses get anonymized 🌳. 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 it introduces structure into the anonymized data that can be exploited in attacks against the technique 👀.
Scanning in Internet background traffic can cause particular problems with this technique. If a scanner uses a predictable and known sequence of addresses, that info 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 🛡️.
4.2. MAC Address Anonymization 🎀
Okay bestie, flow data with sub-IP info can also carry identifying stuff in the form of the hardware (MAC) address. ✨ A MAC address can't tell you where a node sits on the network, but it can directly and uniquely identify one specific device 🔥. Vendors or organizations in the supply chain might then have what they need to figure out who bought it 👀.
MAC address info is not as structured as IP address info 💅. EUI-48 and EUI-64 MAC addresses hold an Organizational Unique Identifier (OUI) in their three most significant bytes, and that OUI also has bits saying whether the address is locally or globally administered. Beyond that, there's no standard relationship among the OUIs a given vendor gets, so it's kinda chaotic 💀.
Also, MAC address info shows up inside IPv6 addresses too 🌈. The EAP-64 address, or an EAP-48 address encoded as an EAP-64 address, becomes the least significant 64 bits of an IPv6 address for link-local addressing or stateless autoconfiguration. So the considerations and techniques in this section may apply to those IPv6 addresses as well 🧚.
+-----------------------------+---------------------+
| Scheme | Action |
+-----------------------------+---------------------+
| Truncation | Generalization |
| Reverse Truncation | Generalization |
| Permutation | Direct Substitution |
| Structured Pseudonymization | Direct Substitution |
+-----------------------------+---------------------+4.2.1. Truncation ✂️
Truncation removes "n" of the least significant bits from a MAC address and replaces them with zeroes 🫶. Basically it keeps the OUI, which tells you the manufacturer, and strips the least significant bits that identify the particular device 💖. Truncating 24 bits of an EAP-48 address or 40 bits of an EAP-64 address zeroes out the device identifier but keeps the OUI.
Truncation is great for making device manufacturers partially or completely identifiable in a dataset while deleting the unique host identifiers 🦋. You can use it to keep and aggregate MAC-layer behavior by vendor, which is so useful 😭.
Truncation to an address length of 0 is equivalent to black-marker anonymization 🖤.
4.2.2. Reverse Truncation 🔄
Reverse truncation removes "n" of the most significant bits from a MAC address and replaces them with zeroes 🌸. It's a non-reversible generalization scheme, so you can't undo it 🙈. This removes the bits of the OUI, which identify manufacturers, before it gets to the least significant bits. Reverse truncation of 24 bits zeroes out the OUI 💀.
Reverse truncation is effective for making device manufacturers partially or completely unidentifiable in a dataset ✨. Hot take though: it can cause ambiguity, because it introduces the possibility of truncated MAC address collision 😬. Also, the utility of removing manufacturer info isn't really covered well in the literature, so keep that in mind 🤔.
Reverse truncation to an address length of 0 is equivalent to black-marker anonymization 🖤.
4.2.3. Permutation 🔀
Permutation is a direct substitution technique 💅. It replaces each MAC address with an address picked from the set of possible MAC addresses, and each anonymized address represents a unique original address 🫶. The selection function is often random, though it doesn't have to be 🎲. Permutation doesn't keep any structural info about a network, but it does keep the unique count of devices on the network 🔢. So any app that needs more structure than just host-uniqueness won't be able to use permuted MAC addresses 💔.
There are loads of permutation functions, and each one comes with trade-offs in performance, security, and guarantees of non-collision 🧠. Evaluating those trade-offs is implementation independent 🛠️. Still, in general, permutation functions used for anonymization SHOULD be difficult to reverse without knowing the parameters (e.g., a secret key for HMAC) 🔐. The EAP-48 space is bigger than the IPv4 address space, but hash functions applied without extra parameters could be reversed through brute force if the hash function is known. So they SHOULD NOT be used as permutation functions 🚫. Permutation functions may guarantee non-collision (meaning each anonymized address represents a unique original address), but they need not 🤷♀️. Either way, the probability of collision SHOULD be low 📉. Even permutations with low but nonzero collision probability still get treated as a direct substitution 💁♀️. Beyond these guidelines, recommendations for specific permutation functions are out of scope for this document 🙅♀️.
4.2.4. Structured Pseudonymization 🧩
Structured pseudonymization for MAC addresses is a direct substitution technique, just like permutation, but with a restriction 💫. The OUI (the most significant three bytes) gets permuted separately from the node identifier, which is the remainder. This is useful when the uniqueness of OUIs has to be preserved for a given analysis task. The catch is that it introduces structure into the anonymized data, and attackers can exploit that structure against the anonymization technique 😱.
4.3. Timestamp Anonymization ⏰
The exact time a flow started or ended isn't particularly identifying 🤷♀️. 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 info about a set of traffic generated or otherwise known by an attacker to recover mappings of other anonymized fields 🎭. They can also identify certain activity through response delay and size fingerprinting, which compares response sizes and inter-flow times in anonymized data to known values 👀. These attacks have been shown to be pretty robust against timestamp anonymization techniques (see [Bur10]), so the techniques in this section are relatively weak and should be used with care 🥺.
+-----------------------+----------------------------+
| Scheme | Action |
+-----------------------+----------------------------+
| Precision Degradation | Generalization |
| Enumeration | Direct or Set Substitution |
| Random Shifts | Direct Substitution |
+-----------------------+----------------------------+4.3.1. Precision Degradation ⏳
Precision degradation is a generalization technique that removes the most precise components of a timestamp 🪄. It treats all events occurring in each given interval (e.g., one millisecond for millisecond level degradation) as simultaneous 👯. This can collapse many timestamps into one. With this technique, time precision goes down and sequencing may get lost, but the info about when the event happened is kept 🫶. The anonymized data may not be very useful for apps that need strict sequencing of flows 💔.
Flow meters with low time precision (e.g., second precision, or millisecond precision on high-capacity networks) already do the equivalent of precision degradation anonymization just by how they're designed 🛠️.
Degradation to a very low precision (on the order of minutes, hours, or days) is commonly used in analyses that work on time-series aggregated data, and it may also be called binning 📊. The time scales are longer and applicability is more restricted, but in principle it's the same operation 💅.
Precision degradation to infinitely low precision is equivalent to black-marker anonymization 🖤. Removing timestamp info is only recommended for analysis tasks that don't need to separate flows in time. For example, counting total volumes or unique occurrences of other flow keys across an entire dataset 🧮.
4.3.2. Enumeration 🔢
Enumeration is a substitution function that keeps the chronological order in which events occurred while getting rid of time info 📜. Timestamps are swapped for equidistant timestamps (or numbers) that start from a randomly chosen start value 🎲. The result is useful for apps that need strict sequencing, but not for apps that need good timing info, like delay- or jitter-measurement for quality-of-service (QoS) applications or service-level agreement (SLA) validation ⏱️.
Enumeration is functionally equivalent to precision degradation in any environment where traffic can be regularly injected to act as a clock at the precision of the frequency of the injected flows 🧚.
4.3.3. Random Shifts 🌀
Random time shifts add a random offset to every timestamp within a dataset 🎲. This makes it a reversible substitution technique, and it keeps duration and inter-event interval info along with the chronological order of flows 🕰️. Random time shifts are pretty weak though, and they're relatively easy to reverse if you have external knowledge about traffic on the measured network 😬.
4.4. Counter Anonymization 🔐
Counters (like packet and octet volumes per flow) are subject to fingerprinting and injection attacks against anonymization, or for user profiling, just like timestamps are 📈. Datasets with anonymized counters are only useful for analysis tasks where relative or imprecise magnitudes of activity are good enough 💖. You can also remove counter info completely, but that's only recommended for analysis tasks that don't need to evaluate the removed counter. For example, counting only unique occurrences of other flow keys 🙌.
+-----------------------+----------------------------+
| Scheme | Action |
+-----------------------+----------------------------+
| Precision Degradation | Generalization |
| Binning | Generalization |
| Random noise addition | Direct or Set Substitution |
+-----------------------+----------------------------+4.4.1. Precision Degradation 📉
Just like precision degradation with timestamps, precision degradation of counters removes the lower-order bits of the counters 🫧. It treats all the counters in a given range as having the same value. Depending on how much precision gets reduced, you lose info about the relationships between sizes of similarly sized flows, but you keep relative magnitude info 💅. Precision degradation to infinitely low precision is equivalent to black-marker anonymization 🖤.
4.4.2. Binning 🗑️
Binning can be seen as a special case of precision degradation 🧁. The operation is identical, except that in precision degradation the counter ranges are uniform, and in binning they don't need to be 📏. Say you want to separate unopened TCP connections from potentially opened TCP connections 🔍. You'd bin the packet counters per flow 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 info a counter needs for a given analysis task 🎯. Also, unlike precision degradation, the bin label doesn't need to be within the bin's range 🤯. Binning counters into a single bin is equivalent to black-marker anonymization 🖤.
4.4.3. Random Noise Addition 🎲
Okay so random noise addition is when you add a random amount to a counter in each flow 🎀. The vibe is keeping the relative magnitude info (who's bigger than who) while messing with the stuff that lets someone fingerprint the anonymization 🕵️♀️✨. ngl there's no guarantee it keeps the ranking order of a counter among a set, so don't bet your whole life on it 💀. It's especially useful when your analysis won't need the lower-order bits of the counters 🦋.
4.5. Anonymization of Other Flow Fields 🌸
Other fields, especially port numbers and protocol numbers, can help identify the apps that made the traffic in a flow trace 👀. That info can be used for fingerprinting attacks, and it's interesting on its own too, like spotting that a certain app with suspected vulnerabilities is running on a network 🙈. These fields are usually anonymized with one of two techniques, periodt 💅.
+-------------+---------------------+
| Scheme | Action |
+-------------+---------------------+
| Binning | Generalization |
| Permutation | Direct Substitution |
+-------------+---------------------+4.5.1. Binning 🪣
Binning is a generalization technique that maps a set of potentially non-uniform ranges into a set of arbitrarily labeled bins 🫶. The common bin arrangements depend on the field type and the analysis application. For example, an IP protocol bin arrangement can keep 1, 6, and 17 for ICMP, UDP, and TCP traffic, then toss every other protocol into one single bin 🗑️. That helps mitigate the use of uncommon protocols in fingerprinting attacks, which is so smart, honestly 🧠. Another example is binning source and destination ports into low (0-1023) and high (1024-65535) bins 🌈. That way you can tell service ports from ephemeral ones without identifying individual applications ✨.
Binning other flow key fields into a single bin is the same thing as black-marker anonymization 🖤. Removing other flow key info is only recommended for analysis tasks that don't need to tell flows apart based on those removed keys. Think total traffic counts or unique counts of other flow keys 📊.
4.5.2. Permutation 🔀
Permutation is a direct substitution technique 💖. It replaces each value with a value picked from the set of possible range, so each anonymized value stands for one unique original value 🦄. This keeps the count of unique values without keeping info about the values themselves, or how they're ordered 🙅♀️.
Permutation ideally guarantees that each anonymized value represents a unique original value, but that can need a lot of state in the Intermediate Anonymization Process 😭. So permutation may be implemented with hashing for performance reasons, using hash functions that have relatively small collision probabilities 🧮. These techniques are still basically direct substitution, even with that nonzero error probability 💅.
5. Parameters for the Description of Anonymization Techniques 📜
This section breaks down the abstract parameters used to describe the anonymization techniques from the last section, one parameter at a time 🧩. These parameters and their export safety shape the design of the IPFIX anonymization metadata export described in the next section 🫶.
5.1. Stability 🔒
A stable anonymization always maps a given real-space value to the same anonymized-space value 💜. An unstable one changes that mapping over time, and a completely unstable anonymization is basically indistinguishable from black-marker anonymization 🖤. Any technique can be applied with a range of stability ✨. Stability matters for comparing anonymized info across different datasets, or within the same dataset over different time periods 📅. In practice, an anonymization might be stable for every dataset a producer publishes to a particular consumer, stable for a stated time period within a dataset or across datasets, or stable for just a single dataset 🎀.
If there's no info about stability, users of anonymized data MAY assume the techniques are stable across the entire dataset but unstable across datasets 🤷♀️. Heads up that stability is a risk-utility trade-off 🍓. Completely stable anonymization is great for long-term trend analysis, but it also carries more attack risk because the mapping never changes 😬. Info about the stability of a mapping SHOULD be exported along with the anonymized data 📦.
5.2. Truncation Length ✂️
Truncation and precision degradation are described by the truncation length, which is how much data is still left in the anonymized field after anonymization 🌸.
Truncation length can usually be inferred from a given dataset, so it doesn't need to be specially exported or protected 🔍. For bit-level truncation, the truncated bits are generally inferable from the least significant bit set for an instance of an Information Element described by a given Template (or the most significant bit set, for reverse truncation) 🧠. For precision degradation, the truncation can be inferred from the maximum precision given 📏. This inference method is generally applicable, but it's data dependent, so there's no guarantee it recovers the exact truncation length used to prep the data 😵💫.
For IP address export with variable (per-record) truncation, the truncation MAY be expressed by exporting the prefix length alongside the address 🌐.
5.3. Bin Map 🗺️
Binning is described by a bin mapping function 💫. This function can generally be expressed as an associative array that maps each point in the original space to a bin, although in practice most bin functions are way simpler and more efficient 🧚.
The bin map is basically the bin mapping key, and it can partially deanonymize binned data depending on how much generalization was done 🔑. So info about the bin mapping function SHOULD NOT be exported 🙅♀️.
5.4. Permutation 🔀
Like binning, permutation is described by a permutation function 🎀. In the general case, that can be expressed as an associative array mapping each point in the original space to a point in the anonymized space 💖. The difference is that each anonymized point corresponds to a single, unique original point, unlike binning 🦄.
The parameters of a permutation function are basically keys (for cryptographic permutation functions, they are the keys) 🗝️. So info about the permutation function or its parameters SHOULD NOT be exported 🚫.
5.5. Shift Amount ➡️
Shifting needs an amount to shift each value by 💅. Since the shift amount is the only key to a shift function, and it can trivially deanonymize shifted data, info about the shift amount SHOULD NOT be exported 🙈.
6. Anonymization Export Support in IPFIX 🧚♀️
Anonymized data exported via IPFIX SHOULD be annotated with anonymization metadata 🏷️. That metadata details which fields, described by which Templates, are anonymized, and gives appropriate info on the anonymization techniques used 📝. This metadata SHOULD be exported in Data Records described by the recommended Options Templates in this section, and those Options Templates use the extra Information Elements described in the next subsection 💜.
Fields anonymized with the black-marker (removal) technique don't need any special metadata support 🖤. Black-marker anonymized fields SHOULD NOT be exported at all, so just leave the matching Information Elements out of the Template describing the Data Set 🙌. But if application requirements mean a black-marker anonymized field has to stay in a Template, an Exporting Process MAY export it with its native length as all-zeros 🫠. It can only do that when there's enough contextual info in the record to tell that field apart from a real zero value ✨.
6.1. Anonymization Records and the Anonymization Options Template
okay bestie, so the Anonymization Options Template is what describes Anonymization Records 💖 Those let anonymization metadata ride along inline over IPFIX, or get stored in an IPFIX File, by hooking info about anonymization techniques onto Information Elements inside defined Templates or Options Templates ✨ Exporting Processes SHOULD export anonymization records for any Template describing exported anonymized Data Records, and IPFIX Collecting Processes (plus anything downstream of them) MAY use those records to treat anonymized data differently depending on the technique 🎀
Anonymization Records are basically ancillary info tied to a Template, so a bunch of the Template rules apply here too 🧚 First up, reliability is a whole vibe 😭 An Exporting Process SHOULD export Anonymization Records after the Templates they describe have been exported, and SHOULD export anonymization records reliably if the transport supports it (so, no partial reliability when you're using Stream Control Transmission Protocol (SCTP)) 🦋
Collecting Processes MUST handle Anonymization Records as scoped to the Template they apply to, within the Transport Session they were sent in 🔥 If a Template gets withdrawn via a Template Withdrawal Message, or it expires during a UDP transport session, the Anonymization Records get withdrawn or expire right alongside it 💀 They don't apply to later Templates with the same Template ID in that Session unless they get re-exported 🙈
The Stability Class inside the anonymizationFlags IE can say that a technique's mapping stays stable across multiple sessions, but that does NOT mean the anonymization technique info in the Anonymization Records carries over between Sessions 🫶 Each new Transport Session MUST contain new Anonymization Records for each Template describing anonymized Data Sets, no exceptions bestie 💅
SCTP per-stream export [IPFIX-PERSTREAM] may be used to ease management of Anonymization Records if it's appropriate for the application 🌈
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. |
+-------------------------+-----------------------------------------+6.2. Recommended Information Elements for Anonymization Metadata
6.2.1. informationElementIndex
Description: a zero-based index of an Information Element referenced by informationElementId within a Template referenced by templateId ✨ It's there to sort out scope when a Template has multiple identical Information Elements 💖
Abstract Data Type: unsigned16
Data Type Semantics: identifier
ElementId: 287
Status: Current
6.2.2. anonymizationTechnique
Description: this describes 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 ones, and those restrictions are spelled out 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
Data Type Semantics: identifier
ElementId: 286
Status: Current
6.2.3. anonymizationFlags
okay so anonymizationFlags is a flag word 💅 that tweaks the anonymization policy for whichever technique is applied to a referenced Information Element inside a referenced Template ✨. when all the flags are clear (0), the normal policy from anonymizationTechnique just applies as-is, no extra drama 🌸
MSB 14 13 12 11 10 9 8 7 6 5 4 3 2 1 LSB
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Reserved |LOR|PmA| SC |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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 SC bits are basically the stability vibe 🦋 they describe how stable the anonymization technique is, meaning how steady its parameters stay. that decides how comfy the mapping between real and anonymized values is over time, and which anonymized datasets can actually be compared with each other 👀
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 are all about whether the parameters of the technique stay put, which is what makes the mapping between real and anonymized values comparable over time. this decides which anonymized datasets can be compared with each other. the values go like this 🎀
+-----+-----+-------------------------------------------------------+
| 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 🌈
Data Type Semantics: flags 🍓
ElementId: 285 ⭐
Status: Current ✨
7. Applying Anonymization Techniques to IPFIX Export and Storage 🦋
okay bestie, when you export or store anonymized flow data using IPFIX, there are some specific interactions between the IPFIX protocol and whichever anonymization techniques you're running that you have to think about 🧠💖 we unpack those in the subsections below, so keep reading, it's giving important 🫶
7.1. Arrangement of Processes in IPFIX Anonymization ✨
okay so anonymization can happen at three spots in the collection setup: on initial export, at a mediator, or after collection, as shown in Figure 1. each spot comes with its own considerations and what it's good for 💅
+==========================================+
| 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 Locationsso, anonymization usually happens before a dataset gets spread around or repurposed, like when you're turning operational measurement data into something researchers can use 🔬 which means anonymizing flow data right at initial export only really works in certain restricted situations: when the Exporting Process (EP) is "publishing" data straight to a Collecting Process (CP), and the EP and CP are run by different entities. also heads up, some of the timestamp guidance in Section 7.2.3 might not apply here, because the Collecting Process could figure out some timing info just from when each Message shows up 🕰️
a much more flexible setup is to anonymize inside a Mediator [RFC6183] 🦋 here the original data goes to a Mediator, which does the anonymizing and then re-exports the cleaned-up data. the Mediator could sit right on the admin domain boundary of whoever runs the original Exporting Process, and then ship anonymized data out to consumers beyond the organization. in this case, the original Exporter SHOULD use TLS [RFC5246] as specified in [RFC5101] to lock down the channel to the Mediator, and the Mediator should follow the guidelines in Section 7.2 so the risk of the original data leaking stays low 🔒
when data is going to be published as an anonymized dataset in an IPFIX File [RFC5655], the anonymizing can also happen at the final Collecting Process, right before storage and dissemination 🌸 in that case the Collector should follow the guidelines in Section 7.2, especially the bits about File-specific Options in Section 7.2.4.
in every one of these data flows, the actual anonymizing of records is done by an Intermediate Anonymization Process (IAP) ✨ the flows going into and out of this IAP are shown in Figure 2 below.
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 Processanonymization parameters also have to be available to the Exporting Process and/or File Writer, so the header data gets anonymized properly too, as covered in Section 7.2.3 🎀
next up, we're going through the IAP's data flows and walking through five basic types of anonymization setups in this framework, shown in Figure 3 💖 on top of the three arrangements we just talked about, anonymization can also happen at a collocated Metering Process (MP) and File Writer (FW) (see Section 7.3.2 of [RFC5655]), or at a file manipulator, which is a File Writer paired with a File Reader (FR) (see Section 7.3.7 of [RFC5655]).
+----+ +-----+ +----+
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
Architectureand here's the fun bit: anonymization can happen at more than one location in the same collection infrastructure 🌈 that lets you pick different levels of anonymization, disclosure risk, or data utility depending on what each purpose needs 👑
7.2. IPFIX-Specific Anonymization Guidelines 🫶
okay so if you're implementing or deploying the anonymization techniques in this document, implementors should know that IPFIX already has features built in for anonymized data export, and they should use those wherever it makes sense 💅 also, be careful that the data structures keeping the protocol itself running don't leak info that could be used to reverse the anonymization on the flow data 😭 those structures can show up in the header, or inside the data stream itself, especially as options data. each of these and how it affects specific anonymization techniques gets its own subsection below 🧚
7.2.1. Appropriate Use of Information Elements for Anonymized Data 🍓
quick reminder from Section 6 above: black-marker anonymized fields SHOULD NOT be exported at all 🙈 a field's absence from a Data Set is implicitly declared just by leaving its Information Element out of the Template that describes that Data Set.
when you're using precision degradation on timestamps, Exporting Processes SHOULD export timing info using Information Elements of the right precision, as explained in Section 4.5 of [RFC5153] ✨ for example, if your timestamps are measured at millisecond precision and get degraded to second precision, you should use flowStartSeconds and flowEndSeconds, not flowStartMilliseconds and flowEndMilliseconds 💜
when you're exporting anonymized data and anonymization metadata, Exporting Processes SHOULD ensure the Information Element and the declared anonymization technique actually go together 💅 the applicable and recommended Information Element types and semantics for each technique are listed in the description of the anonymizationTechnique Information Element in Section 6.2.2. in that 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. the big rule here: an Exporting Process MUST NOT export Anonymization Options records binding techniques to Information Elements they don't apply to 🚫 and it SHOULD NOT export Anonymization Options records binding techniques to Information Elements they aren't recommended for 🙅♀️
7.2.2. Export of Perimeter-Based Anonymization Policies 🌷
sometimes data from a single network needs different anonymization policies for addresses inside the network and addresses outside it 🏡 for example, internal addresses might get simple permutation, while external addresses get aggregated into networks by truncation 🌍 when you're exporting anonymized perimeter bidirectional flow (biflow) data as in Section 5.2 of [RFC5103], this setup can be represented pretty easily by specifying one technique for source endpoint information (which stands for the external endpoint in a perimeter biflow) and one technique for destination endpoint information (which stands for the internal address in a perimeter biflow) 🦋
that said, it can also be handy to represent perimeter-based anonymization policies with unidirectional flow (uniflow) data, or with non-perimeter biflow data 🧩 in that case, you can set the Perimeter Anonymization bit (bit 2) in the anonymizationFlags Information Element that describes the anonymized address Information Elements. this changes the meaning of "source" and "destination" so they mean "external" and "internal" like they do for perimeter biflows, but only with respect to anonymization policies 🎀
7.2.3. Anonymization of Header Data 🌸
each IPFIX Message has a Message Header, and two fields in there can accidentally break certain anonymization techniques: the Export Time, and the Observation Domain ID 🕰️
when an IPFIX Message contains anonymized timestamp data and the original Export Time header field has some relationship to those anonymized timestamps, the Export Time header field SHOULD be anonymized too, so the Export Time stays consistent with the anonymized timestamp data 💖 otherwise, relationships between export time and flow time could be used to partially or totally reverse the timestamp anonymization 😱 also, when anonymizing timestamps and the Export Time header field, you SHOULD avoid times that are too far in the past or future 🙃 [RFC5101] doesn't make any allowance for Export Time error detection, but it makes sense that Collecting Processes might treat Messages with seemingly nonsensical Export Times as erroneous 🚨 the specific limits are implementation dependent, so anonymizing the Export Time header field may cause interoperability issues 🫠
the Observation Domain ID is also 32 bits, the same size as an IPv4 address, so there's a temptation to use an IPv4 interface address on the Metering or Exporting Process as the Observation Domain ID 👀 but if that address is related to the IP addresses in the flow data (say it shares a network prefix with the internal addresses), and those flow addresses are anonymized in a structure-preserving way, then the Observation Domain ID could be used to break the IP address anonymization 💀 so using an IPv4 interface address on the Metering or Exporting Process as the Observation Domain ID is NOT RECOMMENDED in that case 🙅♀️✨
7.2.4. Anonymization of Options Data 🎀
okay so IPFIX uses the Options mechanism to export all sorts of metadata about exported flows and the flow collection infrastructure 🧚. Just like the IPFIX Message Header, certain Options recommended in [RFC5101] and [RFC5655] contain flow timestamps and network addresses of Exporting and Collecting Processes, and those can be used to break certain anonymization techniques 💀. So when you're using these Options alongside anonymized data export and storage, any values in the Options that could break the anonymization SHOULD themselves be anonymized or omitted 🫶.
The Exporting Process Reliability Statistics Options Template, recommended in [RFC5101], has an Exporting Process ID field. That field can be an exportingProcessIPv4Address Information Element or an exportingProcessIPv6Address Information Element 👀. If the Exporting Process address has some relation to the IP addresses in the flow data (like sharing a network prefix with internal addresses) and those flow IP addresses 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 the one used on the IP addresses in the exported data 🔐.
Similarly, the Export Session Details Options Template and Message Details Options Template specified for the IPFIX File Format [RFC5655] may contain the exportingProcessIPv4Address or exportingProcessIPv6Address Information Element to identify the Exporting Process a flow record came from. They may also contain the collectingProcessIPv4Address or collectingProcessIPv6Address Information Element to identify the Collecting Process that received it 📦. If the Exporting Process or Collecting Process address relates to the IP addresses in the dataset (like sharing a network prefix with internal addresses) and those dataset IP addresses are anonymized in a structure-preserving way, then that Exporting or Collecting Process address may be used to break the IP address anonymization. Since these Options Templates are mainly for storing IPFIX Transport Session data for auditing, replay, and testing, it is NOT RECOMMENDED that storage of anonymized data include these Options Templates, in order to mitigate the risk of attack 🙈.
The Message Details Options Template specified for the IPFIX File Format [RFC5655] also contains the collectionTimeMilliseconds Information Element ⏰. Same vibe as the Export Time Message Header field: if the exported dataset has anonymized timestamp information, and the collectionTimeMilliseconds Information Element in a given Message has some relationship to that anonymized timestamp info, then that relationship can be exploited to reverse the timestamp anonymization. Since this Options Template is mainly for storing IPFIX Transport Session data for auditing, replay, and testing, it is NOT RECOMMENDED that storage of anonymized data include this Options Template, to mitigate the risk of attack 🚫.
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 🦋.
7.2.5. Special-Use Address Space Considerations 🌈
When you're anonymizing data for transport or storage with IPFIX, and that data contains anonymized IP addresses, and the analysis purpose allows it, 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 with these addresses (e.g., 0.0.0.0 and 169.254.0.0/16 for link-local autoconfiguration in IPv4 space) is often tied to specific, well-known behavioral patterns 👀. Spotting those patterns in anonymized data can lead to deanonymization of these special-use addresses. That raises the chance of a complete reversal of anonymization by an attacker, especially with prefix-preserving techniques 💀🔥.
7.2.6. Protecting Out-of-Band Configuration and Management Data 🔒
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 those counters from Simple Network Management Protocol (SNMP) information. Concealing the network under test is similarly useless if that information is available in a configuration document 🙄. Since 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 what was anonymized SHOULD NOT be made available to the receiver by any means: not in the Data Records, not in IPFIX protocol structures such as Message Headers, and not out of band 🫶✨.
8. Examples ✨
okay so bestie, this section is where we actually SEE the whole thing work 🎀 we're looking at exporting or storing an anonymized IPv4 dataset from one single network. The record is a super simple Template with a timestamp in seconds, a five-tuple, and packet and octet counters 📦 Figure 4 shows the Template for each record in this Data Set 💖
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 TemplateNow suppose this Data Set gets anonymized with this policy 🦋
- IP addresses within the network are protected by reverse truncation.
- IP addresses outside the network are protected by prefix-preserving anonymization.
- Octet counts are exported using degraded precision in order to provide minimal protection against fingerprinting attacks.
- All other fields are exported unanonymized.
To export Anonymization Records for this Template and policy, we first export the Anonymization Options Template in Figure 5 🌸 For this example, the optional privateEnterpriseNumber and informationElementIndex Information Elements are left out, because they aren't used here.
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 TemplateAfter the Anonymization Options Template comes a Data Set with the Anonymization Records 💅 It has an entry for each Information Element Specifier in Template 256, which describes the flow records. You can see it in Figure 6. Heads up 👀 sourceIPv4Address and destinationIPv4Address both have the Perimeter Anonymization (0x0004) flag set in anonymizationFlags. That means the source address gets treated as network-external, and the destination address as network-internal 🔥
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 RecordsAfter the Anonymization Records come the Data Sets with the anonymized data, exported according to the Template in Figure 4 ✨ Putting it all together, we look at an IPFIX Message with three real data records and the templates needed to export them, shown in Figure 7 🧚 (The scale of this message is 8 bytes per line, for compactness. The lines of dots '. . . . . ' just show the example bit structure shifting, 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 MessageHere's the anonymized version of that message, shown in Figure 8 💜 The Options Template Set that describes the Anonymization Records, plus the Anonymization Records themselves, get added in. IP addresses and byte counts are anonymized exactly as declared 🙈
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 Message9. Security Considerations 🔐
Okay bestie, this one's the serious section, so we're gonna be real about it 💀 This doc gives guidelines for exporting metadata about anonymized data in IPFIX, or for storing metadata about anonymized data in IPFIX Files. It is not a general statement on whether any particular flow data anonymization technique is a good fit, so don't read it that way 🙅♀️ Anyone exporting or publishing anonymized data has to make sure the technique actually fits the data source, the purpose, and the deanonymization risk of their application 🎀
Research into anonymization techniques, and into how to deanonymize them, is still happening 🔬 So a technique that's "safe" right now might get rendered unsafe later by new developments. Yikes 😭
We also need to be super clear that anonymization is not a replacement for encryption when it comes to confidentiality 🚫 It's only a good fit for protecting identifying info in data that's going to be used for purposes where the protected data doesn't matter. Confidentiality in export is best handled with TLS [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC4347], as covered in the Security Considerations section of [RFC5101], and for long-term storage, with implementation-specific protection like the one in the Security Considerations section of [RFC5655]. And honestly? Confidentiality and anonymization aren't enemies 🫶 You can apply encryption for confidentiality on top of anonymized data export or storage too, especially when that anonymized data isn't meant for public release.
Even well-anonymized data still deserves care 🥺 Treat it as privacy-sensitive, always. Anonymization lowers the risk of misuse, but it's not a complete fix for protecting end-user privacy in network flow trace analysis, so don't get too comfy 💅
When you're using pseudonymization techniques with a mutable mapping, there's a real trade-off 🧩 The stability of the map affects both long-term comparability and how well the dataset holds up against deanonymization. Generally, deanonymization attacks get stronger with more information, so the longer a given mapping stays valid, the more info can be used to deanonymize the data. The specifics depend on the technique, so they're out of scope for this document 🤷♀️
When publishers release anonymized data, they need to make sure data that could be used for deanonymization doesn't leak through a side channel 👀 The whole workflow (hardware, software, operational policies and procedures, and so on) has to be checked for data leakage risk. Most of these side channels are out of scope here, but guidelines for reducing information leakage that's specific to the IPFIX export protocol are in Section 7.2 ✨
Last but not least, the Security Considerations section of [RFC5101] also applies to exporting anonymized data, and the Security Considerations section of [RFC5655] applies to storing anonymized data or publishing anonymized traces 📦 Don't skip those, periodt 💜
10. IANA Considerations 🦋
This document creates several new IPFIX Information Elements in the IPFIX Information Element registry, which you can find on the IANA site (http://www.iana.org), as defined in Section 6.2. IANA has assigned the following Information Element numbers to their matching Information Elements 🌸
- Information Element number 285 for the
anonymizationFlagsInformation Element. 🚩 - Information Element number 286 for the
anonymizationTechniqueInformation Element. 🛠️ - Information Element number 287 for the
informationElementIndexInformation Element. 📇
11. Acknowledgments 🫶
Huge thanks to Paul Aitken and John McHugh for their comments and insight 💖 And a big group hug for Carsten Schmoll, Benoit Claise, Lothar Braun, Dan Romascanu, Stewart Bryant, and Sean Turner for their reviews 🎀 Special shoutout to the FP7 PRISM and DEMONS projects for their material support of this work 🌈
12. References 📚
12.1. Normative References
- [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. 🌊
- [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008. 🧠
- [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export Using IP Flow Information Export (IPFIX)", RFC 5103, January 2008. ↔️
- [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. 🗂️
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
- [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010. 🌐
- [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April 2008. 🌐
12.2. Informative References
- [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, "Architecture for IP Flow Information Export", RFC 5470, March 2009. 🏛️
- [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, "IP Flow Information Export (IPFIX) Applicability", RFC 5472, March 2009. 🧩
- [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. Ishibashi, "IP Flow Information Export (IPFIX) Mediation: Framework", RFC 6183, April 2011. 🔀
- [IPFIX-PERSTREAM] Claise, B., Aitken, P., Johnson, A., and G. Muenz, "IPFIX Export per SCTP Stream", Work in Progress, May 2010. 🚧
- [RFC5153] Boschi, E., Mark, L., Quittek, J., Stiemerling, M., and P. Aitken, "IP Flow Information Export (IPFIX) Implementation Guidelines", RFC 5153, April 2008. 🛠️
- [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, "Requirements for IP Flow Information Export (IPFIX)", RFC 3917, October 2004. 📝
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 🏠
- [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. 🔐
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🔒
- [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. 🕵️
- [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. 🎓
Authors' Addresses 🏫
Elisa Boschi Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
EMail: boschie@tik.ee.ethz.ch
Brian Trammell Swiss Federal Institute of Technology Zurich Gloriastrasse 35 8092 Zurich Switzerland
Phone: +41 44 632 70 13 EMail: trammell@tik.ee.ethz.ch
And that's a wrap on the whole RFC, bestie 🌈✨💖
📦 where this page comes from
- ietf: rfc6235 2011-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms