Re: [homenet] standard way of configuring homenets

["STARK, BARBARA H" <[e-mail]>]

> > <individual hat> Since homenet is supposed to be about an unmanaged
> > network, and configuration via a management protocol requires somebody
> > who knows what they’re doing,
> 
> Traditionally, yes, but we do actually want to get away from that.
> (It's our explicit goal to do that in ANIMA, for which homenets are out of
> scope, but we assume that the starting point is a NOC staffed by people who
> know what they are doing.)
> 
> The idea of capturing a homenet config and saving it for future use doesn't
> seem outlandish to me, and using tools developed for managed networks,
> but operated robotically instead of manually, doesn't seem crazy either. But
> it might be a big effort and a distraction.

<as individual contributor>
Using tools developed for managed networks in amateurishly-managed (or unmanaged) home network environments has historically turned out very badly.
Poorly implemented management protocols and "backdoors" are a leading cause of security vulnerabilities. These poor implementations are common and prevalent. 
Improperly secured, but (otherwise) well-implemented management protocols are another leading cause of security vulnerabilities. This is also common and prevalent.
And I'm not just talking about the device's or home network's security. I'm talking about Internet security -- this is how DDoS attacks are enabled.
As a data point: providers like Comcast actively block SNMP ports because SNMP is so easy to use in DDoS attacks. (https://www.xfinity.com/support/articles/list-of-blocked-ports)
I realize netconf and restconf aren't SNMP. But please don't think that if these protocols were to be deployed in millions of consumer devices and placed under the control of end users we would discover them to be magically immune to poor implementations and being improperly secured. I have yet to see a management protocol that is immune to either of these issues.

Which isn't to say it couldn't be done or there might not be a good use case for it. I'm saying that it is a huge effort that would need to be done with extreme foresight and care. We would need to understand extremely well exactly what we do and don't want from such a management solution -- exactly what problems we are trying to solve and what our requirements are. Does it need to be a single management protocol to solve everything, or do we separate reporting of statistics from configuration backup from UI for user configuration? We would have to be rock-solid on requirements for securing any such management interface, understand what our strategy is for minimizing occurrence of poor implementations, and understand what our strategy is for minimizing occurrence of improperly-secured implementations.

On the plus side -- maybe if we were able to do this, it would keep developers from creating their own custom vulnerabilities (aka management interfaces) by giving them a viable properly secured solution.
Barbara