Re: [Ace] Next step for use case document

[Göran Selander <[e-mail]>]

Dear WG chairs and all,


Please find below some further suggestions for content of the use case
document. Apologies for the lengthy mail.


I propose that some use case in the draft should highlight the need for a
solution that supports secure store and forward. Here are a set of use
cases supporting this, the first one is based on interviews with people
working with utilities. The others use cases show that this is not an
isolated example. (There is no need to include all use cases in the draft.)



Utility data collection
- - -
A utility company is updating its old utility distribution network with
advanced meters and new communication systems, known as an Advanced
Metering Infrastructure (AMI).  AMI refers to a system that measures,
collects and analyzes usage, and interacts with metering devices such as
electricity meters, gas meters, heat meters, and water meters, through
various communication media either on request (on-demand) or on
pre-defined schedules.  Based on this technology, new services make it
possible for consumers to control their utility consumption and reduce
costs by supporting new tariff models from utility companies, and more
accurate and timely billing.

The technical solution is based on levels of data aggregation between
³smart meters² located at the consumer premises and the Meter Data
Management (MDM) system located at the utility company.  Two possible
intermediate levels are:

- Head-End System (HES) which is hardware and software that receives the
stream of meter data and exposes an interface to the MDM.

- Data Collection (DC) units located in a local network communicating with
a number of smart meters and with a backhaul interface communicating with
the HES, e.g. using cellular communication.

For reasons of efficiency and cost end-to-end connectivity is not always
feasible, so metering data is stored in batches in DC for some time before
being forwarded to the HES, and in turn accessed by the MDM.  The HES and
the DC units may be operated by a third party service operator on behalf
of the utility company.  One responsibility of the service operator is to
make sure that meter readings are performed and delivered to the HES.  An
example of a Service Level Agreement between the service operator and the
utility company is e.g.  "at least 95 % of the meters have readings
recorded during the last 72 hours².


Security properties

The utility company wants to verify stored and forwarded metering data
with respect to authenticity, integrity and replay.

The utility company wants to configure utility meters securely: The
devices should be able to verify that a configuration request is
authorized, authentic, integrity and replay protected.

The utility company wants to be in control of access to plain text
metering data. Other parties may be allowed access but at the discretion
of the utility company. E.g. the service operator needs access during test
or error cases, or for calibrating units on replacement. In particular, it
should be possible to confidentiality protect the metering data between
smart meter and the utility company's network.

(There are also other desirable security properties, the ambition here is
not to be exhaustive but to highlight the need for end-to-end authorised
access. )



Actually, the drive-by metering use case (section 2.5.1) may require a
similar functionality:


Drive-by metering data collection
- - -
The meters communicate with a vehicle-attached base station, which drives
by and collects meter readings. The drive-by service could potentially be
operated by a third party collecting meter readings on behalf of one or
multiple utility companies, and should not have access to plain text meter
readings, or not be able to change the readings. Also in this case it may
be cost-efficient to upload the readings from the vehicle once the car
returns to the 3rd party premises, e.g. over WLAN. This means that the
readings need to be stored and later forwarded, and should be protected
end-to-end between smart meter and Meter-Data Management system in the
respective utility company network analogously to the previous use case.


There are other examples where it may be impossible or infeasible to
support end-to-end connectivity, e.g. in networks with sleepy devices, in
which case a publish-subscribe paradigm may be more natural.  Here we pick
another application of publish-subscribe:

Information Centric Networking (ICN)
- - -
ICN is a paradigm for data access, changing focus from current
host-centric network to an information-centric network.  In a host-centric
network, the basic idea is to create secure connections to hosts of
trusted providers of data.  In an information-centric network, on the
other hand, it is acceptable that any source (cache) should be equally
usable.  This requires some mechanism for making each information item
trustworthy by itself, which can be achieved for example by signing data.
In this case a consumer of an information object could prove its
authenticity by verifying the digital signature.  Applying ICN to the IoT
setting, sensor readings could be protected and stored in arbitrary
content nodes, not necessarily only in origin servers; device
configuration updates could be protected and stored in proxies, not
necessarily only in dedicated configuration servers.

Similar security properties apply as in the previous cases.



Göran



From:  Likepeng <[e-mail]>
Date:  Wednesday 24 September 2014 09:06
To:  "[e-mail]" <[e-mail]>
Subject:  [Ace] Next step for use case document


>Thanks all for the feedbacks to the use case document:
>http://datatracker.ietf.org/doc/draft-seitz-ace-usecases/
> 
>Hannes and I went through the feedbacks in the mailing list.
>
> 
>In summary, we feel that there is no consensus to adopt the current
>version of this document.
> 
>Considering that use case document is our charter item, and this is the
>only viable candidate, our plan is to ask authors to update the draft
>according to the received feedbacks so far and we will initiate another
>call-for-adoption
> for the new version.
> 
>Also, kindly remind you to contribute your texts to the use case document.
> 
>Thanks,
> 
>Kind Regards
>Kepeng & Hannes