idnits 2.17.1 draft-ietf-lmap-framework-03.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 (January 21, 2014) is 3720 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 260 -- Looks like a reference, but probably isn't: '180' on line 260 == Outdated reference: A later version (-06) exists of draft-ietf-lmap-use-cases-01 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-11 == Outdated reference: A later version (-07) exists of draft-ietf-ippm-lmap-path-01 Summary: 0 errors (**), 0 flaws (~~), 4 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: July 25, 2014 AT&T Labs 6 M. Bagnulo 7 UC3M 8 T. Burbridge 9 BT 10 P. Aitken 11 A. Akhter 12 Cisco Systems 13 January 21, 2014 15 A framework for large-scale measurement platforms (LMAP) 16 draft-ietf-lmap-framework-03 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 July 25, 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 . . . . . . . . . . . . . . . . . . . . 15 71 5.2.1. Measurement Suppression . . . . . . . . . . . . . . . 18 72 5.3. Starting and stopping Measurement Tasks . . . . . . . . . 19 73 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 20 74 5.5. Operation of LMAP over the underlying transport protocol 22 75 5.6. Items beyond the scope of the LMAP Protocol Model . . . . 23 76 5.6.1. Enduser-controlled measurement system . . . . . . . . 24 77 6. Deployment considerations . . . . . . . . . . . . . . . . . . 24 78 6.1. Controller . . . . . . . . . . . . . . . . . . . . . . . 24 79 6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 25 80 6.2.1. Measurement Agent embedded in site gateway . . . . . 26 81 6.2.2. Measurement Agent embedded behind site NAT /Firewall 26 82 6.2.3. Measurement Agent in a multi-homed site . . . . . . . 27 83 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 27 84 7. Security considerations . . . . . . . . . . . . . . . . . . . 27 85 8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 28 86 8.1. Categories of Entities with Information of Interest . . . 29 87 8.2. Examples of Sensitive Information . . . . . . . . . . . . 29 88 8.3. Key Distinction Between Active and Passive Measurement 89 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 8.4. Privacy analysis of the Communications Models . . . . . . 31 91 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 31 92 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 32 93 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 33 94 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 33 95 8.4.5. Passive Measurement Agent . . . . . . . . . . . . . . 34 96 8.4.6. Storage and Reporting of Measurement Results . . . . 35 97 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 35 98 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 36 99 8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 36 100 8.5.3. Correlation and Identification . . . . . . . . . . . 36 101 8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 37 102 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 37 103 8.6.1. Data Minimisation . . . . . . . . . . . . . . . . . . 37 104 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 38 105 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 39 106 8.6.4. Other Mitigations . . . . . . . . . . . . . . . . . . 39 107 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 108 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 109 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 110 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 41 111 11.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 41 112 11.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 42 113 12. Informative References . . . . . . . . . . . . . . . . . . . 42 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 116 1. Introduction 118 There is a desire to be able to coordinate the execution of broadband 119 measurements and the collection of measurement results across a large 120 scale set of diverse devices. These devices could be software based 121 agents on PCs, embedded agents in consumer devices (e.g. blu-ray 122 players), service provider controlled devices such as set-top players 123 and home gateways, or simply dedicated probes. It is expected that 124 such a system could easily comprise 100k devices. Such a scale 125 presents unique problems in coordination, execution and measurement 126 result collection. Several use cases have been proposed for large- 127 scale measurements including: 129 o Operators: to help plan their network and identify faults 131 o Regulators: to benchmark several network operators and support 132 public policy development 134 Further details of the use cases can be found at 135 [I-D.ietf-lmap-use-cases]. The LMAP framework should be useful for 136 these, as well as other use cases that the LMAP WG doesn't 137 concentrate on, such as to help end users run diagnostic checks like 138 a network speed test. 140 The LMAP framework has four basic elements: Measurement Agents, 141 Measurement Peers, Controllers and Collectors. 143 Measurement Agents (MAs) perform Measurement Tasks, perhaps in 144 conjunction with Measurement Peers. They are pieces of code that can 145 be executed in specialized hardware (hardware probe) or on a general- 146 purpose device (like a PC or mobile phone). A device with a 147 Measurement Agent may have multiple interfaces (WiFi, Ethernet, DSL, 148 fibre, etc.) and the Measurement Tasks may specify any one of these. 149 Measurement Tasks may be Active (the MA or Measurement Peer generates 150 Active Measurement Traffic), Passive (the MA observes user traffic), 151 or some hybrid form of the two. For Active Measurement Tasks, the MA 152 (or Measurement Peer) generates Active Measurement Traffic and 153 measures some metric associated with its transfer over the path to 154 (or from) a Measurement Peer. For example, one Active Measurement 155 Task could be to measure the UDP latency between the MA and a given 156 Measurement Peer. MAs may also conduct Passive Measurement Tasks 157 through the observation of traffic. The Measurement Tasks themselves 158 may be on IPv4, IPv6, and on various services (DNS, HTTP, XMPP, FTP, 159 VoIP, etc.). 161 The Controller manages one or more MAs by instructing it which 162 Measurement Tasks it should perform and when. For example it may 163 instruct a MA at a home gateway: "Measure the 'UDP latency' with the 164 Measurement Peer mp.example.org; repeat every hour at xx.05". The 165 Controller also manages a MA by instructing it how to report the 166 Measurement Results, for example: "Report results once a day in a 167 batch at 4am". We refer to these as the Measurement Schedule and 168 Report Schedule. 170 The Collector accepts Reports from the MAs with the Results from 171 their Measurement Tasks. Therefore the MA is a device that gets 172 Instructions from the Controller, initiates the Measurement Tasks, 173 and reports to the Collector. 175 There are additional elements that are part of a measurement system, 176 but that are out of the scope for LMAP. We provide a detailed 177 discussion of all the elements in the rest of the document. 179 The desirable features for a large-scale measurement systems we are 180 designing for are: 182 o Standardised - in terms of the Measurement Tasks that they 183 perform, the components, the data models and protocols for 184 transferring information between the components. Amongst other 185 things, standardisation enables meaningful comparisons of 186 measurements made of the same metric at different times and 187 places, and enables the operator of a measurement system to buy 188 the various components from different vendors. Today's systems 189 are proprietary in some or all of these aspects. 191 o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement 192 Agents in every home gateway and edge device such as set-top-boxes 193 and tablet computers. It is expected that a measurement system 194 could easily encompass a few hundred thousand Measurement Agents. 195 Existing systems have up to a few thousand MAs (without judging 196 how much further they could scale). 198 o Diversity - a measurement system should handle different types of 199 Measurement Agent - for example Measurement Agents may come from 200 different vendors, be in wired and wireless networks and be on 201 devices with IPv4 or IPv6 addresses. 203 2. Outline of an LMAP-based measurement system 205 Figure 1 shows the main components of a measurement system, and the 206 interactions of those components. Some of the components are outside 207 the scope of LMAP. In this section we provide an overview of the 208 whole measurement system and we introduce the main terms needed for 209 the LMAP framework. The new terms are capitalized. In the next 210 section we provide a terminology section with a compilation of all 211 the LMAP terms and their definition. The subsequent sections study 212 the LMAP components in more detail. 214 A Measurement Task measures some performance or reliability Metric of 215 interest. An Active Measurement Task involves either a Measurement 216 Agent (MA) injecting Active Measurement Traffic into the network 217 destined for a Measurement Peer, and/or a Measurement Peer sending 218 Active Measurement Traffic to a MA; one of them measures some 219 parameter associated with the transfer of the packet(s). A Passive 220 Measurement Task involves only a MA, which simply observes existing 221 traffic - for example, it could simply count bytes or it might 222 calculate the average loss for a particular flow. 224 It is very useful to standardise Measurement Methods (a Measurement 225 Method is a generalisation of a Measurement Task), so that it is 226 meaningful to compare measurements of the same Metric made at 227 different times and places. It is also useful to define a registry 228 for commonly-used Metrics [I-D.bagnulo-ippm-new-registry-independent] 229 so that a Measurement Method can be referred to simply by its 230 identifier in the registry. The Measurement Methods and registry 231 will hopefully be referenced by other standards organisations. 233 In order for a Measurement Agent and a Measurement Peer to execute an 234 Active Measurement Task, they exchange Active Measurement Traffic. 235 The protocols used for the Active Measurement Traffic is out of the 236 scope of the LMAP WG and falls within the scope of other IETF WGs 237 such as IPPM. 239 For Measurement Results to be truly comparable, as might be required 240 by a regulator, not only do the same Measurement Methods need to be 241 used but also the set of Measurement Tasks should follow a similar 242 Measurement Schedule and be of similar number. The details of such a 243 characterisation plan are beyond the scope of work in IETF although 244 certainly facilitated by IETF's work. 246 The next components we consider are the Measurement Agent (MA), 247 Controller and Collector. The main work of the LMAP working group is 248 to define the Control Protocol between the Controller and MA, and the 249 Report Protocol between the MA and Collector. Section 4 onwards 250 considers the LMAP components in more detail; here we introduce them. 252 The Controller manages a MA by instructing it which Measurement Tasks 253 it should perform and when. For example it may instruct a MA at a 254 home gateway: "Run the 'download speed test' with the Measurement 255 Peer at the end user's first IP point in the network; if the end user 256 is active then delay the test and re-try 1 minute later, with up to 3 257 re-tries; repeat every hour at xx.05 + Unif[0,180] seconds". The 258 Controller also manages a MA by instructing it how to report the 259 Measurement Results, for example: "Report results once a day in a 260 batch at 4am + Unif[0,180] seconds; if the end user is active then 261 delay the report 5 minutes". These are called the Measurement and 262 Report Schedule. As well as periodic Measurement Tasks, a Controller 263 can initiate a one-off (non-recurring) Measurement Task ("Do 264 measurement now", "Report as soon as possible"). 266 The Collector accepts a Report from a MA with the results from its 267 Measurement Tasks. It may also do some post-processing on the 268 results, for instance to eliminate outliers, as they can severely 269 impact the aggregated results. 271 Finally we introduce several components that are out of scope of the 272 LMAP WG and will be provided through existing protocols or 273 applications. They affect how the measurement system uses the 274 Measurement Results and how it decides what set of Measurement Tasks 275 to perform. 277 The MA needs to be bootstrapped with initial details about its 278 Controller, including authentication credentials. The LMAP WG 279 considers the bootstrap process, since it affects the Information 280 Model. However, it does not define a bootstrap protocol, since it is 281 likely to be technology specific and could be defined by the 282 Broadband Forum, CableLabs or IEEE depending on the device. Possible 283 protocols are SNMP, NETCONF or (for Home Gateways) CPE WAN Management 284 Protocol (CWMP) from the Auto Configuration Server (ACS) (as 285 specified in TR-069). 287 A Subscriber parameter database contains information about the line, 288 such as the customer's broadband contract (perhaps 2, 40 or 80Mb/s), 289 the line technology (DSL or fibre), the time zone where the MA is 290 located, and the type of home gateway and MA. These parameters are 291 already gathered and stored by existing operations systems. They may 292 affect the choice of what Measurement Tasks to run and how to 293 interpret the Measurement Results. For example, a download test 294 suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s 295 line. 297 A results repository records all Measurement Results in an equivalent 298 form, for example an SQL database, so that they can easily be 299 accessed by the data analysis tools. The data analysis tools also 300 need to understand the Subscriber's service information, for example 301 the broadband contract. 303 The data analysis tools receive the results from the Collector or via 304 the Results repository. They might visualise the data or identify 305 which component or link is likely to be the cause of a fault or 306 degradation. This information could help the Controller decide what 307 follow-up Measurement Task to perform in order to diagnose a fault. 309 The operator's OAM (Operations, Administration, and Maintenance) uses 310 the results from the tools. 312 ^ 313 | 314 Active IPPM 315 +---------------+ Measurement +-------------+ Scope 316 +------->| Measurement |<------------>| Measurement | v 317 | | Agent | Traffic | Peer | ^ 318 | +---------------+ +-------------+ | 319 | ^ | | 320 | Instruction | | Report | 321 | | +-----------------+ | 322 | | | | 323 | | v LMAP 324 | +------------+ +------------+ Scope 325 | | Controller | | Collector | | 326 | +------------+ +------------+ v 327 | ^ ^ | ^ 328 | | | | | 329 | | +----------+ | | 330 | | | v | 331 +------------+ +----------+ +--------+ +----------+ | 332 |Bootstrapper| |Subscriber|--->| data |<---|repository| Out 333 +------------+ |parameter | |analysis| +----------+ of 334 |database | | tools | Scope 335 +----------+ +--------+ | 336 | 337 v 339 Figure 1: Schematic of main elements of an LMAP-based 340 measurement system 341 (showing the elements in and out of the scope of the LMAP WG) 343 3. Terminology 345 This section defines terminology for LMAP. Please note that defined 346 terms are capitalized. 348 Active Measurement Method (Task): A type of Measurement Method (Task) 349 that involves a Measurement Agent and a Measurement Peer (or possibly 350 Peers), where either the Measurement Agent or the Measurement Peer 351 injects Active Measurement Traffic into the network destined for the 352 other, and which involves one of them measuring some performance or 353 reliability parameter associated with the transfer of the traffic. 355 Active Measurement Traffic: the packet(s) generated by the 356 Measurement Agent and/or the Measurement Peer, as part of an Active 357 Measurement Task. 359 Bootstrap: A process that initialises a Measurement Agent with the 360 information necessary to be integrated into a measurement system. 362 Capabilities: Information about the Measurement Methods that the MA 363 can perform and the device hosting the MA, for example its interface 364 type and speed and its IP address. 366 Channel: an Instruction Channel, Report Channel or MA-to-Controller 367 Channel 369 Collector: A function that receives a Report from a Measurement 370 Agent. 372 Composite Metric: A Metric that is a combination of other Metrics, 373 and/or a combination of the same Metric measured over different parts 374 of the network or at different times. 376 Controller: A function that provides a Measurement Agent with 377 Instruction(s). 379 Control Channel: a communications channel between a Controller and a 380 MA, which is defined by a specific Controller, MA and associated 381 security, and over which Instructions are sent. 383 Control Protocol: The protocol delivering Instruction(s) from a 384 Controller to a Measurement Agent. It also delivers Failure 385 Information and Capabilities Information from the Measurement Agent 386 to the Controller. 388 Cycle-ID: (optional) A tag that is sent by the Controller in an 389 Instruction and echoed by the MA in its Report. The same Cycle-ID is 390 used by several MAs that use the same Measurement Method with the 391 same Input Parameters. Hence the Cycle-ID allows the Collector to 392 easily identify Measurement Results that should be comparable. 394 Data Model: The implementation of an Information Model in a 395 particular data modelling language. 397 Environmental Constraint: A parameter that is measured as part of the 398 Measurement Task, its value determining whether the rest of the 399 Measurement Task proceeds. 401 Failure Information: Information about the MA's failure to action or 402 execute an Instruction, whether concerning Measurement Tasks or 403 Reporting. 405 Group-ID: (optional) An identifier of a group of MAs. 407 Information Model: The protocol-neutral definition of the semantics 408 of the Instructions, the Report, the status of the different elements 409 of the measurement system as well of the events in the system. 411 Input Parameter: A parameter whose value is left open by the 412 Measurement Method and is set to a specific value in a Measurement 413 Task. Altering the value of an Input Parameter does not change the 414 fundamental nature of the Measurement Method. 416 Instruction: The description of Measurement Tasks to perform and the 417 details of the Report to send. The Instruction is sent by a 418 Controller to a Measurement Agent. 420 MA-to-Controller Channel: a communications channel between a MA and a 421 Controller, which is defined by a specific Controller, MA and 422 associated security, and over which Capabilities and Failure 423 Information is sent. 425 Measurement Agent (MA): The function that receives Instructions from 426 a Controller, performs Measurement Tasks (perhaps in concert with a 427 Measurement Peer) and reports Measurement Results to a Collector. 429 Measurement Agent Identifier (MA-ID): a UUID [RFC4122], which is 430 configured as part of the Bootstrapping and included in a 431 Capabilities message, Failure Information message and optionally in a 432 Report. 434 Measurement Method: The process for assessing the value of a Metric; 435 the process of measuring some performance or reliability parameter; 436 the generalisation of a Measurement Task. 438 Measurement Peer: The function that receives control messages and 439 Active Measurement Traffic from a Measurement Agent and may reply to 440 the Measurement Agent as defined by the Active Measurement Method. 442 Measurement Result: The output of a single Measurement Task (the 443 value obtained for the parameter of interest or Metric). 445 Measurement Schedule: the schedule for performing Measurement Tasks. 447 Measurement Suppression: a type of Instruction that temporarily stops 448 (suppresses) Active Measurement Tasks. 450 Measurement Task: The act that yields a single Measurement Result; 451 the act consisting of the (single) operation of the Measurement 452 Method at a particular time and with all its parameters set to 453 specific values. 455 Metric: The quantity related to the performance and reliability of 456 the network that we'd like to know the value of, and that is 457 carefully specified. 459 Passive Measurement Method (Task): A Measurement Method (Task) in 460 which a Measurement Agent observes existing traffic but does not 461 inject Active Measurement Traffic. 463 Report: The Measurement Results and other associated information (as 464 defined by the Instruction). The Report is sent by a Measurement 465 Agent to a Collector. 467 Report Channel: a communications channel between a MA and a 468 Collector, which is defined by a specific MA, Collector, Report 469 Schedule and associated security, and over which Reports are sent. 471 Report Protocol: The protocol delivering Report(s) from a Measurement 472 Agent to a Collector. 474 Report Schedule: the schedule for sending one or more Reports to a 475 Collector. 477 Subscriber: An entity (associated with one or more users) that is 478 engaged in a subscription with a service provider. The Subscriber is 479 allowed to subscribe and un-subscribe services, and to register a 480 user or a list of users authorized to enjoy these services. [Q1741] 481 Both the Subscriber and service provider are allowed to set the 482 limits relative to the use that associated users make of subscribed 483 services. 485 4. Constraints 487 The LMAP framework makes some important assumptions, which constrain 488 the scope of the work to be done. 490 4.1. Measurement system is under the direction of a single organisation 492 In the LMAP framework, the measurement system is under the direction 493 of a single organisation that is responsible both for the data and 494 the quality of experience delivered to its users. Clear 495 responsibility is critical given that a misbehaving large-scale 496 measurement system could potentially harm user experience, user 497 privacy and network security. 499 However, the components of an LMAP measurement system can be deployed 500 in administrative domains that are not owned by the measuring 501 organisation. Thus, the system of functions deployed by a single 502 organisation constitutes a single LMAP domain which may span 503 ownership or other administrative boundaries. 505 4.2. Each MA may only have a single Controller at any point in time 507 A MA is instructed by one Controller and is in one measurement 508 system. The constraint avoids different Controllers giving a MA 509 conflicting instructions and so means that the MA does not have to 510 manage contention between multiple Measurement (or Report) Schedules. 511 This simplifies the design of MAs (critical for a large-scale 512 infrastructure) and allows a Measurement Schedule to be tested on 513 specific types of MA before deployment to ensure that the end user 514 experience is not impacted (due to CPU, memory or broadband-product 515 constraints). 517 An operator may have several Controllers, perhaps with a Controller 518 for different types of MA (home gateways, tablets) or location 519 (Ipswich, Edinburgh). 521 5. LMAP Protocol Model 523 A protocol model [RFC4101] presents an architectural model for how 524 the protocol operates and needs to answer three basic questions: 526 1. What problem is the protocol trying to achieve? 528 2. What messages are being transmitted and what do they mean? 530 3. What are the important, but unobvious, features of the protocol? 532 An LMAP system goes through the following phases: 534 o a bootstrapping process before the MA can take part in the other 535 three phases 537 o a Control Protocol, which delivers an Instruction from a 538 Controller to a MA, detailing what Measurement Tasks the MA should 539 perform and when, and how it should report the Measurement Results 541 o the actual Measurement Tasks are performed. An Active Measurement 542 Task involves sending Active Measurement Traffic between the 543 Measurement Agent and a Measurement Peer, whilst a Passive 544 Measurement Task involves (only) the Measurement Agent observing 545 existing user traffic. The LMAP WG does not define Measurement 546 Methods, however the IPPM WG does. 548 o a Report Protocol, which delivers a Report from the MA to a 549 Collector. The Report contains the Measurement Results. 551 In the diagrams the following convention is used: 553 o (optional): indicated by round brackets 555 o [potentially repeated]: indicated by square brackets 557 The protocol model is closely related to the Information Model 558 [I-D.burbridge-lmap-information-model], which is the abstract 559 definition of the information carried by the protocol model. The 560 purpose of both is to provide a protocol and device independent view, 561 which can be implemented via specific protocols. The LMAP WG will 562 define a specific Control Protocol and Report Protocol, but others 563 could be defined by other standards bodies or be proprietary. 564 However it is important that they all implement the same Information 565 Model and protocol model, in order to ease the definition, operation 566 and interoperability of large-scale measurement systems. 568 The diagrams show the various LMAP messages and Section 5.5 considers 569 how they could be mapped onto an underlying transport protocol. 571 5.1. Bootstrapping process 573 The primary purpose of bootstrapping is to enable the MA and 574 Controller to be integrated into a measurement system. In order to 575 do that, the MA needs to retrieve information about itself (like its 576 identity in the measurement system), about the Controller, as well as 577 security information (such as certificates and credentials). 579 +--------------+ 580 | Measurement | 581 | Agent | 582 +--------------+ 583 (initial Controller details: 584 address or FQDN, -> 585 security credentials) 587 +-----------------+ 588 | initial | 589 | Controller | 590 +-----------------+ 591 <- (register) 593 Controller details: 594 address or FQDN, -> 595 security credentials 597 +-----------------+ 598 | | 599 | Controller | 600 +-----------------+ 601 <- register 602 MA-ID, (Group-ID), -> 603 Control Channel, 604 (Suppression Channel), 605 MA-to-Controller Channel 607 The MA knows how to contact a Controller through some device /access 608 specific mechanism. For example, this could be in the firmware, 609 downloaded, manually configured or via a protocol like TR-069. The 610 Controller could either be the one that will send it Instructions or 611 else an initial Controller (whose details may be statically 612 configured). The role of an initial Controller is simply to inform 613 the MA how to contact its actual Controller, for example its FQDN 614 (Fully Qualified Domain Name) [RFC1035]. 616 The MA learns its identifier (MA-ID). It may also be told a Group-ID 617 and whether to include the MA-ID as well as the Group-ID in its 618 Reports. A Group-ID would be shared by several MAs and could be 619 useful for privacy reasons, for instance to hinder tracking of a 620 mobile device. 622 The MA is also told about the Control Channel over which it will 623 receive Instructions from the Controller, in particular the 624 associated security information, for example to enable the MA to 625 decrypt the Instruction. Optionally any Suppression messages can be 626 sent over a different Channel. The MA is also informed about the MA- 627 to-Controller Channel, over which the MA can tell the Controller 628 about its Capabilities and any Failure Information. This consists of 629 the address of the Controller, for instance its URL, and security 630 details for MA-to-Controller messages. 632 The MA may tell the Controller its Capabilities, in particular the 633 Measurement Methods it can perform. 635 If the device with the MA re-boots, then the MA needs to re-register, 636 so that it can receive a new Instruction. To avoid a "mass calling 637 event" after a widespread power restoration affecting many MAs, it is 638 sensible for an MA to pause for a random delay (perhaps in the range 639 of one minute or so) before re-registering. 641 Whilst the LMAP WG considers the bootstrapping process, it is out of 642 scope to define a bootstrap mechanism, as it depends on the type of 643 device and access. 645 5.2. Control Protocol 647 The primary purpose of the Control Protocol is to allow the 648 Controller to configure a Measurement Agent with an Instruction about 649 what Measurement Tasks to do, when to do them, and how to report the 650 Measurement Results. The Measurement Agent then acts on the 651 Instruction autonomously. 653 +-----------------+ +-------------+ 654 | | | Measurement | 655 | Controller |===================================| Agent | 656 +-----------------+ +-------------+ 658 (Capabilities request) -> 659 <- Capabilities 660 ACK -> 662 Instruction: 663 [(Measurement Task (Input Parameters)), -> 664 (Measurement Schedule), 665 (Report Channel(s))] 666 <- ACK 668 <- Failure Information: 669 [reason] 670 ACK -> 671 The Controller needs to know the Capabilities of the MA, and in 672 particular what Measurement Methods it supports, so that it can 673 correctly instruct the MA. It is possible that the Controller knows 674 the MA's Capabilities via some mechanism beyond the scope of LMAP, 675 such as a device-specific protocol. In LMAP, the MA can inform the 676 Controller about its Capabilities. This message could be sent in 677 several circumstances: when the MA first communicates with a 678 Controller; when the MA becomes capable of a new Measurement Method; 679 when requested by the Controller (for example, if the Controller 680 forgets what the MA can do or otherwise wants to resynchronize what 681 it knows about the MA). Note that Capabilities do not include 682 dynamic information like the MA's currently unused CPU, memory or 683 battery life. 685 A single Instruction message contains one, two, three or all four of 686 the following elements: 688 o configuration of all the Measurement Tasks, each of which needs: 690 * the Measurement Method, specified as a URN to a registry entry. 691 The registry could be defined by the IETF 692 [I-D.bagnulo-ippm-new-registry-independent], locally by the 693 operator of the measurement system or perhaps by another 694 standards organisation. 696 * any Input Parameters that need to be set for the Measurement 697 Method, such as the address of the Measurement Peer 699 * if the device with the MA has multiple interfaces, then the 700 interface to use 702 * optionally, a Cycle-ID 704 * a name for this Measurement Task configuration 706 o configuration of all the Report Channels, each of which needs: 708 * the address of the Collector, for instance its URL 710 * the timing of when to report Measurement Results, for example 711 every hour or immediately 713 * security for sending the Report, for example the X.509 714 certificate 716 * a name for this Report Channel 718 o the set of periodic Measurement Schedules, each of which needs: 720 * the name of one or several Measurement Task configurations 722 * the timing of when the Measurement Tasks are to be performed. 723 Possible types of timing are periodic and calendar-based 724 periodic 726 * the name of a Report Channel or Channels on which to report the 727 Measurement Results 729 * a name for this Measurement Schedule 731 o the set of one-off Measurement Schedules, each of which needs the 732 same items as for a periodic Measurement Schedule, except that the 733 possible types of timing are one-off immediate and one-off at a 734 future time. 736 A single Instruction message contains one, two, three or all four of 737 the above elements. This allows the different elements to be updated 738 independently at different times and intervals, for example it is 739 likely that the periodic Measurement Schedule will be updated more 740 often than the other elements. 742 Note that an Instruction message replaces (rather than adds to) those 743 elements that it includes. For example, if the message includes 744 (only) a periodic Measurement Schedule, then that replaces the old 745 periodic Measurement Schedule but does not alter the configuration of 746 the Measurement Tasks and Report Channels. 748 Periodic Measurement Schedules contain the name of one or several 749 Measurement Task configurations that are to be carried out on a 750 recurring basis, whilst one-off Measurement Schedules contain non- 751 recurring Measurement Tasks. One-off and periodic Measurement 752 Schedules are kept separate so that the Controller can instruct the 753 MA to perform an ad hoc Measurement Task (for instance to help 754 isolate a fault) without having to re-notify the MA about the 755 periodic Measurement Schedule. 757 Note that the Instruction informs the MA; the Control Protocol does 758 not allow the MA to negotiate, as this would add complexity to the 759 MA, Controller and Control Protocol for little benefit. 761 The MA can inform the Controller about a Failure. There are two 762 broad categories of failure: (1) the MA cannot action the Instruction 763 (for example, it doesn't include a parameter that is mandatory for 764 the requested Measurement Method; or it is missing details of the 765 target Collector). (2) the MA cannot execute the Measurement Task or 766 deliver the Report (for example, the MA unexpectedly has no spare CPU 767 cycles; or the Collector is not responding). Note that it is not 768 considered a failure if a Measurement Task (correctly) doesn't start; 769 for example if the MA detects cross-traffic, this is reported to the 770 Collector in the normal manner. Note also that the MA does not 771 inform the Controller about normal operation of its Measurement Tasks 772 and Reports. 774 In the Figure, ACK means that the message has been delivered 775 successfully. 777 Finally, note that the MA doesn't do a 'safety check' with the 778 Controller (that it should still continue with the requested 779 Measurement Tasks) - nor does it inform the Controller about 780 Measurement Tasks starting and stopping. It simply carries out the 781 Measurement Tasks as instructed, unless it gets an updated 782 Instruction. 784 The LMAP WG will define a Control Protocol and its associated Data 785 Model that implements the Protocol & Information Model. This may be 786 a simple instruction-response protocol. 788 5.2.1. Measurement Suppression 790 Measurement Suppression is used if the measurement system wants to 791 eliminate inessential traffic, because there is some unexpected 792 network issue for example. The Controller instructs the MA to 793 temporarily not begin new Active Measurement Tasks. By default, 794 suppression applies to all Active Measurement Tasks, starts 795 immediately and continues until an un-suppress message is received. 796 Optionally the suppress message may include: 798 o a set of Active Measurement Tasks to suppress; the others are not 799 suppressed. For example, a particular Measurement Task may be 800 overloading a Measurement Peer. 802 o a set of Measurement Schedules to suppress; the others are not 803 suppressed. For example, suppose the measurement system has 804 defined two Schedules, one with the most critical Active 805 Measurement Tasks and the other with less critical ones that 806 create a lot of traffic, then it may only want to suppress the 807 second. 809 o a start time, at which suppression begins 811 o an end time, at which suppression ends. 813 It is not standardised what the impact of Suppression is on: 815 o Passive Measurement Tasks; since they do not create any Active 816 Measurement Traffic there is no need to suppress them, however it 817 may be simpler for an implementation to do so 819 o on-going Active Measurement Tasks; see Section 5.3 821 Note that Suppression is not intended to permanently stop a 822 Measurement Task (instead, the Controller should send a new 823 Measurement Schedule), nor to permanently disable a MA (instead, some 824 kind of management action is suggested). 826 +-----------------+ +-------------+ 827 | | | Measurement | 828 | Controller |===================================| Agent | 829 +-----------------+ +-------------+ 831 Suppress: 832 [(Measurement Task), -> 833 (Measurement Schedule), 834 start time, end time] 835 <- ACK 837 Un-suppress -> 838 <- ACK 840 5.3. Starting and stopping Measurement Tasks 842 The LMAP WG is neutral to what the actual Measurement Task is. The 843 WG does not define a generic start and stop process, since the 844 correct approach depend on the particular Measurement Task; the 845 details are defined as part of each Measurement Method, and hence 846 potentially by the IPPM WG. This section provides some general 847 hints. 849 Once the MA gets its Measurement and Report Schedules from its 850 Controller then it acts autonomously, in terms of operation of the 851 Measurement Tasks and reporting of the result. One implication is 852 that the MA initiates Measurement Tasks. As an example, for the 853 common case where the MA is on a home gateway, the MA initiates a 854 'download speed test' by asking a Measurement Peer to send the file. 856 Many Active Measurement Tasks begin with a pre-check before the test 857 traffic is sent. Action could include: 859 o the MA checking that there is no cross-traffic; in other words, a 860 check that the user isn't already sending traffic; 862 o the MA checking with the Measurement Peer that it can handle a new 863 Measurement Task (in case the Measurement Peer is already handling 864 many Measurement Tasks with other MAs); 866 o the first part of the Measurement Task consisting of traffic that 867 probes the path to make sure it isn't overloaded. 869 It is possible that similar checks continue during the Measurement 870 Task, especially one that is long-running and/or creates a lot of 871 Active Measurement Traffic, which may be abandoned whilst in- 872 progress. A Measurement Task could also be abandoned in response to 873 a "suppress" message (see Section 5.2.1). Action could include: 875 o For 'upload' tests, the MA not sending traffic 877 o For 'download' tests, the MA closing the TCP connection or sending 878 a TWAMP Stop control message [RFC5357]. 880 The Controller may want a MA to run the same Measurement Task 881 indefinitely (for example, "run the 'upload speed' Measurement Task 882 once an hour until further notice"). To avoid the MA generating 883 traffic forever after a Controller has permanently failed, it is 884 suggested that the Measurement Schedule includes a time limit ("run 885 the 'upload speed' Measurement Task once an hour for the next 30 886 days") and that the Measurement Schedule is updated regularly (say, 887 every 10 days). 889 {Comment: It is possible that the set of measurement schedules 890 implies overlapping Measurement Tasks. It is not clear the best 891 thing to do. Our current suggestion is to leave this to the protocol 892 document.} 894 5.4. Report Protocol 896 The primary purpose of the Report Protocol is to allow a Measurement 897 Agent to report its Measurement Results to a Collector, and the 898 context in which they were obtained. 900 +-----------------+ +-------------+ 901 | | | Measurement | 902 | Collector |===================================| Agent | 903 +-----------------+ +-------------+ 905 <- Report: 906 [MA-ID &/or Group-ID, 907 Measurement Results, 908 details of Measurement Task] 909 ACK -> 911 The Report contains: 913 o the MA-ID or a Group-ID (to anonymise results) 915 o the actual Measurement Results, including the time they were 916 measured 918 o the details of the Measurement Task (to avoid the Collector having 919 to ask the Controller for this information later) 921 The MA sends Reports as defined by the Report Channel in the 922 Controller's Instruction. It is possible that the Instruction tells 923 the MA to report the same Results to more than one Collector, or to 924 report a different subset of Results to different Collectors. It is 925 also possible that a Measurement Task may create two (or more) 926 Measurement Results, which could be reported differently (for 927 example, one Result could be reported periodically, whilst the second 928 Result could be an alarm that is created as soon as the measured 929 value of the Metric crosses a threshold and that is reported 930 immediately). 932 Optionally, a Report is not sent when there are no Measurement 933 Results. 935 In the initial LMAP Information Model and Report Protocol, for 936 simplicity we assume that all Measurement Results are reported as-is, 937 but allow extensibility so that a measurement system (or perhaps a 938 second phase of LMAP) could allow a MA to pre-process Measurement 939 Results before it reports them. Potential examples of pre-processing 940 by the MA are: 942 o labelling, or perhaps not including, Measurement Results impacted 943 by, for instance, cross-traffic or the Measurement Peer being busy 945 o not reporting the Measurement Results if the MA believes that they 946 are invalid 948 o detailing when suppression started and ended 950 o filtering outlier Results 952 o calculating some statistic like average (beyond that defined by 953 the Measurement Task itself) 955 The measurement system may define what happens if a Collector 956 unexpectedly does not hear from a MA, for example the Controller 957 could send a fresh Report Schedule to the MA. 959 The LMAP WG will define a Report Protocol and its associated Data 960 Model that implements the Information Model and protocol model. This 961 may be a simple instruction-response protocol. 963 5.5. Operation of LMAP over the underlying transport protocol 965 The above sections have described LMAP's protocol model. The LMAP 966 working group will also specify how it operates over an existing 967 protocol, to be selected, for example REST-style HTTP(S). It is also 968 possible that a different choice is made for the Control and Report 969 Protocols, for example NETCONF-YANG and IPFIX respectively. It is 970 even possible that a different choice could be made for Suppression 971 and for other Instruction messages. 973 For the Control Protocol, the underlying transport protocol could be: 975 o a 'push' protocol (that is, from the Controller to the MA) 977 o a multicast protocol (from the Controller to a group of MAs) 979 o a 'pull' protocol. The MA periodically checks with Controller if 980 the Instruction has changed and pulls a new Instruction if 981 necessary. A pull protocol seems attractive for a MA behind a NAT 982 (as is typical for a MA on an end-user's device), so that it can 983 initiate the communications. A pull mechanism is likely to 984 require the MA to be configured with how frequently it should 985 check in with the Controller, and perhaps what it should do if the 986 Controller is unreachable after a certain number of attempts. 988 o a hybrid protocol. In addition to a pull protocol, the Controller 989 can also push an alert to the MA that it should immediately pull a 990 new Instruction. 992 For the Report Protocol, the underlying transport protocol could be: 994 o a 'push' protocol (that is, from the MA to the Collector) 995 o perhaps supplemented by the ability for the Collector to 'pull' 996 Measurement Results from a MA. 998 5.6. Items beyond the scope of the LMAP Protocol Model 1000 There are several potential interactions between LMAP elements that 1001 are out of scope of definition by the LMAP WG: 1003 1. It does not define a coordination process between MAs. Whilst a 1004 measurement system may define coordinated Measurement Schedules 1005 across its various MAs, there is no direct coordination between 1006 MAs. 1008 2. It does not define interactions between the Collector and 1009 Controller. It is quite likely that there will be such 1010 interactions, optionally intermediated by the data analysis 1011 tools. For example if there is an "interesting" Measurement 1012 Result then the measurement system may want to trigger extra 1013 Measurement Tasks that explore the potential cause in more 1014 detail. 1016 3. It does not define coordination between different measurement 1017 systems. For example, it does not define the interaction of a MA 1018 in one measurement system with a Controller or Collector in a 1019 different measurement system. Whilst it is likely that the 1020 Control and Report Protocols could be re-used or adapted for this 1021 scenario, any form of coordination between different 1022 organisations involves difficult commercial and technical issues 1023 and so, given the novelty of large-scale measurement efforts, any 1024 form of inter-organisation coordination is outside the scope of 1025 the LMAP WG. Note that a single MA is instructed by a single 1026 Controller and is only in one measurement system. 1028 * An interesting scenario is where a home contains two 1029 independent MAs, for example one controlled by a regulator and 1030 one controlled by an ISP. Then the Active Measurement Traffic 1031 of one MA is treated by the other MA just like any other user 1032 traffic. 1034 4. It does not consider how to prevent a malicious party "gaming the 1035 system". For example, where a regulator is running a measurement 1036 system in order to benchmark operators, a malicious operator 1037 could try to identify the broadband lines that the regulator was 1038 measuring and prioritise that traffic. It is assumed this is a 1039 policy issue and would be dealt with through a code of conduct 1040 for instance. 1042 5. It does not define how to analyse Measurement Results, including 1043 how to interpret missing Results. 1045 6. It does not specifically define a enduser-controlled measurement 1046 system, see sub-section 5.6.1. 1048 5.6.1. Enduser-controlled measurement system 1050 The WG concentrates on the cases where an ISP or a regulator runs the 1051 measurement system. However, we expect that LMAP functionality will 1052 also be used in the context of an enduser-controlled measurement 1053 system. There are at least two ways this could happen (they have 1054 various pros and cons): 1056 1. an enduser could somehow request the ISP- (or regulator-) run 1057 measurement system to test his/her line. The ISP (or regulator) 1058 Controller would then send an Instruction to the MA in the usual 1059 LMAP way. Note that a user can't directly initiate a Measurement 1060 Task on an ISP- (or regulator-) controlled MA. 1062 2. an enduser could deploy their own measurement system, with their 1063 own MA, Controller and Collector. For example, the user could 1064 implement all three functions onto the same enduser-owned end 1065 device, perhaps by downloading the functions from the ISP or 1066 regulator. Then the LMAP Control and Report Protocols do not 1067 need to be used, but using LMAP's Information Model would still 1068 be beneficial. The Measurement Peer could be in the home gateway 1069 or outside the home network; in the latter case the Measurement 1070 Peer is highly likely to be run by a different organisation, 1071 which raises extra privacy considerations. 1073 In both cases there will be some way for the user to initiate the 1074 Measurement Task(s). The mechanism is out-of-scope of the LMAP WG, 1075 but could include the user clicking a button on a GUI or sending a 1076 text message. Presumably the user will also be able to see the 1077 Measurement Results, perhaps summarised on a webpage. It is 1078 suggested that these interfaces conform to the LMAP guidance on the 1079 privacy in Section 8. 1081 6. Deployment considerations 1083 6.1. Controller 1085 The Controller should understand both the MA's LMAP Capabilities (for 1086 instance what Measurement Methods it can perform) and about the MA's 1087 other capabilities like processing power and memory. This allows the 1088 Controller to make sure that the Measurement Schedule of Measurement 1089 Tasks and the Reporting Schedule are sensible for each MA that it 1090 Instructs. 1092 An Instruction is likely to include several Measurement Tasks. 1093 Typically these run at different times, but it is also possible for 1094 them to run at the same time, if the Controller is sure that one Task 1095 will not affect the Results of another Task. 1097 The Controller should ensure that the Active Measurement Tasks do not 1098 have an adverse effect on the end user. Typically Tasks, especially 1099 those that generate a substantial amount of traffic, will include a 1100 pre-check that the user isn't already sending traffic (Section 5.3). 1101 Another consideration is whether Active Measurement Traffic will 1102 impact a Subscriber's bill or traffic cap. 1104 The different elements of the Instruction can be updated 1105 independently. For example, the Measurement Tasks could be 1106 configured with different Input Parameters whilst keeping the same 1107 Measurement Schedule. In general this should not create any issues, 1108 since Measurement Methods should be defined so their fundamental 1109 nature does not change for a new value of Input Parameter. There 1110 could be a problem if, for example, a Measurement Task involving a 1111 1kB file upload could be changed into a 1GB file upload. 1113 A measurement system may have multiple Controllers (but note the 1114 overriding principle that a single MA is instructed by a single 1115 Controller at any point in time (Section 4.2)). For example, there 1116 could be different Controllers for different types of MA (home 1117 gateways, tablets) or locations (Ipswich, Edinburgh), for load 1118 balancing or to cope with failure of one Controller. One possibility 1119 is that Bootstrapping involves an initial Controller, whose role is 1120 simply to inform the MA how to contact its actual Controller. 1122 6.2. Measurement Agent 1124 The Measurement Agent could take a number of forms: a dedicated 1125 probe, software on a PC, embedded into an appliance, or even embedded 1126 into a gateway. A single site (home, branch office etc.) that is 1127 participating in a measurement could make use of one or multiple 1128 Measurement Agents in a single measurement. If the site is multi 1129 homed there might be a Measurement Agent per interface. 1131 The Measurement Agent could be deployed in a variety of locations. 1132 Not all deployment locations are available to every kind of 1133 Measurement Agent. There are also a variety of limitations and 1134 trade-offs depending on the final placement. The next sections 1135 outline some of the locations a Measurement Agent may be deployed. 1136 This is not an exhaustive list and combinations may also apply. 1138 If the Instruction includes several Measurement Tasks, these could be 1139 scheduled to run at different times or possibly at the same time - 1140 some Tasks may be compatible, in that they do not affect each other's 1141 Results, whilst with others great care would need to be taken. 1143 The measurement system also needs to consider carefully how to 1144 interpret missing Results; for example, if the missing Results are 1145 ignored and the lack of a Report is caused by its broadband being 1146 broken, then the estimate of overall performance, averaged across all 1147 MAs, would be too optimistic. 1149 6.2.1. Measurement Agent embedded in site gateway 1151 A Measurement Agent embedded with the site gateway, for example a 1152 home router or the edge router of a branch office in a managed 1153 service environment, is one of better places the Measurement Agent 1154 could be deployed. All site-to-ISP traffic would traverse through 1155 the gateway and passive measurements could easily be performed. 1156 Similarly, due to this user traffic visibility, an Active 1157 Measurements Task could be rescheduled so as not to compete with user 1158 traffic. Generally NAT and firewall services are built into the 1159 gateway, allowing the Measurement Agent the option to offer its 1160 Controller facing management interface outside of the NAT/firewall. 1161 This placement of the management interface allows the Controller to 1162 unilaterally contact the Measurement Agent for instructions. 1163 However, if the site gateway is owned and operated by the service 1164 provider, the Measurement Agent will generally not be directly 1165 available for over the top providers, the regulator, end users or 1166 enterprises. 1168 6.2.2. Measurement Agent embedded behind site NAT /Firewall 1170 The Measurement Agent could also be embedded behind a NAT, a 1171 firewall, or both. In this case the Controller may not be able to 1172 unilaterally contact the Measurement Agent unless either static port 1173 forwarding configuration or firewall pin holing is configured, and 1174 might not always be possible. It would require user intervention or 1175 pre-provisioning by the operator via a mechanisms such as TR-069. 1176 The Measurement Agent may originate a session towards the Controller 1177 and maintain the session for bidirectional communications. This 1178 would alleviate the need to have user intervention on the gateway, 1179 but would reduce the overall saleability of the Controller as it 1180 would have to maintain a higher number of active sessions. That 1181 said, sending keepalives to prop open the firewall could serve a dual 1182 purpose in testing network reachability for the Measurement Agent. 1183 An alternative would be to use a protocol such as UPnP or PCP 1184 [RFC6887] to control the NAT/firewall if the gateway supports this 1185 kind of control. 1187 6.2.3. Measurement Agent in a multi-homed site 1189 A broadband site may be multi-homed. For example, the site may be 1190 connected to multiple broadband ISPs, perhaps for redundancy or load- 1191 sharing, or have both wired and wireless broadband connectivity. It 1192 may also be helpful to think of dual stack IPv4 and IPv6 broadband 1193 devices as multi-homed. In these cases, there needs to be clarity on 1194 which network connectivity option is being measured. Sometimes this 1195 is easily resolved by the location of the MA itself. For example, if 1196 the MA is built into the gateway (and the gateway only has a single 1197 WAN side interface), there is little confusion or choice. However, 1198 for multi-homed gateways or devices behind the gateway(s) of multi- 1199 homed sites it would be preferable to explicitly select the network 1200 to measure ([RFC5533]) but the network measured should be included in 1201 the Measurement Result. Section 3.2 of [I-D.ietf-homenet-arch] 1202 describes dual-stack and multi-homing topologies that might be 1203 encountered in a home network (which is generally a broadband 1204 connected site). The Multiple Interfaces (mif) working group covers 1205 cases where hosts are either directly attached to multiple networks 1206 (physical or virtual) or indirectly (multiple default routers, etc.). 1207 [RFC6419] provides the current practices of multi-interfaces hosts 1208 today. As one aim is for a MA is to measure the end user's quality 1209 of experience, it is important to understand the current practices. 1211 6.3. Measurement Peer 1213 A Measurement Peer participates in Active Measurement Tasks. It may 1214 have specific functionality to enable it to participate in a 1215 particular Measurement Method. On the other hand, other Measurement 1216 Methods may require no special functionality, for example if the 1217 Measurement Agent sends a ping to example.com then the server at 1218 example.com plays the role of a Measurement Peer. 1220 A device may participate in some Measurement Tasks as a Measurement 1221 Agent and in others as a Measurement Peer. 1223 7. Security considerations 1225 The security of the LMAP framework should protect the interests of 1226 the measurement operator(s), the network user(s) and other actors who 1227 could be impacted by a compromised measurement deployment. The 1228 measurement system must secure the various components of the system 1229 from unauthorised access or corruption. 1231 We assume that each Measurement Agent (MA) will receive its 1232 Instructions from a single organisation, which operates the 1233 Controller. These Instructions must be authenticated (to ensure that 1234 they come from the trusted Controller), checked for integrity (to 1235 ensure no-one has tampered with them) and not vulnerable to replay 1236 attacks. If a malicious party can gain control of the MA they can 1237 use it to launch DoS attacks at targets, reduce the end user's 1238 quality of experience and corrupt the Measurement Results that are 1239 reported to the Collector. By altering the Measurement Tasks and/or 1240 the address that Results are reported to, they can also compromise 1241 the confidentiality of the network user and the MA environment (such 1242 as information about the location of devices or their traffic). 1244 Reporting by the MA must also be secured to maintain confidentiality. 1245 The results must be encrypted such that only the authorised Collector 1246 can decrypt the results to prevent the leakage of confidential or 1247 private information. In addition it must be authenticated that the 1248 results have come from the expected MA and that they have not been 1249 tampered with. It must not be possible to fool a MA into injecting 1250 falsified data into the measurement platform or to corrupt the 1251 results of a real MA. The results must also be held and processed 1252 securely after collection and analysis. 1254 Availability should also be considered. While the loss of some MAs 1255 may not be considered critical, the unavailability of the Collector 1256 could mean that valuable business data or data critical to a 1257 regulatory process is lost. Similarly, the unavailability of a 1258 Controller could mean that the MAs do not operate a correct 1259 Measurement Schedule. 1261 A malicious party could "game the system". For example, where a 1262 regulator is running a measurement system in order to benchmark 1263 operators, an operator could try to identify the broadband lines that 1264 the regulator was measuring and prioritise that traffic. This 1265 potential issue is currently handled by a code of conduct. It is 1266 outside the scope of the LMAP WG to consider the issue. 1268 8. Privacy Considerations for LMAP 1270 The LMAP Working Group will consider privacy as a core requirement 1271 and will ensure that by default the Control and Report Protocols 1272 operate in a privacy-sensitive manner and that privacy features are 1273 well-defined. 1275 This section provides a set of privacy considerations for LMAP. This 1276 section benefits greatly from the timely publication of [RFC6973]. 1277 Privacy and security (Section 7) are related. In some jurisdictions 1278 privacy is called data protection. 1280 We begin with a set of assumptions related to protecting the 1281 sensitive information of individuals and organisations participating 1282 in LMAP-orchestrated measurement and data collection. 1284 8.1. Categories of Entities with Information of Interest 1286 LMAP protocols need to protect the sensitive information of the 1287 following entities, including individuals and organisations who 1288 participate in measurement and collection of results. 1290 o Individual Internet users: Persons who utilise Internet access 1291 services for communications tasks, according to the terms of 1292 service of a service agreement. Such persons may be a service 1293 Subscriber, or have been given permission by the Subscriber to use 1294 the service. 1296 o Internet service providers: Organisations who offer Internet 1297 access service subscriptions, and thus have access to sensitive 1298 information of individuals who choose to use the service. These 1299 organisations desire to protect their Subscribers and their own 1300 sensitive information which may be stored in the process of 1301 performing Measurement Tasks and collecting and Results. 1303 o Regulators: Public authorities responsible for exercising 1304 supervision of the electronic communications sector, and which may 1305 have access to sensitive information of individuals who 1306 participate in a measurement campaign. Similarly, regulators 1307 desire to protect the participants and their own sensitive 1308 information. 1310 o Other LMAP system operators: Organisations who operate measurement 1311 systems or participate in measurements in some way. 1313 Although privacy is a protection extended to individuals, we include 1314 discussion of ISPs and other LMAP system operators in this section. 1315 These organisations have sensitive information involved in the LMAP 1316 system, and many of the same dangers and mitigations are applicable. 1317 Further, the ISPs store information on their Subscribers beyond that 1318 used in the LMAP system (for instance billing information), and there 1319 should be a benefit in considering all the needs and potential 1320 solutions coherently. 1322 8.2. Examples of Sensitive Information 1324 This section gives examples of sensitive information which may be 1325 measured or stored in a measurement system, and which is to be kept 1326 private by default in the LMAP core protocols. 1328 Examples of Subscriber or authorised Internet user sensitive 1329 information: 1331 o Sub-IP layer addresses and names (MAC address, base station ID, 1332 SSID) 1334 o IP address in use 1336 o Personal Identification (real name) 1338 o Location (street address, city) 1340 o Subscribed service parameters 1342 o Contents of traffic (activity, DNS queries, destinations, 1343 equipment types, account info for other services, etc.) 1345 o Status as a study volunteer and Schedule of (Active) Measurement 1346 Tasks 1348 Examples of Internet Service Provider sensitive information: 1350 o Measurement device identification (equipment ID and IP address) 1352 o Measurement Instructions (choice of measurements) 1354 o Measurement Results (some may be shared, others may be private) 1356 o Measurement Schedule (exact times) 1358 o Network topology (locations, connectivity, redundancy) 1360 o Subscriber billing information, and any of the above Subscriber 1361 information known to the provider. 1363 o Authentication credentials (such as certificates) 1365 Other organisations will have some combination of the lists above. 1366 The LMAP system would not typically expose all of the information 1367 above, but could expose a combination of items which could be 1368 correlated with other pieces collected by an attacker (as discussed 1369 in the section on Threats below). 1371 8.3. Key Distinction Between Active and Passive Measurement Tasks 1373 Passive and Active Measurement Tasks raise different privacy issues. 1375 Passive Measurement Tasks are conducted on a user's traffic, such 1376 that sensitive information is present and stored in the measurement 1377 system (however briefly this storage may be). We note that some 1378 authorities make a distinction on time of storage, and information 1379 that is kept only temporarily to perform a communications function is 1380 not subject to regulation (for example, active queue management, deep 1381 packet inspection). Passive Measurement Tasks could reveal all the 1382 websites a Subscriber visits and the applications and/or services 1383 they use. 1385 Active Measurement Tasks are conducted on traffic which is created 1386 specifically for the purpose. Even if a user host generates Active 1387 Measurement Traffic, there is significantly limited sensitive 1388 information about the Subscriber present and stored in the 1389 measurement system compared to the passive case, as follows: 1391 o IP address in use (and possibly sub-IP addresses and names) 1393 o Status as a study volunteer and Schedule of Active Measurement 1394 Tasks 1396 On the other hand, for a service provider the sensitive information 1397 like Measurement Results is the same for Passive and Active 1398 Measurement Tasks. 1400 From the Subscriber perspective, both Active and Passive Measurement 1401 Tasks potentially expose the description of Internet access service 1402 and specific service parameters, such as subscribed rate and type of 1403 access. 1405 8.4. Privacy analysis of the Communications Models 1407 This section examines each of the protocol exchanges described at a 1408 high level in Section 5 and some example Measurement Tasks, and 1409 identifies specific sensitive information which must be secured 1410 during communication for each case. With the protocol-related 1411 sensitive information identified, we have can better consider the 1412 threats described in the following section. 1414 From the privacy perspective, all entities participating in LMAP 1415 protocols can be considered "observers" according to the definition 1416 in [RFC6973]. Their stored information potentially poses a threat to 1417 privacy, especially if one or more of these functional entities has 1418 been compromised. Likewise, all devices on the paths used for 1419 control, reporting, and measurement are also observers. 1421 8.4.1. MA Bootstrapping 1423 Section 5.1 provides the communication model for the Bootstrapping 1424 process. 1426 Although the specification of mechanisms for Bootstrapping the MA are 1427 beyond the LMAP scope, designers should recognize that the 1428 Bootstrapping process is extremely powerful and could cause an MA to 1429 join a new or different LMAP system with a different Controller and 1430 Collector, or simply install new Measurement Methods (for example to 1431 passively record DNS queries). A Bootstrap attack could result in a 1432 breach of the LMAP system with significant sensitive information 1433 exposure depending on the capabilities of the MA, so sufficient 1434 security protections are warranted. 1436 The Bootstrapping process provides sensitive information about the 1437 LMAP system and the organisation that operates it, such as 1439 o Initial Controller IP address or FQDN 1441 o Assigned Controller IP address or FQDN 1443 o Security certificates and credentials 1445 During the Bootstrap process, the MA receives its MA-ID which is a 1446 persistent pseudonym for the Subscriber in the case that the MA is 1447 located at a service demarcation point. Thus, the MA-ID is 1448 considered sensitive information, because it could provide the link 1449 between Subscriber identification and Measurements Results. 1451 Also, the Bootstrap process could assign a Group-ID to the MA. The 1452 specific definition of information represented in a Group-ID is to be 1453 determined, but several examples are envisaged including use as a 1454 pseudonym for a set of Subscribers, a class of service, an access 1455 technology, or other important categories. Assignment of a Group-ID 1456 enables anonymisation sets to be formed on the basis of service type/ 1457 grade/rates. Thus, the mapping between Group-ID and MA-ID is 1458 considered sensitive information. 1460 8.4.2. Controller <-> Measurement Agent 1462 The high-level communication model for interactions between the LMAP 1463 Controller and Measurement Agent is illustrated in Section 5.2. The 1464 primary purpose of this exchange is to authenticate and task a 1465 Measurement Agent with Measurement Instructions, which the 1466 Measurement Agent then acts on autonomously. 1468 Primarily IP addresses and pseudonyms (MA-ID, Group-ID) are exchanged 1469 with a capability request, then measurement-related information of 1470 interest such as the parameters, schedule, metrics, and IP addresses 1471 of measurement devices. Thus, the measurement Instruction contains 1472 sensitive information which must be secured. For example, the fact 1473 that an ISP is running additional measurements beyond the set 1474 reported externally is sensitive information, as are the additional 1475 Measurements Tasks themselves. The Measurement Schedule is also 1476 sensitive, because an attacker intending to bias the results without 1477 being detected can use this information to great advantage. 1479 An organisation operating the Controller having no service 1480 relationship with a user who hosts the Measurement Agent *could* gain 1481 real-name mapping to a public IP address through user participation 1482 in an LMAP system (this applies to the Measurement Collection 1483 protocol, as well). 1485 8.4.3. Collector <-> Measurement Agent 1487 The high-level communication model for interactions between the 1488 Measurement Agent and Collector is illustrated in Section 5.4. The 1489 primary purpose of this exchange is to authenticate and collect 1490 Measurement Results from a MA, which the MA has measured autonomously 1491 and stored. 1493 The Measurement Results are the additional sensitive information 1494 included in the Collector-MA exchange. Organisations collecting LMAP 1495 measurements have the responsibility for data control. Thus, the 1496 Results and other information communicated in the Collector protocol 1497 must be secured. 1499 8.4.4. Measurement Peer <-> Measurement Agent 1501 Although the specification of the mechanisms for an Active 1502 Measurement Task is beyond the scope of LMAP, it raises potential 1503 privacy issues. The high-level communications model below 1504 illustrates the various exchanges to execute Active Measurement Tasks 1505 and store the Results. 1507 We note the potential for additional observers in the figures below 1508 by indicating the possible presence of a NAT, which has additional 1509 significance to the protocols and direction of initiation. 1511 The various messages are optional, depending on the nature of the 1512 Active Measurement Task. It may involve sending Active Measurement 1513 Traffic from the Measurement Peer to MA, MA to Measurement Peer, or 1514 both. 1516 _________________ _________________ 1517 | | | | 1518 |Measurement Peer |=========== NAT ? ==========|Measurement Agent| 1519 |_________________| |_________________| 1521 <- (Key Negotiation & 1522 Encryption Setup) 1523 (Encrypted Channel -> 1524 Established) 1525 (Announce capabilities -> 1526 & status) 1527 <- (Select capabilities) 1528 ACK -> 1529 <- (Measurement Request 1530 (MA+MP IPAddrs,set of 1531 Metrics, Schedule)) 1532 ACK -> 1534 Active Measurement Traffic <> Active Measurement Traffic 1535 (may/may not be encrypted) (may/may not be encrypted) 1537 <- (Stop Measurement Task) 1539 Measurement Results -> 1540 (if applicable) 1541 <- ACK, Close 1543 This exchange primarily exposes the IP addresses of measurement 1544 devices and the inference of measurement participation from such 1545 traffic. There may be sensitive information on key points in a 1546 service provider's network included. There may also be access to 1547 measurement-related information of interest such as the Metrics, 1548 Schedule, and intermediate results carried in the Active Measurement 1549 Traffic (usually a set of timestamps). 1551 If the Active Measurement Traffic is unencrypted, as found in many 1552 systems today, then both timing and limited results are open to on- 1553 path observers. 1555 8.4.5. Passive Measurement Agent 1557 Although the specification of the mechanisms for a Passive 1558 Measurement Task is beyond the scope of LMAP, it raises potential 1559 privacy issues. 1561 The high-level communications model below illustrates the collection 1562 of user information of interest with the Measurement Agent performing 1563 the monitoring and storage of the Results. This particular exchange 1564 is for passive measurement of DNS Response Time, which most 1565 frequently uses UDP transport. 1567 _________________ ____________ 1568 | | | | 1569 | DNS Server |=========== NAT ? ==========*=======| User client| 1570 |_________________| ^ |____________| 1571 ______|_______ 1572 | | 1573 | Measurement | 1574 | Agent | 1575 |______________| 1577 <- Name Resolution Req 1578 (MA+MP IPAddrs, 1579 Desired Domain Name) 1580 Return Record -> 1582 This exchange primarily exposes the IP addresses of measurement 1583 devices and the intent to communicate with or access the services of 1584 "Domain Name". There may be information on key points in a service 1585 provider's network, such as the address of one of its DNS servers. 1586 The Measurement Agent may be embedded in the user host, or it may be 1587 located in another device capable of observing user traffic. 1589 In principle, any of the user sensitive information of interest 1590 (listed above) can be collected and stored in the passive monitoring 1591 scenario and so must be secured. 1593 It would also be possible for a Measurement Agent to source the DNS 1594 query itself. But then, as with any active measurement task, there 1595 are few privacy concerns. 1597 8.4.6. Storage and Reporting of Measurement Results 1599 Although the mechanisms for communicating results (beyond the initial 1600 Collector) are beyond the LMAP scope, there are potential privacy 1601 issues related to a single organisation's storage and reporting of 1602 Measurement Results. Both storage and reporting functions can help 1603 to preserve privacy by implementing the mitigations described below. 1605 8.5. Threats 1607 This section indicates how each of the threats described in [RFC6973] 1608 apply to the LMAP entities and their communication and storage of 1609 "information of interest". 1611 8.5.1. Surveillance 1613 Section 5.1.1 of [RFC6973] describes Surveillance as the "observation 1614 or monitoring of and individual's communications or activities." 1615 Hence all Passive Measurement Tasks are a form of surveillance, with 1616 inherent risks. 1618 Active Measurement Methods which avoid periods of user transmission 1619 indirectly produce a record of times when a subscriber or authorised 1620 user has used their network access service. 1622 Active Measurement Methods may also utilise and store a Subscriber's 1623 currently assigned IP address when conducting measurements that are 1624 relevant to a specific Subscriber. Since the Measurement Results are 1625 time-stamped, they could provide a record of IP address assignments 1626 over time. 1628 Either of the above pieces of information could be useful in 1629 correlation and identification, described below. 1631 8.5.2. Stored Data Compromise 1633 Section 5.1.2 of [RFC6973] describes Stored Data Compromise as 1634 resulting from inadequate measures to secure stored data from 1635 unauthorised or inappropriate access. For LMAP systems this includes 1636 deleting or modifying collected measurement records, as well as data 1637 theft. 1639 The primary LMAP entity subject to compromise is the repository, 1640 which stores the Measurement Results; extensive security and privacy 1641 threat mitigations are warranted. The Collector and MA also store 1642 sensitive information temporarily, and need protection. The 1643 communications between the local storage of the Collector and the 1644 repository is beyond the scope of the LMAP work at this time, though 1645 this communications channel will certainly need protection as well as 1646 the mass storage itself. 1648 The LMAP Controller may have direct access to storage of Subscriber 1649 information (location, billing, service parameters, etc.) and other 1650 information which the controlling organisation considers private, and 1651 again needs protection. 1653 8.5.3. Correlation and Identification 1655 Sections 5.2.1 and 5.2.2 of [RFC6973] describes Correlation as 1656 combining various pieces of information to obtain desired 1657 characteristics of an individual, and Identification as using this 1658 process to infer identity. 1660 The main risk is that the LMAP system could unwittingly provide a key 1661 piece of the correlation chain, starting with an unknown Subscriber's 1662 IP address and another piece of information. For example, a 1663 Subscriber utilised Internet access from 2000 to 2310 UTC, because 1664 the Active Measurement Tasks were deferred, or sent a name resolution 1665 for www.example.com at 2300 UTC. 1667 8.5.4. Secondary Use and Disclosure 1669 Sections 5.2.3 and 5.2.4 of [RFC6973] describes Secondary Use as 1670 unauthorised utilisation of an individual's information for a purpose 1671 the individual did not intend, and Disclosure is when such 1672 information is revealed causing other's notions of the individual to 1673 change, or confidentiality to be violated. 1675 Passive Measurement Tasks are a form of Secondary Use, and the 1676 Subscribers' permission and the measured ISP's permission should be 1677 obtained beforehand. Although user traffic is only indirectly 1678 involved, the Measurement Results from Active Measurement Tasks 1679 provide some limited information about the Subscriber/ISP and could 1680 be used for Secondary Uses. For example, the use of the Results in 1681 unauthorised marketing campaigns would qualify as Secondary Use. 1683 8.6. Mitigations 1685 This section examines the mitigations listed in section 6 of 1686 [RFC6973] and their applicability to LMAP systems. Note that each 1687 section in [RFC6973] identifies the threat categories that each 1688 technique mitigates. 1690 8.6.1. Data Minimisation 1692 Section 6.1 of [RFC6973] encourages collecting and storing the 1693 minimal information needed to perform a task. 1695 There are two levels of information needed for LMAP results to be 1696 useful for a specific task: troubleshooting and general results 1697 reporting. 1699 For general results, the results can be aggregated into large 1700 categories (the month of March, all subscribers West of the 1701 Mississippi River). In this case, all individual identifications 1702 (including IP address of the MA) can be excluded, and only relevant 1703 results are provided. However, this implies a filtering process to 1704 reduce the information fields, because greater detail was needed to 1705 conduct the Measurement Tasks in the first place. 1707 For troubleshooting, so that a network operator or end user can 1708 identify a performance issue or failure, potentially all the network 1709 information (IP addresses, equipment IDs, location), Measurement 1710 Schedule, service configuration, Measurement Results, and other 1711 information may assist in the process. This includes the information 1712 needed to conduct the Measurements Tasks, and represents a need where 1713 the maximum relevant information is desirable, therefore the greatest 1714 protections should be applied. 1716 We note that a user may give temporary permission for Passive 1717 Measurement Tasks to enable detailed troubleshooting, but withhold 1718 permission for them in general. Here the greatest breadth of 1719 sensitive information is potentially exposed, and the maximum privacy 1720 protection must be provided. 1722 For MAs with access to the sensitive information of users (e.g., 1723 within a home or a personal host/handset), it is desirable for the 1724 results collection to minimise the data reported, but also to balance 1725 this desire with the needs of troubleshooting when a service 1726 subscription exists between the user and organisation operating the 1727 measurements. 1729 For passive measurements where the MA reports flow information to the 1730 Collector, the Collector may perform pre-storage minimisation and 1731 other mitigations (below) to help preserve privacy. 1733 8.6.2. Anonymity 1735 Section 6.1.1 of [RFC6973] describes a way in which anonymity is 1736 achieved: "there must exist a set of individuals that appear to have 1737 the same attributes as the individual", defined as an "anonymity 1738 set". 1740 Experimental methods for anonymisation of user identifiable data 1741 applicable to Passive Measurement Methods have been identified in 1742 [RFC6235]. However, the findings of several of the same authors is 1743 that "there is increasing evidence that anonymisation applied to 1744 network trace or flow data on its own is insufficient for many data 1745 protection applications as in [Bur10]." 1747 Essentially, the details of passive measurement tasks can only be 1748 accessed by closed organisations, and unknown injection attacks are 1749 always less expensive than the protections from them. However, some 1750 forms of summary may protect the user's sensitive information 1751 sufficiently well, and so each Metric must be evaluated in the light 1752 of privacy. 1754 The methods in [RFC6235] could be applied more successfully in Active 1755 Measurement Methods, where there are protections from injection 1756 attack. The successful attack would require breaking the integrity 1757 protection of the LMAP Reporting Protocol and injecting Measurement 1758 Results (known fingerprint, see section 3.2 of [RFC6973]) for 1759 inclusion with the shared and anonymised results, then fingerprinting 1760 those records to ascertain the anonymisation process. 1762 Beside anonymisation of measured Results for a specific user or 1763 provider, the value of sensitive information can be further diluted 1764 by summarising the results over many individuals or areas served by 1765 the provider. There is an opportunity enabled by forming anonymity 1766 sets [RFC6973] based on the reference path measurement points in 1767 [I-D.ietf-ippm-lmap-path]. For example, all measurements from the 1768 Subscriber device can be identified as "mp000", instead of using the 1769 IP address or other device information. The same anonymisation 1770 applies to the Internet Service Provider, where their Internet 1771 gateway would be referred to as "mp190". 1773 8.6.3. Pseudonymity 1775 Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, 1776 are a possible mitigation to revealing one's true identity, since 1777 there is no requirement to use real names in almost all protocols. 1779 A pseudonym for a measurement device's IP address could be an LMAP- 1780 unique equipment ID. However, this would likely be a permanent 1781 handle for the device, and long-term use weakens a pseudonym's power 1782 to obscure identity. 1784 8.6.4. Other Mitigations 1786 Data can be de-personalised by blurring it, for example by adding 1787 synthetic data, data-swapping, or perturbing the values in ways that 1788 can be reversed or corrected. 1790 Sections 6.2 and 6.3 of [RFC6973] describe User Participation and 1791 Security, respectively. 1793 Where LMAP measurements involve devices on the Subscriber's premises 1794 or Subscriber-owned equipment, it is essential to secure the 1795 Subscriber's permission with regard to the specific information that 1796 will be collected. The informed consent of the Subscriber (and, if 1797 different, the end user) is needed, including the specific purpose of 1798 the measurements. The approval process could involve showing the 1799 Subscriber their measured information and results before instituting 1800 periodic collection, or before all instances of collection, with the 1801 option to cancel collection temporarily or permanently. 1803 It should also be clear who is legally responsible for data 1804 protection (privacy); in some jurisdictions this role is called the 1805 'data controller'. It is good practice to time limit the storage of 1806 personal information. 1808 Although the details of verification would be impenetrable to most 1809 subscribers, the MA could be architected as an "app" with open 1810 source-code, pre-download and embedded terms of use and agreement on 1811 measurements, and protection from code modifications usually provided 1812 by the app-stores. Further, the app itself could provide data 1813 reduction and temporary storage mitigations as appropriate and 1814 certified through code review. 1816 LMAP protocols, devices, and the information they store clearly need 1817 to be secure from unauthorised access. This is the hand-off between 1818 privacy and security considerations (Section 7). The Data Controller 1819 has the (legal) responsibility to maintain data protections described 1820 in the Subscriber's agreement and agreements with other 1821 organisations. 1823 9. IANA Considerations 1825 There are no IANA considerations in this memo. 1827 10. Acknowledgments 1829 This document is a merger of three individual drafts: draft-eardley- 1830 lmap-terminology-02, draft-akhter-lmap-framework-00, and draft- 1831 eardley-lmap-framework-02. 1833 Thanks to Juergen Schoenwaelder for his detailed review of the 1834 terminology. Thanks to Charles Cook for a very detailed review of 1835 -02. 1837 Thanks to numerous people for much discussion, directly and on the 1838 LMAP list (apologies to those unintentionally omitted): Alan Clark, 1839 Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian 1840 Trammell, Charles Cook, Dave Thorne, Frode Soerensen, Greg Mirsky, 1841 Guangqing Deng, Jason Weil, Jean-Francois Tremblay, Jerome Benoit, 1842 Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, Ken Ko, Michael 1843 Bugenhagen, Rolf Winter, Sam Crawford, Sharam Hakimi, Steve Miller, 1844 Ted Lemon, Timothy Carey, Vaibhav Bajpai, William Lupton. 1846 Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on 1847 the Leone research project, which receives funding from the European 1848 Union Seventh Framework Programme [FP7/2007-2013] under grant 1849 agreement number 317647. 1851 11. History 1853 First WG version, copy of draft-folks-lmap-framework-00. 1855 11.1. From -00 to -01 1857 o new sub-section of possible use of Group-IDs for privacy 1859 o tweak to definition of Control protocol 1861 o fix typo in figure in S5.4 1863 11.2. From -01 to -02 1865 o change to INFORMATIONAL track (previous version had typo'd 1866 Standards track) 1868 o new definitions for Capabilities Information and Failure 1869 Information 1871 o clarify that diagrams show LMAP-level information flows. 1872 Underlying protocol could do other interactions, eg to get through 1873 NAT or for Collector to pull a Report 1875 o add hint that after a re-boot should pause random time before re- 1876 register (to avoid mass calling event) 1878 o delete the open issue "what happens if a Controller fails" (normal 1879 methods can handle) 1881 o add some extra words about multiple Tasks in one Schedule 1883 o clarify that new Schedule replaces (rather than adds to) and old 1884 one. Similarly for new configuration of Measurement Tasks or 1885 Report Channels. 1887 o clarify suppression is temporary stop; send a new Schedule to 1888 permanently stop Tasks 1890 o alter suppression so it is ACKed 1892 o add un-suppress message 1894 o expand the text on error reporting, to mention Reporting failures 1895 (as well as failures to action or execute Measurement Task & 1896 Schedule) 1898 o add some text about how to have Tasks running indefinitely 1899 o add that optionally a Report is not sent when there are no 1900 Measurement Results 1902 o add that a Measurement Task may create more than one Measurement 1903 Result 1905 o clarify /amend /expand that Reports include the "raw" Measurement 1906 Results - any pre-processing is left for lmap2.0 1908 o add some cautionary words about what if the Collector unexpectedly 1909 doesn't hear from a MA 1911 o add some extra words about the potential impact of Measurement 1912 Tasks 1914 o clarified various aspects of the privacy section 1916 o updated references 1918 o minor tweaks 1920 11.3. From -02 to -03 1922 o alignment with the Information Model 1923 [I-D.burbridge-lmap-information-model] as this is agreed as a WG 1924 document 1926 o One-off and periodic Measurement Schedules are kept separate, so 1927 that they can be updated independently 1929 o Measurement Suppression in a separate sub-section. Can now 1930 optionally include particular Measurement Tasks &/or Schedules to 1931 suppress, and start/stop time 1933 o for clarity, concept of Channel split into Control, Report and MA- 1934 to-Controller Channels 1936 o numerous editorial changes, mainly arising from a very detailed 1937 review by Charles Cook 1939 o 1941 12. Informative References 1943 [Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, 1944 "The Role of Network Trace anonymisation Under Attack", 1945 January 2010. 1947 [Q1741] Q.1741.7, , "IMT-2000 references to Release 9 of GSM- 1948 evolved UMTS core network", 1949 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 1951 [RFC1035] Mockapetris, P., "Domain names - implementation and 1952 specification", STD 13, RFC 1035, November 1987. 1954 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 1955 June 2005. 1957 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1958 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 1959 2005. 1961 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 1962 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 1963 RFC 5357, October 2008. 1965 [I-D.ietf-lmap-use-cases] 1966 Linsner, M., Eardley, P., Burbridge, T., and F. Sorensen, 1967 "Large-Scale Broadband Measurement Use Cases", draft-ietf- 1968 lmap-use-cases-01 (work in progress), December 2013. 1970 [I-D.bagnulo-ippm-new-registry-independent] 1971 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 1972 A. Morton, "A registry for commonly used metrics. 1973 Independent registries", draft-bagnulo-ippm-new-registry- 1974 independent-01 (work in progress), July 2013. 1976 [I-D.ietf-homenet-arch] 1977 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 1978 "IPv6 Home Networking Architecture Principles", draft- 1979 ietf-homenet-arch-11 (work in progress), October 2013. 1981 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 1982 Multiple-Interface Hosts", RFC 6419, November 2011. 1984 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1985 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1986 2013. 1988 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1989 Shim Protocol for IPv6", RFC 5533, June 2009. 1991 [I-D.burbridge-lmap-information-model] 1992 Burbridge, T., Eardley, P., Bagnulo, M., and J. 1993 Schoenwaelder, "Information Model for Large-Scale 1994 Measurement Platforms (LMAP)", draft-burbridge-lmap- 1995 information-model-01 (work in progress), October 2013. 1997 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1998 Support", RFC 6235, May 2011. 2000 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 2001 Morris, J., Hansen, M., and R. Smith, "Privacy 2002 Considerations for Internet Protocols", RFC 6973, July 2003 2013. 2005 [I-D.ietf-ippm-lmap-path] 2006 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 2007 A. Morton, "A Reference Path and Measurement Points for 2008 LMAP", draft-ietf-ippm-lmap-path-01 (work in progress), 2009 September 2013. 2011 Authors' Addresses 2013 Philip Eardley 2014 British Telecom 2015 Adastral Park, Martlesham Heath 2016 Ipswich 2017 ENGLAND 2019 Email: philip.eardley@bt.com 2021 Al Morton 2022 AT&T Labs 2023 200 Laurel Avenue South 2024 Middletown, NJ 2025 USA 2027 Email: acmorton@att.com 2028 Marcelo Bagnulo 2029 Universidad Carlos III de Madrid 2030 Av. Universidad 30 2031 Leganes, Madrid 28911 2032 SPAIN 2034 Phone: 34 91 6249500 2035 Email: marcelo@it.uc3m.es 2036 URI: http://www.it.uc3m.es 2038 Trevor Burbridge 2039 British Telecom 2040 Adastral Park, Martlesham Heath 2041 Ipswich 2042 ENGLAND 2044 Email: trevor.burbridge@bt.com 2046 Paul Aitken 2047 Cisco Systems, Inc. 2048 96 Commercial Street 2049 Edinburgh, Scotland EH6 6LX 2050 UK 2052 Email: paitken@cisco.com 2054 Aamer Akhter 2055 Cisco Systems, Inc. 2056 7025 Kit Creek Road 2057 RTP, NC 27709 2058 USA 2060 Email: aakhter@cisco.com