idnits 2.17.1 draft-ietf-lmap-framework-01.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 (October 21, 2013) is 3834 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 384 -- Looks like a reference, but probably isn't: '180' on line 384 == Missing Reference: 'RFC6887' is mentioned on line 966, but not defined == Missing Reference: 'RFC5533' is mentioned on line 996, but not defined == Unused Reference: 'RFC6241' is defined on line 1694, but no explicit reference was found in the text == Unused Reference: 'I-D.bagnulo-ippm-new-registry-independent' is defined on line 1721, but no explicit reference was found in the text == Unused Reference: 'RFC2330' is defined on line 1727, but no explicit reference was found in the text == Unused Reference: 'I-D.mathis-ippm-model-based-metrics' is defined on line 1731, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1736, but no explicit reference was found in the text == Unused Reference: 'I-D.burbridge-lmap-information-model' is defined on line 1739, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-burbridge-lmap-information-model-00 Summary: 0 errors (**), 0 flaws (~~), 10 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: Standards Track A. Morton 5 Expires: April 24, 2014 AT&T Labs 6 M. Bagnulo 7 UC3M 8 T. Burbridge 9 BT 10 P. Aitken 11 A. Akhter 12 Cisco Systems 13 October 21, 2013 15 A framework for large-scale measurement platforms (LMAP) 16 draft-ietf-lmap-framework-01 18 Abstract 20 Measuring broadband service on a large scale requires standardisation 21 of the logical architecture and a description 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). 25 The document is a contribution towards the LMAP working group's 26 milestone. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Outline of an LMAP-based measurement system . . . . . . . . . 7 65 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.1. Measurement system is under the direction of a single 67 organisation . . . . . . . . . . . . . . . . . . . . . . 11 68 4.2. Each MA may only have a single Controller at any point in 69 time . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5. LMAP Protocol Model . . . . . . . . . . . . . . . . . . . . . 11 71 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 12 72 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 14 73 5.3. Starting and stopping Measurement Tasks . . . . . . . . . 16 74 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 17 75 5.5. Items beyond the scope of the LMAP Protocol Model . . . . 18 76 5.5.1. User-controlled measurement system . . . . . . . . . 19 77 6. Details of the LMAP framework . . . . . . . . . . . . . . . . 20 78 6.1. Measurement Agent (MA) . . . . . . . . . . . . . . . . . 20 79 6.1.1. Measurement Agent embedded in site gateway . . . . . 20 80 6.1.2. Measurement Agent embedded behind Site NAT /Firewall 21 81 6.1.3. Measurement Agent in-line with site gateway . . . . . 21 82 6.1.4. Measurement Agent in multi homed site . . . . . . . . 22 83 6.2. Measurement Peer (MP) . . . . . . . . . . . . . . . . . . 22 84 6.3. Controller . . . . . . . . . . . . . . . . . . . . . . . 23 85 6.4. Collector . . . . . . . . . . . . . . . . . . . . . . . . 23 86 7. Security considerations . . . . . . . . . . . . . . . . . . . 23 87 8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 24 88 8.1. Categories of Entities with Information of Interest . . . 25 89 8.2. Examples of Sensitive Information . . . . . . . . . . . . 25 90 8.3. Key Distinction Between Active and Passive Measurement 91 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 26 92 8.4. Communications Model (for Privacy) . . . . . . . . . . . 26 93 8.4.1. Controller <-> Measurement Agent . . . . . . . . . . 27 94 8.4.2. Collector <-> Measurement Agent . . . . . . . . . . . 28 95 8.4.3. Active Measurement Peer <-> Measurement Agent . . . . 28 96 8.4.4. Passive Measurement Peer <-> Measurement Agent . . . 29 97 8.4.5. Result Storage and Reporting . . . . . . . . . . . . 30 99 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 30 100 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 30 101 8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 31 102 8.5.3. Correlation and Identification . . . . . . . . . . . 31 103 8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 31 104 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 32 105 8.6.1. Data Minimization . . . . . . . . . . . . . . . . . . 32 106 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 33 107 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 34 108 8.6.4. Other Mitigations . . . . . . . . . . . . . . . . . . 34 109 8.7. The potential role of a Group-ID for privacy . . . . . . 34 110 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 111 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 112 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 113 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 37 114 12. Informative References . . . . . . . . . . . . . . . . . . . 37 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 117 1. Introduction 119 There is a desire to be able to coordinate the execution of broadband 120 measurements and the collection of measurement results across a large 121 scale set of diverse devices. These devices could be software based 122 agents on PCs, embedded agents in consumer devices (e.g. blu-ray 123 players), service provider controlled devices such as set-top players 124 and home gateways, or simply dedicated probes. It is expected that 125 such a system could easily comprise 100k devices. Such a scale 126 presents unique problems in coordination, execution and measurement 127 result collection. Several use cases have been proposed for large- 128 scale measurements including: 130 o Operators: to help plan their network and identify faults 132 o Regulators: to benchmark several network operators and support 133 public policy development 135 Further details of the use cases can be found at 136 [I-D.linsner-lmap-use-cases]. The LMAP framework should be useful 137 for these, as well as other use cases that the LMAP WG doesn't 138 concentrate on, such as to help end users run diagnostic checks like 139 a network speed test. 141 The LMAP framework has four basic elements: Measurement Agents, 142 Measurement Peers, Controllers and Collectors. 144 Measurement Agents (MAs) perform network measurements. They are 145 pieces of code that can be executed in specialized hardware (hardware 146 probe) or on a general-purpose device (like a PC or mobile phone). 148 The Measurement Agents may have multiple interfaces (WiFi, Ethernet, 149 DSL, fibre, etc.) and the measurements may specify any one of these. 150 Measurements may be active (the MA or Measurement Peer (MP) generates 151 test traffic), passive (the MA observes user traffic), or some hybrid 152 form of the two. For active measurement tasks, the MA (or MP) 153 generates test traffic and measures some metric associated with its 154 transfer over the path to (or from) a Measurement Peer. For example, 155 one active measurement task could be to measure the UDP latency 156 between the MA and a given MP. MAs may also conduct passive testing 157 through the observation of traffic. The measurements themselves may 158 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 initiates 172 the measurement tasks, gets instructions from the Controller and 173 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 Over the years various efforts inside and outside the IETF have 180 worked on independent components of such a system. There are also 181 existing systems that are deployed today. However, these are either 182 proprietary, closed, and/or not standardized. The IETF Large-Scale 183 Measurement of Broadband Performance (LMAP) Working Group is 184 chartered to specify the information model, associated data models, 185 and select/extend one or more protocols for secure measurement 186 control and measurement result collection. 188 The goal is to have the measurements (made using the same metrics and 189 mechanisms) for a large number of points on the Internet, and to have 190 the results collected and stored in the same form. 192 The desirable features for a large-scale measurement systems we are 193 designing for are: 195 o Standardised - in terms of the tests that they perform, the 196 components, the data models and protocols for transferring 197 information between the components. For example so that it is 198 meaningful to compare measurements made of the same metric at 199 different times and places. For example so that the operator of a 200 measurement system can buy the various components from different 201 vendors. Today's systems are proprietary in some or all of these 202 aspects. 204 o Large-scale - [I-D.linsner-lmap-use-cases] envisages Measurement 205 Agents in every home gateway and edge device such as set-top-boxes 206 and tablet computers. Existing systems have up to a few thousand 207 Measurement Agents (without judging how much further they could 208 scale). 210 o Diversity - a measurement system should handle different types of 211 Measurement Agent - for example Measurement Agents may come from 212 different vendors, be in wired and wireless networks and be on 213 devices with IPv4 or IPv6 addresses. 215 2. Terminology 217 This section defines terminology for LMAP. Please note that defined 218 terms are capitalized. 220 Active Measurement Method (Task): A type of Measurement Method (Task) 221 that involves a Measurement Agent and a Measurement Peer (or possibly 222 Peers), where either the Measurement Agent or the Measurement Peer 223 injects test packet(s) into the network destined for the other, and 224 which involves one of them measuring some performance or reliability 225 parameter associated with the transfer of the packet(s). 227 Bootstrap Protocol: A protocol that initialises a Measurement Agent 228 with the information necessary to be integrated into a measurement 229 system. 231 Collector: A function that receives a Report from a Measurement 232 Agent. Colloquially, a Collector is a physical device that performs 233 this function. 235 Controller: A function that provides a Measurement Agent with 236 Instruction(s). Colloquially, a Controller is a physical device that 237 performs this function. 239 Control Protocol: The protocol delivering Instruction(s) from a 240 Controller to a Measurement Agent. It also delivers logging 241 information and capabilities information from the Measurement Agent 242 to the Controller. 244 Cycle-ID: A tag that is sent by the Controller in an Instruction and 245 echoed by the MA in its Report; Measurement Results with the same 246 Cycle-ID are expected to be comparable. 248 Data Model: The implementation of an Information Model in a 249 particular data modelling language. 251 Derived Metric: A Metric that is a combination of other Metrics, and/ 252 or a combination of the same Metric measured over different parts of 253 the network, or at different times. 255 Environmental Constraint: A parameter that is measured as part of the 256 Measurement Task, its value determining whether the rest of the 257 Measurement Task proceeds. 259 Group-ID: An identifier of a group of MAs. 261 Information Model: The protocol-neutral definition of the semantics 262 of the Instructions, the Report, the status of the different elements 263 of the measurement system as well of the events in the system. 265 Instruction: The description of Measurement Tasks to perform and the 266 details of the Report to send. The Instruction is sent by a 267 Controller to a Measurement Agent. 269 Measurement Agent (MA): The function that receives Instructions from 270 a Controller, performs Measurement Tasks (perhaps in concert with a 271 Measurement Peer) and reports Measurement Results to a Collector. 272 Colloquially, a Measurement Agent is a physical device that performs 273 this function. 275 Measurement Method: The process for assessing the value of a Metric; 276 the process of measuring some performance or reliability parameter; 277 the generalisation of a Measurement Task. 279 Measurement Parameter: A parameter whose value is left open by the 280 Measurement Method. 282 Measurement Peer: The function that receives control messages and 283 test packets from a Measurement Agent and may reply to the 284 Measurement Agent as defined by the Measurement Method. 286 Measurement Result: The output of a single Measurement Task (the 287 value obtained for the parameter of interest, or Metric). 289 Measurement Schedule: the schedule for performing a series of 290 Measurement Tasks. 292 Measurement Suppression: a type of Instruction that stops 293 (suppresses) Measurement Tasks. 295 Measurement Task: The act that yields a single Measurement Result; 296 the act consisting of the (single) operation of the Measurement 297 Method at a particular time and with all its parameters set to 298 specific values. 300 Metric: The quantity related to the performance and reliability of 301 the Internet that we'd like to know the value of, and that is 302 carefully specified. 304 Passive Measurement Method (Task): A Measurement Method (Task) in 305 which a Measurement Agent observes existing traffic at a specific 306 measurement point, but does not inject test packet(s). 308 Report: The Measurement Results and other associated information (as 309 defined by the Instruction); a specific instance of the Data Model. 310 The Report is sent by a Measurement Agent to a Collector. 312 Report Channel: a specific Report Schedule and Collector 314 Report Protocol: The protocol delivering Report(s) from a Measurement 315 Agent to a Collector. 317 Report Schedule: the schedule for sending a series of Reports to a 318 Collector. 320 Subscriber: An entity (associated with one or more users) that is 321 engaged in a subscription with a service provider. The subscriber is 322 allowed to subscribe and un-subscribe services, to register a user or 323 a list of users authorized to enjoy these services, and also to set 324 the limits relative to the use that associated users make of these 325 services. (This definition is from [Q1741].) 327 Test Traffic: for Active Measurement Tasks, the traffic generated by 328 the Measurement Agent and/or the Measurement Peer to execute the 329 requested Measurement Task. 331 3. Outline of an LMAP-based measurement system 333 Figure 1 shows the main components of a measurement system, and the 334 interactions of those components. Some of the components are outside 335 the scope of LMAP. In this section we provide an overview on the 336 whole measurement system, whilst the subsequent sections study the 337 LMAP components in more detail. 339 The first component is a Measurement Task, which measures some 340 performance or reliability Metric of interest. An Active Measurement 341 Task involves either a Measurement Agent injecting Test Traffic into 342 the network destined for a Measurement Peer, and/or a MP sending Test 343 Traffic to a MA; one of them measures the some parameter associated 344 with the transfer of the packet(s). A Passive Measurement Task 345 involves only a MA, which simply observes existing traffic - for 346 example, it could simply count bytes or it might calculate the 347 average loss for a particular flow. 349 It is very useful to standardise Measurement Methods (a Measurement 350 Method is a generalisation of a Measurement Task), so that it is 351 meaningful to compare measurements of the same Metric made at 352 different times and places. It is also useful to define a registry 353 for commonly-used Metrics [registry] so that a Measurement Method can 354 be referred to simply by its identifier in the registry. The 355 Measurement Methods and registry would hopefully also be referenced 356 by other standards organisations. 358 In order for a Measurement Agent and a Measurement Peer to execute an 359 Active Measurement Task, they exchange Test Traffic. The protocols 360 used for the Test Traffic is out of the scope of the LMAP WG and 361 falls within the scope of the IETF WGs such as IPPM. 363 For Measurement Results to be truly comparable, as might be required 364 by a regulator, not only do the same Measurement Methods need to be 365 used but also the set of Measurement Tasks should follow a similar 366 Measurement Schedule and be of similar number. The details of such a 367 characterisation plan are beyond the scope of work in IETF although 368 certainly facilitated by IETF's work. 370 The next components we consider are the Measurement Agent (MA), 371 Controller and Collector. The main work of the LMAP working group is 372 to define the Control Protocol between the Controller and MA, and the 373 Report Protocol between the MA and Collector. Section 4 onwards 374 considers the LMAP compnents in more detail; here we introduce them. 376 The Controller manages a MA by instructing it which tests it should 377 perform and when. For example it may instruct a MA at a home 378 gateway: "Run the 'download speed test' with the test server at the 379 end user's first IP point in the network; if the end user is active 380 then delay the test and re-try 1 minute later, with up to 3 re-tries; 381 repeat every hour at xx.05 + Unif[0,180] seconds". The Controller 382 also manages a MA by instructing it how to report the test results, 383 for example: "Report results once a day in a batch at 4am + 384 Unif[0,180] seconds; if the end user is active then delay the report 385 5 minutes". As well as regular tests, a Controller can initiate a 386 one-off test ("Do test now", "Report as soon as possible"). These 387 are called the Measurement and Report Schedule. 389 The Collector accepts a Report from a MA with the results from its 390 tests. It may also do some processing on the results - for instance 391 to eliminate outliers, as they can severely impact the aggregated 392 results. 394 Finally we introduce several components that are out of scope of the 395 LMAP WG and will be provided through existing protocols or 396 applications. They affect how the measurement system uses the 397 Measurement Results and how it decides what set of Measurement Tasks 398 to perform. 400 The MA needs to be bootstrapped with initial details about its 401 Controller, including authentication credentials. The LMAP WG 402 considers the boostrap process, since it affects the Information 403 Model. However, it does not define a bootstrap protocol, since it is 404 likely to be technology specific and could be defined by the 405 Broadband Forum, DOCSIS or IEEE. depending on the device. Possible 406 protocols are SNMP, NETCONF or (for Home Gateways) CPE WAN Management 407 Protocol (CWMP) from the Auto Configuration Server (ACS) (as 408 specified in TR-069). 410 A Subscriber Parameter Database contains information about the line, 411 for example the customer's broadband contract (perhaps 2, 40 or 80Mb/ 412 s), the line technology (DSL or fibre), the time zone where the MA is 413 located, and the type of home gateway and MA. These are all factors 414 which may affect the choice of what Measurement Tasks to run and how 415 to interpret the Measurement Results. For example, a download test 416 suitable for a line with an 80Mb/s contract may overwhelm a 2Mb/s 417 line. Another example is if the Controller wants to run a one-off 418 test to diagnose a fault, then it should understand what problem the 419 customer is experiencing and what tests have already been run. The 420 Subscribers' service parameters are already gathered and stored by 421 existing operations systems. 423 A Results Database records all measurements in an equivalent form, 424 for example an SQL database, so that they can be easily accessed by 425 the Data Analysis Tools. The Data Analysis Tools also need to 426 understand the Subscriber's service information, for example the 427 broadband contract. 429 The Data Analysis Tools receive the results from the Collector or via 430 the Results Database. They might visualise the data or identify 431 which component or link is likely to be the cause of a fault or 432 degradation. 434 The operator's OAM (Operations, Administration, and Maintenance) uses 435 the results from the tools. 437 ^ 438 | 439 IPPM 440 +---------------+ Test +-------------+ Scope 441 +------->| Measurement |<---------->| Measurement | v 442 | | Agent | Traffic | Peer | ^ 443 | +---------------+ +-------------+ | 444 | ^ | | 445 | Instruction | | Report | 446 | | +-----------------+ | 447 | | | | 448 | | v LMAP 449 | +------------+ +------------+ Scope 450 | | Controller | | Collector | | 451 | +------------+ +------------+ v 452 | ^ ^ | ^ 453 | | | | | 454 | | +----------+ | | 455 | | | v | 456 +-----------+ +---------+ +--------+ +----------+ | 457 |Initializer| |Parameter|--->|Analysis|<---|Repository| Out 458 +-----------+ |DataBase | | tools | +----------+ of 459 +---------+ +--------+ Scope 460 | 461 v 463 Figure 1: Schematic of main elements of an LMAP-based 464 measurement system 465 (showing the elements in and out of the scope of the LMAP WG) 467 4. Constraints 468 The LMAP framework makes some important assumptions, which constrain 469 the scope of the work to be done. 471 4.1. Measurement system is under the direction of a single organisation 473 In the LMAP framework (as defined in the WG's charter) the 474 measurement system is under the direction of a single organisation 475 that is responsible both for the data and the quality of experience 476 delivered to its users. Clear responsibility is critical given that 477 a misbehaving large-scale measurement system could potentially harm 478 user experience, user privacy and network security. 480 However, the components of an LMAP measurement system can be deployed 481 in administrative domains that are not owned by the measuring 482 organisation. Thus, the system of functions deployed by a single 483 organisation constitutes a single LMAP domain which may span 484 ownership or other administrative boundaries. 486 4.2. Each MA may only have a single Controller at any point in time 488 A MA is instructed by one Controller and is in one measurement 489 system. The constraint avoids different Controllers giving a MA 490 conflicting instructions and so means that the MA does not have to 491 manage contention between multiple Measurement (or Report) Schedules. 492 This simplifies the design of MAs (critical for a large-scale 493 infrastructure) and allows a Measurement Schedule to be tested on 494 specific types of MA before deployment to ensure that the end user 495 experience is not impacted (due to CPU, memory or broadband-product 496 constraints). 498 An operator may have several Controllers, perhaps with a Controller 499 for different types of MA (home gateways, tablets) or location 500 (Ipswich, Edinburgh). 502 5. LMAP Protocol Model 504 A protocol model presents (RFC4101) "an architectural model for how 505 the protocol operates ... a short description of the system in 506 overview form, ... [which] needs to answer three basic questions: 508 1. What problem is the protocol trying to achieve? 510 2. What messages are being transmitted and what do they mean? 512 3. What are the important, but unobvious, features of the protocol?" 514 An LMAP system goes through the following phases: 516 o a bootstrapping process before the MA can take part in the three 517 items below 519 o a Control Protocol, which delivers an Instruction from a 520 Controller and a MA. The Instruction details what Measurement 521 Tasks the MA should perform and when, and how it should report the 522 Measurement Results 524 o the actual Measurement Tasks are performed. An Active Measurement 525 Task involves sending test traffic between the Measurement Agent 526 and a Measurement Peer, whilst a Passive Measurement Task involves 527 (only) the Measurement Agent observing existing user traffic. The 528 LMAP WG does not define Measurement Methods, however the IPPM WG 529 does. 531 o a Report Protocol, which delivers a Report from the MA to a 532 Collector. The Report contains the Measurement Results. 534 In the diagrams the following convention is used: 536 o (optional): indicated by round brackets 538 o [potentially repeated]: indicated by square brackets 540 The Protocol Model is closely related to the Information Model, which 541 is the abstract definition of the information carried by the protocol 542 model. The purpose of both is to provide a protocol and device 543 independent view, which can be implemented via specific protocols. 544 The LMAP WG will define a specific Control Protocol and Report 545 Protocol, but other Protocols could be defined by other standards 546 bodies or be proprietary. However it is important that they all 547 implement the same Information and Protocol Model, in order to ease 548 the definition, operation and interoperability of large-scale 549 measurement systems. 551 5.1. Bootstrapping process 553 The primary purpose of bootstrapping is to enable the MA and 554 Controller to be integrated into a measurement system. In order to 555 do that, the MA needs to retrieve information about itself (like its 556 identity in the measurement system), about the Controller and the 557 Collector(s) as well as security information (such as certificates 558 and credentials). 560 +--------------+ 561 | Measurement | 562 | Agent | 563 +--------------+ 565 (Initial Controller details: 566 address or FQDN, -> 567 security credentials) 569 +-----------------+ 570 | Initial | 571 | Controller | 572 +-----------------+ 573 <- (register) 574 Controller details: 575 address or FQDN, -> 576 security credentials 578 +-----------------+ 579 | | 580 | Controller | 581 +-----------------+ 582 <- register 583 MA-ID, (Group-ID, report?) -> 585 Typically the MA is behind a NAT, so needs to initiate 586 communications, in order that the Controller can communicate with it. 587 The normal NAT interactions are not shown in the figure. 589 The MA knows how to contact a Controller through some device /access 590 specific mechanism. For example, this could be in the firmware, 591 downloaded, manually configured or via a protocol like TR-069. The 592 Controller could either be the one that will send it Instructions 593 (see next sub-section) or else an initial Controller. The role of an 594 initial Controller is simply to inform the MA how to contact its 595 actual Controller; this could be useful, for example, for load 596 balancing or if the details of the initial Controller are statically 597 configured or if the measurement system has specific Controllers for 598 different devices types. When the MA registers with the Controller 599 it learns its MA identifier; it may also be told a Group-ID and 600 whether to include the MA-ID as well as the Group-ID in its Reports. 601 A Group-ID would be shared by several MAs and could be useful for 602 privacy reasons (for instance to hinder tracking of a mobile MA 603 device). The MA may also tell the Controller the list of Measurement 604 Methods that its capable of (see next sub-section). 606 Whilst the LMAP WG considers the bootstrapping process, it is out of 607 scope to define a bootstrap mechanism, as it depends on the type of 608 device and access. 610 Open issue: what happens if a Controller fails, how is the MA is 611 homed onto a new one? 613 5.2. Control Protocol 615 The primary purpose of the Control Protocol is to allow the 616 Controller to configure a Measurement Agent with Measurement 617 Instructions, which it then acts on autonomously. 619 +-----------------+ +-------------+ 620 | | | Measurement | 621 | Controller |===================================| Agent | 622 +-----------------+ +-------------+ 624 Instruction: 625 [(Measurement Task (parameters)), -> 626 (Measurement Schedule), 627 (Report Channel(s))] 628 <- ACK 630 (Capability request) -> 631 <- List of Measurement 632 Methods 633 ACK -> 635 Suppress -> 637 <- Failure report: 638 (reason) 639 ACK -> 641 The Instruction contains: 643 o what measurements to do: the Measurement Methods could be defined 644 by reference to a registry entry, along with any parameters that 645 need to be set (such as the address of the Measurement Peer) and 646 any Environmental Constraint (such as, 'delay the test if the end 647 user is active') 649 o when to do them: the Measurement Schedule details the timings of 650 regular tests, one-off tests 652 o how to report the Measurement Results: via Reporting Channel(s), 653 each of which defines a target Collector and Report Schedule 655 An Instruction could contain one or more of the above elements, since 656 the Controller may want the MA to perform several different 657 Measurement Tasks (measure UDP latency and download speed), at 658 several frequencies (a regular test every hour and a one-off test 659 immediately), and report to several Collectors. The different 660 elements can be updated independently at different times and 661 regularities, for example it is likely that the Measurement Schedule 662 will be updated more often than the other elements. 664 In general we expect that the Controller knows what Measurement 665 Methods the MA supports, such that the Controller can correctly 666 instruct the MA. Note that the Control Protocol does not allow 667 negotiation (which would add complexity to the MA, Controller and 668 Control Protocol for little benefit). 670 The MA can send to the Controller the complete list of Measurement 671 Methods that it is capable of. Note that it is not intended to 672 indicate dynamic capabilities like the MA's currently unused CPU, 673 memory or battery life. The list of Measurement Methods could be 674 useful in several circumstances: when the MA first communicates with 675 a Controller; when the MA becomes capable of a new Measurement 676 Method; when requested by the Controller (for example, if the 677 Controller forgets what the MA can do or otherwise wants to 678 resynchronize what it knows about the MA). 680 The Controller has the ability to send a "suppress" message to MAs. 681 This could be useful if there is some unexpected network issue and so 682 the measurement system wants to eliminate inessential traffic. As a 683 result, temporarily the MA does not start new Active Measurement 684 Tasks, and it may also stop in-progress Measurement Tasks, especially 685 ones that are long-running &/or creates a lot of traffic. See the 686 next section for more information on stopping Measuremet Tasks. 688 The figure shows that the various messages are acknowledged, which 689 means that they have been delivered successfully. However, the 690 "suppress" message is not acknowledged, since it is likely to be 691 broadcast to several /many MAs at a time when the measurement system 692 wants to eliminate inessential traffic. Note also that the MA does 693 not inform the Controller about Measurement Tasks starting and 694 stopping. 696 There is no need for the MA to confirm to the Controller that it has 697 understood and acted on the Instruction, since the Controller knows 698 the capabilities of the MA. However, the Control Protocol must 699 support robust error reporting by the MA, to provide the Controller 700 with sufficiently detailed reasons for any failures. There are two 701 broad categories of failure: the MA cannot action the Instruction 702 (for example, it doesn't include a parameter that is mandatory for 703 the requested Measurement Method); or the Measurement Task could not 704 be executed (for example, the MA unexpectedly has no spare CPU 705 cycles). Note that it is not considered a failure if a Measurement 706 Task (correctly) doesn't start - for example if the MA detects cross- 707 traffic; instead this is reported to the Collector in the normal 708 manner (see Section below). 710 Comment: the detailed list of reasons below would be more appropriate 711 in the Information Model i-d. 713 o no value for a mandatory parameter 715 o time of test is in past 717 o type wrong, eg string given where expect integer 719 o Schedule refers to a Measurement configuration or Report Channel 720 that doesn't exist 722 o MA has crashed 724 o MA doesn't (any longer) understand requested Method 726 o MA has run out of CPU, memory, battery power 728 o Collector has disappeared 730 o MP has disappeared 732 Finally, note that the MA doesn't do a 'safety check' with the 733 Controller (that it should still continue with the requested 734 Measurement Tasks) - it simply carries out the Measurement Tasks as 735 instructed, unless it gets an updated Instruction. 737 The LMAP WG will define a Control Protocol and its associated Data 738 Model that implements the Protocol & Information Model. This may be 739 a simple instruction - response protocol, and LMAP will specify how 740 it operates over an existing protocol -to be selected, perhaps REST- 741 style HTTP(s) or NETCONF-YANG. 743 5.3. Starting and stopping Measurement Tasks 745 The LMAP WG is neutral to what the actual Measurement Task is. The 746 WG does not define a generic start and stop process, since the 747 correct approach depend on the particular Measurement Task; the 748 details are defined as part of each Measurement Method, and hence 749 potentially by the IPPM WG. 751 Once the MA gets its Measurement and Report Schedules from its 752 Controller then it acts autonomously, in terms of operation of the 753 Measurement Tasks and reporting of the result. One implication is 754 that the MA initiates Measurement Tasks. Therefore for the common 755 case where the MA is on a home gateway, the MA initiates a 'download 756 speed test' by asking a Measurement Peer to send the file. 758 Many Active Measurement Tasks begin with a pre-check before the test 759 traffic is sent. Action could include: 761 o the MA checking that there is no cross-traffic (ie that the user 762 isn't already sending traffic); 764 o the MA checking with the Measurement Peer that it can handle a new 765 Measurement Task (in case the MP is already handling many 766 Measurement Tasks with other MAs); 768 o the first part of the Measurement Task consisting of traffic that 769 probes the path to make sure it isn't overloaded. 771 It is possible that similar checks continue during the Measurement 772 Task, especially one that is long-running &/or creates a lot of Test 773 Traffic, which may be abandoned whilst in-progress. A Measurement 774 Task could also be abandoned in response to a "suppress" message (see 775 previous section). Action could include: 777 o For 'upload' tests, the MA not sending traffic 779 o For 'download' tests, the MA closing the TCP connection or sending 780 a TWAMP Stop control message. 782 Comment: presumably Passive Measurement Tasks don't do pre-checking 783 or stopping? 785 5.4. Report Protocol 787 The primary purpose of the Report Protocol is to allow a Measurement 788 Agent to report its Measurement Results to a Collector, and the 789 context in which they were obtained. 791 +-----------------+ +-------------+ 792 | | | Measurement | 793 | Collector |===================================| Agent | 794 +-----------------+ +-------------+ 796 <- Report: 797 [MA-ID &/or Group-ID, 798 Measurement Results, 799 Measurement Task] 800 ACK -> 802 The MA acts autonomously in terms of reporting; it simply sends 803 Reports as defined by the Controller's Instruction. 805 The Report contains: 807 o the MA's identifier, or perhaps a Group-ID to anonymise results 809 o the actual Measurement Results, including the time they were 810 measured 812 o the details of the Measurement Task (to avoid the Collector having 813 to ask the Controller for this information later) 815 Depending on the requirements of the measurement system, the MA might 816 label, or perhaps not include, Measurement Results impacted by for 817 instance cross-traffic or the MP being busy. If applicable the 818 Measurement Report includes the start and end of suppression. 820 The MA may report the results to more than one Collector, if the 821 Instruction says so. It could report a different subset of Results 822 to different Collectors. 824 The LMAP WG will define a Report Protocol and its associated Data 825 Model that implements the Protocol & Information Model. This may be 826 a simple instruction - response protocol, and LMAP will specify how 827 it operates over an existing protocol - to be selected, perhaps REST- 828 style HTTP(s) or IPFIX. 830 5.5. Items beyond the scope of the LMAP Protocol Model 832 There are several potential interactions between LMAP elements that 833 are out of scope of definition by the LMAP WG: 835 1. It does not define a coordination process between MAs. Whilst a 836 measurement system may define coordinated Measurement Schedules 837 across its various MAs, there is no direct coordination between 838 MAs. 840 2. It does not define interactions between the Collector and 841 Controller. It is quite likely that there will be such 842 interactions, probably intermediated by the data analysis tools. 843 For example if there is an "interesting" Measurement Result then 844 the measurement system may want to trigger extra Measurement 845 Tasks that explore the potential cause in more detail. 847 3. It does not define coordination between different measurement 848 systems. For example, it does not define the interaction of a MA 849 in one measurement system with a Controller or Collector in a 850 different measurement system. Whilst it is likely that the 851 Control and Report protocols could be re-used or adapted for this 852 scenario, any form of coordination between different 853 organisations involves difficult commercial and technical issues 854 and so, given the novelty of large-scale measurement efforts, any 855 form of inter-organisation coordination is outside the scope of 856 the LMAP WG. Note that a single MA is instructed by a single 857 Controller and is only in one measurement system. 859 * An interesting scenario is where a home contains two 860 independent MAs, for example one controlled by a regulator and 861 one controlled by an ISP. Then the test traffic of one MA is 862 treated by the other MA just like any other user traffic. 864 4. It does not specifically define a user-initiated measurement 865 system, see sub-section. 867 5.5.1. User-controlled measurement system 869 The WG concentrates on the cases where an ISP or a regulator runs the 870 measurement system. However, we expect that LMAP functionality will 871 also be used in the context of an end user-controlled measurement 872 system. There are at least two ways this could happen (they have 873 various pros and cons): 875 1. a user could somehow request the ISP- (or regulator-) run 876 measurement system to test his/her line. The ISP (or regulator) 877 Controller would then send an Instruction to the MA in the usual 878 LMAP way. Note that a user can't directly initiate a Measurement 879 Task on an ISP- (or regulator-) controlled MA. 881 2. a user could deploy their own measurement system, with their own 882 MA, Controller and Collector. For example, the user could 883 download all three functions onto the same user-owned end device; 884 then the LMAP Control and Report protocols do not need to be 885 used, but using LMAP's Information Model would still be 886 beneficial. The MP could be in the home gateway or outside the 887 home network; in the latter case the MP is highly likely to be 888 run by a different organisation, which raises extra privacy 889 considerations. 891 In both cases there will be some way for the user to initiate the 892 Measurement Task(s). The mechanism is out-of-scope of the LMAP WG, 893 but could include the user clicking a button on a GUI or sending a 894 text message. Presumably the user will also be able to see the 895 Measurement Results, perhaps summarised on a webpage. It is 896 suggested that these interfaces conform to the LMAP guidance on the 897 privacy of the Measurement Results and Subscriber information. 899 6. Details of the LMAP framework 901 This section contains a more detailed discussion of the four 902 components of the LMAP framework. 904 6.1. Measurement Agent (MA) 906 The Measurement Agent is the component that is responsible for 907 executing the Measurement Tasks. The Measurement Agent could take a 908 number of forms: a dedicated probe, software on a PC, embedded into 909 an appliance, or even embedded into a gateway. A single site (home, 910 branch office etc.) that is participating in a measurement could make 911 use of one or multiple Measurement Agents in a single measurement 912 e.g., if there are multiple output interfaces, there might be a 913 Measurement Agent per interface. The Measurement Agent's 914 configuration (specifically which Controller to initially connect 915 to), is out of scope within LMAP. However, depending on the type of 916 probe, it could be manually configured by the user, pre-configured 917 before shipment to the end user, or configured by the application (in 918 the case of some PC based Measurement Agents). For example, a 919 Measurement Agent that is included in the app for a content provider 920 might be configured automatically by the content provider to use the 921 content provider's LMAP Controller. That said, there should be an 922 element of local premises configuration that allows the Measurement 923 Agent (especially in the case of Active Measurements Tasks) to mimic 924 performance of user applications at the same site. For example, 925 making use of the same DNS server as the remainder of the site. The 926 Measurement Agent could be deployed in a variety of locations. Not 927 all deployment locations are available to every kind of Measurement 928 Agent operator. There are also a variety of limitations and trade- 929 offs depending on the final placement. The next sections outline 930 some of the locations a Measurement Agent may be deployed. This is 931 not an exhaustive list and combinations of the below may also apply. 933 6.1.1. Measurement Agent embedded in site gateway 934 A Measurement Agent embedded with the site gateway (e.g. in the case 935 of a a branch office in a managed service environment) is one of 936 better places the Measurement Agent could be deployed. All site to 937 ISP traffic would traverse through the gateway and passive 938 measurements could easily be performed. Similarly, due to this user 939 traffic visibility, an Active Measurements Task could be rescheduled 940 so as not to compete with user traffic. Generally NAT and firewall 941 services are built into the gateway, allowing the Measurement Agent 942 the option to offer its Controller facing management interface 943 outside of the NAT/firewall. This placement of the management 944 interface allows the Controller to unilaterally contact the 945 Measurement Agent for instructions. However, if the site gateway is 946 owned and operated by the service provider, the Measurement Agent 947 will generally not be available for over the top providers, the 948 regulator, end users or enterprises. 950 6.1.2. Measurement Agent embedded behind Site NAT /Firewall 952 The Measurement Agent could also be embedded behind a NAT, a 953 firewall, or both. In this case the Controller may not be able to 954 unilaterally contact the Measurement Agent unless either static port 955 forwarding configuration or firewall pin holing is configured. This 956 would require user intervention, and ultimately might not be an 957 option available to the user (perhaps due to permissions). The 958 Measurement Agent may originate a session towards the Controller and 959 maintain the session for bidirectional communications. This would 960 alleviate the need to have user intervention on the gateway, but 961 would reduce the overall scalability of the Controller as it would 962 have to maintain a higher number of active sessions. That said, 963 sending keepalives to prop open the firewall could serve a dual 964 purpose in testing network reachability for the Measurement Agent. 965 An alternative would be to use a protocol such as UPnP or PCP 966 [RFC6887] to control the NAT/firewall if the gateway supports this 967 kind of control. 969 6.1.3. Measurement Agent in-line with site gateway 970 As mentioned earlier, there are benefits in the Measurement Agent's 971 ability to observe the site's user traffic. It allows the 972 Measurement Agent to back off a potentially disruptive Active 973 Measurements Task to avoid impacting the user. A Passive 974 Measurements Task allows the Measurement Agent to gather data without 975 the overhead of Test Traffic (of interest to both the site user and 976 network operator) as well as potentially provide a greater number of 977 samples. A Measurement Agent behind the gateway would generally not 978 be privy to observation of the user traffic unless the Measurement 979 Agent was placed in-line with the site gateway or the site gateway 980 traffic was replicated to the Measurement Agent (a capability 981 generally not found in home broadband gateways). 983 6.1.4. Measurement Agent in multi homed site 985 A broadband site may be multi-homed. For example, the site may be 986 connected to multiple broadband ISPs (perhaps for redundancy or load- 987 sharing), or have a broadband as well as mobile/WiFi connectivity. 988 It may also be helpful to think of dual stack IPv4 and IPv6 broadband 989 sites as multi-homed. In these cases, there needs to be clarity on 990 which network connectivity option is being measured. Sometimes this 991 is easily resolved by the location of the MA itself. For example, if 992 the MA is built into the gateway (and the gateway only has a single 993 WAN side interface), there is little confusion or choice. However, 994 for multi-homed gateways or devices behind the gateway(s) of multi- 995 homed sites it would be preferable to explicitly select the network 996 to measure (e.g. [RFC5533]) but the network measured should be 997 included in the Measurement Result. Section 3.2 of [I-D.ietf- 998 homenet-arch] describes dual-stack and multi-homing topologies that 999 might be encountered in a home network (which is generally a 1000 broadband connected site). The Multiple Interfaces (mif) working 1001 group covers cases where hosts are either directly attached to 1002 multiple networks (physical or virtual) or indirectly (multiple 1003 default routers, etc.). xref target="RFC6419"/> provides the current 1004 practices of multi-interfaces hosts today. As some of the end goals 1005 of a MA is to replicate the end user's network experience, it is 1006 important to understand the current practices. 1008 6.2. Measurement Peer (MP) 1009 A Measurement Peer is the other side of an Active Measurements Task - 1010 the target of Test Traffic from a Measurement Agent. The Measurement 1011 Peer could also take many different forms: a web site, a service 1012 (VoIP), a DNS server, an application specific server (e.g., webex), a 1013 well known web site (e.g., youtube, google search), even another 1014 Measurement Agent in another home could perform as a Measurement Peer 1015 for a given Measurement Task. Particularly useful could be a MP that 1016 is well placed bandwidth-wise and can handle thousand of sessions of 1017 Test Traffic. 1019 6.3. Controller 1021 A Controller is responsible for providing the Measurement Agent with 1022 instructions which include the Measurement Schedule, parameters, etc. 1023 It is basically the entity controlling the Measurement Agents in a 1024 LMAP domain. 1026 For scaling purposes there may be several Controllers, perhaps 1027 regionally located. A large scale test making use of multiple 1028 Controllers would need a master Controller that is the ultimate 1029 source of direction. 1031 6.4. Collector 1033 A Collector is responsible for receiving the Measurement Results from 1034 the Measurement Agent at the end of a Measurement Task. It may have 1035 additional features such as aggregating the results across multiple 1036 Measurement Agents, remove outliers, create additional statistics, 1037 (depending on usage of data) anonymization of results for privacy 1038 reasons (if not done already in the Measurement Agents) etc. The 1039 work of anonymization of user identifiable data has been addressed 1040 for IPFIX via RFC6235 [RFC6235]. For scaling purposes there may be 1041 several Collectors, perhaps regionally located. A large scale test 1042 making use of multiple Collectors would need to aggregate/consolidate 1043 their results for the complete picture. 1045 7. Security considerations 1047 The security of the LMAP framework should protect the interests of 1048 the measurement operator(s), the network user(s) and other actors who 1049 could be impacted by a compromised measurement deployment. 1051 We assume that each Measurement Agent will receive test 1052 configuration, scheduling and reporting instructions from a single 1053 organisation (operator of the Controller). These instructions must 1054 be authenticated (to ensure that they come from the trusted 1055 Controller), checked for integrity (to ensure no-one has tampered 1056 with them) and be prevented from replay. If a malicious party can 1057 gain control of the Measurement Agent they can use the MA 1058 capabilities to launch DoS attacks at targets, reduce the network 1059 user experience and corrupt the measurement results that are reported 1060 to the Collector. By altering the tests that are operated and/or the 1061 Collector address they can also compromise the confidentiality of the 1062 network user and the MA environment (such as information about the 1063 location of devices or their traffic). 1065 The reporting of the MA must also be secured to maintain 1066 confidentiality. The results must be encrypted such that only the 1067 authorised Collector can decrypt the results to prevent the leakage 1068 of confidential or private information. In addition it must be 1069 authenticated that the results have come from the expected MA and 1070 that they have not been tampered with. It must not be possible to 1071 fool a MA into injecting falsified data into the measurement platform 1072 or to corrupt the results of a real MA. 1074 Availability should also be considered. While the loss of some MAs 1075 may not be considered critical, the unavailability of the Collector 1076 could mean that valuable business data or data critical to a 1077 regulatory process is lost. Similarly, the unavailability of a 1078 Controller could mean that the MAs do not operate a correct 1079 Measurement Schedule. 1081 A malicious party could "game the system". For example, where a 1082 regulator is running a measurement system in order to benchmark 1083 operators, an operator could try to identify the broadband lines that 1084 the regulator was measuring and prioritise that traffic. This 1085 potential issue is currently handled by a code of conduct. It is 1086 outside the scope of the LMAP WG to consider the issue. 1088 8. Privacy Considerations for LMAP 1090 Comment: It may be better to create a separate draft about 'LMAP 1091 threats and considerations' containing this section and perhaps the 1092 security section. 1094 The LMAP Working Group will consider privacy as a core requirement 1095 and will ensure that by default measurement and collection mechanisms 1096 and protocols operate in a privacy-sensitive manner, i.e. that 1097 privacy features are well-defined. 1099 This section provides a set of privacy considerations for LMAP. This 1100 section benefits greatly from the timely publication of [RFC6973]. 1101 There are dependencies on the integrity of the LMAP security 1102 mechanisms, described in the Security Considerations section above. 1104 We begin with a set of assumptions related to protecting the 1105 sensitive information of individuals and organizations participating 1106 in LMAP-orchestrated measurement and data collection. 1108 8.1. Categories of Entities with Information of Interest 1110 LMAP protocols need to protect the sensitive information of the 1111 following entities, including individuals and organizations who 1112 participate in measurement and collection of results. 1114 o Individual Internet Users: Persons who utilize Internet access 1115 services for communications tasks, according to the terms of 1116 service of a service agreement. Such persons may be a Service 1117 Subscriber, or have been given permission by the subscriber to use 1118 the service. 1120 o Internet Service Providers: Organizations who offer Internet 1121 access service subscriptions, and thus have access to sensitive 1122 information of Individuals who choose to use the service. These 1123 organizations desire to protect their subscribers and their own 1124 sensitive information which may be stored in the process of 1125 measurement and result collection. 1127 o Other LMAP system Operators: Organizations who operate measurement 1128 systems or participate in measurements in some way. 1130 8.2. Examples of Sensitive Information 1132 This section gives examples of sensitive information which may be 1133 measured or stored in a measurement system, and which is to be kept 1134 private by default in the LMAP core protocols. 1136 Examples of Subscriber or authorized Internet User Sensitive 1137 Information: 1139 o IP address in use 1141 o Personal Identification (Real Name) 1143 o Location (street address, city) 1145 o Subscribed Service Parameters 1147 o Contents of Traffic (Activity, DNS queries, Destinations, 1148 Equipment types, Account info for other services, etc.) 1150 o Status as a study volunteer and Schedule of (Active) Measurement 1151 Tasks 1153 Examples of Internet Service Provider Sensitive Information: 1155 o Measurement Device Identification (Equipment ID and IP address) 1157 o Measurement Instructions (choice of measurements) 1159 o Measurement Results (some may be shared, others may be private) 1161 o Measurement Schedule (exact times) 1163 o Network Topology (Locations, Connectivity, Redundancy) 1165 o Subscriber billing information, and any of the above Subscriber 1166 Information known to the provider. 1168 o Authentication credentials (e.g., certificates) 1170 Other organizations will have some combination of the lists above. 1172 8.3. Key Distinction Between Active and Passive Measurement Tasks 1174 For the purposes of this memo, we define Passive and Active 1175 Measurements Tasks as follows: 1177 Passive: measurements conducted on Internet User traffic, such that 1178 sensitive information is present and stored in the measurement system 1179 (however briefly this storage may be). 1181 Active: measurements conducted on traffic which serves only the 1182 purpose of measurement. Even if a user host generates active 1183 measurement traffic, there is significantly limited sensitive 1184 information present and stored in the measurement system compared to 1185 the passive case, as follows: 1187 o IP address in use 1189 o Status as a study volunteer and schedule of active tests 1191 On the other hand, the sensitive information for an Internet Service 1192 Provider is the same whether active or passive measurements are used. 1194 8.4. Communications Model (for Privacy) 1196 This section briefly presents a set of communication models for LMAP. 1197 We assume that the Measurement Agent is located behind a NAT/ 1198 Firewall, so it performs the role of Initiator for all 1199 communications. 1201 From a privacy perspective, all LMAP entities can be considered 1202 "observers" according to the definition in [RFC6973]. Their stored 1203 information potentially poses a threat to privacy, especially if one 1204 or more of these functional entities has been compromised. 1206 Likewise, all devices on the paths used for control, reporting, and 1207 measurement are also observers. We note this in the figures below by 1208 identifying the possible presence of a NAT, which has additional 1209 significance to the protocols and direction of initiation. 1211 8.4.1. Controller <-> Measurement Agent 1213 The high-level communication model for interactions between the LMAP 1214 Controller and Measurement Agent is illustrated below. The primary 1215 purpose of this exchange is to authenticate and task a Measurement 1216 Agent with Measurement Instructions, which the Measurement Agent then 1217 acts on autonomously. 1219 _________________ _________________ 1220 | | | | 1221 | Controller |=========== NAT ? ==========| Meas Agent | 1222 |_________________| |_________________| 1224 <- Key Negotiation & 1225 Encryption Setup 1226 Encrypted Channel -> 1227 Established 1228 Request Capabilities -> 1229 Equipment ID & Status 1230 <- Reply Equipment ID 1231 Capabil. & Status 1232 Measurement -> 1233 Instruction 1234 (MP IP Addrs, set of 1235 Metrics, Schedule) 1236 <- ACK (new Status) 1238 Primarily IP addresses and pseudonyms are exchanged first, then 1239 measurement-related information of interest such as the metrics, 1240 schedule, and IP addresses of measurement devices. 1242 An organization operating the controller having no service 1243 relationship with the user who hosts the measurement agent *could* 1244 gain real-name mapping to public IP address through user 1245 participation in an LMAP system. 1247 8.4.2. Collector <-> Measurement Agent 1249 The high-level communication model for interactions between the LMAP 1250 Measurement Agent and Collector is illustrated below. The primary 1251 purpose of this exchange is to authenticate and collect results from 1252 a Measurement Agent, which it has measured autonomously and stored. 1254 _________________ _________________ 1255 | | | | 1256 | Collector |=========== NAT ? ==========| Meas Agent | 1257 |_________________| |_________________| 1259 <- Key Negotiation & 1260 Encryption Setup 1261 Encrypted Channel -> 1262 Established 1263 Request Capabilities? -> 1264 Equipment ID & Status 1265 <- Reply Equipment ID 1266 Capabil. & Status 1267 <- Measurement Results 1268 (MP IP Addrs, set of 1269 Metrics, Values) 1270 ACK -> 1272 Primarily IP addresses and pseudonyms are exchanged first, then 1273 measurement-related information of interest such as the metrics, 1274 schedule, results, and IP addresses of measurement devices. 1276 An organization operating the collector having no service 1277 relationship with the user who hosts the measurement agent *could* 1278 gain real-name mapping to public IP address through user 1279 participation in an LMAP system. 1281 8.4.3. Active Measurement Peer <-> Measurement Agent 1283 Although the specification of the mechanisms for measurement is 1284 beyond the LMAP scope, the high-level communications model below 1285 illustrates measurement information and results flowing between 1286 active measurement devices as a potential privacy issue. The primary 1287 purpose of this exchange is to execute measurements and store the 1288 results. 1290 _________________ _________________ 1291 | | | | 1292 | Meas Peer |=========== NAT ? ==========| Meas Agent | 1293 |_________________| |_________________| 1294 <- Key Negotiation & 1295 Encryption Setup 1296 Encrypted Channel -> 1297 Established 1298 Announce Capabilities -> 1299 & Status 1300 <- Select Capabilities 1301 ACK -> 1302 <- Measurement Request 1303 (MA+MP IPAddrs,set of 1304 Metrics, Schedule) 1305 ACK -> 1307 Measurement Traffic <> Measurement Traffic 1308 (may/may not be encrypted) (may/may not be encrypted) 1310 <- Stop Tests 1312 Return Results -> 1313 (if applicable) 1314 <- ACK, Close 1316 This exchange primarily exposes the IP addresses of measurement 1317 devices and the inference of measurement participation from such 1318 traffic. There may be information on key points in a service 1319 provider's network. There may also be access to measurement-related 1320 information of interest such as the metrics, schedule, and results. 1322 If the measurement traffic is unencrypted, as found in many systems 1323 today, then both timing and limited results are open to observers. 1325 8.4.4. Passive Measurement Peer <-> Measurement Agent 1327 Although the specification of the mechanisms for measurement is 1328 beyond the LMAP scope, the high-level communications model below 1329 illustrates passive monitoring and measurement of information flowing 1330 between production network devices as a potential privacy issue. The 1331 primary purpose of this model is to illustrate collection of user 1332 information of interest with the Measurement Agent performing the 1333 monitoring and storage of the results. This particular exchange is 1334 for DNS Response Time, which most frequently uses UDP transport. 1336 _________________ ___________ _____ 1337 | | | | | | 1338 | Meas Peer DNS |=========== NAT ? ==========| Meas Agent|=|User | 1339 |_________________| |___________| |_____| 1340 <- Name Resolution Req 1341 (MA+MP IPAddrs, 1342 Desired Domain Name) 1343 Return Record -> 1345 This exchange primarily exposes the IP addresses of measurement 1346 devices and the intent to communicate with, or access the services of 1347 "Domain Name". There may be information on key points in a service 1348 provider's network, such as the address of one of its DNS servers. 1349 The Measurement Agent may be embedded in the User host, or it may be 1350 located in another device capable of observing user traffic. 1352 In principle, any of the Internet User information of interest 1353 (listed above) can be collected and stored in the passive monitoring 1354 scenario. 1356 8.4.5. Result Storage and Reporting 1358 Although the mechanisms for communicating results (beyond the initial 1359 Collector) are beyond the LMAP scope, there are potential privacy 1360 issues related to a single organization's storage and reporting of 1361 measurement results. Both storage and reporting functions can help 1362 to preserve privacy by implementing the mitigations described below. 1364 8.5. Threats 1366 This section indicates how each of the threats described in [RFC6973] 1367 apply to the LMAP entities and their communication and storage of 1368 "information of interest". 1370 8.5.1. Surveillance 1372 Section 5.1.1 of [RFC6973] describes Surveillance as the "observation 1373 or monitoring of and individual's communications or activities." 1375 All of passive measurement is surveillance, with inherent risks. 1377 Active measurement methods which avoid periods of user transmission 1378 indirectly produce a record of times when a subscriber or authorized 1379 user has utilized their Internet access service. 1381 Active measurements may also utilize and store a subscriber's 1382 currently assigned IP address when conducting measurements that are 1383 relevant to a specific subscriber. Since the measurements are time- 1384 stamped, the measurement results could provide a record of IP address 1385 assignments over time. 1387 Either of the above pieces of information could be useful in 1388 correlation and identification, described below. 1390 8.5.2. Stored Data Compromise 1392 Section 5.1.2 of [RFC6973] describes Stored Data Compromise as 1393 resulting from inadequate measures to secure stored data from 1394 unauthorized or inappropriate access. 1396 The primary LMAP entity subject to compromise is the results storage 1397 which serves the Collector function (also applicable to temporary 1398 storage on the Collector itself). Extensive security and privacy 1399 threat mitigations are warranted for the storage system. Although 1400 the scope of its measurement and storage is smaller than the 1401 collector's, an individual Measurement Agent stores sensitive 1402 information temporarily, and also needs protections. 1404 The LMAP Controller may have direct access to storage of Service 1405 Parameters, Subscriber information (location, billing, etc.), and 1406 other information which the controlling organization considers 1407 private, and needs protection in this case. 1409 The communications between the local storage of the Collector and 1410 other storage facilities (possibly permanent mass storage), is beyond 1411 the scope of the LMAP work at this time, though this communications 1412 channel will certainly need protection as well as the mass storage. 1414 8.5.3. Correlation and Identification 1416 Sections 5.2.1 and 5.2.2 of [RFC6973] describes Correlation as 1417 combining various pieces of information to obtain desired 1418 characteristics of an individual, and Identification as using this 1419 process to infer identity. 1421 The main risk is that the LMAP system could un-wittingly provide a 1422 key piece of the correlation chain, starting with an unknown 1423 Subscriber's IP address and another piece of information (e.g., 1424 Subscriber X utilized Internet access from 2000 to 2310 UTC, because 1425 the active measurements were deferred, or sent a name resolution for 1426 www.example.com at 2300 UTC). 1428 8.5.4. Secondary Use and Disclosure 1430 Sections 5.2.3 and 5.2.4 of [RFC6973] describes Secondary Use as 1431 unauthorized utilization of an individual's information for a purpose 1432 the individual did not intend, and Disclosure is when such 1433 information is revealed causing other's notions of the individual to 1434 change, or confidentiality to be violated. 1436 The collection and reporting of passive traffic measurements is a 1437 form of secondary use, and subscribers' permission should be obtained 1438 before measurement. Although user traffic is only indirectly 1439 involved, active measurement results provide limited information 1440 about the subscriber and may constitute secondary use. 1442 8.6. Mitigations 1444 This section examines the mitigations listed in section 6 of 1445 [RFC6973] and their applicability to LMAP systems. Note that each 1446 section in [RFC6973] identifies the threat categories that each 1447 technique mitigates. 1449 8.6.1. Data Minimization 1451 Section 6.1 of [RFC6973] encourages collecting and storing the 1452 minimal information needed to perform a task. 1454 There are two levels of information needed for LMAP results to be 1455 useful for a specific task: Network Operator and User 1456 troubleshooting, and General results reporting. 1458 The minimal supporting information for general results is conducive 1459 to protection of sensitive information, as long as the results can be 1460 aggregated into large categories (e.g., the month of March, all 1461 subscribers West of the Mississippi River). In this case, all 1462 individual identifications (including IP address of the MA) can be 1463 excluded, and only the results applicable to the desired measurement 1464 path are provided.. However, this implies a filtering process to 1465 reduce the information fields allocated to this task, because greater 1466 detail was needed to conduct the measurements in the first place. 1468 For a Network Operator and User troubleshooting a performance issue 1469 or failure, potentially all the network information (e.g., IP 1470 addresses, equipment IDs, location), measurement schedule, service 1471 configuration, measurement results and other information may assist 1472 in the process. This includes the information needed to conduct the 1473 measurements, and represents a need where the maximum relevant 1474 information is desirable, therefore the greatest protections should 1475 be applied. 1477 We note that a user may give temporary permission for passive 1478 measurements to enable detailed troubleshooting, but withhold 1479 permission for passive measurements in general. Here the greatest 1480 breadth of sensitive information is potentially exposed, and the 1481 maximum privacy protection must be provided. 1483 For MAs with access to the sensitive information of users (e.g., 1484 within a home or a personal host/handset), it is desirable for the 1485 results collection to minimize the data reported, but also to balance 1486 this desire with the needs of troubleshooting when a service 1487 subscription exists between the user and organization operating the 1488 measurements. 1490 For passive measurements where the MA reports flow information to the 1491 Collector, the Collector may perform pre-storage minimization and 1492 other mitigations (below) to help preserve privacy. 1494 8.6.2. Anonymity 1496 Section 6.1.1 of [RFC6973] describes a way in which anonymity is 1497 achieved: "there must exist a set of individuals that appear to have 1498 the same attributes as the individual", defined as an "anonymity 1499 set". 1501 Experimental Methods for anonymization of user identifiable data 1502 applicable to passive measurement have been identified in [RFC6235]. 1503 However, the findings of several of the same authors is that "there 1504 is increasing evidence that anonymization applied to network trace or 1505 flow data on its own is insufficient for many data protection 1506 applications as in [Bur10]." 1508 Essentially, the details of passive flow measurements can only be 1509 accessed by closed organizations, and unknown injection attacks are 1510 always less expensive than the protections from them. However, some 1511 forms of summarized passive measurement may protect the user's 1512 sensitive information sufficiently well, and so each metric must be 1513 evaluated in the light of privacy. 1515 The methods in [RFC6235] could be applied more successfully in active 1516 measurement, where there are protections from injection attack. The 1517 successful attack would require breaking the integrity protection of 1518 the LMAP reporting protocol and injecting measurement results (known 1519 fingerprint, see section 3.2 of [RFC6973]) for inclusion with the 1520 shared and anonymized results, then fingerprinting those records to 1521 ascertain the anonymization process. 1523 Beside anonymization of measured results for a specific user or 1524 provider, the value of sensitive information can be further diluted 1525 by summarizing the results over many individuals or areas served by 1526 the provider. There is an opportunity enabled by forming anonymity 1527 sets [RFC6973] based on the reference path measurement points in [I-D 1528 .ietf-ippm-lmap-path]. For example, all measurements from the 1529 Subscriber device can be identified as "mp000", instead of using the 1530 IP address or other device information. The same anonymization 1531 applies to the Internet Service Provider, where their Internet 1532 gateway would be referred to as "mp190". 1534 8.6.3. Pseudonymity 1536 Section 6.1.2 of [RFC6973] indicates that pseudonyms, or nicknames, 1537 are a possible mitigation to revealing one's true identity, since 1538 there is no requirement to use real names in almost all protocols. 1540 A pseudonym for a measurement device's IP address could be an LMAP- 1541 unique equipment ID. However, this would likely be a permanent 1542 handle for the device, and long-term use weakens a pseudonym's power 1543 to obscure identity. 1545 8.6.4. Other Mitigations 1547 Sections 6.2 and 6.3 of [RFC6973] describe User Participation and 1548 Security, respectively. 1550 Where LMAP measurements involve devices on the Subscriber's premises 1551 or Subscriber-owned equipment, it is essential to secure the 1552 Subscriber's permission with regard to the specific information that 1553 will be collected. 1555 LMAP protocols, devices, and the information they store clearly need 1556 to be secure from unauthorized access. This is the hand-off between 1557 privacy and security considerations, found elsewhere in this memo. 1559 8.7. The potential role of a Group-ID for privacy 1561 A group identifier may be useful to help maintain privacy. Several 1562 MAs would share the same Group-ID. This has been suggested where the 1563 endusers are sensitive about privacy, for example mobile users do not 1564 want their location tracked. Some possibilities are discussed below. 1566 A Group-ID might be used when Results are forwarded by a Collector to 1567 a third party. The measurement system operates using MA-IDs, however 1568 if Results are sent to a third party then Results from several MAs 1569 are aggregated together, in order to prevent the third party tracking 1570 them to an individual MA or enduser. 1572 A Group-ID could be used for Reporting. The Controller's Instruction 1573 still refers to an MA using its MA-ID, but Results are reported to 1574 the Collector including a Group-ID but not an MA-ID. This might be 1575 useful where the measurement system is not run by the ISP (in the 1576 mobile example, the user clearly wants the operator track their 1577 location). The Group-ID needs to be sensible, for example MAs with 1578 the same broadband product (it is not sensible to aggregate Results 1579 from MAs on 2Mb/s and 300Mb/s lines). Note that: 1581 o A malicious MA could bias overall results by reporting more or 1582 less often than it is supposed to. The use of a Group-ID makes 1583 this harder for a Collector to detect. 1585 o An attacker is more likely to be able to break the MA-Collector 1586 communications, since it can only be secured at the group level, 1587 for instance with a shared password. The attacker could then 1588 report false Results. Securing at the individual MA level 1589 intrinsically reveals the MA's identity 1591 o A malicious Collector can probably use other information to 1592 deaggregate the Results per MA, for example by tracking its IP 1593 address or analysing some per-MA 'fingerprint' information 1594 associated with the MA-Collector transmission protocol 1596 o A conspiratorial Controller could create a per-MA fingerprint (for 1597 example a unique set of parameters for the Measurement Tasks or 1598 simply a regular time at which the MA reports), which the 1599 Collector uses to identify the MA 1601 o A well-behaved Collector ensures that it only stores the Group-ID 1602 and throws away per-MA information. Then it cannot subsequently 1603 disaggregate Results per MA - such a breakdown might be requested 1604 by a government agency, an attacker or even by the measurement 1605 system itself (say after a change of company policy). In this 1606 case, the MA-Collector communication can be secured per MA, 1607 providing authentication is changed regularly and/or cannot be 1608 linked to the repository with the Measurement Results. In 1609 principle the scenario doesn't need a Group-ID to be defined for 1610 the Report Protocol - since the Collector can implement the Group- 1611 ID locally, after Results are reported. 1613 A Group-ID could be used for Control as well as Reporting. The same 1614 Instruction is broadcast to all MAs, which check that they have a 1615 matching group-id before carrying out the Instruction. Notes: 1617 o The first three bullets above still apply 1618 o In addition, the Controller-MA communication is now also less 1619 secure 1621 o All the MAs with the same Group-ID probably need to be able to run 1622 exactly the same set of Measurement Methods. 1624 o At least at first glance, failure handling is harder. It is much 1625 less useful for the MA to inform the Controller that it cannot 1626 understand or execute an Instruction - the Controller simply knows 1627 that one or more MAs, with a particular Group-ID, cannot 1628 understand or execute the Instruction. There also seems no point 1629 an MA reporting the Measurement Methods that it understands (which 1630 is intended to help a Controller that has forgotten an MA's 1631 capabilities, perhaps after a crash) 1633 Conclusion - this topic needs more discussion. The use of per-MA 1634 authentication for security seems in tension with the use of Group- 1635 IDs for privacy. 1637 9. IANA Considerations 1639 There are no IANA considerations in this memo. 1641 10. Acknowledgments 1643 This document is a merger of three individual drafts: draft-eardley- 1644 lmap-terminology-02, draft-akhter-lmap-framework-00, and draft- 1645 eardley-lmap-framework-02. 1647 Thanks to numerous people for much discussion, directly and on the 1648 LMAP list. This document tries to capture the current conclusions. 1649 Thanks to Juergen Schoenwaelder for his detailed review of the 1650 terminology. 1652 Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on 1653 the Leone research project, which receives funding from the European 1654 Union Seventh Framework Programme [FP7/2007-2013] under grant 1655 agreement number 317647. 1657 11. History 1659 First WG version, copy of draft-folks-lmap-framework-00. 1661 11.1. From -00 to -01 1663 o new sub-section of possible use of Group-IDs for privacy 1665 o tweak to definition of Control protocol 1667 o fix typo in figure in S5.4 1669 12. Informative References 1671 [I-D.linsner-lmap-use-cases] 1672 Linsner, M., Eardley, P., and T. Burbridge, "Large-Scale 1673 Broadband Measurement Use Cases", draft-linsner-lmap-use- 1674 cases-04 (work in progress), October 2013. 1676 [lmap-yang] 1677 , "A YANG Data Model for LMAP Measurement Agents", , 1678 . 1680 [lmap-netconf] 1681 , "Considerations on using NETCONF with LMAP Measurement 1682 Agents", , 1683 . 1685 [lmap-ipfix] 1686 , "An LMAP application for IPFIX", , 1687 . 1689 [registry] 1690 , , , , , "A registry for commonly used metrics. 1691 Independent registries", , . 1694 [RFC6241] , , , , "Network Configuration Protocol (NETCONF)", , 1695 . 1697 [yang-api] 1698 , "YANG-API Protocol", , 1699 . 1701 [schulzrinne] 1702 , , , "Large-Scale Measurement of Broadband Performance: 1703 Use Cases, Architecture and Protocol Requirements", , 1704 . 1707 [information-model] 1708 Burbridge, T., Eardley, P., Bagnulo, M., and J. 1709 Schoenwaelder, "Information Model for Large-Scale 1710 Measurement Platforms (LMAP)", , . 1713 [Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, 1714 "The Role of Network Trace Anonymization Under Attack", 1715 January 2010. 1717 [Q1741] Q.1741.7, ., "IMT-2000 references to Release 9 of GSM- 1718 evolved UMTS core network", 1719 http://www.itu.int/rec/T-REC-Q.1741.7/en, November 2011. 1721 [I-D.bagnulo-ippm-new-registry-independent] 1722 Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and 1723 A. Morton, "A registry for commonly used metrics. 1724 Independent registries", draft-bagnulo-ippm-new-registry- 1725 independent-01 (work in progress), July 2013. 1727 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1728 "Framework for IP Performance Metrics", RFC 2330, May 1729 1998. 1731 [I-D.mathis-ippm-model-based-metrics] 1732 Mathis, M. and A. Morton, "Model Based Internet 1733 Performance Metrics", draft-mathis-ippm-model-based- 1734 metrics-01 (work in progress), February 2013. 1736 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1737 Delay Metric for IPPM", RFC 2681, September 1999. 1739 [I-D.burbridge-lmap-information-model] 1740 Burbridge, T., Eardley, P., Bagnulo, M., and J. 1741 Schoenwaelder, "Information Model for Large-Scale 1742 Measurement Platforms (LMAP)", draft-burbridge-lmap- 1743 information-model-00 (work in progress), July 2013. 1745 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization 1746 Support", RFC 6235, May 2011. 1748 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1749 Morris, J., Hansen, M., and R. Smith, "Privacy 1750 Considerations for Internet Protocols", RFC 6973, July 1751 2013. 1753 Authors' Addresses 1754 Philip Eardley 1755 British Telecom 1756 Adastral Park, Martlesham Heath 1757 Ipswich 1758 ENGLAND 1760 Email: philip.eardley@bt.com 1762 Al Morton 1763 AT&T Labs 1764 200 Laurel Avenue South 1765 Middletown, NJ 1766 USA 1768 Email: acmorton@att.com 1770 Marcelo Bagnulo 1771 Universidad Carlos III de Madrid 1772 Av. Universidad 30 1773 Leganes, Madrid 28911 1774 SPAIN 1776 Phone: 34 91 6249500 1777 Email: marcelo@it.uc3m.es 1778 URI: http://www.it.uc3m.es 1780 Trevor Burbridge 1781 British Telecom 1782 Adastral Park, Martlesham Heath 1783 Ipswich 1784 ENGLAND 1786 Email: trevor.burbridge@bt.com 1788 Paul Aitken 1789 Cisco Systems, Inc. 1790 96 Commercial Street 1791 Edinburgh, Scotland EH6 6LX 1792 UK 1794 Email: paitken@cisco.com 1795 Aamer Akhter 1796 Cisco Systems, Inc. 1797 7025 Kit Creek Road 1798 RTP, NC 27709 1799 USA 1801 Email: aakhter@cisco.com