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

[Ted Lemon <[e-mail]>]

Thanks for the review, Michael!

On May 25, 2018, at 11:59 AM, Michael Richardson <[e-mail]> wrote:
> Ted Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>> The homenet naming architecture consists of two parts: the simple
>> naming architecture, and the advanced naming architecture.  The
>> advanced architecture provides approximate parity of features with a
>> managed network, including the ability to publish services on the
>> internet.
> 
> I hate to ask this, but it seems like we ought to have a definition for a
> managed network... :-(
> I think that the section 2.1 provides contrasts, but maybe we should instead
> say what aspects of the Managed LAN we care about.

Good point.  The "including the ability to publish services on the Internet" seems like a reasonable first attempt at specifying that, but I agree that it's insufficient.   Do you have a theory to offer?   What I think I meant by this was:

- Has a globally-scoped delegation for publishing names (a forward tree)
- Optionally with DNSSEC
- Has one or more globally-scoped delegations for publishing records referring to globally-scoped IP addresses on the network (a reverse tree)
- Optionally with DNSSEC
- Ability to specify which services are visible from outside, either manually or automatically (e.g. with mud).
- Ability to acquire ACME certs?   This is probably out of scope-ish, but ACME does interact with the naming system.   This is one of my primary motivations for caring about the advanced naming architecture, TBH—it makes it possible to secure the gateway web UI.

There's probably other stuff I forgot, which is in the old version of the homenet naming architecture.   That said, I don't think this needs to be covered exhaustively here.   The point is "
> 
>> o  Authority: a name server that is authoritative for at least a
>> forward and one or two reverse domains that are applicable to that
>> network
> 
> s/forward/forward domain/ ?

An X (B, implicitly) and 2 Y Bs is a pretty normal english construction, but maybe it would be better to be explicit, so I'll make this change.

>> o  Resolution: a full-service caching DNS resolver
> 
> s/caching DNS resolver/caching DNSSEC resolver/ ?

That would be nice for avoiding cache poisoning, but I don't think it's required.   If you don't validate at the host, you might as well not bother.   That said, this point is worth making clear later on when these bullet points are expanded upon.

>> *  manages the lifetime of such information, so that it persists
>> long enough to prevent spoofing, but protects end users from
>> seeing stale information
> 
> Should the naming architecture consider that some devices are guests?
> For instance, should such devices be marked in some way when they publish
> names, and how would they be upgraded?  The upgrade must be simple, but
> intentional, otherwise well have flashing 12:00 VCR syndrome in most home
> networks.

Can you articulate a meaningful distinction between a "guest" service and a regular service?   The only thing I can think of is that you might want a shorter default lifetime on the service registration, but I don't think it's actually very important.  Part of the way the DNSSD registration protocol is intended to work is that names are reserved for longer than they are visible as services, so if you come along an hour after a guest device has left the network, you won't see a service record published for it, but you won't be able to claim its name.   Do you think we need to do more than that?

Are guest devices identified on the basis of connecting to a "guest" network?

(This is a good observation, BTW, and I'm not disagreeing that we should consider it, just not sure what to write).

>> In many managed LANs, establishment of trust for service discovery is
>> simply on the basis of a belief that the local resolver will give a
>> correct answer.  Once the service has been discovered and chosen,
>> there may be some security (e.g., TLS) that protects the connection
>> to the service, but the trust model is often just "you're connected
>> to a network you trust, so you can trust the printer that you
>> discovered on this network."
> 
> I'd be curious to know how many printers on corporate/enterprise/campus
> environments get TLS certificates?   I suspect that in such environments, the
> majority of printing is via a printer server, and the security is via
> ActiveDirectory or equivalent.  But I don't know, I haven't lived in such an
> environment for a long time, and my printers either don't support TLS,
> or they have a self-signed certificate because CUPS doesn't make it easy for
> me to care.
> 
> In essence, I wonder if you are raising the bar for the Homenet higher than
> for real Managed LANs.  I'm okay with that, btw, but I think we should be
> clear that we are doing it because it's easy.

Yes.  That's precisely what I'm hoping to do.   Active Directory obviously isn't going to work in this situation, and since it's not an IETF standard, there's no reason to attempt to replicate that model.   Although if we can hack a TLS cert into a printer on a homenet by claiming it in an active directory domain somehow, I'm all for doing that as a shim.  Another way that someone from the NIST proposed is to just take a $25 Raspberry Pi-ish device (maybe with better I/O, like the NanoPi Neo Plus2) and just interpose it between the printer and the network to prevent the printer from presenting a non-encrypted API.   But that's definitely out of scope.

>> 2.2.  Homenet-specific considerations
> 
>> A naming architecture for homenets therefore adds the following
>> considerations:
> 
>> o  All of the operations mentioned here must reliably function
>> automatically, without any user intervention or debugging.
> 
> I'd like to add some kind of visible auditing here.
> I'm thinking about something like multicasted syslog about things that are
> occuring automatically. (Still funny that evil rcmd and syslog both live on
> port 514...)

I agree, but I think that's out of scope.

>> o  Homenets must address the problem of multiple provisioning
>> domains, in the sense that the DNS may give a different answer
>> depending on whether caching resolvers at one ISP or another are
>> queried.
> 
>> An additional requirement from the Homenet Architecture [9] is that
>> hosts are not required to implement any homenet-specific capabilities
>> in order to discover and access services on the homenet.  This
>> architecture may define optional homenet-specific features, but hosts
>> that do not implement these features must work on homenets.
> 
> Is it acceptable that it only works if the host uses the DNS server that DHCP
> supplied?
> I think it's unacceptable if the host has to rely on search path, and I think
> we all agree on that. (But major captive portal suppliers still haven't
> figured that out)

If the host is doing DoH to bypass the local DNS server, it won't be able to access local services.   This is probably the right outcome.   Anything we do to finesse this is going to require changes on the host.   I suspect that this is out of scope for the simple naming architecture, but am eager to hear arguments to the contrary.   :)