Subject: [Ace] Review of ACE Uses Cases draft (draft-ietf-ace-usecases-03)

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 May 2015 21:07:39 +0000

Hannes, Kepeng, Folks,

As promised, here is a review of the use cases draft (draft-ietf-ace-usecases-03). I also checked against the stated goals of the ACE Charter.

I apologize upfront if some of my comments may offend folks in the ACE WG. However, the field of Constrained Environments and Devices (IoT) is a huge deal, so I believe getting the architecture/protocols right is an important contribution that IETF can make.

General comments:

(a) On the positive side:

- I think this is a pretty good and reasonable set of use-cases from the ACE WG. Congrats!

- The majority of use-cases here have been written in a technology-agnostic manner, as they should. And so perhaps the draft doesn't really need to call out specific technologies/protocols like REST and CoAP (Section 1, Parag 4 & 5) since these are already called out in the ACE Charter. However, leaving these in is also ok and does not detract from value of the use-cases draft.

(b) On the (somewhat) negative side:

- IoT is the other side of the coin of Big Data.  This is particularly true for the Home Automation (Smart Home) scenarios.  The most valuable asset here is the *data* that these devices collect and report.

- As such I was kind of surprise that there was no use-case covering the Home Personal Data Store (Home-PDS). Many smart-home owners would potentially prefer the model where all their home-data (e.g. from AC, refrigerator, thermostat, etc) gets collected into one data-store or container that they control (call it what you will: the home PC, the "home server", the "home gateway", etc). In this way the home-owner then has owner-centric control over which data-sets get sent out of the home.

PS. If the ACE WG is open, I can write a short use-case on the Home-PDS.

(c) Weak Privacy Considerations section (Sect 4):

- The privacy consideration section (Sect 4) is weak IMHO. Perhaps a privacy expert should be invited to contribute better text to that section.

- May I suggest the addition of some references in Sect 4 that indicate awareness of privacy issues around personal/home/health data:

[ref#1] World Economic Forum, "Personal Data: The Emergence of a New Asset Class," 2011, available on http://www.weforum.org/reports/ personal-data-emergence-new-asset-class.

[ref#2] Meglena Kuneva, European Consumer Commissioner, Keynote Speech, Roundtable on Online Data Collection, Targeting and Profiling, Brussels, 31 March 2009. Available at: http://europa.eu/rapid/press-release_SPEECH-09-156_en.htm

Specific comments on certain lines on the draft:

(d) Section 2, parag.2 :

>>> The definition of the function of a
>>> device in a certain use case is not 
>>> in scope of this document.

This line seems redundant. I think a good use-case ("use-case scenario") should always be written in a high level and thus avoid defining functions to begin with.

(e) Section 2.2, parag. 1:

>>> A home automation system connects 
>>> devices in a house to the Internet 
>>> and thus makes them accessible and 
>>> manageable remotely. 

To the non-technical reader, this line seems to confine/limit the potential scope of Home Automation or the Smart Home. IoT in the home promises far more than provide remote accessibility and remote manageability to devices in the home.

(f) Section 2.3.2:

>>> o U3.7 The device provides a service 
>>> that can be fatal for the wearer if it fails.
>>> Accordingly, the wearer wants a security
>>> mechanism to provide a high level of security.

I think I understand the intent of this line (related to U3.6), but the sentence could be improved. More specifically, a device failing may have nothing to do with the level of security implemented in the device. For example, a heart monitor may fail simply because it was a faulty device coming out of the factory.

So perhaps something like: 

"The device provides a service that can be fatal for the wearer if it fails. Accordingly, the wearer wants the device to have a high degree of resistance against attacks that may cause the device to fail to operate partially or completely".

(g) 2.5.3. Advanced Metering Infrastructure:

- This subsection perhaps contains too much technical detail about the Head-End and the Data Collection Units. (Most home owners who have cable TV or cable modem don't know that there is a head end CMTS server that talks to their cable box).

- I would suggest rewriting these two bullets into a softer explanation using the entities involved (home-owner, utility company, smart meter, etc).

(h) 2.5.4: U5.1

>>> U5.1 Devices are installed in hostile 
>>> environments where they are physically 
>>> accessible by attackers. The service 
>>> operator and the utility company want 
>>> to make sure that an attacker cannot use a
>>> captured device to attack other parts 
>>> of their infrastructure.

- This bullet item does not sound like it is an authorization problem but rather a device-physical-security problem, caused by placing the devices (e.g. smart meter) outside the house or premises. This problem could be remedied (e.g. in the future drive-by metering) if in the smart-meter was placed inside the house (e.g. windows panel) or placed on high on the wall or the roof.

(i) 2.5.4: U5.2

>> U5.2 The utility company wants to restrict 
>> which entities are allowed to send data to 
>> their endpoints and to ensure the
>> integrity of the data on their endpoints.

This sentence is a bit confusing and needs fixing (maybe it was 2 sentences joined into one). We know that the utility company wants both of these features (authorization to send data with source-authentication; and integrity-protection of data/messages). Perhaps rewriting this into separate lines would help.

(j) 2.5.4: U5.2

>>> o U5.3 The utility company wants to 
>>> control which entities are allowed to 
>>> read data on their endpoints and protect 
>>> such data in transfer.

This sentence could also be improved as it seems to merge together two different needs (authorization to read data once it arrives at the side of the utility company; and integrity-protection of data/messages in transit to the utility end-point).

(k) Section 3: Parag. 1

>> Therefore, the devices will be entrusted with vast
>> amounts of valuable data or even control functions,
>> that need to be protected from unauthorized
>> access. Moreover, the aggregation of data must be
>> considered: attackers might not only collect 
>> data from a single device but from
>> many devices, thus increasing the potential damage.

- This paragraph does not read to be consistent.  Most IoT devices will have a limited storage resource, which is why they need to periodically "dump" (somewhere) the data they have gathered so far. So over time an IoT device will see large amounts of raw data pass-through but an attacker may not necessarily have access to all of this data.

- The second sentence is unclear. If an attacker can read data from large amounts of distributed IoT devices on an on-going basis, that means they have successfully compromised these devices on an almost permanent basis which means the game is up). Perhaps that second line could be re-written/improved.

/thomas/

____________________________________________

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 May 2015 23:10:17 +0200

> PS. If the ACE WG is open, I can write a short use-case on the Home-PDS.

Yes, please: This would be very useful.

Grüße, Carsten