Subject: [homenet] standard way of configuring homenets

From: Michael Richardson <[email-masked]>
Date: Tue, 24 Jul 2018 17:48:31 -0400

I very much like the idea of having a standard way to configure homenets.
There is the YANG/NETCONF method, and I think that we should go in that
direction.

A thought I had though.... could a HOMENET configuration be recorded by
capturing just HNCP traffic?  Could a network configuration be restored
by essentially playing back that stuff?  I'm pretty sure that this won't
work, but the question is... should it?

Does this work fit into the charter?

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2018 17:56:43 -0400

I don't think using HNCP in that particular way is a great plan, but I'm
willing to be convinced.   I would hope that this is in charter.

On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson <[email-masked]>
wrote:

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 25 Jul 2018 02:59:51 +0000

<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, it doesn’t fall within my interpretation of the charter.
Barbara

From: homenet <[email-masked]> On Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
To: Michael Richardson <[email-masked]>
Cc: homenet <[email-masked]>
Subject: Re: [homenet] standard way of configuring homenets

I don't think using HNCP in that particular way is a great plan, but I'm willing to be convinced.   I would hope that this is in charter.

On Tue, Jul 24, 2018 at 5:48 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sandelman.ca_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=uuWiihYmTZHdlSwLjIDnf8fDYcahci1jFrEDQVRDWBM&s=frhxrsM8yiLM3JkOyRI0HavzzN3k4XrwesIkggWuR0E&e=>        |   ruby on rails    [

_______________________________________________
homenet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/homenet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=uuWiihYmTZHdlSwLjIDnf8fDYcahci1jFrEDQVRDWBM&s=XnYMQ-A87X4UomP-wRjfJITHsZ87UoWghSpiPrGTNy8&e=>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Jul 2018 23:12:34 -0400

Well, the charter certainly says that we're supposed to think about
homenet's impact on manageability.   Granted, that's a thin reed to hang
on, and it would probably be better to make the charter more explicit.
 But to be clear here, all home networks have user interfaces, and this is
all we are talking about.   We've somewhat skirted the issue, but if we
want to be able to have an enrollment process, that's going to have a user
interface.   If we want to be able to do things like change the SSIDs,
that's going to require a user interface.

In my mind, the idea of homenet is not to be an unmanaged network, but to
be a network that doesn't require management to operate.   If you don't do
any managing, it should still work.   That doesn't mean that doing some
managing is a bad thing.   And if we don't specify something in this
regard, I'm afraid we're going to wind up with lots of homegrown management
UIs that force people to buy all their homenet routers from a single vendor.

On Tue, Jul 24, 2018 at 10:59 PM, STARK, BARBARA H <[email-masked]> wrote:

> <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, it doesn’t fall within my interpretation of the
> charter.
>
> Barbara
>
>
>
> *From:* homenet <[email-masked]> *On Behalf Of *Ted Lemon
> *Sent:* Tuesday, July 24, 2018 5:57 PM
> *To:* Michael Richardson <[email-masked]>
> *Cc:* homenet <[email-masked]>
> *Subject:* Re: [homenet] standard way of configuring homenets
>
>
>
> ]     [email-masked]  http://www.sandelman.ca/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.sandelman.ca_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=uuWiihYmTZHdlSwLjIDnf8fDYcahci1jFrEDQVRDWBM&s=frhxrsM8yiLM3JkOyRI0HavzzN3k4XrwesIkggWuR0E&e=>
>       |   ruby on rails    [
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_homenet&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=uuWiihYmTZHdlSwLjIDnf8fDYcahci1jFrEDQVRDWBM&s=XnYMQ-A87X4UomP-wRjfJITHsZ87UoWghSpiPrGTNy8&e=>
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jul 2018 15:50:31 +1200

On 25/07/2018 14:59, STARK, BARBARA H wrote:
> <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.

   Brian

> it doesn’t fall within my interpretation of the charter.
> Barbara
>

---

From: Tim Chown <[email-masked]>
Date: Wed, 25 Jul 2018 05:08:20 +0000

On 25 Jul 2018, at 04:13, Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

Well, the charter certainly says that we're supposed to think about homenet's impact on manageability.   Granted, that's a thin reed to hang on, and it would probably be better to make the charter more explicit.   But to be clear here, all home networks have user interfaces, and this is all we are talking about.   We've somewhat skirted the issue, but if we want to be able to have an enrollment process, that's going to have a user interface.   If we want to be able to do things like change the SSIDs, that's going to require a user interface.

In my mind, the idea of homenet is not to be an unmanaged network, but to be a network that doesn't require management to operate.   If you don't do any managing, it should still work.   That doesn't mean that doing some managing is a bad thing.   And if we don't specify something in this regard, I'm afraid we're going to wind up with lots of homegrown management UIs that force people to buy all their homenet routers from a single vendor.

There’s brief discussion of this in RFC 7368, where I recall some text was added in response to an Ops Area AD’s input, see https://tools.ietf.org/html/rfc7368#section-3.8.2

Tim

On Tue, Jul 24, 2018 at 10:59 PM, STARK, BARBARA H <bs7652@att..com<mailto:[email-masked]>> wrote:
<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, it doesn’t fall within my interpretation of the charter.
Barbara

From: homenet <[email-masked]<mailto:[email-masked]>> On Behalf Of Ted Lemon
Sent: Tuesday, July 24, 2018 5:57 PM
To: Michael Richardson <[email-masked]<mailto:[email-masked]>>
Cc: homenet <[email-masked]<mailto:[email-masked]>>
Subject: Re: [homenet] standard way of configuring homenets

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 25 Jul 2018 10:18:12 +0200 (CEST)

On Wed, 25 Jul 2018, Brian E Carpenter wrote:

> 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.

I agree. There are lots of home routers that allow you to take a 
configuration backup, that can then be restored on a different device. I 
expect there to be quite a few knobs to set on the home ISP-facing router 
for instance, regarding firewall rules, port forwards etc.

So while I do not see this as an immediate homenet concern (homenet should 
for now focus on getting the automatic plug-and-play functions correct), 
going forward I do think it would be good to look into these issues.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 25 Jul 2018 16:40:59 +0000

> > network, and configuration via a management protocol requires somebody
> > who knows what they’re doing,
> 
> (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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Jul 2018 12:55:58 -0400

Hm, possibly there's been some miscommunication here: we aren't talking
about using tools developed for managed networks for amateurishly-managed
networks.   We are talking about the problem of making it possible to do
some degree of management of homenets.   I don't think anybody is assuming
that we will just forklift in SNMP or Netconf/Yang; indeed, at least one
suggestion was to just use HNCP.   HNCP actually possesses exactly the
attack surface you are talking about if we don't have some kind of
enrollment protocol.

On Wed, Jul 25, 2018 at 12:40 PM, STARK, BARBARA H <[email-masked]> wrote:

> doesn't
> 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
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Jul 2018 13:46:52 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > who knows what they’re doing, it doesn’t fall within my interpretation
    > of the charter.

I don't think that management requires somebody who knows what they they are
doing...  :-)

I'm thinking along the lines of being able to *backup* the configuration and
restore it.   You may be right that it's out of charter regardless.

I think that the developers of homenet products need to be able to get
telemetry about what went wrong: so at the least, *we* need to be able to
debug what went wrong.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 25 Jul 2018 18:00:30 +0000

> I don't think that management requires somebody who knows what they
> they are doing...  :-)
> 

I think we could do something for config backup (and restoration) and supplying logs and statistics in a way that would not give me the heebie-jeebies (by enabling a fully-functional management interface). 
I still really like NetJSON (netjson.org) as a mechanism for supplying read-only statistics, logs, and config info. I think if we creating some custom NetJSON modules and getting a DNS-SD service name would be really simple and pretty flexible.
For backup, I think a device could create, name, and encrypt its own backup file, and would just need some place to put it. That backup store wouldn't need to be able to log into the device, otherwise configure the device, or be responsible for pulling these backups. 
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Jul 2018 14:04:59 -0400

On Wed, Jul 25, 2018 at 1:47 PM, STARK, BARBARA H <[email-masked]> wrote:

> > From: Ted Lemon
> I don't see HNCP as being usable in DDoS attacks or as being useful in
> compromising a device. It can give a device bad config info, which could
> prevent the home network from working as desired. But it can't be used for
> a Mirai-like DDoS attack. And it doesn't have the ability (yet) to
> configure login credentials for more in-depth device management. It doesn't
> supply a management interface so much as send around best effort config
> info.
>

In principle it _is_ the management interface; it's just that it's
automatic.   You can't get login credentials because there are no login
credentials.   I would expect that if we come up with a way for, say, an
app on your phone to manage the homenet, then that app would have to go
through the same sort of enrollment process that any other homenet device
would have to use (of course, the first such app might be required to
*bootstrap* the enrollment process).   The current model of having a web UI
with a default configuration password is precisely what I'd like to make
unnecessary by specifying something better.   It is this sort of UI that
has allowed things like the Mirai worm to proliferate.

> I agree with the need for some kind of enrollment to protect components of
> the homenet solution. I'd rather not rely on this enrollment to guarantee
> that components of the homenet solution cannot be used for DDoS attacks. I
> would prefer for homenet solutions to be natively incapable of being used
> in DDoS attacks.
>

That would certainly be nice.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 25 Jul 2018 17:47:38 +0000

> From: Ted Lemon 
> Hm, possibly there's been some miscommunication here: we aren't talking about using tools developed for managed networks for amateurishly-managed networks.   We are talking about the problem of making it possible to do some degree of management of homenets.   I don't think anybody is assuming that we will just forklift in SNMP or Netconf/Yang; indeed, at least one suggestion was to just use HNCP.   HNCP actually possesses exactly the attack surface you are talking about if we don't have some kind of enrollment protocol.

I don't see HNCP as being usable in DDoS attacks or as being useful in compromising a device. It can give a device bad config info, which could prevent the home network from working as desired. But it can't be used for a Mirai-like DDoS attack. And it doesn't have the ability (yet) to configure login credentials for more in-depth device management. It doesn't supply a management interface so much as send around best effort config info.

I agree with the need for some kind of enrollment to protect components of the homenet solution. I'd rather not rely on this enrollment to guarantee that components of the homenet solution cannot be used for DDoS attacks. I would prefer for homenet solutions to be natively incapable of being used in DDoS attacks.
Barbara

As a data point: providers like Comcast actively block SNMP ports because SNMP is so easy to use in DDoS attacks. (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.xfinity.com_support_articles_list-2Dof-2Dblocked-2Dports&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=s27KbgGycHKQ4PdDhbU8u3hn_hJ6V8VXhZLiP1YXI-M&s=73RoZA55LrnReb6kBTz2o8DIdaoGN0pHtadgVDGVrL8&e=)