Subject: Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

From: Michael Richardson <[email-masked]>
Date: Fri, 01 Jun 2018 11:02:26 -0400

Ted Lemon <[email-masked]> wrote:
    > The problem is that hosts tend to remember names.   On MacOS, for
    > instance, if you configure a printer, the host remembers the printer
    > forevermore.   It's no problem to configure a new printer, but if you
    > change the name that the printer advertises, there will be a stale
    > configuration on the host pointing to the old name, and the user will
    > have to configure a new printer to get access to the old printer.

So, there are now "True Names", and "Current Names", and some nebulous
disctinction between them.  TrueNames could be IP addresses or L2 addresses
(except for privacy issues that make them Current names)... 

Let me add additional motivation/use-case to what you say:

Let's say I have a printer called "basement", and after awhile I decide I
want a better printer, and so I get one.  I move the "basement" printer
to the spouse's office, and I want to rename it "houseprinter", because
I want the new printer to be called "basement".

I should be able to rename the printer once, and a whole bunch of places
where there is a link to "basement" should become "houseprinter", because I
see no reason why I should re-install drivers and changes settings, etc.
At the same time, the default printer for my basement desktop should probably
*not* change, but perhaps that's too much to ask.

Contrast this to a case where I get a new phone, and give my old phone to my
kid.  I actually want to *disconnect* all privileges for the old phone when
it is not just renamed, but in fact, factory reset.  My new phone should get
all the privileges of my old phone.

So in fact, when I move the printer I want it to keep the TrueName something,
and when I get a new phone, I want it to adopt the old phone's TrueName
something.

    > So what we are talking about here actually breaks DNSSD's good
    > behavior.   We don't want DNSSD to publish two names.   We don't want
    > DNSSD to publish a CNAME.   That would just be extra garbage that would
    > have to be maintained forever. 

    > What we want is a way for the host to notice that the device's name has
    > changed.   We want the device to have some identity other than the name
    > that doesn't change when the name changes.   And we actually have this
    > in the registration protocol, which is another draft being published in
    > the DNSSD working group.   That protocol has the host generating a
    > public/private key pair, and using the public key as an identity.   It
    > uses this identity to claim the name, but it wouldn't be that much work
    > to also specify that hosts should use that identifier to notice that a
    > device has a new name and update the name in the user interface.

Factory reset generates a new keypair, and despite the name change,
that should persist in the printer, so this is perfect.

So what we want the host to remember is the public key of the printer, not
the name.   Is this possible with DNSSD?  I guess we need this additional draft.

    > When I talk about UI, I'm really talking about the API behind the UI.
    > Having a management API for homenet would be a good thing.   Possibly
    > it could just be done with HNCP. 

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 18 Jun 2018 22:19:52 +0000

Hi homenet,
There was great conversation about homenet-simple-naming a couple of weeks ago. I wanted to see if I could summarize where that ended up.

Main points discussed were device (friendly? pretty?) name and/or identity (public key?) and basic end user management (like giving devices names).

What I read into the discussion (which may not be what others read -- in which case we can and should re-discuss) is:
Some users like to give their devices pretty/friendly names. We need to make sure that's possible, but not required.
Others will simply accept whatever name the device comes with.
These names are visible to users and should not be confused with credentials or a stable identity. But they do need to be unique.
Stable identity is also needed.

So how did I do? And where does this take us?
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Jun 2018 18:32:26 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > in which case we can and should re-discuss) is: Some users like to give
    > their devices pretty/friendly names. We need to make sure that's
    > possible, but not required.  Others will simply accept whatever name
    > the device comes with.  These names are visible to users and should not
    > be confused with credentials or a stable identity. But they do need to
    > be unique.  Stable identity is also needed.

This is essentially correct, but it feels a bit weak to me.

Given that devices wind up with pretty/friendly names, and that those name
can change for a variety of reasons, we REQUIRE stable identity as well as
pretty names.

Users need to be able to connect policies (including, but not just security
policies) to both pretty names ("the office printer"),  and to stable
identies.   Neither thing should have anything to do with IP addresses
(which get renumbered), nor to MAC addresses (which may be more frequently
randomized, even for things like printers).

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Jun 2018 11:50:48 -0400

> randomized, even for things like printers).

I think this is right, but it seems to me we could be slightly more
formal.

Over time, a device has one of more MAC address; the MAC address must
not be treated as a stable identifier because it may change over time.

At a given time, a given MAC address may have 0 or more IP addresses
assigned.  If any MAC address has an IP address assigned to it, that
address is expected to be assigned automatically.  It is expected to
change.  An {IP, MAC} tuple should not be treated as a stable
identifier because both elements of the identifier may change over
time.

Each device will have at least one name.

Some names are automatically assigned through the workings of mDNS or
hybrid multicast DNS (or both).  In particular, when devices are
available by mDNS they are available by name, but the names are
checked (and if need be changed) algorithmically in order to prevent
duplication.  Names are unique within the scope of the homenet, and
devices will change their names in the event of collision.

Some names are generated by users, and assigned to devices, depnding
on whether the device supports that functionality.  These names MUST
NOT be changed algorithmically by devices, and MUST NOT collide with
automatically-generated names.  These names may be globally-unique, or
may be unique only in the scope of the homenet.

I _think_ that covers all the cases, but I might have missed
something.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jun 2018 12:16:37 -0400

FWIW, on the particular topic of name stability, it might be worth
consulting https://tools.ietf.org/html/draft-sctl-service-registration-00,
particularly section 5, which talks about first-come, first-served name
registration.   The document is expired because we've been distracted by
implementation recently, but a new version should be coming out shortly.
This is of course an extension to DNSSD, and therefore can't be counted on
to be present in existing devices, so for those devices the security of
names isn't really possible to guarantee in any meaningful way—as you've
both said, neither the MAC address nor the IP address can be used as an
identifier with any confidence.

On Tue, Jun 19, 2018 at 11:50 AM, Andrew Sullivan <[email-masked]>
wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>