+1 on the need for a local trust anchor if users want authentication
Without a local trust anchor, how are we ever going to do authenticated
reverse resolution of the ULA space?
Without a local trust anchor, how would we guarantee stand-alone
operations (of DNSSEC)?
+1 on the need for a unique/identifiable name space
<uniqueString>.<well-known-string>. might work. e.g. .<ULA>.homenet.
then indeed you'd have to "enroll" with a homenet to be able to trust
it's namespace if you wanted authentication.
But at least the namespace would be pretty unique once you did so, even
for highly mobile devices.
Bootstrapping the namespace wouldn't seem to be a problem, as the ULA
prefix can be detected by all devices.
In the unlikely event of two homenets choosing the same ULA, and thus
having overlapping namespace as detected by a highly mobile device, I
guess there'd have to be some sort of tie-breaker e.g. the trust anchor
itself, or the user is warned and manually regenerates a new ULA for one
of her homenets. FYI RFC6821 uses ULA as a unique host identifier.
regards,
RayH
Brian E Carpenter wrote:
On 10/07/2012 17:18, Michael Thomas wrote:
...
Third, maybe we do not need more than one secure .local name server
in a network that has more than one router.
Seriously, I can see my neighbor's wifi, and I have access to his
(guest) net. This problem is already here.
.local is a problem in exactly the same way that RFC1918 is a problem.
For homenet, we should really do better (as ULAs do better than RFC1918).
If you want something that walks and talks like a locally defined,
locally significant TLD, then that's exactly what you'd better have.
So it needs to be .<uniqueString> not .<wellKnownString>
Brian
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
