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

[Ray Hunter (v6ops)]

james woodyatt wrote:
On Nov 16, 2016, at 17:31, Michael Richardson > wrote:


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)?


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 >



RFC3724.

>  End user choice and empowerment, integrity of service, support for 
trust, and "good network citizen behavior" are all properties that have 
developed as a consequence of the end-to-end principle.


Rendezvous points are themselves an attack vector/ anti-privacy snooping 
vector/ commercial lock-in/ convenience, depending on your point of view.


So please let's empower the end user to either "opt in" or "opt out".

--
regards,
RayH

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

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

[Markus Stenberg]

On 22 Nov 2016, at 18.51, Juliusz Chroboczek  wrote:
>> 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.)

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

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

> 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

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

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

[Michael Thomas]

On 11/22/2016 01:12 AM, Tim Chown wrote:
On 21 Nov 2016, at 19:34, james woodyatt > wrote:


On Nov 16, 2016, at 17:31, Michael Richardson > wrote:


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)?


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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Juliusz Chroboczek]

> 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

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

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

[Tim Chown]

On 21 Nov 2016, at 19:34, james woodyatt 
> wrote:

On Nov 16, 2016, at 17:31, Michael Richardson 
> wrote:

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)?

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.

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

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

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

[james woodyatt]

On Nov 21, 2016, at 15:11, Ted Lemon  wrote:
> 
> 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.

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.


--james woodyatt >



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

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

[Ted Lemon]

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  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!
>
> On Nov 21, 2016, at 11:46, Michael Thomas  wrote:
>
> 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  wrote:
>
>
> 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)?
>
>
> 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 
>
>
>
>
> ___
> 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] About Ted's naming architecture presentation and document

[james woodyatt]

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  wrote:
> 
> 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 < 
>> mcr+i...@sandelman.ca 
>> > wrote:
>>> 
>>> 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)?
>> 
>> 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 >



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

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

[Michael Thomas]

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 > wrote:


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)?


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 >





___
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] About Ted's naming architecture presentation and document

[Juliusz Chroboczek]

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

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

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

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

[Michael Richardson]

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

-- 
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





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

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

[Ted Lemon]

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"  wrote:

>
> Ted Lemon  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 , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Michael Richardson]

Ted Lemon  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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





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

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

[Ted Lemon]

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
 wrote:
> 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
>
> ___
> 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