Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
On Jul 15, 2014, at 5:46 PM, Michael Thomas wrote: > On 07/15/2014 04:42 PM, Ted Lemon wrote: >> On Jul 15, 2014, at 5:12 PM, Michael Thomas 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
On Jul 15, 2014, at 8:46 PM, Michael Thomas 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 07/15/2014 04:42 PM, Ted Lemon wrote: On Jul 15, 2014, at 5:12 PM, Michael Thomas 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 5:12 PM, Michael Thomas 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 Jul 15, 2014, at 11:45 AM, Markus Stenberg wrote: > On 15.7.2014, at 21.35, Juliusz Chroboczek > 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 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 4:27 PM, Michael Thomas 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:09 PM, Ted Lemon wrote: On Jul 15, 2014, at 3:55 PM, Michael Thomas 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 3:55 PM, Michael Thomas 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, 12:43 PM, Ted Lemon wrote: On Jul 15, 2014, at 3:38 PM, Michael Thomas 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:38 PM, Michael Thomas 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:00 PM, Ted Lemon wrote: On Jul 15, 2014, at 2:45 PM, Markus Stenberg 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 2:45 PM, Markus Stenberg 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
>> 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. Uh-huh. Oh, and lest I forget: HNCP does not require stateful DHCPv6 for end nodes. It would be cool if the dynamic DNS mechanism didn't require it either. -- 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 15.7.2014, at 21.35, Juliusz Chroboczek 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
> 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 Jul 15, 2014, at 11:57 AM, Juliusz Chroboczek 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
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
> Many people *do* want seemless access, and as their devices roam outside the > home, I think there are two issues here which are mostly orthogonal: (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? I'm pretty sure that (1) can be answered without giving a full answer to (2). -- 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
Markus Stenberg 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 , 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
On 07/14/2014 11:47 PM, Markus Stenberg wrote: On 9.7.2014, at 18.01, Juliusz Chroboczek 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
