RFC 7594
A Framework for Large-Scale Measurement of Broadband Performance (LMAP)
A Framework for Large-Scale Measurement of Broadband Performance (LMAP) 🦋
okay bestie, this is RFC 7594 and it's an Informational doc from the IETF, not a Standards Track spec 💅 It came out in September 2015 with ISSN 2070-1721. The author crew is P. Eardley (BT), A. Morton (AT&T Labs), M. Bagnulo (UC3M), T. Burbridge (BT), P. Aitken (Brocade), and A. Akhter (a Consultant) 🫶 There's no "Obsoletes" or "Updates" line in the header, so it doesn't replace or change any other RFC.
Abstract 🌸
measuring broadband at a large scale needs two things: a clear picture of the logical architecture, and standardised key protocols that organise how the parts talk to each other 🧚 this doc lays out an overall framework for that kind of big measurement, and it also defines the terminology for LMAP (Large-Scale Measurement of Broadband Performance) ✨
Status of This Memo 📜
this is not an Internet Standards Track spec. It's published just for information 🍓
this doc is a product of the Internet Engineering Task Force (IETF) and it reflects what the IETF community agrees on 🌈 it got public review and the Internet Engineering Steering Group (IESG) approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that 👑
for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7594 💜
Copyright Notice 🎀
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. ✨
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date, so please actually read them, because they spell out your rights and restrictions for this doc 🙈 Code Components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as described in the Simplified BSD License 🔥
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Outline of an LMAP-Based Measurement System . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. The Measurement System Is Under the Direction of a Single
Organisation . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Each MA May Only Have a Single Controller at Any Point in
Time . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Bootstrapping Process . . . . . . . . . . . . . . . . . . 14
5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 15
5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 15
5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 16
5.2.3. Capabilities, Failure, and Logging Information . . . 20
5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 22
5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 22
5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 24
5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. Reporting of the Subscriber's Service Parameters . . 26
5.5. Operation of LMAP over the Underlying Packet Transfer
Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 26
5.6. Items beyond the Scope of the Initial LMAP Work . . . . . 27
5.6.1. End-User-Controlled Measurement System . . . . . . . 28
6. Deployment Considerations . . . . . . . . . . . . . . . . . . 29
6.1. Controller and the Measurement System . . . . . . . . . . 29
6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 30
6.2.1. Measurement Agent on a Networked Device . . . . . . . 30
6.2.2. Measurement Agent Embedded in a Site Gateway . . . . 31
6.2.3. Measurement Agent Embedded behind a Site NAT or
Firewall . . . . . . . . . . . . . . . . . . . . . . 31
6.2.4. Multihomed Measurement Agent . . . . . . . . . . . . 31
6.2.5. Measurement Agent Embedded in an ISP Network . . . . 32
6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 32
6.4. Deployment Examples . . . . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 36
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 38
8.1. Categories of Entities with Information of Interest . . . 38
8.2. Examples of Sensitive Information . . . . . . . . . . . . 39
8.3. Different Privacy Issues Raised by Different Sorts of
Measurement Methods . . . . . . . . . . . . . . . . . . . 40
8.4. Privacy Analysis of the Communication Models . . . . . . 41
8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 41
8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 42
8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 43
8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 43
8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 45
8.4.6. Storage and Reporting of Measurement Results . . . . 46
8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 46
8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 47
8.5.3. Correlation and Identification . . . . . . . . . . . 47
8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 48
8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 48
8.6.1. Data Minimisation . . . . . . . . . . . . . . . . . . 48
8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 49
8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 50
8.6.4. Other Mitigations . . . . . . . . . . . . . . . . . . 50
9. Informative References . . . . . . . . . . . . . . . . . . . 51
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 541. Introduction ✨
okay so there's a real desire to coordinate broadband measurements and gather the results across a massive pile of Measurement Agents (MAs) 🌸 these MAs could be software agents running on PCs, embedded agents in consumer devices like TVs or gaming consoles, or built into service-provider-controlled stuff like set-top boxes and home gateways. They could also just be dedicated probes. MAs can even live on a device inside an ISP's network, like a DSLAM (Digital Subscriber Line Access Multiplexer), a router, a Carrier Grade NAT (Network Address Translator), or an ISP Gateway 🛜 it's expected that one measurement system could easily cover a few hundred thousand, or even millions, of these MAs. 😭 that scale creates some seriously unique problems for coordination, execution, and collecting the results.
there are two main use cases people have proposed for big measurements:
- Operators: to help plan their network and find faults 🔧
- Regulators: to benchmark several network operators and support public policy development 🏛️
you can read more about the use cases in [RFC7536] 💜 the LMAP framework should be useful for those, plus other use cases too, like helping end users run diagnostic checks such as a network speed test 🚀
the LMAP framework has three basic elements: Measurement Agents, Controllers, and Collectors 🧚
Measurement Agents (MAs) are the ones that actually start the measurements, and those measurements are called Measurement Tasks in LMAP-speak 🦋 in principle, there's no restriction on what kind of device the MA function can live in, so it's very flexible 💅
the Controller is the boss 👑 it tells one or more MAs which set of Measurement Tasks to run and when. For example, it might tell an MA at a home gateway something like: "Measure the 'UDP latency' with www.example.org; repeat every hour at xx.05". The Controller also manages an MA by telling it how to report the Measurement Results, for example: "Report results once a day in a batch at 4am". We call these the Measurement Schedule and the Report Schedule 📅
the Collector is the one that accepts Reports from the MAs, which contain the Results from their Measurement Tasks 🫶 so the MA is basically a device that gets Instructions from the Controller, starts the Measurement Tasks, and reports back to the Collector. The way these three LMAP functions talk to each other is structured around a Control Protocol and a Report Protocol 🌈
the design goals for a large-scale Measurement System are these features:
- Standardised: this covers the Measurement Tasks, the components, the data models, and the protocols used to move information between the components 📚 it's a big deal because it lets you make meaningful comparisons of measurements of the same Metric at different times and places. It also gives the operator of a Measurement System criteria to evaluate the different solutions for various purposes, including buying decisions (like buying the different components from different vendors) 🛒 today's systems are proprietary in some or all of these respects, so this is the glow-up we need ✨
- Large-scale: [RFC7536] imagines Measurement Agents in every home gateway and edge device, such as set-top boxes and tablet computers, and spread all over the Internet as well [RFC7398] 🌍 it's expected that a Measurement System could easily cover a few hundred thousand or even millions of Measurement Agents. Existing systems have up to a few thousand MAs (without judging how much further they could scale) 📈
- Diversity: a Measurement System should be able to handle Measurement Agents from different vendors, in wired and wireless networks, that can run different sorts of Measurement Tasks, that sit on devices with IPv4 or IPv6 addresses, and so on 🌸
- Privacy Respecting: the protocols and procedures should respect the sensitive information of everyone involved in the measurements 🔒 privacy is non-negotiable, bestie 💖
2. Outline of an LMAP-Based Measurement System ✨
okay so this section is the big-picture tour of the whole Measurement System 💅 New LMAP-specific terms get capitalised, so keep an eye out for those 👀 Section 3 has a terminology section that compiles every LMAP term with its definition, and from Section 4 onwards we zoom into each component in more detail 🎀
Other LMAP specifications will define an Information Model, the associated Data Models, and select or extend one or more protocols for secure communication. Two protocols are on the list:
- A Control Protocol, for a Controller to instruct Measurement Agents about which performance Metrics to measure, when to measure them, and how and when to report the measurement results to a Collector.
- A Report Protocol, for a Measurement Agent to report the results to the Collector.
Figure 1 shows the main components of a Measurement System and how they talk to each other 🦋 Some of those components are outside the scope of initial LMAP work, so don't panic when you see them 🫶
The MA performs Measurement Tasks, and there are two ways it can do that. One possibility is that the MA just observes existing traffic 👀 The other is for the MA to generate (or receive) traffic that was specially created for the purpose, and then measure some Metric linked to its transfer 🚀 Figure 1 includes both possibilities, even though in practice an MA will usually do just one 💅 Section 6.4 shows some examples of how the components can be arranged.
MAs are pieces of code that can run on specialised hardware (a hardware probe) or on a general-purpose device like a PC or mobile phone 💻 A device with a Measurement Agent may have multiple physical interfaces, like Wi-Fi, Ethernet, or DSL (Digital Subscriber Line), and non-physical interfaces like PPPoE (Point-to-Point Protocol over Ethernet) or IPsec 🌐 The Measurement Tasks are allowed to specify any one of these interfaces, so the MA can be really specific 🎯
The Controller manages an MA through the Control Protocol, which delivers the Instruction to the MA 🎀 The Instruction describes which Measurement Tasks the MA should perform and when. For example, the Controller might tell an MA at a home gateway: Count the number of TCP SYN packets observed in a 1 minute interval; repeat every hour at xx.05 + Unif[0,180] seconds. That's the Measurement Schedule, and it decides when the Measurement Tasks actually run ⏰
The Controller also tells the MA how to report the Measurement Results, which is a whole other vibe 📬 For example: Report results once a day in a batch at 4am + Unif[0,180] seconds; if the end user is active then delay the report 5 minutes. That instruction forms the Report Schedule, and it decides when the Reports get uploaded to the Collector 🚀 The Measurement Schedule and Report Schedule can also handle one-off (non-recurring) actions, like "Do measurement now" or "Report as soon as possible", as well as recurring ones 🔁
The Collector accepts a Report from an MA, and that Report carries the Measurement Results from its Measurement Tasks 📥 After that, the Collector passes the Results along to a repository 🗂️
A Measurement Method defines how to measure a Metric of interest 🔬 Standardising Measurement Methods is a huge deal, because it makes sense to compare measurements of the same Metric taken at different times and places 💖 It's also useful to have a registry for commonly used Metrics [IPPM-REG], so a Metric and its associated Measurement Method can be referred to simply by its identifier in the registry 🌸 Hopefully other standards organisations will reference that registry too ✨ Measurement Methods can be defined by the IETF, locally, or by some other standards body 🌍
Broadly speaking, there are two types of Measurement Methods 🦋 In both types, a Measurement Agent measures a particular Observed Traffic Flow. In the first type, a single MA just observes existing traffic. For example, the Measurement Agent could count bytes or work out the average loss for a particular flow 🧮 In the second type, a Measurement Method observes traffic created specifically for measurement. This needs multiple network entities, each playing a different role 🎭 For example, to measure round trip delay, one possible Measurement Method has an MA send an ICMP (Internet Control Message Protocol) ECHO request ("ping") to a responder on the Internet 🏓 In LMAP terms, that responder is called a Measurement Peer (MP). It helps the MA, but it isn't managed by the Controller 🫶 Other Measurement Methods involve a second MA, with the Controller instructing both MAs in a coordinated way 👯♀️
Traffic generated specifically as part of a Measurement Method is called Measurement Traffic. In the ping example, that's the ICMP ECHO Requests and Replies 📡 The protocols used for Measurement Traffic are out of scope for initial LMAP work. They belong to other IETF working groups, like IPPM (IP Performance Metrics) 💅
A Measurement Task is the action a particular MA performs at a particular time. It's the specific instance of that MA's role in a Measurement Method. LMAP is mainly concerned with Measurement Tasks, for example when it comes to its Information Model and Protocols 💜
For Measurement Results to be truly comparable, which a regulator might need, the same Measurement Methods have to be used to assess Metrics. On top of that, the set of Measurement Tasks should follow a similar Measurement Schedule and be of similar number 📊 The details of that characterisation plan are beyond the scope of IETF work, although the IETF's work definitely makes it easier 🧚
Both control and report messages travel over a secure Channel 🔐 A Control Channel runs between the Controller and an MA. The Control Protocol delivers Instruction Messages to the MA, and sends Capabilities, Failure, and Logging Information back in the reverse direction 🔁 A Report Channel runs between an MA and a Collector, and the Report Protocol delivers Reports to the Collector 📮
Last but not least, there are several components outside the scope of initial LMAP work. They'll be provided through existing protocols or applications 🌈 They affect how the Measurement System uses the Measurement Results, and how it decides which set of Measurement Tasks to run 🧠 As shown in Figure 1, these components are:
- the bootstrapper
- the Subscriber parameter database
- data analysis tools
- the Results repository
The MA needs to be bootstrapped with initial details about its Controller, including authentication credentials 🔑 The LMAP work considers the Bootstrap process, since it affects the Information Model. However, LMAP doesn't define a Bootstrap protocol, because that's likely to be technology specific. It could be defined by the Broadband Forum, CableLabs, or IEEE, depending on the device 🏠 Possible protocols include SNMP (Simple Network Management Protocol), NETCONF (Network Configuration Protocol), or, for Home Gateways, CPE WAN Management Protocol (CWMP) from the Auto Configuration Server (ACS), as specified in TR-069 [TR-069] 🛠️
A Subscriber parameter database holds information about the line 📋 That includes the customer's broadband contract (perhaps 2, 40, or 80 Mb/s), the line technology (DSL or fibre), the time zone the MA is located in, and the type of home gateway and MA. Existing operations systems already gather and store these parameters 🗃️ They can affect which Measurement Tasks get run and how the Measurement Results are interpreted 🧐 For example, a download test that's perfectly fine for an 80 Mb/s contract could totally overwhelm a 2 Mb/s line 💀
A Results repository records all Measurement Results in an equivalent form, for example an SQL (Structured Query Language) database, so the data analysis tools can access them easily 🗄️
The data analysis tools receive results from the Collector or through the Results repository 📊 They might visualise the data, or work out which component or link is likely causing a fault or degradation 🔍 That info could help the Controller decide what follow-up Measurement Task to run in order to diagnose a fault 🩺 The data analysis tools also need to understand the Subscriber's service information, such as the broadband contract 🎀
+--------+ +-----------+ +-----------+ ^
|End user| | | Observed | End user | |
| |<-----|-----------|---Traffic--->| | |
| | | | Flow | | |
| | | | | | Non-LMAP
| | | | Measurement | | Scope
| | | |<--Traffic--->| | |
+--------+ | | +-----------+ |
................|...........|.................................V
<MP> |Measurement| <MP> ^
|Agent: | |
|LMAP | |
+----------->|interface | |
| +-----------+ |
| ^ | LMAP
| Instruction | | Report Scope
| (over Control | | (over Report Channel) |
| Channel) | +-----------------------+ |
| | | |
| | | |
| | v |
| +------------+ +------------+ |
| | Controller | | Collector | |
| +------------+ +------------+ v
| ^ ^ | ^
| | | | |
| | +--------+ | |
| | | v |
+------------+ +----------+ +--------+ +----------+ |
|Bootstrapper| |Subscriber|--->| data |<---| Results | Non-
+------------+ |parameter | |analysis| |repository| LMAP
|database | | tools | +----------+ Scope
+----------+ +--------+ |
|
|
v
MP: Measurement Peer
Figure 1: Schematic of main elements of an LMAP-based Measurement
System (showing the elements in and out of the scope of initial LMAP
work)3. Terminology ✨
okay bestie, this is the glossary 📖 defined terms are CAPITALISED everywhere in LMAP, so if a word has capitals, it's a defined term with a specific meaning. read these first 💅
Bootstrap 🥾: a process that integrates a Measurement Agent into a Measurement System.
Capabilities 🧰: information about the performance measurement capabilities of the MA. That covers the Measurement Method roles and measurement protocol roles it can perform, plus the device hosting the MA, like its interface type and speed. It does not include dynamic information.
Channel 🔗: a bidirectional logical connection defined by a specific Controller and MA, or Collector and MA, plus its associated security.
Collector 📥: a function that receives a Report from an MA.
Configuration ⚙️: a process for informing the MA about its MA-ID, (optional) Group-ID, and Control Channel.
Controller 🧠: a function that provides a Measurement Agent with its Instruction.
Control Channel 🎀: a Channel between a Controller and an MA. Instruction Messages and Capabilities, Failure, and Logging Information travel over it.
Control Protocol 📡: the protocol that delivers Instruction(s) from a Controller to a Measurement Agent. It also carries Capabilities, Failure, and Logging Information from the Measurement Agent back to the Controller. It can be used to update the MA's Configuration too, and it runs over the Control Channel.
Cycle-ID 🔁: a tag that the Controller sends in an Instruction and the MA echoes back in its Report. Several MAs that use the same Measurement Method for a Metric with the same Input Parameters share the same Cycle-ID. So the Collector can easily spot Measurement Results that should be comparable. this one is so clever 🤌
Data Model 🗂️: the implementation of an Information Model in a particular data modelling language [RFC3444].
Environmental Constraint 🌡️: a parameter that is measured as part of the Measurement Task. Its value decides whether the rest of the Measurement Task goes ahead.
Failure Information 🚨: information about the MA's failure to take action or execute an Instruction, whether that's about Measurement Tasks or Reporting.
Group-ID 👯: an identifier for a group of MAs.
Information Model 📐: the protocol-neutral definition of the semantics of the Instructions, the Report, the status of the different elements of the Measurement System, as well as the events in the system [RFC3444].
Input Parameter 🎛️: a parameter whose value is left open by the Metric and its Measurement Method, and gets set to a specific value in a Measurement Task. changing an Input Parameter doesn't change the fundamental nature of the Measurement Task, so it's still the same vibe ✨
Instruction 📋: the description of the Measurement Tasks for an MA to perform, and the details of the Report it should send. It's the whole package: the Measurement Task configurations, the configuration of the Measurement Schedules, the configuration of the Report Channel(s), the configuration of the Report Schedule(s), and the details of any Suppression.
Instruction Message 💌: the message that carries an Instruction from a Controller to a Measurement Agent.
Logging Information 🪵: information about how the Measurement Agent is operating, which might be useful for debugging.
Measurement Agent (MA) 🕵️: the function that receives Instruction Messages from a Controller and runs the Instruction by executing Measurement Tasks. It might use protocols outside the scope of the initial LMAP work, and it might work with one or more other Measurement Agents or Measurement Peers. If the Instruction asks for it, it also reports Measurement Results to a Collector or Collectors.
Measurement Agent Identifier (MA-ID) 🪪: a Universally Unique IDentifier [RFC4122] that identifies a particular MA. It gets configured as part of the Bootstrapping process.
Measurement Method 🧪: the process for assessing the value of a Metric. It's the process of measuring some performance or reliability Metric linked to the transfer of traffic.
Measurement Peer (MP) 🤝: the function that helps a Measurement Agent with Measurement Tasks. It does not have an interface to the Controller or Collector.
Measurement Result 🏆: the output of a single Measurement Task, which is the value obtained for the Metric.
Measurement Schedule 🗓️: the schedule for performing Measurement Tasks.
Measurement System 🏠: the set of LMAP-defined and related components that are operated by a single organisation, for the purpose of measuring performance aspects of the network.
Measurement Task 🎯: the action a particular Measurement Agent performs. It's a single assessment of a Metric, done by running a Measurement Method role at a particular time, with all of that role's Input Parameters set to specific values.
Measurement Traffic 🚚: the packet(s) generated by some types of Measurement Method that measure some parameter linked to the transfer of those packet(s).
Metric 📏: the quantity related to the performance and reliability of the network that we'd like to know the value of.
Observed Traffic Flow 👀: in RFC 7011 [RFC7011], a Traffic Flow (or Flow) is defined as "a set of packets or frames passing an Observation Point in the network during a certain time interval. All packets belonging to a particular Flow have a set of common properties," such as packet header fields, characteristics, and treatments. A Flow measured by the LMAP system is called an Observed Traffic Flow. Its properties get summarised and tabulated in Measurement Results, as opposed to raw capture and export.
Report 📦: the set of Measurement Results and other associated information (as defined by the Instruction). A Measurement Agent sends the Report to a Collector.
Report Channel 📨: a Channel between a Collector and an MA, over which Report messages are sent.
Report Protocol 📬: the protocol that delivers Report(s) from a Measurement Agent to a Collector. It runs over the Report Channel.
Report Schedule ⏰: the schedule for sending Reports to a Collector.
Subscriber 🧾: an entity (associated with one or more users) that has a subscription with a service provider.
Suppression 🤫: the temporary stopping of Measurement Tasks.
4. Constraints 🚧
the LMAP framework makes some big assumptions, and they limit the scope of the initial LMAP work. let's go 👀
4.1. The Measurement System Is Under the Direction of a Single Organisation
in the LMAP framework, one single organisation directs the Measurement System, and that organisation is responsible for any impact its measurements have on a user's quality of experience and privacy. clear responsibility matters a lot 😤 a misbehaving large-scale Measurement System could seriously harm user experience, user privacy, and network security. yikes 💀
that said, the components of an LMAP Measurement System can be deployed in administrative domains that the measuring organisation doesn't own. so the set of functions deployed by a single organisation makes up a single LMAP domain, and that domain can span ownership or other administrative boundaries 🌍
4.2. Each MA May Only Have a Single Controller at Any Point in Time
an MA is instructed by one Controller and belongs to one Measurement System. this avoids different Controllers giving an MA conflicting instructions, so the MA never has to manage contention between multiple Measurement (or Report) Schedules 🙅♀️ this makes MAs simpler to design (which is critical for a large-scale infrastructure), and it lets a Measurement Schedule get tested on specific types of MAs before it's deployed. that way the end-user experience isn't impacted by things like CPU, memory, or broadband-product constraints 🫶 a Measurement System can still have several Controllers, though ✨
5. Protocol Model 🧩
a protocol model [RFC4101] is an architectural model of how the protocol operates. it needs to answer three basic questions:
- What problem is the protocol trying to address?
- What messages are being transmitted and what do they mean?
- What are the important, but not obvious [sic], features of the protocol?
an LMAP system goes through the following phases:
- a Bootstrapping process, before the MA can take part in the other three phases.
- a Control Protocol, which delivers Instruction Messages from a Controller to an MA (amongst other things).
- the actual Measurement Tasks, which measure some performance or reliability Metric(s) linked to the transfer of packets.
- a Report Protocol, which delivers Reports containing the Measurement Results from an MA to a Collector.
the figures show the various LMAP messages, and they use these conventions:
- (optional): indicated by round brackets
- [potentially repeated]: indicated by square brackets
the protocol model is closely related to the Information Model [LMAP-INFO], which is the abstract definition of the information the protocol carries. (if there's any difference between this document and the Information Model, the latter is definitive 👑). both exist to give a protocol- and device-independent view that can be implemented through specific protocols. LMAP defines a specific Control Protocol and Report Protocol, but other standards bodies could define others, or they could be proprietary. still, it's important that they all implement the same Information Model and protocol model. that's how large-scale Measurement Systems stay easy to define, operate, and make interoperable 🌈
5.1. Bootstrapping Process
the main job of Bootstrapping is to let an MA be integrated into a Measurement System. the MA retrieves information about itself (like its identity in the Measurement System) and about the Controller. the Controller learns information about the MA. and they both learn the security information they'll use to communicate, such as certificates and credentials 🔐
this memo does consider the Bootstrapping process, but defining an actual Bootstrap mechanism is beyond the scope of the initial LMAP work, because it depends on the type of device and access 🙃
as a result of Bootstrapping, the MA learns the following information ([LMAP-INFO] defines the matching list of information elements):
- its identifier, either its MA-ID or a device identifier such as one of its Media Access Control (MAC) addresses, or both.
- (optionally) a Group-ID, shared by several MAs. it could be useful for privacy reasons. for instance, reporting the Group-ID and not the MA-ID could stop a mobile device from being tracked 🕶️
- the Control Channel, which is defined by:
- the address that identifies the Control Channel, such as the Controller's FQDN (Fully Qualified Domain Name) [RFC1035]).
- security information (for example, to let the MA decrypt the Instruction Message and encrypt messages sent to the Controller).
the details of Bootstrapping are device- and access-specific. for example, the information could be in the firmware, manually configured, or transferred via a protocol like the one described in TR-069 [TR-069]. there may also be a multi-stage process where the MA contacts a 'hard-coded' address, which replies with the Bootstrapping information 🔁
the MA must learn its MA-ID before getting an Instruction, either during Bootstrapping or via Configuration (Section 5.2.1). that's the handoff, bestie 🦋
5.2. Control Protocol 💖
okay so the Control Protocol is literally the main event 💅 Its whole job is letting the Controller set up a Measurement Agent with an Instruction: which Measurement Tasks to do, when to do them, and how to report the Measurement Results (Section 5.2.2). After that the MA just runs with it autonomously 🦋 The protocol also lets the MA tell the Controller about its Capabilities and any Failure and Logging Information (Section 5.2.3) 🎀 And the Controller can update the MA's Configuration too 🫶
5.2.1. Configuration 🌸
Configuration lets the Controller update the MA about some or all of the info it got during the Bootstrapping process: the MA-ID, the (optional) Group-ID, and the Control Channel ✨ Figure 2 shows the Configuration process. The Measurement System might use Configuration for a few reasons. For example, Bootstrapping could 'hard code' the MA with details of an initial Controller, and then that initial Controller could configure the MA with details about the Controller that actually sends Instruction Messages 💜 (Quick reminder: an MA only has one Control Channel, so it's tied to only one Controller at any given moment 🙈)
Also, an implementation may choose to combine Configuration information and an Instruction Message into a single message 🧚
+-----------------+ +-------------+
| | | Measurement |
| Controller |===================================| Agent |
+-----------------+ +-------------+
Configuration information: ->
(MA-ID),
(Group-ID),
(Control Channel)
<- Response(details)
MA: Measurement Agent
Figure 2: Outline of Configuration5.2.2. Instruction 🍓
The Instruction is the description of the Measurement Tasks for an MA to do, plus the details of the Measurement Reports it should send 💅 Figure 3 shows the Instruction process. To update the Instruction, the Controller uses the Control Protocol to send an Instruction Message over the Control Channel ✨
+-----------------+ +-------------+
| | | Measurement |
| Controller |===================================| Agent |
+-----------------+ +-------------+
Instruction: ->
[(Measurement Task configuration
URI of Metric(
[Input Parameter],
(role)
(interface),
(Cycle-ID)
(measurement point)),
(Report Channel),
(Schedule),
(Suppression information)]
<- Response(details)
Figure 3: Outline of InstructionThe Instruction defines the following info (and [LMAP-INFO] lists the matching information elements) 📝
- the Measurement Task configurations, each of which needs:
- the Metric, specified as a URI pointing to a registry entry. It includes the specification of a Measurement Method. The registry could be defined by a standards organisation, or locally by the operator of the Measurement System. Fun fact: at the time of writing, the IETF is working on such a registry specification [IPPM-REG] 🔥
- the Measurement Method role. For some Measurement Methods, different parties play different roles, like an iperf sender and receiver (see Section 6.4). Each Metric and its associated Measurement Method describes all the measurement roles involved in the process 🫶
- a boolean flag (suppress or do-not-suppress) showing whether that Measurement Task is affected by a Suppression message (see Section 5.2.2.1). So the flag is an Input Parameter 👑
- any Input Parameters that need to be set for the Metric and the Measurement Method. For example, the address of a Measurement Peer (or other Measurement Agent) that might be involved in a Measurement Task, or traffic filters tied to the Observed Traffic Flow 🦋
- the interface to use (if none is defined, the default interface is used), in case the device with the MA has multiple interfaces 🌈
- optionally, a Cycle-ID 🧚
- optionally, the measurement point designation [RFC7398] of the MA and, if applicable, of the MP or other MA. This can be super useful for reporting 📝
- configuration of the Schedules, each of which needs:
- the timing of when the Measurement Tasks are performed or the Measurement Reports are sent. Possible types of timing are periodic, calendar-based periodic, one-off immediate, and one-off at a future time ⭐
- configuration of the Report Channel(s), each of which needs:
- the address of the Collector, for instance its URL 💌
- security for this Report Channel, for example, the X.509 certificate 🔒
- Suppression information, if there is any (see Section 5.2.2.1) 🙈
A single Instruction Message can contain some or all of the parts above. How fine-grained an Instruction Message can get is decided by the implementation and operation of the Control Protocol 🎀 For example, one Instruction Message might add or update a single Measurement Schedule, or it might only update the whole set of Measurement Schedules. One message could update both Measurement Schedules and Measurement Task configurations, or just one of those at a time. BUT here's the big one: Suppression information always replaces any previous Suppression information, it never adds to it 💀
The MA tells the Controller whether it successfully understood the Instruction Message, or whether it can't act on the Instruction. An example of the second case would be if the Instruction is missing a parameter that the requested Metric and Measurement Method need, or if it's missing details of the target Collector 😭
Last but not least, the Instruction Message just instructs the MA. The Control Protocol doesn't let the MA negotiate, because that would add complexity to the MA, the Controller, and the Control Protocol for very little benefit 🍓
5.2.2.1. Suppression 🚫
The Instruction may include Suppression information. The main reason for Suppression is to let the Measurement System eliminate Measurement Traffic, for example because of some unexpected network issue 😬 There are other times Suppression is useful too, like cutting out inessential Reporting traffic even when there's no Measurement Traffic. Figure 4 shows the Suppression process 🦋
The Suppression information may include any of these optional fields:
- a set of Measurement Tasks to suppress, while the others are not suppressed. This could be handy if one Measurement Task is overloading a Measurement Peer with Measurement Traffic 💅
- a set of Measurement Schedules to suppress, while the others are not suppressed. Picture this: the Measurement System has two Schedules, one with the most critical Measurement Tasks and one with less critical tasks that create a ton of Measurement Traffic. It might only want to suppress that second one 🌸
- a set of Reporting Schedules to suppress, while the others are not suppressed. This is especially useful for a Measurement Method that doesn't generate Measurement Traffic. It might still need to keep observing traffic flows but temporarily suppress Reports because of the network footprint of those Reports 📊
- if all the previous fields are included, the MA suppresses the union. In other words, it suppresses the set of Measurement Tasks, the set of Measurement Schedules, and the set of Reporting Schedules 👑
- if the Suppression information includes neither a set of Measurement Tasks nor a set of Measurement Schedules, then the MA doesn't begin new Measurement Tasks whose boolean flag is set to suppress. However, the MA does begin new Measurement Tasks whose flag is set to do-not-suppress ✨
- a start time, at which Suppression begins. If it's absent, Suppression begins immediately ⏰
- an end time, at which Suppression ends. If it's absent, Suppression continues until the MA receives an Un-suppress message 🌙
- a demand that the MA immediately end ongoing Measurement Task(s) that are tagged for Suppression. (Most likely it's appropriate to delete the associated partial Measurement Result(s).) This could be useful in a network emergency, so the operator can eliminate all inessential traffic as fast as possible 🚨 If it's absent, the MA completes the ongoing Measurement Tasks 🫶
An Un-suppress message tells the MA to stop suppressing. That means the MA once again begins new Measurement Tasks, according to its Measurement Schedule 🌈
Okay, real talk: Suppression is not meant to permanently stop a Measurement Task. If you want that, the Controller should send a new Measurement Schedule instead 🙅♀️ It's also not meant to permanently disable an MA. For that, some kind of management action is suggested 🎀
+-----------------+ +-------------+
| | | Measurement |
| Controller |==============================| Agent |
+-----------------+ +-------------+
Suppress:
[(Measurement Task), ->
(Measurement Schedule),
(start time),
(end time),
(on-going suppressed?)]
Un-suppress ->
Figure 4: Outline of Suppression5.2.3. Capabilities, Failure, and Logging Information ✨
Okay so the Control Protocol also lets the MA tell the Controller stuff about itself, like its Capabilities and any Failures 🎀. Figure 5 shows how that works for Capabilities, Failure, and Logging Information. A device-specific mechanism can also be used, but that's outside the scope of the initial LMAP work 💅.
Capabilities are the info the Controller needs to know about the MA so it can instruct it correctly 🧚. That includes:
- the Measurement Method (roles) that the MA supports.
- the measurement protocol types and roles that the MA supports.
- the interfaces that the MA has.
- the version of the MA.
- the version of the hardware, firmware, or software of the device with the MA.
- its Instruction (this could be useful if the Controller thinks something has gone wrong and wants to check what Instruction the MA is using) 👀.
- but not dynamic information like the currently unused CPU, memory, or battery life of the device with the MA 🙅♀️.
Failure Information is all about why the MA couldn't run a Measurement Task or deliver a Report 😭. For example:
- the Measurement Task failed to run properly because the MA (unexpectedly) has no spare CPU cycles.
- the MA failed to record the Measurement Results because it (unexpectedly) is out of spare memory.
- a Report failed to deliver Measurement Results because the Collector (unexpectedly) is not responding.
- but not if a Measurement Task correctly doesn't start. For example, the first step of some Measurement Methods is for the MA to check that there is no cross-traffic 🙈.
Logging Information is about how the MA is operating, and it can really help with debugging 🔍. For example:
- the last time the MA ran a Measurement Task.
- the last time the MA sent a Measurement Report.
- the last time the MA received an Instruction Message.
- whether the MA is currently suppressing Measurement Tasks.
So Capabilities, Failure, and Logging Information get sent by the MA, either because the Controller asked for them (like if the Controller forgets what the MA can do, or just wants to resynchronise what it knows about the MA 🔄), or because the MA decided to send them on its own (like when it first talks to a Controller, or when it suddenly becomes capable of a new Measurement Method 🌟). Another example of the on-its-own case: if the device with the MA re-boots, the MA should notify its Controller in case its Instruction needs updating. Now, to avoid a "mass calling event" after a widespread power restoration hits lots of MAs at once 😱, it's sensible for an MA to pause for a random delay, perhaps in the range of one minute or so. Iconic behaviour, honestly 💖.
+-----------------+ +-------------+
| | | Measurement |
| Controller |==================================| Agent |
+-----------------+ +-------------+
(Request Capabilities),
(Request Failure Information),
(Request Logging Information),
(Request Instruction) ->
<- (Capabilities),
(Failure Information),
(Logging Information),
(Instruction)Figure 5: Outline of Capabilities, Failure, and Logging Information
5.3. Operation of Measurement Tasks 🎀
This LMAP framework doesn't care what the actual Measurement Task is 🤷♀️. It doesn't define Metrics and Measurement Methods either, because those are defined elsewhere.
The MA carries out the Measurement Tasks as instructed, unless it gets an updated Instruction. The MA acts autonomously when it comes to running the Measurement Tasks and reporting the Results. It doesn't do a 'safety check' with the Controller to ask whether it should still keep going with the requested Measurement Tasks. Main character energy, no cap 👑.
The MA may run Measurement Tasks sequentially or in parallel (see Section 5.3.2) ✨.
5.3.1. Starting and Stopping Measurement Tasks
This LMAP framework doesn't define a generic start and stop process, since the right approach depends on the particular Measurement Task. The details get defined as part of each Measurement Method. This section just gives some general hints 💡. The MA doesn't tell the Controller when Measurement Tasks start or stop.
Before starting a Measurement Task, the MA may want to run a pre-check. (The pre-check could be its own separate Task that comes before, or the first part of a bigger Task 🧩.)
For Measurement Tasks that observe existing traffic, the action could include:
- checking that there is traffic of interest.
- checking that the device with the MA has enough resources to execute the Measurement Task reliably. Note that the designer of the Measurement System should make sure the device's resources are normally enough to comfortably run the Measurement Tasks 💪.
For Measurement Tasks that generate Measurement Traffic, a pre-check could include:
- the MA checking that there is no cross-traffic. In other words, checking that the end-user isn't already sending traffic 🙋♀️.
- the MA checking with the Measurement Peer (or other Measurement Agent) involved in the Measurement Task that it can handle a new Measurement Task. For example, the Measurement Peer may already be handling lots of Measurement Tasks with other MAs 🙃.
- sending traffic that probes the path to check it isn't overloaded.
- checking that the device with the MA has enough resources to execute the Measurement Task reliably.
Similar checks may keep happening during the Measurement Task, especially for one that's long-running and/or creates a lot of Measurement Traffic ⏳. If the check spots that the end-user has started sending traffic, the Measurement Task can be abandoned. A Measurement Task could also be abandoned because of a "suppress" message (see Section 5.2.2.1) 🛑. The action could include:
- for 'upload' tests, the MA not sending traffic.
- for 'download' tests, the MA closing the TCP connection or sending a TWAMP (Two-Way Active Measurement Protocol) Stop-Sessions command [RFC5357].
The Controller might want an MA to run the same Measurement Task forever (like "run the 'upload speed' Measurement Task once an hour until further notice" 🔁). But what if the Controller has permanently failed, or communications with it have broken down? Then the MA could keep generating traffic nonstop 😬. To stop that, the MA can be configured with a time limit. If the MA doesn't hear from the Controller for that long, it stops operating Measurement Tasks. Safety first, bestie 🫶.
5.3.2. Overlapping Measurement Tasks
An MA may start a new Measurement Task before another one has finished 🌀. This might be on purpose (that's just how the Measurement System designed its Measurement Schedules), but it could also happen by accident. For instance, a Measurement Task might have a 'wait for X' step that pauses for way longer than expected 😅. This document makes no assumptions about how one Measurement Task affects another.
The operator of the Measurement System can handle overlapping Measurement Tasks however they like, or not handle them at all 🤍. That's a policy or implementation issue, and it isn't LMAP's concern. A few possible approaches: configure the MA to not begin the second Measurement Task; start the second Measurement Task as usual; make the action an Input Parameter of the Measurement Task; and so on 🧠.
It may be important for the Measurement Report to say that the Measurement Tasks overlapped 📝.
5.4. Report Protocol 📬
The main job of the Report Protocol is to let a Measurement Agent report its Measurement Results to a Collector, along with the context they were obtained in 🦋. Figure 6 shows how the Report process goes.
+-----------------+ +-------------+
| | | Measurement |
| Collector |==================================| Agent |
+-----------------+ +-------------+
<- Report:
[MA-ID &/or Group-ID],
[Measurement Result],
[details of Measurement Task],
(Cycle-ID)
ACK ->
MA: Measurement Agent
Figure 6: Outline of the ReportThe Report contains:
- the MA-ID or a Group-ID (to anonymise results) 🕶️.
- the actual Measurement Results, including the time they were measured. In general, the time is just the MA's best estimate, and there's no guarantee on how accurate or granular the information is. Some specific analysis of a particular Measurement Method's Results might impose timing requirements, though ⏱️.
- the details of the Measurement Task (so the Collector doesn't have to ask the Controller for this info later), for example, the interface used for the measurements 🔌.
- the Cycle-ID, if one was included in the Instruction 🔄.
- perhaps the Subscriber's service parameters (see Section 5.4.1) 📶.
- the measurement point designation of the MA and, if applicable, the MP or other MA, if that info was included in the Instruction. This numbering system is defined in [RFC7398] and lets a Measurement Report describe the path measured in an abstract way (for example, "from a measurement agent at a home gateway to a measurement peer at a DSLAM") 🗺️. Also, the MA can anonymise results by including measurement point designations instead of IP addresses (Section 8.6.2) 🙈.
The MA sends Reports as defined by the Instruction. The Instruction may tell the MA to report the same Results to more than one Collector, or to report a different subset of Results to different Collectors 📤. Also, one Measurement Task might create two (or more) Measurement Results, and those could be reported differently. For example, one Result could be reported periodically, while the second Result could be an alarm that gets created as soon as the measured value of the Metric crosses a threshold, and that gets reported right away 🚨.
Optionally, a Report is not sent when there are no Measurement Results 🫥.
In the initial LMAP Information Model and Report Protocol, we keep things simple and assume that all Measurement Results are reported as-is. But it allows for extensibility, so that a Measurement System (or maybe a second phase of LMAP) could let an MA do the following 🧩:
- label, or perhaps not include, Measurement Results impacted by, for instance, cross-traffic or a Measurement Peer (or other Measurement Agent) being busy.
- label Measurement Results obtained by a Measurement Task that overlapped with another.
- not report the Measurement Results if the MA believes they are invalid.
- detail when Suppression started and ended.
As discussed in Section 6.1, data analysis of the Results should carefully consider potential bias from any Measurement Results that aren't reported, or from Measurement Results that are reported but may be invalid 🔍✨.
5.4.1. Reporting of the Subscriber's Service Parameters 💖
okay so the Subscriber's service parameters are the deets about their broadband contract, line rate, and all that jazz 📋✨ and honestly this info is super useful when it's time to analyse the Measurement Results. like, it helps you figure out if a download speed is actually reasonable or if the ISP is being sus 🙈
the info could go straight from the Subscriber parameter database over to the data analysis tools 🧚. or, if the MAs can access the Subscriber's service parameters, they could be reported along with the Measurement Results in the Report Protocol 💅. whether (and how) an MA knows this stuff totally depends on the device type 🎀. the MA could include it in a Measurement Report, or send it separately 🫶
5.5. Operation of LMAP over the Underlying Packet Transfer Mechanism 🦋
so far we've been talking about LMAP's protocol model 👑. the actual Control and Report Protocols get defined in other specs, and they might run on top of something that already exists, like REST-style [REST] HTTP(S) 🌈. or they could go a totally different route, like NETCONF-YANG [RFC6241] for Control and IPFIX (Internet Protocol Flow Information Export) [RFC7011] for Reports 🍓
from the LMAP side, the Controller needs to know whether the MA actually got the Instruction Message, or at least whether it needs to be re-sent because delivery might have failed 😭. the MA needs the same kind of confirmation for Capabilities, Failure, and Logging Information going to the Controller, and for Reports going to the Collector 🫶. how that gets handled depends on how the Control and Report Protocols are designed, plus whatever packet transfer mechanism is underneath 💅
for the Control Protocol, the underlying transfer mechanism could be:
- a 'push' protocol (basically, from the Controller to the MA) 🚀
- a multicast protocol (from the Controller to a group of MAs) 📣
- a 'pull' protocol 🦋. the MA periodically checks in with the Controller to see if the Instruction has changed, and grabs a new one if it has. pull seems really attractive for an MA sitting behind a NAT or firewall (which is super typical for an MA on an end-user's device) because the MA can start the conversation itself 🙈. it also seems great for an MA on a mobile device, where the Controller might not even know how to reach it 📱. a pull mechanism will probably need the MA to be configured with how often it should check in, and maybe what to do if the Controller can't be reached after a certain number of tries ⏰
- a hybrid protocol ✨. on top of pull, the Controller can also push an alert telling the MA to immediately pull a new Instruction 🔥
for the Report Protocol, the underlying transfer mechanism could be:
- a 'push' protocol (from the MA to the Collector) 💌
- perhaps with an added ability for the Collector to 'pull' Measurement Results from an MA 🧚
5.6. Items beyond the Scope of the Initial LMAP Work 🌸
okay this is the part where we list the stuff that's just not in the initial LMAP work, no drama 🙃. there are several potential interactions between LMAP elements that are beyond scope, and they go like this:
- it does not define a coordination process between MAs. a Measurement System might coordinate Measurement Schedules across its MAs, but there's no direct coordination between the MAs themselves 🤝
- it does not define interactions between the Collector and Controller. honestly there's probably going to be some, maybe run through the data analysis tools 👑. like, if there's an "interesting" Measurement Result, the Measurement System might want to trigger extra Measurement Tasks to dig into the potential cause 🔍. or if the Collector unexpectedly stops hearing from an MA, the Measurement System might want the Controller to send a fresh Instruction Message to that MA 📨
- it does not define coordination between different Measurement Systems 🌍. so it doesn't cover an MA in one Measurement System talking to a Controller or Collector in a different one. the Control and Report Protocols could probably be reused or adapted for that, but any coordination between different organisations comes with messy commercial and technical issues 💀. and since large-scale measurement is still pretty new, any inter-organisation coordination is out of scope for the initial LMAP work 🙅♀️. just a reminder: a single MA is instructed by a single Controller and is only in one Measurement System 💜
- an interesting scenario is a home with two independent MAs, say one controlled by a regulator and one controlled by an ISP 🏠. in that case, the Measurement Traffic from one MA gets treated by the other MA just like any other end-user traffic 🫠
- it does not consider how to stop a malicious party from "gaming the system" 😤. for example, if a regulator runs a Measurement System to benchmark operators, a shady operator could try to figure out which broadband lines the regulator is measuring and then prioritise that traffic 👀. this is assumed to be a policy issue, and would be handled through something like a code of conduct 📜
- it does not define how to analyse Measurement Results, including how to interpret missing Results 🤷♀️
- it does not specifically define an end-user-controlled Measurement System, see Section 5.6.1 🎀
5.6.1. End-User-Controlled Measurement System 🦋
this framework mostly focuses on cases where an ISP or a regulator runs the Measurement System 💼. but we expect LMAP functionality to also show up in an end-user-controlled Measurement System 🙌. there are at least two ways this could happen, and they each have their own pros and cons ⚖️
- an end-user could ask the ISP-run (or regulator-run) Measurement System to test their line. the ISP (or regulator) Controller would then send an Instruction to the MA in the usual LMAP way 📬
- an end-user could deploy their own Measurement System, with their own MA, Controller, and Collector 👩💻. for example, the user could put all three functions on the same end-user-owned end device, maybe by downloading them from the ISP or regulator 📲. in that case the LMAP Control and Report Protocols don't need to be used, but using LMAP's Information Model would still be beneficial 💅. a Measurement Peer (or another MA involved in a Measurement Task) could sit in the home gateway or outside the home network 🏡. if it's outside, the Measurement Peer is highly likely to be run by a different organisation, which brings up extra privacy considerations 🔐
in both cases, there has to be some way for the end-user to kick off the Measurement Task(s) 👆. the mechanism is outside the scope of the initial LMAP work, but it could be something like clicking a button on a GUI or sending a text message 💬. presumably the user will also be able to see the Measurement Results, maybe summarised on a webpage 📊. it's suggested that these interfaces follow the LMAP guidance on privacy in Section 8 🔒
6. Deployment Considerations 🧚
6.1. Controller and the Measurement System 👑
hot take: the Controller should really understand both the MA's LMAP Capabilities (like which Metrics and Measurement Methods it can run) and its other capabilities, like processing power and memory 🧠. this lets the Controller make sure the Measurement Schedule of Measurement Tasks and the Reporting Schedule actually make sense for each MA it instructs 📅
an Instruction is likely to include several Measurement Tasks 📝. usually they run at different times, but they can also run at the same time ⏱️. some Tasks are compatible, meaning they don't affect each other's Results, while others need really careful handling 🧐. some Tasks can also be complementary 🤝. for example, one Task might be followed by a traceroute Task to the same destination address, so you can learn the network path that was measured 🗺️
the Controller should make sure Measurement Tasks don't have an adverse effect on the end user 🙏. Tasks that generate a lot of Measurement Traffic will often include a pre-check that the user isn't already sending traffic (Section 5.3.1) 🚦. another thing to think about is whether Measurement Traffic will affect a Subscriber's bill or traffic cap 💸
a Measurement System may have multiple Controllers (but remember the overriding principle that a single MA is instructed by a single Controller at any point in time (Section 4.2)) ☝️. for example, there could be different Controllers for different types of MA (like home gateways or tablets), or for different locations (like Ipswich, Edinburgh, or Paris) 🗺️. they might be split up for load balancing, or so the system can cope if one Controller fails 🛟
the measurement system also needs to think carefully about how to interpret missing Results 🤔. the right interpretation depends on why the Results are missing (it could be related to measurement Suppression or a delayed Report submission), and potentially on the specifics of the Measurement Task and Measurement Schedule 🧩. for example, an Observed Traffic Flow may be empty, but the Measurement Report may still be sent according to the Report Schedule 📤
6.2. Measurement Agent 🦋
the MA should be careful about picking Measurement Tasks back up if it reboots or has been offline for a while, because its Instruction might be stale 🙈. if it rebooted, it also needs to make sure its clock reset correctly, so it reads the Schedule right ⏰
if the MA runs out of storage for Measurement Results, or can't contact the Controller, the right action depends on the device and the Measurement System 🤷♀️
the Measurement Agent could take a bunch of different forms 🌈. for example, an MA could be a dedicated probe or software on a PC, or it could be embedded in an appliance or even in a gateway 🖥️. a single site (like a home or branch office) taking part in a measurement could use one or multiple Measurement Agents or Measurement Peers in that measurement 🏢
the Measurement Agent can be deployed in a variety of locations 📍. not every deployment location is available to every kind of Measurement Agent, and there are also limitations and trade-offs depending on where it ends up 🫤. the next sections outline some of the locations an MA may be deployed. this isn't an exhaustive list, and combinations may apply too ✨
6.2.1. Measurement Agent on a Networked Device 📱
an MA may be embedded on a device that's directly connected to the network, like an MA on a smartphone 📲. other examples include an MA downloaded and installed on a subscriber's laptop or tablet when the network service is provided over wired connections or other wireless radio technologies, like Wi-Fi 💻✨
6.2.2. Measurement Agent Embedded in a Site Gateway
Okay so one of the best spots for the Measurement Agent is inside the site gateway 🏠, like a home router or the edge router of a branch office in a managed service setup. All the site-to-ISP traffic goes right through it, so Measurement Methods that measure user traffic can easily happen 👀. That same user traffic visibility means a Measurement Method that generates Measurement Traffic can make sure it doesn't compete with user traffic 💅. Gateways usually come with NAT and firewall services built in, so the MA gets to choose whether to put its Controller-facing management interface outside the NAT/firewall 🛡️. That placement lets the Controller unilaterally contact the MA with Instructions ✨. BUT ngl, an MA on a site gateway (whether it's end-user owned or service-provider owned) generally won't be directly reachable by over-the-top providers, the regulator, end users, or enterprises 😬.
6.2.3. Measurement Agent Embedded behind a Site NAT or Firewall
The Measurement Agent could also be tucked behind a NAT, a firewall, or both 🧱. In that situation, the Controller might not be able to unilaterally contact the MA unless static port forwarding or firewall pin holing is set up 🙅♀️. Port forwarding can be configured with stuff like the Port Control Protocol [RFC6887], the CPE WAN Management Protocol [TR-069], or Universal Plug and Play [UPnP] 🔧. To open a pin hole in the firewall, the MA could send keepalives towards the Controller, and maybe use those as a network reachability test too 🕳️✨.
6.2.4. Multihomed Measurement Agent
If the device with the Measurement Agent is single homed, there's no confusion about which interface to measure 🙌. Same goes for an MA at the gateway when the gateway only has one WAN-side and one LAN-side interface. For Measurement Methods that generate Measurement Traffic, the location of the other MA or Measurement Peer decides whether the WAN or the LAN gets measured 🧭.
BUT the device with the Measurement Agent might be multihomed 🌀. Picture a home or campus connected to several broadband ISPs, like a wired provider and a wireless one, maybe for redundancy or load sharing. It also helps to think of dual stack IPv4 and IPv6 broadband devices as multihomed 💜. Section 3.2 of [RFC7368] goes through the dual-stack and multihoming topologies you could run into at home, [RFC6419] covers the current practices for multi-interface hosts, and the Multiple Interfaces (mif) working group looks at cases where hosts are attached directly (physical or virtual) or indirectly (like multiple default routers) to multiple networks 📡. In all of these, it has to be clear which network connectivity option is being measured 🎯.
One option is to have a Measurement Agent per interface, so the Controller's pick of MA decides which interface gets measured 🎀. But if one MA can measure any of the interfaces, the Controller spells out in the Instruction which interface the MA should use for a Measurement Task 📝. If the interface isn't defined, the MA just uses the default one 🤷♀️. Being explicit is preferred when the Measurement System wants to measure the performance of one particular network 🔍. Using the default is better when the Measurement System wants to include the impact of the MA's interface selection algorithm 🧠. Either way, the Measurement Result should include the network that was measured 💖.
6.2.5. Measurement Agent Embedded in an ISP Network
An MA can live on a device that's part of an ISP's network, like a router or switch 🛰️. The network devices with an embedded MA are usually in strategic spots, like a Carrier-Grade NAT or an ISP Gateway 🗺️. [RFC7398] has lots of examples of where an MA might sit within a network to act as an intermediate measurement point on the end-to-end path 🧩. Another example is a network device whose main job is hosting MA functions and the necessary measurement protocol 🫶.
6.3. Measurement Peer
A Measurement Peer joins in on some Measurement Methods 🤝. It might have special functionality that lets it take part in a particular Measurement Method ✨. Other Measurement Methods don't need any special functionality at all 🌸. For example, if the Measurement Agent pings example.com, then the server at example.com is playing the role of a Measurement Peer 🏓. Or if the MA is just monitoring existing traffic, then the existing endpoints are the Measurement Peers 👀.
A device can be a Measurement Agent for some Measurement Methods and a Measurement Peer for others 🔄.
Measurement Schedules should account for limited resources in a Measurement Peer when they tell an MA to run measurements with that Measurement Peer 🧮. Some measurement protocols, like [RFC4656] and [RFC5357], let the Measurement Peer turn down a measurement session or refuse a control connection before a measurement session is even set up 🚫. That way it can protect itself from resource exhaustion 🛡️. This is a seriously valuable capability, bestie, because the MP may be used by more than one organisation 👑.
6.4. Deployment Examples ✨
okay so this section is all about the deployment scenarios that totally work inside the LMAP framework 🎀 let's gooo
A super simple example of a Measurement Peer (MP) is a web server that the MA downloads a web page from (like www.example.com) to run a speed test 💅 The web server is the MP, and from its point of view the MA is just another client. The MP doesn't have any special measurement feature, it's just vibing 🌸 Figure 7 shows this:
^
+------------------+ web traffic +----------------+ non-LMAP
| web client |<------------>| web server | Scope
| | +----------------+ |
...|..................|....................................V...
|MA:LMAP interface | <MP> ^
+------------------+ |
^ | |
Instruction | | Report |
| +-----------------+ |
| | |
| v LMAP
+------------+ +------------+ Scope
| Controller | | Collector | |
+------------+ +------------+ V
MA: Measurement Agent
MP: Measurement Peer
Figure 7: LMAP deployment example, with Web server as Measurement
PeerAnother MP is a TWAMP Server and TWAMP Session-Reflector 🦋 It gets deployed to help MAs that run TWAMP tests, where the MA is co-located with the TWAMP Control-Client and Session-Sender. And the ping server from Section 2 is another example, where the Measurement Peer is a ping server 🧚
A further example is traceroute-like measurement 🙈 Here, for each packet sent, the router where the TTL expires is the one doing the MP function. So for one Measurement Task there's one MA involved and several MPs, one per hop. iykyk 😭
In Figure 8 we see an OWAMP (One-Way Active Measurement Protocol) Server and Session-Receiver acting as an MP 💖 The OWAMP Server sends results back to the OWAMP Fetch-Client, so the MP handles both control-plane and data-plane communications with its OWAMP counterparts that are co-located with the MA.
+------------------+ OWAMP +-----------------+ ^
| OWAMP |<--control--->| | |
| control-client |-test-traffic>| OWAMP server & | non-LMAP
| fetch-client & |<----fetch----| session-receiver| Scope
| session-sender | | | |
| | +-----------------+ |
...|..................|.....................................v...
|MA:LMAP interface | <MP> ^
+------------------+ |
^ | |
Instruction | | Report |
| +-----------------+ |
| | |
| v LMAP
+------------+ +------------+ Scope
| Controller | | Collector | |
+------------+ +------------+ v
MA: Measurement Agent
MP: Measurement Peer
Figure 8: LMAP deployment example, with OWAMP server as Measurement
PeerHowever, it's also possible to use two Measurement Agents when doing one-way Measurement Tasks, as shown in Figure 9 🔥 Both MAs are instructed by the Controller: MA-1 sends the traffic, and MA-2 measures the received traffic and sends Reports to the Collector. Also, the Measurement Task at MA-2 can listen for traffic from MA-1 and respond multiple times without having to be rescheduled, which is so iconic 👑
+----------------+ +-------------------+ ^
| | | | non-LMAP
| iperf -u sender|-UDP traffic->| iperf -u receiver | Scope
| | | | v
...|................|..............|...................|........
| MA-1: | | MA-2: | ^
| LMAP interface | | LMAP interface | |
+----------------+ +-------------------+ |
^ ^ | |
Instruction | Instruction{Report} | | Report |
{Task, | +-------------------+ | |
Schedule} | | | |
| | v LMAP
+------------+ +------------+ Scope
| Controller | | Collector | |
+------------+ +------------+ v
MA: Measurement Agent
Figure 9: Schematic of LMAP-based Measurement System, with two
Measurement Agents cooperating to measure UDP trafficNext up are Measurement Methods that meter the Observed Traffic Flow 🌈 Traffic is generated at one point in the network and flows toward a given destination, and it gets observed at some point along the path. One way to do this is for the endpoints that generate and receive the traffic to not be instructed by the Controller, which makes them MPs. The MA sits along the path with a monitor function that measures the traffic. The Controller instructs the MA to monitor that particular traffic and to send the Report to the Collector. Figure 10 has the whole picture 🧚
+--------+ +------------------+ +--------+ ^
|End user| | monitor | Observed |End user| |
| |<--|------------------|--Traffic-->| | non-LMAP
| | | | Flow | | Scope
+--------+ | | +--------+ |
............|..................|............................v..
<MP> |MA:LMAP interface | <MP> ^
+------------------+ |
^ | |
Instruction | | Report |
| +-----------------+ |
| | |
| v LMAP
+------------+ +------------+ Scope
| Controller | | Collector | |
+------------+ +------------+ v
MA: Measurement Agent
MP: Measurement Peer
Figure 10: LMAP deployment example, with a Measurement Agent
monitoring traffic7. Security Considerations 🔐
Okay, security is literally the whole vibe here 🫶 The LMAP framework should protect the interests of the measurement operator(s), the network user(s), and other actors who could be impacted by a compromised measurement deployment. The Measurement System must secure the various components of the system from unauthorised access or corruption. Much of the general advice contained in Section 6 of [RFC4656] is applicable here 💅
The process to upgrade the firmware in an MA is outside the scope of the initial LMAP work, just as is the protocol to Bootstrap the MAs. However, systems that provide remote upgrades must secure authorised access and integrity of the process 🔧
We assume that each Measurement Agent (MA) will receive its Instructions from a single organisation, which operates the Controller. These Instructions must be authenticated (to ensure that they come from the trusted Controller), checked for integrity (to ensure no one has tampered with them), and not vulnerable to replay attacks 🔒 If a malicious party can gain control of the MA, they can use it to launch denial-of-service (DoS) attacks at targets, create a platform for pervasive monitoring [RFC7258], reduce the end-user's quality of experience, and corrupt the Measurement Results that are reported to the Collector 😭 By altering the Measurement Tasks and/or the address that Results are reported to, they can also compromise the confidentiality of the network user and the MA environment (such as information about the location of devices or their traffic). The Instruction Messages also need to be encrypted to maintain confidentiality, as the information might be useful to an attacker 🕵️♀️
Honestly, this is the part where a compromised MA becomes a real problem for everyone, so the locks matter. 🔐
Reporting by the MA must be encrypted to maintain confidentiality, so that only the authorised Collector can decrypt the results to prevent the leakage of confidential or private information 🎀 Reporting must also be authenticated (to ensure that it comes from a trusted MA and that the MA reports to a genuine Collector) and not vulnerable to tampering (which can be ensured through integrity and replay checks). It must not be possible to fool an MA into injecting falsified data, and the results must also be held and processed securely after collection and analysis 🧼 See Section 8.5.2 for additional considerations on stored data compromise, and Section 8.6 on potential mitigations for compromise 🦋
Since Collectors will be contacted repeatedly by MAs using the Report Protocol to convey their recent results, a successful attack to exhaust the communication resources would prevent a critical operation: reporting. Therefore, all LMAP Collectors should implement technical mechanisms to:
- limit the number of reporting connections from a single MA (simultaneous and established in some time period).
- limit the transmission rate from a single MA.
- limit the memory/storage consumed by a single MA's reports.
- efficiently reject reporting connections from unknown sources.
- separate resources if multiple authentication strengths are used, where the resources should be separated according to each class of strength.
A corrupted MA could report falsified information to the Collector. Whether this can be effectively mitigated depends on the platform on which the MA is deployed. However, where the MA is deployed on a customer-controlled device, then the reported data is to some degree inherently untrustworthy 🙈 Further, a sophisticated party could distort some Measurement Methods, perhaps by dropping or delaying packets for example. This suggests that the network operator should be cautious about relying on Measurement Results for action such as refunding fees if a service level agreement is not met 💀
As part of the protocol design, it will be decided how LMAP operates over the underlying protocol (Section 5.5). The choice raises various security issues, such as how to operate through a NAT and how to protect the Controller and Collector from DoS attacks 🌸
The security mechanisms described above may not be strictly necessary if the network's design ensures the LMAP components and their communications are already secured, for example potentially if they are all part of an ISP's dedicated management network ✨
Finally, there are three other issues related to security: privacy (considered in Section 8), availability, and "gaming the system". While the loss of some MAs may not be considered critical, the unavailability of the Collector could mean that valuable business data or data critical to a regulatory process is lost. Similarly, the unavailability of a Controller could mean that the MAs do not operate a correct Measurement Schedule 😩
A malicious party could "game the system". For example, where a regulator is running a Measurement System in order to benchmark operators, an operator could try to identify the broadband lines that the regulator was measuring and prioritise that traffic. Normally, this potential issue is handled by a code of conduct. It is outside the scope of the initial LMAP work to consider the issue 👑
8. Privacy Considerations 🌈
The LMAP work considers privacy a core requirement and will ensure that by default the Control and Report Protocols operate in a privacy-sensitive manner and that privacy features are well defined 💜
This section provides a set of privacy considerations for LMAP. This section benefits greatly from the publication of [RFC6973]. Privacy and security (Section 7) are related. In some jurisdictions, privacy is called data protection 🧚
We begin with a set of assumptions related to protecting the sensitive information of individuals and organisations participating in LMAP-orchestrated measurement and data collection 🫶
8.1. Categories of Entities with Information of Interest
LMAP protocols need to protect the sensitive information of the following entities, including individuals and organisations who participate in measurement and collection of results.
- Individual Internet users: Persons who utilise Internet access services for communications tasks, according to the terms of service of a service agreement. Such persons may be a service Subscriber, or have been given permission by the Subscriber to use the service.
- Internet service providers: Organisations that offer Internet access service subscriptions, and thus have access to sensitive information of individuals who choose to use the service. These organisations desire to protect their Subscribers and their own sensitive information, which may be stored in the process of performing Measurement Tasks and collecting Results.
- Regulators: Public authorities responsible for exercising supervision of the electronic communications sector, and which may have access to sensitive information of individuals who participate in a measurement campaign. Similarly, regulators desire to protect the participants and their own sensitive information.
- Other LMAP system operators: Organisations who operate Measurement Systems or participate in measurements in some way.
Although privacy is a protection extended to individuals, we discuss data protection by ISPs and other LMAP system operators in this section. These organisations have sensitive information involved in the LMAP system, and many of the same dangers and mitigations are applicable. Further, the ISPs store information on their Subscribers beyond that used in the LMAP system (for example, billing information), and there should be a benefit in considering all the needs and potential solutions coherently 📚
8.2. Examples of Sensitive Information
This section gives examples of sensitive information that may be measured or stored in a Measurement System, and that is to be kept private by default in the LMAP core protocols 🙈
Examples of Subscriber or authorised Internet user sensitive information:
- Sub-IP-layer addresses and names (MAC address, base station ID, SSID)
- IP address in use
- Personal Identification (real name)
- Location (street address, city)
- Subscribed service parameters
- Contents of traffic (activity, DNS queries, destinations, equipment types, account info for other services, etc.)
- Status as a study volunteer and Schedule of Measurement Tasks
Examples of Internet Service Provider sensitive information:
- Measurement device identification (equipment ID and IP address)
- Measurement Instructions (choice of measurements)
- Measurement Results (some may be shared, others may be private)
- Measurement Schedule (exact times)
- Network topology (locations, connectivity, redundancy)
- Subscriber billing information, and any of the above Subscriber information known to the provider.
- Authentication credentials (such as certificates)
Other organisations will have some combination of the lists above. The LMAP system would not typically expose all of the information above, but could expose a combination of items that could be correlated with other pieces collected by an attacker (as discussed in Section 8.5 on Threats) 🕵️♀️
8.3. Different Privacy Issues Raised by Different Sorts of Measurement Methods
Measurement Methods raise different privacy issues depending on whether they measure traffic created specifically for that purpose or whether they measure user traffic 🦋
Measurement Tasks conducted on user traffic store sensitive information, however briefly this storage may be. We note that some authorities make a distinction on time of storage, and information that is kept only temporarily to perform a communications function is not subject to regulation (for example, active queue management, deep packet inspection). Such Measurement Tasks could reveal all the websites a Subscriber visits and the applications and/or services they use. This issue is not specific to LMAP. For instance, IPFIX has discussed similar issues (see Section 11.8 of [RFC7011]), but mitigations described in the sections below were considered beyond their scope 😬
In contrast to Measurement Tasks conducted on user traffic, other Measurement Tasks use traffic which is created specifically for the purpose of measurement. Even if a user host generates Measurement Traffic, there is limited sensitive information about the Subscriber present and stored in the Measurement System:
- IP address in use (and possibly sub-IP addresses and names)
- Status as a study volunteer and Schedule of Measurement Tasks
On the other hand, for a service provider, the sensitive information like Measurement Results is the same for all Measurement Tasks 💅
From the Subscriber perspective, both types of Measurement Tasks potentially expose the description of Internet access service and specific service parameters, such as the Subscriber rate and type of access 🌸
8.4. Privacy Analysis of the Communication Models 🔍
okay so this section goes through each of the protocol exchanges from Section 5 (go check it, it's giving architecture) plus some example Measurement Tasks. it figures out exactly which sensitive info needs locking down while it's in transit for each case 🔒 once we've got the protocol-related sensitive info identified, the threats in the next section hit way harder 💀
from the privacy angle, every entity taking part in LMAP protocols counts as an "observer" under the definition in [RFC6973] 👀 their stored info can be a privacy risk, especially if one or more of these functional entities gets compromised. and all the devices on the paths used for control, reporting, and measurement are observers too 🫣
8.4.1. MA Bootstrapping 🥾
Section 5.1 has the communication model for the Bootstrapping process.
ok, so the specifics of Bootstrapping mechanisms are out of scope for the initial LMAP work, but designers need to clock that Bootstrapping is extremely powerful 😤 it could make an MA join a brand new LMAP system with a different Controller and Collector, or just install new Metrics with associated Measurement Methods (for example, to record DNS queries). a Bootstrap attack could lead to a breach of the whole LMAP system with major sensitive info exposure, depending on what the MA can do. so sufficient security protections are warranted, no debate 🛡️
the Bootstrapping process gives away sensitive info about the LMAP system and the organisation running it, such as:
- the MA's identifier (MA-ID)
- the address that identifies the Control Channel, such as the Controller's FQDN
- Security information for the Control Channel
during the Bootstrap process for an MA sitting at a single Subscriber's service demarcation point, the MA gets an MA-ID, which is a persistent pseudonym for the Subscriber. so the MA-ID counts as sensitive info, because it could be the link between Subscriber identification and Measurement Results 🔗
also, the Bootstrap process could assign a Group-ID to the MA. what exactly goes in a Group-ID is still to be determined, but a few examples are envisaged: a pseudonym for a set of Subscribers, a class of service, an access technology, or other important categories 🧩 assigning a Group-ID lets anonymisation sets get formed based on service type, grade, or rates. so the mapping between Group-ID and MA-ID is considered sensitive info too ✨
8.4.2. Controller <-> Measurement Agent 🎛️
the high-level communication model for interactions between the LMAP Controller and Measurement Agent is illustrated in Section 5.2. the main point of this exchange is to authenticate and task a Measurement Agent with Measurement Instructions, which the Measurement Agent then acts on by itself 🤖
mostly, IP addresses and pseudonyms (MA-ID, Group-ID) get swapped during a capability request, then measurement-related info of interest like the parameters, schedule, metrics, and IP addresses of measurement devices. so the Measurement Instruction carries sensitive info that has to be secured 🔐 for example, the fact that an ISP is running extra measurements beyond the set reported externally is sensitive, and so are the additional Measurement Tasks themselves 👀 the Measurement Schedule is sensitive as well, because an attacker who wants to bias the results without getting caught could use it to great advantage 😈
an organisation running the Controller that has no service relationship with a user hosting the Measurement Agent could gain a real-name mapping to a public IP address, just from that user taking part in an LMAP system. this applies to the Measurement Collection protocol too, so keep an eye on it 👁️
8.4.3. Collector <-> Measurement Agent 📦
the high-level communication model for interactions between the Measurement Agent and Collector is illustrated in Section 5.4. the main job of this exchange is to authenticate and collect Measurement Results from an MA, which the MA measured autonomously and then stored 📊
the Measurement Results are the extra sensitive info in the Collector-MA exchange. organisations that collect LMAP measurements are responsible for data control, so the Results and any other info communicated in the Collector protocol must be secured 🫶
8.4.4. Measurement Peer <-> Measurement Agent 🤝
a Measurement Method that involves Measurement Traffic brings up potential privacy issues 🫣 the specifics of the mechanisms are beyond the scope of the initial LMAP work, but the figure below shows the various exchanges needed to run such a Measurement Method and store the Results.
we flag the potential for extra observers in the figures below by showing a possible NAT, which matters a lot for the protocols and for which direction initiates the connection 🚦
the various messages are optional, depending on the nature of the Measurement Method. Measurement Traffic might go from the Measurement Peer to the MA, from the MA to the Measurement Peer, or both ways. a second (or more) MAs could also be involved. (Note: For simplicity, Figure 11 and the description don't show the non-LMAP functionality that is associated with the transfer of the Measurement Traffic and is located at the devices with the MA and MP.)
_________________ _________________
| | | |
|Measurement Peer |=========== NAT ? ==========|Measurement Agent|
|_________________| |_________________|
<- (Key Negotiation &
Encryption Setup)
(Encrypted Channel ->
Established)
(Announce capabilities ->
& status)
<- (Select capabilities)
ACK ->
<- (Measurement Request
(MA+MP IPAddrs,set of
Metrics, Schedule))
ACK ->
Measurement Traffic <> Measurement Traffic
(may/may not be encrypted) (may/may not be encrypted)
<- (Stop Measurement Task)
Measurement Results ->
(if applicable)
<- ACK, Close
Figure 11: Interactions between Measurement Peer and Measurement
Agentthis exchange mainly exposes the IP addresses of measurement devices, and the inference that someone is taking part in measurement based on that traffic 🕵️♀️ there might be sensitive info about key points in a service provider's network in there too. there may also be access to measurement-related info of interest, like the Metrics, Schedule, and intermediate results carried in the Measurement Traffic (usually a set of timestamps) ⏱️
the Measurement Peer may be able to use traffic analysis (maybe combined with traffic injection) to learn interesting things about the Subscriber 😳 as a simple example, if the Measurement Task includes a pre-check that the end user isn't already sending traffic, the Measurement Peer may be able to figure out when the Subscriber is away on holiday 🏖️
if the Measurement Traffic is unencrypted, as it is in many systems today, then both the timing and the limited results are open to on-path observers. yikes 😬
8.4.5. Measurement Agent 👩💻
some Measurement Methods only involve a single Measurement Agent observing existing traffic. those raise potential privacy issues too, though the specifics of the mechanisms are beyond the scope of the initial LMAP work 🙈
the high-level communications model in Figure 12 shows the collection of user info of interest, with the Measurement Agent doing the monitoring and storing the Results. this particular exchange is for measuring DNS Response Time, which most often uses UDP transport. (Note: For simplicity, Figure 12 and its description do not show the non-LMAP functionality that is associated with the transfer (export) of the observed Measurement Traffic beyond the measurement devices located with the MA.)
_________________ ____________
| | | |
| DNS Server |=========== NAT ? ==========*=======| User client|
|_________________| ^ |____________|
______|_______
| |
| Measurement |
| Agent |
|______________|
<- Name Resolution Required
(MA+MP IPAddrs,
Desired Domain Name)
Return Record ->
MA: Measurement Agent
MP: Measurement Peer
Figure 12: LMAP deployment example, with Measurement Agent monitoring
DNS response timein this example, the MA monitors DNS messages so it can measure the DNS response time. the Measurement Agent may be embedded in the user host, or it may sit in another device that's able to observe user traffic 🧐 the MA learns the IP addresses of measurement devices and the intent to communicate with or access the services of a particular domain name. it may also learn info on key points in a service provider's network, such as the address of one of its DNS servers 🗺️
in principle, any of the user sensitive info of interest (listed above) can be collected and stored in the monitoring scenario, so it all has to be secured 🔐
it would also be possible for a Measurement Agent to source the DNS query itself, and in that case there aren't many privacy concerns 💖
8.4.6. Storage and Reporting of Measurement Results 🗄️
the mechanisms for communicating results beyond the initial Collector are out of scope for the initial LMAP work. still, there are potential privacy issues tied to a single organisation's storage and reporting of Measurement Results 📑 both storage and reporting functions can help preserve privacy by implementing the mitigations described below. ✨
8.5. Threats ⚠️
this section shows how each of the threats described in [RFC6973] applies to the LMAP entities and to their communication and storage of "information of interest" 🎯 the DoS and other attacks described in the Security section are threats too, and they get more effective when sensitive info protections have been compromised 💀
8.5.1. Surveillance 👀
Okay so, Section 5.1.1 of [RFC6973] describes surveillance as the "observation or monitoring of an individual's communications or activities." 💅 That means every Measurement Method that measures user traffic is a form of surveillance, and it comes with inherent risks 😬
Measurement Methods that avoid periods of user transmission indirectly produce a record of times when a subscriber or authorised user has used their network access service. Even when they're being quiet, the silence itself tells a story 🤫
Measurement Methods may also utilise and store a Subscriber's currently assigned IP address when conducting measurements that are relevant to a specific Subscriber. Since the Measurement Results are timestamped, they could provide a record of IP address assignments over time 🕰️
Either of the above pieces of information could be useful in correlation and identification, as described below 🔍
8.5.2. Stored Data Compromise 🔐
Section 5.1.2 of [RFC6973] describes Stored Data Compromise as resulting from inadequate measures to secure stored data from unauthorised or inappropriate access. For LMAP systems, this includes deleting or modifying collected measurement records, as well as data theft 🫣
The primary LMAP entity subject to compromise is the repository, which stores the Measurement Results. Extensive security and privacy threat mitigations are warranted 🏰 The Collector and MA also store sensitive information temporarily and need protection. The communications between the local storage of the Collector and the repository is beyond the scope of the initial LMAP work, though this communications channel will certainly need protection, as will the mass storage itself.
The LMAP Controller may have direct access to storage of Subscriber information (for example, location, billing, service parameters, etc.) and other information that the controlling organisation considers private, and again it needs protection 🔒
Note that there is tension between the desire to store all raw results in the LMAP Collector (for reproduction and custom analysis) and the need to protect the privacy of measurement participants. Many of the mitigations described in Section 8.6 are most efficient when deployed at the MA, therefore minimising the risks associated with stored results 💖
8.5.3. Correlation and Identification 🧩
Sections 5.2.1 and 5.2.2 of [RFC6973] describe correlation as combining various pieces of information to obtain desired characteristics of an individual, and identification as using this combination to infer identity.
The main risk is that the LMAP system could unwittingly provide a key piece of the correlation chain, starting with an unknown Subscriber's IP address and another piece of information. For example, a Subscriber utilised Internet access from 2000 to 2310 UTC, because the Measurement Tasks were deferred or sent a name resolution for www.example.com at 2300 UTC. 😱
If a user's access with another system already gave away sensitive information, correlation is clearly easier and can result in re-identification, even when an LMAP system conserves sensitive information to a great extent 🚨
8.5.4. Secondary Use and Disclosure 📣
Sections 5.2.3 and 5.2.4 of [RFC6973] describe secondary use as unauthorised utilisation of an individual's information for a purpose the individual did not intend. They describe disclosure as when such information is revealed, causing another's notions of the individual to change or confidentiality to be violated 🙈
Measurement Methods that measure user traffic are a form of secondary use, and the Subscribers' permission should be obtained beforehand. It may be necessary to obtain the measured ISP's permission to conduct measurements (for example, when required by the terms and conditions of the service agreement). Notification is considered good measurement practice 📝
For Measurement Methods that measure Measurement Traffic, the Measurement Results provide some limited information about the Subscriber or ISP and could result in secondary uses. For example, the use of the Results in unauthorised marketing campaigns would qualify as secondary use. Secondary use may break national laws and regulations, and may violate an individual's expectations or desires. That is a big no from me 🙅♀️
8.6. Mitigations 🛡️
This section examines the mitigations listed in Section 6 of [RFC6973] and their applicability to LMAP systems. Note that each section in [RFC6973] identifies the threat categories that each technique mitigates 🧠
8.6.1. Data Minimisation 🧹
Section 6.1 of [RFC6973] encourages collecting and storing the minimal information needed to perform a task ✨
LMAP Results can be useful for general reporting about performance and for specific troubleshooting. They need different levels of information detail, as explained in the paragraphs below 💭
For general reporting, the results can be aggregated into large categories (for example, the month of March, or all US subscribers West of the Mississippi River). In this case, all individual identifications (including IP address of the MA) can be excluded, and only relevant results are provided. However, this implies a filtering process to reduce the information fields, because greater detail was needed to conduct the Measurement Tasks in the first place 📊
For troubleshooting, so that a network operator or end user can identify a performance issue or failure, potentially all the network information (for example, IP addresses, equipment IDs, location), Measurement Schedules, service configurations, Measurement Results, and other information may assist in the process. This includes the information needed to conduct the Measurement Tasks. It represents a need where the maximum relevant information is desirable, so the greatest protections should be applied 🔥 This level of detail is greater than needed for general performance monitoring.
As regards Measurement Methods that measure user traffic, we note that a user may give temporary permission (to enable detailed troubleshooting) but withhold permission for them in general. Here the greatest breadth of sensitive information is potentially exposed, so the maximum privacy protection must be provided. The Collector may perform pre-storage minimisation and other mitigations (Section 8.6.4) to help preserve privacy 🫶
For MAs with access to the sensitive information of users (for example, within a home or a personal host/handset), it is desirable for the Results collection to minimise the data reported. It also needs to balance this desire with the needs of troubleshooting when a service subscription exists between the user and the organisation operating the measurements 🏠
8.6.2. Anonymity 🎭
Section 6.1.1 of [RFC6973] describes an "anonymity set" as a way in which anonymity is achieved: "there must exist a set of individuals that appear to have the same attribute(s) as the individual." 🥸
Experimental methods for anonymisation of user-identifiable data (and so particularly applicable to Measurement Methods that measure user traffic) have been identified in [RFC6235]. However, the findings of several of the same authors is that "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]." 😬 Essentially, the details of such Measurement Methods can only be accessed by closed organisations, and unknown injection attacks are always less expensive than the protections from them. However, some forms of summary may protect the user's sensitive information sufficiently well, so each Metric must be evaluated in the light of privacy 🔍
The techniques in [RFC6235] could be applied more successfully in Measurement Methods that generate Measurement Traffic, where there are protections from injection attack. The successful attack would require breaking the integrity protection of the LMAP Reporting Protocol and injecting Measurement Results (known fingerprint, see Section 3.2 of [RFC6973]) for inclusion with the shared and anonymised results. Then the attacker would fingerprint those records to ascertain the anonymisation process 🕵️♀️
Besides anonymisation of measured Results for a specific user or provider, the value of sensitive information can be further diluted by summarising the Results over many individuals or areas served by the provider. There is an opportunity enabled by forming anonymity sets [RFC6973] based on the reference path measurement points in [RFC7398]. For example, all measurements from a Subscriber device can be identified as mp000, instead of using the IP address or other device information. The same anonymisation applies to the Internet Service Provider, where their Internet gateway would be referred to as mp190 🌸
Another anonymisation technique is for the MA to include its Group-ID instead of its MA-ID in its Measurement Reports, with several MAs sharing the same Group-ID 👯
8.6.3. Pseudonymity 🦋
Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, are a possible mitigation to revealing one's true identity, since there is no requirement to use real names in almost all protocols 🎀
A pseudonym for a measurement device's IP address could be an LMAP-unique equipment ID. However, this would likely be a permanent handle for the device, and long-term use weakens a pseudonym's power to obscure identity 🫠
8.6.4. Other Mitigations 🧁
Data can be depersonalised by blurring it, for example by adding synthetic data, data-swapping, or perturbing the values in ways that can be reversed or corrected 🌈
Sections 6.2 and 6.3 of [RFC6973] describe user participation and security, respectively 📚
Where LMAP measurements involve devices on the subscriber's premises or Subscriber-owned equipment, it is essential to secure the Subscriber's permission with regard to the specific information that will be collected. The informed consent of the Subscriber (and, if different, the end user) may be needed, including the specific purpose of the measurements. The approval process could involve showing the Subscriber their measured information and results before instituting periodic collection, or before all instances of collection, with the option to cancel collection temporarily or permanently 🙋♀️
It should also be clear who is legally responsible for data protection (privacy). In some jurisdictions, this role is called the 'data controller'. It is always good practice to limit the time that personal information is stored ⏳
Although the details of verification would be impenetrable to most subscribers, the MA could be architected as an "app" with open source code, pre-download and embedded terms of use and agreement on measurements, and protection from code modifications usually provided by the app stores. Further, the app itself could provide data reduction and temporary storage mitigations as appropriate, and be certified through code review 📱
LMAP protocols, devices, and the information they store clearly need to be secure from unauthorised access. This is the hand-off between privacy and security considerations (Section 7). The data controller is responsible (legally) for maintaining data protections described in the Subscriber's agreement and agreements with other organisations 🔐
Finally, it is recommended that each entity described in Section 8.1, (for example, individuals, ISPs, regulators, others) assess the risks of LMAP data collection by conducting audits of their data protection methods 🔎
9. Informative References ✨
Okay bestie, this is the reading list 📚 every reference the RFC leans on, all in one place, with the full details so you can go find them yourself 🦋
[Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi,
"The Role of Network Trace anonymisation Under Attack",
January 2010.
[IPPM-REG] Bagnulo, M., Claise, B., Eardley, P., Morton, A., and A.
Akhter, "Registry for Performance Metrics", Work in
Progress, draft-ietf-ippm-metric-registry-04, July 2015.
[LMAP-INFO]
Burbridge, T., Eardley, P., Bagnulo, M., and J.
Schoenwaelder, "Information Model for Large-Scale
Measurement Platforms (LMAP)", Work in Progress,
draft-ietf-lmap-information-model-06, July 2015.
[REST] Wikipedia, "Representational state transfer", July 2015,
<https://en.wikipedia.org/w/index.php?
title=Representational_state_transfer&oldid=673799183>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
DOI 10.17487/RFC4101, June 2005,
<http://www.rfc-editor.org/info/rfc4101>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006,
<http://www.rfc-editor.org/info/rfc4656>.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, DOI 10.17487/RFC5357, October 2008,
<http://www.rfc-editor.org/info/rfc5357>.
[RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
<http://www.rfc-editor.org/info/rfc6235>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC6419] Wasserman, M. and P. Seite, "Current Practices for
Multiple-Interface Hosts", RFC 6419, DOI 10.17487/RFC6419,
November 2011, <http://www.rfc-editor.org/info/rfc6419>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
DOI 10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258,
May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<http://www.rfc-editor.org/info/rfc7368>.
[RFC7398] Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for
Large-Scale Measurement of Broadband Performance",
RFC 7398, DOI 10.17487/RFC7398, February 2015,
<http://www.rfc-editor.org/info/rfc7398>.
[RFC7536] Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen,
"Large-Scale Broadband Measurement Use Cases", RFC 7536,
DOI 10.17487/RFC7536, May 2015,
<http://www.rfc-editor.org/info/rfc7536>.
[TR-069] The Broadband Forum, "CPE WAN Management Protocol", TR-069
Amendment 5, November 2013,
<https://www.broadband-forum.org/technical/download/
TR-069_Amendment-5.pdf>.
[UPnP] UPnP Forum, "UPnP Device Architecture 2.0", February 2015,
<http://www.iso.org/iso/home/store/catalogue_ics/
catalogue_detail_ics.htm?csnumber=57195>.Acknowledgments
This document started life as a merger of three individual drafts 🌸: "Terminology for Large MeAsurement Platforms (LMAP)" (July 2013), "A Framework and Inventory for a Large Scale Measurement System" (July 2013), and "A framework for large-scale measurements" (July 2013). Three drafts becoming one doc is giving teamwork 🫶
Huge thanks to Juergen Schoenwaelder for his super detailed review of the terminology 🤓, and to Charles Cook for a very thorough review of an early draft 💖. Thanks also to Barbara Stark and Ken Ko for so many helpful comments on the later drafts ✨.
Thanks to numerous people for all the discussion, both directly and on the LMAP list 💬 (apologies to anyone we accidentally left out 🙈): Alan Clark, Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian Trammell, Charles Cook, Dan Romascanu, Dave Thorne, Frode Soerensen, Greg Mirsky, Guangqing Deng, Jason Weil, Jean-Francois Tremblay, Jerome Benoit, Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, Ken Ko, Lingli Deng, Mach Chen, Matt Mathis, Marc Ibrahim, Michael Bugenhagen, Michael Faath, Nalini Elkins, Radia Perlman, Rolf Winter, Sam Crawford, Sharam Hakimi, Steve Miller, Ted Lemon, Timothy Carey, Vaibhav Bajpai, Vero Zheng, and William Lupton. 👑
Philip Eardley, Trevor Burbridge and Marcelo Bagnulo worked in part on the Leone research project 🧚, which got funding from the European Union Seventh Framework Programme under grant agreement number 317647 🇪🇺.
Authors' Addresses
Philip Eardley
BT
Adastral Park, Martlesham Heath
Ipswich
England
Email: philip.eardley@bt.com
Al Morton
AT&T Labs
200 Laurel Avenue South
Middletown, NJ
United States
Email: acmorton@att.com
Marcelo Bagnulo
Universidad Carlos III de Madrid
Av. Universidad 30
Leganes, Madrid 28911
Spain
Phone: 34 91 6249500
Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es
Trevor Burbridge
BT
Adastral Park, Martlesham Heath
Ipswich
England
Email: trevor.burbridge@bt.com
Paul Aitken
Brocade Communications Systems, Inc.
19a Canning Street, Level 3
Edinburgh, Scotland EH3 8EG
United Kingdom
Email: paitken@brocade.com
Aamer Akhter
Consultant
118 Timber Hitch
Cary, NC
United States
Email: aakhter@gmail.comAnd that's the whole RFC, bestie! 🌈💅 Every author, every reference, every thank-you, all accounted for 🦋💜
📦 where this page comes from
- ietf: rfc7594 2015-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms