Subject: [homenet] About Ted's naming architecture presentation and document

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Nov 2016 07:24:42 +0100

I've got three comments about the proposed naming architecture.

First point.  I feel I'm not alone in feeling uncomfortable about the
sheer breadth of this document.  I'm wondering if the main problem isn't
that it's trying to solve multiple problems, each of which is difficult in
itself:

  (1) naming within the homenet (the "epson.homenet" issue outlined by Stuart);
  (2) access to homenet devices from the Global Internet;
  (3) a management API;
  (4) probably others that I'm not yet able to identify.

I think it would be worthwile working out which of the above are doable,
which of the above this working group actually cares about enough to get
them fully specified and fully implemented.  In particular, I'm wondering
if dropping point (2) wouldn't yield a much simpler document.

Second point.  Should we define a management API, it would be a waste if
it were bound to naming.  Case in point, it has been requested in
a previous thread to be able to list the rogue wifi-enabled lightbulbs
that are on one's network, and prevent them from speaking to the Global
Internet.

Third point.  Should we define a management API (and I'm not sure we
should), I'm really not worried about getting the client app into client
devices: the first implementation would be a bunch of javascript code
that's downloaded from the router's web interface.  This implies, of
course, that the API is layered above something that Javascript can speak
(REST, as suggested by Ted, or simple RPC-over-JSON-over-HTTP(s), or RPC
over Websockets).

(Aside: which is yet another argument in favour of opportunistic encryption
in HTTP, but that's not an issue for this particular working group.)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 16:12:39 +0900

The conclusion of the presentation today was that we should define a
model for DNSSD+mDNS hybrid that will scale up to adding an
authoritative name server and doing DNSSEC, so that if you buy a bunch
of routers that do just the easy solution, you can buy one router
later that does the real deal.   Or, more likely, at least initially,
just get OpenWRT.

On Wed, Nov 16, 2016 at 3:24 PM, Juliusz Chroboczek
<[email-masked]> wrote:
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Nov 2016 17:17:36 +0900

I think publishing your lightbulb in the global DNS is generally out
of scope.   The plan is to define an architecture that is
upwards-compatible with the fancy all-singing all-dancing management
API/DNS zones model.   Yes, publishing stuff in the global DNS is out
of scope for the simple homenet naming architecture document.

On Wed, Nov 16, 2016 at 4:56 PM, Juliusz Chroboczek <[email-masked]> wrote:
>> model for DNSSD+mDNS hybrid that will scale up
>
> Thanks for the clarification, that wasn't clear to me -- there was a lot
> of discussion of management interfaces, smartphone apps, and stuff, and
> I wasn't fully awake yet.
>
> So publishing your lightbulb in the global DNS is out of scope for now?
>
> -- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Nov 2016 09:22:02 +0100

> Yes, publishing stuff in the global DNS is out of scope for the simple
> homenet naming architecture document.

I suddenly worry much less.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 10:31:52 +0900

Ted Lemon <[email-masked]> wrote:
    > I think publishing your lightbulb in the global DNS is generally out of
    > scope.

But, do you agree that publishing your home lighting controller to the DNS is
how you manage to control your lights from your phone when you are out of
wifi distance, as you roam to 3G. (I switch to 3G when I get to the front of
my rather modest driveway, as the AP is in the back of the basement)?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 11:20:13 +0900

If you read the current homenet architecture doc, you will see that there
is a hairbrained scheme for how to provide private queries for devices that
have a trust relationship with the homenet. I don't think we want to make
that information public.

On Nov 17, 2016 10:31, "Michael Richardson" <[email-masked]> wrote:

> of

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 17:04:00 +0900

Ted Lemon <[email-masked]> wrote:
    > If you read the current homenet architecture doc, you will see that
    > there is a hairbrained scheme for how to provide private queries for
    > devices that have a trust relationship with the homenet. I don't think
    > we want to make that information public.

Oh, I will look it up, as I don't recall that part.
Do you mean... RFC7368 section 3.7. (.4)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2016 17:42:03 +0900

Sorry, homenet naming architecture, not homenet architecture.   It's
an individual submission.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 17 Nov 2016 20:31:21 +0100

> wifi distance,

Yes, I didn't mean we should disallow this.  If the user wants to publish
his lightbulbs under .com, it's not our job to tell him he shouldn't.
What I was worried about was that Ted's original proposal was that he was
attempting to solve two independent and fairly doable problems with one
overly general solution that would take years to specify and implement.

I've said that before, so sorry for repeating myself: publishing a name in
the global DNS is an end-to-end application-layer issue.  If it involves
the Homenet routers or the CPEs in any way, we're doing it wrong.  The
device that wishes to be publicly named should directly contact a DNS
provider and get a lease on a suitable DNS name.  It's not rocket science,
and people like Dyn have been doing it for ages.  (By the way -- I'm not
particularly recommending Dyn's protocol, which doesn't do expiry times.)

-- Juliusz

---

From: james woodyatt <[email-masked]>
Date: Mon, 21 Nov 2016 11:34:31 -0800

> my rather modest driveway, as the AP is in the back of the basement)?

If anybody is currently shipping, or has announced plans to ship, any kind of home automation device that does this, please speak up on the mailing list. I’d like to calibrate my perhaps mistaken apprehension that nobody would seriously consider doing this. Everyone I know in this field plans to do this by providing a single public rendezvous point with high availability servers that communicate in turn to home automation controllers acting as private clients.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 21 Nov 2016 11:46:53 -0800

You mean i have to dogleg through a provider who i don't trust? For whom 
I'm the product? yuck.

Mike

On 11/21/2016 11:34 AM, james woodyatt wrote:
> On Nov 16, 2016, at 17:31, Michael Richardson <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
> If anybody is currently shipping, or has announced plans to ship, any 
> kind of home automation device that does this, please speak up on the 
> mailing list. I’d like to calibrate my perhaps mistaken apprehension 
> that nobody would seriously consider doing this. Everyone I know in 
> this field plans to do this by providing a single public rendezvous 
> point with high availability servers that communicate in turn to home 
> automation controllers acting as private clients.
>
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 21 Nov 2016 12:46:05 -0800

Hi Mike,

Yeah, you have to dog-leg through a provider that you don’t trust. Because the providers you don’t trust are the only things that home automation device manufacturers are assured by the actual existing Internet will be reachable from arbitrarily located remote mobile handsets. 

Home automation controllers and similar servers on home networks will not generally be reachable from arbitrarily located remote mobile handsets without some kind of standard solution to the problem described in section 3.4, Passive Listeners of RFC 6092, which is widely deployed now in most residential IPv6 gateways. Note also that REC-49 of that document is also widely ignored in most implementations, certainly enough implementations that it cannot serve as a dependable mechanism. It’s also important that REC-48 has mostly gone without further attention since, and that certainly adds additional complications.

Look on the bright side! Consider the possibilities that open before you when there is a 3rd-party provider that everyone can trust!

> On Nov 21, 2016, at 11:46, Michael Thomas <[email-masked]> wrote:
> 
> You mean i have to dogleg through a provider who i don't trust? For whom I'm the product? yuck.
> 
> Mike
> 
>> On Nov 16, 2016, at 17:31, Michael Richardson < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Nov 2016 18:11:35 -0500

Part of the goal of providing a naming infrastructure for the homenet
is precisely to avoid what you are describing, James.   While it's
true that consumer IoT manufacturers do seem to be using that model
now, it's a broken model, and work is underway to obsolete it in the
open source world.   Of course, that _does not_ mean that IoT devices
will be publishing their services in the public DNS, but the dogleg
model has many problems, not the least of which is that devices that
use it and control power consumption are a significant risk for
utilities.

On Mon, Nov 21, 2016 at 3:46 PM, james woodyatt <[email-masked]> wrote:
> Hi Mike,
>
> Yeah, you have to dog-leg through a provider that you don’t trust. Because
> the providers you don’t trust are the only things that home automation
> device manufacturers are assured by the actual existing Internet will be
> reachable from arbitrarily located remote mobile handsets.
>
> Home automation controllers and similar servers on home networks will not
> generally be reachable from arbitrarily located remote mobile handsets
> without some kind of standard solution to the problem described in section
> 3.4, Passive Listeners of RFC 6092, which is widely deployed now in most
> residential IPv6 gateways. Note also that REC-49 of that document is also
> widely ignored in most implementations, certainly enough implementations
> that it cannot serve as a dependable mechanism. It’s also important that
> REC-48 has mostly gone without further attention since, and that certainly
> adds additional complications.
>
> Look on the bright side! Consider the possibilities that open before you
> when there is a 3rd-party provider that everyone can trust!
>
> If anybody is currently shipping, or has announced plans to ship, any kind
> of home automation device that does this, please speak up on the mailing
> list. I’d like to calibrate my perhaps mistaken apprehension that nobody
> would seriously consider doing this. Everyone I know in this field plans to
> do this by providing a single public rendezvous point with high availability
> servers that communicate in turn to home automation controllers acting as
> private clients.
>
>
>
> --james woodyatt <[email-masked]>
>
>
>
>

---

From: james woodyatt <[email-masked]>
Date: Mon, 21 Nov 2016 16:26:18 -0800

> use it and control power consumption are a significant risk for

This goes to the heart of my criticism of the Homenet Naming Architecture draft. If there is anything in any of the Homenet working group documents or pending drafts that contradicts the recommendations of RFC 6092 that amount in practice to a prohibition against passive listeners in the home network from being reachable by arbitrary exterior hosts, then I’m not seeing it. Could you provide me with a pointer to the relevant passage in the drafts? Without that, I can’t see how there’s really a strong case for doing any of this naming architecture work.

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Nov 2016 09:12:12 +0000

On 21 Nov 2016, at 19:34, james woodyatt <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 16, 2016, at 17:31, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

There are certainly many devices I access directly in my home, e.g. webcams, media servers, but these are not real home automation devices, and not providing “mission critical” functions. They mostly work via web ports and, where IPv4-only, require an amount of port mapping shenanigans. I do have some IPv6 services running in my home that I access remotely.

The challenge with home automation is that there’s a particular need for that service to be both secure and reliable (high uptime). Obviously Mirai has highlighted the problem of insecure IoT in the home, especially through access via default passwords being left in place.

That said, there are examples of home automation companies that have stopped trading, leaving the devices in the home useless. Similarly with some “Internet toys” that require the mothership to still be in orbit for them to work. Non-proprietary devices/protocols are perhaps as important as the architecture itself.

Tim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 22 Nov 2016 15:39:56 +0100

> If there is anything in any of the Homenet working group documents or
> pending drafts that contradicts the recommendations of RFC 6092 that
> amount in practice to a prohibition against passive listeners in the
> home network from being reachable by arbitrary exterior hosts, then I’m
> not seeing it.

I think that's a very serious point.

-- Juliusz

---

From: Michael Thomas <[email-masked]>
Date: Tue, 22 Nov 2016 08:28:36 -0800

On 11/22/2016 01:12 AM, Tim Chown wrote:
> There are certainly many devices I access directly in my home, e.g. 
> webcams, media servers, but these are not real home automation 
> devices, and not providing “mission critical” functions. They mostly 
> work via web ports and, where IPv4-only, require an amount of port 
> mapping shenanigans. I do have some IPv6 services running in my home 
> that I access remotely.
>
> The challenge with home automation is that there’s a particular need 
> for that service to be both secure and reliable (high uptime). 
> Obviously Mirai has highlighted the problem of insecure IoT in the 
> home, especially through access via default passwords being left in place.
>
> That said, there are examples of home automation companies that have 
> stopped trading, leaving the devices in the home useless. Similarly 
> with some “Internet toys” that require the mothership to still be in 
> orbit for them to work. Non-proprietary devices/protocols are perhaps 
> as important as the architecture itself.

Right. Since Homenet is predicated on ipv6, we should never bake in 
expectations of doglegging that have their justifications in v4/nat. 
There are perfectly
good reasons I don't want to hand over control to some dogleg servers 
whose primary reason for being is to make me a product. I can put that 
controller
into my own home and operate it (and in fact, i do exactly that today 
even in v4-land). And homenet as standards should certainly not be 
catering to some
particular business model -- allow me to opt into being the product, 
thankyouverymuch.

Mike

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 22 Nov 2016 17:51:00 +0100

> I can put that controller into my own home and operate it

Assuming that you can control the stateful firewall that's running on the
edge routers.  Recall that the edge router is not necessarily on the local
link, and that there can be multiple edge routers.

(I see that hnet-full in OpenWRT/LEDE installs a thing called
"minimalist-pcproxy", but I have no idea what it does and whether it
handles multiple edge routers correctly.)

(In order to keep the discussion at the high intellectual level customary
for this group, I suggest that all mentions of uPNP be banned.  PCP
(formerly NAT-PMP) is the Standards Track protocol for punching holes in
stateful firewalls and NAT boxes, and unlike uPNP it actually makes
sense.)

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 22 Nov 2016 20:31:25 +0200

> handles multiple edge routers correctly.)

It does. Downside with it is that it is based on essentially non-IETF stuff (my expired draft) for figuring who to forward the requests to. PCP WG wasn’t that keen about it, and then they disbanded. Perhaps someone should adopt it here if firewall hole punching is still on the agenda (as plain PCP proxy specified in the PCP WG is not up to the multiprefix part of the task, and is also overly complex).

> stateful firewalls and NAT boxes, and unlike uPNP it actually makes

Does it? Now that I have thought about it more, I do not control all devices in my home that well to start with (hello, embedded things that talk IP), and I am not that keen to allow them to punch holes in firewall. Obviously, they can do call-home anyway (if they are not on a restricted access subnet at any rate), but it is one less vulnerable externally visible protocol implementation to worry about if they can only call outside and not have port scanners hit them.

As an anecdote, I upgraded my home infra during the last month (hello, Turris Omnia), and essentially thought about ‘do I want this piece or not’.

What made the cut from homenet/friends:

- ohybridproxy (only really scalable and sensible IPv6 rdns source that I am aware of, given nodes talk mdns)

- shsp (joke draft, but my home automation stuff still runs DNCP-based distributed computation using it)

What didn’t:

- the rest (I have few subnets, but they have also different policies in regard to each other and outside world => autoconfiguration is not on the cards).

Manual configuration = win for most things, if you are security conscious, and I try to be. 

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 22 Nov 2016 20:47:41 +0100

> It does.

Excellent.

> Downside with it is that it is based on essentially non-IETF stuff (my
> expired draft) [...]  (as plain PCP proxy specified in the PCP WG is not
> up to the multiprefix part of the task, and is also overly complex).

Thanks for the info.  I'll try to grok when I next have some hacking time.

>> [PCP] actually makes sense

> Does it?

Assuming you want to allow hole punching, PCP makes sense.  Whether you
want to allow hole punching in the first place is a separate discussion.

> Now that I have thought about it more, I do not control all devices in
> my home that well to start with (hello, embedded things that talk IP),
> and I am not that keen to allow them to punch holes in
> firewall. Obviously, they can do call-home anyway

Uh-huh.  I don't see how punching holes in the firewall is worse than
allowing access to the Global Internet.

> (if they are not on a restricted access subnet at any rate)

Exactly.  All my untrusted devices, I mean, my one untrusted device lives
on a dedicated VLAN which is carefully firewalled.

>   I am aware of, given nodes talk mdns)

Noted, thanks for the opinion.  I still don't understand how it works (who
gets port 53?  how are data from multiple links merged?), but I intend to
do my homework.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 23 Nov 2016 00:39:50 +0200

> allowing access to the Global Internet.

The recent IoT DDoS publicity is a good example; the devices that are the Mirai botnet are devices that had/have open ports facing the internet. They are not (as far as I know) contacting corrupted servers, nor is there active DNS attack ongoing, but instead IPv4 address range is being scanned and then the bad software being exploited. (Default username+password for most part in this case, but it could be equally well buffer overflow on the protocol implementation listening on that port that would be port scannable.)

It is all about reducing the attack surface. 

(Obviously having no bad software would be even better.)

> gets port 53?  how are data from multiple links merged?), but I intend to

I give dnsmasq port 53, and then have it forward queries for .home (chuckle) and my IPv4/IPv6 reverses in .arpa-land to 127.0.0.1:54 where ohp listens on my routers. (xns-ch called and wants its port but I try to resist.)

Cheers,

-Markus

---

From: james woodyatt <[email-masked]>
Date: Tue, 22 Nov 2016 15:23:40 -0800

On Nov 22, 2016, at 11:47, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Assuming you want to allow hole punching, PCP makes sense.

It only makes sense if the distinguished hole punched by the recommendations in Section 3.2.4 IPsec and Internet Key Exchange (IKE) [RFC 6092] are insufficient or unsuitable for the given application.

> Whether you want to allow hole punching in the first place is a separate discussion.

A separate, closely related discussion is whether hole punching should continue to be “opt-in” or if it should be changed to be “opt-out” (assuming it’s even possible to make such a change at this late date, but the roll-out of HOMENET systems might bring an opportunity, should we choose to take it).

I mean, it’s really quite revealing in Section 3.6 in "IPv6 Home Networking Architecture Principles" [RFC7368], which includes a long disquisition about the architecture expressly not taking any opinion on the “opt-in” or “opt-out” question, that the whole discussion gets reduced down to this fairly ambiguous sentence in Section 5.1 of “Home Networking Control Protocol” [RFC7788] to this rather unambiguous positive recommendation for filtering:

>> Accessing internal resources from external interfaces is restricted, i.e., the use of Recommended Simple Security Capabilities in Customer Premises Equipments (CPEs) [RFC6092] is RECOMMENDED.

On Nov 22, 2016, at 08:28, Michael Thomas <[email-masked]> wrote:
> 
> Right. Since Homenet is predicated on ipv6, we should never bake in expectations of doglegging that have their justifications in v4/nat. […]

I think we can safely observe that the expectation for passive listeners on unmanaged home networks to be protected by IPv6 Simple Security from receiving inbound flows from arbitrary hosts on the public Internet is not merely due to the legacy of IPv4/NAT.

During the long and heated debate over RFC 4864 and the even longer and more heated debate over RFC 6092, I would say that the IETF community really did come to the consensus that eliminating the need for NAT to provide address amplification does not entail eliminating the need for simple security at the borders of unmanaged networks. That’s pretty clear in RFC 4864, and we had the opportunity to revisit in RFC 6092, and we did not.

This argument that passive listener protection on unmanaged networks is an obsolescence left over from IPv4/NAT just doesn’t work. We had plenty of opportunities to leave it behind with IPv6 and we quite deliberately kept it. We can’t claim we didn’t know what we were doing.

> There are perfectly good reasons I don't want to hand over control to some dogleg servers […] thankyouverymuch.

And yet, we have the Internet as it has been constructed in the real world according to its deliberately planned architecture, in which most if not all passive listeners on unmanaged residential networks are expected to be protected directly by security packet filters from receiving inbound flows directly from arbitrary initiators over public routes. The architecture instead expressly calls for them to make outbound flows to some exterior service that facilitates their communications or proxies on their behalf at application layers.

That’s your dog-leg. We have it because IETF experts are afraid of the chaos entailed by allowing the riffraff to do without it too easily.

Maybe the IETF community will revisit this architecture in the next version of the Internet Protocol, but with IPv6 I have to say the matter seems well and truly decided at this point. In the meantime, with the Internet we have, it doesn’t make sense to me why we should spend our time specifying protocols for registering names of services in the global domain name system unless we have a realistic usage scenario that shows how they will be reachable directly by arbitrary public hosts.

I just don’t see how there is any such realistic scenario. Hence, I’m not sold that adopting this draft is a good idea.

---

From: james woodyatt <[email-masked]>
Date: Tue, 22 Nov 2016 17:34:57 -0800

On Nov 22, 2016, at 14:39, Markus Stenberg <[email-masked]> wrote:
> 
> The recent IoT DDoS publicity is a good example; the devices that are the Mirai botnet are devices that had/have open ports facing the internet.

Not quite, c.f. <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/ <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/>>

The vast majority of those devices were protected from receiving inbound flows over public Internet routes by the stateful filters of IPv4/NAT gateways.

p1. Those ports would not have been open and facing the Internet except they were also configured to use UPnP IGD to punch a hole through their firewall to expose their unsecured services.

p2. More importantly, they were also open and facing other compromised hosts on the same network, which were vulnerable not because they had open ports facing the Internet but because they were exposed to malware by legitimate requests to web servers at public Internet destinations.

The calls [in both cases p1 and p2] were coming from inside the house.

> It is all about reducing the attack surface.

What attack surfaces were reduced? None of them were turned on at all. And why? Because, strangely, the industry in which we work engineers so many of the systems, which ordinary people are expected to use, in a way that makes them unusable unless all the security mechanisms that reduce the attack surfaces are disabled or bypassed by default.

It’s not about reducing attack surfaces. It’s about making systems that are safe for deployment in close proximity to humans.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 22 Nov 2016 18:54:05 -0800

On Tue, Nov 22, 2016 at 5:34 PM, james woodyatt <[email-masked]> wrote:

> The recent IoT DDoS publicity is a good example; the devices that are the
> Mirai botnet are devices that had/have open ports facing the internet.
>
>
> Not quite, c.f. <https://krebsonsecurity.com/2016/10/who-makes-the-iot-
> things-under-attack/>
>
> The vast majority of those devices were protected from receiving inbound
> flows over public Internet routes by the stateful filters of IPv4/NAT
> gateways.
>

... and this knowledge is not new. The conficker paper
<https://seclab.cs.ucsb.edu/media/uploads/papers/torpig.pdf> from 2009
found that "144,236 (78.9%) of the infected machines were behind a NAT,
VPN, proxy, or firewall". We should know this by now :stateful firewalls do
not protect against malware.

It’s not about reducing attack surfaces. It’s about making systems that are
> safe for deployment in close proximity to humans.
>

+1

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 23 Nov 2016 09:07:23 +0200

> On 23 Nov 2016, at 3.34, james woodyatt <[email-masked]> wrote:
> Not quite, c.f. <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/>
> 

Interesting. I read somewhere elsewhere that upnp igd was part of the problem but not the main one.

> p1. Those ports would not have been open and facing the Internet except they were also configured to use UPnP IGD to punch a hole through their firewall to expose their unsecured services.

So the default opt-out policy of hole punching is broken.

> p2. More importantly, they were also open and facing other compromised hosts on the same network, which were vulnerable not because they had open ports facing the Internet but because they were exp…

I did not read that in that article at least. I can believe infested Windows hosts can contaminate anything near them.

> The calls [in both cases p1 and p2] were coming from inside the house.

Default drop inbound policy would have worked in the p1 case; p2 case on the other hand, the moment you have someone inside the network, you are lost, given the modern software quality.

> What attack surfaces were reduced? None of them were turned on at all. And why? Because, strangely, the industry in which we work engineers so many of the systems, which ordinary people are expecte…

At least based on my reading elsewhere, there is quite a bit of IoT hardware that actually has direct IPv4 address as well. And median time to infestation is minutes in the current IPv4 land. I also seem to recall that the ‘unpatched Windows - time to infestation’ benchmark also was minutes already ten years ago. (current Windows has saner default policies though, so I am not sure if that is applicable any more.)

> It’s not about reducing attack surfaces. It’s about making systems that are safe for deployment in close proximity to humans.

Sounds like an impossible dream then, given how prevalent the default username+password has been since 90s. Or buffer overflows. Or SQL injection attacks. All of that has been with us 20+ years and seems to be just more common, not less common, as the time goes by.

> ... and this knowledge is not new. The conficker paper from 2009 found that "144,236 (78.9%) of the infected machines were behind a NAT, VPN, proxy, or firewall". We should know this by now :stateful firewalls do not protect against malware.

There are also two other potential readings to this;

- the nodes could also move and be infected elsewhere, or

- they can make requests to the outside world with bad actor somewhere in the loop. At least earlier, the main _computer_ infection vector were essentially humans, who clicked ‘funny picture.exe’ and ignored security warnings.

IoT land, there is no human in the loop, so there is bit more hope, given software quality is sufficient, as people do not have access to run the ‘funny picture.exe’ as root on the devices.

Cheers,

-Markus

---

From: Ca By <[email-masked]>
Date: Wed, 23 Nov 2016 07:23:31 -0800

On Tue, Nov 22, 2016 at 11:07 PM, Markus Stenberg <[email-masked]>
wrote:

> >> The recent IoT DDoS publicity is a good example; the devices that are
> the Mirai botnet are devices that had/have open ports facing the internet.
> > p1. Those ports would not have been open and facing the Internet except
> they were also configured to use UPnP IGD to punch a hole through their
> firewall to expose their unsecured services.
>
> > p2. More importantly, they were also open and facing other compromised
> hosts on the same network, which were vulnerable not because they had open
> ports facing the Internet but because they were exposed to malware by
> legitimate requests to web servers at public Internet destinations.
>
> I did not read that in that article at least. I can believe infested
> Windows hosts can contaminate anything near them.
>
> Default drop inbound policy would have worked in the p1 case; p2 case on
> the other hand, the moment you have someone inside the network, you are
> lost, given the modern software quality.
>
> > What attack surfaces were reduced? None of them were turned on at all.
> And why? Because, strangely, the industry in which we work engineers so
> many of the systems, which ordinary people are expected to use, in a way
> that makes them unusable unless all the security mechanisms that reduce the
> attack surfaces are disabled or bypassed by default.
>
> At least based on my reading elsewhere, there is quite a bit of IoT
> hardware that actually has direct IPv4 address as well. And median time to
> infestation is minutes in the current IPv4 land. I also seem to recall that
> the ‘unpatched Windows - time to infestation’ benchmark also was minutes
> already ten years ago. (current Windows has saner default policies though,
> so I am not sure if that is applicable any more.)
>
> > It’s not about reducing attack surfaces. It’s about making systems that
> are safe for deployment in close proximity to humans.
>
> Sounds like an impossible dream then, given how prevalent the default
> username+password has been since 90s. Or buffer overflows. Or SQL injection
> attacks. All of that has been with us 20+ years and seems to be just more
> common, not less common, as the time goes by.
>
> > ... and this knowledge is not new. The conficker paper from 2009 found
> that "144,236 (78.9%) of the infected machines were behind a NAT, VPN,
> proxy, or firewall". We should know this by now :stateful firewalls do not
> protect against malware.
>
> - they can make requests to the outside world with bad actor somewhere in
> the loop. At least earlier, the main _computer_ infection vector were
> essentially humans, who clicked ‘funny picture.exe’ and ignored security
> warnings.
>
> IoT land, there is no human in the loop, so there is bit more hope, given
> software quality is sufficient, as people do not have access to run the
> ‘funny picture.exe’ as root on the devices.
>
>
Yeh, we took the human out of the loop, but with UPnP and PCP, we gave the
malware an API to open the gate.

That said, given HOMENET's charter to be the ideal network we always wanted
without the technical debt, i suggest HOMENET take a strong stance and
reject "crunchy core, soft middle" security approach.  Meaning, assuming
that some other device is going to do security for you and you can leave a
default password telnet open.... that idea needs to die.

We need to make sure that HOMENET does not have a diagram that says
"security done here" with an arrow pointed at the gateway.  HOMENET needs
to specifically mandate all nodes have sane security, and part of that is
ripping off the band-aid / security blanket of "stateful firewall"... the
popular notion that stateful firewall does anything meaningful is very
damaging to ecosystem... mostly because it makes security the
responsibility of some other node.... which is not ok.

CB

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Nov 2016 07:31:39 -0800

On 11/22/2016 06:54 PM, Lorenzo Colitti wrote:
> On Tue, Nov 22, 2016 at 5:34 PM, james woodyatt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     The recent IoT DDoS publicity is a good example; the devices that
>>     are the Mirai botnet are devices that had/have open ports facing
>>     the internet.
>
>     Not quite, c.f.
>     <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/
>     <https://krebsonsecurity.com/2016/10/who-makes-the-iot-things-under-attack/>>
>
>     The vast majority of those devices were protected from receiving
>     inbound flows over public Internet routes by the stateful filters
>     of IPv4/NAT gateways.
>
>
> found that "144,236 (78.9%) of the infected machines were behind a 
> NAT, VPN, proxy, or firewall". We should know this by now :stateful 
> firewalls do not protect against malware.
>
>     It’s not about reducing attack surfaces. It’s about making systems
>     that are safe for deployment in close proximity to humans.
>
>
> +1

I'm glad I'm not the only one who is somewhat dubious of the importance 
of the All Mighty Maginot^H^H^H^H^H^HFirewall in this day and age.
Trivial mobility (eg, phones, etc), for one, really launches big old 
rocks at a firewall's assumption of We and They.

Is there some set of standards/bcp's that describe how, say, a light 
bulb controller can create a completely private network for the light bulbs
that is specifically not routed to the Internet, where that the light 
bulb controller acts as an ALG to those bulbs? That seems more of what I 
want than where
each individual light bulb has to hope that some firewall protects it 
from the mean old internets.

Mike

---

From: Tim Chown <[email-masked]>
Date: Wed, 23 Nov 2016 15:49:30 +0000

On 23 Nov 2016, at 15:23, Ca By <[email-masked]<mailto:[email-masked]>> wrote:

<snip>

That said, given HOMENET's charter to be the ideal network we always wanted without the technical debt, i suggest HOMENET take a strong stance and reject "crunchy core, soft middle" security approach.  Meaning, assuming that some other device is going to do security for you and you can leave a default password telnet open.... that idea needs to die.

We need to make sure that HOMENET does not have a diagram that says "security done here" with an arrow pointed at the gateway.  HOMENET needs to specifically mandate all nodes have sane security, and part of that is ripping off the band-aid / security blanket of "stateful firewall"... the popular notion that stateful firewall does anything meaningful is very damaging to ecosystem... mostly because it makes security the responsibility of some other node.... which is not ok.

Part of the “problem” is that the Homenet security architecture is not yet documented. It was somewhat punted during the discussions towards RFC 7368, with Section 3.6 mentioning RFC 6092 and RFC 4864, without being prescriptive - https://tools.ietf.org/html/rfc7368#section-3.6.

I have my doubts that any attempt to flesh that out further now would reach consensus, but given we’ve now moved on quite a way, e.g. knowing we have HNCP, Babel, etc, and having witnessed Mirai, it might be worth a try. Something for the chairs…?

Tim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 23 Nov 2016 16:59:53 +0100

> IoT land [...] there is bit more hope

Joke, right?

---

From: Ray Bellis <[email-masked]>
Date: Wed, 23 Nov 2016 16:05:38 +0000

On 23/11/2016 15:49, Tim Chown wrote:

> I have my doubts that any attempt to flesh that out further now would
> reach consensus, but given we’ve now moved on quite a way, e.g. knowing
> we have HNCP, Babel, etc, and having witnessed Mirai, it might be worth
> a try. Something for the chairs…?

The Chairs think it would be a fine idea.

However we are short of volunteers to take on the work...

Ray

---

From: Tim Coote <[email-masked]>
Date: Wed, 23 Nov 2016 17:34:09 +0000

> On 23 Nov 2016, at 15:59, Juliusz Chroboczek <[email-masked]> wrote:
> 

Do the Security Economics need thinking about here: what are the threats and who’s best placed to confirm that some set of computers and services are safe and working correctly, how are they incentivised to behave ‘correctly’?

It would be possible to externalise this cost and say that it’s a legal or commercial issue. But wouldn’t it be sensible to at least state some security related assumptions, and maybe document an initial view of the threats and impacted stakeholders (e.g. to highlight risks to third parties that the likes of Mirai present)?

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 Nov 2016 19:15:43 +0100

Hi,

> That said, given HOMENET's charter to be the ideal network we always wanted without the technical debt, i suggest HOMENET take a strong stance and reject "crunchy core, soft middle" security approa…

This.  +1.  And some.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 23 Nov 2016 20:41:08 +0100

> it doesn’t make sense to me why we should spend our time specifying
> protocols for registering names of services in the global domain name
> system unless we have a realistic usage scenario that shows how they
> will be reachable directly by arbitrary public hosts.

Agreed.

> I just don’t see how there is any such realistic scenario. Hence, I’m
> not sold that adopting this draft is a good idea.

I believe that Ted has now clarified that the next version of his draft
will focus solely on naming within the home.  Perhaps I'm optimistic, but
it looks to me like we're slowly converging towards consensus on doing
naming in the home only and ignoring the issues of naming in the Global
Internet.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 23 Nov 2016 20:45:41 +0100

> I give dnsmasq port 53, and then have it forward queries for .home
> (chuckle) and my IPv4/IPv6 reverses in .arpa-land to 127.0.0.1:54 where
> ohp listens on my routers.

Ok, makes sense (except for the choice of 54).  Two more questions:

  - who merges data from multiple links?  (I'd wish that the hybrid
    proxies compute a minimal spanning tree and perform peer-to-peer
    magic, but I suspect you're generating a config file dynamically
    and restarting dnsmasq whenever the set of hybrid proxies changes.)

  - who speaks mDNS?  The Hybrid proxies?  Or do they communicate with
    a dedicated mDNS speaker?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 24 Nov 2016 07:43:43 +0200

>    and restarting dnsmasq whenever the set of hybrid proxies changes.)

There is no need for merging, there are only few zones. They are all in DNS-SD browse/legacy browse path, and also in DNS search path. The configuration is actually static in my case. The benefit of merging is limited as there are only few subnets.

>    a dedicated mDNS speaker?

ohybridproxy is not a mDNS implementation. I did one once ( https://github.com/fingon/hnet-core ) and later on decided it was a bad idea. ohp uses patched version of Apple’s mdnsd  ( https://github.com/fingon/mDNSResponder ) for heavy lifting.
I haven’t recently checked, but at least at the time Apple’s UNIX version of mDNSResponder was essentially broken but I fixed the few bugs that bothered me when developing ohp.

Cheers,

-Markus

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Nov 2016 09:28:36 +0000

On 23 Nov 2016, at 19:45, Juliusz Chroboczek <[email-masked]<mailto:[email-masked]>> wrote:

- ohybridproxy (only really scalable and sensible IPv6 rdns source that
I am aware of, given nodes talk mdns)

In dnssd we have the “stitching” topic on our plate, around operation of dns-sd in unmanaged multi-link networks.  So this is timely discussion.

We’re beginning work on a BCP for the use of the discovery/advertising proxy in enterprise/campus networks, where there is administrative configuration, and scalability is a concern. The stitching topic would likely form part of a corresponding BCP for unmanaged operation, as per a multi-link homenet.

The proxies ask about (discover) services on the link(s) they serve on behalf of the (remote) querier. For general info on how dns-sd works, see https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05, Section 5 in particular.

For info the “hybrid proxy” has been renamed the “discovery proxy”, which will be reflected in the -06 draft, and Stuart will be publishing a separate “advertising proxy”, which will allow (remote) proxy advertisements of services in addition to proxy discovery of them.  For more info on that, see https://www.ietf.org/proceedings/97/slides/slides-97-dnssd-hybrid-proxy-00.pdf

The other thing to be aware of is that there is “long lived query” support for the proxies being defined via the DNS Push Notifications and DNS Session Signalling drafts (https://tools.ietf.org/html/draft-ietf-dnssd-push-09 and https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-01). These allow clients to get timely notifications of changes.

Tim

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 24 Nov 2016 10:36:02 +0100

> There is no need for merging, there are only few zones. They are all in
> DNS-SD browse/legacy browse path, and also in DNS search path. The
> configuration is actually static in my case. The benefit of merging is
> limited as there are only few subnets.

I'm probably just being slow, please bear with me.  There's one hybrid
proxy on each link, right?  Each of these only learns about the mDNS
announcements done on this particular link, right?  Dnsmasq must somehow
get the union of all of these data, right?

So is dnsmasq speaking to localhost:54 only, and localhost:54 somehow
learns all the data, or is dnsmasq speaking too foo:54 for all values of
foo?  If the latter (which I suspect), how does hnetd communicate the list
of foos to dnsmasq?

> ohp uses patched version of Apple’s mdnsd [...] for heavy lifting.

Ack.  I really need to read your code at some point.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 24 Nov 2016 10:47:16 +0100

> In dnssd we have the “stitching” topic on our plate, around operation of dns-sd
> in unmanaged multi-link networks.  So this is timely discussion.

Aha, excellent.

> We’re beginning work on a BCP for the use of the discovery/advertising proxy in
> enterprise/campus networks, where there is administrative configuration, and
> scalability is a concern. The stitching topic would likely form part of a
> corresponding BCP for unmanaged operation, as per a multi-link homenet.

I could be wrong, but I believe that stitching could be just as useful in
managed networks.  I'm not especially enthused by the solution suggested
in Section 5.1 of dnssd-hybrid-05 (making a single hybrid proxy ubiquitous
through link-layer magic).

> The proxies ask about (discover) services on the link(s) they serve on behalf
> of the (remote) querier. For general info on how dns-sd works, see
> https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-05, Section 5 in
> particular.

The draft suggests that the hybrid proxy does not speak mDNS, but that it
gets the information from an existing mDNS cache (last paragraph of 5.1).
It appears that Markus' OpenWRT implementation follows this model.  As
a general rule, I'm not overly keen on solutions that require dependencies
between daemons, but Markus and Steven have a good track record of beating
such constructs into compliance.

> For more info on that, see
> https://www.ietf.org/proceedings/97/slides/slides-97-dnssd-hybrid-proxy-00.pdf

Will do, thanks.

> The other thing to be aware of is that there is “long lived query” support for
> the proxies being defined via the DNS Push Notifications and DNS Session
> Signalling drafts (https://tools.ietf.org/html/draft-ietf-dnssd-push-09 and
> https://tools.ietf.org/html/draft-ietf-dnsop-session-signal-01).

Oh my.  Is that meant to be optional?

Thanks for all the info,

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 24 Nov 2016 12:59:35 +0200

> On 24 Nov 2016, at 11.28, Tim Chown <[email-masked]> wrote:

For the record, 'stitching' combined with mdns is really hard. One of the reasons I gave up on my original mdns proxy designs, which incorporated stitching. 

As long as there is no conflict, it is trivial, but dealing with conflict in user-friendly manner is essentially impossible in presence of any resource name rewriting (and that inevitably happens when hybrid proxy is involved).

mdns conflict precedence may change as result of rewrites -> have to do really ugly things to force one party to rename, if you want the ground truth to match what is presented in the stitched zone. If you do not want that, then the problem becomes just matter of providing long-lived name rewrites if and only if conflicts are detected, and it is not much more fun either.

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 24 Nov 2016 13:01:33 +0200

> On 24 Nov 2016, at 11.36, Juliusz Chroboczek <[email-masked]> wrote:
> 

When done dynamically (i.e. by hnetd), dnsmasqs are configured to:

- forward requests for non-local zones to nodes where they are based (based on HNCP state)
- forward locally to the ohp local zones

In my static config (which is 'official' HNCP free), I just have configuration files which mirror this idea.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 25 Nov 2016 16:09:30 +0100

I think I now see how the pieces fit.  Thanks, Markus.

-- Juliusz

---

From: james woodyatt <[email-masked]>
Date: Mon, 28 Nov 2016 12:11:40 -0800

On Nov 23, 2016, at 08:05, Ray Bellis <[email-masked]> wrote:
>> I have my doubts that any attempt to flesh that out further now would reach consensus,[…]

So do I, and these doubts were amplified by the recent discussion here following my objection to adopting I-D.lemon-homenet-naming-architecture on the grounds that we have no clear security architecture to provide for passive listeners on unmanaged networks receiving inbound flows from unauthenticated hosts over public Internet routes. [*] In fact, if we were to search for the consensus to write one, I suspect it would settle on strongly prohibiting all such communications. [**]

>>  Something for the chairs…?
> 
> However we are short of volunteers to take on the work…

“Prepare to waste a lot of time accomplishing nothing,” says the little voice in my head. Maybe if my forecast for reaching consensus on the security architecture seemed less gloomy.

[*] To be pedantic, we *do* have a security architecture, but it’s far from clear and it's not recommended anywhere: RFC 6092 provides the distinguished inbound flow exception for IPsec and IKE. I doubt anyone believes that could be a feature of any security architecture that will be adopted by industrial policy, but if the chairs are interested in tilting at windmills, I might be able to find time to write a short draft to clarify how it would work.

[**] Before anyone asks, the answer is "No, I will not write a security architecture draft for HOMENET that prohibits passive listeners on unmanaged networks receiving inbound flows from unauthenticated hosts over public Internet routes. If that’s how it should unfold, then I’m confident the working group will find somebody with the necessary moral flexibility."

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 28 Nov 2016 13:32:51 -0800

On Mon, Nov 28, 2016 at 12:11 PM, james woodyatt <[email-masked]> wrote:

> [**] Before anyone asks, the answer is "No, I will not write a security
> architecture draft for HOMENET that prohibits passive listeners on
> unmanaged networks receiving inbound flows from unauthenticated hosts over
> public Internet routes. If that’s how it should unfold, then I’m confident
> the working group will find somebody with the necessary moral flexibility."
>

I don't think there is any point writing such a document since it is
unlikely gain consensus anyway.