idnits 2.17.1 draft-ietf-lmap-framework-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 31, 2014) is 3678 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 229 -- Looks like a reference, but probably isn't: '180' on line 229 == Unused Reference: 'UPnP' is defined on line 2271, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-lmap-use-cases-02 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-13 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-lmap-path-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eardley 3 Internet-Draft BT 4 Intended status: Informational A. Morton 5 Expires: October 2, 2014 AT&T Labs 6 M. Bagnulo 7 UC3M 8 T. Burbridge 9 BT 10 P. Aitken 11 A. Akhter 12 Cisco Systems 13 March 31, 2014 15 A framework for large-scale measurement platforms (LMAP) 16 draft-ietf-lmap-framework-04 18 Abstract 20 Measuring broadband service on a large scale requires a description 21 of the logical architecture and standardisation of the key protocols 22 that coordinate interactions between the components. The document 23 presents an overall framework for large-scale measurements. It also 24 defines terminology for LMAP (large-scale measurement platforms). 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 2, 2014. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Outline of an LMAP-based measurement system . . . . . . . . . 5 62 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1. Measurement system is under the direction of a single 65 organisation . . . . . . . . . . . . . . . . . . . . . . 11 66 4.2. Each MA may only have a single Controller at any point in 67 time . . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5. LMAP Protocol Model . . . . . . . . . . . . . . . . . . . . . 12 69 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 13 70 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 14 71 5.2.1. Instruction . . . . . . . . . . . . . . . . . . . . . 14 72 5.2.2. Capabilities and Failure information . . . . . . . . 17 73 5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 19 74 5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 19 75 5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 20 76 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 21 77 5.4.1. Reporting of Subsriber's service parameters . . . . . 22 78 5.5. Operation of LMAP over the underlying transport protocol 22 79 5.6. Items beyond the scope of the LMAP Protocol Model . . . . 23 80 5.6.1. End-user-controlled measurement system . . . . . . . 24 81 6. Deployment considerations . . . . . . . . . . . . . . . . . . 25 82 6.1. Controller and the measurement system . . . . . . . . . . 25 83 6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 26 84 6.2.1. Measurement Agent on a networked device . . . . . . . 26 85 6.2.2. Measurement Agent embedded in site gateway . . . . . 26 86 6.2.3. Measurement Agent embedded behind site NAT /Firewall 27 87 6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 27 88 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 28 89 7. Security considerations . . . . . . . . . . . . . . . . . . . 28 90 8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 30 91 8.1. Categories of Entities with Information of Interest . . . 30 92 8.2. Examples of Sensitive Information . . . . . . . . . . . . 31 93 8.3. Key Distinction Between Active and Passive Measurement 94 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 8.4. Privacy analysis of the Communications Models . . . . . . 33 96 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 33 97 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 34 98 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 34 99 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 35 100 8.4.5. Passive Measurement Agent . . . . . . . . . . . . . . 36 101 8.4.6. Storage and Reporting of Measurement Results . . . . 37 102 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 37 103 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 38 104 8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 38 105 8.5.3. Correlation and Identification . . . . . . . . . . . 39 106 8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 39 107 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 39 108 8.6.1. Data Minimisation . . . . . . . . . . . . . . . . . . 39 109 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 40 110 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 41 111 8.6.4. Other Mitigations . . . . . . . . . . . . . . . . . . 41 112 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 113 10. Appendix: Deployment examples . . . . . . . . . . . . . . . . 42 114 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 115 12. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 116 12.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 47 117 12.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 47 118 12.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 48 119 12.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 49 120 13. Informative References . . . . . . . . . . . . . . . . . . . 49 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 123 1. Introduction 125 There is a desire to be able to coordinate the execution of broadband 126 measurements and the collection of measurement results across a large 127 scale set of diverse devices. These devices could be software based 128 agents on PCs, embedded agents in consumer devices (e.g. blu-ray 129 players), service provider controlled devices such as set-top players 130 and home gateways, or simply dedicated probes. It is expected that 131 such a system could easily comprise 100,000 devices. Such a scale 132 presents unique problems in coordination, execution and measurement 133 result collection. Several use cases have been proposed for large- 134 scale measurements including: 136 o Operators: to help plan their network and identify faults 138 o Regulators: to benchmark several network operators and support 139 public policy development 141 Further details of the use cases can be found in 142 [I-D.ietf-lmap-use-cases]. The LMAP framework should be useful for 143 these, as well as other use cases, such as to help end users run 144 diagnostic checks like a network speed test. 146 The LMAP framework has three basic elements: Measurement Agents, 147 Controllers and Collectors. 149 Measurement Agents (MAs) perform the actual measurements, which are 150 called Measurement Tasks in the LMAP terminology. 152 The Controller manages one or more MAs by instructing it which 153 Measurement Tasks it should perform and when. For example it may 154 instruct a MA at a home gateway: "Measure the 'UDP latency' with 155 www.example.org; repeat every hour at xx.05". The Controller also 156 manages a MA by instructing it how to report the Measurement Results, 157 for example: "Report results once a day in a batch at 4am". We refer 158 to these as the Measurement Schedule and Report Schedule. 160 The Collector accepts Reports from the MAs with the Results from 161 their Measurement Tasks. Therefore the MA is a device that gets 162 Instructions from the Controller, initiates the Measurement Tasks, 163 and reports to the Collector. 165 There are additional elements that are part of a measurement system, 166 but these are out of the scope for LMAP. We provide a detailed 167 discussion of all the elements in the rest of the document. 169 The desirable features for a large-scale measurement systems we are 170 designing for are: 172 o Standardised - in terms of the Measurement Tasks that they 173 perform, the components, the data models and protocols for 174 transferring information between the components. Amongst other 175 things, standardisation enables meaningful comparisons of 176 measurements made of the same metric at different times and 177 places, and provides the operator of a measurement system with a 178 criteria for evaluation of the different solutions that can be 179 used for various purposes including buying decisions (such as 180 buying the various components from different vendors). Today's 181 systems are proprietary in some or all of these aspects. 183 o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement 184 Agents in every home gateway and edge device such as set-top-boxes 185 and tablet computers. It is expected that a measurement system 186 could easily encompass a few hundred thousand Measurement Agents. 187 Existing systems have up to a few thousand MAs (without judging 188 how much further they could scale). 190 o Diversity - a measurement system should handle different types of 191 Measurement Agent - for example Measurement Agents may come from 192 different vendors, be in wired and wireless networks, have 193 different Measurement Task capabilities and be on devices with 194 IPv4 or IPv6 addresses. 196 2. Outline of an LMAP-based measurement system 198 Figure 1 shows the main components of a measurement system, and the 199 interactions of those components. Some of the components are outside 200 the scope of LMAP. In this section we provide an overview of the 201 whole measurement system and we introduce the main terms needed for 202 the LMAP framework. The new terms are capitalised. In the next 203 section we provide a terminology section with a compilation of all 204 the LMAP terms and their definition. 206 The main work of the LMAP working group is to define the Control 207 Protocol between the Controller and MA, and the Report Protocol 208 between the MA and Collector. Section 4 onwards considers the LMAP 209 components in more detail. 211 The MA performs Measurement Tasks. The MAs are pieces of code that 212 can be executed in specialised hardware (hardware probe) or on a 213 general-purpose device (like a PC or mobile phone). A device with a 214 Measurement Agent may have multiple interfaces (WiFi, Ethernet, DSL, 215 fibre, etc.) and the Measurement Tasks may specify any one of these. 216 Measurement Tasks may be Active (the MA generates Active Measurement 217 Traffic and measures some metric associated with its transfer), 218 Passive (the MA observes user traffic), or some hybrid form of the 219 two. 221 The MA is managed by a Controller using the Control Protocol. The MA 222 receives Instructions from the Controller about which Measurement 223 Tasks it should perform and when. For example the Controller may 224 instruct a MA at a home gateway: "Count the number of TCP SYN packets 225 observed in a 1 minute interval; repeat every hour at xx.05 + 226 Unif[0,180] seconds". The Measurement Schedule determines when the 227 Measurement Tasks are executed. The Controller also manages a MA by 228 instructing it how to report the Measurement Results, for example: 229 "Report results once a day in a batch at 4am + Unif[0,180] seconds; 230 if the end user is active then delay the report 5 minutes". The 231 Report Schedule determines when the Reports are uploaded to the 232 Collector. The Measurement chedule and Report Schedule can define 233 one-off (non-recurring) actions ("Do measurement now", "Report as 234 soon as possible"), as well as recurring ones. 236 The Collector accepts a Report from a MA with the Measurement Results 237 from its Measurement Tasks. It then provides the Results to a 238 repository (see below). 240 Some Measurement Tasks involve several MAs acting in a coordinated 241 fashion. This coordination is achieved by the Controller instructing 242 the multiple MAs in a coherent manner. In some Measurement Tasks the 243 MA(s) is assisted by one or more network entities that are not 244 managed by the Controller. The entities that helps the MA in the 245 Measurement Tasks but are not managed by the Controller are called 246 Measurement Peers (MPs). For example consider the case of a "ping" 247 Measurement Task, to measure the round trip delay between the MA and 248 a given ICMP ECHO responder in the Internet. In this case, the 249 responder is the Measurement Peer. The ICMP ECHO request and ICMP 250 ECHO Requests and Replies flowing between the MA and the MP is called 251 Active Measurement Traffic. The Appendix has some other examples of 252 possible arrangements of Measurement Agents and Peers. 254 A Measurement Method defines how to measure a Metric of interest. It 255 is very useful to standardise Measurement Methods, so that it is 256 meaningful to compare measurements of the same Metric made at 257 different times and places. It is also useful to define a registry 258 for commonly-used Metrics [I-D.manyfolks-ippm-metric-registry] so 259 that a Measurement Method can be referred to simply by its identifier 260 in the registry. The Measurement Methods and registry will hopefully 261 be referenced by other standards organisations. 263 A Measurement Task is a specific instantiation of a Measurement 264 Method.It generates a Measurement Result. An Active Measurement Task 265 involves either a Measurement Agent (MA) injecting Active Measurement 266 Traffic into the network destined for a Measurement Peer or for 267 another Measurement Agent, and/or a Measurement Peer (or another 268 Measurement Agent) sending Active Measurement Traffic to a MA; one of 269 them measures some parameter associated with the transfer of the 270 packet(s). A Passive Measurement Task involves a MA simply observing 271 existing traffic - for example, it could count bytes or it might 272 calculate the average loss for a particular flow. 274 In order for a Measurement Agent and a Measurement Peer (or another 275 Measurement Agent) to execute an Active Measurement Task, they 276 exchange Active Measurement Traffic. The protocols used for the 277 Active Measurement Traffic are out of the scope of the LMAP WG; they 278 fall within the scope of other IETF WGs such as IPPM. 280 For Measurement Results to be truly comparable, as might be required 281 by a regulator, not only do the same Measurement Methods need to be 282 used but also the set of Measurement Tasks should follow a similar 283 Measurement Schedule and be of similar number. The details of such a 284 characterisation plan are beyond the scope of work in IETF although 285 certainly facilitated by IETF's work. 287 Finally we introduce several components that are out of scope of the 288 LMAP WG and will be provided through existing protocols or 289 applications. They affect how the measurement system uses the 290 Measurement Results and how it decides what set of Measurement Tasks 291 to perform. 293 The MA needs to be bootstrapped with initial details about its 294 Controller, including authentication credentials. The LMAP WG 295 considers the bootstrap process, since it affects the Information 296 Model. However, it does not define a bootstrap protocol, since it is 297 likely to be technology specific and could be defined by the 298 Broadband Forum, CableLabs or IEEE depending on the device. Possible 299 protocols are SNMP, NETCONF or (for Home Gateways) CPE WAN Management 300 Protocol (CWMP) from the Auto Configuration Server (ACS) (as 301 specified in TR-069 [TR-069]). 303 A Subscriber parameter database contains information about the line, 304 such as the customer's broadband contract (perhaps 2, 40 or 80Mb/s), 305 the line technology (DSL or fibre), the time zone where the MA is 306 located, and the type of home gateway and MA. These parameters are 307 already gathered and stored by existing operations systems. They may 308 affect the choice of what Measurement Tasks to run and how to 309 interpret the Measurement Results. For example, a download test 310 suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s 311 line. 313 A results repository records all Measurement Results in an equivalent 314 form, for example an SQL database, so that they can easily be 315 accessed by the data analysis tools. 317 The data analysis tools receive the results from the Collector or via 318 the Results repository. They might visualise the data or identify 319 which component or link is likely to be the cause of a fault or 320 degradation. This information could help the Controller decide what 321 follow-up Measurement Task to perform in order to diagnose a fault. 322 The data analysis tools also need to understand the Subscriber's 323 service information, for example the broadband contract. 325 ^ 326 | 327 Active +-------------+ IPPM 328 +---------------+ Measurement | Measurement | Scope 329 | Measurement |<------------>| Peer | | 330 | Agent | Traffic +-------------+ v 331 +------->| | ^ 332 | +---------------+ | 333 | ^ | | 334 | Instruction | | Report | 335 | | +-----------------+ | 336 | | | | 337 | | v LMAP 338 | +------------+ +------------+ Scope 339 | | Controller | | Collector | | 340 | +------------+ +------------+ v 341 | ^ ^ | ^ 342 | | | | | 343 | | +----------+ | | 344 | | | v | 345 +------------+ +----------+ +--------+ +----------+ | 346 |Bootstrapper| |Subscriber|--->| data |<---|repository| Out 347 +------------+ |parameter | |analysis| +----------+ of 348 |database | | tools | Scope 349 +----------+ +--------+ | 350 | 351 v 353 Figure 1: Schematic of main elements of an LMAP-based 354 measurement system 355 (showing the elements in and out of the scope of the LMAP WG) 357 3. Terminology 359 This section defines terminology for LMAP. Please note that defined 360 terms are capitalized. 362 Active Measurement Method (Task): A Measurement Method (Task) in 363 which a Measurement Agent creates or receives Active Measurement 364 Traffic, by coordinating with one or more other Measurement Agents or 365 Measurement Peers using protocols outside LMAP's scope. 367 Active Measurement Traffic: the packet(s) generated in order to 368 execute an Active Measurement Task. 370 Bootstrap: A process that integrates a Measurement Agent into a 371 measurement system. 373 Capabilities: Information about the Measurement Methods that the MA 374 can perform and the device hosting the MA, for example its interface 375 type and speed, but not dynamic information. 377 Channel: A bi-directional logical connection that is defined by a 378 specific Controller and MA, or Collector and MA, plus associated 379 security. 381 Collector: A function that receives a Report from a Measurement 382 Agent. 384 Controller: A function that provides a Measurement Agent with its 385 Instruction. 387 Control Channel: a Channel between a Controller and a MA over which 388 Instruction Messages and Capabilities and Failure information are 389 sent. 391 Control Protocol: The protocol delivering Instruction(s) from a 392 Controller to a Measurement Agent. It also delivers Failure 393 Information and Capabilities Information from the Measurement Agent 394 to the Controller. 396 Cycle-ID: A tag that is sent by the Controller in an Instruction and 397 echoed by the MA in its Report. The same Cycle-ID is used by several 398 MAs that use the same Measurement Method with the same Input 399 Parameters. Hence the Cycle-ID allows the Collector to easily 400 identify Measurement Results that should be comparable. 402 Data Model: The implementation of an Information Model in a 403 particular data modelling language [RFC3444]. 405 Data Transfer Method: The process whereby: a Controller transfers 406 information over a Control Channel to a MA; or a MA transfers 407 information over a Control Channel to a Controller; or a MA transfers 408 information over a Report Channel to a Collector; the generalisation 409 of a Data Transfer Task. 411 Data Transfer Task: The act consisting of the (single) operation of a 412 Data Transfer Method at a particular time. 414 Environmental Constraint: A parameter that is measured as part of the 415 Measurement Task, its value determining whether the rest of the 416 Measurement Task proceeds. 418 Failure Information: Information about the MA's failure to action or 419 execute an Instruction, whether concerning Measurement Tasks or 420 Reporting. 422 Group-ID: An identifier of a group of MAs. 424 Information Model: The protocol-neutral definition of the semantics 425 of the Instructions, the Report, the status of the different elements 426 of the measurement system as well of the events in the system 427 [RFC3444]. 429 Input Parameter: A parameter whose value is left open by the 430 Measurement Method and is set to a specific value in a Measurement 431 Task. Altering the value of an Input Parameter does not change the 432 fundamental nature of the Measurement Method. 434 Instruction: The description of Measurement Tasks for a MA to perform 435 and the details of the Report for it to send. It is the collective 436 description of the Measurement Task configurations, the configuration 437 of the Report Channel(s), the configuration of Data Transfer Tasks, 438 the configuration of the Measurement Schedules, and the details of 439 any suppression. 441 Instruction Message: The message that carries an Instruction from a 442 Controller to a Measurement Agent. 444 Measurement Agent (MA): The function that receives Instruction 445 Messages from a Controller and operates the Instruction by executing 446 Measurement Tasks (using protocols outside LMAP's scope and perhaps 447 in concert with one or more other Measurement Agents or Measurement 448 Peers) and (if part of the Instruction) by reporting Measurement 449 Results to a Collector or Collectors. 451 Measurement Agent Identifier (MA-ID): a UUID [RFC4122] that 452 identifies a particular MA and is configured as part of the 453 Bootstrapping process. 455 Measurement Method: The process for assessing the value of a Metric; 456 the process of measuring some performance or reliability parameter 457 associated with the transfer of traffic; the generalisation of a 458 Measurement Task. 460 Measurement Peer (MP): The function that assists a Measurement Agent 461 with Measurement Tasks and does not have an interface to the 462 Controller or Collector. 464 Measurement Result: The output of a single Measurement Task (the 465 value obtained for the parameter of interest or Metric). 467 Measurement Schedule: The schedule for performing Measurement Tasks. 469 Measurement Task: The act that consistsof the single operation of the 470 Measurement Method at a particular time and with all its Input 471 Parameters set to specific values. 473 Metric: The quantity related to the performance and reliability of 474 the network that we'd like to know the value of, and that is 475 carefully specified. 477 Passive Measurement Method (Task): A Measurement Method (Task) in 478 which a Measurement Agent observes existing traffic but does not 479 inject Active Measurement Traffic. 481 Report: The set of Measurement Results and other associated 482 information (as defined by the Instruction). The Report is sent by a 483 Measurement Agent to a Collector. 485 Report Channel: a communications channel between a MA and a 486 Collector, which is defined by a specific MA, Collector, Report 487 Schedule and associated security, and over which Reports are sent. 489 Report Protocol: The protocol delivering Report(s) from a Measurement 490 Agent to a Collector. 492 Report Schedule: the schedule for sending Reports to a Collector. 494 Subscriber: An entity (associated with one or more users) that is 495 engaged in a subscription with a service provider. The Subscriber is 496 allowed to subscribe and un-subscribe services, and to register a 497 user or a list of users authorized to enjoy these services. [Q1741]. 498 Both the Subscriber and service provider are allowed to set the 499 limits relative to the use that associated users make of subscribed 500 services. 502 Suppression: the temporary cessation of Active Measurement Tasks. 504 4. Constraints 506 The LMAP framework makes some important assumptions, which constrain 507 the scope of the work to be done. 509 4.1. Measurement system is under the direction of a single organisation 511 In the LMAP framework, the measurement system is under the direction 512 of a single organisation that is responsible for any impact that 513 measurements have on a user's quality of experience and privacy. 514 Clear responsibility is critical given that a misbehaving large-scale 515 measurement system could potentially harm user experience, user 516 privacy and network security. 518 However, the components of an LMAP measurement system can be deployed 519 in administrative domains that are not owned by the measuring 520 organisation. Thus, the system of functions deployed by a single 521 organisation constitutes a single LMAP domain which may span 522 ownership or other administrative boundaries. 524 4.2. Each MA may only have a single Controller at any point in time 526 A MA is instructed by one Controller and is in one measurement 527 system. The constraint avoids different Controllers giving a MA 528 conflicting instructions and so means that the MA does not have to 529 manage contention between multiple Measurement (or Report) Schedules. 530 This simplifies the design of MAs (critical for a large-scale 531 infrastructure) and allows a Measurement Schedule to be tested on 532 specific types of MA before deployment to ensure that the end user 533 experience is not impacted (due to CPU, memory or broadband-product 534 constraints). 536 An operator may have several Controllers, perhaps with a Controller 537 for different types of MA (home gateways, tablets) or location 538 (Ipswich, Edinburgh). 540 5. LMAP Protocol Model 542 A protocol model [RFC4101] presents an architectural model for how 543 the protocol operates and needs to answer three basic questions: 545 1. What problem is the protocol trying to achieve? 547 2. What messages are being transmitted and what do they mean? 549 3. What are the important, but unobvious, features of the protocol? 551 An LMAP system goes through the following phases: 553 o a bootstrapping process before the MA can take part in the other 554 three phases 556 o a Control Protocol, which delivers an Instruction from a 557 Controller to a MA, detailing what Measurement Tasks the MA should 558 perform and when, and how it should report the Measurement Results 560 o the actual Measurement Tasks, which measure some performance or 561 reliability parameter(s) associated with the transfer of packets. 562 The LMAP WG does not define Measurement Methods, however the IPPM 563 WG does. 565 o a Report Protocol, which delivers a Report from the MA to a 566 Collector. The Report contains the Measurement Results. 568 The diagrams show the various LMAP messages and usesthe following 569 convention: 571 o (optional): indicated by round brackets 573 o [potentially repeated]: indicated by square brackets 575 The protocol model is closely related to the Information Model 576 [I-D.burbridge-lmap-information-model], which is the abstract 577 definition of the information carried by the protocol model. The 578 purpose of both is to provide a protocol and device independent view, 579 which can be implemented via specific protocols. The LMAP WG will 580 define a specific Control Protocol and Report Protocol, but others 581 could be defined by other standards bodies or be proprietary. 582 However it is important that they all implement the same Information 583 Model and protocol model, in order to ease the definition, operation 584 and interoperability of large-scale measurement systems. 586 5.1. Bootstrapping process 588 The primary purpose of bootstrapping is to enable a MA to be 589 integrated into a measurement system. The MA retrieves information 590 about itself (like its identity in the measurement system) and about 591 the Controller, the Controller learns information about the MA, and 592 they learn about security information to communicate (such as 593 certificates and credentials). 595 Whilst the LMAP WG considers the bootstrapping process, it is out of 596 scope to define a bootstrap mechanism, as it depends on the type of 597 device and access. 599 As a result of the bootstrapping process the MA learns the following 600 information: 602 o its identifier, MA-ID 604 o (optionally) a Group-ID. A Group-ID would be shared by several 605 MAs and could be useful for privacy reasons, for instance to 606 hinder tracking of a mobile device 608 o the Control Channel, which is defined by: 610 * the address of the Controller (such as its FQDN (Fully 611 Qualified Domain Name) [RFC1035]) 613 * security information (for example to enable the MA to decrypt 614 the Instruction Message and encrypt messages sent to the 615 Controller) 617 * the name of this Control Channel 619 The details of the bootstrapping process are device /access specific. 620 For example, the information could be in the firmware, manually 621 configured or transferred via a protocol like TR-069. There may be a 622 multi-stage process where the MA contacts the device at a 'hard- 623 coded' address, which replies with the boostrapping information. 625 5.2. Control Protocol 627 The primary purpose of the Control Protocol is to allow the 628 Controller to configure a Measurement Agent with an Instruction about 629 what Measurement Tasks to do, when to do them, and how to report the 630 Measurement Results (Section 5.2.1). The Measurement Agent then acts 631 on the Instruction autonomously. The Control Protocol also enables 632 the MA to inform the Controller about its Capabilities and any 633 Failures (Section 5.2.2). 635 5.2.1. Instruction 637 The Instruction is the description of the Measurement Tasks for a 638 Measurement Agent to do and the details of the Measurement Reports 639 for it to send. In order to update the Instruction the Controller 640 uses a Data Transfer Task to send an Instruction Message over the 641 Control Channel. 643 +-----------------+ +-------------+ 644 | | | Measurement | 645 | Controller |======================================| Agent | 646 +-----------------+ +-------------+ 648 Instruction: -> 649 [(Measurement Task configuration( 650 [Input Parameter], 651 (interface), 652 (Cycle-ID))), 653 (Report Channel), 654 (Data Transfer Task), 655 (Measurement Schedule), 656 (Suppression information)] 657 <- Response(details) 659 The Instruction defines the following: 661 o the Measurement Task configurations, each of which needs: 663 * the Measurement Method, specified as a URN to a registry entry. 664 The registry could be defined by the IETF 665 [I-D.manyfolks-ippm-metric-registry], locally by the operator 666 of the measurement system or perhaps by another standards 667 organisation. 669 * any Input Parameters that need to be set for the Measurement 670 Method, such as the address of the Measurement Peer (or other 671 Measurement Agent) that are involved in an Active Measurement 672 Task 674 * if the device with the MA has multiple interfaces, then the 675 interface to use (if not defined, then the default interface is 676 used) 678 * optionally, a Cycle-ID (a tag that may help the data analysis 679 tools identify Measurement Results that should be comparable) 681 * a name for this Measurement Task configuration 683 o configuration of the Report Channels, each of which needs: 685 * the address of the Collector, for instance its URL 687 * security for this Report Channel, for example the X.509 688 certificate 690 * a name for this Report Channel 692 o configuration of the Data Transfer Tasks, each of which needs: 694 * the name of the Channel to use 696 * the timing of when to operate this Data Transfer Task 698 * whether to include the MA-ID &/or Group-ID in a Measurement 699 Report 701 * a name for this Data Transfer Task 703 A Data Transfer Task may concern the reporting of Measurement 704 Results (when the timing could be every hour or immediately, for 705 instance). Alternatively, a Data Transfer Task may concern the MA 706 informing the Controller about its Capabilities or any Failures. 708 o configuration of the Measurement Schedules, each of which needs: 710 * the name of one or several Measurement Task configurations 712 * the timing of when the Measurement Tasks are to be performed. 713 Possible types of timing are periodic, calendar-based periodic, 714 one-off immediate and one-off at a future time 716 * the name of a Data Transfer Task or Tasks on which to report 717 the Measurement Results 719 * a name for this Measurement Schedule 721 o Suppression information, if any (see Section 5.2.1.1) 723 A single Instruction Message may contain some or all of the above 724 parts. The finest level of granularity possible in an Instruction 725 Message is determined by the implementation and operation of the 726 Control Protocol. For example, a single Instruction Message may be 727 able to add or update an individual Measurement Schedule - or it may 728 only be able to update the complete set of Measurement Schedules; a 729 single Instruction Message may be able to update both Measurement 730 Schedules and Measurement Task configurations - or only one at a 731 time; and so on. 733 The MA informs the Controller that it has successfully understood the 734 Instruction Message, or that it cannot action the Instruction - for 735 example, if it doesn't include a parameter that is mandatory for the 736 requested Measurement Method, or it is missing details of the target 737 Collector. 739 The Instruction Message instructs the MA; the Control Protocol does 740 not allow the MA to negotiate, as this would add complexity to the 741 MA, Controller and Control Protocol for little benefit. 743 5.2.1.1. Suppression 745 The Instruction may include Suppression information. Suppression is 746 used if the measurement system wants to eliminate inessential 747 traffic, because there is some unexpected network issue for example. 748 By default, Suppression means that the MA does not begin any new 749 Active Measurement Task. The impact on other Measurement Tasks is 750 not defined by LMAP; since they do not involve the MA creating any 751 Active Measurement Traffic there is no need to suppress them, however 752 it may be simpler for an implementation to do so. Also, by default 753 Suppression starts immediately and continues until an un-suppress 754 message is received. Optionally the Suppression information may 755 include: 757 o a set of Measurement Tasks to suppress; the others are not 758 suppressed. For example, this could be useful if a particular 759 Measurement Task is overloading a Measurement Peer. 761 o a set of Measurement Schedules to suppress; the others are not 762 suppressed. For example, suppose the measurement system has 763 defined two Schedules, one with the most critical Measurement 764 Tasks and the other with less critical ones that create a lot of 765 Active Measurement Traffic, then it may only want to suppress the 766 second. 768 o a start time, at which suppression begins 770 o an end time, at which suppression ends 772 o that the MA should end its on-going Active Measurement Task(s). 774 Note that Suppression is not intended to permanently stop a 775 Measurement Task (instead, the Controller should send a new 776 Measurement Schedule), nor to permanently disable a MA (instead, some 777 kind of management action is suggested). 779 +-----------------+ +-------------+ 780 | | | Measurement | 781 | Controller |===================================| Agent | 782 +-----------------+ +-------------+ 784 Suppress: 785 [(Measurement Task), -> 786 (Measurement Schedule), 787 start time, 788 end time, 789 on-going suppressed?] 791 Un-suppress -> 793 5.2.2. Capabilities and Failure information 795 The Control Protocol also enables the MA to inform the Controller 796 about various information, such as its Capabilities and any Failures, 797 by the MA operating a Data Transfer Task. It is also possible that a 798 device-specific mechanism beyond the scope of LMAP is used. 800 Capabilities are information about the MA that the Controller needs 801 to know in order to correctly instruct the MA, such as: 803 o the Measurement Methods that the MA supports 804 o the interfaces that the MA has 806 o the version of the MA 808 o the version of the hardware, firmware or software of the device 809 with the MA 811 o but not dynamic information like the currently unused CPU, memory 812 or battery life of the device with the MA. 814 The MA could do this in response to a request from the Controller 815 (for example, if the Controller forgets what the MA can do or 816 otherwise wants to resynchronize what it knows about the MA) or on 817 its own initiative (for example when the MA first communicates with a 818 Controller or if it becomes capable of a new Measurement Method). 819 Another example of the latter case is if the device with the MA re- 820 boots, then the MA should notify its Controller in case its 821 Instruction needs to be updated; to avoid a "mass calling event" 822 after a widespread power restoration affecting many MAs, it is 823 sensible for an MA to pause for a random delay, perhaps in the range 824 of one minute or so. 826 Failure information is sent on the initiative of the MA and concerns 827 why the MA has been unable to execute a Measurement Task or Data 828 Transfer Task, for example: 830 o the Measurement Task failed to run properly because the MA 831 (unexpectedly) has no spare CPU cycles 833 o the MA failed record the Measurement Results because it 834 (unexpectedly) is out of spare memory 836 o a Data Transfer Task failed to deliver Measurement Results because 837 the Collector (unexpectedly) is not responding 839 o but not if a Measurement Task correctly doesn't start. For 840 example, the first step of some Measurement Methods is for the MA 841 to check there is no cross-traffic. 843 Logging information is sent by the MA in response to a request from 844 the Controller; it concerns how the MA is operating and may help 845 debugging, for example: 847 o the last time the MA ran a Measurement Task 849 o the last time the MA sent a Measurement Report 851 o the last time the MA received an Instruction Message 852 o whether the MA is currently Suppressing Measurement Tasks 854 . 856 +-----------------+ +-------------+ 857 | | | Measurement | 858 | Controller |===================================| Agent | 859 +-----------------+ +-------------+ 861 (Capabilities request) -> 862 <- Capabilities 864 <- Failure Information 865 [reason] 867 Logging request -> 868 <- Logging Information 869 [details] 871 5.3. Operation of Measurement Tasks 873 The LMAP WG is neutral to what the actual Measurement Task is. It 874 does not define Measurement Methods, however the IPPM WG does. 876 The MA carries out the Measurement Tasks as instructed, unless it 877 gets an updated Instruction. The MA acts autonomously, in terms of 878 operation of the Measurement Tasks and reporting of the Results; it 879 doesn't do a 'safety check' with the Controller to ask whether it 880 should still continue with the requested Measurement Tasks. 882 5.3.1. Starting and Stopping Measurement Tasks 884 The WG does not define a generic start and stop process, since the 885 correct approach depends on the particular Measurement Task; the 886 details are defined as part of each Measurement Method. This section 887 provides some general hints. The MA does not inform the Controller 888 about Measurement Tasks starting and stopping. 890 Before sending Active Measurement Traffic the MA may run a pre-check. 891 Action could include: 893 o the MA checking that there is no cross-traffic. In other words, a 894 check that the end-user isn't already sending traffic; 896 o the MA checking with the Measurement Peer (or other Measurement 897 Agent involved in the Measurement Task) that it can handle a new 898 Measurement Task (in case, for example, the Measurement Peer is 899 already handling many Measurement Tasks with other MAs); 901 o the first part of the Measurement Task consisting of traffic that 902 probes the path to make sure it isn't overloaded; 904 o the first part of the Measurement Task checking that the device 905 with the MA has enough resources to execute the Measurement Task 906 reliably. Note that the designer of the measurement system should 907 ensure that the device's capabilities are normally sufficient to 908 comfortably operate the Measurement Tasks. 910 It is possible that similar checks continue during the Measurement 911 Task, especially one that is long-running and/or creates a lot of 912 Active Measurement Traffic, and might lead to it being abandoned 913 whilst in-progress. A Measurement Task could also be abandoned in 914 response to a "suppress" message (see Section 5.2.1). Action could 915 include: 917 o For 'upload' tests, the MA not sending traffic 919 o For 'download' tests, the MA closing the TCP connection or sending 920 a TWAMP Stop control message [RFC5357]. 922 The Controller may want a MA to run the same Measurement Task 923 indefinitely (for example, "run the 'upload speed' Measurement Task 924 once an hour until further notice"). To avoid the MA generating 925 traffic forever after a Controller has permanently failed, it is 926 suggested that the Measurement Schedule includes a time limit ("run 927 the 'upload speed' Measurement Task once an hour for the next 30 928 days") and that the Measurement Schedule is updated regularly (say, 929 every 10 days). 931 5.3.2. Overlapping Measurement Tasks 933 It is possible that a MA starts a new Measurement Task before another 934 Measurement Task has completed. This may be intentional (the way 935 that the measurement system has designed the Measurement Schedules), 936 but it could also be unintentional - for instance, if a Measurement 937 Task has a 'wait for X' step which pauses for an unexpectedly long 938 time. The operator of the measurement system can handle (or not) 939 overlapping Measurement Tasks in any way they choose - it is a policy 940 or implementation issue and not the concern of LMAP. Some possible 941 approaches are: to configure the MA not to begin the second 942 Measurement Task; to start the second Measurement Task as usual; for 943 the action to be an Input Parameter of the Measurement Task; and so 944 on. 946 It is likely to be important to include in the Measurement Report the 947 fact that the Measurement Task overlapped with another. 949 5.4. Report Protocol 951 The primary purpose of the Report Protocol is to allow a Measurement 952 Agent to report its Measurement Results to a Collector, along with 953 the context in which they were obtained. 955 +-----------------+ +-------------+ 956 | | | Measurement | 957 | Collector |===================================| Agent | 958 +-----------------+ +-------------+ 960 <- Report: 961 [MA-ID &/or Group-ID], 962 [Measurement Result 963 [details of Measurement Task]] 964 ACK -> 966 The Report contains: 968 o the MA-ID or a Group-ID (to anonymise results) 970 o the actual Measurement Results, including the time they were 971 measured 973 o the details of the Measurement Task (to avoid the Collector having 974 to ask the Controller for this information later) 976 o perhaps the Subscriber's service parameters (see Section 5.4.1). 978 The MA sends Reports as defined by the Data Transfer Task in the 979 Controller's Instruction. It is possible that the Instruction tells 980 the MA to report the same Results to more than one Collector, or to 981 report a different subset of Results to different Collectors. It is 982 also possible that a Measurement Task may create two (or more) 983 Measurement Results, which could be reported differently (for 984 example, one Result could be reported periodically, whilst the second 985 Result could be an alarm that is created as soon as the measured 986 value of the Metric crosses a threshold and that is reported 987 immediately). 989 Optionally, a Report is not sent when there are no Measurement 990 Results. 992 In the initial LMAP Information Model and Report Protocol, for 993 simplicity we assume that all Measurement Results are reported as-is, 994 but allow extensibility so that a measurement system (or perhaps a 995 second phase of LMAP) could allow a MA to: 997 o label, or perhaps not include, Measurement Results impacted by, 998 for instance, cross-traffic or the Measurement Peer (or other 999 Measurment Agent) being busy 1001 o label Measurement Results obtained by a Measurement Task that 1002 overlapped with another 1004 o not report the Measurement Results if the MA believes that they 1005 are invalid 1007 o detail when Suppression started and ended 1009 5.4.1. Reporting of Subsriber's service parameters 1011 The Subscriber's service parameters are information about his/her 1012 broadband contract, line rate and so on. Such information is likely 1013 to be needed to help analyse the Measurement Results, for example to 1014 help decide whether the measured download speed is reasonable. 1016 The information could be transferred directly from the Subscriber 1017 parameter database to the data analysis tools. It may also be 1018 possible to transfer the information via the MA. How (and if) the MA 1019 knows such information is likely to depend on the device type. The 1020 MA could either include the information in a Measurement Report or 1021 run a separate Data Transfer Task. All such considerations are out 1022 of scope of LMAP. 1024 5.5. Operation of LMAP over the underlying transport protocol 1026 The above sections have described LMAP's protocol model. As part of 1027 the design of the Control and Report Protocols, the LMAP working 1028 group will specify operation over an existing protocol, to be 1029 selected, for example REST-style HTTP(S). It is also possible that a 1030 different choice is made for the Control and Report Protocols, for 1031 example NETCONF-YANG and IPFIX respectively. 1033 From an LMAP perspective, the Controller needs to know that the MA 1034 has received the Instruction Message, or at least that it needs to be 1035 re-sent as it may have failed to be delivered. Similarly the MA 1036 needs to know about the delivery of Capabilities and Failure 1037 information to the Controller and Reports to the Collector. How this 1038 is done depends on the design of the Control and Report Protocols and 1039 the underlying transport protocol. 1041 For the Control Protocol, the underlying transport protocol could be: 1043 o a 'push' protocol (that is, from the Controller to the MA) 1045 o a multicast protocol (from the Controller to a group of MAs) 1047 o a 'pull' protocol. The MA periodically checks with Controller if 1048 the Instruction has changed and pulls a new Instruction if 1049 necessary. A pull protocol seems attractive for a MA behind a NAT 1050 (as is typical for a MA on an end-user's device), so that it can 1051 initiate the communications. A pull mechanism is likely to 1052 require the MA to be configured with how frequently it should 1053 check in with the Controller, and perhaps what it should do if the 1054 Controller is unreachable after a certain number of attempts. 1056 o a hybrid protocol. In addition to a pull protocol, the Controller 1057 can also push an alert to the MA that it should immediately pull a 1058 new Instruction. 1060 For the Report Protocol, the underlying transport protocol could be: 1062 o a 'push' protocol (that is, from the MA to the Collector) 1064 o perhaps supplemented by the ability for the Collector to 'pull' 1065 Measurement Results from a MA. 1067 5.6. Items beyond the scope of the LMAP Protocol Model 1069 There are several potential interactions between LMAP elements that 1070 are out of scope of definition by the LMAP WG: 1072 1. It does not define a coordination process between MAs. Whilst a 1073 measurement system may define coordinated Measurement Schedules 1074 across its various MAs, there is no direct coordination between 1075 MAs. 1077 2. It does not define interactions between the Collector and 1078 Controller. It is quite likely that there will be such 1079 interactions, optionally intermediated by the data analysis 1080 tools. For example, if there is an "interesting" Measurement 1081 Result then the measurement system may want to trigger extra 1082 Measurement Tasks that explore the potential cause in more 1083 detail; or if the Collector unexpectedly does not hear from a MA, 1084 then the measurement system may want to trigger the Controller to 1085 send a fresh Instruction Message to the MA. 1087 3. It does not define coordination between different measurement 1088 systems. For example, it does not define the interaction of a MA 1089 in one measurement system with a Controller or Collector in a 1090 different measurement system. Whilst it is likely that the 1091 Control and Report Protocols could be re-used or adapted for this 1092 scenario, any form of coordination between different 1093 organisations involves difficult commercial and technical issues 1094 and so, given the novelty of large-scale measurement efforts, any 1095 form of inter-organisation coordination is outside the scope of 1096 the LMAP WG. Note that a single MA is instructed by a single 1097 Controller and is only in one measurement system. 1099 * An interesting scenario is where a home contains two 1100 independent MAs, for example one controlled by a regulator and 1101 one controlled by an ISP. Then the Active Measurement Traffic 1102 of one MA is treated by the other MA just like any other end- 1103 user traffic. 1105 4. It does not consider how to prevent a malicious party "gaming the 1106 system". For example, where a regulator is running a measurement 1107 system in order to benchmark operators, a malicious operator 1108 could try to identify the broadband lines that the regulator was 1109 measuring and prioritise that traffic. It is assumed this is a 1110 policy issue and would be dealt with through a code of conduct 1111 for instance. 1113 5. It does not define how to analyse Measurement Results, including 1114 how to interpret missing Results. 1116 6. It does not specifically define a end-user-controlled measurement 1117 system, see sub-section 5.6.1. 1119 5.6.1. End-user-controlled measurement system 1121 The WG concentrates on the cases where an ISP or a regulator runs the 1122 measurement system. However, we expect that LMAP functionality will 1123 also be used in the context of an end-user-controlled measurement 1124 system. There are at least two ways this could happen (they have 1125 various pros and cons): 1127 1. an end-user could somehow request the ISP- (or regulator-) run 1128 measurement system to test his/her line. The ISP (or regulator) 1129 Controller would then send an Instruction to the MA in the usual 1130 LMAP way. Note that a user can't directly initiate a Measurement 1131 Task on an ISP- (or regulator-) controlled MA. 1133 2. an end-user could deploy their own measurement system, with their 1134 own MA, Controller and Collector. For example, the user could 1135 implement all three functions onto the same end-user-owned end 1136 device, perhaps by downloading the functions from the ISP or 1137 regulator. Then the LMAP Control and Report Protocols do not 1138 need to be used, but using LMAP's Information Model would still 1139 be beneficial. The Measurement Peer (or other MA involved in the 1140 Measurement Task) could be in the home gateway or outside the 1141 home network; in the latter case the Measurement Peer is highly 1142 likely to be run by a different organisation, which raises extra 1143 privacy considerations. 1145 In both cases there will be some way for the end-user to initiate the 1146 Measurement Task(s). The mechanism is out-of-scope of the LMAP WG, 1147 but could include the user clicking a button on a GUI or sending a 1148 text message. Presumably the user will also be able to see the 1149 Measurement Results, perhaps summarised on a webpage. It is 1150 suggested that these interfaces conform to the LMAP guidance on 1151 privacy in Section 8. 1153 6. Deployment considerations 1155 The Appendix has some examples of possible deployment arrangements of 1156 Measurement Agents and Peers. 1158 6.1. Controller and the measurement system 1160 The Controller should understand both the MA's LMAP Capabilities (for 1161 instance what Measurement Methods it can perform) and about the MA's 1162 other capabilities like processing power and memory. This allows the 1163 Controller to make sure that the Measurement Schedule of Measurement 1164 Tasks and the Reporting Schedule are sensible for each MA that it 1165 Instructs. 1167 An Instruction is likely to include several Measurement Tasks. 1168 Typically these run at different times, but it is also possible for 1169 them to run at the same time. Some Tasks may be compatible, in that 1170 they do not affect each other's Results, whilst with others great 1171 care would need to be taken. 1173 The Controller should ensure that the Active Measurement Tasks do not 1174 have an adverse effect on the end user. Typically Tasks, especially 1175 those that generate a substantial amount of traffic, will include a 1176 pre-check that the user isn't already sending traffic (Section 5.3). 1177 Another consideration is whether Active Measurement Traffic will 1178 impact a Subscriber's bill or traffic cap; if it will, then the 1179 measurement system may need to compensate the Subscriber, for 1180 instance. 1182 The different elements of the Instruction can be updated 1183 independently. For example, the Measurement Tasks could be 1184 configured with different Input Parameters whilst keeping the same 1185 Measurement Schedule. In general this should not create any issues, 1186 since Measurement Methods should be defined so their fundamental 1187 nature does not change for a new value of Input Parameter. There 1188 could be a problem if, for example, a Measurement Task involving a 1189 1kB file upload could be changed into a 1GB file upload. 1191 A measurement system may have multiple Controllers (but note the 1192 overriding principle that a single MA is instructed by a single 1193 Controller at any point in time (Section 4.2)). For example, there 1194 could be different Controllers for different types of MA (home 1195 gateways, tablets) or locations (Ipswich, Edinburgh), for load 1196 balancing or to cope with failure of one Controller. 1198 The measurement system also needs to consider carefully how to 1199 interpret missing Results; for example, if the missing Results are 1200 ignored and the lack of a Report is caused by its broadband being 1201 broken, then the estimate of overall performance, averaged across all 1202 MAs, would be too optimistic. 1204 6.2. Measurement Agent 1206 The Measurement Agent could take a number of forms: a dedicated 1207 probe, software on a PC, embedded into an appliance, or even embedded 1208 into a gateway. A single site (home, branch office etc.) that is 1209 participating in a measurement could make use of one or multiple 1210 Measurement Agents or Measurement Peers in a single measurement. 1212 The Measurement Agent could be deployed in a variety of locations. 1213 Not all deployment locations are available to every kind of 1214 Measurement Agent. There are also a variety of limitations and 1215 trade-offs depending on the final placement. The next sections 1216 outline some of the locations a Measurement Agent may be deployed. 1217 This is not an exhaustive list and combinations may also apply. 1219 6.2.1. Measurement Agent on a networked device 1221 A MA may be embedded on a device that is directly connected to the 1222 network, such as a MA on a smartphone. 1224 6.2.2. Measurement Agent embedded in site gateway 1226 A Measurement Agent embedded with the site gateway, for example a 1227 home router or the edge router of a branch office in a managed 1228 service environment, is one of better places the Measurement Agent 1229 could be deployed. All site-to-ISP traffic would traverse through 1230 the gateway and passive measurements could easily be performed. 1231 Similarly, due to this user traffic visibility, an Active Measurement 1232 Task could be rescheduled so as not to compete with user traffic. 1234 Generally NAT and firewall services are built into the gateway, 1235 allowing the Measurement Agent the option to offer its Controller- 1236 facing management interface outside of the NAT/firewall. This 1237 placement of the management interface allows the Controller to 1238 unilaterally contact the Measurement Agent for instructions. 1239 However, if the site gateway is owned and operated by the service 1240 provider, the Measurement Agent will generally not be directly 1241 available for over the top providers, the regulator, end users or 1242 enterprises. 1244 6.2.3. Measurement Agent embedded behind site NAT /Firewall 1246 The Measurement Agent could also be embedded behind a NAT, a 1247 firewall, or both. In this case the Controller may not be able to 1248 unilaterally contact the Measurement Agent unless either static port 1249 forwarding configuration or firewall pin holing is configured. For 1250 the former, protocols such as PCP [RFC6887], TR-069 [TR-069]or UPnP 1251 [UPnP]could be used. For the latter, the Measurement Agent could 1252 send keepalives towards the Controller to prop open the firewall (and 1253 perhaps use these also as a network reachability test). 1255 6.2.4. Multi-homed Measurement Agent 1257 If the device with the Measurement Agent is single homed then there 1258 is no confusion about what interface to measure. Similarly, if the 1259 MA is at the gateway and the gateway only has a single WAN-side and a 1260 single LAN-side interface, there is little confusion - for an Active 1261 Measurement Task, the location of the other MA or Measurement Peer 1262 determines whether the WAN or LAN is measured. 1264 However, the device with the Measurement Agent may be multi-homed. 1265 For example, a home or campus may be connected to multiple broadband 1266 ISPs, such as a wired and wireless broadband provider, perhaps for 1267 redundancy or load- sharing. It may also be helpful to think of dual 1268 stack IPv4 and IPv6 broadband devices as multi-homed. More 1269 generally, Section 3.2 of [I-D.ietf-homenet-arch] describes dual- 1270 stack and multi-homing topologies that might be encountered in a home 1271 network, [RFC6419] provides the current practices of multi-interfaces 1272 hosts, and the Multiple Interfaces (mif) working group covers cases 1273 where hosts are either directly attached to multiple networks 1274 (physical or virtual) or indirectly (multiple default routers, etc.). 1275 In these cases, there needs to be clarity on which network 1276 connectivity option is being measured. 1278 One possibility is to have a Measurement Agent per interface. Then 1279 the Controller's choice of MA determines which interface is measured. 1280 However, if a MA can measure any of the interfaces, then the 1281 Controller defines in the Instruction which interface the MA should 1282 use for a Measurement Task; if the choice of interface is not defined 1283 then the MA uses the default one. Explicit definition is preferred 1284 if the measurement system wants to measure the performance of a 1285 particular network, whereas using the default is better if the 1286 measurement system wants to include the impact of the MA's interface 1287 selection algorithm. In any case, the Measurement Result should 1288 include the network that was measured. 1290 6.3. Measurement Peer 1292 A Measurement Peer participates in Active Measurement Tasks. It may 1293 have specific functionality to enable it to participate in a 1294 particular Measurement Method. On the other hand, other Measurement 1295 Methods may require no special functionality, for example if the 1296 Measurement Agent sends a ping to example.com then the server at 1297 example.com plays the role of a Measurement Peer. 1299 A device may participate in some Measurement Tasks as a Measurement 1300 Agent and in others as a Measurement Peer. 1302 Measurement schedules should account for limited resources in a 1303 Measurement Peer when instructing a MA to execute measurements with a 1304 Measurement Peer. In some measurement protocols, such as [RFC4656] 1305 and [RFC5357], the Measurement Peer can reject a measurement session 1306 or refuse a control connection prior to setting-up a measurement 1307 session and so protect itself from resource exhaustion. This is a 1308 valuable capability because the MP may be used by more than one 1309 organisation. 1311 7. Security considerations 1313 The security of the LMAP framework should protect the interests of 1314 the measurement operator(s), the network user(s) and other actors who 1315 could be impacted by a compromised measurement deployment. The 1316 measurement system must secure the various components of the system 1317 from unauthorised access or corruption. Much of the general advice 1318 contained in section 6 of [RFC4656] is applicable here. 1320 We assume that each Measurement Agent (MA) will receive its 1321 Instructions from a single organisation, which operates the 1322 Controller. These Instructions must be authenticated (to ensure that 1323 they come from the trusted Controller), checked for integrity (to 1324 ensure no-one has tampered with them) and not vulnerable to replay 1325 attacks. If a malicious party can gain control of the MA they can 1326 use it to launch DoS attacks at targets, reduce the end user's 1327 quality of experience and corrupt the Measurement Results that are 1328 reported to the Collector. By altering the Measurement Tasks and/or 1329 the address that Results are reported to, they can also compromise 1330 the confidentiality of the network user and the MA environment (such 1331 as information about the location of devices or their traffic). 1333 The process to upgrade the firmware in an MA is out-of-scope for this 1334 phase of LMAP development, similar to the protocol to bootstrap the 1335 MAs (as specified in the charter). However, systems which provide 1336 remote upgrade must secure authorised access and integrity of the 1337 process. 1339 Reporting by the MA must also be secured to maintain confidentiality. 1340 The results must be encrypted such that only the authorised Collector 1341 can decrypt the results to prevent the leakage of confidential or 1342 private information. In addition it must be authenticated that the 1343 results have come from the expected MA and that they have not been 1344 tampered with. It must not be possible to fool a MA into injecting 1345 falsified data into the measurement platform or to corrupt the 1346 results of a real MA. The results must also be held and processed 1347 securely after collection and analysis. See section 8.5.2 below for 1348 additional considerations on stored data compromise, and section 8.6 1349 on potential mitigations for compromise. 1351 Since Collectors will be contacted repeatedly by MAs using the 1352 Collection Protocol to convey their recent results, a successful 1353 attack to exhaust the communication resources would prevent a 1354 critical operation: reporting. Therefore, all LMAP Collectors should 1355 implement technical mechanisms to: 1357 o limit the number of reporting connections from a single MA 1358 (simultaneous, and connections per unit time). 1360 o limit the transmission rate from a single MA. 1362 o limit the memory/storage consumed by a single MA's reports. 1364 o efficiently reject reporting connections from unknown sources. 1366 o separate resources if multiple authentication strengths are used, 1367 where the resources should be separated according to each class of 1368 strength. 1370 o limit iteration counters to generate keys with both a lower and 1371 upper limit, to prevent an attacking system from requesting the 1372 maximum and causing the Controller to stall on the process (see 1373 section 6 of [RFC5357]). 1375 Many of the above considerations are applicable to Controllers using 1376 a "push" model, where the MA must contact the Controller because NAT 1377 or other network aspect prevents Controllers from contacting MAs 1378 directly. 1380 Availability should also be considered. While the loss of some MAs 1381 may not be considered critical, the unavailability of the Collector 1382 could mean that valuable business data or data critical to a 1383 regulatory process is lost. Similarly, the unavailability of a 1384 Controller could mean that the MAs do not operate a correct 1385 Measurement Schedule. 1387 A malicious party could "game the system". For example, where a 1388 regulator is running a measurement system in order to benchmark 1389 operators, an operator could try to identify the broadband lines that 1390 the regulator was measuring and prioritise that traffic. This 1391 potential issue is currently handled by a code of conduct. It is 1392 outside the scope of the LMAP WG to consider the issue. 1394 8. Privacy Considerations for LMAP 1396 The LMAP Working Group will consider privacy as a core requirement 1397 and will ensure that by default the Control and Report Protocols 1398 operate in a privacy-sensitive manner and that privacy features are 1399 well-defined. 1401 This section provides a set of privacy considerations for LMAP. This 1402 section benefits greatly from the timely publication of [RFC6973]. 1403 Privacy and security (Section 7) are related. In some jurisdictions 1404 privacy is called data protection. 1406 We begin with a set of assumptions related to protecting the 1407 sensitive information of individuals and organisations participating 1408 in LMAP-orchestrated measurement and data collection. 1410 8.1. Categories of Entities with Information of Interest 1412 LMAP protocols need to protect the sensitive information of the 1413 following entities, including individuals and organisations who 1414 participate in measurement and collection of results. 1416 o Individual Internet users: Persons who utilise Internet access 1417 services for communications tasks, according to the terms of 1418 service of a service agreement. Such persons may be a service 1419 Subscriber, or have been given permission by the Subscriber to use 1420 the service. 1422 o Internet service providers: Organisations who offer Internet 1423 access service subscriptions, and thus have access to sensitive 1424 information of individuals who choose to use the service. These 1425 organisations desire to protect their Subscribers and their own 1426 sensitive information which may be stored in the process of 1427 performing Measurement Tasks and collecting and Results. 1429 o Regulators: Public authorities responsible for exercising 1430 supervision of the electronic communications sector, and which may 1431 have access to sensitive information of individuals who 1432 participate in a measurement campaign. Similarly, regulators 1433 desire to protect the participants and their own sensitive 1434 information. 1436 o Other LMAP system operators: Organisations who operate measurement 1437 systems or participate in measurements in some way. 1439 Although privacy is a protection extended to individuals, we include 1440 discussion of ISPs and other LMAP system operators in this section. 1441 These organisations have sensitive information involved in the LMAP 1442 system, and many of the same dangers and mitigations are applicable. 1443 Further, the ISPs store information on their Subscribers beyond that 1444 used in the LMAP system (for instance billing information), and there 1445 should be a benefit in considering all the needs and potential 1446 solutions coherently. 1448 8.2. Examples of Sensitive Information 1450 This section gives examples of sensitive information which may be 1451 measured or stored in a measurement system, and which is to be kept 1452 private by default in the LMAP core protocols. 1454 Examples of Subscriber or authorised Internet user sensitive 1455 information: 1457 o Sub-IP layer addresses and names (MAC address, base station ID, 1458 SSID) 1460 o IP address in use 1462 o Personal Identification (real name) 1464 o Location (street address, city) 1466 o Subscribed service parameters 1468 o Contents of traffic (activity, DNS queries, destinations, 1469 equipment types, account info for other services, etc.) 1471 o Status as a study volunteer and Schedule of (Active) Measurement 1472 Tasks 1474 Examples of Internet Service Provider sensitive information: 1476 o Measurement device identification (equipment ID and IP address) 1478 o Measurement Instructions (choice of measurements) 1480 o Measurement Results (some may be shared, others may be private) 1482 o Measurement Schedule (exact times) 1484 o Network topology (locations, connectivity, redundancy) 1486 o Subscriber billing information, and any of the above Subscriber 1487 information known to the provider. 1489 o Authentication credentials (such as certificates) 1491 Other organisations will have some combination of the lists above. 1492 The LMAP system would not typically expose all of the information 1493 above, but could expose a combination of items which could be 1494 correlated with other pieces collected by an attacker (as discussed 1495 in the section on Threats below). 1497 8.3. Key Distinction Between Active and Passive Measurement Tasks 1499 Passive and Active Measurement Tasks raise different privacy issues. 1501 Passive Measurement Tasks are conducted on a user's traffic, such 1502 that sensitive information is present and stored in the measurement 1503 system (however briefly this storage may be). We note that some 1504 authorities make a distinction on time of storage, and information 1505 that is kept only temporarily to perform a communications function is 1506 not subject to regulation (for example, active queue management, deep 1507 packet inspection). Passive Measurement Tasks could reveal all the 1508 websites a Subscriber visits and the applications and/or services 1509 they use. 1511 Active Measurement Tasks are conducted on traffic which is created 1512 specifically for the purpose. Even if a user host generates Active 1513 Measurement Traffic, there is limited sensitive information about the 1514 Subscriber present and stored in the measurement system compared to 1515 the passive case, as follows: 1517 o IP address in use (and possibly sub-IP addresses and names) 1519 o Status as a study volunteer and Schedule of Active Measurement 1520 Tasks 1522 On the other hand, for a service provider the sensitive information 1523 like Measurement Results is the same for Passive and Active 1524 Measurement Tasks. 1526 From the Subscriber perspective, both Active and Passive Measurement 1527 Tasks potentially expose the description of Internet access service 1528 and specific service parameters, such as subscribed rate and type of 1529 access. 1531 8.4. Privacy analysis of the Communications Models 1533 This section examines each of the protocol exchanges described at a 1534 high level in Section 5 and some example Measurement Tasks, and 1535 identifies specific sensitive information which must be secured 1536 during communication for each case. With the protocol-related 1537 sensitive information identified, we can better consider the threats 1538 described in the following section. 1540 From the privacy perspective, all entities participating in LMAP 1541 protocols can be considered "observers" according to the definition 1542 in [RFC6973]. Their stored information potentially poses a threat to 1543 privacy, especially if one or more of these functional entities has 1544 been compromised. Likewise, all devices on the paths used for 1545 control, reporting, and measurement are also observers. 1547 8.4.1. MA Bootstrapping 1549 Section 5.1 provides the communication model for the Bootstrapping 1550 process. 1552 Although the specification of mechanisms for Bootstrapping the MA are 1553 beyond the LMAP scope, designers should recognize that the 1554 Bootstrapping process is extremely powerful and could cause an MA to 1555 join a new or different LMAP system with a different Controller and 1556 Collector, or simply install new Measurement Methods (for example to 1557 passively record DNS queries). A Bootstrap attack could result in a 1558 breach of the LMAP system with significant sensitive information 1559 exposure depending on the capabilities of the MA, so sufficient 1560 security protections are warranted. 1562 The Bootstrapping process provides sensitive information about the 1563 LMAP system and the organisation that operates it, such as 1565 o Initial Controller IP address or FQDN 1567 o Assigned Controller IP address or FQDN 1569 o Security certificates and credentials 1570 During the Bootstrap process, the MA receives its MA-ID which is a 1571 persistent pseudonym for the Subscriber in the case that the MA is 1572 located at a service demarcation point. Thus, the MA-ID is 1573 considered sensitive information, because it could provide the link 1574 between Subscriber identification and Measurements Results. 1576 Also, the Bootstrap process could assign a Group-ID to the MA. The 1577 specific definition of information represented in a Group-ID is to be 1578 determined, but several examples are envisaged including use as a 1579 pseudonym for a set of Subscribers, a class of service, an access 1580 technology, or other important categories. Assignment of a Group-ID 1581 enables anonymisation sets to be formed on the basis of service type/ 1582 grade/rates. Thus, the mapping between Group-ID and MA-ID is 1583 considered sensitive information. 1585 8.4.2. Controller <-> Measurement Agent 1587 The high-level communication model for interactions between the LMAP 1588 Controller and Measurement Agent is illustrated in Section 5.2. The 1589 primary purpose of this exchange is to authenticate and task a 1590 Measurement Agent with Measurement Instructions, which the 1591 Measurement Agent then acts on autonomously. 1593 Primarily IP addresses and pseudonyms (MA-ID, Group-ID) are exchanged 1594 with a capability request, then measurement-related information of 1595 interest such as the parameters, schedule, metrics, and IP addresses 1596 of measurement devices. Thus, the measurement Instruction contains 1597 sensitive information which must be secured. For example, the fact 1598 that an ISP is running additional measurements beyond the set 1599 reported externally is sensitive information, as are the additional 1600 Measurements Tasks themselves. The Measurement Schedule is also 1601 sensitive, because an attacker intending to bias the results without 1602 being detected can use this information to great advantage. 1604 An organisation operating the Controller having no service 1605 relationship with a user who hosts the Measurement Agent *could* gain 1606 real-name mapping to a public IP address through user participation 1607 in an LMAP system (this applies to the Measurement Collection 1608 protocol, as well). 1610 8.4.3. Collector <-> Measurement Agent 1612 The high-level communication model for interactions between the 1613 Measurement Agent and Collector is illustrated in Section 5.4. The 1614 primary purpose of this exchange is to authenticate and collect 1615 Measurement Results from a MA, which the MA has measured autonomously 1616 and stored. 1618 The Measurement Results are the additional sensitive information 1619 included in the Collector-MA exchange. Organisations collecting LMAP 1620 measurements have the responsibility for data control. Thus, the 1621 Results and other information communicated in the Collector protocol 1622 must be secured. 1624 8.4.4. Measurement Peer <-> Measurement Agent 1626 Although the specification of the mechanisms for an Active 1627 Measurement Task is beyond the scope of LMAP, it raises potential 1628 privacy issues. The high-level communications model below 1629 illustrates the various exchanges to execute Active Measurement Tasks 1630 and store the Results. 1632 We note the potential for additional observers in the figures below 1633 by indicating the possible presence of a NAT, which has additional 1634 significance to the protocols and direction of initiation. 1636 The various messages are optional, depending on the nature of the 1637 Active Measurement Task. It may involve sending Active Measurement 1638 Traffic from the Measurement Peer to MA, MA to Measurement Peer, or 1639 both. 1641 _________________ _________________ 1642 | | | | 1643 |Measurement Peer |=========== NAT ? ==========|Measurement Agent| 1644 |_________________| |_________________| 1646 <- (Key Negotiation & 1647 Encryption Setup) 1648 (Encrypted Channel -> 1649 Established) 1650 (Announce capabilities -> 1651 & status) 1652 <- (Select capabilities) 1653 ACK -> 1654 <- (Measurement Request 1655 (MA+MP IPAddrs,set of 1656 Metrics, Schedule)) 1657 ACK -> 1659 Active Measurement Traffic <> Active Measurement Traffic 1660 (may/may not be encrypted) (may/may not be encrypted) 1662 <- (Stop Measurement Task) 1664 Measurement Results -> 1665 (if applicable) 1666 <- ACK, Close 1668 This exchange primarily exposes the IP addresses of measurement 1669 devices and the inference of measurement participation from such 1670 traffic. There may be sensitive information on key points in a 1671 service provider's network included. There may also be access to 1672 measurement-related information of interest such as the Metrics, 1673 Schedule, and intermediate results carried in the Active Measurement 1674 Traffic (usually a set of timestamps). 1676 If the Active Measurement Traffic is unencrypted, as found in many 1677 systems today, then both timing and limited results are open to on- 1678 path observers. 1680 8.4.5. Passive Measurement Agent 1682 Although the specification of the mechanisms for a Passive 1683 Measurement Task is beyond the scope of LMAP, it raises potential 1684 privacy issues. 1686 The high-level communications model below illustrates the collection 1687 of user information of interest with the Measurement Agent performing 1688 the monitoring and storage of the Results. This particular exchange 1689 is for passive measurement of DNS Response Time, which most 1690 frequently uses UDP transport. 1692 _________________ ____________ 1693 | | | | 1694 | DNS Server |=========== NAT ? ==========*=======| User client| 1695 |_________________| ^ |____________| 1696 ______|_______ 1697 | | 1698 | Measurement | 1699 | Agent | 1700 |______________| 1702 <- Name Resolution Req 1703 (MA+MP IPAddrs, 1704 Desired Domain Name) 1705 Return Record -> 1707 This exchange primarily exposes the IP addresses of measurement 1708 devices and the intent to communicate with or access the services of 1709 "Domain Name". There may be information on key points in a service 1710 provider's network, such as the address of one of its DNS servers. 1711 The Measurement Agent may be embedded in the user host, or it may be 1712 located in another device capable of observing user traffic. 1714 In principle, any of the user sensitive information of interest 1715 (listed above) can be collected and stored in the passive monitoring 1716 scenario and so must be secured. 1718 It would also be possible for a Measurement Agent to source the DNS 1719 query itself. But then, as with any active measurement task, there 1720 are few privacy concerns. 1722 8.4.6. Storage and Reporting of Measurement Results 1724 Although the mechanisms for communicating results (beyond the initial 1725 Collector) are beyond the LMAP scope, there are potential privacy 1726 issues related to a single organisation's storage and reporting of 1727 Measurement Results. Both storage and reporting functions can help 1728 to preserve privacy by implementing the mitigations described below. 1730 8.5. Threats 1732 This section indicates how each of the threats described in [RFC6973] 1733 apply to the LMAP entities and their communication and storage of 1734 "information of interest". 1736 8.5.1. Surveillance 1738 Section 5.1.1 of [RFC6973] describes Surveillance as the "observation 1739 or monitoring of and individual's communications or activities." 1740 Hence all Passive Measurement Tasks are a form of surveillance, with 1741 inherent risks. 1743 Active Measurement Methods which avoid periods of user transmission 1744 indirectly produce a record of times when a subscriber or authorised 1745 user has used their network access service. 1747 Active Measurement Methods may also utilise and store a Subscriber's 1748 currently assigned IP address when conducting measurements that are 1749 relevant to a specific Subscriber. Since the Measurement Results are 1750 time-stamped, they could provide a record of IP address assignments 1751 over time. 1753 Either of the above pieces of information could be useful in 1754 correlation and identification, described below. 1756 8.5.2. Stored Data Compromise 1758 Section 5.1.2 of [RFC6973] describes Stored Data Compromise as 1759 resulting from inadequate measures to secure stored data from 1760 unauthorised or inappropriate access. For LMAP systems this includes 1761 deleting or modifying collected measurement records, as well as data 1762 theft. 1764 The primary LMAP entity subject to compromise is the repository, 1765 which stores the Measurement Results; extensive security and privacy 1766 threat mitigations are warranted. The Collector and MA also store 1767 sensitive information temporarily, and need protection. The 1768 communications between the local storage of the Collector and the 1769 repository is beyond the scope of the LMAP work at this time, though 1770 this communications channel will certainly need protection as well as 1771 the mass storage itself. 1773 The LMAP Controller may have direct access to storage of Subscriber 1774 information (location, billing, service parameters, etc.) and other 1775 information which the controlling organisation considers private, and 1776 again needs protection. 1778 Note that there is tension between the desire to store all raw 1779 results in the LMAP Collector (for reproduceability and custom 1780 analysis), and the need to protect the privacy of measurement 1781 participants. Many of the compromise mitigations described in 1782 section 8.6 below are most efficient when deployed at the MA, 1783 therefore minimizing the risks with stored results. 1785 8.5.3. Correlation and Identification 1787 Sections 5.2.1 and 5.2.2 of [RFC6973] describes Correlation as 1788 combining various pieces of information to obtain desired 1789 characteristics of an individual, and Identification as using this 1790 process to infer identity. 1792 The main risk is that the LMAP system could unwittingly provide a key 1793 piece of the correlation chain, starting with an unknown Subscriber's 1794 IP address and another piece of information. For example, a 1795 Subscriber utilised Internet access from 2000 to 2310 UTC, because 1796 the Active Measurement Tasks were deferred, or sent a name resolution 1797 for www.example.com at 2300 UTC. 1799 8.5.4. Secondary Use and Disclosure 1801 Sections 5.2.3 and 5.2.4 of [RFC6973] describes Secondary Use as 1802 unauthorised utilisation of an individual's information for a purpose 1803 the individual did not intend, and Disclosure is when such 1804 information is revealed causing other's notions of the individual to 1805 change, or confidentiality to be violated. 1807 Passive Measurement Tasks are a form of Secondary Use, and the 1808 Subscribers' permission and the measured ISP's permission should be 1809 obtained beforehand. Although user traffic is only indirectly 1810 involved, the Measurement Results from Active Measurement Tasks 1811 provide some limited information about the Subscriber/ISP and could 1812 be used for Secondary Uses. For example, the use of the Results in 1813 unauthorised marketing campaigns would qualify as Secondary Use. 1815 8.6. Mitigations 1817 This section examines the mitigations listed in section 6 of 1818 [RFC6973] and their applicability to LMAP systems. Note that each 1819 section in [RFC6973] identifies the threat categories that each 1820 technique mitigates. 1822 8.6.1. Data Minimisation 1824 Section 6.1 of [RFC6973] encourages collecting and storing the 1825 minimal information needed to perform a task. 1827 There are two levels of information needed for LMAP results to be 1828 useful for a specific task: troubleshooting and general results 1829 reporting. 1831 For general results, the results can be aggregated into large 1832 categories (the month of March, all subscribers West of the 1833 Mississippi River). In this case, all individual identifications 1834 (including IP address of the MA) can be excluded, and only relevant 1835 results are provided. However, this implies a filtering process to 1836 reduce the information fields, because greater detail was needed to 1837 conduct the Measurement Tasks in the first place. 1839 For troubleshooting, so that a network operator or end user can 1840 identify a performance issue or failure, potentially all the network 1841 information (IP addresses, equipment IDs, location), Measurement 1842 Schedule, service configuration, Measurement Results, and other 1843 information may assist in the process. This includes the information 1844 needed to conduct the Measurements Tasks, and represents a need where 1845 the maximum relevant information is desirable, therefore the greatest 1846 protections should be applied. 1848 We note that a user may give temporary permission for Passive 1849 Measurement Tasks to enable detailed troubleshooting, but withhold 1850 permission for them in general. Here the greatest breadth of 1851 sensitive information is potentially exposed, and the maximum privacy 1852 protection must be provided. 1854 For MAs with access to the sensitive information of users (e.g., 1855 within a home or a personal host/handset), it is desirable for the 1856 results collection to minimise the data reported, but also to balance 1857 this desire with the needs of troubleshooting when a service 1858 subscription exists between the user and organisation operating the 1859 measurements. 1861 For passive measurements where the MA reports flow information to the 1862 Collector, the Collector may perform pre-storage minimisation and 1863 other mitigations (below) to help preserve privacy. 1865 8.6.2. Anonymity 1867 Section 6.1.1 of [RFC6973] describes a way in which anonymity is 1868 achieved: "there must exist a set of individuals that appear to have 1869 the same attributes as the individual", defined as an "anonymity 1870 set". 1872 Experimental methods for anonymisation of user identifiable data 1873 applicable to Passive Measurement Methods have been identified in 1874 [RFC6235]. However, the findings of several of the same authors is 1875 that "there is increasing evidence that anonymisation applied to 1876 network trace or flow data on its own is insufficient for many data 1877 protection applications as in [Bur10]." 1879 Essentially, the details of passive measurement tasks can only be 1880 accessed by closed organisations, and unknown injection attacks are 1881 always less expensive than the protections from them. However, some 1882 forms of summary may protect the user's sensitive information 1883 sufficiently well, and so each Metric must be evaluated in the light 1884 of privacy. 1886 The methods in [RFC6235] could be applied more successfully in Active 1887 Measurement Methods, where there are protections from injection 1888 attack. The successful attack would require breaking the integrity 1889 protection of the LMAP Reporting Protocol and injecting Measurement 1890 Results (known fingerprint, see section 3.2 of [RFC6973]) for 1891 inclusion with the shared and anonymised results, then fingerprinting 1892 those records to ascertain the anonymisation process. 1894 Beside anonymisation of measured Results for a specific user or 1895 provider, the value of sensitive information can be further diluted 1896 by summarising the results over many individuals or areas served by 1897 the provider. There is an opportunity enabled by forming anonymity 1898 sets [RFC6973] based on the reference path measurement points in 1899 [I-D.ietf-ippm-lmap-path]. For example, all measurements from the 1900 Subscriber device can be identified as "mp000", instead of using the 1901 IP address or other device information. The same anonymisation 1902 applies to the Internet Service Provider, where their Internet 1903 gateway would be referred to as "mp190". 1905 8.6.3. Pseudonymity 1907 Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, 1908 are a possible mitigation to revealing one's true identity, since 1909 there is no requirement to use real names in almost all protocols. 1911 A pseudonym for a measurement device's IP address could be an LMAP- 1912 unique equipment ID. However, this would likely be a permanent 1913 handle for the device, and long-term use weakens a pseudonym's power 1914 to obscure identity. 1916 8.6.4. Other Mitigations 1918 Data can be de-personalised by blurring it, for example by adding 1919 synthetic data, data-swapping, or perturbing the values in ways that 1920 can be reversed or corrected. 1922 Sections 6.2 and 6.3 of [RFC6973] describe User Participation and 1923 Security, respectively. 1925 Where LMAP measurements involve devices on the Subscriber's premises 1926 or Subscriber-owned equipment, it is essential to secure the 1927 Subscriber's permission with regard to the specific information that 1928 will be collected. The informed consent of the Subscriber (and, if 1929 different, the end user) is needed, including the specific purpose of 1930 the measurements. The approval process could involve showing the 1931 Subscriber their measured information and results before instituting 1932 periodic collection, or before all instances of collection, with the 1933 option to cancel collection temporarily or permanently. 1935 It should also be clear who is legally responsible for data 1936 protection (privacy); in some jurisdictions this role is called the 1937 'data controller'. It is good practice to time limit the storage of 1938 personal information. 1940 Although the details of verification would be impenetrable to most 1941 subscribers, the MA could be architected as an "app" with open 1942 source-code, pre-download and embedded terms of use and agreement on 1943 measurements, and protection from code modifications usually provided 1944 by the app-stores. Further, the app itself could provide data 1945 reduction and temporary storage mitigations as appropriate and 1946 certified through code review. 1948 LMAP protocols, devices, and the information they store clearly need 1949 to be secure from unauthorised access. This is the hand-off between 1950 privacy and security considerations (Section 7). The Data Controller 1951 has the (legal) responsibility to maintain data protections described 1952 in the Subscriber's agreement and agreements with other 1953 organisations. 1955 9. IANA Considerations 1957 There are no IANA considerations in this memo. 1959 10. Appendix: Deployment examples 1961 In this section we describe some deployment scenarios that are 1962 feasible within the LMAP framework defined in this document. 1964 The LMAP framework defines two types of components involved in the 1965 actual measurement task, namely the Measurement Agent (MA) and the 1966 Measurement Peer (MP). The fundamental difference conveyed in the 1967 definition of these terms is that the MA has a interface with the 1968 Controller/Collector while the MP does not. The MP is broadly 1969 defined as a function that assists the MA in the Measurement Task but 1970 has no interface with the Controller/Collector. There are many 1971 elements in the network that can fall into this broad definition of 1972 MP. We believe that the MP terminology is useful to allow us to 1973 refer an element of the network that plays a role that is 1974 conceptually important to understand and describe the measurement 1975 task being performed. We next illustrate these concepts by 1976 describing several deployment scenarios. 1978 A very simple example of a Measurement Peer is a web server that the 1979 MA is downloading a web page from (such as www.example.com) in order 1980 to perform a speed test. The web server is an MP and from its 1981 perspective, the MA is just another customer; the MP doesn't have a 1982 specific function for assisting measurements. This is described in 1983 the figure A1. 1985 ^ 1986 +----------------+ Web Traffic +----------------+ IPPM 1987 | Web Client |<------------>| MP: Web Server | Scope 1988 | | +----------------+ | 1989 ...|................|....................................V... 1990 | LMAP interface | ^ 1991 +----------------+ | 1992 ^ | | 1993 Instruction | | Report | 1994 | +-----------------+ | 1995 | | | 1996 | v LMAP 1997 +------------+ +------------+ Scope 1998 | Controller | | Collector | | 1999 +------------+ +------------+ V 2001 Figure A1: Schematic of LMAP-based measurement system, 2002 with Web server as Measurement Peer 2004 Another case that is slightly different than this would be the one of 2005 a ping responder. This is also an MP, with a helper function, the 2006 ping server, which is specially deployed to assist the MAs that 2007 perform pings. It only has the data plane interface. This example 2008 is described in Section 2. 2010 A third related example would be the case of a traceroute like 2011 measurement. In this case, for each packet sent, the router where 2012 the TTL expires is performing the MP function. So for a given 2013 Measurement Task, there is one MA involved and several MPs, one per 2014 hop. 2016 In figure A2 we depict the case of an OWAMP responder acting as an 2017 MP. In this case, the helper function in addition reports results 2018 back to the MA. So it has both a data plane and control interface 2019 with the MA. 2021 +----------------+ OWAMP +----------------+ ^ 2022 | OWAMP |<--control--->| MP: | | 2023 | control-client |>test-traffic>| OWAMP server & | IPPM 2024 | fetch-client & |<----fetch----| session-rec'ver| Scope 2025 | session-sender | | | | 2026 | | +----------------+ | 2027 ...|................|....................................v... 2028 | LMAP interface | ^ 2029 +----------------+ | 2030 ^ | | 2031 Instruction | | Report | 2032 | +-----------------+ | 2033 | | | 2034 | v LMAP 2035 +------------+ +------------+ Scope 2036 | Controller | | Collector | | 2037 +------------+ +------------+ v 2038 IPPM 2040 Figure A2: Schematic of LMAP-based measurement system, 2041 with OWAMP server as Measurement Peer 2043 However, it is also possible to use two Measurement Agents when 2044 performing one way Measurement Tasks, as described in figure A3 2045 below. In this case, MA1 generates the traffic and MA2 receives the 2046 traffic and send the reports to the Collector. Note that both MAs 2047 are instructed by the Controller. MA1 receives an Instruction to 2048 send the traffic and MA2 receives an Instruction to measured the 2049 received traffic and send Reports to the Collector. 2051 +----------------+ +----------------+ ^ 2052 | MA1 | | MA2 | IPPM 2053 | iperf -u sender|-UDP traffic->| iperf -u recvr | Scope 2054 | | | | v 2055 ...|................|..............|................|....v... 2056 | LMAP interface | | LMAP interface | ^ 2057 +----------------+ +----------------+ | 2058 ^ ^ | | 2059 Instruction | Instruction{Report} | | Report | 2060 {task, | +-------------------+ | | 2061 schedule} | | | | 2062 | | v LMAP 2063 +------------+ +------------+ Scope 2064 | Controller | | Collector | | 2065 +------------+ +------------+ v 2066 IPPM 2068 Figure A3: Schematic of LMAP-based measurement system, 2069 with two Measurement Agents cooperating to measure UDP traffic 2071 Next, we consider Passive Measurement Tasks. Traffic generated in 2072 one point in the network flowing towards a given destination and the 2073 traffic is passively observed in some point along the path. One way 2074 to implement this is that the endpoints generating and receiving the 2075 traffic are not instructed by the Controller; hence they are MPs. 2076 The MA is located along the path with a passive monitor function that 2077 measures the traffic. The MA is instructed by the Controller to 2078 monitor that particular traffic and to send the Report to the 2079 Collector. It is depicted in figure A4 below. 2081 +-----+ +----------------+ +------+ ^ 2082 | MP | | Passive Monitor| | MP | IPPM 2083 | |<--|----------------|---traffic--->| | Scope 2084 +-----+ | | +------+ | 2085 .......|................|.........................v........... 2086 | LMAP interface | ^ 2087 +----------------+ | 2088 ^ | | 2089 Instruction | | Report | 2090 | +-----------------+ | 2091 | | | 2092 | v LMAP 2093 +------------+ +------------+ Scope 2094 | Controller | | Collector | | 2095 +------------+ +------------+ v 2097 Figure A4: Schematic of LMAP-based measurement system, 2098 with a Measurement Agent passively monitoring traffic 2100 Finally, we should consider the case of a router or a switch along 2101 the measurement path. This certainly performs an important role in 2102 the measurement - if packets are not forwarded, the measurement task 2103 will not work. Whilst it doesn't has an interface with the 2104 Controller or Collector, and so fits into the definition of MP, 2105 usually it is not particularly useful to highlight it as a MP. 2107 11. Acknowledgments 2109 This document is a merger of three individual drafts: draft-eardley- 2110 lmap-terminology-02, draft-akhter-lmap-framework-00, and draft- 2111 eardley-lmap-framework-02. 2113 Thanks to Juergen Schoenwaelder for his detailed review of the 2114 terminology. Thanks to Charles Cook for a very detailed review of 2115 -02. 2117 Thanks to numerous people for much discussion, directly and on the 2118 LMAP list (apologies to those unintentionally omitted): Alan Clark, 2119 Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian 2120 Trammell, Charles Cook, Dave Thorne, Frode Soerensen, Greg Mirsky, 2121 Guangqing Deng, Jason Weil, Jean-Francois Tremblay, Jerome Benoit, 2122 Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, Ken Ko, Michael 2123 Bugenhagen, Rolf Winter, Sam Crawford, Sharam Hakimi, Steve Miller, 2124 Ted Lemon, Timothy Carey, Vaibhav Bajpai, William Lupton. 2126 Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on 2127 the Leone research project, which receives funding from the European 2128 Union Seventh Framework Programme [FP7/2007-2013] under grant 2129 agreement number 317647. 2131 12. History 2133 First WG version, copy of draft-folks-lmap-framework-00. 2135 12.1. From -00 to -01 2137 o new sub-section of possible use of Group-IDs for privacy 2139 o tweak to definition of Control protocol 2141 o fix typo in figure in S5.4 2143 12.2. From -01 to -02 2145 o change to INFORMATIONAL track (previous version had typo'd 2146 Standards track) 2148 o new definitions for Capabilities Information and Failure 2149 Information 2151 o clarify that diagrams show LMAP-level information flows. 2152 Underlying protocol could do other interactions, eg to get through 2153 NAT or for Collector to pull a Report 2155 o add hint that after a re-boot should pause random time before re- 2156 register (to avoid mass calling event) 2158 o delete the open issue "what happens if a Controller fails" (normal 2159 methods can handle) 2161 o add some extra words about multiple Tasks in one Schedule 2163 o clarify that new Schedule replaces (rather than adds to) and old 2164 one. Similarly for new configuration of Measurement Tasks or 2165 Report Channels. 2167 o clarify suppression is temporary stop; send a new Schedule to 2168 permanently stop Tasks 2170 o alter suppression so it is ACKed 2172 o add un-suppress message 2173 o expand the text on error reporting, to mention Reporting failures 2174 (as well as failures to action or execute Measurement Task & 2175 Schedule) 2177 o add some text about how to have Tasks running indefinitely 2179 o add that optionally a Report is not sent when there are no 2180 Measurement Results 2182 o add that a Measurement Task may create more than one Measurement 2183 Result 2185 o clarify /amend /expand that Reports include the "raw" Measurement 2186 Results - any pre-processing is left for lmap2.0 2188 o add some cautionary words about what if the Collector unexpectedly 2189 doesn't hear from a MA 2191 o add some extra words about the potential impact of Measurement 2192 Tasks 2194 o clarified various aspects of the privacy section 2196 o updated references 2198 o minor tweaks 2200 12.3. From -02 to -03 2202 o alignment with the Information Model 2203 [I-D.burbridge-lmap-information-model] as this is agreed as a WG 2204 document 2206 o One-off and periodic Measurement Schedules are kept separate, so 2207 that they can be updated independently 2209 o Measurement Suppression in a separate sub-section. Can now 2210 optionally include particular Measurement Tasks &/or Schedules to 2211 suppress, and start/stop time 2213 o for clarity, concept of Channel split into Control, Report and MA- 2214 to-Controller Channels 2216 o numerous editorial changes, mainly arising from a very detailed 2217 review by Charles Cook 2219 o 2221 12.4. From -03 to -04 2223 o updates following the WG Last Call, with the proposed consensus on 2224 the various issues as detailed in http://tools.ietf.org/agenda/89/ 2225 slides/slides-89-lmap-2.pdf. In particular: 2227 o tweaked definitions, especially of Measurement Agent and 2228 Measurement Peer 2230 o Instruction - left to each implementation & deployment of LMAP to 2231 decide on the granularity at which an Instruction Message works 2233 o words added about overlapping Measurement Tasks (measurement 2234 system can handle any way they choose; Report should mention if 2235 the Task overlapped with another) 2237 o Suppression: no defined impact on Passive Measurement Task; extra 2238 option to suppress on-going Active Measurement Tasks; suppression 2239 doesn't go to Measurement Peer, since they don't understand 2240 Instructions 2242 o new concept of Data Transfer Task (and therefore adjustment of the 2243 Channel concept) 2245 o enhancement of Results with Subscriber's service parameters - 2246 could be useful, don't define how but can be included in Report to 2247 various other sections 2249 o various other smaller improvements, arising from the WGLC 2251 o Appendix added with examples of Measurement Agents and Peers in 2252 various deployment scenarios. To help clarify what these terms 2253 mean. 2255 o 2257 13. Informative References 2259 [Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, 2260 "The Role of Network Trace anonymisation Under Attack", 2261 January 2010. 2263 [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- 2264 evolved UMTS core network", 2265 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 2267 [TR-069] TR-069, , "CPE WAN Management Protocol", 2268 http://www.broadband-forum.org/technical/trlist.php, 2269 November 2013. 2271 [UPnP] ISO/IEC 29341-x, , "UPnP Device Architecture and UPnP 2272 Device Control Protocols specifications", 2273 http://upnp.org/sdcps-and-certification/standards/, 2011. 2275 [RFC1035] Mockapetris, P., "Domain names - implementation and 2276 specification", STD 13, RFC 1035, November 1987. 2278 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 2279 June 2005. 2281 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2282 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2283 2005. 2285 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2286 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2287 RFC 5357, October 2008. 2289 [I-D.ietf-lmap-use-cases] 2290 Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen, 2291 "Large-Scale Broadband Measurement Use Cases", draft-ietf- 2292 lmap-use-cases-02 (work in progress), January 2014. 2294 [I-D.manyfolks-ippm-metric-registry] 2295 Bagnulo, M., Claise, B., Eardley, P., and A. Morton, 2296 "Registry for Performance Metrics", draft-manyfolks-ippm- 2297 metric-registry-00 (work in progress), February 2014. 2299 [I-D.ietf-homenet-arch] 2300 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 2301 "IPv6 Home Networking Architecture Principles", draft- 2302 ietf-homenet-arch-13 (work in progress), March 2014. 2304 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 2305 Multiple-Interface Hosts", RFC 6419, November 2011. 2307 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 2308 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2309 2013. 2311 [I-D.burbridge-lmap-information-model] 2312 Burbridge, T., Eardley, P., Bagnulo, M., and J. 2313 Schoenwaelder, "Information Model for Large-Scale 2314 Measurement Platforms (LMAP)", draft-burbridge-lmap- 2315 information-model-01 (work in progress), October 2013. 2317 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 2318 Support", RFC 6235, May 2011. 2320 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2321 Morris, J., Hansen, M., and R. Smith, "Privacy 2322 Considerations for Internet Protocols", RFC 6973, July 2323 2013. 2325 [I-D.ietf-ippm-lmap-path] 2326 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 2327 A. Morton, "A Reference Path and Measurement Points for 2328 LMAP", draft-ietf-ippm-lmap-path-02 (work in progress), 2329 February 2014. 2331 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 2332 Zekauskas, "A One-way Active Measurement Protocol 2333 (OWAMP)", RFC 4656, September 2006. 2335 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2336 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 2337 RFC 5357, October 2008. 2339 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2340 Information Models and Data Models", RFC 3444, January 2341 2003. 2343 Authors' Addresses 2345 Philip Eardley 2346 BT 2347 Adastral Park, Martlesham Heath 2348 Ipswich 2349 ENGLAND 2351 Email: philip.eardley@bt.com 2352 Al Morton 2353 AT&T Labs 2354 200 Laurel Avenue South 2355 Middletown, NJ 2356 USA 2358 Email: acmorton@att.com 2360 Marcelo Bagnulo 2361 Universidad Carlos III de Madrid 2362 Av. Universidad 30 2363 Leganes, Madrid 28911 2364 SPAIN 2366 Phone: 34 91 6249500 2367 Email: marcelo@it.uc3m.es 2368 URI: http://www.it.uc3m.es 2370 Trevor Burbridge 2371 BT 2372 Adastral Park, Martlesham Heath 2373 Ipswich 2374 ENGLAND 2376 Email: trevor.burbridge@bt.com 2378 Paul Aitken 2379 Cisco Systems, Inc. 2380 96 Commercial Street 2381 Edinburgh, Scotland EH6 6LX 2382 UK 2384 Email: paitken@cisco.com 2386 Aamer Akhter 2387 Cisco Systems, Inc. 2388 7025 Kit Creek Road 2389 RTP, NC 27709 2390 USA 2392 Email: aakhter@cisco.com