Re: [homenet] homenet: what now? ... next?

[Michael Richardson]

Michael Richardson  wrote:
> There is significant effort to isolate IoT devices on seperate L2s via
> what in the enterprise switch space is called MAC-based-VLANs.  The
> only devices that "move" in such a network are the laptops and mobile
> phones, and both could easily take on a variety of mechanisms including
> things like off-link /128s.

let me clarify two things:

1) the other (IoT) devices could "roam" between access points, but they don't,
   because they are attached to walls, etc.

2) none of the mDNS naming that a flat L2 enables will work because of the 
firewalling,
   so they need the naming issues fixed in the way that Ted is doing, and
   once that's fixed there is no reason for them to need a flat L2.

--
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] homenet: what now? ... next?

[Stephen Farrell]

Thanks Michael,

More such input is very welcome! As chairs we'll try ask
again in a bit, but it'll be the same questions basically
so answering now is just as good:-)

On 23/04/2019 22:40, Michael Richardson wrote:
> I think that perhaps the naming work could move to DNSSD WG if closing down
> the WG was important.

Two things on that: a) I'd not thought about moving work
to dnssd, will check it out a bit though, (I believe I may
know one of the chairs:-) and b) closing the WG isn't a
goal, it's just an option, if that's what WG participants
(or the lack thereof) indicate is the right thing.

Cheers,
S.


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] homenet: what now? ... next?

[Michael Richardson]

Stephen Farrell  wrote:
> (5) it's fine stuff, but IMO not going to be used, so
> there's not much point in producing RFCs

> (6) not sure at the moment,
> maybe the WG should go quiescent for a while 'till we know more

After having various homenet threads in my inbox for 6 weeks, I've been
through them, and through Ted's marketing requirements draft.

My feeling is (6), until we are sure about (5).
Your list is unclear what "it" is, I think it might naming, but it might be
bigger.  I think that we should wait a bit longer.

My take is that wifi-roaming across a big house problem has been solved in
proprietary spaces for those that have this problem, and they are unlikely to
replace their solution with the WiFi easyMesh one.  easyMesh may show up
openWRT thanks to prpl, and it might become ubiquitously available available,
just in time to not be used, because the last thing anyone wants from a
home network security point of view is every IoT device on the same L2.

There is significant effort to isolate IoT devices on seperate L2s via
what in the enterprise switch space is called MAC-based-VLANs.  The only
devices that "move" in such a network are the laptops and mobile phones, and
both could easily take on a variety of mechanisms including things like
off-link /128s. 

I joined HOMENET (and spent personal money attending the first interim
meeting in PHL) because I saw HOMENET as an attempt to get rid of the stupid
L2 tricks that IPv4 scarcity forced people into.   I recognize the often
futility of trying to lead industry with specifications. In the homenet
case, I thought a few major vendors were committed, but I was wrong.

I think that perhaps the naming work could move to DNSSD WG if closing down
the WG was important.  At least if we had one WG then there potential
scheduling conflict would reduced.

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




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

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Juliusz Chroboczek  writes:

>> PIE [...] lends itself better for implementation in existing hardware,
>> or hardware with small modification.
>
> Could one of you please explain why?

With the caveat that I have never worked with any of this hardware, this
is my understanding:

Basically, you can re-use the drop mechanism from RED and use the PIE
algorithm as a (better) way to control the setpoints. This makes it
possible to retrofit it in existing hardware. In fact I believe you can
implement PIE entirely in the (software) control plane on (a lot of)
gear that already knows how to do RED.

-Toke

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

Re: [homenet] homenet: what now? ... next?

[Mikael Abrahamsson]

On Fri, 15 Mar 2019, Juliusz Chroboczek wrote:


PIE [...] lends itself better for implementation in existing hardware,
or hardware with small modification.


Could one of you please explain why?


Packet accelerators work either by completely autonomously forwarding 
packet without CPU involvement, or it works by flow offload. This 
basically means that on this kind of hardware if you tcpdump packets 
you'll see the first TCP handshake packets and then kernel sees nothing. 
It's now offloaded to the packet forwarding hardware, including all 
queueing decisions.


I am not an expert on exact implementations, but WRED is available on a 
lot of platforms. PIE seems to be taking a stance in WRED and adding a bit 
of control logic on top of it, and that's that. It means PIE has a 
possibility to be retrofitted onto older hardware.


FQ part of FQ_CODEL means you need to have a lot of queues, and you need 
to L4 hash onto these different queues. That's just not possible on a lot 
of HW.


I don't know if CODEL can be retrofitted onto WRED style HW, but I don't 
think so.


My observation has been that the bufferbloat movement has focused on 
academic excellence and making this work on the platforms they have 
available to them. Nothing wrong with that and the results are great, it's 
just not applicable to a lot of equipment out there that it should be 
applicable to.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> PIE [...] lends itself better for implementation in existing hardware,
> or hardware with small modification.

Could one of you please explain why?

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

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote:
>
>> You're right that packet accelerators complicate things a bit. I'm not 
>> entirely convinced that the "doesn't lend itself to FQ-CoDel and the 
>> rest of the mechanisms the bufferbloat movement has gravitated towards" 
>> actually *has* to be true, but it's harder to do a proof of concept 
>> since the barrier to entry for hardware development is higher. So I 
>> doubt anything is likely to happen here unless someone with the 
>> resources to do hardware development steps up.
>
> The people with hardware experience want to do PIE, because it lends
> itself better for implementation in existing hardware, or hardware
> with small modification.
>
> Sometimes it's better to accept non-perfect more easily implementable
> solutions that solves most of the problem space, instead of aiming for
> the "perfect one" and getting nothing.

Absolutely, I'm all for that. But even something that is as
retrofitable[0] as PIE is not getting implemented... So then what to do?
This makes it difficult to motivate spending more resources on doing
more work in this area... :/

-Toke

[0] "Retrofitable" is totally a word...

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

Re: [homenet] homenet: what now? ... next?

[Mikael Abrahamsson]

On Thu, 14 Mar 2019, Toke Høiland-Jørgensen wrote:

You're right that packet accelerators complicate things a bit. I'm not 
entirely convinced that the "doesn't lend itself to FQ-CoDel and the 
rest of the mechanisms the bufferbloat movement has gravitated towards" 
actually *has* to be true, but it's harder to do a proof of concept 
since the barrier to entry for hardware development is higher. So I 
doubt anything is likely to happen here unless someone with the 
resources to do hardware development steps up.


The people with hardware experience want to do PIE, because it lends 
itself better for implementation in existing hardware, or hardware with 
small modification.


Sometimes it's better to accept non-perfect more easily implementable 
solutions that solves most of the problem space, instead of aiming for the 
"perfect one" and getting nothing.


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote:
>
>> Since you seem to be pretty up to date on the ISP-level CPE offerings, 
>> just out of curiosity: Do any of these fancy ARM boxes include actual 
>> fixes for bufferbloat? :)
>
> Short answer, no.
>
> Bufferbloat isn't on the radar of any product managers I have talked
> to. Cable Labs is the only organisation that seems to do anything
> about this that I have seen.

Right, yeah, that's what I thought. :/

> I have made statements previously in that context of most newer higer
> end devices having packet accelerators which doesn't lend itself to
> FQ_CODEL and the rest of the mechanisms the bufferbloat movement has
> gravitated towards, but I still feel what I said wasn't really
> accepted and "taken in".

Well, for my part I have mentally filed this under "vendors don't care",
which has been my impression the whole time (with a few exceptions).
It's terribly frustrating, but it's not like there's anything I can
really do about it, so I've more or less resigned myself to this.

You're right that packet accelerators complicate things a bit. I'm not
entirely convinced that the "doesn't lend itself to FQ-CoDel and the
rest of the mechanisms the bufferbloat movement has gravitated towards"
actually *has* to be true, but it's harder to do a proof of concept
since the barrier to entry for hardware development is higher. So I
doubt anything is likely to happen here unless someone with the
resources to do hardware development steps up.

But anyway, thanks for confirming by suspicions :)

-Toke

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

Re: [homenet] homenet: what now? ... next?

[Mikael Abrahamsson]

On Wed, 13 Mar 2019, Toke Høiland-Jørgensen wrote:

Since you seem to be pretty up to date on the ISP-level CPE offerings, 
just out of curiosity: Do any of these fancy ARM boxes include actual 
fixes for bufferbloat? :)


Short answer, no.

Bufferbloat isn't on the radar of any product managers I have talked to. 
Cable Labs is the only organisation that seems to do anything about this 
that I have seen.


I have made statements previously in that context of most newer higer end 
devices having packet accelerators which doesn't lend itself to FQ_CODEL 
and the rest of the mechanisms the bufferbloat movement has gravitated 
towards, but I still feel what I said wasn't really accepted and "taken 
in".


--
Mikael Abrahamssonemail: swm...@swm.pp.se___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Toke Høiland-Jørgensen]

Mikael Abrahamsson  writes:

> On Fri, 1 Mar 2019, Michael Richardson wrote:
>
>> For the last 10 to 15 years the ISP-provided home router has come to
>> dominate the market, with the belief by the ISPs that this is a MUST
>> that they control the device. Many (but not all) at the IETF do not
>> share this view, but most non-technical users see the ISP provided
>> router is simply saving the trip to BestBuy, rather than an
>> abdication of control over their home. If this trend continues, then
>> I believe that ISPs (residential IAPs) will come to want to control
>> all IoT devices in the home -- because security -- telling
>> residential customers what they can and not connect.
>
> I have data from some ISPs here pointing to 1% of the customers
> setting the media converter/router into bridge mode and providing
> their own HGW. Most people just keep whatever the ISP provided them
> with. Looking at the SSIDs I see, typically people don't even change
> the SSIDs/passwords from what came out of the box.
>
> A multi-router home isn't on the product managers radar. Their biggest
> issue right now, is customers complaining about bad service and most
> of the time this is related to bad wifi for the last 0-30 meters of
> access to the end-user device.
>
> If HOMENET somehow could help solve that problem (diagnosing bad wifi
> and helping the ISP/customer figure out what's wrong and what needs to
> be done) then HOMENET might get onto the radar and be of interest.
>
> The good thing is that the HGW is going from an unloved cost-cut
> necessity into a more important device that is a lot higher end
> device. It's gone from a 2-4MB flash / 16 MB RAM device, to nowadays
> often having 128-512MB RAM and 32-128MB flash (or even more). It now
> also is more likely to have aN ARM processor which is several times
> faster than the devices of 5-10 years ago. A negative though, is that
> it's also very likely to contain a packet accelerator that is quite
> constrained in what it can and can't do acceleration of. This might
> make some use-cases harder to achieve. Speeds have gone up and
> nowadays having 4x4 wifi chips in there that'll in practice support
> actual transport payload speeds of upwards of 1 gigabit/s on wifi
> isn't uncommon. We're also now seeing devices with even higher port
> speeds than 1GE, but that might take a bit longer to reach wider
> adoption.

Since you seem to be pretty up to date on the ISP-level CPE offerings,
just out of curiosity: Do any of these fancy ARM boxes include actual
fixes for bufferbloat? :)

-Toke

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

Re: [homenet] homenet: what now? ... next?

[Mikael Abrahamsson]

On Fri, 1 Mar 2019, Michael Richardson wrote:


For the last 10 to 15 years the ISP-provided home router has come to dominate
the market, with the belief by the ISPs that this is a MUST that they control
the device.  Many (but not all) at the IETF do not share this view, but most
non-technical users see the ISP provided router is simply saving the trip to
BestBuy, rather than an abdication of control over their home.   If this
trend continues, then I believe that ISPs (residential IAPs) will come to
want to control all IoT devices in the home -- because security -- telling
residential customers what they can and not connect.


I have data from some ISPs here pointing to 1% of the customers setting 
the media converter/router into bridge mode and providing their own HGW. 
Most people just keep whatever the ISP provided them with. Looking at the 
SSIDs I see, typically people don't even change the SSIDs/passwords from 
what came out of the box.


A multi-router home isn't on the product managers radar. Their biggest 
issue right now, is customers complaining about bad service and most of 
the time this is related to bad wifi for the last 0-30 meters of access 
to the end-user device.


If HOMENET somehow could help solve that problem (diagnosing bad wifi and 
helping the ISP/customer figure out what's wrong and what needs to be 
done) then HOMENET might get onto the radar and be of interest.


The good thing is that the HGW is going from an unloved cost-cut necessity 
into a more important device that is a lot higher end device. It's gone 
from a 2-4MB flash / 16 MB RAM device, to nowadays often having 128-512MB 
RAM and 32-128MB flash (or even more). It now also is more likely to have 
aN ARM processor which is several times faster than the devices of 5-10 
years ago. A negative though, is that it's also very likely to contain a 
packet accelerator that is quite constrained in what it can and can't do 
acceleration of. This might make some use-cases harder to achieve. Speeds 
have gone up and nowadays having 4x4 wifi chips in there that'll in 
practice support actual transport payload speeds of upwards of 1 gigabit/s 
on wifi isn't uncommon. We're also now seeing devices with even higher 
port speeds than 1GE, but that might take a bit longer to reach wider 
adoption.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 8, 2019, at 7:48 AM, Juliusz Chroboczek mailto:j...@irif.fr>> wrote:
>> (a) work on simple naming
> 
> I think that this work should be stalled until we have an implementation
> to play with and make some in vivo experiments.  (Experience shows that
> the best way to break a protocol is to give an implementation to Dave.)

We have a working dnssd discovery proxy and client.   What we don’t have is 
those things connected via hncpd.   That is one of the things I would like to 
work on at the hackathon, if there is interest.

>> (We also have a chartered work item [4] on security that has seen no
>> progress but you can comment on that as item (c) if you like;-)
> 
> Some pointers for the rare people who don't spend most of their leisure
> time reading Internet-Drafts:
> 
> - HNCP is based on DNCP, which includes a security mechanism designed to
>   provide authenticity, integrity and confidentiality of the HNCP data:
> 
>   RFC 7525 Section 8
> 
>   I believe that this is implemented in hnetd.  (Yeah, Markus and
>   Stephen did some remarkable work.)

I had indeed missed this—thanks for pointing it out.   However, I have no idea 
how to configure it with existing software.   This is also something I’d like 
to work on at the hackathon: can we actually use this mechanism?   Can we come 
up with a way to set it up in OpenWRT that people who are not networking grad 
students can deploy?

> - Babel has two security mechanisms:
> 
>   https://tools.ietf.org/html/draft-ietf-babel-hmac 
> 
>   https://tools.ietf.org/html/draft-ietf-babel-dtls 
> 
> 
>   There appear to be no standards-track key distribution and rotation
>   protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
>   to be the norm), so a natural question is whether HNCP could serve
>   this purpose, or whether it would be better to use a dedicated key
>   distribution and rotation mechanism.
> 
> - RFC 3971 Section 6 says the following:
> 
>  To protect Router Discovery, SEND requires that routers be
>  authorized to act as routers.  This authorization is provisioned in
>  both routers and hosts.
> 
>   Since hosts don't participate in HNCP, it is not clear if HNCP can be
>   used as a SEND trust anchor.  I believe there's the same issue with
>   securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).

HNCP can’t be used by hosts to establish trust, as currently specified.   We 
don’t really have an answer to the host enrollment problem at present, 
unfortunately.___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 8, 2019, at 8:36 AM, Juliusz Chroboczek  wrote:
> I think this protocol has reached the point where any further paper work
> will be counter-productive until somebody tries their hand at implementing
> it.

Which protocol?

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

>> I think that this work should be stalled until we have an implementation
>> to play with and make some in vivo experiments. 

> I'm not sure if by "stalled" you mean sticking with the plan above, or
> something else

I'm concerned about two things:

  - if you're not implementing yourself, everything seems easy, and you
end up with an overly complex design;
  - once you've spent a lot of time on a paper protocol, you're unwilling
to change things even when the implementation work indicates they're
broken, so you end up with a design that is not only overly complex,
but doesn't work very well.

I think this protocol has reached the point where any further paper work
will be counter-productive until somebody tries their hand at implementing
it.

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Stephen Farrell]

Hiya,

Given the level of list inactivity, it's actually really
helpful that you took the time to re-tx those points!

One clarifying question below...

On 08/03/2019 12:48, Juliusz Chroboczek wrote:
> Hi Stephen,
> 
> Sorry if I'm repeating myself -- I've already expressed the opinions
> below, both at the mike and on the list.
> 
>> (a) work on simple naming
> 
> I think that this work should be stalled until we have an implementation
> to play with and make some in vivo experiments. 

Our (chairs), plan for that has been to try help the WG get the
draft to the point where one would normally do a WGLC and to then
hold off on that WGLC, waiting for the kind of implementation
experience you mention. Given the level (i.e., lack) of engagement
though, I'm wondering if that's still a viable plan, despite the
good work Ted and others continue to do it this space.

I'm not sure if by "stalled" you mean sticking with the plan above,
or something else (e.g., for the WG to go entirely quiescent until
the authors come back and claim the draft is done and have running
code). Can you clarify?

Thanks,
S.

> (Experience shows that
> the best way to break a protocol is to give an implementation to Dave.)
> 
>> (b) the drafts on handling names with help from your ISP.
> 
> I fear that these drafts are a bad case of complexity for the sake of
> complexity (or perhaps a case of involving the ISP for the sake of
> involving the ISP).  I still haven't seen a compelling argument that they
> do solve a problem that a trivial end-to-end protocol wouldn't solve.
> Back in July 2018, I wrote the following:
> 
> This is a question that I've been asking since July 2014, and I still
> haven't received an answer I could understand.
> 
> Please see the thread starting on 18 July 2018:
> 
> https://www.mail-archive.com/homenet@ietf.org/msg07012.html
> 
>> (We also have a chartered work item [4] on security that has seen no
>> progress but you can comment on that as item (c) if you like;-)
> 
> Some pointers for the rare people who don't spend most of their leisure
> time reading Internet-Drafts:
> 
>   - HNCP is based on DNCP, which includes a security mechanism designed to
> provide authenticity, integrity and confidentiality of the HNCP data:
> 
> RFC 7525 Section 8
> 
> I believe that this is implemented in hnetd.  (Yeah, Markus and
> Stephen did some remarkable work.)
> 
>   - Babel has two security mechanisms:
> 
> https://tools.ietf.org/html/draft-ietf-babel-hmac
> https://tools.ietf.org/html/draft-ietf-babel-dtls
> 
> There appear to be no standards-track key distribution and rotation
> protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
> to be the norm), so a natural question is whether HNCP could serve
> this purpose, or whether it would be better to use a dedicated key
> distribution and rotation mechanism.
> 
>   - RFC 3971 Section 6 says the following:
> 
>To protect Router Discovery, SEND requires that routers be
>authorized to act as routers.  This authorization is provisioned in
>both routers and hosts.
> 
> Since hosts don't participate in HNCP, it is not clear if HNCP can be
> used as a SEND trust anchor.  I believe there's the same issue with
> securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).
> 
> -- Juliusz
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

Hi Stephen,

Sorry if I'm repeating myself -- I've already expressed the opinions
below, both at the mike and on the list.

> (a) work on simple naming

I think that this work should be stalled until we have an implementation
to play with and make some in vivo experiments.  (Experience shows that
the best way to break a protocol is to give an implementation to Dave.)

> (b) the drafts on handling names with help from your ISP.

I fear that these drafts are a bad case of complexity for the sake of
complexity (or perhaps a case of involving the ISP for the sake of
involving the ISP).  I still haven't seen a compelling argument that they
do solve a problem that a trivial end-to-end protocol wouldn't solve.
Back in July 2018, I wrote the following:

This is a question that I've been asking since July 2014, and I still
haven't received an answer I could understand.

Please see the thread starting on 18 July 2018:

https://www.mail-archive.com/homenet@ietf.org/msg07012.html

> (We also have a chartered work item [4] on security that has seen no
> progress but you can comment on that as item (c) if you like;-)

Some pointers for the rare people who don't spend most of their leisure
time reading Internet-Drafts:

  - HNCP is based on DNCP, which includes a security mechanism designed to
provide authenticity, integrity and confidentiality of the HNCP data:

RFC 7525 Section 8

I believe that this is implemented in hnetd.  (Yeah, Markus and
Stephen did some remarkable work.)

  - Babel has two security mechanisms:

https://tools.ietf.org/html/draft-ietf-babel-hmac
https://tools.ietf.org/html/draft-ietf-babel-dtls

There appear to be no standards-track key distribution and rotation
protocols for either of OSPF, IS-IS, BGP or BFD (static keying seems
to be the norm), so a natural question is whether HNCP could serve
this purpose, or whether it would be better to use a dedicated key
distribution and rotation mechanism.

  - RFC 3971 Section 6 says the following:

   To protect Router Discovery, SEND requires that routers be
   authorized to act as routers.  This authorization is provisioned in
   both routers and hosts.

Since hosts don't participate in HNCP, it is not clear if HNCP can be
used as a SEND trust anchor.  I believe there's the same issue with
securing access the DNS stub resolver (DNSCrypt, DNS over TLS, etc.).

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Stephen Farrell]

Hi all,

We'd really appreciate more feedback on this topic,
so could you please take a few minutes to give us
some more guidance on where you want to see the
work go from here...

Thanks,
S.

On 01/03/2019 21:21, Stephen Farrell wrote:
> 
> Dear WG,
> 
> At IETF-103 Ted lead a good discussion of where we're at and where we
> and others in the homenet space may be heading. One key aspect of that
> discussion is that we might (or might not) be working on specs that have
> been overtaken by events e.g. in the sense that perhaps there are now
> sufficient other options that people are less likely to implement the
> specs we currently have as WG documents.
> 
> As chairs, we have also noted the relative lack of activity on the list
> in recent months, which could also be related to a lack of interest in
> implementing and deploying our current WG drafts.
> 
> We'd therefore like to have a discussion on the list, between now
> and IETF-104 as to what the WG ought be doing.
> 
> It's fine to offer general opinions, but as a way to break it down, we
> basically have two bits of work in-hand: (a) work on simple naming [1]
> and (b) the drafts on handling names with help from your ISP. [2,3]
> (We also have a chartered work item [4] on security that has seen no
> progress but you can comment on that as item (c) if you like;-)
> 
> Ted also has some concrete ideas for work to do at the upcoming
> hackathon. We've asked him to start a separate thread on that and
> would love to see people participate in that.
> 
> We think there are a few potential positions that participants in the
> discussion may have (or end up having) with respect to each of those,
> perhaps:
> 
> (1) it's great work and I plan to implement or deploy - see
> you at the hackathon!
> (2) it's great work and I'll be actively engaged with it in
> the coming months reviewing drafts and posting to the
> list
> (3) I do care about this stuff getting done, but I don't have
> the time/management interest to spend the time I'd like.
> (4) I'm not that interested in this stuff, but I don't object,
> and I'll read some drafts as I'm able to.
> (5) it's fine stuff, but IMO not going to be used, so there's
> not much point in producing RFCs
> (6) not sure at the moment, maybe the WG should go quiescent for
> a while 'till we know more
> 
> If one of those positions captures your opinion, feel free to respond
> in shorthand. Otherwise, please tell us where you think we ought be
> going, as a WG, with (a), (b) and/or (c).
> 
> To be clear, we're happy to proceed according to the consensus of the
> WG participants whatever that may be. That could mean trying to
> accelerate some work, or closing down the WG, or anything in between,
> assuming we see enough engagement in discussion and that there's a
> rough consensus that we can call.
> 
> As chairs, we want to allow plenty of time for this, and are considering
> devoting (part of) a f2f session to bottoming out on this topic at
> IETF-104 if that's needed, but we'd like to be reassured that the WG
> think we're working on the right things now, and that those are likely
> to be implemented and hopefully deployed.
> 
> We'd really appreciate it if you can send an initial response to
> this mail in the next week so we can start to build an agenda for
> our session at IETF-104.
> 
> Thanks
> B (As chairs)
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-homenet-simple-naming
> [2]
> https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation
> [3]
> https://tools.ietf.org/wg/homenet/draft-ietf-homenet-naming-architecture-dhc-options/
> [4] https://tools.ietf.org/wg/homenet/charters
> 
> 
> 
> 
> 
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.

> (The only significant difference is the treatment of border routers, which
> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

> Does that equality mean that I can route from a device in one home to a device
> in another over v4.

You'll need something like ICE (RFC 8445), or at least STUN (of which ICE
is a superset).  PCP (or NAT-PMP) should in principle work too, but
I haven't actually tried getting it to work over multiple hops.

You'll need ICE STUN or PCP even for IPv6, since people appear to be
intent on putting stateful IPv6 firewalls on their edge routers.

> Won’t they both have rfc 1918 addresses (possibly the same ones).

ICE is fine with that.

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> I do remember that talk. CS grad students are not our target market.

First year undergrad, Ted.  Eighteen year-old lass with no previous
networking experience.

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

I do remember that talk. CS grad students are not our target market. Open
source distributions are a great demo, but I want this stuff in Ubiquiti
routers, Eero routers, etc.  it’s clear you aren’t interested in working on
it at the Hackathon, which is perfectly understandable, but I was asking if
anyone *is *interested because i can’t do it all by myself.

On Sun, Mar 3, 2019 at 06:45 Juliusz Chroboczek  wrote:

> >> It should be an easy fix, feel free to go ahead.
>
> > The point of soliciting participation at hackathon is for us to gain
> > collective experience on the easy or difficulty of deploying homenet in
> > practice.
>
> Oh, that's different, and not at all the motivation you give in your
> previous mail.  Experience shows that the best way to make something
> happen is to organise it oneself, and therefore you should feel free to
> organise a Homenet tutorial yourself, just like you should feel free to
> fix yourself the issues you're having with hnetd.
>
> I'm not sure that you'll find much of an audience, though -- as you
> rightly point out, there doesn't appear to be much excitement left around
> Homenet, and the main contributors appear to have moved on with their
> lives.  It's been six years, after all.  (For my part, my IETF funding
> runs out in September.)
>
> On that subject, you might remember the talk I gave about HNCP deployment
> back in 2016.  The conclusions were that a first year student who had
> never done any networking before was able to deploy an HNCP+Babel mesh
> network in two weeks, and most of that time was spent learning to reflash
> off-the-shelf routers from scratch.
>
> https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1
>
> -- Juliusz
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

>> It should be an easy fix, feel free to go ahead.

> The point of soliciting participation at hackathon is for us to gain
> collective experience on the easy or difficulty of deploying homenet in
> practice.

Oh, that's different, and not at all the motivation you give in your
previous mail.  Experience shows that the best way to make something
happen is to organise it oneself, and therefore you should feel free to
organise a Homenet tutorial yourself, just like you should feel free to
fix yourself the issues you're having with hnetd.

I'm not sure that you'll find much of an audience, though -- as you
rightly point out, there doesn't appear to be much excitement left around
Homenet, and the main contributors appear to have moved on with their
lives.  It's been six years, after all.  (For my part, my IETF funding
runs out in September.)

On that subject, you might remember the talk I gave about HNCP deployment
back in 2016.  The conclusions were that a first year student who had
never done any networking before was able to deploy an HNCP+Babel mesh
network in two weeks, and most of that time was spent learning to reflash
off-the-shelf routers from scratch.

https://datatracker.ietf.org/meeting/96/materials/slides-96-homenet-1

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

>> Both HNCP and Babel carry their control traffic over link-local IPv6, but
>> they support both IPv4 and IPv6 with almost equal functionality.
>> 
>> (The only significant difference is the treatment of border routers, which
>> are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

> Oh, I thought the charter was for v6 only.  Did that change, or am
> I misremembering?

Yeah, I never understood that.  The charter is pretty much v6-only, but
I don't recall anyone ever suggesting that we should omit IPv4 support
(but then, I only got involved around the summer of 2014).  RFC 7788 says:

   While RFC 7368 sets no requirements for IPv4 support, HNCP aims to
   support the dual-stack mode of operation, and therefore the
   functionality is designed with that in mind.

while the Babel profile for Homenet says:

   REQ3: a Homenet implementation of Babel SHOULD implement the IPv4
   subset of the protocol

The implementation status is pretty solid:

  - both implementations of HNCP (hnetd and shncpd) have good support for
IPv4 and DHCPv4;
  - of the six implementations of Babel known to me, four support IPv4
(babeld, BIRD, FRR and David's Top Secret Implementation).

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 2, 2019, at 8:50 PM, Juliusz Chroboczek  wrote:
> That's an property of the hnetd implementation, not a feature of the
> protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

The text:

  An HNCP router MUST create a private IPv4 prefix [RFC1918 
]
  whenever it wishes to provide IPv4 Internet connectivity to the
  network and no other private IPv4 prefix with Internet
  connectivity currently exists.  It MAY also enable local IPv4
  connectivity by creating a private IPv4 prefix if no IPv4 prefix
  exists but MUST NOT do so otherwise.

So it does allow the implementation to use use RFC1918 addresses internally 
when there is no upstream address, but it really does seem to be saying that’s 
not necessary.   Better advice would be that if an IPv4 address is ever 
obtained externally, that internal RFC1918 addressing should remain available 
until some substantial amount of time has passed.   Right now this behavior is 
optional.

>> This is one of the reasons that I would like us to get together and hack on
>> this at the hackathon:
> 
> It should be an easy fix, feel free to go ahead.

The point of soliciting participation at hackathon is for us to gain collective 
experience on the easy or difficulty of deploying homenet in practice.   It’s 
all very well and good to have implementations, but if nobody is able to use 
them, this isn’t really what we want when we talk about having interoperating 
implementations.   This is particularly true when the goal of a body of work is 
automatic operation (as in ops), as opposed to mere protocol interoperation.

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.

> in fact while what you are saying is technically true, in practice IPv4
> _is_ treated like a second-class citizen in the sense that if your
> ISP-provided public IP address ever goes away, all of your RFC1918
> addresses on the homenet also go away.

That's an property of the hnetd implementation, not a feature of the
protocol (and it doesn't apply to shncpd).  See RFC 7788 Section 6.5.

> This is one of the reasons that I would like us to get together and hack on
> this at the hackathon:

It should be an easy fix, feel free to go ahead.

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

... if your ISP-provided public IP address ever goes away, all of your RFC1918 
addresses on the homenet also go away.

 Not in any router I’ve ever had a hand in specifying or procuring! And 
not true of my Netgear router, or any of my older Linksys routers. Or OpenWRT 
loaded routers. My RFC1918 addresses absolutely stay put. I just can’t access 
the Internet (through that broadband connection) when my ISP-provided public IP 
address goes away. I’m not aware of any router that loses its RFC1918 addresses 
when the WAN goes down.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> For the last 10 to 15 years the ISP-provided home router has come to
> dominate the market, with the belief by the ISPs that this is a MUST that they
> control the device.  Many (but not all) at the IETF do not share this view, 
> but
> most non-technical users see the ISP provided router is simply saving the trip
> to
> BestBuy, rather than an abdication of control over their home.   If this
> trend continues, then I believe that ISPs (residential IAPs) will come to want
> to control all IoT devices in the home -- because security -- telling 
> residential
> customers what they can and not connect.

Just to be clear, the main reasons most ISPs require use of the ISP CE router 
at the edge of mass market customer networks is because:
1. Providing instructions for installation and setup becomes easier, as well as 
ensuring the installation process is as trouble-free and easy as possible.
2. Improved but simplified security between the CE router and the access network
3. Cost of help desk support is greatly reduced because help desk personnel 
only have to know how to guide customers through one GUI, and the help desk can 
get permission from the customer (when on a call with the customer) to directly 
manage the router if the customer prefers that approach.

The cost of supporting a customer under a bring-your-own-random-CE-router model 
is considerably higher than the cost of supporting a customer in an 
ISP-managed/specified/provided-CE-router model.

None of which prevents anyone from putting their own router between the ISP CE 
router and their home network. That's what I do. The ISP doesn't control my 
home network and there's no requirement from the ISP that they control my home 
network. I have not abdicated control of my home network to my ISP.

Home automation services may be offered by an ISP, but I'm not aware of any 
case in the US (or Europe) where someone who wants home automation / security 
is required to get it from their ISP or where the ISP has to give permission 
for someone else (or for the homeowner) to operate such a service. I don't know 
the rest of the world.

Can we please avoid making these rather insulting and inflammatory claims 
without evidence? If there's evidence, please provide it. If the evidence 
indicates the practice is localized (to a single ISP, country, or geography), 
please note that when providing evidence. Broad claims that an entire 
IETF-stakeholder group is evil and trying to control everything are not nice.

> I believe that this direction will result in ISPs being 100% liable for 
> attacks on
> critical infrastructure; I don't think that this is a place that ISPs want to 
> be, but
> I'm not sure that they have understood this yet.

I don't know about other ISPs, but I do know my employer takes network security 
very seriously. And access network security (including preventing theft of a 
customer's access service) is one of the reasons I mentioned for providing 
customers with an ISP-provided CE router.

> It's clearly not in
> Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-
> conglomerate's
> interest to be told by ISPs what their products may or may not do.
> This is an ongoing tussle that that relates in some ways (but not all) to the 
> net
> neutrality debate and the desire my ISPs for a cut of the over-top-pie.
> My answer is that the consumer should be in control, and that ISPs need to
> get out of the home router business entirely.  Home router vendors (or the
> service companies they create) should provide first-level support for issues,
> and actual real connectivity issues should be submitted electronically.  Not 
> so
> different in the way that my furnace maintenance is not provided by my gas
> supplier, but my gas supplier gets to inspect the hookup.

No ISP in the US is in a position to tell these companies what they can or 
can't do in a device connected to a customer's network. I can't speak for other 
regions.
There is no evidence that all ISP routers provided by all ISPs in every corner 
of the world prevent all of their customers from being in complete control of 
the home network.  
I remain in complete control of my home network and the devices connected to 
it, independent of the fact that my home network edge router is connected 
through an ISP CE router. Therefore, I know this claim is false in my case.
In any case, I think this comment is well outside the realm of the homenet 
charter.



Barbara

> When we started this effort we heard of real situations such as Fred's 
> original
> FUN BOF slides on how dual-geek households are forced not to share
> printers due to corporate home firewall requirements.  And that we should
> expect the situation to get worse.  Those slides are close to ten years old.
> I'd like to know if they are still at relevant.  Maybe they aren't.
> If not, why not?
> 
> --
> Michael Richardson , Sandelman Software Works
> -= IPv6 IoT consulting =-

___

Re: [homenet] homenet: what now? ... next?

[Michael Richardson]

Ralf Weber  wrote:
> Moin!

> On 2 Mar 2019, at 1:14, Michael Richardson wrote:
>> I personally do not believe that Home Router firmware update practices 
have
>> significantly improved.  I would welcome more recent data: is anyone
>> collecting this on a regular basis?  I suspect that 90% of firmware 
updates
>> occur because the (integrated) modem is replaced in order to upgrade
>> bandwidth.

> So you think this is a problem.

I'm saying that the devices are not getting updates, even ISP provided
ones.

>> For the last 10 to 15 years the ISP-provided home router has come to
>> dominate
>> the market, with the belief by the ISPs that this is a MUST that they
>> control
>> the device.  Many (but not all) at the IETF do not share this view, but
>> most
>> non-technical users see the ISP provided router is simply saving the trip
>> to
>> BestBuy, rather than an abdication of control over their home.

> And I agree with most of the non-technical end users there. An ISP 
provided
> router does get updates and in case of problems I can call them and

I do not observe ISP provided modems to get updates.

>> net neutrality debate and the desire my ISPs for a cut of the 
over-top-pie.
>> My answer is that the consumer should be in control, and that ISPs need 
to
>> get out of the home router business entirely.

> I agree that customers should be in control, and they are now as in most
> countries you can choose between an ISP provided routers or buy one at 
your
> convenience. I do not see how less choice (only non ISP provided routers)
> will make this better especially as ISP provided and often managed routers
> are usually updated and taken care of by the ISP in case of problems.

There are quite a number of services in Canada where the ISP provided
modem/router combo has no way to go into a layer-2 only mode.  Or it's very
hard to figure out, or the ISP disdains all notions of supporting you.

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



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

Re: [homenet] homenet: what now? ... next?

[Michael Thomas]

On 3/2/19 8:30 AM, Juliusz Chroboczek wrote:

What I meant is that homenet router protocols are v6 only.

No, they're not.

Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.

(The only significant difference is the treatment of border routers, which
are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)


Oh, I thought the charter was for v6 only. Did that change, or am I 
misremembering?


Mike

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

Re: [homenet] homenet: what now? ... next?

[Ted Lemon]

On Mar 2, 2019, at 11:30 AM, Juliusz Chroboczek  wrote:
> No, they're not.
> 
> Both HNCP and Babel carry their control traffic over link-local IPv6, but
> they support both IPv4 and IPv6 with almost equal functionality.

This is one of the reasons that I would like us to get together and hack on 
this at the hackathon: in fact while what you are saying is technically true, 
in practice IPv4 _is_ treated like a second-class citizen in the sense that if 
your ISP-provided public IP address ever goes away, all of your RFC1918 
addresses on the homenet also go away.

So on a practical level, homenets as currently specified really are, if not 
v6-only, then at least only-v6-reliable.

I think it would actually be better if homenets were IPv6-only, with NAT64 at 
the edge for the case where there is only an IPv4 address, but I imagine that 
this would not be a popular enough view to get consensus.  It would be equally 
good if IPv4 were just assumed to be required to work regardless of whether 
there’s an upstream IPv4 address.   This is something that we should really 
re-think—the way it is now isn’t ideal.

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

Re: [homenet] homenet: what now? ... next?

[Juliusz Chroboczek]

> What I meant is that homenet router protocols are v6 only.

No, they're not.

Both HNCP and Babel carry their control traffic over link-local IPv6, but
they support both IPv4 and IPv6 with almost equal functionality.

(The only significant difference is the treatment of border routers, which
are assumed to be doing NAT in IPv4 and stateless routing in IPv6.)

-- Juliusz

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

Re: [homenet] homenet: what now? ... next?

[Ralf Weber]

Moin!

On 2 Mar 2019, at 1:14, Michael Richardson wrote:
I personally do not believe that Home Router firmware update practices 
have

significantly improved.  I would welcome more recent data: is anyone
collecting this on a regular basis?  I suspect that 90% of firmware 
updates

occur because the (integrated) modem is replaced in order to upgrade
bandwidth.

So you think this is a problem.

For the last 10 to 15 years the ISP-provided home router has come to 
dominate
the market, with the belief by the ISPs that this is a MUST that they 
control
the device.  Many (but not all) at the IETF do not share this view, 
but most
non-technical users see the ISP provided router is simply saving the 
trip to

BestBuy, rather than an abdication of control over their home.
And I agree with most of the non-technical end users there. An ISP 
provided
router does get updates and in case of problems I can call them and they 
will
fix it. I currently experience that myself as my DSL modem (not ISP 
supplied)
is currently experiencing problems, which the ISP provided router does 
not
have. So I now have to research what the actual problem is, which is 
something

most non technical users wouldn’t be even capable of doing.

Also I’ve seen way more intrusion of my home and privacy by over the 
top
providers or IoT devices than I have seen by my ISP. I know this might 
be
different in different parts of the world, which is why we should not 
take

either view for granted.


It's clearly not in
Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-conglomerate's
interest to be told by ISPs what their products may or may not do.
This is an ongoing tussle that that relates in some ways (but not all) 
to the
net neutrality debate and the desire my ISPs for a cut of the 
over-top-pie.
My answer is that the consumer should be in control, and that ISPs 
need to

get out of the home router business entirely.

I agree that customers should be in control, and they are now as in most
countries you can choose between an ISP provided routers or buy one at 
your
convenience. I do not see how less choice (only non ISP provided 
routers)
will make this better especially as ISP provided and often managed 
routers

are usually updated and taken care of by the ISP in case of problems.


Home router vendors (or the
service companies they create) should provide first-level support for 
issues,
and actual real connectivity issues should be submitted 
electronically.
Well I wish I had a pony, but sorry this is not how it works. The 
primary
driver for most people when they buy home routers is price and I doubt 
that

these mostly Asia based companies could support my wider family with a
german speaking hotline. My ISP can though…

On Stephens original question I am between 3 and 4, as I mostly care 
from
an intellectual standpoint, as in man it would be great if that would 
work,
rather then believe we will actually get devices widely deployed, but I 
for

sure would like to play with some in my free time.

So long
-Ralf
—--
Ralf Weber

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

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> > But Wi-Fi Alliance (WFA) has been working to provide a solution for
> seamless whole home coverage. And from what I can see, I think it's going to
> be successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged
> network. I do think this needs to move towards true mesh (and the reason
> they haven't is because they haven't yet been properly introduced to an
> easy method of loop avoidance).
> 
> 
> Do you know if they deal with differences in the security domains? Or is
> it punted to L3? Like in my example, I might want to let my neighbors
> access my hot tub controller, but not, say, my tv. You can envision the
> same thing with guest/kids nets.

Release 1 did not. 
Here is the Release 1 spec: 
https://www.wi-fi.org/file/multi-ap-specification-v10
They do make non-members provide contact info, but the download is free.

Release 2 hasn't been released, yet. And I've pledged to abide by their 
non-disclosure policies, so I can't tell non-members what's in it. I think it's 
safe to say, it adds functionality that many companies find desirable.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Michael Thomas]

On 3/1/19 4:14 PM, Michael Richardson wrote:


When we started this effort we heard of real situations such as Fred's
original FUN BOF slides on how dual-geek households are forced not to share
printers due to corporate home firewall requirements.  And that we should
expect the situation to get worse.  Those slides are close to ten years old.
I'd like to know if they are still at relevant.  Maybe they aren't.
If not, why not?

I've been in startup land the last several years where everything is in 
the cloud and everybody brings their own device. At the office, it was 
just business cable. We got asked by a customer what our firewall was 
and we sort of looked puzzled. Where do you mean? There was no corporate 
network and no need for one. We outsourced all of the typical things 
that corpro IT does which was fine by us because who wants to spend time 
and money on reinventing wheels?


My point here is that companies who are started in the cloud -- which is 
just about everybody these days -- don't even understand the 
requirement. Maybe they do when they get big enough, but I'm not sure.


Mike

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

Re: [homenet] homenet: what now? ... next?

[Michael Richardson]

Michael Thomas  wrote:
> I would guess that even after 5 years, we still don't have much v6
> deployment
> into homes and that's a pretty big problem. Router vendors are not much
> motivated by that which doesn't have a market.

Cable ISPs in north america (Rogers, Comcast) seem to be turning more and
more IPv6 on daily.  I am going by increasingly visible IPv6 (including ULAs,
btw) at local pubs/restaurants/coffee shops.  But, IPv6 is at this point, a
non-event for users (that's good that they don't notice, btw).

I personally do not believe that Home Router firmware update practices have
significantly improved.  I would welcome more recent data: is anyone
collecting this on a regular basis?  I suspect that 90% of firmware updates
occur because the (integrated) modem is replaced in order to upgrade
bandwidth.

For the last 10 to 15 years the ISP-provided home router has come to dominate
the market, with the belief by the ISPs that this is a MUST that they control
the device.  Many (but not all) at the IETF do not share this view, but most
non-technical users see the ISP provided router is simply saving the trip to
BestBuy, rather than an abdication of control over their home.   If this
trend continues, then I believe that ISPs (residential IAPs) will come to
want to control all IoT devices in the home -- because security -- telling
residential customers what they can and not connect.

I believe that this direction will result in ISPs being 100% liable for
attacks on critical infrastructure; I don't think that this is a place that
ISPs want to be, but I'm not sure that they have understood this yet.

It's clearly not in
Amazon/Google/Facebook/Intel/Samsung/insert-another-IoT-conglomerate's
interest to be told by ISPs what their products may or may not do.
This is an ongoing tussle that that relates in some ways (but not all) to the
net neutrality debate and the desire my ISPs for a cut of the over-top-pie.
My answer is that the consumer should be in control, and that ISPs need to
get out of the home router business entirely.  Home router vendors (or the
service companies they create) should provide first-level support for issues,
and actual real connectivity issues should be submitted electronically.  Not
so different in the way that my furnace maintenance is not provided by my gas
supplier, but my gas supplier gets to inspect the hookup.

When we started this effort we heard of real situations such as Fred's
original FUN BOF slides on how dual-geek households are forced not to share
printers due to corporate home firewall requirements.  And that we should
expect the situation to get worse.  Those slides are close to ten years old.
I'd like to know if they are still at relevant.  Maybe they aren't.
If not, why not?

--
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] homenet: what now? ... next?

[Michael Thomas]

On 3/1/19 3:49 PM, STARK, BARBARA H wrote:

I would guess that even after 5 years, we still don't have much
v6 deployment into homes and that's a pretty big problem.

That's an interesting statement to make. Do you have evidence of that?
https://www.worldipv6launch.org/measurements/ shows considerable deployment. I know 
for a fact that the AT wireline network supports IPv6 to 100% of customers. 
The reason only 61.26% of traffic is IPv6 is *not* due to the ISP not supporting 
it. It's due to edge networks that don't support. And in this case, it's mostly due 
to enterprises not supporting. The 61.26% number is heavily weighted towards mass 
market customers using IPv6, because it was easier to push IPv6 support into 
managed CE routers.


Oh, that's interesting. I knew it was getting support on mobile, but 
haven't kept up on what's going on cable/dsl/fiber.





What I *am* seeing, is a lack of random topology multi-router networks.
While it may be that continued use of IPv4 in home networks is a factor that 
drives people away from multi-router topologies, I don't think this is the same 
as saying that lack of IPv6 is a reason people aren't deploying.
I really don't think IPv6 (or even IPv6-only inside the mass market LAN -- 
which won't be happening for a long time) is a driver for multiple routers.
What I meant is that homenet router protocols are v6 only. At least the 
last time I checked.

The biggest driver historically has been to get multiple Wi-Fi access points, 
to cover more of the premises. But many people resisted even this driver, 
because devices didn't seamlessly move between APs and the routed interfaces 
blocked multicast traffic (so you could only cast to your TV if you were on the 
same AP with the TV).


Yeah, I have that problem with my friends/neighbors.



But Wi-Fi Alliance (WFA) has been working to provide a solution for seamless 
whole home coverage. And from what I can see, I think it's going to be 
successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged network. 
I do think this needs to move towards true mesh (and the reason they haven't is 
because they haven't yet been properly introduced to an easy method of loop 
avoidance).



Do you know if they deal with differences in the security domains? Or is 
it punted to L3? Like in my example, I might want to let my neighbors 
access my hot tub controller, but not, say, my tv. You can envision the 
same thing with guest/kids nets.




But even if the common home network won't have lots of routers, the need for a 
good naming architecture still exists, IMO.



Yes, and that's not dependent on v6 afaik.

Mike

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

Re: [homenet] homenet: what now? ... next?

[STARK, BARBARA H]

> I would guess that even after 5 years, we still don't have much
> v6 deployment into homes and that's a pretty big problem. 

That's an interesting statement to make. Do you have evidence of that?
https://www.worldipv6launch.org/measurements/ shows considerable deployment. I 
know for a fact that the AT wireline network supports IPv6 to 100% of 
customers. The reason only 61.26% of traffic is IPv6 is *not* due to the ISP 
not supporting it. It's due to edge networks that don't support. And in this 
case, it's mostly due to enterprises not supporting. The 61.26% number is 
heavily weighted towards mass market customers using IPv6, because it was 
easier to push IPv6 support into managed CE routers.

What I *am* seeing, is a lack of random topology multi-router networks.
While it may be that continued use of IPv4 in home networks is a factor that 
drives people away from multi-router topologies, I don't think this is the same 
as saying that lack of IPv6 is a reason people aren't deploying.
I really don't think IPv6 (or even IPv6-only inside the mass market LAN -- 
which won't be happening for a long time) is a driver for multiple routers.
The biggest driver historically has been to get multiple Wi-Fi access points, 
to cover more of the premises. But many people resisted even this driver, 
because devices didn't seamlessly move between APs and the routed interfaces 
blocked multicast traffic (so you could only cast to your TV if you were on the 
same AP with the TV).

But Wi-Fi Alliance (WFA) has been working to provide a solution for seamless 
whole home coverage. And from what I can see, I think it's going to be 
successful. But WFA EasyMesh (release 1) is a tree-topology L2 bridged network. 
I do think this needs to move towards true mesh (and the reason they haven't is 
because they haven't yet been properly introduced to an easy method of loop 
avoidance). 

So if multi-access points was a driver for multiple routers, WFA EasyMesh may 
very well kill that off as a driver.

But even if the common home network won't have lots of routers, the need for a 
good naming architecture still exists, IMO.
And the need for good loop avoidance...

This is my personal, individual opinion, if that wasn't obvious.
Barbara
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] homenet: what now? ... next?

[Michael Thomas]

On 3/1/19 2:25 PM, Ted Lemon wrote:
On Mar 1, 2019, at 4:21 PM, Stephen Farrell > wrote:

If one of those positions captures your opinion, feel free to respond
in shorthand. Otherwise, please tell us where you think we ought be
going, as a WG, with (a), (b) and/or (c).


For me it’s (1) and (2).

I think there are a few reasons why homenet feels stalled right now.



I would guess that even after 5 years, we still don't have much v6 
deployment into homes and that's a pretty big problem. Router vendors 
are not much motivated by that which doesn't have a market.


Sigh.


Mike



  * We are tracking a moving target, and we haven’t adjusted our
goals.   This is the conclusion I came to as a result of working
on the presentation I did in Bangkok on Homenet Marketing.   I
don’t think this is bad.
  * I conjecture that one of the reasons that there is good attendance
at homenet but relatively limited participation is in fact that we
are developing technology that is interesting to the people who
are showing up, but not quite addressing their needs.
  * I don’t actually know what the applicability is for the hidden
primary stuff.   I’ve gotten feedback that there are people who
want this, but I have no idea what to do with it, given that we
don’t want to expose internal DNS to external nodes.
  * No hardware that does homenet.   We have homenet stuff in OpenWRT,
but making it work in a home isn’t a turnkey operation, and that
is, after all, the goal of Homenet: a real network that sets
itself up without the user having to grok how it works.
  * One of the applications of Homenet that we keep hearing about is
the SOHO market.   We should target that explicitly and see what
gaps exist in addressing it.


So I think spending some time re-targeting would be worthwhile, and 
it’s my intention to present a draft that talks about that in Prague.


I also would really like to see if anybody is willing to actually hack 
on Homenet in the hackathon.   There are a couple of projects I’d like 
to see us work on:


  * Turnkey homenet build of OpenWRT
  * If the Turris folks are down, it would be nice if they could join
us and make it work in Turris OS as well.
  * Homenet-wide service discovery using the DNSSD Discovery proxy
we’ve been working on, which is fully functional at this point.
  * Support for DNSSD SRP (this would involve finishing the SRP
gateway I’ve been working on, and getting it to update Unbound or
BIND).
  * Joining constrained-network edge routers to homenet routing and
service discovery infrastructure
  * MUD support for devices that are not on a separate link, but are
isolated from nodes that don’t have permission to talk to them.  
This should be doable in OpenWRT.
  * Automatic IKEv2 tunnels on OpenWRT that use the new split DNS
stuff being published in IPSECME to allow us to serve home.arpa to
VPN clients.


This is an ambitious set of goals, and I don’t expect we’ll work on 
all of them, but these are things that need work, so if there is 
energy to work on any of them, it would be nice to see that happen at 
hackathon.




___
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] homenet: what now? ... next?

[Ted Lemon]

On Mar 1, 2019, at 4:21 PM, Stephen Farrell  wrote:
> If one of those positions captures your opinion, feel free to respond
> in shorthand. Otherwise, please tell us where you think we ought be
> going, as a WG, with (a), (b) and/or (c).

For me it’s (1) and (2).

I think there are a few reasons why homenet feels stalled right now.

We are tracking a moving target, and we haven’t adjusted our goals.   This is 
the conclusion I came to as a result of working on the presentation I did in 
Bangkok on Homenet Marketing.   I don’t think this is bad.
I conjecture that one of the reasons that there is good attendance at homenet 
but relatively limited participation is in fact that we are developing 
technology that is interesting to the people who are showing up, but not quite 
addressing their needs.
I don’t actually know what the applicability is for the hidden primary stuff.   
I’ve gotten feedback that there are people who want this, but I have no idea 
what to do with it, given that we don’t want to expose internal DNS to external 
nodes.
No hardware that does homenet.   We have homenet stuff in OpenWRT, but making 
it work in a home isn’t a turnkey operation, and that is, after all, the goal 
of Homenet: a real network that sets itself up without the user having to grok 
how it works.
One of the applications of Homenet that we keep hearing about is the SOHO 
market.   We should target that explicitly and see what gaps exist in 
addressing it.

So I think spending some time re-targeting would be worthwhile, and it’s my 
intention to present a draft that talks about that in Prague.

I also would really like to see if anybody is willing to actually hack on 
Homenet in the hackathon.   There are a couple of projects I’d like to see us 
work on:
Turnkey homenet build of OpenWRT
If the Turris folks are down, it would be nice if they could join us and make 
it work in Turris OS as well.
Homenet-wide service discovery using the DNSSD Discovery proxy we’ve been 
working on, which is fully functional at this point.
Support for DNSSD SRP (this would involve finishing the SRP gateway I’ve been 
working on, and getting it to update Unbound or BIND).
Joining constrained-network edge routers to homenet routing and service 
discovery infrastructure
MUD support for devices that are not on a separate link, but are isolated from 
nodes that don’t have permission to talk to them.   This should be doable in 
OpenWRT.
Automatic IKEv2 tunnels on OpenWRT that use the new split DNS stuff being 
published in IPSECME to allow us to serve home.arpa to VPN clients.

This is an ambitious set of goals, and I don’t expect we’ll work on all of 
them, but these are things that need work, so if there is energy to work on any 
of them, it would be nice to see that happen at hackathon.


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

[homenet] homenet: what now? ... next?

[Stephen Farrell]

Dear WG,

At IETF-103 Ted lead a good discussion of where we're at and where we
and others in the homenet space may be heading. One key aspect of that
discussion is that we might (or might not) be working on specs that have
been overtaken by events e.g. in the sense that perhaps there are now
sufficient other options that people are less likely to implement the
specs we currently have as WG documents.

As chairs, we have also noted the relative lack of activity on the list
in recent months, which could also be related to a lack of interest in
implementing and deploying our current WG drafts.

We'd therefore like to have a discussion on the list, between now
and IETF-104 as to what the WG ought be doing.

It's fine to offer general opinions, but as a way to break it down, we
basically have two bits of work in-hand: (a) work on simple naming [1]
and (b) the drafts on handling names with help from your ISP. [2,3]
(We also have a chartered work item [4] on security that has seen no
progress but you can comment on that as item (c) if you like;-)

Ted also has some concrete ideas for work to do at the upcoming
hackathon. We've asked him to start a separate thread on that and
would love to see people participate in that.

We think there are a few potential positions that participants in the
discussion may have (or end up having) with respect to each of those,
perhaps:

(1) it's great work and I plan to implement or deploy - see
you at the hackathon!
(2) it's great work and I'll be actively engaged with it in
the coming months reviewing drafts and posting to the
list
(3) I do care about this stuff getting done, but I don't have
the time/management interest to spend the time I'd like.
(4) I'm not that interested in this stuff, but I don't object,
and I'll read some drafts as I'm able to.
(5) it's fine stuff, but IMO not going to be used, so there's
not much point in producing RFCs
(6) not sure at the moment, maybe the WG should go quiescent for
a while 'till we know more

If one of those positions captures your opinion, feel free to respond
in shorthand. Otherwise, please tell us where you think we ought be
going, as a WG, with (a), (b) and/or (c).

To be clear, we're happy to proceed according to the consensus of the
WG participants whatever that may be. That could mean trying to
accelerate some work, or closing down the WG, or anything in between,
assuming we see enough engagement in discussion and that there's a
rough consensus that we can call.

As chairs, we want to allow plenty of time for this, and are considering
devoting (part of) a f2f session to bottoming out on this topic at
IETF-104 if that's needed, but we'd like to be reassured that the WG
think we're working on the right things now, and that those are likely
to be implemented and hopefully deployed.

We'd really appreciate it if you can send an initial response to
this mail in the next week so we can start to build an agenda for
our session at IETF-104.

Thanks
B (As chairs)


[1] https://tools.ietf.org/html/draft-ietf-homenet-simple-naming
[2]
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation
[3]
https://tools.ietf.org/wg/homenet/draft-ietf-homenet-naming-architecture-dhc-options/
[4] https://tools.ietf.org/wg/homenet/charters







0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


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