Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
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)
On Fri, Nov 25, 2022 at 3:19 PM Daniel Migault wrote: > > >> >>Though the HNA may also later directly update the values of the DS >>via the Control Channel, it is RECOMMENDED to use other mechanisms >>such as CDS and CDNSKEY [RFC7344] for transparent updates during key >>roll overs. >> >> If this is going to be a fully automated enduser CPE solution, this >> RECOMMENDED >> is too weak. It should be a MUST because otherwise DNSSEC rollover is just >> impossible. >> > > I am happy to move it to SHOULD. > RECOMMENDED and SHOULD are the same thing, according to RFC 2119. -MSK ___ 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)
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Michael.
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.
So any decent server should probably already
1) check that the notify arrives from somewhere where the server trusts
the source of the zone information
2) use the notify as an indication that the local refresh timer should
be expired e.g. set a flag for later action by a timed background task.
3) rate limit how often this happens
4) check for updates in zone content by the standard mechanism via the
Synchronization Channel of DM->HNA, .
My assumption therefore was that the Notify from HNA->DM COULD be
unprotected and transported as DNS over UDP as per RFC1996.
HNA could learn the correct source and destination IP address to use for
the Notify by reversing information learned from previous inbound
DM->HNA synchronization channel connections.
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.
that was my assumption.
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.
My view is that TLS is overkill, although I have no objection to it. It
potentially adds some privacy.
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
Kind regards / Met vriendelijke groet,
Ray Hunter
___
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)
On Fri, Dec 2, 2022 at 9:50 AM Michael Richardson wrote: > > 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? > That was my reading of 9103, but now I am thinking that if the tcp session is down, protection is probably using port 853 on the DM. In that case, using the control channel or a new TLS session seems to be the same. One advantage is that PSK can be used to the already established control channel. My impression is that using the control channel is one way to do and have some benefits, but that only one way to do and other ways could include 53 or a new TLS session. > > > 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. > I see your point. I think that it is worth mentioning that the reason for using the control channel is that it is the only port we know the DM is reachable. I have connected all dots -thanks for the explanation - and I am fine with your recommendation. I agree with your two points. > > -- > Michael Richardson. o O ( IPv6 IøT consulting ) >Sandelman Software Works Inc, Ottawa and Worldwide > > > > > -- Daniel Migault Ericsson ___ 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)
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
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Michael,
Just sharing my thoughts,
Yours,
Daniel
On Thu, Dec 1, 2022 at 8:56 PM Michael Richardson wrote:
> 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.
>
> 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.
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)
>
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.
> 2) They are always sent in TLS.
>
> I am inclined to say that we should rely on 9103 as much as possible and
the price of a non encrypted NOTIFY can be acceptable. If that is not the
case, the control channel may be used - which should be agreed out-of band-
by the two parties.
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
>
--
Daniel Migault
Ericsson
___
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)
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Paul, As mentioned offline, I am rebooting the conversation and addressing the DISCUSS and comments. Please let me know if there is anything that needs to be clarified or if additional information is needed. I tried to remain quite high level in my responses in an effort to address high level concerns. I think this will fix the main concerns and we can later narrow the discussion to more technical / detailed discussion. I can envision some more specific text regarding the update of the DS for example. Yours, Daniel On Thu, Oct 20, 2022 at 1:46 AM Paul Wouters via Datatracker < nore...@ietf.org> wrote: > Paul Wouters has entered the following ballot position for > draft-ietf-homenet-front-end-naming-delegation-18: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > -- > DISCUSS: > -- > > I have to agree with Warren here. I do not understand how this protocol is > supposed to work. It renames a bunch of DNS terms (hidden primary, primary, > seconday, AXFR/IXFR, DNS update --> HNA, DM, DOI, Control Channel, Sync > channel) which makes the document very hard to read. > > As far as I can tell, I do not think we rename any entities. Let me give a more detailed overview. The overall mechanism is that the homenet defines a DNS zone for its home network and this zone contains the names of the devices that can at least be published outside. Because the CPE of the home network is not willing to host the authoritative server on the wild Internet it will outsource this to a DNS Outsourcing Infrastructure. The draft details how the home network outsource the DNS zone to the DOI. The entity in the home network that is in charge of outsourcing the DNS zone to the DOI is the Homenet Naming Authority (HNA). The DOI has at least two functions: 1) interacting with the HNA and 2) publishing the DNS zone on the Internet. The entity interacting with the HNA is designated as the DM (Distribution Manager). The protocol we describe in the document is solely between the HNA and the DM. DNS defines a mechanism known as primary secondary or master slave synchronization to synchronize a zone between two servers. Such mechanism is instantiated between the HNA and the DM and requires the DM and teh HMA some configurations parameters to be agreed. This is why we have two channels: * the control channel where the HNA and the DM agree with the necessary parameters to set their primary / secondary relation * the synchronization channel which is the primary / secondary relation. As a result HNA and DM can be seen as the entity configuring the zone synchronization as well as configuring the zone synchronization. In a homenet perspective the HNA is also likely to generate the zone and sign it. Though we do not modify in any way the DNS zone synchronization mechanisms, the control channel uses DNS messages to exchange some parameters between the HNA and the DM. We could have used JSON, but the WG chose to re-use DNS messages as a means to carry some information and the messages that have been selected were DNS update and AXFR exchanges. This are only used a s a convention and do not have the standard meaning we usually give to AXFR and DNS update. In fact no zone is involved over the parameters exchanged over the control channel. > For those parts where protocol glue is needed to use these DNS > technologies, > the document presents no solutions. I don't understand if users can create > their own named zones, or whether this is only provider generated zones. > The > latter seems less useful to the user, the former seems to need more > specification on how to handle registry/registrar/registrant matters > (especially with respect to DS) > > So, the idea is that the honment is able to generate its own zone as it wishes. Our protocol assumes the HNA knows which DM it needs to contact and the DM is able to authenticate the HNA ( as the owner of the registered domain name). In the most generic way, these parameters needs to be configured in the HNA, however, we just mention in the document there are cases where such configuration can be eased. The protocol we describe limits its scope to the outsourcing operation from the HNA to the DOI. This requires for example the zone is being provisioned with the appropriate NS of the DOI, this requires the DM to be aware of the IP address of the HNA to synch the zone and operate as a
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Wed, Nov 23, 2022 at 9:12 AM Paul Wouters wrote: > On Nov 22, 2022, at 16:15, Daniel Migault wrote: > > > > > > Hi Paul, > > > > I am doing the follow-up and would like to check if there are any > specific questions regarding the current version of the document. > > During IETF-115 I talked to Michael. It helped confirm the parts that I > thought were unspecified. While I do believe that makes the protocol > practically undeployable, as the hard parts have been left out of scope, I > can now reread the document with that understanding. > Make sure you point out what you believe is practically undeployable. > > I do think Experimental is a better classification than Standard Track > though because of this. It is hard to see how two implementations can fully > interact and interoperate. Does anyone know of any implementations ? > Again make sure "this" is clearly specified so it can potentially be addressed/discussed. Until "this" is not clearly stated, it cannot justify the downgrade to Experimental. In our case, our products need a Standard Track. Ray has an implementation not published as open source yet. > > Paul -- Daniel Migault Ericsson ___ 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)
On Nov 22, 2022, at 16:15, Daniel Migault wrote: > > > Hi Paul, > > I am doing the follow-up and would like to check if there are any specific > questions regarding the current version of the document. During IETF-115 I talked to Michael. It helped confirm the parts that I thought were unspecified. While I do believe that makes the protocol practically undeployable, as the hard parts have been left out of scope, I can now reread the document with that understanding. I do think Experimental is a better classification than Standard Track though because of this. It is hard to see how two implementations can fully interact and interoperate. Does anyone know of any implementations ? Paul ___ 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)
Hi Paul, I am doing the follow-up and would like to check if there are any specific questions regarding the current version of the document. Yours, Daniel On Mon, Oct 31, 2022 at 10:34 PM Daniel Migault wrote: > Ray implemented the front end naming architecture but I am unaware if > there is any link to an open source implementation. > > I am unable to figure out what you believe is out of scope of the document > (or not), as gaps you believe are under specified. If stated explicitly we > 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. As you mentioned earlier you can start with one. > > Note that the current version 22 has been published today with all > addressable concerns: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > Yours, > Daniel > > On Mon, Oct 31, 2022 at 5:56 PM Paul Wouters > wrote: > >> On Oct 31, 2022, at 09:39, Daniel Migault wrote: >> >> >> >> Hi Paul, >> >> This is just a follow-up regarding the remaining concerns that need to be >> solved. Does Michael's response address your questions, if not please >> let us know what remains unclear as well as what other clarification is >> needed. >> >> >> It does clarify some of the process, but sadly adds more to the “this >> part is out of scope of this document”, still resulting in unspecified gaps >> in the solution that this document claims to facilitate. >> >> Has anyone implemented this? Maybe a reference opensource one that could >> help my understanding ? >> >> Paul >> >> >> >> >> Yours, >> Daniel >> >> On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson >> wrote: >> >>> >>> 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
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi, I have an implementation of this specification. It's not open source today. But if it were to be published I'd be willing to discuss publishing the code as open source. (I am self-employed so there's no IPR issues in that). regards, Juliusz Chroboczek wrote on 01/11/2022 12:22: Juliusz, please go read RFC2026. You are completely out of order. Proposed standards do not need *ANY* interoperable implementations. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet Kind regards / Met vriendelijke groet, -- Ray Hunter +31620363864 Globis Consulting BV, The Netherlands Registered at KvK Noord Brabant 17098279 ___ 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)
On Tue, Nov 1, 2022 at 6:11 AM Juliusz Chroboczek wrote: > Removing the IESG from CC. > > > I propose you start mentioning what you believe are unspecified gaps > > that could lead to interoperability issues. > > With all due respect, Daniel, I'm a little surprised by this development. > In this WG, we did spend a lot of effort ensuring that all of our > specifications have at least two independent implementations. This > allowed us to claim with assurance that our protocols are not only > implementable, but actually described clearly enough to allow independent > reimplementation. (Which didn't prevent a small minority of IESG members > from blocking progress for months, but that's a different story, and one > that's well documented in RFC 3774.) > > From your mail, it would appear that the burden of proof has changed > sides: it is apparently no longer the people who propose a protocol who > need to prove that it is implementable, but the people who have tried but > failed to understand how to implement a draft who need to prove that the > draft is incoplete. > > The purpose of a discussion is to try to understand what the other means. This is what we are trying to do. > When did that happen? > > -- Juliusz > -- Daniel Migault Ericsson ___ 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)
> Juliusz, please go read RFC2026. You are completely out of order. > Proposed standards do not need *ANY* interoperable implementations. Usually, neither implementation nor operational experience is required for the designation of a specification as a Proposed Standard. However, such experience is highly desirable, and will usually represent a strong argument in favor of a Proposed Standard designation. ___ 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)
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)
Removing the IESG from CC. > I propose you start mentioning what you believe are unspecified gaps > that could lead to interoperability issues. With all due respect, Daniel, I'm a little surprised by this development. In this WG, we did spend a lot of effort ensuring that all of our specifications have at least two independent implementations. This allowed us to claim with assurance that our protocols are not only implementable, but actually described clearly enough to allow independent reimplementation. (Which didn't prevent a small minority of IESG members from blocking progress for months, but that's a different story, and one that's well documented in RFC 3774.) >From your mail, it would appear that the burden of proof has changed sides: it is apparently no longer the people who propose a protocol who need to prove that it is implementable, but the people who have tried but failed to understand how to implement a draft who need to prove that the draft is incoplete. When did that happen? -- Juliusz ___ 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)
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Ray implemented the front end naming architecture but I am unaware if there is any link to an open source implementation. I am unable to figure out what you believe is out of scope of the document (or not), as gaps you believe are under specified. If stated explicitly we 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. As you mentioned earlier you can start with one. Note that the current version 22 has been published today with all addressable concerns: https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ Yours, Daniel On Mon, Oct 31, 2022 at 5:56 PM Paul Wouters wrote: > On Oct 31, 2022, at 09:39, Daniel Migault wrote: > > > > Hi Paul, > > This is just a follow-up regarding the remaining concerns that need to be > solved. Does Michael's response address your questions, if not please > let us know what remains unclear as well as what other clarification is > needed. > > > It does clarify some of the process, but sadly adds more to the “this part > is out of scope of this document”, still resulting in unspecified gaps in > the solution that this document claims to facilitate. > > Has anyone implemented this? Maybe a reference opensource one that could > help my understanding ? > > Paul > > > > > Yours, > Daniel > > On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson > wrote: > >> >> 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. >>
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Oct 31, 2022, at 09:39, Daniel Migault wrote: > > > Hi Paul, > > This is just a follow-up regarding the remaining concerns that need to be > solved. Does Michael's response address your questions, if not please let us > know what remains unclear as well as what other clarification is needed. It does clarify some of the process, but sadly adds more to the “this part is out of scope of this document”, still resulting in unspecified gaps in the solution that this document claims to facilitate. Has anyone implemented this? Maybe a reference opensource one that could help my understanding ? Paul > > Yours, > Daniel > >> On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson >> wrote: >> >> 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.
Re: [homenet] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
Hi Paul, This is just a follow-up regarding the remaining concerns that need to be solved. Does Michael's response address your questions, if not please let us know what remains unclear as well as what other clarification is needed. Yours, Daniel On Tue, Oct 25, 2022 at 8:08 AM Michael Richardson wrote: > > 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 =- > > > > -- Daniel Migault Ericsson ___ 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)
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] Paul Wouters' Discuss on draft-ietf-homenet-front-end-naming-delegation-18: (with DISCUSS and COMMENT)
On Sun, Oct 23, 2022 at 10:30 PM Daniel Migault wrote: > Thanks Paul for the review, > > Most of the DISCUSS was composed of questions we answered all of them, and > updated the text when necessary. You can see the change below: > > https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/27233e962f66ad72db91dac7ec7b65b7cd3b00f4 > > We clarified the TTL and the use of CDS as an example. Please let us know > if there is anything you want us to change. > I am not much further into my questions on how this is all supposed to work. So instead of going into the details, let me pick the one question that I think is core to my lack of understanding: > I agree the net admin is expected to knwo the domain name, but I think I am missing the comment. > We hardly mention DHCP in this document. We are operating at teh zone level. phones, laptop, tv do not need to implement anything. 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? Is it envisioned that this would be done by talking to the device, using a name served by the "homenet public zone" ? If so, can I determine the name of this zone, or is it only CPE auto-generated? 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 ? But all of these different options requires different things - most things a regular enduser does not have. How is this homenet public zone envisioned to exist? Who runs the homenet Public zone ? 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? It seems these questions are not answered in this draft, or I fail to understand it. 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" ? Now that we have a zone of stuff, how do we locally serve it at home, and how do we propagate this to the public internet. What's the role of the CPE vendor and the ISP ? I am not talking about the reverse IPv6 zones. I understand and ISP with some CPE vendor could almost automate this other than the first step of binding the name to the IP. I also do not need to know the name of an IPv6 IP when I am not home to reach my own stuff, so I don't think this matters at all for any enduser. In your answer, please try to formulate a flow of events, and then we can talk about the details of those events after that. Paul ___ 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)
Thanks Paul for the review, Most of the DISCUSS was composed of questions we answered all of them, and updated the text when necessary. You can see the change below: https://github.com/ietf-homenet-wg/ietf-homenet-hna/commit/27233e962f66ad72db91dac7ec7b65b7cd3b00f4 We clarified the TTL and the use of CDS as an example. Please let us know if there is anything you want us to change. Yours, Daniel On Thu, Oct 20, 2022 at 1:46 AM Paul Wouters via Datatracker < nore...@ietf.org> wrote: > Paul Wouters has entered the following ballot position for > draft-ietf-homenet-front-end-naming-delegation-18: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-homenet-front-end-naming-delegation/ > > > > -- > DISCUSS: > -- > > I have to agree with Warren here. I do not understand how this protocol is > supposed to work. It renames a bunch of DNS terms (hidden primary, primary, > seconday, AXFR/IXFR, DNS update --> HNA, DM, DOI, Control Channel, Sync > channel) which makes the document very hard to read. > > The document describes HNA, DM and DOI. These elements re-uses existing architecture elements, protocols to communicate. I do not see and renaming, but maybe you might be more explicit. happy to clarify. > For those parts where protocol glue is needed to use these DNS > technologies, > the document presents no solutions. The comment i sunclear to me. Please be more explicit so I can address your comment. > I don't understand if users can create > their own named zones, or whether this is only provider generated zones. > The > latter seems less useful to the user, the former seems to need more > specification on how to handle registry/registrar/registrant matters > (especially with respect to DS) > > I do not understand the comment. The HNA creates the zone that is expected to be published and instructs the DOI via the HNA to publish the zone. With respect to the DS what the document says is that two entities can handle the DS update the HNA and the DOI. We recommend when possible this to be handled by the DOI. The HNA is able to request the DOI to take that in charge and the DOI is able to respond whether it will handle it. How the update is performed is out of the scope of the document. > The security seems to mix up transport security with TLS and data integrity > security of the DNS protocol (typically TSIG or SIG0, but the document > claims > this cannot be used) > > no, the current version of the document does not have the words TSIG and SIG(0). In the previous version we had one section where we explained our motivation for using TLS that was all. I am taking from your comment that the more recent version address your comment correct ? Having provider generated homenet named DNS zones makes scanning for > hostnames > in those zones much easier than scanning an entire /64 IPv6 for vulnerable > devices. Eg well known host names like "tv" or "LG" or "washing_machine" or > just any <= 8 character string based hostnames or dictionary attacks. > > I do not understand the comment. Typically the zone content is managed by the user via the HNA. > Like Warren, I've added my notes as comments without splitting them further > into DISCUSSes or COMMENTs > > > -- > COMMENT: > -- > >* the CPE/HNA router is unaware of the process, and cannot respond > to queries for these names and communications to these names > require an Internet connectivity is order to perform the DNS > resolution. Such dependence does not meet the requirement for > internal communications to be resilient to ISP connectivity > disruptions [RFC7368]. > > If there is a host within the home network that is the DHCP/DNS server, > then this does not require further support from a CPE/HNA or internet > uplink. For example Linux openwrt with avahi and dnsmasq is a common > deployment of this: https://openwrt.org/docs/guide-user/base-system/dhcp > Arguably, one could say openwrt is the CPE/HNA in such case, provided > that user has their own domain they can send "dynamic DNS" updates for > on the public internet hosting their homenet zone. > yes, there are alternate ways to do what we do - we never said we were the only way to handle this. We are the only one handling this at the zone level as opposed to on a per
