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

[Ted Lemon]

On May 25, 2018, at 7:18 PM, Brian E Carpenter  
wrote:
> Understood. However, many of us exposed to certain operating systems deeply 
> hate it when the system thinks it knows what we want better than we do. What 
> I'm suggesting is that dealing with unexpected and/or faulty human 
> intervention is also necessary. So IMHO human override needs to be thought 
> about, both as a risk and as a feature.

Yes, for sure.   But e.g. one of the things homenets do right is to deal with 
humans plugging and unplugging indiscriminately.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

Brian E Carpenter  wrote:
>> Ted Lemon  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.

> This prompts a few thoughts:

> (1) There's a strong resemblance between a homenet and a small office
> network, in which there's quite likely to be a human who is supposedly
> in charge of the network as a minor part of their job. That may well be
> a human who has the authority but not the skills. So there's possibly
> a category of "badly managed network" to consider.

Yes, so there are badly managed small office networks, and unmanaged small
office networks (using homenet technology).

> (2) I note the "(human)". Actually some of the concepts of autonomics
> and intent-based networking may spill over from enterprise networks
> into SOHO, at some point in the future.

I think that it's a grey area, but I'm okay with claiming that the autonomic
network had a human operator write the Intent.

> So, the naming system may end up being fully automatic, well or badly
> managed by a human, or managed autonomically.

I realize reading this that the autonomic network is much like the autonomous
vehicle:  Something we aspire to get right, and to do so in order to
avoid/reduce human errors.   (Are the autonomous vehicle people
ahead of the autonomic network people? Not sure)

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




signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian E Carpenter]

On 26/05/2018 11:02, Ted Lemon wrote:
> On May 25, 2018, at 1:49 PM, Brian E Carpenter  
> wrote:
>> So, the naming system may end up being fully automatic, well or badly
>> managed by a human, or managed autonomically.
> 
> The simple naming architecture is fully automatic, but doesn't do as much as 
> we might want.   I think that the advanced architecture can also be 
> automated, but that's terra incognita.   We are not interested in the use 
> case where naming is managed by the human.   It may be possible for the human 
> to intervene, but it has to work if they don't, and that's the nut we are 
> trying to crack.

Understood. However, many of us exposed to certain operating systems deeply 
hate it when the system thinks it knows what we want better than we do. What 
I'm suggesting is that dealing with unexpected and/or faulty human intervention 
is also necessary. So IMHO human override needs to be thought about, both as a 
risk and as a feature.

   Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On May 25, 2018, at 12:21 PM, Michael Thomas  wrote:
> Optional to implement or optional to deploy?

Optional to deploy.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

On May 25, 2018, at 1:49 PM, Brian E Carpenter  
wrote:
> So, the naming system may end up being fully automatic, well or badly
> managed by a human, or managed autonomically.

The simple naming architecture is fully automatic, but doesn't do as much as we 
might want.   I think that the advanced architecture can also be automated, but 
that's terra incognita.   We are not interested in the use case where naming is 
managed by the human.   It may be possible for the human to intervene, but it 
has to work if they don't, and that's the nut we are trying to crack.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian E Carpenter]

On 26/05/2018 08:06, Michael Richardson wrote:
> 
> Ted Lemon  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.

This prompts a few thoughts:

(1) There's a strong resemblance between a homenet and a small office
network, in which there's quite likely to be a human who is supposedly
in charge of the network as a minor part of their job. That may well be
a human who has the authority but not the skills. So there's possibly
a category of "badly managed network" to consider.

(2) I note the "(human)". Actually some of the concepts of autonomics
and intent-based networking may spill over from enterprise networks
into SOHO, at some point in the future.

So, the naming system may end up being fully automatic, well or badly
managed by a human, or managed autonomically.

 Brian

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

Ted Lemon  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
> 

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

[Ted Lemon]

This is out of scope for simple naming anyway, so I don't think we need to
answer this now.

On Fri, May 25, 2018, 12:24 Michael Thomas  wrote:

>
>
> On 5/25/18 10:34 AM, Ted Lemon wrote:
> > 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.
> >
> >
>
> Optional to implement or optional to deploy?
>
> Mike
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Thomas]

On 5/25/18 10:34 AM, Ted Lemon wrote:
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.





Optional to implement or optional to deploy?

Mike

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Ted Lemon]

Thanks for the review, Michael!

On May 25, 2018, at 11:59 AM, Michael Richardson  wrote:
> Ted Lemon > 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 

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

[Michael Richardson]

Ted Lemon  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  [ 
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[ 



signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet