On Fri, Jun 29, 2012 at 1:30 PM, Ray Hunter <[email protected]> wrote: > Michael Thomas wrote: >> >> On 06/29/2012 08:34 AM, Ralph Droms wrote: >>> >>> >>> a) Homenet name-service MUST NOT interfere with Internet name-service >>> "Internet name-service"? Do you mean "DNS"? "Co-exist" might be a >>> better word. Users want a single interface into naming and don't >>> want to have to differentiate between "naming stuff on my local network" >>> and "naming stuff in the Internet". Ted Lemon raised this issue much >>> more eloquently during the WG meeting. >>> >>> I'll add my first bullet here, rephrased a little: >>> >>> a.1) Relative name resolution: some naming convention that allows name >>> resolution while mitigating the need to know an absolute location in the >>> Internet name-service >>> >>>> b) Homenet name-service MUST NOT be in Internet name space. >>> >>> How are things in the home identified from outside the homenet? >>> >> >> Maybe I can add some fuel to Olafur's fire. I'd like to say that the >> homenet name service MUST be DNS. >> >> This may sound like heresy, but here's my reason: I want the ability >> to transition from a private name space to a public name space with >> minimal fuss. I don't want a different naming mechanism that has >> its own oddities just because I can't think up a clever domain name >> for my home net that goes into the global DNS when I'm forced to >> install my router. When I'm finally inspired, I want to be able to make >> that transition and then worry about the split horizon implications >> (if I even get around to caring about such a thing). >> >> So perhaps, we can make use of statistically unique naming to keep >> things from bumping into one another, etc... this is sort of off the cuff, >> but the real point is not having to transmogrify one naming scheme into >> another. Yuck. >> >> Mike >> > There are a number of parallels from Homenet to small and large enterprises > who declared UDI from the global DNS (and set up their own private root > servers) for any number of reasons. Similarly for WINS and mDNS users. > > So maybe a useful approach would be to ask "what's wrong with DNS today that > it can't satisfy all of the requirements mentioned" or "Why did these people > declare UDI in the first place?" or "Why did they invent that stuff?" and > more to the point "Can it be fixed?" > > Some of my answers to those questions would be: > > 1. Availability: Undesirability of fate sharing > > I don't want my media streamer and other devices like a smoke alarm becoming > locally unavailable because I change provider or the Internet link is down > for an extended period.
You shouldn't outsource your dns to your provider but be running a local cache and authorative server. As for the link being down for an extended period, that is something of a problem in the general case. I'd harden this requirement to your network should be able to boot and run independently of the internet being available or not. This is certainly the case with mdns, not so much with dns. > > 2. Easy roll out and maintenance > > I can't see Homenet being able to implement DNSSEC today, so we have to be > aware of cache poisoning in Homenet and how to address that if DNS is the > chosen solution. I'm puzzled. cerowrt and iscwrt have had dnssec for a year now... while bind is the most heavyweight daemon in the mix (about 10MB just to start, about 20MB with a full cache), it's certainly possible to run dnssec on your typical consumer router, and seems possible to add DNSSEC to something more lightweight like dnsmasq. At least a few applications implement dnssec too, there's a plugin for firefox that I know of. > > 3. One single namespace for all destinations.Coexistence with global DNS. > > Strong desire to integrate into the global DNS naming tree. Single name > space, single query type, no two way synchronization of separate name > spaces. I make no statement of preference on whether the transport has to be > native DNS within the home. This sort of conflicts with 8 below. > 4. Support of Highly Mobile out of the shrinkwrap > > Changing environments can be especially problematic for highly mobile nodes > with flexible tethering, such as iDevices. They should just work in and out > of the home, as you move within range of your Homenet wireless. Hard problem that crosses not just dns, but applications, the network stack and cryptography. The app that I love that implements this functionality fairly well is mosh, and even then it only works presently on ipv4 and that with public ip addresses. > 5. Integrity: Integrated Security > > We should be aware of security issues with a .local style namespace over > whatever transport (your iDevice connecting to my evil .local device posing > as a friendly fileserver because you're walking past my open home network). > So there would need to be some extra device pairing if a .local namespace is > used, or see (5). Drive by wifi exists independently of the .local convention. It's a network, not naming problem. > 6. Independent Local Trust Anchor > > Strong desire to avoid a heavyweight trust anchor tied into the public DNS. > That would be another important point for me if starting from scratch. > Perhaps the ability to insert a private trust anchor at some nominal point > on the DNS tree that I can use to authenticate between my own devices, other > than being limited to a trust anchor derived from the DNS root. I'm pretty > sure ISP's won't want to have people phoning their help desks asking about > key rotation problems or with how-to questions about key signing keys in > Homenet. Having a decent trust anchor to start with with any system would be good. One of my own issues is that the cert system is so broke that the most secure certs are the ones you generate yourself, but those throw an error in your browser by default. > 7. Integrated Low Power Version > > Ability for low power devices to sleep for extended periods built in from > the get go (naming gateway? naming proxy responder?) > > 8. Confidentiality: Name space hiding > > Ability to "hide" a portion of the name space to discourage scanning. > regards, > RayH > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-6 is out with fq_codel!" _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
