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.
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.
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.
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.
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).
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.
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
