draft-ietf-lmap-framework-06.txt   draft-ietf-lmap-framework-07.txt 
Network Working Group P. Eardley Network Working Group P. Eardley
Internet-Draft BT Internet-Draft BT
Intended status: Informational A. Morton Intended status: Informational A. Morton
Expires: December 15, 2014 AT&T Labs Expires: December 26, 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
June 13, 2014 June 24, 2014
A framework for large-scale measurement platforms (LMAP) A framework for large-scale measurement platforms (LMAP)
draft-ietf-lmap-framework-06 draft-ietf-lmap-framework-07
Abstract Abstract
Measuring broadband service on a large scale requires a description Measuring broadband service on a large scale requires a description
of the logical architecture and standardisation of the key protocols of the logical architecture and standardisation 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).
Status of This Memo Status of This Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 December 15, 2014. This Internet-Draft will expire on December 26, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Outline of an LMAP-based measurement system . . . . . . . . . 5 2. Outline of an LMAP-based measurement system . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Measurement system is under the direction of a single 4.1. Measurement system is under the direction of a single
organisation . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. LMAP Protocol Model . . . . . . . . . . . . . . . . . . . . . 12 5. LMAP Protocol Model . . . . . . . . . . . . . . . . . . . . . 12
5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 13 5.1. Bootstrapping process . . . . . . . . . . . . . . . . . . 13
5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 14 5.2. Control Protocol . . . . . . . . . . . . . . . . . . . . 14
5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Configuration . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Instruction . . . . . . . . . . . . . . . . . . . . . 15
5.2.3. Capabilities and Failure information . . . . . . . . 18 5.2.3. Capabilities and Failure information . . . . . . . . 18
5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 20 5.3. Operation of Measurement Tasks . . . . . . . . . . . . . 20
5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 20 5.3.1. Starting and Stopping Measurement Tasks . . . . . . . 20
5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 21 5.3.2. Overlapping Measurement Tasks . . . . . . . . . . . . 21
5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 22 5.4. Report Protocol . . . . . . . . . . . . . . . . . . . . . 22
skipping to change at page 2, line 51 skipping to change at page 2, line 51
6.1. Controller and the measurement system . . . . . . . . . . 26 6.1. Controller and the measurement system . . . . . . . . . . 26
6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 27 6.2. Measurement Agent . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Measurement Agent on a networked device . . . . . . . 27 6.2.1. Measurement Agent on a networked device . . . . . . . 27
6.2.2. Measurement Agent embedded in site gateway . . . . . 27 6.2.2. Measurement Agent embedded in site gateway . . . . . 27
6.2.3. Measurement Agent embedded behind site NAT /Firewall 28 6.2.3. Measurement Agent embedded behind site NAT /Firewall 28
6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 28 6.2.4. Multi-homed Measurement Agent . . . . . . . . . . . . 28
6.2.5. Measurement Agent embedded in ISP Network . . . . . . 29 6.2.5. Measurement Agent embedded in ISP Network . . . . . . 29
6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 29 6.3. Measurement Peer . . . . . . . . . . . . . . . . . . . . 29
7. Security considerations . . . . . . . . . . . . . . . . . . . 29 7. Security considerations . . . . . . . . . . . . . . . . . . . 29
8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 31 8. Privacy Considerations for LMAP . . . . . . . . . . . . . . . 31
8.1. Categories of Entities with Information of Interest . . . 32 8.1. Categories of Entities with Information of Interest . . . 31
8.2. Examples of Sensitive Information . . . . . . . . . . . . 33 8.2. Examples of Sensitive Information . . . . . . . . . . . . 32
8.3. Different privacy issues raised by different sorts of 8.3. Different privacy issues raised by different sorts of
Measurement Methods . . . . . . . . . . . . . . . . . . . 34 Measurement Methods . . . . . . . . . . . . . . . . . . . 33
8.4. Privacy analysis of the Communications Models . . . . . . 34 8.4. Privacy analysis of the Communications Models . . . . . . 34
8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 35 8.4.1. MA Bootstrapping . . . . . . . . . . . . . . . . . . 34
8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 35 8.4.2. Controller <-> Measurement Agent . . . . . . . . . . 35
8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 36 8.4.3. Collector <-> Measurement Agent . . . . . . . . . . . 36
8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 36 8.4.4. Measurement Peer <-> Measurement Agent . . . . . . . 36
8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 37 8.4.5. Measurement Agent . . . . . . . . . . . . . . . . . . 37
8.4.6. Storage and Reporting of Measurement Results . . . . 38 8.4.6. Storage and Reporting of Measurement Results . . . . 38
8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 38 8.5. Threats . . . . . . . . . . . . . . . . . . . . . . . . . 38
8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 39 8.5.1. Surveillance . . . . . . . . . . . . . . . . . . . . 39
8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 39 8.5.2. Stored Data Compromise . . . . . . . . . . . . . . . 39
8.5.3. Correlation and Identification . . . . . . . . . . . 40 8.5.3. Correlation and Identification . . . . . . . . . . . 40
8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 40 8.5.4. Secondary Use and Disclosure . . . . . . . . . . . . 40
skipping to change at page 3, line 33 skipping to change at page 3, line 33
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
10. Appendix: Deployment examples . . . . . . . . . . . . . . . . 44 10. Appendix: Deployment examples . . . . . . . . . . . . . . . . 44
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47
12. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
12.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 48 12.1. From -00 to -01 . . . . . . . . . . . . . . . . . . . . 48
12.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 48 12.2. From -01 to -02 . . . . . . . . . . . . . . . . . . . . 48
12.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 49 12.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . 49
12.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 50 12.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . 50
12.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 50 12.5. From -04 to -05 . . . . . . . . . . . . . . . . . . . . 50
12.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 51 12.6. From -05 to -06 . . . . . . . . . . . . . . . . . . . . 51
13. Informative References . . . . . . . . . . . . . . . . . . . 51 12.7. From -06 to -07 . . . . . . . . . . . . . . . . . . . . 51
13. Informative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53
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 boxes
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 100,000 devices. Measurement such a system could easily comprise 100,000 devices. Measurement
devices may also be embedded on a device that is part of an ISP's devices may also be embedded on a device that is part of an ISP's
network, such as a DSLAM, router, Carrier Grade NAT or ISP Gateway. network, such as a DSLAM, router, Carrier Grade NAT or ISP Gateway.
Such a scale presents unique problems in coordination, execution and Such a scale presents unique problems in coordination, execution and
measurement result collection. Several use cases have been proposed measurement result collection. Several use cases have been proposed
for large-scale measurements including: for large-scale measurements including:
o Operators: to help plan their network and identify faults o Operators: to help plan their network and identify faults
o Regulators: to benchmark several network operators and support o Regulators: to benchmark several network operators and support
public policy development public policy development
Further details of the use cases can be found in Further details of the use cases can be found in
[I-D.ietf-lmap-use-cases]. The LMAP framework should be useful for [I-D.ietf-lmap-use-cases]. The LMAP framework should be useful for
these, as well as other use cases, such as to help end users run these, as well as other use cases, such as to help end users run
diagnostic checks like a network speed test. diagnostic checks like a network speed test.
The LMAP Framework has three basic elements: Measurement Agents, The LMAP Framework has three basic elements: Measurement Agents,
Controllers and Collectors. Controllers and Collectors.
skipping to change at page 4, line 43 skipping to change at page 4, line 46
Report Protocol. Report Protocol.
The desirable features for a large-scale measurement systems we are The desirable features for a large-scale measurement systems we are
designing for are: designing for are:
o Standardised - in terms of the Measurement Tasks that they o Standardised - in terms of the Measurement Tasks that they
perform, the components, the data models and protocols for perform, the components, the data models and protocols for
transferring information between the components. Amongst other transferring information between the components. Amongst other
things, standardisation enables meaningful comparisons of things, standardisation enables meaningful comparisons of
measurements made of the same metric at different times and measurements made of the same metric at different times and
places, and provides the operator of a measurement system with a places, and provides the operator of a measurement system with
criteria for evaluation of the different solutions that can be criteria for evaluation of the different solutions that can be
used for various purposes including buying decisions (such as used for various purposes including buying decisions (such as
buying the various components from different vendors). Today's buying the various components from different vendors). Today's
systems are proprietary in some or all of these aspects. systems are proprietary in some or all of these aspects.
o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement o Large-scale - [I-D.ietf-lmap-use-cases] envisages Measurement
Agents in every home gateway and edge device such as set-top-boxes Agents in every home gateway and edge device such as set-top boxes
and tablet computers, and located throughout the Internet as well and tablet computers, and located throughout the Internet as well
[I-D.ietf-ippm-lmap-path]. It is expected that a measurement [I-D.ietf-ippm-lmap-path]. It is expected that a measurement
system could easily encompass a few hundred thousand or even system could easily encompass a few hundred thousand or even
millions of Measurement Agents. Existing systems have up to a few millions of Measurement Agents. Existing systems have up to a few
thousand MAs (without judging how much further they could scale). thousand MAs (without judging how much further they could scale).
o Diversity - a measurement system should handle different types of o Diversity - a measurement system should handle different types of
Measurement Agents - for example Measurement Agents may come from Measurement Agents - for example Measurement Agents may come from
different vendors, be in wired and wireless networks, be able to different vendors, be in wired and wireless networks, be able to
execute different sorts of Measurement Task and be on devices with execute different sorts of Measurement Task and be on devices with
IPv4 or IPv6 addresses. IPv4 or IPv6 addresses.
skipping to change at page 5, line 41 skipping to change at page 5, line 44
measure, when to measure them, how/when to report the measurement measure, when to measure them, how/when to report the measurement
results to a Collector; secondly, a Report Protocol, for a results to a Collector; secondly, a Report Protocol, for a
Measurement Agent to report the results to the Collector. Measurement Agent to report the results to the Collector.
The MA performs Measurement Tasks. The MAs are pieces of code that The MA performs Measurement Tasks. The MAs are pieces of code that
can be executed in specialised hardware (hardware probe) or on a can be executed in specialised hardware (hardware probe) or on a
general-purpose device (like a PC or mobile phone). The MA may general-purpose device (like a PC or mobile phone). The MA may
generate Measurement Traffic and measure some metric associated with generate Measurement Traffic and measure some metric associated with
its transfer, or the MA may observe existing traffic, or there may be its transfer, or the MA may observe existing traffic, or there may be
some kind of hybrid of these two possibilities. A device with a some kind of hybrid of these two possibilities. A device with a
Measurement Agent may have multiple interfaces (WiFi, Ethernet, DSL, Measurement Agent may have multiple physical interfaces (Wi-Fi,
fibre; and non-physical interfaces such as PPPoE or IPsec) and the Ethernet, DSL, fibre; and non-physical interfaces such as PPPoE or
Measurement Tasks may specify any one of these. IPsec) and the Measurement Tasks may specify any one of these.
The Controller manages a MA through use of the Control Protocol, The Controller manages a MA through use of the Control Protocol,
which transfer the Instruction to the MA. This describes the which transfers the Instruction to the MA. This describes the
Measurement Tasks the MA should perform and when. For example the Measurement Tasks the MA should perform and when. For example the
Controller may instruct a MA at a home gateway: "Count the number of Controller may instruct a MA at a home gateway: "Count the number of
TCP SYN packets observed in a 1 minute interval; repeat every hour at TCP SYN packets observed in a 1 minute interval; repeat every hour at
xx.05 + Unif[0,180] seconds". The Measurement Schedule determines xx.05 + Unif[0,180] seconds". The Measurement Schedule determines
when the Measurement Tasks are executed. The Controller also manages when the Measurement Tasks are executed. The Controller also manages
a MA by instructing it how to report the Measurement Results, for a MA by instructing it how to report the Measurement Results, for
example: "Report results once a day in a batch at 4am + Unif[0,180] example: "Report results once a day in a batch at 4am + Unif[0,180]
seconds; if the end user is active then delay the report 5 minutes". seconds; if the end user is active then delay the report 5 minutes".
The Report Schedule determines when the Reports are uploaded to the The Report Schedule determines when the Reports are uploaded to the
Collector. The Measurement Schedule and Report Schedule can define Collector. The Measurement Schedule and Report Schedule can define
skipping to change at page 9, line 22 skipping to change at page 9, line 24
Controller: A function that provides a Measurement Agent with its Controller: A function that provides a Measurement Agent with its
Instruction. Instruction.
Control Channel: a Channel between a Controller and a MA over which Control Channel: a Channel between a Controller and a MA over which
Instruction Messages and Capabilities, Failure and Logging Instruction Messages and Capabilities, Failure and Logging
Information are sent. Information are sent.
Control Protocol: The protocol delivering Instruction(s) from a Control Protocol: The protocol delivering Instruction(s) from a
Controller to a Measurement Agent. It also delivers Capabilities, Controller to a Measurement Agent. It also delivers Capabilities,
Failure and Logging Information from the Measurement Agent to the Failure and Logging Information from the Measurement Agent to the
Controller. Controller. It can also be used to update the MA's configuration.
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. The same Cycle-ID is used by several echoed by the MA in its Report. The same Cycle-ID is used by several
MAs that use the same Measurement Method for a Metric with the same MAs that use the same Measurement Method for a Metric with the same
Input Parameters. Hence the Cycle-ID allows the Collector to easily Input Parameters. Hence the Cycle-ID allows the Collector to easily
identify Measurement Results that should be comparable. identify Measurement Results that should 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 [RFC3444]. particular data modelling language [RFC3444].
skipping to change at page 13, line 33 skipping to change at page 13, line 41
Whilst this memo considers the bootstrapping process, it is beyond Whilst this memo considers the bootstrapping process, it is beyond
the scope of initial LMAP work to define a bootstrap mechanism, as it the scope of initial LMAP work to define a bootstrap mechanism, as it
depends on the type of device and access. depends on the type of device and access.
As a result of the bootstrapping process the MA learns information As a result of the bootstrapping process the MA learns information
with the following aims ([I-D.ietf-lmap-information-model] defines with the following aims ([I-D.ietf-lmap-information-model] defines
the consequent list of information elements): the consequent list of information elements):
o its identifier, either its MA-ID or a device identifier such as o its identifier, either its MA-ID or a device identifier such as
its MAC its MAC or both.
o (optionally) a Group-ID. A Group-ID would be shared by several o (optionally) a Group-ID. A Group-ID would be shared by several
MAs and could be useful for privacy reasons. For instance, MAs and could be useful for privacy reasons. For instance,
reporting the Group-ID and not the MA-ID could hinder tracking of reporting the Group-ID and not the MA-ID could hinder tracking of
a mobile device a mobile device
o the Control Channel, which is defined by: o the Control Channel, which is defined by:
* the address which identifies the Control Channel, such as the * the address which identifies the Control Channel, such as the
Controller's FQDN (Fully Qualified Domain Name) [RFC1035]) Controller's FQDN (Fully Qualified Domain Name) [RFC1035])
skipping to change at page 15, line 48 skipping to change at page 16, line 14
locally by the operator of the measurement system or perhaps by locally by the operator of the measurement system or perhaps by
another standards organisation. another standards organisation.
* the Measurement Method role. For some Measurement Methods, * the Measurement Method role. For some Measurement Methods,
different parties play different roles; for example (figure A3 different parties play different roles; for example (figure A3
in the Appendix) an iperf sender and receiver. Each Metric and in the Appendix) an iperf sender and receiver. Each Metric and
its associated Measurement Method will describe all measurement its associated Measurement Method will describe all measurement
roles involved in the process. Thus, the Measurement Method roles involved in the process. Thus, the Measurement Method
role is an Input Parameter. role is an Input Parameter.
* a boolean flag (supppress or do-not-suppress) indicating how * a boolean flag (suppress or do-not-suppress) indicating how
such a Measurement Task is impacted by a Suppression message such a Measurement Task is impacted by a Suppression message
(see Section 5.2.2.1). Thus, the flag is an Input Parameter. (see Section 5.2.2.1). Thus, the flag is an Input Parameter.
* any Input Parameters that need to be set for the Metric and the * any Input Parameters that need to be set for the Metric and the
Measurement Method, such as the address of a Measurement Peer Measurement Method, such as the address of a Measurement Peer
(or other Measurement Agent) that may be involved in a (or other Measurement Agent) that may be involved in a
Measurement Task, and for the measurement protocol used, such Measurement Task, and for the measurement protocol used, such
as protocol role(s). as protocol role(s).
* if the device with the MA has multiple interfaces, then the * if the device with the MA has multiple interfaces, then the
skipping to change at page 17, line 24 skipping to change at page 17, line 38
fields: fields:
o a set of Measurement Tasks to suppress; the others are not o a set of Measurement Tasks to suppress; the others are not
suppressed. For example, this could be useful if a particular suppressed. For example, this could be useful if a particular
Measurement Task is overloading a Measurement Peer. Measurement Task is overloading a Measurement Peer.
o a set of Measurement Schedules to suppress; the others are not o a set of Measurement Schedules to suppress; the others are not
suppressed. For example, suppose the measurement system has suppressed. For example, suppose the measurement system has
defined two Schedules, one with the most critical Measurement defined two Schedules, one with the most critical Measurement
Tasks and the other with less critical ones that create a lot of Tasks and the other with less critical ones that create a lot of
Active Measurement Traffic, then it may only want to suppress the Measurement Traffic, then it may only want to suppress the second.
second.
o if the Suppression information includes neither a set of o if the Suppression information includes neither a set of
Measurement Tasks nor a set of Measurement Schedules, then the MA Measurement Tasks nor a set of Measurement Schedules, then the MA
does not begin new Measurement Tasks that have the boolean flag does not begin new Measurement Tasks that have the boolean flag
set to "suppress"; however, the MA does begin new Measurement set to "suppress"; however, the MA does begin new Measurement
Tasks that have the flag set to "do-not-suppress". Tasks that have the flag set to "do-not-suppress".
o a start time, at which suppression begins. If absent, then o a start time, at which suppression begins. If absent, then
Suppression begins immediately. Suppression begins immediately.
o an end time, at which suppression ends. If absent, then o an end time, at which suppression ends. If absent, then
Suppression continues until the MA receives an un-Suppress Suppression continues until the MA receives an un-Suppress
message. message.
o a demand that the MA ends its on-going Active Measurement Task(s) o a demand that the MA immediately ends on-going Measurement Task(s)
immediately (and deletes the associated partial Measurement that are tagged for suppression (and deletes the associated
Result(s)). If absent, the MA completes on-going Measurement partial Measurement Result(s)). This could be useful in the case
Tasks. of a network emergency so that the operator can eliminate all
inessential traffic as rapidly as possible. If absent, the MA
completes on-going Measurement Tasks.
So the default action (if none of the optional fields is set) is that So the default action (if none of the optional fields is set) is that
the MA does not begin any new Measurement Task with the "suppress" the MA does not begin any new Measurement Task with the "suppress"
flag. flag.
An un-Suppress message instructs the MA no longer to suppress, An un-Suppress message instructs the MA no longer to suppress,
meaning that the MA once again begins new Measurement Tasks, meaning that the MA once again begins new Measurement Tasks,
according to its Measurement Schedule. according to its Measurement Schedule.
Note that Suppression is not intended to permanently stop a Note that Suppression is not intended to permanently stop a
skipping to change at page 18, line 18 skipping to change at page 18, line 33
kind of management action is suggested). kind of management action is suggested).
+-----------------+ +-------------+ +-----------------+ +-------------+
| | | Measurement | | | | Measurement |
| Controller |===================================| Agent | | Controller |===================================| Agent |
+-----------------+ +-------------+ +-----------------+ +-------------+
Suppress: Suppress:
[(Measurement Task), -> [(Measurement Task), ->
(Measurement Schedule), (Measurement Schedule),
start time, [start time],
end time, [end time],
on-going suppressed?] [on-going suppressed?]]
Un-suppress -> Un-suppress ->
5.2.3. Capabilities and Failure information 5.2.3. Capabilities and Failure information
The Control Protocol also enables the MA to inform the Controller The Control Protocol also enables the MA to inform the Controller
about various information, such as its Capabilities and any Failures. about various information, such as its Capabilities and any Failures.
It is also possible to use a device-specific mechanism which is It is also possible to use a device-specific mechanism which is
beyond the scope of the initial LMAP work. beyond the scope of the initial LMAP work.
skipping to change at page 23, line 35 skipping to change at page 23, line 35
parameter database to the data analysis tools. It may also be parameter database to the data analysis tools. It may also be
possible to transfer the information via the MA. How (and if) the MA possible to transfer the information via the MA. How (and if) the MA
knows such information is likely to depend on the device type. The knows such information is likely to depend on the device type. The
MA could either include the information in a Measurement Report or MA could either include the information in a Measurement Report or
separately. separately.
5.5. Operation of LMAP over the underlying packet transfer mechanism 5.5. Operation of LMAP over the underlying packet transfer mechanism
The above sections have described LMAP's protocol model. Other The above sections have described LMAP's protocol model. Other
specifications will define the actual Control and Report Protocols, specifications will define the actual Control and Report Protocols,
possibly operating over an existing protocol, to be selected, for possibly operating over an existing protocol, such as REST-style
example REST-style HTTP(S). It is also possible that a different HTTP(S). It is also possible that a different choice is made for the
choice is made for the Control and Report Protocols, for example Control and Report Protocols, for example NETCONF-YANG and IPFIX
NETCONF-YANG and IPFIX respectively. respectively.
From an LMAP perspective, the Controller needs to know that the MA From an LMAP perspective, the Controller needs to know that the MA
has received the Instruction Message, or at least that it needs to be has received the Instruction Message, or at least that it needs to be
re-sent as it may have failed to be delivered. Similarly the MA re-sent as it may have failed to be delivered. Similarly the MA
needs to know about the delivery of Capabilities and Failure needs to know about the delivery of Capabilities and Failure
information to the Controller and Reports to the Collector. How this information to the Controller and Reports to the Collector. How this
is done depends on the design of the Control and Report Protocols and is done depends on the design of the Control and Report Protocols and
the underlying packet transfer mechanism. the underlying packet transfer mechanism.
For the Control Protocol, the underlying packet transfer mechanism For the Control Protocol, the underlying packet transfer mechanism
skipping to change at page 25, line 42 skipping to change at page 25, line 42
This framework concentrates on the cases where an ISP or a regulator This framework concentrates on the cases where an ISP or a regulator
runs the measurement system. However, we expect that LMAP runs the measurement system. However, we expect that LMAP
functionality will also be used in the context of an end-user- functionality will also be used in the context of an end-user-
controlled measurement system. There are at least two ways this controlled measurement system. There are at least two ways this
could happen (they have various pros and cons): could happen (they have various pros and cons):
1. an end-user could somehow request the ISP- (or regulator-) run 1. an end-user could somehow request the ISP- (or regulator-) run
measurement system to test his/her line. The ISP (or regulator) measurement system to test his/her line. The ISP (or regulator)
Controller would then send an Instruction to the MA in the usual Controller would then send an Instruction to the MA in the usual
LMAP way. Note that a user can't directly initiate a Measurement LMAP way.
Task on an ISP- (or regulator-) controlled MA.
2. an end-user could deploy their own measurement system, with their 2. an end-user could deploy their own measurement system, with their
own MA, Controller and Collector. For example, the user could own MA, Controller and Collector. For example, the user could
implement all three functions onto the same end-user-owned end implement all three functions onto the same end-user-owned end
device, perhaps by downloading the functions from the ISP or device, perhaps by downloading the functions from the ISP or
regulator. Then the LMAP Control and Report Protocols do not regulator. Then the LMAP Control and Report Protocols do not
need to be used, but using LMAP's Information Model would still need to be used, but using LMAP's Information Model would still
be beneficial. The Measurement Peer (or other MA involved in the be beneficial. The Measurement Peer (or other MA involved in the
Measurement Task) could be in the home gateway or outside the Measurement Task) could be in the home gateway or outside the
home network; in the latter case the Measurement Peer is highly home network; in the latter case the Measurement Peer is highly
skipping to change at page 26, line 29 skipping to change at page 26, line 28
The Appendix has some examples of possible deployment arrangements of The Appendix has some examples of possible deployment arrangements of
Measurement Agents and Peers. Measurement Agents and Peers.
6.1. Controller and the measurement system 6.1. Controller and the measurement system
The Controller should understand both the MA's LMAP Capabilities (for The Controller should understand both the MA's LMAP Capabilities (for
instance what Metrics and Measurement Methods it can perform) and instance what Metrics and Measurement Methods it can perform) and
about the MA's other capabilities like processing power and memory. about the MA's other capabilities like processing power and memory.
This allows the Controller to make sure that the Measurement Schedule This allows the Controller to make sure that the Measurement Schedule
of Measurement Tasks and the Reporting Schedule are sensible for each of Measurement Tasks and the Reporting Schedule are sensible for each
MA that it Instructs. MA that it instructs.
An Instruction is likely to include several Measurement Tasks. An Instruction is likely to include several Measurement Tasks.
Typically these run at different times, but it is also possible for Typically these run at different times, but it is also possible for
them to run at the same time. Some Tasks may be compatible, in that them to run at the same time. Some Tasks may be compatible, in that
they do not affect each other's Results, whilst with others great they do not affect each other's Results, whilst with others great
care would need to be taken. care would need to be taken.
The Controller should ensure that the Measurement Tasks do not have The Controller should ensure that the Measurement Tasks do not have
an adverse effect on the end user. Tasks, especially those that an adverse effect on the end user. Tasks, especially those that
generate a substantial amount of traffic, will often include a pre- generate a substantial amount of traffic, will often include a pre-
skipping to change at page 28, line 20 skipping to change at page 28, line 17
a site gateway (whether end-user service-provider owned) will a site gateway (whether end-user service-provider owned) will
generally not be directly available for over the top providers, the generally not be directly available for over the top providers, the
regulator, end users or enterprises. regulator, end users or enterprises.
6.2.3. Measurement Agent embedded behind site NAT /Firewall 6.2.3. Measurement Agent embedded behind site NAT /Firewall
The Measurement Agent could also be embedded behind a NAT, a The Measurement Agent could also be embedded behind a NAT, a
firewall, or both. In this case the Controller may not be able to firewall, or both. In this case the Controller may not be able to
unilaterally contact the Measurement Agent unless either static port unilaterally contact the Measurement Agent unless either static port
forwarding or firewall pin holing is configured. Configuring port forwarding or firewall pin holing is configured. Configuring port
forwarding could use protocols such as PCP [RFC6887], TR-069 forwarding could use protocols such as PCP [RFC6887], TR-069 [TR-069]
[TR-069]or UPnP [UPnP]. To prop open the firewall, the Measurement or UPnP [UPnP]. To prop open the firewall, the Measurement Agent
Agent could send keepalives towards the Controller (and perhaps use could send keepalives towards the Controller (and perhaps use these
these also as a network reachability test). also as a network reachability test).
6.2.4. Multi-homed Measurement Agent 6.2.4. Multi-homed Measurement Agent
If the device with the Measurement Agent is single homed then there If the device with the Measurement Agent is single homed then there
is no confusion about what interface to measure. Similarly, if the is no confusion about what interface to measure. Similarly, if the
MA is at the gateway and the gateway only has a single WAN-side and a MA is at the gateway and the gateway only has a single WAN-side and a
single LAN-side interface, there is little confusion - for single LAN-side interface, there is little confusion - for
Measurement Methods that generate Measurement Traffic, the location Measurement Methods that generate Measurement Traffic, the location
of the other MA or Measurement Peer determines whether the WAN or LAN of the other MA or Measurement Peer determines whether the WAN or LAN
is measured. is measured.
skipping to change at page 30, line 7 skipping to change at page 30, line 5
7. Security considerations 7. Security considerations
The security of the LMAP framework should protect the interests of The security of the LMAP framework should protect the interests of
the measurement operator(s), the network user(s) and other actors who the measurement operator(s), the network user(s) and other actors who
could be impacted by a compromised measurement deployment. The could be impacted by a compromised measurement deployment. The
measurement system must secure the various components of the system measurement system must secure the various components of the system
from unauthorised access or corruption. Much of the general advice from unauthorised access or corruption. Much of the general advice
contained in section 6 of [RFC4656] is applicable here. contained in section 6 of [RFC4656] is applicable here.
The process to upgrade the firmware in an MA is outside the scope of
the initial LMAP work, similar to the protocol to bootstrap the MAs
(as specified in the charter). However, systems which provide remote
upgrade must secure authorised access and integrity of the process.
We assume that each Measurement Agent (MA) will receive its We assume that each Measurement Agent (MA) will receive its
Instructions from a single organisation, which operates the Instructions from a single organisation, which operates the
Controller. These Instructions must be authenticated (to ensure that Controller. These Instructions must be authenticated (to ensure that
they come from the trusted Controller), checked for integrity (to they come from the trusted Controller), checked for integrity (to
ensure no-one has tampered with them) and not vulnerable to replay ensure no-one has tampered with them) and not vulnerable to replay
attacks. If a malicious party can gain control of the MA they can attacks. If a malicious party can gain control of the MA they can
use it to launch DoS attacks at targets, reduce the end user's use it to launch DoS attacks at targets, reduce the end user's
quality of experience and corrupt the Measurement Results that are quality of experience and corrupt the Measurement Results that are
reported to the Collector. By altering the Measurement Tasks and/or reported to the Collector. By altering the Measurement Tasks and/or
the address that Results are reported to, they can also compromise the address that Results are reported to, they can also compromise
the confidentiality of the network user and the MA environment (such the confidentiality of the network user and the MA environment (such
as information about the location of devices or their traffic). The as information about the location of devices or their traffic). The
Instruction messages also need to be encrypted to maintain Instruction messages also need to be encrypted to maintain
confidentiality, as the information might be useful to an attacker. confidentiality, as the information might be useful to an attacker.
The process to upgrade the firmware in an MA is outside the scope of In some circumstances (if the MA is behind a NAT for instance), the
the initial LMAP work, similar to the protocol to bootstrap the MAs Controller cannot contact the MA directly an so the MA must contact
(as specified in the charter). However, systems which provide remote the Controller (the "pull" model). The Controller should ensure that
upgrade must secure authorised access and integrity of the process. its resources cannot be exhausted by a malicious party pretending to
be a MA. For example, the Controller could limit the rate of "pull"
Reporting by the MA must also be secured to maintain confidentiality. requests from a single MA.
The results must be encrypted such that only the authorised Collector
can decrypt the results to prevent the leakage of confidential or
private information. In addition it must be authenticated that the
results have come from the expected MA and that they have not been
tampered with. It must not be possible to fool a MA into injecting
falsified data into the measurement platform or to corrupt the
results of a real MA. The results must also be held and processed
securely after collection and analysis.
Reporting by the MA must be encrypted to maintain confidentiality, to Reporting by the MA must be encrypted to maintain confidentiality, so
that only the authorised Collector can decrypt the results, to
prevent the leakage of confidential or private information. prevent the leakage of confidential or private information.
Reporting must also be authenticated (to ensure that it comes from a Reporting must also be authenticated (to ensure that it comes from a
trusted MA) and not vulnerable to tampering (which can be ensured trusted MA) and not vulnerable to tampering (which can be ensured
through integrity and replay checks). It must not be possible to through integrity and replay checks). It must not be possible to
fool a MA into injecting falsified data and the results must also be fool a MA into injecting falsified data and the results must also be
held and processed securely after collection and analysis See section held and processed securely after collection and analysis. See
8.5.2 below for additional considerations on stored data compromise, section 8.5.2 below for additional considerations on stored data
and section 8.6 on potential mitigations for compromise. compromise, and section 8.6 on potential mitigations for compromise.
Since Collectors will be contacted repeatedly by MAs using the Since Collectors will be contacted repeatedly by MAs using the
Collection Protocol to convey their recent results, a successful Collection Protocol to convey their recent results, a successful
attack to exhaust the communication resources would prevent a attack to exhaust the communication resources would prevent a
critical operation: reporting. Therefore, all LMAP Collectors should critical operation: reporting. Therefore, all LMAP Collectors should
implement technical mechanisms to: implement technical mechanisms to:
o limit the number of reporting connections from a single MA o limit the number of reporting connections from a single MA
(simultaneous, and connections per unit time). (simultaneous, and connections per unit time).
o limit the transmission rate from a single MA. o limit the transmission rate from a single MA.
o limit the memory/storage consumed by a single MA's reports. o limit the memory/storage consumed by a single MA's reports.
o efficiently reject reporting connections from unknown sources. o efficiently reject reporting connections from unknown sources.
o separate resources if multiple authentication strengths are used, o separate resources if multiple authentication strengths are used,
where the resources should be separated according to each class of where the resources should be separated according to each class of
strength. strength.
o limit iteration counters to generate keys with both a lower and
upper limit, to prevent an attacking system from requesting the
maximum and causing the Controller to stall on the process (see
section 6 of [RFC5357]).
Many of the above considerations are applicable to a "pull" model,
where the MA must contact the Controller because NAT or other network
aspect prevents Controllers from contacting MAs directly.
Availability should also be considered. While the loss of some MAs
may not be considered critical, the unavailability of the Collector
could mean that valuable business data or data critical to a
regulatory process is lost. Similarly, the unavailability of a
Controller could mean that the MAs do not operate a correct
Measurement Schedule.
The security mechanisms described above may not be strictly necessary The security mechanisms described above may not be strictly necessary
if the network's design ensures the LMAP components and their if the network's design ensures the LMAP components and their
communications are already secured, for example potentially if they communications are already secured, for example potentially if they
are all part of an ISP's dedicated management network. are all part of an ISP's dedicated management network.
Finally, there are three other issues related to security: privacy
(considered in Section 8 below), availability and 'gaming the
system'. While the loss of some MAs may not be considered critical,
the unavailability of the Collector could mean that valuable business
data or data critical to a regulatory process is lost. Similarly,
the unavailability of a Controller could mean that the MAs do not
operate a correct Measurement Schedule.
A malicious party could "game the system". For example, where a A malicious party could "game the system". For example, where a
regulator is running a measurement system in order to benchmark regulator is running a measurement system in order to benchmark
operators, an operator could try to identify the broadband lines that operators, an operator could try to identify the broadband lines that
the regulator was measuring and prioritise that traffic. Normally, the regulator was measuring and prioritise that traffic. Normally,
this potential issue is handled by a code of conduct. It is outside this potential issue is handled by a code of conduct. It is outside
the scope of the initial LMAP work to consider the issue. the scope of the initial LMAP work to consider the issue.
8. Privacy Considerations for LMAP 8. Privacy Considerations for LMAP
The LMAP work considers privacy as a core requirement and will ensure The LMAP work considers privacy as a core requirement and will ensure
skipping to change at page 47, line 39 skipping to change at page 47, line 39
usually it is not particularly useful to highlight it as a MP. usually it is not particularly useful to highlight it as a MP.
11. Acknowledgments 11. 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.
Thanks to Juergen Schoenwaelder for his detailed review of the Thanks to Juergen Schoenwaelder for his detailed review of the
terminology. Thanks to Charles Cook for a very detailed review of terminology. Thanks to Charles Cook for a very detailed review of
-02. -02. Thanks to Barbara Stark and Ken Ko for many helpful comments
about later versions.
Thanks to numerous people for much discussion, directly and on the Thanks to numerous people for much discussion, directly and on the
LMAP list (apologies to those unintentionally omitted): Alan Clark, LMAP list (apologies to those unintentionally omitted): Alan Clark,
Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian Alissa Cooper, Andrea Soppera, Barbara Stark, Benoit Claise, Brian
Trammell, Charles Cook, Dave Thorne, Frode Soerensen, Greg Mirsky, Trammell, Charles Cook, Dave Thorne, Frode Soerensen, Greg Mirsky,
Guangqing Deng, Jason Weil, Jean-Francois Tremblay, Jerome Benoit, Guangqing Deng, Jason Weil, Jean-Francois Tremblay, Jerome Benoit,
Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, Ken Ko, Lingli Joachim Fabini, Juergen Schoenwaelder, Jukka Manner, Ken Ko, Lingli
Deng, Michael Bugenhagen, Rolf Winter, Sam Crawford, Sharam Hakimi, Deng, Mach Chen, Marc Ibrahim, Michael Bugenhagen, Michael Faath,
Steve Miller, Ted Lemon, Timothy Carey, Vaibhav Bajpai, William Nalini Elkins, Rolf Winter, Sam Crawford, Sharam Hakimi, Steve
Miller, Ted Lemon, Timothy Carey, Vaibhav Bajpai, Vero Zheng, William
Lupton. Lupton.
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.
12. History 12. History
First WG version, copy of draft-folks-lmap-framework-00. First WG version, copy of draft-folks-lmap-framework-00.
skipping to change at page 51, line 41 skipping to change at page 51, line 41
o Suppression: there is now the concept of a flag (boolean) which o Suppression: there is now the concept of a flag (boolean) which
indicates whether a Task is by default gets suppressed or not. indicates whether a Task is by default gets suppressed or not.
The optional suppression message (with list of specific tasks The optional suppression message (with list of specific tasks
/schedules to suppress) over-rides this flag. /schedules to suppress) over-rides this flag.
o The previous bullet also means there is no need to make a o The previous bullet also means there is no need to make a
distinction between active and passive Measurement Tasks, so this distinction between active and passive Measurement Tasks, so this
distinction is removed. distinction is removed.
o removed distinction o removed Configuration Protocol - Configuration is part of the
Instruction and so uses the Control Protocol.
o added a Configuration Protocol - allows the Controller to update 12.7. From -06 to -07
the MA about information that it obtained during the bootstrapping
process (for consistency with Information Model) o Clarifications and nits
13. Informative References 13. Informative References
[Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi, [Bur10] Burkhart, M., Schatzmann, D., Trammell, B., and E. Boschi,
"The Role of Network Trace anonymisation Under Attack", "The Role of Network Trace anonymisation Under Attack",
January 2010. January 2010.
[TR-069] TR-069, , "CPE WAN Management Protocol", [TR-069] TR-069, , "CPE WAN Management Protocol",
http://www.broadband-forum.org/technical/trlist.php, http://www.broadband-forum.org/technical/trlist.php,
November 2013. November 2013.
skipping to change at page 53, line 13 skipping to change at page 53, line 22
Support", RFC 6235, May 2011. Support", RFC 6235, May 2011.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, July Considerations for Internet Protocols", RFC 6973, July
2013. 2013.
[I-D.ietf-ippm-lmap-path] [I-D.ietf-ippm-lmap-path]
Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and Bagnulo, M., Burbridge, T., Crawford, S., Eardley, P., and
A. Morton, "A Reference Path and Measurement Points for A. Morton, "A Reference Path and Measurement Points for
LMAP", draft-ietf-ippm-lmap-path-03 (work in progress), LMAP", draft-ietf-ippm-lmap-path-04 (work in progress),
May 2014. June 2014.
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M.
Zekauskas, "A One-way Active Measurement Protocol Zekauskas, "A One-way Active Measurement Protocol
(OWAMP)", RFC 4656, September 2006. (OWAMP)", RFC 4656, September 2006.
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J.
Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
RFC 5357, October 2008. RFC 5357, October 2008.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
 End of changes. 37 change blocks. 
85 lines changed or deleted 79 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/