Thanks for the reply. See inline.
Dave Taht <mailto:[email protected]>
29 June 2012 22:52
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.
hmm. Ok in corporates. But SME & Homenet?
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.
Good point. Should be capable of working stand alone, or co-existent
with global DNS.
Perhaps I'm being naive, but I see no fundamental reason why the same
zone file can't be mounted at two points on the DNS tree. Once for a
.homenet. root (for local resolution independent of the global internet)
and once for a globally derived root (for resolution from outside of
Homenet). Resolvers would have two defaults in their search list, first
.homenet space and then one for global name space.
Isn't that better than trying to run/export/import/synch 2 completely
independent name resolution protocols?
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.
Perhaps try explaining to your mom what she needs to do for
best-practice zone management, and how to update key signing keys etc.
when changing providers ?
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.
Yes. These requirements are not always consistent. Perhaps that's why we
have so many name resolution protocols.
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.
True. But it's what consumers expect.
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.
Maybe we can agree that caching of a .local style namespace that is not
uniquely globally identifiable is problematic (for highly mobile nodes)
and needs to be addressed.
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.
I presume you're more than marginally acquainted with Active Directory.
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
Ray Hunter <mailto:[email protected]>
29 June 2012 22:30
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
