Ted Lemon <[email protected]> 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.
> 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/ ?
> o Resolution: a full-service caching DNS resolver
s/caching DNS resolver/caching DNSSEC resolver/ ?
> * 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.
> 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.
> 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...)
> 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)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
