Hi
Thank you for your response and feed backs. See my response in the text
body as well as in your text. I think we are making progress.
[draft-mglt-homenet-front-end-naming-delegation] and
[draft-mglt-homenet-naming-architecture-dhc-options] are distinct
documents. The one describes the architecture to outsource the homenet
authoritative naming service on the Internet. In that sense it should not
be CPE specific. The second draft describes how DHCP Option could help to
set this architecture. It does not mean they must always be used.
A brief response to how these document are CPE specific:
- The architecture document
[draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific. See
below for more details.
- The DHCP Options document
[draft-mglt-homenet-naming-architecture-dhc-options] is currently CPE
specific. It can be made non CPE specific in two ways: 1) Keeping the
document CPE specific and adding a section that describes how the option
can be used when functions are not collocated. or 2) making the whole
document non CPE specific. Reasons I would prefer 1) are: it makes things
easier to read and understand, generalization is easy and I believe these
options will mostly be used by CPE. That said both options are fine to me.
See more details below.
A more detailed response:
In [draft-mglt-homenet-front-end-naming-delegation] we use the term
CPE, as this is the device we are focused on, and we also believe that in
most homenet this device will play this role. However, there are no such
restriction. In this document, The CPE is the device that owns the Homenet
Zone and that could publish the zone on the Internet. Instead, of
publishing itself, it outsources the Zone to the Public Server. In order to
clarify this misunderstanding, we can:
- a) Explicitly mention that the CPE is an example, and any device
can be
- b) Introduce a new designation like the Internet Homenet
Authoritative Server.
Maybe b) is better. I would appreciate to have feed backs. Other
designations are also welcome!
In [draft-mglt-homenet-naming-architecture-dhc-options] we took advantage
of the collocation DHCP client that exchange with the DHCP Server of the
ISP, signing of the Zone and the Reverse Zone by the same device. If we
want to split the different functions we may have to consider:
- the CPE,
- the Internet Homenet Authoritative Server
- the Internet Reverse Homenet Authoritative Server
To me only the Internet Reverse Homenet Authoritative Server needs to
dialogue with the ISP, as the ISP manage the delegation of the Reverse
Zone. If the Internet Reverse Homenet Authoritative Server is not colocated
with the CPE, the DHCP Server of the home network will have to relay these
options to the DHCP Server of the ISP.
The Internet Homenet Authoritative Server can use the DHCP Options with any
other DHCP Server that is configured to respond to these options.
In the current draft, we used only one key the one the CPE uses to sign
both the Homenet Zone and the Reverse Zone. If this may not be performed by
the CPE, we need to have two keys: one for the Homenet Zone and one for the
Reverse Zone. So that's something we missed, thanks for pointing it out.
To me a network that have different entity for the CPE, the Internet
Homenet Authoritative Server and the Internet Reverse Homenet
Authoritative Server in different devices and a DHCP Relay may not be a
home network anymore. I suggest the draft 1) remain restricted to the CPE
and 2) add a section to describe how things could work if the functions are
split into different devices. I also agree we need to have different
options for the Key of the Reverse Homenet Zone and Homenet Zone. The
reason to do so, is that
Any opinions on that?
I also added small comments inline.
BR,
Daniel
On Wed, Jul 9, 2014 at 3:39 AM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:
> Thanks for your patience, Daniel. I feel I'm understanding a little more
> now. My main misunderstanding was the following:
>
> - you're not populating DNS with mDNS data, you're populating it with the
> DHCP hostname data; I now understand that mDNS is mostly orthogonal.
>
> What I still don't understand is how your protocol can work when the
> hidden master is not the CPE.
>
> > In the architecture document we mention that the CPE is the most likely
> > to host the DNS zone for the home network.
>
> I'd really like to encourage you to revise the drafts so that it makes it
> clear that the hidden master is not necessarily the CPE. I'd be
> particularly keen to understand how the hidden master can sign the zone
> when it is not the CPE, given that you expect signing keys to be obtained
> over DHCP.
>
> > I do not think our architecture is bound to the CPE [...] If you could
> > point specific sections, that would help to clarify the next versions.
>
> This document describes a homenet naming architecture where the CPEs
> manage the DNS zone associates to its home network,
>
> [...]
>
> the DNS(SEC) Homenet Zone built by the CPE is outsourced to Public
> Authoritative Servers.
>
> [...]
>
> The zone signing and secure delegation can be performed either by the
> CPE or by the Public Authoritative Servers.
>
> [...]
>
> outsourcing the authoritative naming service from the CPE
>
> ...and so forth, and so on. I'm sure you can see where my confusion stems
> from ;-)
>
> > Similarly, I do not recall using the term proxy in one or the other
> > draft, and I do not see what could be considered as a proxy.
>
> I fear I wasn't very clear:
>
> 1. the homenet nodes populate the master zone at the hidden master (which
> is not at all the CPE, as we've established above) using DHCP;
>
This DHCP is the one of the home network and not the one of the ISP.
>
> 2. the hidden master (which is not at all the CPE) performs a zone
> transfer to its secondaries (which are not at all the ones hardwired by
> the ISP into the CPE) using normal DNS(SEC) procedures.
>
> So in effect the hostname data is flowing (1) from the node to the hidden
> master which (2) forwards it to the authoritative secondaries. In effect,
> it's being proxied from the node to the secondaries by the hidden master.
>
> OK, If I understand correctly you called that proxy as nodes do not
register directly to the Public Authoritative Server. Instead, this is
performed by the Internet Homenet Authoritative Server.
Note also that nothing prevents the node to perform its registration to the
Public Authoritative Server directly. This architecture do nothing against
this. This is simply not part of the architecture.
> > In the architecture we propose, things may be as follows: the NAS only
> > needs a hostname: myserver for example. You plug the NAS in your home
> > network, it announces its name via DHCP. The DHCP transmit the
> > information to the entity that manages the DNS zone, which then
> > outsource the zone to the registrar. You NAS does not need to be
> > configured to update the zone at the registrar.
>
> Ah. I think that's the crucial point -- it's easier to provide
> credentials to a single node rather than to every node that needs to
> register in the global DNS. That makes sense.
>
> So how does the hidden master get the credentials? You say:
>
> The DHCP Server makes the Public Key available to the DNS servers, so
> the CPE can secure its DNS transactions. Note that the Public Key
> alone is not sufficient to perform the authentication [...] How the
> binding is performed is out of scope of the document. It can be
> a centralized database or various bindings may be sent to the
> different servers.
>
> That speaks about the ISP's DHCP server, right? But now that we've
> established that the hidden master is not the CPE -- it's not necessarily
> on the same link as the DHCP server. Are you assuming a DHCP proxy at the
> CPE?
>
As mentioned above the DHCP Options have currently been established for CPE.
>
> I also don't understand what you mean by "various bindings" in the last
> sentence quoted above. I'd appreciate a clarification. Perhaps you can
> tell us how the private keys are distributed in your implementation?
>
> A public key alone is not sufficient for authentication. You need an ID.
This ID can be the domain name, the end user ID , the line number..... This
is not specified in the document. As name servers needs the name and the
key, the binding I would use would be the name and the key.
> >>> Suppose your ISP has a connectivity issue, even a node in your home
> >>> network will not be able to contact your web server as the DNS(SEC)
> >>> resolution is not possible.
>
> >> But my nodes are still running mDNS/zeroconf, right?
>
> > By the way, I am not deprecating the use of mDNS at all it is simply
> > orthogonal.
>
> What I meant by that is that you're still running mDNS, so losing
> connectivity to the master won't prevent you from resolving using mDNS.
> However, I now see that you're not deriving the DNS zone from mDNS, so the
> name you're interested in might very well not be advertised over mDNS.
>
> Thanks for your patience,
>
> -- Juliusz
>
--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
