Re: [homenet] Homenet NA bike shed opportunities: terminology DOI

[Michael Richardson]

Eric Vyncke (evyncke)  wrote:
> Let's work on bike shedding [1], it is always easier and funnier ;-)

Yes, but typically inconclusive.

> DOS: DNS Outsourcing Services EDI: External DNS Infrastructure

> Or somehow more seriously: NOS: Naming Outsourcing Services NES: Naming
> External Services NEOS: Naming Externally Outsourced Services

NEOS is the best.

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

Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

The HNA MUST produce CDS/CDSKEY.

But, we have little control over whether or not the *parent zone* actually
uses CDS/CDSKEY.

We RECOMMEND that that they do (and maybe this RFC could be used as a
hammer), but it's outside of the control of the Outsourced Infrastructure
operator.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

v6ops  wrote:
> Michael Richardson wrote on 02/12/2022 02:56:
>> In re-editing I found that the section 7.1 is a bit vague about where
>> the Notifies go.  Ray Hunter please comment.
>>
>> 
https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-22.html#name-securing-the-synchronizatio
>>
>> Since the Synchronization Channel is from the DM->HNA, it can't be
>> issued there.  It must therefore be the case that the zone update
>> Notifies go into the Control Channel.

> Not necessarily.

> A Notify IMVHO is just an unsolicited signal from a (hidden) primary to
> a secondary that they may want to check for updated content.

I agree with everything you wrote.

My concern is that the thing getting the notify on port 53 is not the thing
that terminates the Control Channel on (maybe) port 853.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] [DNSOP] automating RFC2317 via IPv6 reverse map/DHCPv6

[Michael Richardson]

Havard Eidnes  wrote:
>> Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it 
occured
>> to me that the automatic reverse that
>> draft-ietf-homenet-naming-architecture-dhc-options could enable
>> better/simpler RFC2317 delegation for IPv4 subnets.
>>
>> My experience is that some of the pushback for doing 2317 is that there 
is
>> sane way to automate it, and too many confusing ways to do it.
>>
>> So, I wrote:
>> https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/
>>
>> which basically says to point the CNAMEs into the IPv6 delegation that is
>> "already" (will have been) being done.

> The actual convention to use isn't really specified by 2317, only
> a few examples are given.  This one should work just as well as
> any other convention, and if this makes it easier to use, I'm all
> for it.

Yes, the lack of a convention in 2317 was something that I noticed, and
thought wait... what if we adopted *this* convention.

(I see no point in proceeding with this document until the homenet documents
are in RFC editor Q. Of course, as there are no IANA actions, and it's just a
update to a convention,  it could be implemented now)

Tim Wicinski  wrote:
> Some time back Tony Finch proposed a 2317bis -
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc2317bis-00
> which the WG adopted but died for lack of interest.

> It would be useful to revise this document

Thank you for the pointer.
It got enough interest to get adopted... the document looks like it could
just be WGLC'ed.  My suggest convention into the ip6.arpa tree could be
combined in, and probably the first-last convention could be also be used.
(and it sounds like Vixie thinks the document should/could go ahead)






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

Re: [homenet] Next actions for I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt

[Michael Richardson]

Eric Vyncke (evyncke)  wrote:
> I would suggest to upload a clean -25 to avoid other people in the IETF
> community or in the IESG also calling idnits and complaining ;-)

I'll wait three days for other nits and post -25.

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

Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt

[Michael Richardson]

internet-dra...@ietf.org wrote:
> A diff from the previous version is available at:
> 
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-24

Version 24 is a response to Eric's unicast review comments, posted with 
permission.

Eric Vyncke (evyncke)  wrote:
> Some comments:
> - figure 1, on the right hand side there is the reverse zone but not on
> the left hand side ? (I would have added .local on the LHS as well)

a) I've added x.y.z.ip6.arpa to the left-hand side.  I'm concerned that this
may make some people think that only the delegating ISP can offer this
service.
b) .local isn't really a zone.  It's a convention that if you see it, then
you use mDNS.  So there never really is a zone by that name.

> - section 6.1, I wonder how plain DNS AXFR can be used to retrieve all
> the information required by HNA

Most of the detail is in section 6.5, and I've punted more clearly to that 
section.
I've edited section 6.5 to clarify the templateness of things.

> - section 6.3 is a little unclear about "with its new IPv4 and IPv6
> addresses" (plural) and the rest of the section "the IP address"
> (singular)

I've removed the IPv4 update, as I don't think that we support zone transfers
over IPv4.

> - section 6.5 " encouraged." Should this be a normative "RECOMMENDED" ?

I guess we SHOULD go that way.

> - section 7 " DNS updates are to sent over the Control" should this be
> "DNS Notifies" ? (my spell checker does not like "are to sent")

Thank you, are you are correct.

> - section 9 rather than using "WAN interface" should it be "public
> interface" ? Plural form is used but HNA listens on only one interface

fixed however... "public" interface is actually less meaningful in IPv6
world.  So I changed it to "internet facing"

In theory, the HNA could be on a device with multiple uplinks.
I'll remove (s) for now.

> - section 10, should the obvious be stated ? I.e., only applicable to
> IPv6 ?

I've thrown in "IPv6" in twice.

> - section 11, " It is RECOMMENDED the HNA sign the Public Homenet
> Zone." But early in the I-D, it was asserted that HNA signs the zones,
> i.e., use MUST and plural form (or is the reverse zone not signed) ?

If there is signing, then the HNA does it, not the DM.
I've removed "also" from the early section.

We have RECOMMENDED here, yes.
Let's change that.  RECOMMEND is a SHOULD, and the exceptions are unclear to me.
In particular, I want the zone signed even if the delegation is not secured.
This forces implementations to be ready for a secured delegation.

I've posted -24.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] Next actions for I-D Action: draft-ietf-homenet-front-end-naming-delegation-24.txt

[Michael Richardson]

Eric Vyncke (evyncke)  wrote:
> As the text has changed a lot, not so much on the technical content but
> more or completeness and readability, I will re-submit it to another
> IESG evaluation early January in the hope that the IESG will approve
> this draft.

Thank you.

> May I kindly request the authors to fix the idnits issues ?
> 
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-24.txt
> it is about a reference to RFC 6125 or its -bis and the use of
> obsoleted RFC 5077.

The text says:

   The HNA will validate the DM's control channel certificate by doing
   [RFC6125]/[I-D.ietf-uta-rfc6125bis] DNS-ID check on the name.

The word "an" ought to be in front of [RFC6125].
I think that idnits is confused.

I thought the UTA document was just a patch on RFC6125, but I see that it's a
complete replacement, so referencing both makes less sense.

As for RFC5077. I have replaced it with RFC8446 (TLS1.3), section 4.6.1, but
the reference feels less useful now.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

[homenet] automating RFC2317 via IPv6 reverse map/DHCPv6

[Michael Richardson]

Hi, while editing draft-ietf-homenet-front-end-naming-delegation, it occured
to me that the automatic reverse that
draft-ietf-homenet-naming-architecture-dhc-options could enable
better/simpler RFC2317 delegation for IPv4 subnets.

My experience is that some of the pushback for doing 2317 is that there is
sane way to automate it, and too many confusing ways to do it.

So, I wrote:
https://datatracker.ietf.org/doc/draft-richardson-ipv4-reverse-in-v6/

which basically says to point the CNAMEs into the IPv6 delegation that is
"already" (will have been) being done.

Anything we can do to make those who need just a bit of IPv4 (one or two
addresses) easier, while encouraging IPv6-first, is a good thing to me.

Your comments much appreciated.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-23.txt

[Michael Richardson]

internet-dra...@ietf.org wrote:
> There is also an HTML version available at:
> 
https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-23.html

> A diff from the previous version is available at:
> 
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-23

Some notes from me.
I've touched quite a lot of text through the document.
It took me a half day on Tuesday/Wednesday/Thursday/Friday and today to do.
(counting staring at the cat to figure out what to write)

I have the advantage of not having really read it for a few months, so my
proof reading is, I hope, beneficial to understanding without changing
any content.

I did however, delete figure 1, because it's basically repeated by figure 2,
and I redrew figure 2 with asciio, and then made sure that it translated to
SVG well.  That made me adjust some things, and it had to fit in 72 columns
too.  I wound up truncating "Zo"ne. in one place.

I see one place where markdown slipped through in {#sec-zone-delete}, and
it's fixed in git.

The technical place which I posted about a few days ago concerns where the
Notifies go.  I have placed them into the Control Channel.

Note that the Control Channel offers:
1. AXFR to get the zone template.
2. DNSUPD to change the NS (Synchronization Channel), and the DS records.
3. receipt of Notify to poke the Synchization process.

I have added some words about EKU on the certificates involved, basically
saying to please ignore them.   I posted to dnsop, and Daniel forwarded my
query onwards, about this, as RFC9103 is silent about this.  Ignoring them
might be important, because if DOI Operator gets their certificates from
LetsEncrypt via dns-01 challenge (a totally reasonable thing to do), then
they probably will have an EKU with *WWW* TLS Client and *WWW* TLS Server bits 
set.

I have tried to insert some of the more common terms from RFC8499, but there
aren't enough terms, and the term "DOI" remains, and I'd be happy to replace
it, but suggestions of "External DNS" are wrong.   That would be confusing,
and that term is never properly defined.

I've also expanded DOI several times more often than required, and the RPC
will freak about that, but I think it's worthwhile repeating what it means a
few times since the term is so awkward.

There are probably some typos and some repeated words, but I hope that the
text is better.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

Daniel Migault  wrote:
> In my opinion the Synchronization Channel is initiated by the DM and
> follows AXFR over TLS (9103). To my understanding NOTIFY, SOA exchange
> may be protected by TLS or not. Of course if the TLS session has not
> been established by the DM the NOTIFY cannot be protected.

Yes. It is initiated by the DM, and it's a TCP/TLS connection from
a random port on the DM to the designated port (853) on the HNA.
So, how does the *HNA* use this connection to send a Notify from the HNA to
the DM, when doesn't initiate to the DM?

> While I do see the point in re-using the control channel, I do not
> think we should recommend this. Firstly it mixes the following
> channels, so if we find another way to set the DM / HNA configuration
> we will always have to handle the Notify.

> I also believe that changes
> 9103, and I believe that would be good if we could re-se implementation
> of 9103 without modifications. It might be good to mention the Notifies
> may also take the control channel - just leaving this as a potential
> possibility.

9103 documents that NOTIFY messages travel over port-53, and are not protected.
That's fine, since they just cause an SOA query in the other direction, but
in the case of the HNA and DM, the only port that the HNA knows about that it
can send to is the Control Channel's port.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

[homenet] Homenet NA bike shed opportunities: terminology DOI

[Michael Richardson]

In draft-ietf-homenet-front-end-naming, we have the term: DOI.

DNS Outsourcing Infrastructure (DOI):
: is the infrastructure responsible for receiving the Public Homenet Zone and 
publishing it on the Internet.
It is mainly composed of a Distribution Manager and Public Authoritative 
Servers.


I never liked the acronym ("DOI" means evil old ISAKMP/IKEv1 things to me),
but I never had a better term.RFC8499 has a bunch of terms, but none of
them seem to be helpful here.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

In re-editing I found that the section 7.1 is a bit vague about where the
Notifies go.  Ray Hunter please comment.

https://www.ietf.org/archive/id/draft-ietf-homenet-front-end-naming-delegation-22.html#name-securing-the-synchronizatio

Since the Synchronization Channel is from the DM->HNA, it can't be issued
there.  It must therefore be the case that the zone update Notifies go into
the Control Channel.

But the text below doesn't say this, and is pretty wishy-washy about about
whether TLS is used or not.  It could very well be the case that Notifies are
*not* protected at all.
Since the Control Channel is not a regular DNS channel, and likely is port
853 DoT, it seems unlikely that a Notify to port 53 would go the right place.
OTH, bringing up DoT just to send the Notify might be considered by some to be
overkill.   TLS resumption tickets to the rescue is my opinion.

I'm looking for objections to:

1) Notifies go across the Control Channel (DoT)
2) They are always sent in TLS.

This means that the text will get moved around a bunch.



The text as it appears now:


## Securing the Synchronization Channel {#sec-synch-security}

The Synchronization Channel uses standard DNS requests.

First the HNA (primary) notifies the DM (secondary) that the zone must be 
updated and leaves the DM (secondary) to proceed with the update when 
possible/convenient.

More specifically, the HNA sends a NOTIFY message, which is a small packet that 
is less likely to load the secondary.
Then, the DM sends  AXFR {{!RFC1034}} or IXFR {{!RFC1995}} request.
This request consists in a small packet sent over TCP (Section 4.2 
{{!RFC5936}}), which also mitigates reflection attacks using a forged NOTIFY.

The AXFR request from the DM to the HNA MUST be secured with TLS {{!RFC8446}}) 
following DNS Zone Transfer over TLS {{!RFC9103}}.
While {{!RFC9103}} MAY not consider the protection by TLS of NOTIFY and SOA 
requests, these MAY still be protected by TLS to provide additional privacy.

When using TLS, the HNA MAY authenticate inbound connections from the DM using 
standard mechanisms, such as a public certificate with baked-in root 
certificates on the HNA, or via DANE {{?RFC6698}}.
In addition, to guarantee the DM remains the same across multiple TLS session, 
the HNA and DM MAY implement {{?RFC8672}}.

The HNA SHOULD apply an ACL on inbound AXFR requests to ensure they only arrive 
from the DM Synchronization Channel.
In this case, the HNA SHOULD regularly check (via a DNS resolution) that the 
address of the DM in the filter is still valid.

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

Re: [homenet] Artart last call review of draft-ietf-homenet-front-end-naming-delegation-22

[Michael Richardson]

Thank you for your comments!

Darrel Miller via Datatracker  wrote:
> be.  The biggest concern I have with the document is that it raises the
> possibility that the objectives of the document could be addressed
> using a "RESTful service" but then provides no reasoning for why a DNS
> solution was chosen instead.

We could have gone with a RESTful solution for the Control Channel, but the
infrastructure (the DM) needs the Synchronization channel to be DNS.
So implementers found that having two mechanisms and protocols and security
and ... to be more annoying than one.


--
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

Juliusz Chroboczek  wrote:
> In this WG, we did spend a lot of effort ensuring that all of our
> specifications have at least two independent implementations.

Juliusz, please go read RFC2026. You are completely out of order.
Proposed standards do not need *ANY* interoperable implementations.
2nd step (used to Draft Standard, now Internet Standard) do.

(Routing WGs sometimes have a higher standard for things that could kill the 
Internet)


--
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

Daniel Migault  wrote:
> will be able to address those or clarify them. I propose you start
> mentioning what you believe are unspecified gaps that could lead to
> INTEROPERABILITY ISSUES.

I emphasize this point.

--
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] Roman Danyliw's Discuss on draft-ietf-homenet-front-end-naming-delegation-21: (with DISCUSS and COMMENT)

[Michael Richardson]

Roman Danyliw via Datatracker  wrote:
> [per -18] I’m not sure if this my misreading of the behavior of
> internal clients.  To clarify, the (internal) Homenet DNSSEC Resolver
> will “... resolves the DS record on the Global DNS and the name
> associated to the Public Homenet Zone (myhome.example) on the Public
> Authoritative Servers.”?  Why would the internal resolver serving a
> request for an internal client for an internal service go to the Global
> DNS if the information if it could come from the internal Homenet Zone
> it is already configured with?

Because it needs the glue records to prove it is authoritative.

> As an operational consideration, why go
> outside of the network if you don’t need to?  As a privacy
> consideration, why leak the request to an outside entity if the network
> already has the information.

> [per -20] Thanks for the revised text: On the other hand, to provide
> resilience to the Public Homenet Zone in case of WAN connectivity
> disruption, the Homenet DNSSEC Resolver SHOULD be able to perform the
> resolution on the Homenet Authoritative Servers.

> -- Is there a reason this can’t be a MUST?

If the resolver and cache have been offline for long enough, any cached chain
of DS/NS/DNSKEY records from . down to the myhome.example might have expired.
(Consider a DNSSEC resolver on a host behind the gateway)

What to do in this situation has many answers with different tradeoffs.

--
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)

[Michael Richardson]

Paul Wouters  wrote:
> These two sentences I think show the core of my lack of understanding.
> Let's say I want to put my sauna on my public home net so I can access it
> remotely and turn it on before I get home?

> Is this envisioned as a goal of the homenet architecture?

You say, "homenet architecture", but our document is not the homenet 
architecture.
It's about the homenet naming architecture, and I'm sorry to be pedantic, but
the subtle difference includes a whole bunch of possible sins.
I have no idea if your sauna can be remotely controlled, or if if your home
router will let the traffic through, and it's not the job of this document to
standardize either of those things.

So, let's take a simpler version of this:

Your sauna can connect to an IRC server to tell you about it's temperature,
and the number of people currently in it.  But, IRC being what it is, it
would like to have a valid reverse name, and for that reverse name to match
the forward name before it will let you in.

> Is it envisioned that this would be done by talking to the device, using a
> name served by the "homenet public zone" ?

No, your sauna would not be involved at all.

> If so, can I determine the name of this zone, or is it only CPE
> auto-generated?

You would inform your CPE to please publish the IP address of your sauna
under a name that you decide.  How your CPE does this is not the concern of
the specification, but here are some ideas:
  * CPE identifies your sauna by MAC address, publishes the IPv6 that the NCE
says is associated with it.
  * CPE identifies your sauna by mDNS name
  * you have told your CPE to give the sauna a specific IPv6 via DHCPv6, and
it publishes that
  * something else

> If I can determine the name, I am confused how this all would hook into
> existing DNS infrastructure. It could be in my personal subdomain, a 
custom
> generic domain in .com ?

You could have obtained a domain, yes, perhaps in .com, for your CPE.
"paulshome.nohat.ca" if you desire.

We suggest, non-normatively in Appendix C of a JSON blob that could be copy
and pasted from your domain provider/DOI to your CPE in order to configure
everything.  We imagine flows where this actually all happens via browser/OAUTH2
flow, but that's not a normative part of the specification.

Your CPE could have been provisioned with a name (probably ugly) by the maker
of the CPE device.  I have been involved in two proofs of concept for this.
The ISP that provided the CPE to you, or some other party that sold you service.

> Then we get to my sauna device. It calls itself "tylo". How does this end
> up as a FQDN in the homenet public zone ? How does my home end up being
> able to query for it?
> How do the queries go when not at home?

All of this is really in the document.
1) How your CPE publishes the name tylo is up to the CPE.

2) the CPE is authoriative for the homenet public zone

3) the CPE tells the Domain Outsourcing Infrastructure (DOI) about the
   localtion of the zone, and the DOI does a DoX to transfer it. The DOI
   has some resilient infrastructure to publish things.  Whether it's
   ns1/ns2 on different subnets, or some multi-continent anycast system
   depends upon what you pay.

4) when you aren't at home, the queries go to the ns1/ns2 that the DNS
   has published.

5) When you are at home, we expect the CPE to answer authoritatively
   itself.  A well designed CPE would have cached the DS/NS/DNSKEY that leads
   to it's domain so that it can answer a secure chain even when the Internet
   connection is broken.

> So I am guessing. The only known method for hostnames publishing their
> names into a zone I know of is with Dynamic Updates on a local zone. But
> perhaps what homenet
> envisions is that I give my sauna a static IP and configure some webgui on
> my CPE to add it to my "zone" ?

No, and the document explains why this is a non-starter.


--
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] Lars Eggert's Abstain on draft-ietf-homenet-naming-architecture-dhc-options-22: (with COMMENT)

[Michael Richardson]

Lars Eggert via Datatracker  wrote:
> this document tries to describe would see adoption, it's become very
> clear that dynamic DNS services as described in Section 4 have won out
> here. These services are far from perfect, but at least some of the
> limitations in Section 4 have been addressed, and others are arguably a
> feature and not a limitation.

so, perhaps you could explain to me how to use some service to host my IPv6
reverse DNS then.


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

Re: [homenet] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18

[Michael Richardson]

Thank you for this review!
You did a very good job..

Matt Brown via Datatracker  wrote:
> Homenet Zone is highly likely to be the same IP with an open DNS
> port for the DM to connect to for XFR, and while the relationship
> in IPv6 is not as straightforward given the likely use of privacy
> addressing, etc it's not particularly hard to scan the enclosing
> /64 or beyond for an address with an open DNS port.

18 quintillion addresses is quite a lot :-)
It's not easy to scan.  Maybe you had some 

Here is a discussion in 6man, about using a browser to scan the IPv6-LL
of a local LAN:
  https://mailarchive.ietf.org/arch/msg/ipv6/YDRrY71hxhQBdMGLS-XByHS1f7I/

The other points are interesting, and I'll need to think about your
editorial suggestions about what order to present things in.

-- 
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] [dnsdir] Dnsdir telechat review of draft-ietf-homenet-front-end-naming-delegation-18

[Michael Richardson]

as> Reviewer: Anthony Somerset
as> Review result: Ready with Nits

as> Section 3.2 = "SHOULD remain pointing at the cloud provider's server IP 
address
as> - which in many cases will be an anycast addresses."

as> I don't believe its correct to include this assumption about anycast 
addresses
as> and is largely irrelevant to the content of the draft so i don't 
believe there
as> is value in keeping the text after the hyphen

I see your point.
I feel that there is some relevance to pointing this out.

One of important aspect of reminding people about this is to indicate that it
should be surprising if queries to these addresses actually return different
time views of the zone.  It can take some minutes for all anycast hosts to
update.

A second important aspect is that the address that queries go to is not,
because of anycast, the same as the place where the updates go.

I don't feel strongly about this, I just think that we wrote this down for a 
reason.

> The intro is very long and talks about things that don't get explained 
until
> much later in document and could cause some confusion, it may be better 
to make
> the intro more concise and move some of these aspects into the relevant
> sections.

It grew as a result of reviews.
you are saying we overshot, sure.

> Section 1.2 - to me this would flow better if it was its own section 
after the
> solution is explained

okay.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] Artart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21

[Michael Richardson]

Thank you for the encourging review!
IANA sections/tables sometimes get rewritten by IANA later on.

--
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] [Snac] summary of Gateway 2 Gateway side meeting

[Michael Richardson]

Marc Blanchet  wrote:
>> Also, because ICN does not involve making active (in the TCP sense)
>> connections to the sensors, it means that there is no inherent trust
>> that must be created in the sensors in order for them to communicate:
>> they simply announce their state and allow the network to do its
>> thing.

> I’m getting concerned that we are trying to boil the ocean. We should
> reduce the scope of this work to what is achievable. The proponents
> seemed to suggest a more narrow use case.

I think that I should have also reported that nobody in the side meeting
through that it belonged as part of the SNAC work.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

[homenet] summary of Gateway 2 Gateway side meeting

[Michael Richardson]

On Tuesday 2022-07-26, six local people and three remote attendees got
together to talk about the Gateway to Gateway communication situation.
The remote participant access was probably very poor, but that's the
situation today for side meetings.

After some introductions, the slides from Wei were opened and the group
started to walk through them.

{ the slides and background document
https://github.com/mcr/building-local-emergency-comms/blob/main/presentations/Gateway-To-Gateway-Communication-sidemeeting.pdf
  
https://www.ietf.org/archive/id/draft-richardson-snac-building-use-case-00.html 
}


There were numerous clarifying questions such as:

1) what kind of connectivity is really needed?
2) do devices talk to their own gateways only?  Do they talk to other gateways?
3) do devices talk to other devices?
4) how is the security context setup for his communication?

There was a general pessimism that a routing protocol like OSPFv3 would do a 
good job.

There was a fair bit of discussion about what are the road blocks to a
converged network like this.  It was felt that there were significant
regulatory roadblocks, and it would be quite difficult to get those
regulations changed.  An answer to this was: yes, that's true, but what kind
of network can be we build that might begin to satisfy the regulator?

Could such a network be deployed for non-emergency systems (or non-emergency
uses) and then, based upon the observed performance of such a network
(perhaps including fire drills), would a regulator begin to see this as
reasonable?

(As an aside: what are the cost savings of such a converged network?  There
could be direct savings in terms of wiring and maintenance, but also indirect
savings through new opportunities enabled)

There was no opinion about RPL/RFC6550, as there was not enough familiarity
with it.

A question arose: in emergencies, do we even need bi-directional
communications?

If communications is based upon Object Security (COSE not DTLS/OSCORE), then
could it all be done via an Information Centric Networking paradigm?  In such
a thing, actuators are not connected to sensors by pre-configuration, but
rather actuators observe outputs from sensors (which may be multicast), and
when some set of conditions occurs, the actuator does something.

There was general agreement that ICN could be a very interesting direction to
take.

It would take onboarding of all devices so that they had an appropriate
credential that could be validated against a (set of) trust anchors.

Also, because ICN does not involve making active (in the TCP sense)
connections to the sensors, it means that there is no inherent trust that
must be created in the sensors in order for them to communicate: they simply
announce their state and allow the network to do its thing.

At this point, the time ran out and the group walked to the social event at
the museum.


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

[homenet] Gateway 2 Gateway side meeting

[Michael Richardson]

As mentioned during the SNAC BOF, Wei, Qin and I have organized a side
meeting on Tuesday at 1800  (Eastern) in Philadelphia South.   That's 2200UTC.

Yes, the social starts at 18:30, and our plan is to keep the meeting on the
short side, and walk over the social event at 18:45 as a group.   It is
apparently, about 4 blocks.

The topic is about network connectivity and communications in large
commercial/residential buildings during emergencies.

I talked briefly about this topic at the SNAC BOF on Monday morning,
and we came to that BOF because we think that the same RA-based mechanism
might be one way to deal with the L3 connectivity that we are interested.

However, there are higher level connectivity concerns that we also want to
explore: identities, MQTT, CoAP vs ?

It is our observation that building emergency systems are presently all hard
wired, but if designed sensibly, could be a core part of a converged network
in the future.

For remote people, we will attempt to use https://whereby.com/gateway2gateway
for audio and slides only. (no video...)

Documents include:
  
https://github.com/mcr/building-local-emergency-comms/blob/main/presentations/Gateway-To-Gateway-Communication-sidemeeting.pdf
  
https://www.ietf.org/archive/id/draft-richardson-snac-building-use-case-00.html

Please feel free to forward this email!


--
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] naming drafts

[Michael Richardson]

Eric Vyncke (evyncke)  wrote:
> As we are halfway between IETF-113 and IETF-114, it is time to make a
> check as I have seen no revised version for those 2 ‘naming’ drafts.

Yes... I think that *I* said that I wouldn't have time.

> You may also have noticed that Ted’s ‘stub networking’ work is going in
> a SNAC BoF at IETF-114 (please attend and contribute to the
> s...@ietf.org mailing list).

> Therefore, the plan is to close Homenet early July 2022 if nothing 
changes.
> Hoping to see you in “Philly” to celebrate the achievments of Homenet !

will be there.

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

Re: [homenet] Looking for a Homenet co-chair

[Michael Richardson]

Michael Richardson  wrote:
>> progress the stub networks draft because I've been too busy doing
>> dnssd work, but that would be an example. I'd really like to progress
>> that draft /somewhere/, and it seems a /bit/ off-topic for dnssd. It
>> could go in v6ops, but it's pretty off-topic for v6ops. Same with
>> intarea.

>> But of course the stub networks document isn't what Homenet set out to
>> do.  It's just a building block that might lead there. The original
>> work of homenet doesn't seem to have caught on in the market, and I
>> think it's because we didn't have an adoption strategy. Personally I
>> think stub networks is a good bottom-up beginning to a strategy that
>> could ultimately produce an adoptable version of what we originally
>> tried to do. But again, only if people here want to pursue that.

> I thought that you *wanted* to go to INTAREA with this document.  I
> agree that it's an important document.

If we need to keep HOMENET open to do stub networks, then let's do that.



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

Re: [homenet] Looking for a Homenet co-chair

[Michael Richardson]

Ted Lemon  wrote:
> progress the stub networks draft because I've been too busy doing dnssd
> work, but that would be an example. I'd really like to progress that draft
> /somewhere/, and it seems a /bit/ off-topic for dnssd. It could go in
> v6ops, but it's pretty off-topic for v6ops. Same with intarea.

> But of course the stub networks document isn't what Homenet set out to do.
> It's just a building block that might lead there. The original work of
> homenet doesn't seem to have caught on in the market, and I think it's
> because we didn't have an adoption strategy. Personally I think stub
> networks is a good bottom-up beginning to a strategy that could ultimately
> produce an adoptable version of what we originally tried to do. But again,
> only if people here want to pursue that.

I thought that you *wanted* to go to INTAREA with this document.
I agree that it's an important document.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] naming drafts

[Michael Richardson]

sf> Sure, and as I said I'm not opposed to that. I suspect the
sf> best thing is for the authors to chat with our AD and see
sf> if he's either willing to AD-sponsor it, or to ask another
sf> WG to adopt, or try find a dispatch-like process to see if
sf> enough interest/review can be found that way.

It's the WG's document, and the WG can abandon it if it likes.
That would require some consensus seeking discussing.

If it turns out the WG isn't interested in the document, I sure wish that the
WG had said so a year ago though.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] naming drafts

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Michael, it would probably take you 20 minutes to write up an I-D
> describing a reasonable REST-based DDNS protocol, another 5 minutes to
> write a client implementation in Javascript, and one hour to write
> a robust server that is well integrated with Bind.

Yes, I did that.  It's in front of you.
As you said, there are three different specifications: why didn't you pick one?

We went back and forth multiple times as to REST vs AXFR from the HNA.
The feedback *FROM DNS OPERATORS* (which you aren't) was that they preferred 
AXFR.

>> If the device renumbers, or experiences a flash renumbering, how does it
>> know to re-register?

> All of these are interesting issues.  However, I don't see how they depend
> on whether the update is carried over HTTPS or AXFR.

It sure does, because DDNS as described by you is done by the end-device,
which can't see the IPv4 renumber, which btw, is all those devices support.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

Re: [homenet] naming drafts

[Michael Richardson]

Stephen Farrell  wrote:
> On 05/06/2021 19:46, Michael Richardson wrote:
>> Well, I'd be happy to discuss with this them again, but they'd have to
>> actually tell us what "DDNS" really is for them.

> Just to clarify: I don't think/claim DDNS is "better" than
> the proposal here, rather I don't find the arguments as to
> why this is "better" convincing, and so, given that DDNS is
> deployed, and has some similarity, I'm wondering if this
> spec really has much of a chance at gaining traction.

I don't think that they solve the same problem, nor do they have the same 
audience.

In particular, DDNS is very IPv4 specific and very divorced from ISP
operations, while the front-end naming is very IPv6 focused and integrates
much better with ISP operations.

Nothing we've done in Homenet has gained any traction, why do the chairs
suddenly care?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

Re: [homenet] naming drafts

[Michael Richardson]

Juliusz Chroboczek  wrote:
>>> Stephen and Juliusz expressed that they're still not convinced that
>>> DDNS isn't a good enough solution for the use case.

>> Well, I'd be happy to discuss with this them again, but they'd have to
>> actually tell us what "DDNS" really is for them.

> https://mailarchive.ietf.org/arch/msg/homenet/7JmkTCBSSMs5nnH3VWPj6JAL0cA/

Hi, thanks for that email, let me paste parts of it in.
I didn't find any clear definition of how DDNS works in that email.


>> In particular, I'd like to know if it's okay with them if an arbitrary 
device
>> in their home automatically signs up with a DDNS provider, disclosing 
their
>> IPv6 address to the world.

> No; unless the user has explicitly requested that a device be accessible
> from the Global Internet, it has no business publishing its IP address.
> I've tried to be very clear on that specific point in the mail linked 
above.

jc> Oh, nothing that geeky.  I copy my vacation photographs onto my NAS. I
jc> click the "share over the Internet" button on the NAS's web
jc> interface. The NAS performs DynDNS registration,

So, explain to me that this part works: "the NAS performs DynDNS registration"?

First, are you talking about RFC3007? No, I don't think so.  What's the
Performance Specification that describes this process?  Yes, I know where
the vendor specific documentation is.

Second, how are the credentials for that communication established?
What name does your NAS pick?   How did you communicate the credential to the
NAS?
Once the 14 year old in the house does this, how does the parent find out
about the name that was used?

Was it IPv4, IPv6 (and from which ISP, as our homenet architecture says we
can have more than one ISP. That's why we did all that BABEL stuff, right?),
and did the device publish a SLAAC derived IP, a privacy IP, a stable IPv6?

If the device renumbers, or experiences a flash renumbering, how does it know
to re-register?

So, let me know the details here, as these are the kind of things the HNA
mediated zone is dealing with.

> Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
> dynamic updates to be dependent on my CPE, which is buggy (it was provided
> by the major competitor of your employer) and isn't available at the

All sorts of devices can be buggy.
I don't expect to be dependent upon a buggy NAS either.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

Re: [homenet] naming drafts

[Michael Richardson]

STARK, BARBARA H  wrote:
> Stephen and Juliusz expressed that they're still not convinced that
> DDNS isn't a good enough solution for the use case.

Well, I'd be happy to discuss with this them again, but they'd have to
actually tell us what "DDNS" really is for them.

What specific solution are they talking about?  Tell us the whole story,
including how the credential gets into the device.

In particular, I'd like to know if it's okay with them if an arbitrary device
in their home automatically signs up with a DDNS provider, disclosing their
IPv6 address to the world.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] Fwd: I-D Action: draft-ietf-homenet-front-end-naming-delegation-15.txt

[Michael Richardson]

Daniel Migault  wrote:
> Please find the new version that is considering the discussions of the
> mailing list as well as comments received from Med.

Daniel, I was just proofreading, and you'll see a pull request "typos"

1. reading at the beginning, I didn't recall if we had concluded that we were
   going to mandate the AXFR to be XoT (AXFR over TLS) or not.
   We later reference [I-D.ietf-dprive-xfr-over-tls], but not section 4.5.1.
   Is it enough to say it in section 5.1?

2. What if the zone template provided by the DM has to change.
   (Because, for instance, the distribution server NS records change).
   Is the template retrieve each time the zone is signed?
   Once? (And never again?...)
   Based upon some TTL?

3. Section 4.6, we say "SHOULD" on TLS, but in which case, what exception are we
   thinking?  I guess we three will have to do another SHOULD/MUST audit.
   Noting that RECOMMENDED ==> SHOULD.


Section 5 has "" and "XX"... which feels like maybe we forgot to do some
IANA thing.  Maybe we should omit the placeholders?  What does the WG think?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

Daniel Migault  wrote:
> "Distribution Primary" is probably my preferred alternative as the
> replacement of Master by Primary makes a smooth transition from what is
> currently used. If that is fine with everyone I will update the
> document with it as well as the DHCP option draft. If not feel free to
> provide a better alternative.

I'm okay with that, but would list "Distribution Manager" as a nice TLA
preserving of "DM"

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

Ole Troan  wrote:
> Is this the same as a hidden primary name server?

That's Stealth Primary.
The DM is not a stealth primary, because it's not primary.
It hasn't got the DNSSEC signing keys, for instance.

>> On 5 May 2021, at 21:09, Michael Richardson 
>> wrote:
>>
>>  Ted Lemon  wrote:
    >>>> On May 5, 2021, at 11:51 AM, Michael Richardson 
>>>> wrote: 3) We would be happy to go with another term, but we don't
>>>> want to invent another term.  So, if the DNS anycast operator has
>>>> another term, then I'd go with it.
>>
>>> Authority database?
>>
>> I thought that you were asking who was an authoritive database of
>> operators.  Then I understood that you are suggesting "authority
>> database" as the term.
>>
>> Some ascii art, (so pick a sensible mono-spaced font, or use the
>> archive link):
>>
>> .-.  .-.  | S P | ---> | D M |\---\--\ `-'
>> `-' | | | V V V .-. .. ..  | Sec | | Sec| |Sec |
>> `-' `' `'
>>
>> S.P. = Stealth Primary Sec = Secondary D M = Distribution M*
>>
>> Note that the "DM" is usually not listed as an NS, but rather, two or
>> more "Sec" are what is listed.
>>
>> So, maybe "Distribution Authority" would make us both happy.
>>
>> --
>> Michael Richardson  . o O ( IPv6 IøT consulting
>> ) Sandelman Software Works Inc, Ottawa and Worldwide
>> ___ 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] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

[Michael Richardson]

Ted Lemon  wrote:
> On May 5, 2021, at 11:44 AM, Michael Richardson 
> wrote:
>> The end user might suffer slightly by having locally served reverse
>> names that are no longer connected: they should obsolete that zone
>> when they realize that their PD hasn't been renewed, until such time,
>> (if it was a flash renumber), they would be right to think that they
>> legitimately control them.

> In practice I don’t think this is an issue. The reverse lookup is
> usually triggered by receipt of a message from an IP address, so as
> long as the IP address is still in use internally, the presence of the
> reverse zone is wanted. When the address changes, the old zone becomes
> obsolete whether it continues to be served or not. The likelihood of
> the zone being re-allocated to some other network for which the
> original network will then do a reverse lookup is very small, so I
> don’t think there’s any reason to be concerned about this.

I agree with you completely.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

Ted Lemon  wrote:
> On May 5, 2021, at 11:51 AM, Michael Richardson 
> wrote:
>> 3) We would be happy to go with another term, but we don't want to
>> invent another term.  So, if the DNS anycast operator has another
>> term, then I'd go with it.

> Authority database?

I thought that you were asking who was an authoritive database of operators.
Then I understood that you are suggesting "authority database" as the term.

Some ascii art, (so pick a sensible mono-spaced font, or use the archive link):

.-.  .-.
| S P | ---> | D M |\---\--\
`-'  `-'|   |  |
V   V  V
 .-. .. ..
 | Sec | | Sec| |Sec |
 `-' `' `'

S.P. = Stealth Primary
Sec  = Secondary
D M  = Distribution M*

Note that the "DM" is usually not listed as an NS, but rather,
two or more "Sec" are what is listed.

So, maybe "Distribution Authority" would make us both happy.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

Re: [homenet] homenet naming drafts "terminology"

[Michael Richardson]

STARK, BARBARA H  wrote:
> I'm hoping not to start divisive discussion, but think it's better to
> discuss inside the WG rather than wait until IETF LC.

> Might the authors consider whether a word other than "Master" could be
> used in the terms Distribution Master, Reverse Distribution Master,

Yes, the authors discussed this at length, and we actually reached out to
quite a number of people for the terminology.  There were even emails on this
ML, I think.

1) DM is a term used in the DNS operational community.  It's not ubiquitous,
   but it is understood in many of the anycast DNS groups.

2) The term "stealth primary" is also used, but according to how it is used,
   that term would apply to the HNA, not the DM function.

3) We would be happy to go with another term, but we don't want to invent
   another term.  So, if the DNS anycast operator has another term, then
   I'd go with it.

> Perhaps "Primary" could be used? Or something else?

Nope, because that's confusing in the DNS space.
It's not a primary.

--
]       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] [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

[Michael Richardson]

Bernie Volz \(volz\)  wrote:
> And, something to ponder: - In 5.3, is there any value in potentially
> allowing a Relay Agent to supply these options to a server to
> potentially return to a client via the RSOO option (RFC6422)?
> I raise this question as it seems no documents have mentioned this and 
there
> was a case that recently came up where this was useful for another
> option, so just want to remind folks that it exists and to consider
> whether it could be used for these options.

We expect that most of the time, these options will be returned for the
reverse zone at the time that a IPv6 PD is initially done.
(And the rest of the time, it will be because forward zone is *also* configured
by the ISP)

Do Relay Agents delegated PD?  Alas, no.
So I can't see a use case for putting those options there.

One thing that I just thought of, and I don't remember if we discussed it at
all, was whether there was a need to synchonize these returned options with
the IA_PD lifetimes.I think not: because if the ISP renumbers the end
user (whether a flash number or controlled), then they can also just stop
synchronizing the reverse zone, and that effectively kills the reverse zone
content.   The end user might suffer slightly by having locally served
reverse names that are no longer connected: they should obsolete that zone
when they realize that their PD hasn't been renewed, until such time,
(if it was a flash renumber), they would be right to think that they
legitimately control them.

(I'm still miffed that Relay Agents have to snoof to learn PD, and nobody
seems to think this a problem)

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

[homenet] version of -13 of draft-ietf-homenet-front-end-naming-delegation posted

[Michael Richardson]

Hi,

I completed the CDDL description for section 14.
We hummed and hawed about YANG vs CDDL for describing this non-normative bit
of JSON, and settled on CDDL.  I think that I need to revise Appendix B to be 
sure it matches.

We have posted -13 because it has been more than two months, and while this
version still has a number of edits needed, we needed a firmer base on which
to discuss.

I was reading the diff, and I saw:

  XX,  and  as well-known ports in section 5.
  I thought that we didn't need any well-known ports?
  Can you comment Ray?

In reading the diff I have fixed one "teh"->"the" typo, and some { missing in
the reference for DANE.

There is a lot of cut text since -12, and maybe some of it was valuable.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

[homenet] Ted's stub network document: draft-lemon-stub-networks{, -ps}

[Michael Richardson]

Ted posted draft-lemon-stub-networks-ps awhile ago, and I have attempted to
collaborate with him on it.  There was a goof in the XML, so when he posted
-01 of the document, it was named draft-lemon-stub-networks, and overwrote
his previously uploaded solution document.

I think that this is a key architectural document on connecting IoT networks,
although there is some resistance to putting such a specific use case into
the title.

The Problem Statement is at:
   https://www.ietf.org/archive/id/draft-lemon-stub-networks-01.html

The solution document is at:
   https://datatracker.ietf.org/doc/draft-lemon-stub-networks/00/?include_text=1

Ted shared a (google) document with me to edit, but I'm not sure if he wants
that as the canonical place to contribute.

Here are some of my comments/questions about this document:

1) Perhaps "Stub Router" should be in the terminology.
   The terms: AIL, NAIL, NAL and OSNR are introduced but aren't really used.
   They aren't really that pneumonic.
   If anything, I'd like a cool TLA for "Stub Router"

2) There is advise about monitoring the RAs from the infrastructure router
   (which is probably the home CPE router), and soliciting them regularly.
   In effect, the Stub Router can't depend that the CPE router will remain
   alive for it's lifetime.
   That is, the RA lifetimes tell the client how long it may use the
   resource, but not how to determine if the router is alive.  Of course,
   power can disappear at any time.
   Ted: it seems that maybe neigh-cache entries already have all the timers
   and rechecks needed, and maybe the Stub Router can just watch for
   the NCE going Stale?

3) _Adjacent infrastructure link (AIL)_  that's the home LAN, right?
   Maybe it would clearer if it was just called that?

4) I'd like to add a state machine diagram to 3.1.1/3.1.2.

5) _IP addressability not present on adjacent infrastructure link_ (AIL)
   When the Stub router finds no IPv6 on the "LAN" link, then it advertises
   one.  I think that this prefix should be advertised as being _off-link_.

   To clarify for others: the stub router will have a ULA, and it might
   advertise ULA:0002::/64 on the AIL ("LAN"), and will number it's stub
   network with ULA:0001::/64.  It will do this with a PIO that does not
   include a default route.
   On the AIL, where there is also an IPv6 prefix (but not DHCPv6-PD),
   then it just seems like not putting a second ULA on top of the LAN
   for the purpose of communicating within the LAN seems better.
   While the off-link prefix can be used for e2e communications on the
   LAN, I think that the on-link prefix will be preferred.

   Perhaps this messes with DNS-SD discovery.



--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation

[Michael Richardson]

Eric Vyncke \(evyncke\)  wrote:
> Daniel, thank you for the update on this draft.
> May the WG expect a revised I-D (and possibly one for the DHCPv6 draft) 
in the coming days?

Hi, I posted a revised document, but there are still issues that I don't
expect to work out until Ray and I put his code through some more testing.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] I-D Action: draft-ietf-homenet-front-end-naming-delegation-12.txt

[Michael Richardson]

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-homenet-front-end-naming-delegation-12

This is the result of many weekly meetings among Ray, Daniel and I.
I have spend ~8 hours over the weekend thinking and rewriting.
This includes changing the title of the document.

I don't know if "Simple" is accurate: the intention is for it to be simple
for the home owner, compared to "vi mydomain.dnsfile.txt"

I have rewritten the abstract, and I'm not really happy with it yet.

Ray has running code for the DOI, and I have running code for the
provisioning, but so far we haven't made them meet yet.

Please read the diffs.

internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
> This draft is a work item of the Home Networking WG of the IETF.

> Title   : Simple Provisioning of Public Names for Residential 
Networks
> Authors     : Daniel Migault
> Ralf Weber
> Michael Richardson
> Ray Hunter
> Chris Griffiths
> Wouter Cloetens
> Filename: draft-ietf-homenet-front-end-naming-delegation-12.txt
> Pages   : 44
> Date: 2020-11-02

> Abstract:
> Home owners often have IPv6 devices that they wish to access over the
> Internet using names.  It has been possible to register and populate
> a DNS Zone with names since DNS became a thing, but it has been an
> activity typically reserved for experts.  This document automates the
> process through creation of a Homenet Naming Authority, whose
> responsibility is to select, sign and publish names to a set of
> publically visible servers.

> The use of an outsourced primary DNS server deals with possible
> renumbering of the home network, and with possible denial of service
> attacks against the DNS infrastructure.

> This document describes the mechanism that enables the Home Network
> Authority (HNA) to outsource the naming service to the DNS
> Outsourcing Infrastructure via a Distribution Master (DM).

> In addition, this document deals with publication of a corresponding
> reverse zone.


> The IETF datatracker status page for this draft is:
> 
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

> There are also htmlized versions available at:
> 
https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-12
> 
https://datatracker.ietf.org/doc/html/draft-ietf-homenet-front-end-naming-delegation-12


> Please note that it may take a couple of minutes from the time of 
submission
> until the htmlized version and diff are available at tools.ietf.org.

> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/


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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

[homenet] draft-thubert-6man-ipv6-over-wireless-06.html -- only you can help stamp out low-speed broadcasts

[Michael Richardson]

I hope the reply-to: 6...@ietf.org might survive, but I ask you to verify
when you Reply-All that it goes to that list only.

In https://www.ietf.org/id/draft-thubert-6man-ipv6-over-wireless-06.html
Pascal Thubert provides a well written survey explanation of the challenges
of ND across a wide variety of mesh-under network topologies.

Normally, I think of "mesh-under" to be technologies like 802.15.10,
but in reading it realize that the entire pantheon of 802 technologies
after 10base5 [Big Yellow Coax Cable-1] and 10base2 [Small Grey Coax Cable-2],
actually fall into the category of "mesh-under".

35 years of what I like to call "stupid layer-2 tricks".
 ... They all seemed to make sense at the time
  (to paraphase Douglas Adams's Arthur Dent).


Specifically, they were tricks because IPv4 gave us such pathetic subnet
limitations, and broadcast emulation was costing more and more bandwidth.
We have extensive broadcast mitigation techniques in IPv6.
We use of various multicast groups such that, given we had a
[Big-Yellow-Coax-Cable], we can push multicast filters down into hardware and
avoid waking that overworked Sun-2 20Mhz 68020 CPU for stupid things.
The reality today is that none of that matters: the host registers the
multicast groups it cares about with the switch using MLD, we hope the IGMPv6
snooping works
(I have a closet where IPv6 ND is broken, I think because it isn't working,
and I can't get in due to lockdown rules to investigate in person.  IPv6-LL
works, btw...)

What I'm trying to say is that the model we have about the physical network
has been wrong for 25 to 30 years now.  Yet, we continue to design networks
as if that model is correct, and the folks over at IEEE continue to try to
emulate things.  It's a deadly embrace in which neither party has the guts to
point out that whatever clothing the emperor thinks they are wearing are not
in fact the ones we observe.

Now, in homenet we have talked about putting /128s into our visible and
debuggable routing protocol, vs putting (to-be-randomized) /48 L2 addresses
into the invisible L2 "switching" protocol.
The /128 routing was deemed "too complex" by some, who are somehow content to
do exactly the same thing at L2 using hardware implementations that can't be
upgraded... ever.

We have all sorts of mechanisms to deal with discovery across multiple
networks, given that the wired and wifi networks are bridged, yet half the
devices can see both at the same time.

In ROLL, we have the /128s in the routing protocol, and some profiles have
adopted RFC8505, but not all yet.  So, we got halfway there, but yet all the
way.

So, please read Pascal's draft.   It sat open in a tab on my desktop for too 
long.
It's a very nice and educational survey.

I am not quite sure what the actionable item in it is yet.
I don't know what 6man should do exactly about it.
It's not yet a loud call to action.

The draft hints that using RFC8505 more is a good idea, but I'm not sure it
actually says this.

To my mind, the question is really about deployment.
If Cisco enterprise class APs supported RFC8505 would any wifi client devices
consider supporting it?  Is there a killer application that makes it worth
it?  Maybe in warehouse/logistics situations. I don't know exactly where it
might take off.

Maybe it can be shown that it helps avoiding dropped packets when roaming
among APs within an Enterprise.  Is there some other situation?

Can routing IPv6 /128s that have mapped IPv4 in them keep all the IPv4 ARP
multicast traffic away from the wireless media?


[Big Yellow Coax Cable-1] 
https://en.wikipedia.org/wiki/Vampire_tap#/media/File:VampireTap.jpg
  https://en.wikipedia.org/wiki/10BASE5
[Small Grey Coax Cable-2] https://en.wikipedia.org/wiki/10BASE2

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Stephen Farrell  wrote:
>> Stephen Farrell  wrote:
>>
>> > On 29/09/2020 19:41, Michael Richardson wrote: >> It will be good if
>> we can get a document from the MAC randomization >> proponents (if
>> there is such a group), to explain the thread profile.  >> I don't
>> think it includes active compromised hosts.
>>
>> > That is a problem yes. I no longer think "compromised host" is the >
>> correct term there though. In the case of android, we found google
>> play > services regularly calls home linking all these identifiers and
>> more > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be
>> very
>>
>> I feel that you have confounded two things, and I don't think it's
>> helpful.  I won't dispute your observatrions about surveillance
>> capitalism, but I feel that you've sensationalized what I thought was
>> a pretty specific technical point. Namely: You can't see into the L3
>> layer of WIFI, even when there are ARP broadcasts, unless your are
>> also part of that L2 network.

> I disagree about sensationalising, obviously;-)

> The point is that we tended to think of a compromised host as one that
> had been subject to a successful attack often run by an unknown
> party. For mobile phones, the privacy adversary seems more often to be
> an entity that the phone user has accepted one way or another, whether
> that be the OS or handset vendor or whoever wrote that cute spirit-
> level app.

My take home from your work is that MAC address randomization is a useless
waste of time.  It causes significant costs to the network operator(s) without
actually providing any benefit to the mobile phone owner, because the
adversary is inside the device, invited in by the owner.
In such a situation, MAC randomization feels like security theatre to me.

[I'm reminded of various systems of magic in fiction, where you are safe as long
as you don't unwittingly invite the bad guys in]

You have defined the security perimeter as being from "top" of the phone.
(Between the screen and the human)

I have defined the security perimeter as being the "bottom" of the phone
(between the phone and the Internet).

I think that we can do more here, and I think that the cost to the operator
(moving from unencrypted, MAC-address excepted networks, to encrypted 802.1X
authenticated networks with provisioned identities) with some correspondant
benefits to the operator as well as the end user.

    > PS: to be clear - the above's not really anti-google - we've seen
> similar looking traffic from handset vendors' pre-installed s/w too.

Agreed.

--
]   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[


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Stephen Farrell  wrote:

> On 29/09/2020 19:41, Michael Richardson wrote:
>> It will be good if we can get a document from the MAC randomization
>> proponents (if there is such a group), to explain the thread profile.
>> I don't think it includes active compromised hosts.

> That is a problem yes. I no longer think "compromised host" is the
> correct term there though. In the case of android, we found google play
> services regularly calls home linking all these identifiers and more
> (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very

I feel that you have confounded two things, and I don't think it's helpful.
I won't dispute your observatrions about surveillance capitalism, but I feel
that you've sensationalized what I thought was a pretty specific technical
point. Namely:
You can't see into the L3 layer of WIFI, even when there are
ARP broadcasts, unless your are also part of that L2 network.

I'm sure that Google Play calls home and tells Google all the your
L2/L3/IMEI/etc.  I don't doubt it.

I don't see how this relates to a local passive eavesdropping observing the
L2 frames with the encrypted L3.  One not involved with the operation
of the wifi, nor connected to that link.

Unless you are saying that Google Play operates as active eavesdropper on all
the networks on which it is connected?  I.e. it sends the L2/L3 mappings for
all devices on that network?

> More on-topic, I do think MAC address randomisation has a role to play
> for WiFi as it does for BLE, but yes there is a lack of guidance as to
> how to implement and deploy such techniques well. It's a bit tricky
> though as it's fairly OS dependent so maybe not really in scope for the
> IETF?

The IEEE has a spec on how to do MAC address ramdomization.
It says nothing about how to automatically update the accept-list rules
created by RFC8520, or RFC8908/RFC8910 (CAPPORT).  Or EAP-FOO.

> (For the last 3 years I've set a possible student project in
> this space, but each time a student has considered it, it turned out
> "too hard";-)

:-(

--
]   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] [Captive-portals] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

<#secure method=pgpmime mode=sign>

Brian Dickson  wrote:
> Any host/interface that uses ARP (not sure whether any flavor of WiFi
> does, or if so which flavors), exposes the L3/L2 mapping.

Yes, WIFI does use ARP. On all flavours.

Encrypted WIFI, which is mostly the default now, encrypts everything above
the L2, so the L3 part of the mapping is not seen by passive EM observers.

ARP broadcasts as you mention, so other stations on the network could see the
mapping, and the AP by default helpfully re-encrypts broadcasts to every
station.  But, that's not a passive observer: the observer is on the network.
Many APs filter ARP broadcasts as being useless chatter.

> So, wired
> IPv4 for certain (except in very locked-down enterprise settings with
> static MAC addresses, perhaps) leaks this information to every host on
> the same broadcast domain (same subnet and possibly additional subnets
> on the same LAN/VLAN).

Yes, but that's not wifi.  Phones do not have wired connections.

> ARP L2 broadcasts solicit information about IP addresses, and at a
> minimum each such query exposes its own MAC and IP address. Responses
> may be unicast or broadcast, not sure which.  An active compromised
> host can easily solicit that information by iterating over all the IP
> addresses on the subnet and performing an ARP for each one.

It will be good if we can get a document from the MAC randomization
proponents (if there is such a group), to explain the thread profile.
I don't think it includes active compromised hosts.

Such hosts can also ARP/ND spoof, and can even do that for the router (".1"),
capturing all the traffic on the network.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide




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

Re: [homenet] [Int-area] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Christian Huitema  wrote:
> Martin is making an important point here. There are a number of privacy
> enhancing technologies deployed at different layers: MAC address
> randomization at L2, Privacy addresses at L3, various forms of
> encryption and compartments at L4 and above. Each of these technologies
> is useful by itself, but they can easily be defeated by deployment
> mistakes. For example:

You are spot on.
But, even your four points muddle things.

We need some diagrams that we can all agree upon, and we need to name the
different observers.

Each thing defends against different kinds of observers, and not all
observers can see all things.
Some observers may collaborate (I invoke, the WWII French resistance emotion
for this term...)
Some observers may have strong reasons not to.

> 1) Using the same IP address with different MAC addresses negates a lot
> of the benefits of randomized MAC addresses,

This assumes that a single observer can observe both at the same time.
WEP++ leaves MAC addresses visible, but encrypts the rest of L3 content.

--
]   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[

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

Re: [homenet] [Captive-portals] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Pascal Thubert \(pthubert\)  wrote:
> Hello Dave and all:

> So far I have not seen how the MAC randomization deals with:

> - differentiated environments - the preferred behavior on a highway or
> at a coffee shop may differ from that at in a corporate or a DC
> network. In the corporate network, we can expect something like .1x to
> undo the privacy, for good reasons. And we can expect state to be
> maintained for each IP and each MAC. When a MAC changes, there can be
> unwanted state created and remaining in the DHCP server, LISP MSMR,
> SAVI switch,  etc... Privacy MAC is only an additional hassle that we
> want to minimize.

If we can assume 802.1X using an Enterprise scheme, and using a TLS1.3
substrate, then if the identity resides in a (Client) TLS Certificate, it
will not been by a passive attacker.

The MAC address is outside of the WEP encryption, so it is always seen, even
if the traffic is otherwise encrypted.

An EAP-*TLS based upon TLS1.2 would reveal the identity, at least the first
time.  Perhaps this is a reason to support resumption tokens in EAP-TLS!

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Ralf Weber  wrote:
>> While I don't object to a BOF, I don't know where it goes.
>> What I see is that much of this problem needs to be resolved through
>> increased use of 802.1X: making WPA-Enterprise easier to use and setup,
>> this changing core identity from MAC Address to IDevID.
>>
>> My understanding is that Apple intends to randomize MAC every 12 hours,
>> even on the same "LAN" (ESSID), and that they will just repeat the WPA
>> authentication afterwards to get back on the network.

> I of course don’t know Apples intentions, but what you are describing is 
the
> behaviour of early iOS 14 beta versions. However this behaviour has 
changed
> in later beta versions and the released iOS 14.0 version to have a random 
Mac
> per ESSID and not change that over the lifetime of the device (at least 
no so
> far on my devices at home), which I think is more in line what the rest of
> the industry does.

That's interesting news.
Why did they try something different in the beta?  Maybe they thought that
the industry was ready for this, but were wrong?
I heard about this change from Tiru Reddy.

It would be great if this BOF elicited public statements and/or public policies 
about
Google and Apple's intentions in this space.  If it's their goal to go in the
direction I outlined, then it would be good to know.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide


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

Re: [homenet] [Captive-portals] [EXTERNAL] Re: [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Martin Thomson  wrote:
> Maybe that is out of scope for your draft, but it shouldn't be out of
> scope for a group that attempts to look more closely at providing
> advice for dealing with these features.

> (Does this thread really need to be cross-posted so widely?  Can we 
decide on a single venue?)

Blame me :-)
It's only three lists.
It's not like I CC'ed to ADD, emailcore and the dns* groups :-)

I didn't think that Yiu's post to int-area would catch all the right flies.
Apparently it might get a BOF ML soon.

and I felt that it deserved wider review and excitement.
Our mailman strips off Reply-To: since we did that DMARC avoidant hack
(AFAIK), so redirecting replies only works if we all agree.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Brian Dickson  wrote:
>> I don't get the NAPT issue though.
>> The NAPT issues are because DHCP gave the device a different IP(v4), 
right?
>> If you solve persistent DHCP, then you solve those, don't you?
>>

> I think there are some environments where that isn't technically accurate,
> or might not be 100% accurate.
> E.g. The difference between DHCP6 and that other wacky thing that is doing
> random self-assigned IPv6 addresses.

Sure.  If there is a port mapping (or PCP created incoming ACL for IPv6),
which is bound to a particular IPv6 (however assigned), and that the IPv6
changes, then the mapping will break right?
This is independant of MAC address randomization right?
If we changed the MAC address, and then kept the IP address involved, then ND
would fix things up, and things would continue just fine.

> (E.g. maintaining the IP address when the MAC changes, defeats at least 
one
> possible purpose of changing the MAC.)

I strongly disagree here.
We use privacy IPv6 addresses in order to keep legitimate distant end points
(and their associated snoops) from tracking one for place to place.

We use different MAC addresses for different networks to keep from being
tracked by a federation of local snoops from place to place.

We change our MAC address at the same network to hide our time of use and
presence from local snoops.  But, also to deal with malicious attackers who
put up a common ESSID ("Starbucks").   We can, and do encrypt our IPv6
address on those networks.  But, we can't encrypt our MAC address, because as
you say, it used for media access control.

> I sense a potential rat-hole, but also the possibility of finding common
> ground to fix a bunch of things that are problematic to some degree or
> another.

I hope so too.

> I'm hopeful that something like 802.1x can be made use of effectively, but
> again a lot depends on the use cases and will likely require pretty deep
> dives on each of the relevant technologies and implementations.

> IMNSHO, MACs should be relegated to the role reflected in their name: 
Media
> Access Control, basically a disambiguator, not an identity.

> Maybe MACs should be used the way the initial values selected by the two
> parties doing DH key exchange are used, just as a stepping stone in
> establishing a cryptographically-strong "thing" that only they know.
> I.e. use the initial MAC (regardless of what it is) as an initial layer-2
> communications things, during the set-up of {whatever the BOF/WG output
> is}, after which the MAC gets changed to {something else}.

An interesting idea.

--
]   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[


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






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

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Bob Hinden  wrote:
> I have read the emails and the draft 
.   I am not clear what the goal of the BOF 
is.

> Could the proponents state it clearly?

I can't speak for the proponents, but at the simplest, one could add:
  "how can we do X if the MAC cannot be used as identity"

> • LAN gateway NAPT forwarding - (PRESENTER TBD)
> • Static NAPT policies - (PRESENTER TBD)
> • Persistent DHCP IP address assignments - (PRESENTER TBD)
> • Device-to-user or group association for malware protection - (PRESENTER 
TBD)
> • Device-to-user or group association for parental controls - (PRESENTER 
TBD)
> • Device-to-user or group association to restrict or authorize unwanted
> or unverified device connections to the LAN - (PRESENTER TBD)

I don't get the NAPT issue though.
The NAPT issues are because DHCP gave the device a different IP(v4), right?
If you solve persistent DHCP, then you solve those, don't you?

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide



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

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

Damn. Spelt captive-portal without the s again.  Reposting, sorry for 
duplicates.
I hate when WG names and list names do not match, and that we can't have 
aliases.
And I think that reply-to gets filtered.

Archived-At: 
<https://mailarchive.ietf.org/arch/msg/int-area/14Skgm84GslPZ9UcGoWY3uzmK6I>
To: int-a...@ietf.org, captive-por...@ietf.org, homenet@ietf.org
From: Michael Richardson 
Date: Tue, 22 Sep 2020 16:34:33 -0400

This thread was started today on the INTAREA WG ML.

While I don't object to a BOF, I don't know where it goes.
What I see is that much of this problem needs to be resolved through
increased use of 802.1X: making WPA-Enterprise easier to use and setup, this
changing core identity from MAC Address to IDevID.

My understanding is that Apple intends to randomize MAC every 12 hours, even
on the same "LAN" (ESSID), and that they will just repeat the WPA
authentication afterwards to get back on the network.   If the per-device
unique policy (including CAPPORT authorization) can be tied to the device
better, than the MAC address based "physical" exception can be updated.

But, WPA-PSK doesn't work, because it does not, in general, distinguish
between different devices.

It can be made to work if every device is given a unique PSK, and there are
some successful experiments doing exactly that.  Mostly it just works, but
the challenge is communicating the unique PSK through an unreliable human.
BRSKI can certainly do this, and it can leverage that unencrypted ESSID
present at most hospitality locations to get onto the encrypted
WPA-Enterprise.  Or BRSKI-TEEP, or some other BRSKI-EAP method.  The
unencrypted SSID is not going away at those locations.

Thus QR-code based methods are best, yet those do not work for many IoT
devices.   EMU's EAP-NOOB can help in certain cases, but we, as a community
need be clear on what direction we want to go.  One answer is that IoT
devices have little reason to randomize their MAC if they are not generally
ported.


On 2020-09-22 3:49 p.m., Lee, Yiu wrote:
> Hi team,
>
> We proposed a BoF. The agenda is in
> https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and the
> proposal is in
> https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md.
>  You
> can also find the draft here
> https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.
>
> At this stage, we are looking for inputs for more use cases and interests
> of working together in this domain. Please post your comments in the
> mailing list.
>
> Thanks
>


--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide



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

Re: [homenet] [Int-area] Evaluate impact of MAC address randomization to IP applications

[Michael Richardson]

This thread was started today on the INTAREA WG ML.

While I don't object to a BOF, I don't know where it goes.
What I see is that much of this problem needs to be resolved through 
increased use of 802.1X: making WPA-Enterprise easier to use and setup, 
this changing core identity from MAC Address to IDevID.


My understanding is that Apple intends to randomize MAC every 12 hours, 
even on the same "LAN" (ESSID), and that they will just repeat the WPA 
authentication afterwards to get back on the network.   If the 
per-device unique policy (including CAPPORT authorization) can be tied 
to the device better, than the MAC address based "physical" exception 
can be updated.


But, WPA-PSK doesn't work, because it does not, in general, distinguish 
between different devices.


It can be made to work if every device is given a unique PSK, and there 
are some successful experiments doing exactly that.  Mostly it just 
works, but the challenge is communicating the unique PSK through an 
unreliable human.
BRSKI can certainly do this, and it can leverage that unencrypted ESSID 
present at most hospitality locations to get onto the encrypted 
WPA-Enterprise.  Or BRSKI-TEEP, or some other BRSKI-EAP method.  The 
unencrypted SSID is not going away at those locations.


Thus QR-code based methods are best, yet those do not work for many IoT 
devices.   EMU's EAP-NOOB can help in certain cases, but we, as a 
community need be clear on what direction we want to go.  One answer is 
that IoT devices have little reason to randomize their MAC if they are 
not generally ported.



On 2020-09-22 3:49 p.m., Lee, Yiu wrote:

Hi team,

We proposed a BoF. The agenda is in 
https://github.com/jlivingood/IETF109BoF/blob/master/109-Agenda.md and 
the proposal is in 
https://github.com/jlivingood/IETF109BoF/blob/master/BoF-Proposal-20200918.md. 
You can also find the draft here 
https://tools.ietf.org/html/draft-lee-randomized-macaddr-ps-01.


At this stage, we are looking for inputs for more use cases and 
interests of working together in this domain. Please post your comments 
in the mailing list.


Thanks



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

Re: [homenet] auto-passthrough from ISP routers

[Michael Richardson]

otr...@employees.org wrote:
>>>> On 23 Jul 2020, at 18:58, Michael Richardson  
wrote:
>>>>
>>>> This is very cool.
>>>> Is it written up as a specification somewhere?  What is the signal 
that the
>>>> device behind is a router, and not a PC?
>>>>
>>>> Why isn't homenet standardizing this?
>>>
>>> Cause it's architecturally "challenged"?
>>
>> The working group or the solution?

> Not sure how you could interpret that as pointing to the working group.

> The solution obviously.
> IPv4 "pass through" implies sharing the IPv4 address among multiple nodes.
> Creating all sorts of tricky problems.

Yeah, it's a weird situation where it basically is forced/transparent
proxying it's management port, and then letting everything else through.
Definitely a place where moving the management to IPv6 would be easier.

I think that the signaling that is observed to cause the bypass should be 
written down.
That it nicely does DHCPv6-PD proxying is very nice.

I think that had this description come to the WG five years ago, we would
have thought about it deeply.

--
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] auto-passthrough from ISP routers

[Michael Richardson]

STARK, BARBARA H  wrote:
>> From: Michael Richardson 
>>
>> In the ADD WG, Barbara STARK, BARBARA H  wrote:
>> > [BHS] While my ISP requires me to use the CE router they supply, I’ve
>> > never had an issue connecting that to my own router and then running
>> my
>> > home network from my router. The CE router from my particular ISP
>> > (YMMV) even automatically passes on the public IPv4 address it acquires
>> > and a /64 IPv6 prefix to my router (so IPv4 just has the single NAT and
>> > IPv6 works great). I have total ability to choose any router I want and
>> > configure that router as much as that router vendor’s GUI allows (e.g.,
>>
>> 1) Does your ISP provides router auto-detect that there is another router
>> behind
>> it, and turn itself into a modem only?  or did you have configure that?

> The ISP router auto-detects the presence of a router on its LAN and
> uses a capture screen to ask the user if they want the ISP router to go
> into "IPv4 passthrough" mode. The ISP router does not become a

This is very cool.
Is it written up as a specification somewhere?  What is the signal that the
device behind is a router, and not a PC?

Why isn't homenet standardizing this?

> PPPoE is only legacy (old ADSL). The IPv4 passthrough does work there
> (because the ISP router is still a router, as described above). IPv6 on
> legacy is 6rd with a /60 -- so the IPv6 stuff is different. Fiber,
> VDSL, and Gfast (and some newer ADSL) are IPoE (PTM), and not IP o
> PPPoE o ATM.

Nobody has told Bell Canada the PPPoE is legacy :-)

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

[homenet] auto-passthrough from ISP routers

[Michael Richardson]

In the ADD WG, Barbara STARK, BARBARA H  wrote:
> [BHS] While my ISP requires me to use the CE router they supply, I’ve
> never had an issue connecting that to my own router and then running my
> home network from my router. The CE router from my particular ISP
> (YMMV) even automatically passes on the public IPv4 address it acquires
> and a /64 IPv6 prefix to my router (so IPv4 just has the single NAT and
> IPv6 works great). I have total ability to choose any router I want and
> configure that router as much as that router vendor’s GUI allows (e.g.,

1) Does your ISP provides router auto-detect that there is another router behind
   it, and turn itself into a modem only?  or did you have configure that?

2) I can imagine how a cable modem/router could become a bridge, and all
   would be well.
   But, I think that AT&T is more in the DSL space with PPPoE.
   Does this work for PPPoE, and if so, do you have to put the PPPoE
   password, into your "own" router?
   The ppp password is among those things that ISPs like to provision 
automatically.

I'm really hoping that there is some technology out there that I'm ignorant of.
(but, I'm cynically thinking that the technology involves sending Barbara out
in a GPS equipped truck)

--
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] lack of discussion

[Michael Richardson]

STARK, BARBARA H  wrote:
> Hi homenet, While Michael and Daniel put some effort into their draft
> prior to IETF 107, there's been no subsequent discussion of it on the
> list. And no new activity on the draft.  In the absence of activity,
> Stephen and I don't think homenet should request time during IETF 108.

Hi, I agree that our document is not making as much progress as we'd like.
I haven't been able to get back to testing Ray's code,  and Ray was ill,
and Daniel has been getting dial tone when he has tried to engage us :-)
So I feel that invoking closure on us is a bit premature given the global
situation.   I do not object to having no meeting at 108.

> It may be time to close homenet and move the draft elsewhere (like
> maybe INT area).

{I, generally, dislike "closing" WGs, as it seems so much harder
to re-open than to re-charter, but in any case the ML will stay open,
I'm sure.  I am very sad about the HOMENET situation.}

> If you disagree, this is best expressed this through technical
> discussion and activities.

I believe that Ted's discussion was very relevant, but it did not go
anywhere beyond the 6 or so of us who have chatted about that.

I believe that Ted's ideas should go to go 6man.
{I believe that the home network situation is significant more relevant to e2e
architecture than SPRING}

I think that the most important thing that has happened in the past two years
is TR-369 (UCP), which I know Barbara had a hand in.   I would like to see
this work discussed more widely in the IETF.

--
]   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] biggest L2 domain

[Michael Richardson]

Ted Lemon  wrote:
> If it turns out that there is some performance benefit to making a
> port-to-port, point-to-point link for the router pair, then we can do that
> adaptively. That’s an optimization: it need not be where we start, and 
indeed
> back when we were initially working on this, I don’t think there was any
> assumption that we would try to constrain links to being either
> point-to-point or multi-station.

I'm not arguing for doing this.
I'm asking what happened to the text that said that we weren't.

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

Re: [homenet] biggest L2 domain

[Michael Richardson]

Gert Doering  wrote:
> On Fri, Dec 13, 2019 at 09:54:08AM -0500, Michael Richardson wrote:
>> I thought that we wrote somewhere in RFC7368 that the Homenet router 
should
>> collect as many ports as possible together into a single L2 zone.
>> I can't find that text right now. Did it go away?
>>
>> In testing, we have found a device that does not put it's 5-"LAN" ports 
into
>> a bridge.  That's probably a missing configuration, but in the meantime, 
we
>> have an interesting HNCP and naming setup!

> My understanding of "homenet" and "HNCP" devices has always been "every
> single hole in the box is a routed port".  Now that's my understanding and
> not necessarily written down somewhere.

It wasn't intended to be automatic, but rather based upon provisioned
knowledge that a device had.

The intent was to avoid routing-at-layer-two (i.e. spanning tree, etc.), but
not to replace switches.

--
]   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[

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

[homenet] biggest L2 domain

[Michael Richardson]

I thought that we wrote somewhere in RFC7368 that the Homenet router should
collect as many ports as possible together into a single L2 zone.
I can't find that text right now. Did it go away?

In testing, we have found a device that does not put it's 5-"LAN" ports into
a bridge.  That's probably a missing configuration, but in the meantime, we
have an interesting HNCP and naming setup!

--
]   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] Support for RFC 7084 on shipping devices...

[Michael Richardson]

Ted Lemon  wrote:
>> Too bad then... I still fail to see why the model cannot be
>> generalized to more powerful nodes. 

> Because it is maximally complex?   :]

> You say that RPL has scaled to millions of nodes.   Where is this
> deployed in production?   What are the leaf nodes doing?   With what
> are they communicating?

Diagram to help:
  A   B
  |   |
 ++---+---++ <-network 1
 |||
 CDE
 |||
   +-+-+(2) +-+-+(3) +-+-+(4)
   |   ||   ||   |
   F   GH   IJ   K


1) the deployments I'm aware of involve many thousands (4-zeros) of
   electricity meters (Automatic Metering Infrastructure) (sometimes
   including gas or water meters as leaves). 
   I'm *unaware* of any LLNs that have 10^6 nodes in a single LLN.
   Unfortunately Pascal can't tell you who, because of NDAs he has with his
   customers.  I've been shown evidence with stuff blacked out/redacted.

2) the leaf nodes are sending readings up on a MP2P topology.  There isn't
   much cross-traffic.  So in a homenet context, this is equivalent to there
   being 30 routers in the home, and no PCs/laptops/etc, rather than 3
   routers with 10 desktops each.
   In the homenet situation, cross-traffic would be traffic that somehow goes
   from network 2(F) to network 4(K) without going across network 1.
   In an LLN there might be other paths across the radio links that would
   permit F<->K traffic without using network 1, and P2PRPL is a protocol
   that could find it.

3) the leaf nodes in AMI talk to HQ only.
   There are lighting LLNs that are all cross-traffic though.


Some other things to note:
  a) RPL is not particularly self-configuring, and probably has more
 parameters to tweak than other protocols, but getting it exactly right
 only really matters when you have to worry about bandwidth and energy.

  b) to date, RPL hasn't had a lot of "Internet Standard"-style interop
 validation.  All of the deployments I'm aware of are single-vendor, or
 involve one or two vendors working closely together.  This is sad.

  c) While RPL has a single root to which all traffic flows, in the diagram,
 both A and B would announce their own DODAG in a DODOG Information
 Object (DIO), and the DIO would include Prefix Information Object, which
 is the equivalent of an RA.
 Routes in the network are usually /128 routes, but if one used DHCPv6-PD
 or HNCP to get a /64, one could announce that equally well.
 Announcing exclusively /128s (with L=0, so offlink) does do nice things
 for wifi and mobility.

-- 
]       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] Support for RFC 7084 on shipping devices...

[Michael Richardson]

Mikael Abrahamsson  wrote:
>> The deployment challenge of that is that every router must support HNCP 
and
>> must support SADR.

> Yes, there is indeed a problem here with incremental deployment.

> That's why I think there might be upside in "homenet lite" which drops the
> arbitrary topology requirement and keeps the "routed home" requirement, 
but
> also brings with it the service discovery part. Perhaps it's an easier 
chunk
> of code to deploy if vendors do not need to implement full homenet but
> instead implement RFC7084 plus a few other things?

So, 7084++ or HomeNet-Lite.  

> High level would be to use DHCPv6-PD, turning sub-router WAN firewall off 
and
> enabling service discovery proxies, as I outlined in previous email.

I agree. 7084bis should suggest downstream DHCPv6-PD be supported, and we
need to explicitely signal there when HNCP is available so that we don't wind
up double allocating things, etc.

-- 
]   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] Support for RFC 7084 on shipping devices...

[Michael Richardson]

Mark Smith  wrote:
> Perhaps ANIMA is an alternative? It has seemed to me that home networks
> might be just a more specific case of autonomic networks.

> For example, they've been defining a Generic Autonomic Signalling
> Protocol (GRASP).

GRASP has some overlap with HNCP, but HNCP isn't really the issue.
Homenet has a routing protocol (BABEL).  It was going to be OSPFv3, and we'd
add the information flooding that HNCP wound up doing into OSPFv3, but that
"didn't work" and the WG (mysteriously) abandonned that idea.

ANIMA's GRASP is also not a routing protocol: ANIMA builds an overlap control
layer with IP over IPsec over IPv6LL tunnels, and runs RPL (RFC6550) as
the routing protocol for the control plane.  While the resulting ACP shares
some properties with the desired HOMENET routing goals, it's not the same
thing at all.

-- 
]   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] Support for RFC 7084 on shipping devices...

[Michael Richardson]

Ted Lemon  wrote:
> I’ve been involved in some discussions recently where the question has
> come up: how good is support for RFC7084 in shipping routers?   And
> what gaps exist in RFC7084 that could cause problems?   And in cases
> where RFC7084 support either isn’t present, or isn’t useful because no
> IPv6 or because ISP is delegating a /64, what things might work and
> what things might not, if we want bidirectional reachability between
> two separate network links in the home.

I see it (7084) in most every router at pubs in Ottawa.  
They are connected by one of the incumbents that also does TV (think sports
channels in bars). There isn't always an IPv6 uplink (30% of them have IPv6),
but there is consistently an IPv6 ULA visible.
Less often in coffee shops (WPA is on chalkboard), where it seems that they
tend to either buy from smaller ISPs (and provide their own crappy router),
or they are a multinational with hostile portals.

> So for example, suppose we have "CE Router," which supports RFC7084,
> including prefix delegation.  And we have "Internal Router" on that
> network requests a delegation, and gets a prefix from the CE router.
> Presumably that prefix is out of a larger prefix that CE Router got
> from the ISP.  Great so far.  Let’s call the network on the southbound
> interface of Internal Router “South Network”. Let’s call the network on
> its northbound interface, which is also the network on CE router’s
> southbound interface, “North Network.”

But 7084 has no requirements for DHCPv6-PD server.

> Similarly, suppose we have a network where unfortunately PD Isn’t
> available internally, but IPv6 is present on the northbound interface
> of the internal node and southbound interface of the CE router.
> Suppose further that Internal Router allocates itself a ULA prefix and
> advertises that as reachable and on-link on its southbound interface,
> and as reachable but not on-link on its northbound interface.   Will
> that be blocked at layer 2 by CE Router?   I’m sort of assuming here
> that the CE router is managing the North Network link, which is
> probably WiFi.

That would probably work.

> The goal here is to have bidirectional reachability between the two
> nodes on IPv6 using either a global prefix or a ULA.  The concern is
> that something could prevent each of these cases from working.   What
> I’m really curious about is whether people have experience with doing
> communications of this type using actual routers that ISPs are
> shipping.   Is this “internal network” scenario part of acceptance
> testing for these routers?  Is this all a big question mark?   In
> principle this should all work, unless RA guard is hyperactive in CE
> Router.   But what about in practice?

I have never tried it, but I'm keen to.

-- 
]   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] DNCP/HNCP Revisited

[Michael Richardson]

Ray Hunter (v6ops)  wrote:
> First observation: Running HNCP over L2TPv3 breaks HCNP because L2TPv3 
breaks
> UDP fragmentation (works as designed).

> The L2TPv3 tunnel has a lower MTU than the local LAN, and does not report
> ICMP PTB, so HNCP packets in one direction get through, but replies get
> dropped.

> Early drafts of HNCP stated that UDP fragmentation would not be broken in 
the
> Homenet for the foreseeable future. Well I managed to break that ;)

(Why are we using a L2 tunnel?  So that a few of us, including Ray, can hack on 
stuff together)

> Changing the MTU on the LAN interfaces of my routers to 1280 brought
> everything back to normal, as expected.

I think that the right answer is for the software to assume a 1280 MTU.
Someone could write an HNCP extension to do PLPMTUD inside afterwards to
increase the size if desired.

> Question: If Homenets are moving to flat L2 meshes over foo, as some have
> said, will this impact HNCP?

Unlikely, in my opinion, because "good" L2 meshes will preserve the 1500 byte 
MTU.

> Question: As a simple mitigation, is there any way of manually signalling 
to
> the kernel that ALL UDP packets on port 8231 should assume an PMTU of 1280
> octets?

> That wouldn't require any specification change and would allow HNCP to 
work
> reliably in the presence of tunnels and varying MTU's that don't match the
> local interface MTU.

I think that the HNCP code can do this.

--
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] IPv6 & firewall config in a home net

[Michael Richardson]

Mikael Abrahamsson  wrote:
> This is the first time I've seen anyone make this claim (I guess
> related to GDPR). I've gone through GDPR review and talked to others
> who have done the same, and I from a GDPR point of view there is no
> reason to renumber on a regular basis. From what I can tell,
> renumbering at some frequency makes no difference from a GDPR point of
> view. The addresses are privacy sensitive regardless if you change them
> frequently or not.

It would be nice to get a public legal opinion published somewhere, so that
it can't be used as a marketing excuse.

> The conclusion is that we need to create solutions that handle both
> these cases.

Agreed, and it would be nice if it wasn't a flash renumber, which resetting
of the PPPoE session can causes.

-- 
]   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] IPv6 & firewall config in a home net

[Michael Richardson]

On Sep 2, 2019, at 1:47 PM, Michael Richardson  wrote:
> Assuming that the prefix change is make-before-break (which we
> do not clearly know how to do on the WAN side, I think), then the web
> server should configure with the same rfc7212 IID, but a new prefix.

To be clear, the issue of the make-before-break is on the WAN DHCPv6-PD side.
I believe that we concluded that it's possible to do in existing
specifications, but not well enough implemented at both sides (ISP/CPE)
device to depend upon.

Ted Lemon wrote on 05/09/2019 18:31:
> I don’t think there’s any need for the IID to be persistent.
> Make-before-break is accomplished by deprecating the old prefix when
> the new prefix is added.  This is trivial to do; whether it is in fact
> done is a different matter.  I think that at present the client would
> have to notice that it’s happened.

Ray Hunter (v6ops)  wrote:
> Agreed.

> Using RFC7217 will anyway almost certainly guarantee that the IID will
> also change if the prefix changes.

> The prefix is included in the function that generates candidate IID's.

>   RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

> That was done to prevent tracking when people move between wifi
> hotspots.

But, a host running a web server that wants to be in the same place could
keep the same RID once generated.

-- 
]   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] IPv6 & firewall config in a home net

[Michael Richardson]

Ted Lemon  wrote:
> Your router should be using PCP to allow servers to open ports and
> should have a GUI to authorize that, or better yet support MUD profiles
> and use the GUI to control that.

I meant to mention PCP as well.
Question: do PCP messages always go to the default route?  I re-read 6887 and
that was unclear. RFC7488 did not clarify for me.

How does it work if there are multiple layers of router?

--
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] IPv6 & firewall config in a home net

[Michael Richardson]

 wrote:
> I have a home networking question with respect to IPv6 standards, I'm
> hoping to use you as a sounding board first before I take it to v6ops.

okay.

> The scenario here is a home / soho network situation where the user
> wants to host a service, lets say its a webserver, but really could be
> any hosted application, importantly using IPv6. The router is setup to
> use SLAAC only.

Understood.  Why is SLAAC important here?

> The ISP offers IPv6 GUA addressing in a non-stable manor, its "sticky"
> but at some point in the future it might change (BNG reboot for
> example), so the user will use DynDNS provider to provide a stable name
> for their service, this sounds OK so far.

sure, or can use the front-end naming mechanism that this WG is working on.

> The user has to allow the webserver port, 443 in their router GUI
> firewall to allow the traffic in, sounds simple enough. Importantly it
> should be to that webserver device only.

Fair enough.

> Now the tricky part

> Since in this scenario the webserver device is using privacy
> extensions, it has a bunch of IPv6 GUA addresses and no EUI-64 and
> - It has Temporary addressing (which will regularly change)
> - It has a "Permanent" address (which is the one the webserver will want 
to use)

> Does this sound reasonable and make sense so far ? Cool.

Yes, so an rfc7217 address.

> In the router GUI the user is presented with a list of "devices" for
> which the router can open up TCP 443 in the firewall.

How does the router get this list?  This is important.  Is this a list of
names, or a list of addresses?

> It is reasonable to assume the user does not want to type in the
> Permanent IPv6 address of the device, as it is poor CX and anyway it
> will change in the future (possibly due to a network change / BNG
> restart etc as mentioned)

It seems reasonable that the user is given a list of names.
The names would ideally come from DNS-SD's SRP.

> Current routers on the market I have come across have either:

> 1.  Open the port to the current temporary address only which means
> that inbound connections on the port usually fails right away (if the
> webserver is not listening on that address) - or fail after the
> temporary address changes.

that's not useful.

> 2.  Opens the port to the correct address (by chance)
> *   - But then fails at some point in the future when the network
> prefix changes (as router drops the rule when the prefix changes).

Assuming that the prefix change is make-before-break (which we do not clearly
know how to do on the WAN side, I think), then the web server should
configure with the same rfc7212 IID, but a new prefix.

> 3.  Opens the port to some or ALL addresses currently (& sometimes
> historically) associated with the mac address of the device  (not great
> for security - spoofing? )
> *   But even that sometimes excludes the permanent address

Hmm. How does it know those addresses are all the same device?
If the router can tell, maybe the privacy addresses aren't very private :-)

> 4.  Opens the port to all addresses on LAN (not great for security at all)

no.

> *   Basically the routers firewall config gui doesn't know reliably
> which device address is the permanent one.

> *   Should there exist a mechanism to signal to the router or the
> router can accurately learn which of the devices addresses should be
> used for configuration in the firewall ?

> Is this a problem - have I missed something - Is it worth fixing ?

Yes, it's worth fixing.
Note that RFC8520 (MUD) could also be used by the web server to announce it's
need.  In particular if the web server is running on a multi-purpose host,
having it configure an extra rfc7217 address JUST for it, and then using
DHCPv6 to communicate it's MUD file would make sense.
The router owner would need to affirm that this is desired communications.
(Yes, there are missing APIs in general-purpose operating systems to make
this happen)

> Thoughts:
> This is probably a strange thing for the user to do (but I have had
> users trying to do it). Its usually fixed for a customer by switching
> off privacy extensions / using EUI-64 so basically giving the device a
> single address for the router gui to identify the device by.

Being able to open connections into services, particularly doing so for some
subset of the Internet (your alarm monitoring company, work or mobile access
to you nanny cam, etc) is one of the "killer app" for IPv6 in the home.
So I don't think it's strange, and it has to "just work" for users

Re: [homenet] homenet notes

[Michael Richardson]

On 2019-07-23 10:09 a.m., STARK, BARBARA H wrote:

  - terminology (homenet)
  - front-end naming
  - SRP in homenet (assumes dnssd SRP draft)
  - HNCP for external domain
  - service discovery in homenet


It seems like "SRP in homenet" and "service discovery in homenet" might 
be the same thing.  I can't recall what the distinction was, but I 
recall that's we'd wind up with five documents.


> At IETF 106, see if we can have joint dnssd + homenet 2 hour session
> and give homenet 30 minutes to discuss service discovery in homenet.
> Before IETF 106, there should be day where Ted, Michael and Daniel
> hack and talk together. August 28 tentatively set as date.

I also think that maybe we should have a virtual interim in october?




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

Re: [homenet] final planning for not formally meeting

[Michael Richardson]

STARK, BARBARA H  wrote:
> If there are people interested in HNCP integration, I’m happy to
> reserve space for that (at a time different from the -naming effort),
> and I’m happy to participate in that as well.

I want to do HNCP integration at the hackathon, if we can.
If it overflows into the Code Lounge, fine.  But, my idea for Tuesday morning
is that it's about bashing documents, not code.

> I’ll see about reflashing my router to the most current OpenWRT. It
> really needs updating, anyway.

I'm also happy if we get (at the Hackathon) devices that people bring up to 
"current"

-- 
]   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] final planning for not formally meeting

[Michael Richardson]

Ted Lemon  wrote:
> This is opposite a “Technology Deep Dive” talk that some folks might
> want to go to.

True.
I think that it will be standing room only, and it will show up on Youtube.

> I have an OpenWRT repo set up here that I’m using for the hacking I’m
> doing, and that we could use as a collaborative space if it seems
> useful: https://github.com/IETF-Hackathon/openwrt

okay 

> Right now the packages I’m working on don’t build out of the box, but
> I’ll fix that in the next day or so. If anybody is interested in
> building what I’m building, I can supply some pointers. I’m doing my
> development on the GL-iNet AR-750S router, which builds cleanly out of
> this repo. In principle the repo is tracking OpenWRT current, but I
> haven’t merged in a few days.

> My plan is to hack on homenet stuff—if there are folks who want to do
> naming, that would be great, but I wouldn’t mind doing some HNCP
> integration if there’s anyone who’s interested in that.

I would like to suggest that we spend at least 3-4 hours setting up HNCP
among a few people.  Maybe a "tell-two-friends" kind of effort.

If we/you can then make homenet naming work that would be very cool.
I expect that my build experts will be there, otherwise, I'll have to fix
(git update, etc.) by build machine.  It's supposed to be all CI now.

I brought one router...  Damn!  Stupid packing list this afternoon.
I was supposed to bring a few spare 3800s as well!
I have a bunch of small machines that can go behind routers though.
I also brought some extra TTL/USB adapters, and since I'm on the train a
bunch of tools.

-- 
]   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] final planning for not formally meeting

[Michael Richardson]

STARK, BARBARA H  wrote:
> Hi homenet, Now that we're less than a week out...  - What planning
> should people do who can/will attend the hackathon? I intend to come,
> and can bring a (LEDE load, currently) wireless router and other items
> (Raspberry Pi ?).

I will bring 2-3 devices with custom openwrt 18.06 loads.
I will bring 4-5 multi-port devices that can be placed "behind" the routers.
(These are OrangePi0 devices in custom cases).

> If that would be useful. Does anyone else want to
> share their plans or ask for something specific?

I think that the MUD people and the Homenet people should occupy a table with
a switch together.  I have been trying to get confirmation from the NOC that
the DHCPv6-PD is ready to go, but so far I haven't gotten any replies.

> - I haven't scheduled
> an unstructured meeting. Should I? Should I do a quick Doodle poll for
> when? Or would people prefer to wing it when we get there? If we
> schedule something, I could set up a WebEx for remote people.

I had suggested that it should be a *-naming "design team" focus,
I had proposed Tuesday morning. I hadn't booked anything yet either.

--
]   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] [DNSOP] Montreal homenet activities -- front-end-naming

[Michael Richardson]

Normen Kowalewski  wrote:
> apologies for this really very late reply, but FAIW it's IMHO not
> really a "Synchronization Server", because the flow is really
> hierachical - from home via the to-be-named-entity, and then to the
> place tha scales out, like the slaves of that entity. I think it is
> also not really a “Distribution Server", if the collecting
> to-be-named-entity is a fully grown-up DNS Auth by itself, in which i
> can/do also manage zones directly.

I never liked "Synchornization Server", and we removed that term.

We settled on Distribution Master, which is usually the stealth primary, and
transfers zones to the public secondaries.

> When I ran things in a chain like this, it saw the  to-be-named-entity
> as acting in the capacity of a "DNS intermediary [master]", or "DNS
> provisioning proxy".

DNS intermediary Master, conveniently could also be abbreviated to "DM" :-)

> AFAIK already when we starting the early discussions on this (Hi
> Daniel, Hi Ralf!) for the former expired draft, we had not found a
> specific terminology for such a use of nn DNS Authorittive Server in a
> draft/doc anywhere, but i still think it is worth the effort to have a
> specific term for that.

--
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] webauthn for routers

[Michael Richardson]

Michael Thomas  wrote:
> Thanks, it's probably pretty dated by now, especially all of the crypto
> hackery :). The thing that I'm not sure about is whether the out-of-band
> method for adding clients would work in a home router situation. My 
solution
> required the server (ie, the router) to send email to somebody. It

Or SMS. Or a push notify, which would definitely work.

--
]   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[

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

Re: [homenet] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Are you assuming here there's a central Homenet controller that presents
> a web interface where the "house owner" can choose which names get
> published?

No, we are assuming that there are one or more homenet routers that either
come with a delegated domain from the manufacturer (probably a very ugly
one), or which that CPE's ISP will delegate via DHCPv6. (or both)

Whether we should or have to do some negotiation over HNCP if there are
multiple CPEs is a problem we can deal with later.

We have, however, been thinking about the problem of having partial
connectivity for the home, and how do published names get resolved.

> I'm probably missing something, Michael, so please explain if you agree
> with the analysis above, whether you're assuming a central controller,
> and, if so, where is the central controller located in a network that has
> multiple edge routers.

If an end user wants a non-ugly domain, and they buy it, then they need to
introduce one or more of their CPEs to the upstream provider of the
domain.  It could be it is at this point that it makes sense to do some HNCP,
but in essence, this is an internal problem, and the front-end-naming
document is not about internal issues.

--
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] webauthn for routers

[Michael Richardson]

Michael Thomas  wrote:
>> Secondary admins are encouraged to guard against loss/destruction of 
mobile
>> phone, and it is also possible to enroll a second time, provided the
>> manufacturer agrees (this is both a feature and a bug)
>>
>> The code is at https://github.com/CIRALabs/
>>

> I'm not sure we're talking about the same thing? I'm just talking about 
the
> normal web interface that home routers have to hand configure them. 
There's
> no need for certs at all.

Yes, that's what I'm talking about.
Yes, there is a need for strong security.

The bad guys are inside already, they send trojans, and if the router has
passwords ("admin"/"admin"), then the bad guys just change the security
policy.

They don't do this now, because they don't need to, our home routers are
basically swiss cheese in the outbound direction, but I'm sure they will
learn.  Particularly, it will be easy if we have a standard (or
defacto-standard) API.  At this point, the luci interface is probably easily
automated.

Modern browsers practically don't let you even type passwords in over HTTP
now, so you really really really need a certificate for the inside of the
router, and it needs to be valid.

> I wrote a blog post which considered the enrollment problem of a
> webauthn-like protocol (way before webauthn was even started). I'm not 
sure
> if it works for the special case of a home router though.

> 
http://rip-van-webble.blogspot.com/2012/06/using-asymmetric-keys-for-web-joinlogin.html

> Enrollment, of course, is out of scope for webauthn, per se.

I'll read it.

--
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] webauthn for routers (was: securing zone transfer)

[Michael Richardson]

MIchael Thomas  wrote:
>>> There are no passwords.

>> Yes please.

> Speaking of which, should we be encouraging router vendors to implement
> webauthn? Considering that probably half of home routers have the default
> password, that seems like it would be a Good Thing.

We have done an enrollment system which based upon BRSKI.
It is described in draft-richardson-ietf-anima-smarkaklink.
We have running code with a desktop acting as the client, with
the mobile app being built now.  I am making a screencast today, actually.
There are similarities to some profiles of EAP-NOOB, but we do
rely on the manufacturer as the root of trust.

I guess we could/should have considered enhancing webauthn instead; I have to
think a bit about whether it would have work as well.  I will need to see.

At the end of the day, we wind up with a mobile phone with a certificate
enrolled into a private CA on the router.  The router itself has a
LetsEncrypt certificate acting as it's IDevID, although this could
be a private CA instead.  There are issues in both directions.

Secondary admins are encouraged to guard against loss/destruction of mobile
phone, and it is also possible to enroll a second time, provided the
manufacturer agrees (this is both a feature and a bug)

The code is at https://github.com/CIRALabs/


--
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] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Your son clicks "publish name" in the Minecraft server's UI, at which
> point he faces the following dialog box:

> Domain: dyndns.minecraft.example.com
> Hostname: minecraft-7ac8
> Password:

And where does the password come from?
If this is one he picks, how can I know that it's a good one?
And how do I prevent him from doing this?

> Your turn now.  Could you please describe the UI that you envision?

The list of names (from the internal mDNS/DNS-SD, as well as DHCP hostnames)
is presented to the house owner, they click on the ones that the want to
be publically visible.  (They may also apply a security policy for access,
but that's not a naming issue)

There are no passwords.

--
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] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
> Thank you for your detailed reply.  I'm glad we're finally having
> a discussion about my objections to Daniel's proposal.

>> We strongly believe that the HNA needs to know the list of names in
>> order to be able to answer for those names when there is unstable (or
>> no) Internet connectivity.

>> Otherwise, applications and people have to know two different names for 
the
>> service. (A public one for when away, and the .local one)

> That's a good point.  While I happen to believe that it's reasonable to
> have a service known as "boombox.local" from home, and
> "boombox.jch.example.org" from the Internet, this might be inconvenient
> for e.g. smartphone users.

Actually, it's fatal, because you can't get a certificate for "boombox.local"
so you can't secure it that way.  So you always have to use the FQDN.

>> o  the credentials for the dynamic DNS server need to be securely
>> transferred to the hosts that wish to use it.  This is not a
>> problem for a technical user to do with one or two hosts, but it
>> does not scale to multiple hosts and becomes a problem for non-
>> technical users.

> I think that's our main disagreement.

> For some reason, you guys seem to be assuming that the average user will
> want to publish hundreds of names in the global DNS.

Hundreds?  How about two.
My son wants to publish his desktop's name so that his friend can reach his
system directly for minecraft.  I want the same.  Yes, it's native IPv6 the
whole way, but they don't know that, and they don't have to know that.

> However, none of the end-user services that I know use incoming
> connections require a name in the global DNS to function (WebRTC, Skype,
> online games, BitTorrent, remote desktops, BTSync/Resilio, syncthing).

All of these are applications which either presently use cloud relays due to
NAT, or exchange IP addresses within the protocol.  All of these applications
are built during the IPv4 mindset of scarcity.

> Thus, my assumption is that the typical user will want to publish exactly
> 0 public names, and that only the extreme geek will publish up to 3 or 4
> (music server, NAS, game server, web server with family photographs).

> Richard, Daniel -- please be so kind as to explain why you think my
> assumption is wrong.  How many names do you envision wanting to publish in
> the public DNS, and for what purpose?

I think that you are living in the late 1990s IPv4 scarcity world.
The gigabit connected IPv6 home doesn't have to be like that.

I know at least twenty minor geeks who have music servers, NAS,
game server boxes and that family web server.  Yet, have no clue what
an IP address is.

Many of them have griped to me that there should be a way for them to easily
give their stuff names that they can access.  We've spoken at times of
building more mesh networks here, but what's the point if you can't give
things good names?

Anyway, you don't have to publish any names if you don't want to.

--
]       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[





--
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] [EXT] securing zone transfer

[Michael Richardson]

Ted Lemon  wrote:
>for things that need internet connectivity, and have the primary DNS
>server on the main land.   TSIG & DNS over TLS look like a good option
>to look at.

> Have you looked at draft-ietf-dnssd-srp
> (https://tools.ietf.org/html/draft-ietf-dnssd-srp-01
> <https://tools.ietf.org/html/draft-ietf-dnssd-srp-01>)?

Ted, I didn't think it was relevant, but I read it anyway.

It has been sometime since I tried to grok the SRP stuff, and last time it
was mostly to understand the more homenet related things.

  dnssd-srp> In other network environments, updates for names ending in
  dnssd-srp> "default.services.arpa" may be rewritten internally to  names with
  dnssd-srp> broader visibility.

Our goal with front-end-naming is to provide the "rewritten internally 
function".

I found section 2.3.2.  Testing using standard RFC2136-compliant servers out
of place. I think it belongs in an appendix?

This dnssd-srp protocol seems like it will work wonderfully within a homenet
(or small to medium sized campus). I think that is the goal.

I don't think it will work as the protocol for a homenet to publish a public
zone to the Internet without some additional security and setup. At least,
that's my feeling at this point.

--
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] Montreal homenet activities -- front-end-naming

[Michael Richardson]

(context: The HOMENET WG will not meet in Montreal at IETF105)

The HOMENET front-end-naming design team will spend some unstructure time
together.   This relates to
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

The exact time is to be determined as the unstructured schedule has yet to be
determined.  Tentatively, I want to suggest an hour on Tuesday morning.

We would love to spend some time with people who design and/or operate public
anycast DNS systems.  We want to make sure that we match any terminology that
you use, and to learn about practical limitations that we might be unaware
of.  This in particular relates to the questions at:
  https://mailarchive.ietf.org/arch/msg/homenet/VcXftoB30feY9PlsPtvEV65JycM

--
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] securing zone transfer

[Michael Richardson]

Juliusz Chroboczek  wrote:
>> The front end naming architecture uses a primary and a secondary dns 
server to
>> synchronize a zone.

> People will recall that the need for a hidden primary hasn't been
> established yet.  Please see my unanswered e-mail of 21 November 2018.

> https://mailarchive.ietf.org/arch/msg/homenet/vz1kdCJISN6UPNZpj9ZD4e8EdwQ

We strongly believe that the HNA needs to know the list of names in order to
be able to answer for those names when there is unstable (or no) Internet 
connectivity.

Otherwise, applications and people have to know two different names for the
service. (A public one for when away, and the .local one)

In our current draft we have:

2.1.  Alternative solutions

   An alternative to having a single zone is what is currently common
   with IPv4, where a host uses a RESTful HTTP service to register a
   single name into a common public zone.  This is often called "Dynamic
   DNS", and there are a number of commercial providers, including
   dyn.com, ghandi.com.  These solutions were typically used by a host
   behind the CPE to make it's CPE IPv4 address visible, usually in
   order to enable incoming connections.

   For a small number (one to three) of hosts, use of such a system
   provides an alternative to the architecture described in this
   document.  The alternative does suffer from some limitations:

   o  the CPE/HNA router is unaware of the process, and can not answer
  for the same names when there are disruptions in connectivity.
  This makes the home user using different names when there are
  disruptions.

   o  the CPE/HNA router can not control the process.  Any host can do
  this regardless of whether or not the home network administrator
  wants the name published or not.  There is therefore no possible
  audit trail.

   o  the credentials for the dynamic DNS server need to be securely
  transferred to the hosts that wish to use it.  This is not a
  problem for a technical user to do with one or two hosts, but it
  does not scale to multiple hosts and becomes a problem for non-
  technical users.

   o  "all the good names are taken" - current services put everyone's
  names into a some set of zones, and there are often conflicts.
  Distinguishing similar names by delegation of zones was among the
  primary design goals of the DNS system.

   There is no technical reason why a RESTful cloud service could not
   provide solutions to many of these problems, but this document
   describes a DNS based solution.

--
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] securing zone transfer

[Michael Richardson]

Ted Lemon  wrote:
> For dns updates, SIG(0) works fine. I have code you can steal that
> works with mbedtls and ecdsa. Signing and validation.  But I think TLS
> client certs can also work.  Proving the front end servers identity
> sounds like the hard part.

Just to ask again clearly:

1a) is it possible to authorize an AXFR transfer by SIG(0)?
1b) is it possible to authorize an SOA query by SIG(0)?
2) is anyone doing AXFR over TLS  (DPRIVE)?

{3) is RFC3007 really the most recent text on dynamic DNS?}

>> On Jun 8, 2019, at 6:32 PM, Michael Richardson  
wrote:
>>
>>
>> Ted Lemon  wrote:
>>>> Can we use TLS for authorization, assuming that we have trusted
>>>> certificates
>>>> at both ends?  Perhaps this is more of a: did anyone implement this?
>>
>>> How is trust established?   Sure, doing TSIG over TLS is no problem.
>>
>> Certificates are exchanged/created at manufacturing time (IDevID), and 
then
>> optionally updated to LDevID.  The certificate contains the name of the 
zone
>> which the HNA is authoritative for (or a control record pins the
>> certificate).
>>
>> TSIG requires a shared secret, thus a database of shared secrets 
available
>> online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
>> if I have to use TSIG for mechanical reasons, I want to derive the secret
>> From the TLS.
>>
>> I need to authorize the following:
>> 1) DNS update of some data (NS, DS,  that NS points to) by
>> Distribution Master (cloud/public system)
>> 2) SOA query by Distribution Master by HNA.
>> 3) AXFR by Distribution Master by HNA.
>>
>> --
>> Michael Richardson , Sandelman Software Works
>> -= IPv6 IoT consulting =-

--
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] securing zone transfer

[Michael Richardson]

Ted Lemon  wrote:
>> Can we use TLS for authorization, assuming that we have trusted
>> certificates
>> at both ends?  Perhaps this is more of a: did anyone implement this?

> How is trust established?   Sure, doing TSIG over TLS is no problem.

Certificates are exchanged/created at manufacturing time (IDevID), and then
optionally updated to LDevID.  The certificate contains the name of the zone
which the HNA is authoritative for (or a control record pins the
certificate).

TSIG requires a shared secret, thus a database of shared secrets available
online.   I don't want to do TSIG over TLS, I want to not do TSIG, or
if I have to use TSIG for mechanical reasons, I want to derive the secret
From the TLS.

I need to authorize the following:
  1) DNS update of some data (NS, DS,  that NS points to) by
 Distribution Master (cloud/public system)
  2) SOA query by Distribution Master by HNA.
  3) AXFR by Distribution Master by HNA.

--
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] securing zone transfer

[Michael Richardson]

Ray Bellis  wrote:
>> Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not
>> provide confidentiality, and we would rather go for user space security. 
>> Are there any recommendation for using TLS or DTLS in that case ?

> Please don't invent something new.  DNS over TLS should be fine for
> channel security, with TSIG embedded inside that if additional
> authorisation is required.

Can we get away without TSIG?

Can we use TLS for authorization, assuming that we have trusted certificates
at both ends?  Perhaps this is more of a: did anyone implement this?

--
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] primary / secondary configuration

[Michael Richardson]

Daniel Migault  wrote:
> the zone with the outsourcing infrastructure. To build the zone some
> elements of the infrastructure are needed such as the NS and IP for
> example. One way to enable the transmission of information from the the
> outsourcing infrastructure to the homenet is to use an well known fqdn
> hna.example.com with an AXFR request. Does it sound reasonable ?

So, during setup phase, the HNA does the equivalent of:

% dig @configuration-server myDEVICE.r.example.net axfr

and gets back:
myDEVICE.r.example.net IN SOA mname foo bar ...
   IN NS ns1.example.com
   IN NS ns2.example.com
   IN NS ns3.example.com

which it uses as it's template for building it's zone, which is then signed
and AXFR'ed back to the distribution-master using the normal mechanisms.

There are probably some high-level details that we haven't gotten into the
document yet, which are important for understanding.

We drew this diagram in our call today:
  https://github.com/ietf-homenet-wg/ietf-homenet-hna/blob/master/hna-dm-cfg.svg

although I see some example.com->example.net, and foo.com->example.com edits 
that I
should make.

--
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] securing zone transfer

[Michael Richardson]

Daniel Migault  wrote:
> Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does not
> provide confidentiality, and we would rather go for user space security.
> Are there any recommendation for using TLS or DTLS in that case ?

And TSIG requires the Distribution Master to have a database of private
(symmetric) keys, which if disclosed causes havok.  (yes, DNSSEC can
partially save your bacon as we propose signatures be done on the homenet 
routers)

Can we use RFC7858 to authorize and provide privacy for AXFR?   We don't know
yet!  I believe that SIG(0) can be used for authorization, but I've never
configured that myself, or seen it in production.

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

[homenet] front-end naming document: Synchronization Server

[Michael Richardson]

Last week Daniel and I resurrected
  
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

The -08 version was posted, it should have minimal changes for the expired
-07 version, except that this version is done in Markdown/github, etc.
Issues tracked are at:
   https://github.com/ietf-homenet-wg/ietf-homenet-hna
(please ignore similar named repo which was duplicated)

The -09 version will include significant changes, and we posted -08 to be
sure that all changes were intentional.  I include the abstract below for the
benefit of people who are BCC'ed.

The essential architecture is a stealth primary running in the homenet
(likely in one of the CPEs), using a zone-transfer to "cloud" hosted primary
server (A), and likely from there to a typical set of authortiative servers.
These might be anycast'ed or not, depending upon who is running the service.

The question I have for this email is whether or not there is a common
name for the primary server (A), which collects the zones from the stealth
primary server.  That server is often not publically listed.  In the document,
it was called the "Synchronization Server", but I don't think that is a good
name.  In my previous experience doing this kind of thing the server A
was called the Distribution Server.

While I like that term better, I don't know how common it is for other DNS
providers.  So what term do you know of?

Has the architecture of having a stealth primary feeding a distribution
server, which then transfers to some set of public facing servers been
formally described in an IETF document?  If not, in some OARC document?



Abstract

   Designation of services and devices of a home network is not user
   friendly, and mechanisms should enable a user to designate services
   and devices inside a home network using names.

   In order to enable internal communications while the home network
   experiments Internet connectivity shortage, the naming service should
   be hosted on a device inside the home network.  On the other hand,
   home networks devices have not been designed to handle heavy loads.
   As a result, hosting the naming service on such home network device,
   visible on the Internet exposes this device to resource exhaustion
   and other attacks, which could make the home network unreachable, and
   most probably would also affect the internal communications of the
   home network.

   As result, home networks may prefer not serving the naming service
   for the Internet, but instead prefer outsourcing it to a third party.
   This document describes a mechanisms that enables the Home Network
   Authority (HNA) to outsource the naming service to the Outsourcing
   Infrastructure.



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

[homenet] front-end naming document: Synchronization Server

[Michael Richardson]

Last week Daniel and I resurrected
  
https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/

The -08 version was posted, it should have minimal changes for the expired
-07 version, except that this version is done in Markdown/github, etc.
Issues tracked are at:
   https://github.com/ietf-homenet-wg/ietf-homenet-hna
(please ignore similar named repo which was duplicated)

The -09 version will include significant changes, and we posted -08 to be
sure that all changes were intentional.  I include the abstract below for the
benefit of people who are BCC'ed.

The essential architecture is a stealth primary running in the homenet
(likely in one of the CPEs), using a zone-transfer to "cloud" hosted primary
server (A), and likely from there to a typical set of authortiative servers.
These might be anycast'ed or not, depending upon who is running the service.

The question I have for this email is whether or not there is a common
name for the primary server (A), which collects the zones from the stealth
primary server.  That server is often not publically listed.  In the document,
it was called the "Synchronization Server", but I don't think that is a good
name.  In my previous experience doing this kind of thing the server A
was called the Distribution Server.

While I like that term better, I don't know how common it is for other DNS
providers.  So what term do you know of?

Has the architecture of having a stealth primary feeding a distribution
server, which then transfers to some set of public facing servers been
formally described in an IETF document?  If not, in some OARC document?



Abstract

   Designation of services and devices of a home network is not user
   friendly, and mechanisms should enable a user to designate services
   and devices inside a home network using names.

   In order to enable internal communications while the home network
   experiments Internet connectivity shortage, the naming service should
   be hosted on a device inside the home network.  On the other hand,
   home networks devices have not been designed to handle heavy loads.
   As a result, hosting the naming service on such home network device,
   visible on the Internet exposes this device to resource exhaustion
   and other attacks, which could make the home network unreachable, and
   most probably would also affect the internal communications of the
   home network.

   As result, home networks may prefer not serving the naming service
   for the Internet, but instead prefer outsourcing it to a third party.
   This document describes a mechanisms that enables the Home Network
   Authority (HNA) to outsource the naming service to the Outsourcing
   Infrastructure.



--
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 rechartering, meetings, and code

[Michael Richardson]

STARK, BARBARA H  wrote:
> The Montreal Hackathon 
(https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon) currently shows:
> HOMENET build-out
> Champion(s)
> TO BE DETERMINED, probably Ted.
> Project(s)
> hook up multiple routers and do back-end and front-end naming tests

I filled this in (subtle voluntold of Ted) because I had the wiki open, and
Ted had discussed doing exactly this, and I want to participate.

> Should we be encouraging this on the list (i.e., is anyone intending to
> show up at the hackathon and work on homenet code)? BTW, I'm happy to
> bring a couple of OpenWRT routers and play with whatever code others
> produce.

What we need is to do some discussions online and on-list about what exactly
we want to test.  It's more than just showing up.

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

[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] multiple routers vs IoT

[Michael Richardson]

Tim Coote  wrote:
> On 2 Apr 2019, at 17:04, Michael Richardson 
> wrote:

mcr> The way for multiple routers in the house is to recognize that the IoT
mcr> gateway is the second router. It's not a second uplink.

mcr> So there are in fact three situations:

mcr> 1) multiple uplinks. (rare at this point, we all agree, partly I think
mcr> because it's hard to do)

mcr> 2) multiple routers. (rather common, often by mistake) 3) IoT routers
mcr> (usually on purpose)

> By ‘IoT router’, do you mean nodes providing the routing to 6LoWPAN 
network
> (s) running over various protocols, the router that links IoT nodes to the
> internet, or something else such as incorporating sensors/actuators that 
are
> powered and use wifi as the network protocol?

I mean the gateway between 6lowpan and the home network (whether it's wifi or
wired).  That node likely also links them to the Internet (is appropriate,
ULA otherwise).

sensors/actuators with power and Wifi (and probably an marriage to a cloud
service) are "Web Enabled Devices", not IoT :-)

--
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] wifi broadcast domain - Mikael Abrahamsson's comments

[Michael Richardson]

STARK, BARBARA H  wrote:
> I am involved in the joint BBF effort that they mentioned. If someone
> wanted to join that project (it's free to join -- just requires
> agreeing to IPR policy and BSD+Patent open source license) and suggest
> and provide code for HNCP, they could.

I will followup with you, unicast.

> But since this is a purely Layer
> 2 network (routers will break it), the HNCP would really only be for
> other routers (e.g., IoT gateways attaching a Thread network) that
> aren't part of the Multi AP L2 network. If you'd like more info for
> joining the joint BBF/prpl project, let me know.

If the border routers are on the same L2 as the extensions, then it shouldn't
be a problem.  If there is a more complex HNCP network, then we could
probably simulate the L2 scenario with VXLAN, configured by HNCP.

There are probably some advantages to doing that as well.

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

[homenet] homenet.org

[Michael Richardson]

So... who owns homenet.org then?
Whois is of course, now neutered.

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

[homenet] wifi broadcast domain - Mikael Abrahamsson's comments

[Michael Richardson]

prplMesh solves the wifi broadcast domain issue.
   https://prplfoundation.org/working-groups/prplmesh/

I don't think we can fight this.  I'm upset that this is a gated
organization, and I hate it more than you.  Perhaps we can ask for a formal
liason, perhaps via Broadband Forum.

My question is how can we use HNCP to help manage this.
I don't know, as I haven't read their specification, but I'd like to figure
it out.   I think it's further layer-2 hacks inspired from 30 years of living
in IPv4.

A reason we need to delve into prplMesh is that it permits us to hairpin
traffic between two wifi devices to go through the (security) gateway so that
they can't attack each other.

I, like Juliusz, think we can do this better in layer-3 with much less complex
machinery, but I'm not sure that Homenet should solve this problem itself.

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

[homenet] multiple routers vs IoT

[Michael Richardson]

The way for multiple routers in the house is to recognize that the IoT
gateway *is* the second router.  It's not a second uplink.

So there are in fact three situations:

1) multiple uplinks. (rare at this point, we all agree, partly I think
 because it's hard to do)
2) multiple routers. (rather common, often by mistake)
3) IoT routers (usually on purpose)

Let's recharter to address (2) and (3).

As for Ted's comments about backbone router in 6lo... that's rather esoteric
Industrial IoT stuff.  It's not, I think, quite right for the home. At least,
not yet.

{ps: I have the thread that the chairs started partly unread, because I
had contributed to the questions, and I wanted to let others chime before I
argued with them}

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