Subject: Request for Comments on Internet Draft about IoT DNS Name Autoconf

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 14 Jul 2015 22:31:26 +0900

Hi 6MAN WG,
This is Paul.

I would like to let you know a draft for IoT Device DNS Name
Autoconfiguration:

----------------------------------------------------------------------------
DNS Name Autoconfiguration for Internet of Things Devices
(draft-jeong-homenet-device-name-autoconf-03)

https://tools.ietf.org/html/draft-jeong-homenet-device-name-autoconf-03

Abstract
   This document specifies an autoconfiguration scheme for DNS names of
   Internet of Things (IoT) devices, such as appliances and sensors.  By
   this scheme, the DNS name of an IoT device can be autoconfigured with
   the device's category and model in wired and wireless networks (e.g.,
   home, office, shopping mall, smart grid, and road network).  This DNS
   name lets IoT users (e.g., home residents and customers) easily
   identify each device for monitoring and remote-controlling it in a
   target network.
----------------------------------------------------------------------------

This draft is a follow-up IETF draft of RFC6106-bis for IPv6 RA RDNSS and
DNSSL options for IPv6 Host DNS Configuration:

https://tools.ietf.org/html/draft-jeong-6man-rdnss-rfc6106-bis-00

For this draft, three organizations (i.e., SKKU, ETRI, and Jubix)
are developing a prototype of our proposed IoT DNS name autoconfiguration
on top of a smart grid platform to collect the usage of electonic meters
over
IPv6/6lo/SUN (Smart Utility Network, IEEE 802.15.4g) in a smart grid in
Korea Electric Power Corporation (KEPCO).

We believe that the proposed scheme will be useful in a variety of
environments using IPv6, such as smart grid, smart home, smart mall, smart
factory,
and smart Intelligent Transportation Systems (ITS).

I think that this IoT DNS name autoconfiguration will be an enabler such
that
IPv6 will be a key network layer of such IoT environments.

In this IETF meeting, I will briefly introduce this scheme along with our
prototype.
Please read our draft and give us your comments by email before the 6MAN WG
meeting in Prague:

https://tools.ietf.org/html/draft-jeong-homenet-device-name-autoconf-03

Thanks.

Paul
===========================
Jaehoon (Paul) Jeong
Assistant Professor
Department of Software
Sungkyunkwan University
Mobile: +82-10-4758-1765
Email: [email-masked], [email-masked]
URI: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Jul 2015 11:16:26 -0700

Dear Professor Jeong,

Thank you for sharing the update to your draft.  I note that in the
security section of your draft that you make the following proposal:

  to prevent the disclosure of location information for privacy
  concern, the subdomains related to location can be encrypted by a
  shared key or public-and-private keys.  For example, a DNS name of
  smartphone1.living_room.home can be represented as
  smartphone1.xxx.home where xxx is a string of the encrypted
  representation of the subdomain living_room.

First, I believe that there are more privacy concerns here than location
privacy.  The base format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | unique_id.device_model.device_category.mic_loc.mac_loc.domain_name|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

proposes to include both the device model and a unique identifier.
A naive implementation could easily select its serial number, which
would clearly be problematic; even the device model may be an issue for
certain cases (e.g. a medical device).

Second, the delegation model here seems to require a consistent view  of
both device categories and location names.  How do you see that being
produced?

Lastly, the privacy mitigation given is not yet clear to me.  How would a
user of the DNS determine how to decrypt the encrypted strings?  If the
point of the effort is autoconfiguration, relying on out-of-band
configuration for this  seems contrary to the goal.  If you distribute the
decryption keys within the DNS, however, you are likely to lose whatever
privacy protection is provided.  Can you explain this further?

regards,

Ted Hardie

On Tue, Jul 14, 2015 at 6:31 AM, Mr. Jaehoon Paul Jeong <
[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 15 Jul 2015 06:26:55 +0900

Hi Ted,
First of all, thanks for your valuable comments and questions.
Let me put my answers in lines.

For privacy-sensitive devices (e.g., medical device), only device_category
is represented as plaintext, and
device_model and unique_id can be represented as cypertext for privacy
protection.
If needed, device_category can also be encrypted for better privacy
protection.
But this conservative way does not provide device information to other
users or devices
in terms of service discovery (i.e., searching for what devices are
available).

Though I am not sure that I understand your question about the consistent
view correctly,
the standard representation of device categories and location names will be
developed further
through the input from 6MAN WG.
For now, if the base format above is respected, we can define device
categories and location names
from common sense as follows:

* device categories (device category : description)
  smart_tv : smart television
  smartphone: smartphone
  refrigerator: refrigerator
  temp_controller: temperature controller
  smoke_detector: smoke detector
  light_bulb : light_bulb

* location names (location : description)
  1) mac_loc (macro-location)
    living_room : living room
    kitchen : kitchen
    bedroom : bedroom
    study_room : study room
    garage : garage
    office : office

  2) mic_loc (micro-location)
    center : center of mac_loc
    wall : wall of mac_loc
    corner : corner of mac_loc

As shown above, we can represent and standardize both device categories and
locations
according to common sense.

We can think various candidate options for key sharing for the
encryption/decryption
of the DNS subdomains.

One easy way is that a vendor provides a customer with a factory-default
key
(i.e., pre-shared key) as many bluetooth pairing products (e.g., bluetooth
mouse) are used.
The key of a device can be input by the customer into his/her home gateway
(or home configuation server)
whenever he/she installs the device into his/her house.

A better way is welcomed if anybody proposes it. :-)

Paul

---

From: Ted Hardie <[email-masked]>
Date: Tue, 14 Jul 2015 14:47:52 -0700

​Dear Professor Jeong,

Thank you for quick reply, and I will follow your practice of replying
in-line.​

> in terms of service discovery (i.e., searching for what devices are
​In the most privacy sensitive case, in other words, this would four
encrypted strings, followed by the domain name​.  As varying the number of
slots which are encrypted leaks which elements are sensitive, I am not sure
I understand why this is not the common case.  I am not sure, given that no
other users or devices would be able to use this data why it would benefit
from storage in the DNS.

> the standard representation of device categories and location names will
> be developed further

​I am afraid that while some languages may have the benefit of common sense
here, American English isn't one of the.  The same room in the house I grew
up in was called the living room, the den, and the parlor, depending on the
age of the speaker and the formality of the activity.  To avoid that, you
appear to need a registry of all potential locations, as well as all IoT
types.  Even then, you will have a problem for cases which occur more than
once (as bedroom would in many cases)--how do you disambiguate among them?

> As shown above, we can represent and standardize both device categories
> and locations
​If understand you correctly, that might cover​ the encryption of unique
id, but it cannot cover the other elements above that, because they are
shared.  Let's say that there are two smartphones in the center of a
bedroom.  Your format is:

unique_id.device_model.device_category.mic_loc.mac_loc.domain_name|

or

effaabb.samsung_galaxy6.smartphone.center.bedroom.domain_name

and

bbaaeff.apple_iphone6.smartphone.center.bedroom.domain_name

​If the two are in the same category, which key is sued for encrypting
device_category?  What about mic_loc? What about mac_loc?​

> A better way is welcomed if anybody proposes it. :-)
​I do not think the encrypted approach present is the right way forward
here, and I suggest you think instead of data minimization strategies and
the basic privacy issues.

best regards,

Ted Hardie​

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 16 Jul 2015 07:22:51 +0900

Ted,
Here are my answers in lines with the arrow symbol "=>".

On Wed, Jul 15, 2015 at 6:47 AM, Ted Hardie <[email-masked]> wrote:

>> For privacy-sensitive devices (e.g., medical device), only
>> device_category is represented as plaintext, and
> => For a more conservative privacy, we can prevent devices' DNS names from
being exposed to adversaries
     by encrypting the whole DNS names.
     Only authenticated users (via smartphone) will be able to obtain the
tuples of IoT device DNS names and IPv6 addresses
     from an authoritative DNS server, having those tuples.

> ​I am afraid that while some languages may have the benefit of common
> sense here, American English isn't one of the.  The same room in the house
> I grew up in was called the living room, the den, and the parlor, depending
> on the age of the speaker and the formality of the activity.  To avoid
> that, you appear to need a registry of all potential locations, as well as
> all IoT types.  Even then, you will have a problem for cases which occur
> more than once (as bedroom would in many cases)--how do you disambiguate
> among them?
>
>   => We will be able to select a set of location names for IoT devices
through an agreement procedure.
       For multiple instances with the same location (e.g., bedroom), we
can add a serial number to the location name
       in order to disambiguate them, such as bedroom1 and bedroom2.

>> >Lastly, the privacy mitigation given is not yet clear to me.  How would
>> a user of the DNS determine how to decrypt the encrypted strings?  If the
>> (i.e., pre-shared key) as many bluetooth pairing products (e.g.,
>> bluetooth mouse) are used.
>> The key of a device can be input by the customer into his/her home
>> gateway (or home configuation server)
>  => Assume that these two smartphones belong to a member of domain_name
(e.g., home).
      In this case, a shared key of the member can be used to encrypt
bedroom.

      Also, assume that members of domain_name (e.g., home) share such a
pre-shared key and
      they have galaxy6 and iphone6 smartphones, respectively.
      Such members can decrypt the encrypted representation of bedroom with
their pre-shared key.

>  => I agree that your proposed data minimization strategies may be a good
candidate approach for the privacy of IoT device DNS names.
      I will further consider an approach to handle sensitive subdomains,
such as device category, device model, location information
      (i.e., mac_loc and mic_loc), including data minimization strategies.

      Thanks.

      Paul

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: Francisco Paletta <[email-masked]>
Date: Thu, 16 Jul 2015 11:06:17 -0300

Hello Professor Jeong,

Thank you for your draft. I'm pleased to read it and see this work in the
area of the IoT. Lately I have been using Arduino in some subjects with my
students as the main platform to develop the various theories we study and
I have some comments I would like to share:

I agree with Ted and I believe security and privacy MUST be a major
concern. If your draft moves forward and no specific mechanism is defined
then it will have to be added later, as we have seen in many other cases.

I never thought of problems with high-capacity devices, as you mentioned.
They are usually big enough to accommodate easy input and output methods to
allow the user to give the device a distinct DNS name (and other
configuration). But I totally agree that on low-capacity devices that
becomes an issue. In this case, my approach has been the use of a second
device, such a Bluetooth enabled smartphone to provide input/output on
initial configuration. I agree this is not always possible.

As other comments start to come in, I believe you will face some road
blocks such as the balance between the security and the real need of
auto-configuration (as opposed to available methods of manually inputting
data on the devices). In my opinion you could narrow down to scenarios
where these devices will really need auto-configuration, analyse the
specific security concerns, and then propose a detailed solution.

Adding to all of that, I haven't seen yet a proposal for IoT devices
"auto-configuration" of the gateway IPv6 firewall (maybe I didn't search
deep enough). But for the IoT device to work as "plug and play" and be
reachable from Internet, it will need, besides DNS auto-configuration,
other method of informing the firewall to open the necessary ports. If such
method exists, then it shares the same security concerns as yours.

Best regards,

Francisco Paletta

2015-07-15 19:22 GMT-03:00 Mr. Jaehoon Paul Jeong <[email-masked]>:

>>> >First, I believe that there are more privacy concerns here than
>>> location privacy.  The base format:
>>> >
>> => For a more conservative privacy, we can prevent devices' DNS names
> from being exposed to adversaries
>>> >Second, the delegation model here seems to require a consistent view
>>>  of both device categories and location names.  How do you see that being
>>> produced?
>>>
>>> Though I am not sure that I understand your question about the
>>> consistent view correctly,
>       Such members can decrypt the encrypted representation of bedroom
> with their pre-shared key.
>
>
>>
>>

---

From: manning <[email-masked]>
Date: Thu, 16 Jul 2015 21:26:34 -0700

The reason I ask is that the title is about DNS name autoconfig.  It might be reasonable to run a parallel stream in DNSOPs, in the unlikely event of problems.
manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 16July2015Thursday, at 12:19, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:

> Hi Manning,
> Sure, my proposal can be discussed in DNSOPS WG.
> Since my proposal uses IPv6 ND(neighbor discovery) and NI(node information) query,
> 6MAN WG will be a good place to discuss it first.
> After that, if needed, I will be able to introduce it to DNSOPS WG.
> 
> Thanks.
> 
> Paul
> 
> On Fri, Jul 17, 2015 at 2:29 AM, manning <[email-masked]> wrote:
> Ted et.al.   Is there a good reason this is not being discussed in the DNSOPS WG?
> 
> 
> manning
> [email-masked]
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
> 
> 
> 
> On 14July2015Tuesday, at 11:16, Ted Hardie <[email-masked]> wrote:
> 
> > Dear Professor Jeong,
> >
> > Thank you for sharing the update to your draft.  I note that in the security section of your draft that you make the following proposal:
> > First, I believe that there are more privacy concerns here than location privacy.  The base format:
> >
> > would clearly be problematic; even the device model may be an issue for certain cases (e.g. a medical device).
> >
> > Second, the delegation model here seems to require a consistent view  of both device categories and location names.  How do you see that being produced?
> >
> > Lastly, the privacy mitigation given is not yet clear to me.  How would a user of the DNS determine how to decrypt the encrypted strings?  If the point of the effort is autoconfiguration, relying on out-of-band configuration for this  seems contrary to the goal.  If you distribute the decryption keys within the DNS, however, you are likely to lose whatever privacy protection is provided.  Can you explain this further?
> > regards,
> >
> > Ted Hardie
> >
> >
> > On Tue, Jul 14, 2015 at 6:31 AM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> > Hi 6MAN WG,
> > This is Paul.
> >
> > I would like to let you know a draft for IoT Device DNS Name Autoconfiguration:
> >
> > on top of a smart grid platform to collect the usage of electonic meters over
> > environments using IPv6, such as smart grid, smart home, smart mall, smart factory,
> > I think that this IoT DNS name autoconfiguration will be an enabler such that
> > In this IETF meeting, I will briefly introduce this scheme along with our prototype.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sun, 19 Jul 2015 20:44:00 +0200

Manning,
I will add this thread to DNSOP WG and 6lo WG.
This is because a good target application area of my draft is 6lo
environment.
Today I discussed my draft with Samita, who is a co-chair of 6lo WG.
She recommended to me that I can announce my draft to 6lo WG.

DNSOP WG and 6lo WG,
if you have time and interest in DNS autoconfiguration for constrained
nodes (e.g., IoT devices),
please attend 6MAN WG meeting from 1PM to 3PM tomorrow (at Congress Hall
III).
My presentation will be the last one.

My draft on DNS name autoconfiguration for constrained nodes can be found in
https://tools.ietf.org/html/draft-jeong-homenet-device-name-autoconf-03

Also, you two WG people can give me your comments by email.

Thanks.

Paul

On Fri, Jul 17, 2015 at 6:26 AM, manning <[email-masked]> wrote:

> The reason I ask is that the title is about DNS name autoconfig.  It might
> be reasonable to run a parallel stream in DNSOPs, in the unlikely event of
> problems.
> manning
> [email-masked]
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102
>
>
>
> > >    |
> > > would clearly be problematic; even the device model may be an issue
> for certain cases (e.g. a medical device).
> > >
> > > Lastly, the privacy mitigation given is not yet clear to me.  How
> would a user of the DNS determine how to decrypt the encrypted strings?  If
> the point of the effort is autoconfiguration, relying on out-of-band