Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 07/14/2014 11:47 PM, Markus Stenberg wrote: On 9.7.2014, at 18.01, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: There's still something I don't understand. If I'm understanding Steve's and Markus' work correctly, HNCP performs prefix delegation to internal routers over HNCP, and the internal routers don't proxy stateful DHCPv6 to the CPE. How does your protocol work in the presence of multiple links? Or are you assuming that only nodes directly connected to the IHAS/CPE can be advertised over your protocol? Or even more weirdly, what if you don’t want stateful DHCPv6? SLAAC + temporary addresses? Finally, what happens when there are multiple CPEs, which HNCP explicitly supports? Are you assuming that only one acts as IHAS? .. and how do the zones map to multiple uplinks .. Personally, I don’t believe in auto-exported ~full DNS information from home because current service discovery schemes (mdns, dns-sd, upnp) or even host-name discovery schemes (dhcp*) do not really lend themselves to the external visibility being _opt in_. I don’t really want to publish my home zone, and if I even did, anything that’s firewalled (= everything except few ports on few addresses) is not useful outside the home in any case. Yet, I really, really, triple-super really want to be able to access my home network devices when i'm not at home. Any part of the naming architecture better take that as a very basic requirement. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
Markus Stenberg markus.stenb...@iki.fi wrote: Personally, I don’t believe in auto-exported ~full DNS information from home because current service discovery schemes (mdns, dns-sd, upnp) or even host-name discovery schemes (dhcp*) do not really lend themselves to the external visibility being _opt in_. I don’t really want to publish my home zone, and if I even did, anything that’s firewalled (= everything except few ports on few addresses) is not useful outside the home in any case. Many people *do* want seemless access, and as their devices roam outside the home, they expect, that having entered the name of the device, they expect that whatever security they have (such as a VPN) will then get kicked off automatically. That requires that names-IPv6 mapping be available so that the VPN can know it is supposed to do something. I have way too much experience with IPsec VPNs where I have to turn the VPN on, flush my DNS cache, restart my browser, and then finally, I can access some internal name, all because some CIO thought that it would be insecure if the world knew about intranet.example.com. That's not the same as having an open network, so please stop saying that names are useless because there is no connectivity. I think that whether you auto-export, or whitelist, or blacklist, etc. is completely a local matter. We may recommend a default, but we should make sure that the mechanisms exist. -- Michael Richardson mcr+i...@sandelman.ca, Sandelman Software Works -= IPv6 IoT consulting =- pgpqE4K0xCDLj.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
Hi, On Tue, Jul 15, 2014 at 11:41:15AM -0400, Michael Richardson wrote: I think that whether you auto-export, or whitelist, or blacklist, etc. is completely a local matter. We may recommend a default, but we should make sure that the mechanisms exist. +1 for have a policy that specifies whether names should be auto-exported or not, and I actually want all my machines be visible, and most of them be *reachable*, since they can protect themselves. They have to. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 pgpV9IE_SsMQa.pgp Description: PGP signature ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 11:57 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: (1) Do we want a standardised protocol for exporting data into the global DNS? (2) What is the right policy from exporting homenet names into the global DNS? We already have two standardized protocols for exporting data into the global DNS: Dynamic DNS updates and DNS zone transfers. What's needed is just the connective tissue to set it up. There is no one right policy for exporting. I assume you mean that we need to recommend a default policy and also document the range of other policies that the end user might choose to use. It would also be nice if the PCP server could somehow feed into this: if you open a PCP port, then you get a DNS registration; if you don't, you don't. Something like that. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 15.7.2014, at 21.35, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I assume you mean that we need to recommend a default policy and also document the range of other policies that the end user might choose to use. No, I just mean that Markus not wanting anything published in DNS is policy, and that's completely independent of whether we want to define a mechanism. I have no opinion on either point. All I know is that if we want to define a mechanism, then the mechanism should be compatible with the worldview of HNCP, which includes things such as multiple internal links and multiple CPEs. The mechanism should not be tied to the particular ISPs either, except perhaps optionally. In my case, I have 2 upstream ISPs, neither of which officially even admits IPv6 exists, but I _would_ like to publish my home v6 zone somewhere.. *sigh* So to summarize: - mechanism to publish either single DNS updates or zones would be nice to have (possibly with tie-in to service discovery) - with policy bits thrown in and some sort of possible zero-conf use, with help of co-operating ISP perhaps, but _not_ requiring the first-hop ISP to be the only party you interact with. The ‘homenet’ policy stuff may be actually relatively extensive in the end, although with some sort of reasonable zeroconf defaults. In this case, policy stuff should apply to what’s advertised (and in which scope), and where it can be reached from (firewalling either with accept rules, or PCP-derived holes). (Hmm. We don’t seem to have any drafts on policy or management yet.) Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 2:45 PM, Markus Stenberg markus.stenb...@iki.fi wrote: The mechanism should not be tied to the particular ISPs either, except perhaps optionally. I think the motivation with Daniel's draft was to provide support for the optional case where the ISP wants to support it, because you get some better results in that case, but clearly the full solution needs to work well enough with partial or nonexistent ISP cooperation. Have you looked at https://datatracker.ietf.org/doc/draft-lemon-dhc-dns-pd/ ? I don't have time to work on this anymore, but the goal was to allow the ISP and the end-user to negotiate how they want to set up the DNS for a delegated prefix, and I'd like to see it move forward if there is interest. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
I assume you mean that we need to recommend a default policy and also document the range of other policies that the end user might choose to use. No, I just mean that Markus not wanting anything published in DNS is policy, and that's completely independent of whether we want to define a mechanism. I have no opinion on either point. All I know is that if we want to define a mechanism, then the mechanism should be compatible with the worldview of HNCP, which includes things such as multiple internal links and multiple CPEs. -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 7/15/14, 12:00 PM, Ted Lemon wrote: On Jul 15, 2014, at 2:45 PM, Markus Stenberg markus.stenb...@iki.fi wrote: The mechanism should not be tied to the particular ISPs either, except perhaps optionally. I think the motivation with Daniel's draft was to provide support for the optional case where the ISP wants to support it, because you get some better results in that case, but clearly the full solution needs to work well enough with partial or nonexistent ISP cooperation. That pretty much means that you need a solution that isn't bolted to DHCP, right? Or at least, that DHCP is only providing a default discovery mechanism which my CPE is completely free to ignore. Beyond the discovery, it ought to work identically regardless of whether it's my first hop ISP(s), or 20 hops away in Nairobi, right? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 3:38 PM, Michael Thomas m...@mtcc.com wrote: That pretty much means that you need a solution that isn't bolted to DHCP, right? Or at least, that DHCP is only providing a default discovery mechanism which my CPE is completely free to ignore. Beyond the discovery, it ought to work identically regardless of whether it's my first hop ISP(s), or 20 hops away in Nairobi, right? The point is that what the ISP is offering may be ideal for some users, and not others. And some ISPs may offer it, while others don't. So if there's a standard mechanism in place for using it when it's offered, if desired, then that's a win, even if not everyone wins. What happens with queries isn't important as long as they are satisfied; there are lots of ways of satisfying queries for records, but only two ways of satisfying queries for PTR records, and the ISP may support one or both of those two ways, or neither. The point of the DNS-PD document is to provide a way for the ISP and CPE to communicate about which mechanisms are supported and desired. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 7/15/14, 12:43 PM, Ted Lemon wrote: On Jul 15, 2014, at 3:38 PM, Michael Thomas m...@mtcc.com wrote: That pretty much means that you need a solution that isn't bolted to DHCP, right? Or at least, that DHCP is only providing a default discovery mechanism which my CPE is completely free to ignore. Beyond the discovery, it ought to work identically regardless of whether it's my first hop ISP(s), or 20 hops away in Nairobi, right? The point is that what the ISP is offering may be ideal for some users, and not others. And some ISPs may offer it, while others don't. So if there's a standard mechanism in place for using it when it's offered, if desired, then that's a win, even if not everyone wins. What happens with queries isn't important as long as they are satisfied; there are lots of ways of satisfying queries for records, but only two ways of satisfying queries for PTR records, and the ISP may support one or both of those two ways, or neither. The point of the DNS-PD document is to provide a way for the ISP and CPE to communicate about which mechanisms are supported and desired. What I'm trying to say is that DHCP as a way of advertising a service that will host my zone, or in some way make my homenet names globally available is OK, but it should just be about DISCOVERY and nothing else. All of the rest of the mechanisms between my CPE and some service that causes my names to be globally available ought to use standard mechanisms which are not in any way tied to topology. It's OK if discovery for non-ISP's remains an unsolved problem, let's just have one mechanism once I know who I want to speak to. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 3:55 PM, Michael Thomas m...@mtcc.com wrote: What I'm trying to say is that DHCP as a way of advertising a service that will host my zone, or in some way make my homenet names globally available is OK, but it should just be about DISCOVERY and nothing else. All of the rest of the mechanisms between my CPE and some service that causes my names to be globally available ought to use standard mechanisms which are not in any way tied to topology. Ah, yes. Agreed, at least in theory. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 7/15/14, 1:09 PM, Ted Lemon wrote: On Jul 15, 2014, at 3:55 PM, Michael Thomas m...@mtcc.com wrote: What I'm trying to say is that DHCP as a way of advertising a service that will host my zone, or in some way make my homenet names globally available is OK, but it should just be about DISCOVERY and nothing else. All of the rest of the mechanisms between my CPE and some service that causes my names to be globally available ought to use standard mechanisms which are not in any way tied to topology. Ah, yes. Agreed, at least in theory. Good. If that can be done at all, is there a reason that it cannot have those properties? That is if, say, my Google Nest spams my local homenet advertising the Google Eggs-in-one-basket DNS service, it should use the same set of protocols as a local ISP advertising over DHCP to actually hook everything up between my CPE and their service. Can we make this a *requirement*? If not, why not? Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 4:27 PM, Michael Thomas m...@mtcc.com wrote: Good. If that can be done at all, is there a reason that it cannot have those properties? That is if, say, my Google Nest spams my local homenet advertising the Google Eggs-in-one-basket DNS service, it should use the same set of protocols as a local ISP advertising over DHCP to actually hook everything up between my CPE and their service. We can safely assume that any device that is monetized through the cloud will do everything in its power to prevent us from accessing it, so that's really not the interesting test case. The interesting test case is whether a Nest-like device that isn't operated through the manufacturer's captive portal will use this set of standard protocols. (I don't know what the policies behind Nest are specifically, but the phenomenon I'm talking about is more the rule than the exception in citizen-grade IoT devices at the moment). Can we make this a *requirement*? If not, why not? We can't force anybody to do anything, that's why not. But we can document a mechanism for doing it, and if implementation becomes widespread in home gateways, it's not unreasonable to think that devices that _don't_ depend on a captive portal for monetization will use these protocols rather than reinventing the wheel. But bear in mind that this is a fairly big if. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 7/15/14, 1:53 PM, Ted Lemon wrote: We can safely assume that any device that is monetized through the cloud will do everything in its power to prevent us from accessing it, so that's really not the interesting test case. The interesting test case is whether a Nest-like device that isn't operated through the manufacturer's captive portal will use this set of standard protocols. (I don't know what the policies behind Nest are specifically, but the phenomenon I'm talking about is more the rule than the exception in citizen-grade IoT devices at the moment). I believe we are at least in the fortunate situation that nobody's tried hard to do a naming provider land grab yet, so there may yet be time to do the right thing. Can we make this a *requirement*? If not, why not? We can't force anybody to do anything, that's why not. But we can document a mechanism for doing it, and if implementation becomes widespread in home gateways, it's not unreasonable to think that devices that _don't_ depend on a captive portal for monetization will use these protocols rather than reinventing the wheel. But bear in mind that this is a fairly big if. I mean a requirement for the homenet working group, of course. I'm not entirely sure what the appetite is for wheel reinvention in this space is, but I'm guessing it's not that high if this working group comes up with something that is workable, and gives CPE vendors something to shoot for rather than a bunch of ad hoc point solutions requiring bilateral dev agreements. We should be really clear that CPE !== Router too. If the Nest wants to be my DNS name repository that gets mirrored out in Google's intrastructure somehow, that should OK too. I think its main requirement is that it: a) doesn't move around out of my homenet b) is always on Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 11:45 AM, Markus Stenberg markus.stenb...@iki.fi wrote: On 15.7.2014, at 21.35, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: I assume you mean that we need to recommend a default policy and also document the range of other policies that the end user might choose to use. No, I just mean that Markus not wanting anything published in DNS is policy, and that's completely independent of whether we want to define a mechanism. I have no opinion on either point. All I know is that if we want to define a mechanism, then the mechanism should be compatible with the worldview of HNCP, which includes things such as multiple internal links and multiple CPEs. The mechanism should not be tied to the particular ISPs either, except perhaps optionally. In my case, I have 2 upstream ISPs, neither of which officially even admits IPv6 exists, but I _would_ like to publish my home v6 zone somewhere.. *sigh* So to summarize: - mechanism to publish either single DNS updates or zones would be nice to have (possibly with tie-in to service discovery) - with policy bits thrown in and some sort of possible zero-conf use, with help of co-operating ISP perhaps, but _not_ requiring the first-hop ISP to be the only party you interact with. The ‘homenet’ policy stuff may be actually relatively extensive in the end, although with some sort of reasonable zeroconf defaults. In this case, policy stuff should apply to what’s advertised (and in which scope), and where it can be reached from (firewalling either with accept rules, or PCP-derived holes). (Hmm. We don’t seem to have any drafts on policy or management yet.) There is some dependency on security for these. Mark Cheers, -Markus ___ 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] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 5:12 PM, Michael Thomas m...@mtcc.com wrote: I believe we are at least in the fortunate situation that nobody's tried hard to do a naming provider land grab yet, so there may yet be time to do the right thing. That's not the point. If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device without sending them your data, so chances are the device is going to just talk to their portal using a proprietary scheme and ignore what we want. Which is fine; my point is not that they are evil, but just that the use case for this may not be quite as broad as we imagine. I still think it's worth doing, and I hope that over time this stuff moves in the direction of more flexibility. What we do in homenet can easily either make that easy or make it hard, so we should try to make it easy. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On 07/15/2014 04:42 PM, Ted Lemon wrote: On Jul 15, 2014, at 5:12 PM, Michael Thomas m...@mtcc.com wrote: I believe we are at least in the fortunate situation that nobody's tried hard to do a naming provider land grab yet, so there may yet be time to do the right thing. That's not the point. If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device without sending them your data, so chances are the device is going to just talk to their portal using a proprietary scheme and ignore what we want. Which is fine; my point is not that they are evil, but just that the use case for this may not be quite as broad as we imagine. I still think it's worth doing, and I hope that over time this stuff moves in the direction of more flexibility. What we do in homenet can easily either make that easy or make it hard, so we should try to make it easy. Oh, ok. But this entire area is going to be pretty darn tricksey to get right, and we can have some hope that after enough proprietary we-need-to-get-something-done from vendors, they'll be somewhat relieved to have exactly One something that's standardized to support. I've seen this many times at $routervendor, even when they have their own business model in mind. So we shouldn't be too fatalistic... the game is still young on this account. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 8:46 PM, Michael Thomas m...@mtcc.com wrote: So we shouldn't be too fatalistic... the game is still young on this account. I applaud and encourage your optimism. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 5:46 PM, Michael Thomas m...@mtcc.com wrote: On 07/15/2014 04:42 PM, Ted Lemon wrote: On Jul 15, 2014, at 5:12 PM, Michael Thomas m...@mtcc.com wrote: I believe we are at least in the fortunate situation that nobody's tried hard to do a naming provider land grab yet, so there may yet be time to do the right thing. That's not the point. If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device without sending them your data, so chances are the device is going to just talk to their portal using a proprietary scheme and ignore what we want. Which is fine; my point is not that they are evil, but just that the use case for this may not be quite as broad as we imagine. I still think it's worth doing, and I hope that over time this stuff moves in the direction of more flexibility. What we do in homenet can easily either make that easy or make it hard, so we should try to make it easy. Oh, ok. But this entire area is going to be pretty darn tricksey to get right, and we can have some hope that after enough proprietary we-need-to-get-something-done from vendors, they'll be somewhat relieved to have exactly One something that's standardized to support. I've seen this many times at $routervendor, even when they have their own business model in mind. So we shouldn't be too fatalistic... the game is still young on this account. Dear Mike, http://tools.ietf.org/html/rfc6281 offers a fair amount of detail about safely leveraging home networks. Further examination of this scheme shows selective publications of devices in DNS and expects other services to be indirectly shared by these devices. It makes extensive use of ULAs that offer a stable basis for publishing addresses in DNS. http://tools.ietf.org/html/rfc6890 and homenet arch also references use of ULAs. http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6 3.6.6. ULAs as a hint of connection origin The basic security related premise employed by mDNS can be confirmed by use of ULAs. It is also conceivable anti-distribution protection schemes can be satisfied when ULAs have a common prefix. There are also many home routers already able to combine GUA and ULAs. Add L2TP and it seems we are done. Regards, Douglas Otis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
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
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
- The architecture document [draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific. - The DHCP Options document [draft-mglt-homenet-naming-architecture-dhc-options] is currently CPE specific. Ah, I see. That definitely needs to be clarified. - a) Explicitly mention that the CPE is an example [...] - b) Introduce a new designation like the Internet Homenet Authoritative Server. [...] Maybe b) is better. Definitely so. Replacing CPE with IHAS in the text will allow you to see more clearly where you've assumed that the CPE and IHAS are co-located. There's still something I don't understand. If I'm understanding Steve's and Markus' work correctly, HNCP performs prefix delegation to internal routers over HNCP, and the internal routers don't proxy stateful DHCPv6 to the CPE. How does your protocol work in the presence of multiple links? Or are you assuming that only nodes directly connected to the IHAS/CPE can be advertised over your protocol? Finally, what happens when there are multiple CPEs, which HNCP explicitly supports? Are you assuming that only one acts as IHAS? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
Hi Please see my comments inline. On Sat, Jul 5, 2014 at 12:12 AM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: The main idea is that the CPE builds the zone for the whole home network. Thanks for the clarification. Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that right now I'm strongly opposed to this protocol. I hold no opinion yet on whether proxying is necessary (although I hope it isn't), but I am strongly opposed to binding the DNS proxy role with the CPE at the protocol level. (This does not mean that the DNS proxy cannot be colocated with the CPE, only that I find a protocol that mandates this kind of colocation unacceptable.) I do not think our architecture is bound to the CPE. In the architecture document we mention that the CPE is the most likely to host the DNS zone for the home network. However, I agree it can be any other node. We do not either mandate any collocation of functions. If you could point specific sections, that would help to clarify the next versions. 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. More specifically, suppose you have a authoritative DNS server in your homenet work. In the draft we said a CPE will most likely handle this function. This server MAY NOT want to respond for queries that are coming from outside the home network. In this case, This server outsources the authoritative server for queries coming from the Internet to a third party. DNS queries for the Domain name of the home network will be answered by the CPE when the query comes form the home network and by the third party when the query comes from outside the home network. I am rephrasing your use case to make sure we have the same in mind. Please clarify if we do not agree on the use case. You consider is a web server in the home network, that you want to be reachable from the Internet. In order to do that you buy a specific domain name www.homenet.com. The domain is hosted on a Public Authoritative Server, you edit the zone, add the IP address of your server. Oh, nothing that geeky. I copy my vacation photographs onto my NAS. I click the share over the Internet button on the NAS's web interface. The NAS performs DynDNS registration, I get a link that I can copy-paste into an e-mail to my mom: Mom, the vacation photographs are on http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the password is 1234. I've avoided putting my private photographs on Google's servers -- and we're changing the world. I click on the share over the internet button on my stereo's web interface. The stereo performs DynDNS registration, I get a link that I can copy-paste. Daniel, the song you found so funny at my place last night night is on http://www.user-fe83-paris-13.dyndns.example.com/funny-music, the password is 1234. I've avoided sending 20MB of Ukrainian R'n'B over SMTP -- and we're changing the world. I'm at the train station. There's a strike on. I'm playing Civilisation on my laptop in an internet cafe. I click the Invite over the Internet button. Civilisation performs DynDNS registration, I get a link which I can copy-paste. Daniel, I'm bored, join me for a game of Civilisation, link is civ://www.user-fe83-paris-13.dyndns.example.com, password is 1234, and now I can wholeheartedly support the cheminot's strike -- we're changing the world again. To me the last use case you provide is not in the scope of home network unless you are unsing a VPN. The two first examples seems to be related to WEBDAV. On a DNS point of view, it looks to me that they involve only a DNS registration. Suppose there is not NAT. Your NAS requests /discovers its IP address and then registers its IP address to the registrar. This means that at one time you have configured your NAS with the appropriated credentials to update your zone in the registrar. 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. 1) It is not scalable in term of configuration: if you have a single server, you can edit the zone. If you have 100 devices (which is not much) you will not be able to do it especially if you IP prefix changes every day. 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 internet cafe. To me the Internet cafe is not the home network. The issue of buggy CPE is an important one. The goal of the two drafts is to provide guidance to
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
The main idea is that the CPE builds the zone for the whole home network. Thanks for the clarification. Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that right now I'm strongly opposed to this protocol. I hold no opinion yet on whether proxying is necessary (although I hope it isn't), but I am strongly opposed to binding the DNS proxy role with the CPE at the protocol level. (This does not mean that the DNS proxy cannot be colocated with the CPE, only that I find a protocol that mandates this kind of colocation unacceptable.) I am rephrasing your use case to make sure we have the same in mind. Please clarify if we do not agree on the use case. You consider is a web server in the home network, that you want to be reachable from the Internet. In order to do that you buy a specific domain name www.homenet.com. The domain is hosted on a Public Authoritative Server, you edit the zone, add the IP address of your server. Oh, nothing that geeky. I copy my vacation photographs onto my NAS. I click the share over the Internet button on the NAS's web interface. The NAS performs DynDNS registration, I get a link that I can copy-paste into an e-mail to my mom: Mom, the vacation photographs are on http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the password is 1234. I've avoided putting my private photographs on Google's servers -- and we're changing the world. I click on the share over the internet button on my stereo's web interface. The stereo performs DynDNS registration, I get a link that I can copy-paste. Daniel, the song you found so funny at my place last night night is on http://www.user-fe83-paris-13.dyndns.example.com/funny-music, the password is 1234. I've avoided sending 20MB of Ukrainian R'n'B over SMTP -- and we're changing the world. I'm at the train station. There's a strike on. I'm playing Civilisation on my laptop in an internet cafe. I click the Invite over the Internet button. Civilisation performs DynDNS registration, I get a link which I can copy-paste. Daniel, I'm bored, join me for a game of Civilisation, link is civ://www.user-fe83-paris-13.dyndns.example.com, password is 1234, and now I can wholeheartedly support the cheminot's strike -- we're changing the world again. 1) It is not scalable in term of configuration: if you have a single server, you can edit the zone. If you have 100 devices (which is not much) you will not be able to do it especially if you IP prefix changes every day. 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 internet cafe. 2) It is not scalable in term of software installation: every registrar have its own API for configuring the zone. Then why not standardise a registration API? Furthermore, if you suppose all registrar agree to have a unique way to do so, -- suppose nsupdate -- all devices will have to implement this protocol. For most devices this may be not a problem, however, for all devices like sensors having to perform nsupdate every day, may impact their battery life time for nothing. If you really believe that proxying is necessary (and I'd like actual figures to support this claim -- how many devices do you have in your home that cannot afford the cost of one registration every few hours?), then there's nothing preventing a DNS proxy from using the standardised registration protocol on behalf of its clients. Then clients can choose whether to go through the proxy, and users can choose whether use the ISP-provided proxy (co-located with the CPE) or a third-party proxy that happens to work. 3) It is not automatic and flexible: A new device that is in your network cannot have a name, as an admin needs to register its name in the zone myhomenet.com, or provide the credential for it to all new devices. That's what we have HNCP for -- for distributing random data to all devices. 4) It is not scalable in term of zone management and bandwidth: Suppose you have n devices in the home network and a renumbering occurs. All these n devices will contact the Public Authoritative Server that may be miles away from your home network. I've got 100 devices. I renumber. Each device sends 500 bytes of registration data. My monthly Internet bill has just increased by 50 kB. 5) it exposes your homenet to IP disruption. 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? Or are you deprecating that? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
Hi, Thanks for the question. If I understand it properly, the use case you consider: 1) you set up a web server in your homenet, 2) you want it to be accessed from the outside so you register your domain name and register the IP address to the zone. Note that In this case, the Authoritative Naming service is outsourced to a third party which is what we want to achieve to. Your case is very specific. First your web server is a fixed node that is expected to last at least a few years in your home network. This makes manual configuration feasible. Then you only have one node you may install a specific software that updates the IP address to the DNS authoritative servers. This is to avoid multiple DNS configuration at every IP renumbering. At last you have an interface on your server you may not have with other nodes. On the other hand, if you have multiple devices, you are unlikely to handle / edit the zone manually or install the specific software on each device -- given that some device will not support it. For this reason we would like the CPE to handle this complexity. The advantages I see using the CPE are: - Ease the naming of device of various nature. - CPE remains in the homenet and may be easier to be authenticated than all different devices. - CPE presents a centralized point for end user interactions - CPE are powerful enough to handle complex policies... - CPE can integrate multiple protocols to publish a zone. Suppose mDNS is used by a node, than registration of its IP address and name cannot be perfomed on a public authoritative server cannot be performed using mDNS. - BR, Daniel On Wed, Jul 2, 2014 at 10:38 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Since I saw a previous version of that in London, I've been wondering about one thing, but didn't dare ask. Please be indulgent if it is a stupid question. Why does the CPE need to intervene in what is an application layer interaction between two consenting adults? If I'm setting up a web server on my home network, I'd expect that negotiating a DNS registration is a private matter between the web server and the authoritative DNS master; why would I want the CPE to act as intermediary? Thanks, -- 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
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
Thanks for your answer, Daniel. If I understand it properly, the use case you consider: 1) you set up a web server in your homenet, 2) you want it to be accessed from the outside so you register your domain name and register the IP address to the zone. Note that In this case, the Authoritative Naming service is outsourced to a third party which is what we want to achieve to. No, I think that I'm speaking of the same use case as your draft. (I'm not sure, since your draft takes the use case for granted -- I'm probably missing some background here, sorry for not being more attentive previously.) I've got a device that wants to be advertised in the global DNS (a web server is the obvious example, but it doesn't matter). Your draft suggests (I think) that the device should speak to the CPE which will take care of the interaction with the public DNS (arrow 6 in Figure 1 is missing, by the way). I'd like to understand why the device needs to go through the middleman rather than speaking directly to the authoritative DNS server. My family was poor but honest, Daniel, and NATed addresses were all we could afford. Notwithstanding our difficult conditions, my parents took a lot of care to bring me up to believe that end-to-end is always better than proxying. Since you're advocating proxying, I'd like to understand why you think it is necessary. What is more, I'd like to understand why you require that the proxy be co-located with the CPE. (It could certainly be implemented on the CPE, but I don't understand why the protocol requires that.) You give some good reasons below, and I think they should be included in the draft: - Ease the naming of device of various nature. Please explain. - CPE remains in the homenet and may be easier to be authenticated than all different devices. Good point. - CPE presents a centralized point for end user interactions I'm not convinced about that, the authoritative DNS master seems like the natural place for end-user interactions. (Note that this does not prevent the CPE's web interface from implementing some sort of proxy to the DNS master's interface.) - CPE are powerful enough to handle complex policies... Everything is powerful enough nowadays. My abacus has a four-core chip. - CPE can integrate multiple protocols to publish a zone. Suppose mDNS is used by a node, than registration of its IP address and name cannot be perfomed on a public authoritative server cannot be performed using mDNS. I strongly disagree. I don't want mDNS-DNS proxying. Registering in the global DNS is something that should be under user control, while mDNS is something that happens automatically (for better or worse). -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
I'd like to understand why the device needs to go through the middleman rather than speaking directly to the authoritative DNS server. You may find some useful background in RFC 5625. I'm increasingly confused. RFC 5625 is about proxying DNS requests from the LAN. Daniel's draft is about proxying dynamic DNS updates, right? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Thu, Jul 03, 2014 at 02:39:26PM +0200, Juliusz Chroboczek wrote: I'm increasingly confused. RFC 5625 is about proxying DNS requests from the LAN. Daniel's draft is about proxying dynamic DNS updates, right? Yes. My impression is that the idea in Daniel's draft is that the ISP will take the load of most DNS queries, and will effectively mark a boundary of split-horizon, so that some names resolve both outside and inside the local network, and some will resolve only inside. This is really a formalization of the way many CPE systems already work, where they update services like Dyn (full disclosure: my employer), no-ip, and so on. The differences seem to be (1) that the relationship is somehow stapled to the ISP rather than to an outside service and (2) that the commands all flow over Dynamic Update as opposed to any other protocol. Personally, I see the value in (2), but I'm worried about (1). Thinking as a vendor, I note that (2) basically means ditching a lot of running code, although for a protocol I think is poorly designed. A -- Andrew Sullivan a...@anvilwalrusden.com ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Thu, 3 Jul 2014, Douglas Otis wrote: Since mDNS is unable to make determinations regarding the ability of a device to safely interact with the Internet, an overlay approach could be taken. Although details are missing from the Hybrid Unicast/Multicast DNS-Based Service Discovery draft, use of ULAs can better establish a secure separation than can a split-horizon. DNS was I would very much prefer to see a solution where you can have policy to limit what is being published and to where, rather than the very binary use ULAs for Internal resources. Apart from the fact that I do not like ULAs, I would also like to see more granularity and to enable the possibility to have zoning within the home network, for instance to have guest networks. So we need to enable possibility to control propagation of service discovery information, we need packet filtering, and we also need some kind of identity for the devices so they can interact with all of this. -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 2, 2014, at 1:38 PM, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: Since I saw a previous version of that in London, I've been wondering about one thing, but didn't dare ask. Please be indulgent if it is a stupid question. Why does the CPE need to intervene in what is an application layer interaction between two consenting adults? If I'm setting up a web server on my home network, I'd expect that negotiating a DNS registration is a private matter between the web server and the authoritative DNS master; why would I want the CPE to act as intermediary? Dear Juliusz, That is a very good question. In essence, especially because ULA address use was ignored by the mDNS proxy scheme, anything reported by mDNS that is routable is to be published into DNS as a means to establish a routable unicast alternative to that of mDNS. One major downside is this will end up including devices never intended to have direct access from the Internet, where things like an All-in-One printer or baby monitor may find themselves. Use of a ULA addressing space offers a locally routable alternative without exposing these devices to the Internet. Unfortunately, many in the homenet wg consider this to be a problem to be resolved by the device rather than the homenet protocol. Regards, Douglas Otis ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
