1. Thoughts on the LMAP protocol(s) LMAP Interim meeting, Dublin, 15 th September 2014 Philip Eardley Al Morton Jason Weil 1

2. Summary Slides pick out various protocol-affecting stuff from the Charter & Framework And make various proposals for the protocol work (in order to speed it up etc) 2

3. Charter work items 4. The Control protocol and the associated data model: The definition of how instructions are delivered from a Controller to a MA; this includes a Data Model consistent with the Information Model plus a transport protocol. This may be a simple instruction - response protocol, and LMAP will specify how it operates over an existing protocol (to be selected, perhaps REST-style HTTP(s) or NETCONF). 5. The Report protocol and the associated data model: The definition of how the Report is delivered from a MA to a Collector; this includes a Data Model consistent with the Information Model plus a transport protocol (to be selected, perhaps REST-style HTTP(s) or IPFIX). Milestone date: Dec 2014 3

4. Comments on Charter Proposal – Select /extend a single control protocol and a single report protocol If required, WG can extend another protocol after initial work. Other standards bodies may also. – Long run: Different devices may have such different requirements that a different protocol selection is appropriate. May select same or different protocol for Control and Reporting 4

5. Framework constraint #1 (S4.1) Measurement system under the direction of a single organisation – However, the components of an LMAP measurement system can be deployed in administrative domains not owned by the measuring organisation Suggests security requirements – Anti eavesdropping, tampering, injection, replay… – Avoid exhaustion of MA /Controller /Collector resources – Avoid use as a platform for DoS attacks Proposal – Protocol selected must use mutual authentication and encryption This seems to solve the security requirements – Key Management system must be efficient at Large Scale (like everything else) – Protocol selected must already be battle hardened – we will reuse its existing mechanisms (no work on extending security) To speed up the work 5

6. Framework constraint #2 (S4.1) Each MA may only have a single Controller at any point in time – The framework does mention that the MA might change its Controller Proposal – Control Protocol does not need to provide a mechanism for the Controller to inform the MA about a change of Controller Seems a secondary requirement May raise new security issues? MA cannot detect attacker’s Controller if communication uses valid credentials 6

7. Privacy considerations (S8) Primarily influence on the Reporting Protocol – Again must be efficient at large scale Proposals for MA Reporting Protocol OPTIONS: – Minimise Sensitive Information (personal data) reported with Results (including IP Addresses, Service Plan Details, Account #) – Facilitate formation of anonymity sets through use of pseudonyms, such as MA Group-ID instead of MA-ID, and Measurement Point designations instead of IP Addresses Proposals for Control and Reporting – Payload Encryption Required But don’t assume that encryption solves all privacy issues – Sensitive data (including MA-ID) must not be in the header 7

8. Bootstrapping process (S5.1) Process that integrates the MA into the measurement system – – phase before the MA can get an Instruction – Tells MA its identifier, (optionally Group-ID), Control Channel Control Channel is identified by FQDN &/or IP address, plus interface if not default and security credentials – Process “depends on the type of device and access” – Control Protocol should allow varying bootstrapping mechanisms – Charter defines as out of scope Proposal – Control protocol does not need to provide a bootstrapping mechanism – Assume, for the sake of argument, manual configuration – Assume that MA learns its MA-ID as part of bootstrapping 8

9. Operation of LMAP over the underlying packet transfer mechanism (S5.5) Need to know messages have been received or need to be re-sent Cannot assume transport protocol provides reliable delivery For Control Protocol, underlying packet transfer mechanism could be – Push ; Multicast ; Pull ; Hybrid Proposal – For Control Protocol, assume pull: MA initiates comms with Controller Since main case is MA behind a NAT-firewall, and this is the simplest solution As soon as bootstrapped, MA does pull from Controller Control Protocol must allow a response “continue with Instruction – no changes Control Protocol may configure MA with how often to check in with Controller & say what to do if Controller unreachable after X attempts – Also acts as an aliveness check – Assume these parameters are set by the bootstrapping process? 9

10. Control Protocol (S5.3) Control protocol has several jobs: – Configure MA with MA-ID, Group-ID, control channel – Send Instruction with (all/subset of): Measurement Task configuration (which has URI, role, Input Parameters etc); report channel; measurement schedule; report schedule; suppression information; other tasks (eg data processing) & their schedule – Request MA to send (all/some of) capabilities, failure & logging information (CFLI) Assume Controller understands what MA tells it about MA’s capabilities (or simply ignores what it doesn’t understand) – MA sends (all/some of) CFLI (in response to request or on its own initiative) 10

11. Control Protocol (S5.3) Proposal – Control protocol does not handle configuration (leave to bootstrapping process) (for now) – Control protocol must be able to transfer to MA all of items listed in Information Model, or an arbitrary subset – Control protocol must be able to transfer to MA in a single message everything from a reasonably complex Instruction to a simple one (Schedule with a single Measurement Task) – Control protocol may use separate messages for Instruction and request to send CFLI – Control protocol must handle message being lost & so to be re-sent (eg ack) – Control protocol must handle message & its duplicate both being received (ie not left to MA’s database later to de-duplicate) – Control protocol must handle update of some of Instruction, with reasonable certainty that Controller & MA have same opinion of what the Instruction is ? Solved by reliability of protocol ? Instruction-checksum ? Controller can request MA to send Instr – Out of scope: delivery of suppression message before the MA does its next regular pull 11

12. Operation of LMAP over the underlying packet transfer mechanism (S5.5) Need to know messages have been received or need to be re- sent For Report Protocol, underlying packet transfer mechanism could be – Push ; Perhaps supplemented by pull Proposal – assume push: MA pushes report to Collector Report Protocol does not include facility for Collector to pull results from MA 12

13. Report protocol (S5.4) Report may contain (all/subset of): – measurement results; details of measurement tasks; MA-ID &/or Group-ID; cycle-ID; subscriber’s service parameters; measurement point designation Instruction may tell the MA to report (same /different) results to several collectors Proposal – Report protocol must be able to transfer to the Collector all of items listed in Information Model, or an arbitrary subset – Report protocol must be able to transfer to the Collector in a single message, from a single Measurement Result up to a reasonably large number of Results – Report protocol must handle message being lost & so to be re-sent (eg ack) – Report protocol must handle message & its duplicate both being received (ie not left to Collector’s database later to de-duplicate) – Report channel is identified by FQDN &/or IP address, plus interface if not default (and security credentials) ?handling change of default interface? – If there’s another collector, run separate instance of report protocol 13