Ted Lemon <[email protected]> wrote: >> 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:
A managed network is one that has a (human) manager, or operator.
The operator has authority over the network, and the authority to publish names
in a forward DNS tree, and reverse names in the reverse tree.
The operator has the authority to sign the respective trees with DNSSEC,
and acquire TLS certificates for hosts/servers within the network.
>>> 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.
Yes, but if you change "forward" to "forwarder", then it implies something
about routing. So that's a mistake a reader might make.
>>> 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.
"caching DNS(sec) resolver" ?
>> 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?
I visit you. I find it amusing to name my phone "printer".
When I leave, you unbox your printer, and find that you can't name it "printer".
Is this important?
> Are guest devices identified on the basis of connecting to a "guest"
network?
Yes, quite possibly.
> (This is a good observation, BTW, and I'm not disagreeing that we
> should consider it, just not sure what to write).
It would be nice if the network called my phone:
"printer.guestnetwork.example.com".
>>> 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.
I wasn't suggesting AD was a solution, but rather than in a *managed*
network, I suspect that the printers people 'discover' aren't the real
printers. Perhaps someone else will enlighten me.
>>> 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.
I was responding to "without any user debugging" --- what I think we don't
want to do is create a black box situation which means that debugging is
impossible for even an clueful person to do.
>> 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. :)
But, when a homenet host (a smartphone for instance), is away from the
homenet, it is expected to be able to use names from the homenet to reach
things. That's not any different than a host that uses 8.8.8.8 is it?
--
] 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
