draft-ietf-lmap-framework-00.txt   draft-ietf-lmap-framework-01.txt 
Network Working Group P. Eardley Network Working Group P. Eardley
Internet-Draft BT Internet-Draft BT
Intended status: Standards Track A. Morton Intended status: Standards Track A. Morton
Expires: April 06, 2014 AT&T Labs Expires: April 24, 2014 AT&T Labs
M. Bagnulo M. Bagnulo
UC3M UC3M
T. Burbridge T. Burbridge
BT BT
P. Aitken P. Aitken
A. Akhter A. Akhter
Cisco Systems Cisco Systems
October 03, 2013 October 21, 2013
A framework for large-scale measurement platforms (LMAP) A framework for large-scale measurement platforms (LMAP)
draft-ietf-lmap-framework-00 draft-ietf-lmap-framework-01
Abstract Abstract
Measuring broadband service on a large scale requires standardisation Measuring broadband service on a large scale requires standardisation
of the logical architecture and a description of the key protocols of the logical architecture and a description of the key protocols
that coordinate interactions between the components. The document that coordinate interactions between the components. The document
presents an overall framework for large-scale measurements. It also presents an overall framework for large-scale measurements. It also
defines terminology for LMAP (large-scale measurement platforms). defines terminology for LMAP (large-scale measurement platforms).
The document is a contribution towards the LMAP working group's The document is a contribution towards the LMAP working group's
milestone. milestone.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 06, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Outline of an LMAP-based measurement system . . . . . . . . . 7 3. Outline of an LMAP-based measurement system . . . . . . . . . 7
4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Measurement system is under the direction of a single 4.1. Measurement system is under the direction of a single
organisation . . . . . . . . . . . . . . . . . . . . . . 10 organisation . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Each MA may only have a single Controller at any point in 4.2. Each MA may only have a single Controller at any point in
time . . . . . . . . . . . . . . . . . . . . . . . . . . 11 time . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. LMAP Protocol Model . . . . . . . . . . . . . . . . . . . . . 11 5. LMAP Protocol Model . . . . . . . . . . . . . . . . . . . . . 11
5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 12 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 12
5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 13 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 14
5.3. Starting and stopping Measurement Tasks . . . . . . . . . 16 5.3. Starting and stopping Measurement Tasks . . . . . . . . . 16
5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 17 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 17
5.5. Items beyond the scope of the LMAP Protocol Model . . . . 18 5.5. Items beyond the scope of the LMAP Protocol Model . . . . 18
5.5.1. User-controlled measurement system . . . . . . . . . 19 5.5.1. User-controlled measurement system . . . . . . . . . 19
6. Details of the LMAP framework . . . . . . . . . . . . . . . . 19 6. Details of the LMAP framework . . . . . . . . . . . . . . . . 20
6.1. Measurement Agent (MA) . . . . . . . . . . . . . . . . . 19 6.1. Measurement Agent (MA) . . . . . . . . . . . . . . . . . 20
6.1.1. Measurement Agent embedded in site gateway . . . . . 20 6.1.1. Measurement Agent embedded in site gateway . . . . . 20
6.1.2. Measurement Agent embedded behind Site NAT /Firewall 20 6.1.2. Measurement Agent embedded behind Site NAT /Firewall 21
6.1.3. Measurement Agent in-line with site gateway . . . . . 21 6.1.3. Measurement Agent in-line with site gateway . . . . . 21
6.1.4. Measurement Agent in multi homed site . . . . . . . . 21 6.1.4. Measurement Agent in multi homed site . . . . . . . . 22
6.2. Measurement Peer (MP) . . . . . . . . . . . . . . . . . . 22 6.2. Measurement Peer (MP) . . . . . . . . . . . . . . . . . . 22
6.3. Controller . . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Controller . . . . . . . . . . . . . . . . . . . . . . . 23
6.4. Collector . . . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Collector . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security considerations . . . . . . . . . . . . . . . . . . . 23 7. Security considerations . . . . . . . . . . . . . . . . . . . 23
8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 24 8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 24
8.1. Categories of Entities with Information of Interest . . . 24 8.1. Categories of Entities with Information of Interest . . . 25
8.2. Examples of Sensitive Information . . . . . . . . . . . . 25 8.2. Examples of Sensitive Information . . . . . . . . . . . . 25
8.3. Key Distinction Between Active and Passive Measurement 8.3. Key Distinction Between Active and Passive Measurement
Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.4. Communications Model (for Privacy) . . . . . . . . . . . 26 8.4. Communications Model (for Privacy) . . . . . . . . . . . 26
8.4.1. Controller <-> Measurement Agent . . . . . . . . . . 26 8.4.1. Controller <-> Measurement Agent . . . . . . . . . . 27
8.4.2. Collector <-> Measurement Agent . . . . . . . . . . . 27 8.4.2. Collector <-> Measurement Agent . . . . . . . . . . . 28
8.4.3. Active Measurement Peer <-> Measurement Agent . . . . 28 8.4.3. Active Measurement Peer <-> Measurement Agent . . . . 28
8.4.4. Passive Measurement Peer <-> Measurement Agent . . . 29 8.4.4. Passive Measurement Peer <-> Measurement Agent . . . 29
8.4.5. Result Storage and Reporting . . . . . . . . . . . . 30 8.4.5. Result Storage and Reporting . . . . . . . . . . . . 30
8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 30 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 30 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 30
8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 30 8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 31
8.5.3. Correlation and Identification . . . . . . . . . . . 31 8.5.3. Correlation and Identification . . . . . . . . . . . 31
8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 31 8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 31
8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 31 8.6. Mitigations . . . . . . . . . . . . . . . . . . . . . . . 32
8.6.1. Data Minimization . . . . . . . . . . . . . . . . . . 31 8.6.1. Data Minimization . . . . . . . . . . . . . . . . . . 32
8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 33 8.6.2. Anonymity . . . . . . . . . . . . . . . . . . . . . . 33
8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 33 8.6.3. Pseudonymity . . . . . . . . . . . . . . . . . . . . 34
8.6.4. Other Mitigations . . . . . . . . . . . . . . . . . . 34 8.6.4. Other Mitigations . . . . . . . . . . . . . . . . . . 34
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8.7. The potential role of a Group-ID for privacy . . . . . . 34
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
12. Informative References . . . . . . . . . . . . . . . . . . . 34 11. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 11.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 37
12. Informative References . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
There is a desire to be able to coordinate the execution of broadband There is a desire to be able to coordinate the execution of broadband
measurements and the collection of measurement results across a large measurements and the collection of measurement results across a large
scale set of diverse devices. These devices could be software based scale set of diverse devices. These devices could be software based
agents on PCs, embedded agents in consumer devices (e.g. blu-ray agents on PCs, embedded agents in consumer devices (e.g. blu-ray
players), service provider controlled devices such as set-top players players), service provider controlled devices such as set-top players
and home gateways, or simply dedicated probes. It is expected that and home gateways, or simply dedicated probes. It is expected that
such a system could easily comprise 100k devices. Such a scale such a system could easily comprise 100k devices. Such a scale
skipping to change at page 5, line 46 skipping to change at page 5, line 50
Collector: A function that receives a Report from a Measurement Collector: A function that receives a Report from a Measurement
Agent. Colloquially, a Collector is a physical device that performs Agent. Colloquially, a Collector is a physical device that performs
this function. this function.
Controller: A function that provides a Measurement Agent with Controller: A function that provides a Measurement Agent with
Instruction(s). Colloquially, a Controller is a physical device that Instruction(s). Colloquially, a Controller is a physical device that
performs this function. performs this function.
Control Protocol: The protocol delivering Instruction(s) from a Control Protocol: The protocol delivering Instruction(s) from a
Controller to a Measurement Agent. Controller to a Measurement Agent. It also delivers logging
information and capabilities information from the Measurement Agent
to the Controller.
Cycle-ID: A tag that is sent by the Controller in an Instruction and Cycle-ID: A tag that is sent by the Controller in an Instruction and
echoed by the MA in its Report; Measurement Results with the same echoed by the MA in its Report; Measurement Results with the same
Cycle-ID are expected to be comparable. Cycle-ID are expected to be comparable.
Data Model: The implementation of an Information Model in a Data Model: The implementation of an Information Model in a
particular data modelling language. particular data modelling language.
Derived Metric: A Metric that is a combination of other Metrics, and/ Derived Metric: A Metric that is a combination of other Metrics, and/
or a combination of the same Metric measured over different parts of or a combination of the same Metric measured over different parts of
skipping to change at page 17, line 27 skipping to change at page 17, line 47
or stopping? or stopping?
5.4. Report Protocol 5.4. Report Protocol
The primary purpose of the Report Protocol is to allow a Measurement The primary purpose of the Report Protocol is to allow a Measurement
Agent to report its Measurement Results to a Collector, and the Agent to report its Measurement Results to a Collector, and the
context in which they were obtained. context in which they were obtained.
+-----------------+ +-------------+ +-----------------+ +-------------+
| | | Measurement | | | | Measurement |
| Controller |===================================| Agent | | Collector |===================================| Agent |
+-----------------+ +-------------+ +-----------------+ +-------------+
<- Report: <- Report:
[MA-ID &/or Group-ID, [MA-ID &/or Group-ID,
Measurement Results, Measurement Results,
Measurement Task] Measurement Task]
ACK -> ACK ->
The MA acts autonomously in terms of reporting; it simply sends The MA acts autonomously in terms of reporting; it simply sends
Reports as defined by the Controller's Instruction. Reports as defined by the Controller's Instruction.
skipping to change at page 34, line 21 skipping to change at page 34, line 32
Where LMAP measurements involve devices on the Subscriber's premises Where LMAP measurements involve devices on the Subscriber's premises
or Subscriber-owned equipment, it is essential to secure the or Subscriber-owned equipment, it is essential to secure the
Subscriber's permission with regard to the specific information that Subscriber's permission with regard to the specific information that
will be collected. will be collected.
LMAP protocols, devices, and the information they store clearly need LMAP protocols, devices, and the information they store clearly need
to be secure from unauthorized access. This is the hand-off between to be secure from unauthorized access. This is the hand-off between
privacy and security considerations, found elsewhere in this memo. privacy and security considerations, found elsewhere in this memo.
8.7. The potential role of a Group-ID for privacy
A group identifier may be useful to help maintain privacy. Several
MAs would share the same Group-ID. This has been suggested where the
endusers are sensitive about privacy, for example mobile users do not
want their location tracked. Some possibilities are discussed below.
A Group-ID might be used when Results are forwarded by a Collector to
a third party. The measurement system operates using MA-IDs, however
if Results are sent to a third party then Results from several MAs
are aggregated together, in order to prevent the third party tracking
them to an individual MA or enduser.
A Group-ID could be used for Reporting. The Controller's Instruction
still refers to an MA using its MA-ID, but Results are reported to
the Collector including a Group-ID but not an MA-ID. This might be
useful where the measurement system is not run by the ISP (in the
mobile example, the user clearly wants the operator track their
location). The Group-ID needs to be sensible, for example MAs with
the same broadband product (it is not sensible to aggregate Results
from MAs on 2Mb/s and 300Mb/s lines). Note that:
o A malicious MA could bias overall results by reporting more or
less often than it is supposed to. The use of a Group-ID makes
this harder for a Collector to detect.
o An attacker is more likely to be able to break the MA-Collector
communications, since it can only be secured at the group level,
for instance with a shared password. The attacker could then
report false Results. Securing at the individual MA level
intrinsically reveals the MA's identity
o A malicious Collector can probably use other information to
deaggregate the Results per MA, for example by tracking its IP
address or analysing some per-MA 'fingerprint' information
associated with the MA-Collector transmission protocol
o A conspiratorial Controller could create a per-MA fingerprint (for
example a unique set of parameters for the Measurement Tasks or
simply a regular time at which the MA reports), which the
Collector uses to identify the MA
o A well-behaved Collector ensures that it only stores the Group-ID
and throws away per-MA information. Then it cannot subsequently
disaggregate Results per MA - such a breakdown might be requested
by a government agency, an attacker or even by the measurement
system itself (say after a change of company policy). In this
case, the MA-Collector communication can be secured per MA,
providing authentication is changed regularly and/or cannot be
linked to the repository with the Measurement Results. In
principle the scenario doesn't need a Group-ID to be defined for
the Report Protocol - since the Collector can implement the Group-
ID locally, after Results are reported.
A Group-ID could be used for Control as well as Reporting. The same
Instruction is broadcast to all MAs, which check that they have a
matching group-id before carrying out the Instruction. Notes:
o The first three bullets above still apply
o In addition, the Controller-MA communication is now also less
secure
o All the MAs with the same Group-ID probably need to be able to run
exactly the same set of Measurement Methods.
o At least at first glance, failure handling is harder. It is much
less useful for the MA to inform the Controller that it cannot
understand or execute an Instruction - the Controller simply knows
that one or more MAs, with a particular Group-ID, cannot
understand or execute the Instruction. There also seems no point
an MA reporting the Measurement Methods that it understands (which
is intended to help a Controller that has forgotten an MA's
capabilities, perhaps after a crash)
Conclusion - this topic needs more discussion. The use of per-MA
authentication for security seems in tension with the use of Group-
IDs for privacy.
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations in this memo. There are no IANA considerations in this memo.
10. Acknowledgments 10. Acknowledgments
This document is a merger of three individual drafts: draft-eardley- This document is a merger of three individual drafts: draft-eardley-
lmap-terminology-02, draft-akhter-lmap-framework-00, and draft- lmap-terminology-02, draft-akhter-lmap-framework-00, and draft-
eardley-lmap-framework-02. eardley-lmap-framework-02.
skipping to change at page 34, line 45 skipping to change at page 37, line 5
Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on Philip Eardley, Trevor Burbridge and Marcelo Bagnulo work in part on
the Leone research project, which receives funding from the European the Leone research project, which receives funding from the European
Union Seventh Framework Programme [FP7/2007-2013] under grant Union Seventh Framework Programme [FP7/2007-2013] under grant
agreement number 317647. agreement number 317647.
11. History 11. History
First WG version, copy of draft-folks-lmap-framework-00. First WG version, copy of draft-folks-lmap-framework-00.
11.1. From -00 to -01
o new sub-section of possible use of Group-IDs for privacy
o tweak to definition of Control protocol
o fix typo in figure in S5.4
12. Informative References 12. Informative References
[I-D.linsner-lmap-use-cases] [I-D.linsner-lmap-use-cases]
Linsner, M., Eardley, P., and T. Burbridge, "Large-Scale Linsner, M., Eardley, P., and T. Burbridge, "Large-Scale
Broadband Measurement Use Cases", draft-linsner-lmap-use- Broadband Measurement Use Cases", draft-linsner-lmap-use-
cases-04 (work in progress), October 2013. cases-04 (work in progress), October 2013.
[lmap-yang] [lmap-yang]
, "A YANG Data Model for LMAP Measurement Agents", , , "A YANG Data Model for LMAP Measurement Agents", ,
<http://tools.ietf.org/html/draft-schoenw-lmap-yang>. <http://tools.ietf.org/html/draft-schoenw-lmap-yang>.
 End of changes. 20 change blocks. 
25 lines changed or deleted 115 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/