Re: [homenet] Host naming in Homenet
Markus Stenberg wrote: On 26.8.2015, at 16.17, Juliusz Chroboczekj...@pps.univ-paris-diderot.fr wrote: I guess we might as well simply recommend MDNS Fair enough, assuming there is mDNS proxying in the Homenet. (Or should we be speaking on ff05::fb and counting on Pierre to do some magic?) It is not really an option - it requires serious host changes. Of course, if you’re completely crazy you could do some sort of linklocal - sitelocal - linklocal translation, but I would rather not go there especially as you would want to eliminate e.g. linklocal addresses from A/ records =conflict resolution breaks = oops. The options in increasing level of evil from my point of view are: - DHCPv6 (ha ha! but at least it is simple in this case) - hybrid proxy (rather complex but works) - mdns-to-mdns proxying (complex, fragile, easy to break) Cheers, -Markus IMHO This is a very worthwhile discussion that we've glossed over for a long time. I've seen several drafts over the course of the Homenet WG. e.g. https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-03 discusses how DNS can be bootstrapped and parent domains delegated to a Homenet Border Router. So that seems to be one portion of the overall jigsaw. And https://tools.ietf.org/id/draft-jeong-homenet-device-name-autoconf-03.txt talks about each device auto-naming then the router performing discovery using NI [RFC4620] coupled with dynamic update [RFC2136] to seed LLN devices into the (global) DNS. We also have https://datatracker.ietf.org/doc/rfc7558/?include_text=1 that details requirements for extending mDNS e.g. linking mDNS sub-domains of the parent namespace to physical interfaces. Meanwhile windows in the enterprise generally uses a delegated portion of the overall DNS namespace such as win.company.com and it's own update mechanisms internally. So what are the expectations/requirements for naming in Homenet, and particularly host - router interaction? How will name registration work? Are we looking at a single flat name space? How will name conflicts be resolved? Are we looking at a name space that is link dependent? Are we looking at a name space that includes delegations via subdomains for special devices or technologies? Are we looking at supporting nodes that roam from link to link often within the Homenet? What about devices that couple and uncouple from the Homenet? (mobile phones with wifi and 3G) Is this going to turn into (another) DNS/mDNS war, or is there a model in which the two can peacefully co-exist? e.g. query mDNS first? query both simultaneously? e.g. seed mDNS into a DNS delegated domain? e.g. translate mDNS queries into DNS and perhaps vice versa? How will resolution work? Will the end host be responsible for performing multiple resolution? Or the Homenet router? Are we looking at electing a single authoritative DNS server for all of Homenet? With standby? Or one DNS server per Homenet Border Router? Or is every Homenet device a DNS/name server and we deploy a (large) search list. Perhaps most importantly: What mechanisms do common host operating systems support today? Regards, RayH ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
What does that mean for shncpd? I do nothing, and wait for the pixie dust to settle? If you feel motivated you could implement all the SHOULDs of HNCP naming and sd: 1. find (or implement) a DNS cache and populate it using the HNCP DNS and naming TLVs, and the recursive DNSs from the ISPs, then announce said cache to your clients using RAs and DHCPv4/v6 2. find or implement an MDNS hybrid proxy and hook it up to your HNCP implementation 3. implement stateful DHCPv6 and populate your DNS cache with the acquired hostnames Consider 2 and 3 bonuses :P ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On 08/27/2015 09:18 AM, Markus Stenberg wrote: Well, feel free to come up with your magic pixie dust solution, as you seem to keen to pipe up every time on the topic, I have been waiting for it years (literally). This has nothing to do with me, your ongoing ad hominems aside. *None* of them deal with host naming well. They will require far, far better UI and structural support at the very least. As should be expected for any new piece of major functionality. This is distinctly different that, say, routing which traditionally does not put requirements on the host. Naming has always had implications. So saying host changes are out of scope is dismissive and counter factual. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
Thanks for the explanation, Markus. What does that mean for shncpd? I do nothing, and wait for the pixie dust to settle? -- Juliusz ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] DNS delegation [was: Host naming in Homenet]
On 27.8.2015, at 18.10, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr wrote: In short -- the ability within the Homenet to do scp backup-20150827.tar mylaptop.home:backup/ and having it work no matter which link the laptop happens to be connected to. I'd add whether it was connected to Homenet or the Internet. I distinctly remember complaining that Daniel's protocol didn't allow for announcing my laptop when it's not in the Homenet, and hearing that this is out of scope. Here's the thread: http://www.ietf.org/mail-archive/web/homenet/current/msg03724.html For that, all you need is (appropriately authenticated) DNS-Update to point at your home’s DNS server(s) and Bob’s your uncle. -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On 27.8.2015, at 15.38, Ray Hunter ray.hun...@globis.net wrote: IMHO This is a very worthwhile discussion that we've glossed over for a long time. I've seen several drafts over the course of the Homenet WG. e.g. https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-03 discusses how DNS can be bootstrapped and parent domains delegated to a Homenet Border Router. So that seems to be one portion of the overall jigsaw. And https://tools.ietf.org/id/draft-jeong-homenet-device-name-autoconf-03.txt talks about each device auto-naming then the router performing discovery using NI [RFC4620] coupled with dynamic update [RFC2136] to seed LLN devices into the (global) DNS. Requires host changes. Out of scope. We also have https://datatracker.ietf.org/doc/rfc7558/?include_text=1 that details requirements for extending mDNS e.g. linking mDNS sub-domains of the parent namespace to physical interfaces. Meanwhile windows in the enterprise generally uses a delegated portion of the overall DNS namespace such as win.company.com and it's own update mechanisms internally. So what are the expectations/requirements for naming in Homenet, and particularly host - router interaction? How will name registration work? Ideally, zeroconf. So registration is a strong word here. Are we looking at a single flat name space? Probably not, at least if mdns is leveraged - it’s conflict resolution is strictly per-link, and as we have multiple links, we either implement clumsy conflict resolution scheme within mdns - dns conversion step (not recommend) or provide zone per link. How will name conflicts be resolved? See above. Are we looking at a name space that is link dependent? Depends. I can see two different namespaces in general: [1] manually configured, to be updated to local master, and then to ISP (Miguel’s stuff, i.o.w.); this could be flat [2] zeroconf, based on mDNS, that is zone-per-link, and the associated zeroconf paths; clearly not flat Are we looking at a name space that includes delegations via subdomains for special devices or technologies? Not sure what you mean by this. Are we looking at supporting nodes that roam from link to link often within the Homenet? Possibly. The manual (dns-update) based mechanism could ensure that laptop.fingon.iki.fi points to my laptop _wherever it is_, inside or outside home. It is also known as laptop.lan.home by default, by simple mDNS - DNS conversion and local hnetd action. (I haven’t done the [1] part, so that part of the example is fictional in my laptop case.) What about devices that couple and uncouple from the Homenet? (mobile phones with wifi and 3G) See above. Is this going to turn into (another) DNS/mDNS war, or is there a model in which the two can peacefully co-exist? They coexist in my mind, see above. e.g. query mDNS first? query both simultaneously? mDNS is not really useful in and of itself in homenet, as it is per-link. mDNS proxied to DNS (hello, hybrid proxy), on the other hand, is the bee’s knees :-) e.g. seed mDNS into a DNS delegated domain? Seed mDNS hybrid proxy NS entries to DNS; I am not convinced of zeroconf DNS zone population via mDNS for various reasons. e.g. translate mDNS queries into DNS and perhaps vice versa? Yes. How will resolution work? draft-ietf-dnssd-hybrid, draft-stenberg-hybrid-proxy-zeroconf, HNCP. Will the end host be responsible for performing multiple resolution? Or the Homenet router? Host. Are we looking at electing a single authoritative DNS server for all of Homenet? With standby? No, see HNCP. We could do that for the manually configured part, see above. Or one DNS server per Homenet Border Router? No. Or is every Homenet device a DNS/name server and we deploy a (large) search list. Yes. Perhaps most importantly: What mechanisms do common host operating systems support today? The operating systems I care about support mDNS, DNS and DNS-SD. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On 08/27/2015 08:33 AM, Markus Stenberg wrote: Requires host changes. Out of scope. This is *complete* bs. *None* of this -- MDNS included -- is well supported (please spare me the bleating about Apple, blah blah blah, it sucks too). Any real solution will require host changes. Period. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Host naming in Homenet
On 08/27/2015 06:13 AM, Juliusz Chroboczek wrote: how DNS can be bootstrapped and parent domains delegated to a Homenet Border Router. I think we're speaking about different things. You're speaking about exporting the naming of the Homenet into the ISP (the single ISP, sigh) and from there into the global DNS, while we're speaking about having naming *within* the Homenet. No, it doesn't mean that. You don't need to be an ISP to run a DNS server. Even an authoritative one. There are a world of choices here. Mike ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP WGLC
Hi Douglas, it is a bit hard for me to decipher your mail or extract what is relevant wrt. to the HNCP I-D. Sorry for the delay. We were attempting to complete a security related draft on the topic. Are you preparing a generic draft on homenet security or is this specific to HNCP or DNS-SD? Do you have an ETA or can you share the relevant pieces for HNCP (can be in private to Markus, Pierre and me) upfront so we can address them in the next HNCP revision? We'd rather like to go ahead asap, that is probably release a new revision early next week, fixing all the things that came up during LC. Most of that is already staged in our git. A few issues may be a concern. The required support of UDP 4000 byte packets in Section 3 DNCP Profile suggests there may be a concern. Section 2.1.4. Amplification Issues of https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-00 describes considerations not covered in RFC6762, RFC6763 or RFC7368 when aggregate sizes of RRsets are overlooked, especially in such environments. I do not think amplification attacks wrt. HNCP are particularly relevant given you can mitigate them by using (DNCP) security. I also don't get the RRset thing? Are you referring to SD and Naming TLVs in HNCP or was this not intended to be relevant for HNCP? This section, as well as the Security Considerations section, does not ensure local resources are not externally exposed. Which section? RFC 6092 is supposed to be followed by edge routers as HNCP references 7084 and applies it to HNCP interfaces, however it might be a good idea to explicitly reference RFC 6092 in our own Security Considerations in 12.1. where we merely state A firewall perimeter is set up for the external interfaces without any further references. We might as well just do that. Cheers, Steven ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] HNCP WGLC
On 27.8.2015, at 9.26, Steven Barth cy...@openwrt.org wrote: A few issues may be a concern. The required support of UDP 4000 byte packets in Section 3 DNCP Profile suggests there may be a concern. Section 2.1.4. Amplification Issues of https://tools.ietf.org/html/draft-otis-dnssd-scalable-dns-sd-threats-00 describes considerations not covered in RFC6762, RFC6763 or RFC7368 when aggregate sizes of RRsets are overlooked, especially in such environments. I do not think amplification attacks wrt. HNCP are particularly relevant given you can mitigate them by using (DNCP) security. I also don't get the RRset thing? Are you referring to SD and Naming TLVs in HNCP or was this not intended to be relevant for HNCP? HNCP has nothing to do with RRsets, and HNCP only runs _within_ home. In-home amplification attacks sound far-fetched, especially as HNCP itself (given DTLS at least) is relatively hard to attack in such a way. If there are concerns about the definition of home and not-home being unclear, diffs are welcome. However, at worst case, given no firewalls and wrong interface category, ISP may attack the home router _from the next hop_ only, due to link-local addresses being only ones specified (also in the Section 3). I consider this somewhat unlikely to be a real threat. Cheers, -Markus ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
