Subject: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt

From: Daniel Migault <[email-masked]>
Date: Wed, 2 Jul 2014 16:39:35 +0200

Hi,

Here is a new version of the DHCP Options for Homenet Naming Architecture
<http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/>.
DHCP Options are designed so the CPE can automatically outsource its
Authoritative DNS Service. [1]

We carefully considered the remarks of the DHCP WG in London for the design
of the options. We also considered the remarks we received in the Homenet
WG more especially:
    - We removed TSIG for securing transaction between the CPE and the DNS
servers. Intead we used SIG(0)
    -  We considered AXFR and Master/Slave mechanisms to outsource the Zone
from the CPE to the DNS Server.
    - We documented how outsourcing can be done on DNS owned/managed by the
ISP and by third party DNS providers.

The scope of the draft is designing DHCP Option to outsource a Zone from
the CPE to the some other DNS. As such we did not discussed:
    - whether the zone shoudl be signed or not.
    - how the DS record should be updated. This should be performed by the
DNS server hosting the zone, not (necessarily) the CPE.
    - the cases of internal / external zones

This points have not been omitted and will be discussed in
draft-mglt-homenet-front-end-naming-delegation.

Feel free to make comments!

Daniel

[1]
http://datatracker.ietf.org/doc/draft-mglt-homenet-naming-architecture-dhc-options/

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 02 Jul 2014 22:38:35 +0200

Since I saw a previous version of that in London, I've been wondering
about one thing, but didn't dare ask.  Please be indulgent if it is
a stupid question.

Why does the CPE need to intervene in what is an application layer
interaction between two consenting adults?  If I'm setting up a web server
on my home network, I'd expect that negotiating a DNS registration is
a private matter between the web server and the authoritative DNS master;
why would I want the CPE to act as intermediary?

Thanks,

-- Juliusz

---

From: Douglas Otis <[email-masked]>
Date: Wed, 2 Jul 2014 13:49:55 -0700

> why would I want the CPE to act as intermediary?

Dear Juliusz,

That is a very good question.

In essence, especially because ULA address use was ignored by the mDNS proxy scheme, anything reported by mDNS that is routable is to be published into DNS as a means to establish a routable unicast alternative to that of mDNS.  One major downside is this will end up including devices never intended to have direct access from the Internet, where things like an All-in-One printer or baby monitor may find themselves.  Use of a ULA addressing space offers a locally routable alternative without exposing these devices to the Internet.  Unfortunately, many in the homenet wg consider this to be a problem to be resolved by the device rather than the homenet protocol.

Regards,
Douglas Otis

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Jul 2014 08:28:56 +0200 (CEST)

On Wed, 2 Jul 2014, Douglas Otis wrote:

> In essence, especially because ULA address use was ignored by the mDNS 
> proxy scheme, anything reported by mDNS that is routable is to be 
> published into DNS as a means to establish a routable unicast 
> alternative to that of mDNS.  One major downside is this will end up 
> including devices never intended to have direct access from the 
> Internet, where things like an All-in-One printer or baby monitor may 
> find themselves.  Use of a ULA addressing space offers a locally 
> routable alternative without exposing these devices to the Internet. 
> Unfortunately, many in the homenet wg consider this to be a problem to 
> be resolved by the device rather than the homenet protocol.

Personally my thinking has been that the service discovery mechanisms and 
how wide the service discovery information is propagated (and wherefrom 
and who has access to the services themselves), would be up to policy in 
the homenet CPEs.

I have always envisioned a "control panel" for the home, where (new) 
devices pops up, and the user has to set up roles or equivalent for these 
devices, and the roles control how these devices and their services should 
be handled.

I would like to see a lot of this complexity done at the CPE (or a 
"homenet controller") and not in the individual device. The "controller" 
would own the policy settings that the user interacts with using for 
instance a smartphone app and/or a web page.

I have been meaning to write down use-cases and examples of my thoughts 
but I have not done this yet, but I should in the near future.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Thu, 3 Jul 2014 12:24:55 +0200

Hi,

Thanks for the question. If I understand it properly, the use case you
consider: 1) you set up a web server in your homenet, 2) you want it to be
accessed from the outside so you register your domain name and register the
IP address to the zone. Note that In this case, the Authoritative Naming
service is outsourced to a third party which is what we want to achieve to.

Your case is very specific. First your web server is a fixed node that is
expected to last at least a few years in your home network. This makes
manual configuration feasible. Then you only have one node you may install
a specific software that updates the IP address to the DNS authoritative
servers. This is to avoid multiple DNS configuration at every IP
renumbering.  At last you have an interface on your server you may not have
with other nodes. On the other hand, if you have multiple devices, you are
unlikely to handle / edit the zone manually or install the specific
software on each device -- given that some device will not support it.

For this reason we would like the CPE to handle this complexity. The
advantages I see using the CPE are:
    - Ease the naming of device of various nature.
    - CPE remains in the homenet and may be easier to be authenticated than
all different devices.
    - CPE presents a centralized point for end user interactions
    - CPE are "powerful enough" to handle complex policies...
    - CPE can integrate multiple protocols to publish a zone. Suppose mDNS
is used by a node, than registration of its IP address and name cannot be
perfomed on a public authoritative server cannot be performed using mDNS.
   - ....

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Jul 2014 14:14:04 +0200

Thanks for your answer, Daniel.

> If I understand it properly, the use case you consider: 1) you set up
> a web server in your homenet, 2) you want it to be accessed from the
> outside so you register your domain name and register the IP address to
> the zone. Note that In this case, the Authoritative Naming service is
> outsourced to a third party which is what we want to achieve to.

No, I think that I'm speaking of the same use case as your draft.  (I'm
not sure, since your draft takes the use case for granted -- I'm probably
missing some background here, sorry for not being more attentive previously.)

I've got a device that wants to be advertised in the global DNS (a web
server is the obvious example, but it doesn't matter).  Your draft
suggests (I think) that the device should speak to the CPE which will take
care of the interaction with the public DNS (arrow 6 in Figure 1 is
missing, by the way).  I'd like to understand why the device needs to go
through the middleman rather than speaking directly to the authoritative
DNS server.

My family was poor but honest, Daniel, and NATed addresses were all we
could afford.  Notwithstanding our difficult conditions, my parents took
a lot of care to bring me up to believe that end-to-end is always better
than proxying.  Since you're advocating proxying, I'd like to understand
why you think it is necessary.  What is more, I'd like to understand why
you require that the proxy be co-located with the CPE.  (It could
certainly be implemented on the CPE, but I don't understand why the
protocol requires that.)

You give some good reasons below, and I think they should be included in

>     - Ease the naming of device of various nature.

Please explain.

>     - CPE remains in the homenet and may be easier to be authenticated
> than all different devices.

Good point.

>     - CPE presents a centralized point for end user interactions

I'm not convinced about that, the authoritative DNS master seems like the
natural place for end-user interactions.  (Note that this does not prevent
the CPE's web interface from implementing some sort of proxy to the DNS
master's interface.)

>     - CPE are "powerful enough" to handle complex policies...

Everything is powerful enough nowadays.  My abacus has a four-core chip.

>     - CPE can integrate multiple protocols to publish a zone. Suppose mDNS is
> used by a node, than registration of its IP address and name cannot be

I strongly disagree.  I don't want mDNS->DNS proxying.  Registering in the
global DNS is something that should be under user control, while mDNS
is something that happens automatically (for better or worse).

-- Juliusz

---

From: Ray Bellis <[email-masked]>
Date: Thu, 3 Jul 2014 12:22:19 +0000

On 3 Jul 2014, at 13:14, Juliusz Chroboczek <[email-masked]> wrote:

> I'd like to understand why the device needs to go

[no hat]

Juliusz,

You may find some useful background in RFC 5625.

The essence of it is that in the absence of external connectivity (and therefore external DNS servers) the CPE is the ideal place to run DNS services for the LAN.  Unfortunately most vendors made a right mess of their implementations, although the situation is improving.

Ray

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Jul 2014 14:33:24 +0200 (CEST)

> through the middleman rather than speaking directly to the authoritative 

Isn't the thought that DNS-SD would be used, in that case the device 
wouldn't need to do anything else apart from announcing the service on the 
local subnet and the CPE would take care of making sure it would be 
discoverable globally?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 03 Jul 2014 14:39:26 +0200

>> I'd like to understand why the device needs to go through the middleman
>> rather than speaking directly to the authoritative DNS server.

> You may find some useful background in RFC 5625.

I'm increasingly confused.  RFC 5625 is about proxying DNS requests from
the LAN.  Daniel's draft is about proxying dynamic DNS updates, right?

-- Juliusz

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 3 Jul 2014 10:00:04 -0400

> the LAN.  Daniel's draft is about proxying dynamic DNS updates, right?

Yes.  My impression is that the idea in Daniel's draft is that the ISP
will take the load of most DNS queries, and will effectively mark a
boundary of split-horizon, so that some names resolve both outside and
inside the local network, and some will resolve only inside.  This is
really a formalization of the way many CPE systems already work, where
they update services like Dyn (full disclosure: my employer), no-ip,
and so on.  The differences seem to be (1) that the relationship is
somehow stapled to the ISP rather than to an outside service and (2)
that the commands all flow over Dynamic Update as opposed to any other
protocol.  Personally, I see the value in (2), but I'm worried about
(1).  Thinking as a vendor, I note that (2) basically means ditching a
lot of running code, although for a protocol I think is poorly
designed.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Jul 2014 10:20:50 -0400

> I've got a device that wants to be advertised in the global DNS (a web

Let's call this device "FredBaby" (with allusions to Breakfast at Tiffanys,
which I was reading on the weekend)

    > suggests (I think) that the device should speak to the CPE which will
    > take care of the interaction with the public DNS (arrow 6 in Figure 1 is

The reason why FredBaby device MAY speak to the CPE as the middleman is
because:
    1) in the homenet we can automate the discovery of CPE / FredBaby,
       and probably bootstrap a secure relationship between them.
    2) the CPE may be managing multiple zones in multiple different ways.
       For instance, dyndns update to the ISP, dyndns to the DNS provider,
       stealth primary for the zone, public primary for the zone.
    3) we may be able to bootstrap the secure relationship between the
       CPE device some of the forward zones with the ISP, and definitely
       will do that for the reverse zone with the ISP.  FredBaby will have
       no relationship with the ISP(s).
    4) the CPE will know about all the other devices that want their name
       managed, such as Rusty, Yunioshi, Sally.  In particular the CPE
       will also know about brother-FredBaby, the device which you are
       replacing, but haven't yet turned off.  You'll therefore be able
       to see all the various attempts to publish in one place and
       decide who gets priority, and which devices ("Sally" the Tomato),
       you weren't supposed to publish your relationship with.

    > a lot of care to bring me up to believe that end-to-end is always better

LUXURY! <Queue Monty Python sketch>

    > the CPE's web interface from implementing some sort of proxy to the DNS

I'm not sure I understand where the authoritative DNS master is.
I don't think that Daniel is demanding the CPE be the only possible answer,
and perhaps within HNCP we should be passing around the address of the
homenet authoritative DNS master, as if there are multiple CPE they might
need to argue about it too.

    > is something that happens automatically (for better or worse).

I think that this is the reason why we want it proxied; so that we have a
filter.   That's why FredBaby shouldn't talk to some out-of-home DNS master
directly.  I think that populating DNS from mDNS could well be turned off
by default, and enabled in a UI on a per name basis.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Douglas Otis <[email-masked]>
Date: Thu, 3 Jul 2014 14:43:59 -0700

> lot of running code, although for a protocol I think is poorly

Dear Andrew,

Since mDNS is unable to make determinations regarding the ability of a device to safely interact with the Internet, an overlay approach could be taken.  Although details are missing from the Hybrid Unicast/Multicast DNS-Based Service Discovery draft, use of ULAs can better establish a secure separation than can a split-horizon.  DNS was never intended to keep information private, especially within an environment having uncertain network boundaries with informal input schemes.  Use of ULAs can replicate the securities permitted by use of link-local by mDNS while also permitting continued operation when ISP up-links are disrupted. 

For some references see:
https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink

Regards,
Douglas Otis

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 4 Jul 2014 06:58:38 +0200 (CEST)

On Thu, 3 Jul 2014, Douglas Otis wrote:

> Since mDNS is unable to make determinations regarding the ability of a 
> device to safely interact with the Internet, an overlay approach could 
> be taken.  Although details are missing from the Hybrid 
> Unicast/Multicast DNS-Based Service Discovery draft, use of ULAs can 
> better establish a secure separation than can a split-horizon.  DNS was

I would very much prefer to see a solution where you can have policy to 
limit what is being published and to where, rather than the very binary 
"use ULAs for Internal resources". Apart from the fact that I do not like 
ULAs, I would also like to see more granularity and to enable the 
possibility to have zoning within the home network, for instance to have 
guest networks.

So we need to enable possibility to control propagation of service 
discovery information, we need packet filtering, and we also need some 
kind of "identity" for the devices so they can interact with all of this.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Jul 2014 23:15:28 +0200

Hi Juliusz,

If I understand correctly your point your point is not about the DHCP
Options, but about the architecture we defined for outsourcing the DNS
Homenet Zone. I have just submitted an update of the description of the
architecture in  draft-mglt-homenet-front-end-naming-delegation-04.txt [1].

The main idea is that the CPE builds the zone for the whole home network.
Then it outsources the zone on a server that handles the authoritative
naming service on the Internet. The reason for outsourcing is that CPE have
not been designed to host the authoritative service on the Internet and
thus may be exposed to resource exhaustion.

I am rephrasing your use case to make sure we have the same in mind. Please
clarify if we do not agree on the use case. You consider is a web server in
the home network, that you want to be reachable from the Internet. In order
to do that you buy a specific domain name www.homenet.com. The domain is
hosted on a Public Authoritative Server, you edit the zone, add the IP
address of your server. Then, you can do that manually every time your IP
changed or use a specific software that your registrar recommend you.

To me, the drawbacks of this architecture are:
    1) It is not scalable in term of configuration: if you have a single
server, you can edit the zone. If you have 100 devices (which is not much)
you will not be able to do it especially if you IP prefix changes every day.
    2) It is not scalable in term of software installation: every registrar
have its own API for configuring the zone. If you want to be able to do so,
devices need to ba familiar with all APIs. Furthermore, if you suppose all
registrar agree to have a unique way to do so, -- suppose nsupdate -- all
devices will have to implement this protocol. For most devices this may be
not a problem, however, for all devices like sensors having to perform
nsupdate every day, may impact their battery life time for nothing.
    3) It is not automatic and flexible: A new device that is in your
network cannot have a name, as an admin needs to register its name in the
zone myhomenet.com, or provide the credential for it to all new devices.
    4) It is not scalable in term of zone management and bandwidth: Suppose
you have n devices in the home network and a renumbering occurs. All these
n devices will contact the Public Authoritative Server that may be miles
away from your home network. The Authoritative Server will have to deal
with n nsupdate transaction instead of one.
    5) it exposes your homenet to IP disruption. Suppose your ISP has a
connectivity issue, even a node in your home network will not be able to
contact your web server as the DNS(SEC) resolution is not possible.

In contrast, the architecture we describe in [1] :
    1) is scalable in term of configuration: The only device that you may
need to configure is your CPE. In the worst case it is done once for all.
    2) is scalable in term of software installation: Only the CPE needs to
be compliant with the registrar API, other devices do  not need any kind of
credentials, or other APIs.
    3) It is automatic and flexible: as a new node is attached, it
advertise its name in a DHCP query and the CPE takes in charge the binding.
    4) it is scalable in term of zone management and bandwidth:
registration is performed by the CPE, that is one of the first hops. Then
the CPE updates once the zone to the Public Authoritative Server. This can
be done with nsupdate, but we recommend master / slave synchronization.
    5) It preserves the home network from IP disruption. If you d not have
any connectivity on the Internet, as the authoritative naming service is
provided by the CPE for the home network, nodes within the home network can
still communicate.

BR,

Daniel

[1]
http://www.ietf.org/internet-drafts/draft-mglt-homenet-front-end-naming-delegation-04.txt

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 05 Jul 2014 00:12:42 +0200

> The main idea is that the CPE builds the zone for the whole home network.

Thanks for the clarification.

Daniel, perhaps I'm still misunderstanding something -- but I'm afraid that
right now I'm strongly opposed to this protocol.  I hold no opinion yet on
whether proxying is necessary (although I hope it isn't), but I am strongly
opposed to binding the DNS proxy role with the CPE at the protocol level.
(This does not mean that the DNS proxy cannot be colocated with the CPE,
only that I find a protocol that mandates this kind of colocation unacceptable.)

> the home network, that you want to be reachable from the Internet. In order to
> do that you buy a specific domain name www.homenet.com. The domain is hosted
> on a Public Authoritative Server, you edit the zone, add the IP address of
> your server.

Oh, nothing that geeky.  I copy my vacation photographs onto my NAS.
I click the "share over the Internet" button on the NAS's web interface.
The NAS performs DynDNS registration, I get a link that I can copy-paste
into an e-mail to my mom: "Mom, the vacation photographs are on
http://www.user-fe83-paris-13.dyndns.example.com:8080/photos, the password
is 1234."  I've avoided putting my private photographs on Google's
servers -- and we're changing the world.

I click on the "share over the internet" button on my stereo's web
interface.  The stereo performs DynDNS registration, I get a link that
I can copy-paste.  "Daniel, the song you found so funny at my place last
night night is on http://www.user-fe83-paris-13.dyndns.example.com/funny-music,
the password is 1234".  I've avoided sending 20MB of Ukrainian R'n'B over
SMTP -- and we're changing the world.

I'm at the train station.  There's a strike on.  I'm playing Civilisation
on my laptop in an internet cafe.  I click the "Invite over the Internet"
button.  Civilisation performs DynDNS registration, I get a link which
I can copy-paste.  "Daniel, I'm bored, join me for a game of Civilisation,
link is civ://www.user-fe83-paris-13.dyndns.example.com, password is
1234", and now I can wholeheartedly support the cheminot's strike -- we're
changing the world again.

> server, you can edit the zone. If you have 100 devices (which is not much) you
> will not be able to do it especially if you IP prefix changes every day.

Sure.  Just like you, I'm expecting dynamic updates.  But I don't expect
dynamic updates to be dependent on my CPE, which is buggy (it was provided
by the major competitor of your employer) and isn't available at the
internet cafe.

> have its own API for configuring the zone.

Then why not standardise a registration API?

> Furthermore, if you suppose all registrar agree to have a unique way to
> do so, -- suppose nsupdate -- all devices will have to implement this
> protocol. For most devices this may be not a problem, however, for all
> devices like sensors having to perform nsupdate every day, may impact
> their battery life time for nothing.

If you really believe that proxying is necessary (and I'd like actual
figures to support this claim -- how many devices do you have in your home
that cannot afford the cost of one registration every few hours?), then
there's nothing preventing a DNS proxy from using the standardised
registration protocol on behalf of its clients.  Then clients can choose
whether to go through the proxy, and users can choose whether use the
ISP-provided proxy (co-located with the CPE) or a third-party proxy that
happens to work.

>     3) It is not automatic and flexible: A new device that is in your network
> cannot have a name, as an admin needs to register its name in the zone 
> myhomenet.com, or provide the credential for it to all new devices.

That's what we have HNCP for -- for distributing random data to all devices.

> you have n devices in the home network and a renumbering occurs. All these n
> devices will contact the Public Authoritative Server that may be miles away
> from your home network.

I've got 100 devices.  I renumber.  Each device sends 500 bytes of
registration data.  My monthly Internet bill has just increased by 50 kB.

> contact your web server as the DNS(SEC) resolution is not possible. 

But my nodes are still running mDNS/zeroconf, right?  Or are you deprecating
that?

-- Juliusz

---

From: Daniel Migault <[email-masked]>
Date: Mon, 7 Jul 2014 14:46:25 +0200

Hi

Please see my comments inline.

>
>
> On Sat, Jul 5, 2014 at 12:12 AM, Juliusz Chroboczek <
I do not think our architecture is bound to the CPE. In the architecture
document we mention that the CPE is the most likely to host the DNS zone
for the home network. However, I agree it can be any other node. We do not
either mandate any collocation of functions. If you could point specific
sections, that would help to clarify the next versions.

Similarly, I do not recall using the term proxy in one or the other draft,
and I do not see what could be considered as a proxy. More specifically,
suppose you have a authoritative DNS server in your homenet work. In the
draft we said a CPE will most likely handle this function. This server MAY
NOT want to respond for queries that are coming from outside the home
network. In this case, This server outsources the authoritative server for
queries coming from the Internet to a third party. DNS queries for the
Domain name of the home network will be answered by the "CPE" when the
query comes form the home network and by the "third party" when the query
comes from outside the home network.

>> night night is on
>> http://www.user-fe83-paris-13.dyndns.example.com/funny-music,
To me the last use case you provide is not in the scope of home network
unless you are unsing a VPN. The two first examples seems to be related to
WEBDAV. On a DNS point of view, it looks to me that they involve only a DNS
registration. Suppose there is not NAT. Your NAS requests /discovers its IP
address and then registers its IP address to the registrar. This means that
at one time you have configured your NAS with the appropriated credentials
to update your zone in the registrar. In the architecture we propose,
things may be as follows: the NAS only needs a hostname: myserver for
example. You plug the NAS in your home network, it announces its name via
DHCP. The DHCP transmit the information to the entity that manages the DNS
zone, which then outsource the zone to the registrar. You NAS does not need
to be configured to update the zone at the registrar.

>> by the major competitor of your employer) and isn't available at the
To me the Internet cafe is not the home network. The issue of buggy CPE is
an important one. The goal of the two drafts is to provide guidance to
avoid such issues... and providing no guidances or leaving things as there
are now won't solve these issues ;-)

>> Then why not standardise a registration API?
I am not sure there is a real interest in doing so, nor that it is
feasible. The important thing is that you have the APIs of your registrar
and that you do not have to set it in all devices. Some devices like sensor
will never be able to embed these APIs anyway.

>> ISP-provided proxy (co-located with the CPE) or a third-party proxy that
It is not clear what you have in mind with proxy, so I might misunderstand
your point here. It seems to me that you do not want the architecture to
prevent a host to register on its own. YES this is the case. Suppose your
Registered Domain Name for your home network is myhome.net. With our
architecture, as mentioned above, your NAS may be automatically registered
as myserver.myhome.net. If you want your server to be registered as
myserver.org, nothing prevents you from doing so. You may have two names
for the server, or a single one. In other words the proposed architecture
is compliant with existing deployment.

>> network
I am sure I misunderstood your point, but I understand you suggest using
HNCP to distribute credentials (private keys, login password). Am I
correct?

>> registration data.  My monthly Internet bill has just increased by 50 kB.
That is still more than 0  ;-)

>> But my nodes are still running mDNS/zeroconf, right?  Or are you
Interchanging mDNS and DNS for local / global scope is not an easy thing.
These protocols are different protocols and I do not think it is a good
idea to impose all devices to have both, then homenet may have different
subnetworks, mDNS can use UTF-8...  There are a lot of ongoing work in
dnssd.

By the way, I am not deprecating the use of mDNS at all it is simply
orthogonal.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 09 Jul 2014 03:39:59 +0200

Thanks for your patience, Daniel.  I feel I'm understanding a little more
now.  My main misunderstanding was the following:

 - you're not populating DNS with mDNS data, you're populating it with the
   DHCP hostname data; I now understand that mDNS is mostly orthogonal.

What I still don't understand is how your protocol can work when the
hidden master is not the CPE.

> In the architecture document we mention that the CPE is the most likely
> to host the DNS zone for the home network.

I'd really like to encourage you to revise the drafts so that it makes it
clear that the hidden master is not necessarily the CPE.  I'd be
particularly keen to understand how the hidden master can sign the zone
when it is not the CPE, given that you expect signing keys to be obtained
over DHCP.

> I do not think our architecture is bound to the CPE [...] If you could
> point specific sections, that would help to clarify the next versions.

    This document describes a homenet naming architecture where the CPEs
    manage the DNS zone associates to its home network,

    [...]

    the DNS(SEC) Homenet Zone built by the CPE is outsourced to Public
    Authoritative Servers.

    [...]

    The zone signing and secure delegation can be performed either by the
    CPE or by the Public Authoritative Servers.

    [...]

    outsourcing the authoritative naming service from the CPE

...and so forth, and so on.  I'm sure you can see where my confusion stems
from ;-)

> Similarly, I do not recall using the term proxy in one or the other
> draft, and I do not see what could be considered as a proxy.

I fear I wasn't very clear:

1. the homenet nodes populate the master zone at the hidden master (which
   is not at all the CPE, as we've established above) using DHCP;

2. the hidden master (which is not at all the CPE) performs a zone
   transfer to its secondaries (which are not at all the ones hardwired by
   the ISP into the CPE) using normal DNS(SEC) procedures.

So in effect the hostname data is flowing (1) from the node to the hidden
master which (2) forwards it to the authoritative secondaries.  In effect,
it's being proxied from the node to the secondaries by the hidden master.

> In the architecture we propose, things may be as follows: the NAS only
> needs a hostname: myserver for example. You plug the NAS in your home
> network, it announces its name via DHCP. The DHCP transmit the
> information to the entity that manages the DNS zone, which then
> outsource the zone to the registrar. You NAS does not need to be
> configured to update the zone at the registrar.

Ah.  I think that's the crucial point -- it's easier to provide
credentials to a single node rather than to every node that needs to
register in the global DNS.  That makes sense.

So how does the hidden master get the credentials?  You say:

    The DHCP Server makes the Public Key available to the DNS servers, so
    the CPE can secure its DNS transactions.  Note that the Public Key
    alone is not sufficient to perform the authentication [...] How the
    binding is performed is out of scope of the document.  It can be
    a centralized database or various bindings may be sent to the
    different servers.

That speaks about the ISP's DHCP server, right?  But now that we've
established that the hidden master is not the CPE -- it's not necessarily
on the same link as the DHCP server.  Are you assuming a DHCP proxy at the
CPE?

I also don't understand what you mean by "various bindings" in the last
sentence quoted above.  I'd appreciate a clarification.  Perhaps you can
tell us how the private keys are distributed in your implementation?

>>> Suppose your ISP has a connectivity issue, even a node in your home
>>> network will not be able to contact your web server as the DNS(SEC)
>>> resolution is not possible.

>> But my nodes are still running mDNS/zeroconf, right?

> By the way, I am not deprecating the use of mDNS at all it is simply

What I meant by that is that you're still running mDNS, so losing
connectivity to the master won't prevent you from resolving using mDNS.
However, I now see that you're not deriving the DNS zone from mDNS, so the
name you're interested in might very well not be advertised over mDNS.

Thanks for your patience,

-- Juliusz

---

From: Daniel Migault <[email-masked]>
Date: Wed, 9 Jul 2014 15:53:16 +0200

Hi

Thank you for your response and feed backs. See my response in the text
body as well as in your text. I think we are making progress.

[draft-mglt-homenet-front-end-naming-delegation] and
[draft-mglt-homenet-naming-architecture-dhc-options] are distinct
documents. The one describes the architecture to outsource the homenet
authoritative naming service on the Internet. In that sense it should not
be CPE specific. The second draft describes how DHCP Option could help to
set this architecture. It does not mean they must always be used.

A brief response to how these document are CPE specific:

    - The architecture document
[draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific. See
below for more details.
    - The DHCP Options document
[draft-mglt-homenet-naming-architecture-dhc-options] is currently CPE
specific. It can be made non CPE specific in two ways: 1) Keeping the
document CPE specific and adding a section that describes how the option
can be used when functions are not collocated. or 2) making the whole
document non CPE specific. Reasons I would prefer 1) are: it makes things
easier to read and understand, generalization is easy and I believe these
options will mostly be used by CPE. That said both options are fine to me.
See more details below.

A more detailed response:

    In [draft-mglt-homenet-front-end-naming-delegation] we use the term
CPE, as this is the device we are focused on, and we also believe that in
most homenet this device will play this role. However, there are no such
restriction. In this document, The CPE is the device that owns the Homenet
Zone and that could publish the zone on the Internet. Instead, of
publishing itself, it outsources the Zone to the Public Server. In order to
clarify this misunderstanding, we can:
        - a) Explicitly mention that the CPE is an example, and any device
can be
        - b) Introduce a new designation like the Internet Homenet
Authoritative Server.

Maybe b) is better. I would appreciate to have feed backs. Other
designations are also welcome!

In [draft-mglt-homenet-naming-architecture-dhc-options] we took advantage
of the collocation DHCP client that exchange with the DHCP Server of the
ISP, signing of the Zone and the Reverse Zone by the same device. If we
want to split the different functions we may have to consider:
    - the CPE,
    - the Internet Homenet Authoritative Server
    - the Internet Reverse Homenet Authoritative Server

To me only the Internet Reverse Homenet Authoritative Server needs to
dialogue with the ISP, as the ISP manage the delegation of the Reverse
Zone. If the Internet Reverse Homenet Authoritative Server is not colocated
with the CPE, the DHCP Server of the home network will have to relay these
options to the DHCP Server of the ISP.

The Internet Homenet Authoritative Server can use the DHCP Options with any
other DHCP Server that is configured to respond to these options.

In the current draft, we used only one key the one the CPE uses to sign
both the Homenet Zone and the Reverse Zone. If this may not be performed by
the CPE, we need to have two keys: one for the Homenet Zone and one for the
Reverse Zone. So that's something we missed, thanks for pointing it out.

To me a network that have different entity for the CPE, the Internet
Homenet Authoritative Server  and the Internet Reverse Homenet
Authoritative Server in different devices and a DHCP Relay may not be a
home network anymore. I suggest the draft 1) remain restricted to the CPE
and 2) add a section to describe how things could work if the functions are
split into different devices. I also agree we need to have different
options for the Key of the Reverse Homenet Zone and Homenet Zone. The
reason to do so, is that

Any opinions on that?

I also added small comments inline.

BR,
Daniel
On Wed, Jul 9, 2014 at 3:39 AM, Juliusz Chroboczek <

>    is not at all the CPE, as we've established above) using DHCP;
This DHCP is the one of the home network and not the one of the ISP.

> OK, If I understand correctly you called that proxy as nodes do not
register directly  to the Public Authoritative Server. Instead, this is
performed by the Internet Homenet Authoritative Server.

Note also that nothing prevents the node to perform its registration to the
Public Authoritative Server directly. This architecture do nothing against
this. This is simply not part of the architecture.

> on the same link as the DHCP server.  Are you assuming a DHCP proxy at the

As mentioned above the DHCP Options have currently been established for CPE.

> A public key alone is not sufficient for authentication. You need an ID.
This ID can be the domain name, the end user ID , the line number..... This
is not specified in the document. As name servers needs the name and the
key, the binding I would use would be the name and the key.

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 09 Jul 2014 17:01:38 +0200

> [draft-mglt-homenet-front-end-naming-delegation] in NOT CPE specific.

> specific.

Ah, I see.  That definitely needs to be clarified.

> - a) Explicitly mention that the CPE is an example [...]
> - b) Introduce a new designation like the Internet Homenet Authoritative
>   Server.

[...]

> Maybe b) is better.

Definitely so.  Replacing CPE with IHAS in the text will allow you to see
more clearly where you've assumed that the CPE and IHAS are co-located.

There's still something I don't understand.  If I'm understanding Steve's
and Markus' work correctly, HNCP performs prefix delegation to internal
routers over HNCP, and the internal routers don't proxy stateful DHCPv6 to
the CPE.  How does your protocol work in the presence of multiple links?
Or are you assuming that only nodes directly connected to the IHAS/CPE can
be advertised over your protocol?

Finally, what happens when there are multiple CPEs, which HNCP explicitly
supports?  Are you assuming that only one acts as IHAS?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Jul 2014 09:47:35 +0300

> be advertised over your protocol?

Or even more weirdly, what if you don’t want stateful DHCPv6? SLAAC + temporary addresses?

> supports?  Are you assuming that only one acts as IHAS?

.. and how do the zones map to multiple uplinks ..

Personally, I don’t believe in auto-exported ~full DNS information from home because current service discovery schemes (mdns, dns-sd, upnp) or even host-name discovery schemes (dhcp*) do not really lend themselves to the external visibility being _opt in_. I don’t really want to publish my home zone, and if I even did, anything that’s firewalled (= everything except few ports on few addresses) is not useful outside the home in any case.

Getting security right on ‘all devices’ so you can leave your firewall open by default is a nice dream, but I think I stopped dreaming sometime in the 90s on that front :p Default deny + clued allow is much, much better than the default allow + ISP doing filtering for you after your home is owned.

Cheers,

-Markus

P.S. I am amused by recent WeMo/that other IoT light security woes. I’m sure publishing _their_ names on my home zone would help me, somehow, to get remote controlled home disco if nothing else.. at least, if they weren’t on a separate, L3-firewalled link that has no outside connectivity outside my home.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Jul 2014 07:29:24 -0700

> Personally, I don’t believe in auto-exported ~full DNS information from home because current service discovery schemes (mdns, dns-sd, upnp) or even host-name discovery schemes (dhcp*) do not really…

Yet, I really, really, triple-super really want to be able to access my 
home network devices when i'm not
at home. Any part of the naming architecture better take that as a very 
basic requirement.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Jul 2014 11:41:15 -0400

Markus Stenberg <[email-masked]> wrote:
    > Personally, I don’t believe in auto-exported ~full DNS information from
    > home because current service discovery schemes (mdns, dns-sd, upnp) or
    > even host-name discovery schemes (dhcp*) do not really lend themselves
    > to the external visibility being _opt in_. I don’t really want to
    > publish my home zone, and if I even did, anything that’s firewalled (=
    > everything except few ports on few addresses) is not useful outside the
    > home in any case.

Many people *do* want seemless access, and as their devices roam outside the
home, they expect, that having entered the name of the device, they expect
that whatever security they have (such as a VPN) will then get kicked off
automatically.  That requires that names->IPv6 mapping be available so that
the VPN can know it is supposed to do something.

I have way too much experience with IPsec VPNs where I have to turn the VPN
on, flush my DNS cache, restart my browser, and then finally, I can access
some internal name, all because some CIO thought that it would be insecure if
the world knew about intranet.example.com.

That's not the same as having an open network, so please stop saying that
names are useless because there is no connectivity.

I think that whether you "auto-export", or whitelist, or blacklist, etc. is
completely a local matter.  We may recommend a default, but we should make
sure that the mechanisms exist.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 15 Jul 2014 17:57:04 +0200

> home,

I think there are two issues here which are mostly orthogonal:

 (1) Do we want a standardised protocol for exporting data into the global DNS?
 (2) What is the right policy from exporting homenet names into the global DNS?

I'm pretty sure that (1) can be answered without giving a full answer to (2).

-- Juliusz

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Jul 2014 18:00:38 +0200

Hi,

> sure that the mechanisms exist.

+1 for "have a policy that specifies whether names should be auto-exported
or not", and I actually want all my machines be visible, and most of them
be *reachable*, since they can protect themselves.  They have to.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 13:00:04 -0400

> (2) What is the right policy from exporting homenet names into the global DNS?

We already have two standardized protocols for exporting data into the global DNS: Dynamic DNS updates and DNS zone transfers.   What's needed is just the connective tissue to set it up.

There is no one right policy for exporting.   I assume you mean that we need to recommend a default policy and also document the range of other policies that the end user might choose to use.   It would also be nice if the PCP server could somehow feed into this: if you open a PCP port, then you get a DNS registration; if you don't, you don't.  Something like that.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 15 Jul 2014 20:35:09 +0200

> I assume you mean that we need to recommend a default policy and also
> document the range of other policies that the end user might choose to
> use.

No, I just mean that Markus not wanting anything published in DNS is
policy, and that's completely independent of whether we want to define
a mechanism.  I have no opinion on either point.

All I know is that if we want to define a mechanism, then the mechanism
should be compatible with the worldview of HNCP, which includes things
such as multiple internal links and multiple CPEs.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Jul 2014 21:45:24 +0300

> such as multiple internal links and multiple CPEs.

The mechanism should not be tied to the particular ISPs either, except perhaps optionally.

In my case, I have 2 upstream ISPs, neither of which officially even admits IPv6 exists, but I _would_ like to publish my home v6 zone somewhere.. *sigh*

So to summarize:

- mechanism to publish either single DNS updates or zones would be nice to have (possibly with tie-in to service discovery)

- with policy bits thrown in 

and some sort of possible zero-conf use, with help of co-operating ISP perhaps, but _not_ requiring the first-hop ISP to be the only party you interact with.

The ‘homenet’ policy stuff may be actually relatively extensive in the end, although with some sort of reasonable zeroconf defaults.
In this case, policy stuff should apply to what’s advertised (and in which scope), and where it can be reached from (firewalling either with accept rules, or PCP-derived holes).

(Hmm. We don’t seem to have any drafts on policy or management yet.)

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 15 Jul 2014 20:59:19 +0200

> The mechanism should not be tied to the particular ISPs either, except

Uh-huh.

Oh, and lest I forget: HNCP does not require stateful DHCPv6 for end
nodes.  It would be cool if the dynamic DNS mechanism didn't require it
either.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 15:00:42 -0400

> The mechanism should not be tied to the particular ISPs either, except perhaps optionally.

I think the motivation with Daniel's draft was to provide support for the optional case where the ISP wants to support it, because you get some better results in that case, but clearly the full solution needs to work "well enough" with partial or nonexistent ISP cooperation.

Have you looked at https://datatracker.ietf.org/doc/draft-lemon-dhc-dns-pd/ ?   I don't have time to work on this anymore, but the goal was to allow the ISP and the end-user to negotiate how they want to set up the DNS for a delegated prefix, and I'd like to see it move forward if there is interest.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Jul 2014 12:38:56 -0700

> I think the motivation with Daniel's draft was to provide support for the optional case where the ISP wants to support it, because you get some better results in that case, but clearly the full sol…

That pretty much means that you need a solution that isn't bolted to 
DHCP, right?
Or at least, that DHCP is only providing a default discovery mechanism 
which my CPE
is completely free to ignore. Beyond the discovery, it ought to work 
identically regardless
of whether it's my first hop ISP(s), or 20 hops away in Nairobi, right?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 15:43:45 -0400

On Jul 15, 2014, at 3:38 PM, Michael Thomas <[email-masked]> wrote:
> That pretty much means that you need a solution that isn't bolted to DHCP, right?
> Or at least, that DHCP is only providing a default discovery mechanism which my CPE
> is completely free to ignore. Beyond the discovery, it ought to work identically regardless

The point is that what the ISP is offering may be ideal for some users, and not others.   And some ISPs may offer it, while others don't.   So if there's a standard mechanism in place for using it when it's offered, if desired, then that's a win, even if not everyone wins.

What happens with queries isn't important as long as they are satisfied; there are lots of ways of satisfying queries for AAAA records, but only two ways of satisfying queries for PTR records, and the ISP may support one or both of those two ways, or neither.   The point of the DNS-PD document is to provide a way for the ISP and CPE to communicate about which mechanisms are supported and desired.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Jul 2014 12:55:05 -0700

> What happens with queries isn't important as long as they are satisfied; there are lots of ways of satisfying queries for AAAA records, but only two ways of satisfying queries for PTR records, and…

What I'm trying to say is that DHCP as a way of advertising a service 
that will host my zone, or
in some way make my homenet names globally available is OK, but it 
should just be about
DISCOVERY and nothing else. All of the rest of the mechanisms between my 
CPE and some service
that causes my names to be globally available ought to use standard 
mechanisms which are not
in any way tied to topology.

It's OK if discovery for non-ISP's remains an unsolved problem, let's 
just have one mechanism once
I know who I want to speak to.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 16:09:55 -0400

On Jul 15, 2014, at 3:55 PM, Michael Thomas <[email-masked]> wrote:
> What I'm trying to say is that DHCP as a way of advertising a service that will host my zone, or
> in some way make my homenet names globally available is OK, but it should just be about
> DISCOVERY and nothing else. All of the rest of the mechanisms between my CPE and some service
> that causes my names to be globally available ought to use standard mechanisms which are not

Ah, yes.   Agreed, at least in theory.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Jul 2014 13:27:51 -0700

> Ah, yes.   Agreed, at least in theory.

Good. If that can be done at all, is there a reason that it cannot have 
those properties?
That is if, say, my Google Nest spams my local homenet advertising the 
Google Eggs-in-one-basket
DNS service, it should use the same set of protocols as a local ISP 
advertising over DHCP to
actually hook everything up between my CPE and their service.

Can we make this a *requirement*? If not, why not?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 16:53:39 -0400

On Jul 15, 2014, at 4:27 PM, Michael Thomas <[email-masked]> wrote:
> Good. If that can be done at all, is there a reason that it cannot have those properties?
> That is if, say, my Google Nest spams my local homenet advertising the Google Eggs-in-one-basket
> DNS service, it should use the same set of protocols as a local ISP advertising over DHCP to

We can safely assume that any device that is monetized through the cloud will do everything in its power to prevent us from accessing it, so that's really not the interesting test case.   The interesting test case is whether a Nest-like device that isn't operated through the manufacturer's captive portal will use this set of standard protocols.   (I don't know what the policies behind Nest are specifically, but the phenomenon I'm talking about is more the rule than the exception in citizen-grade IoT devices at the moment).

> Can we make this a *requirement*? If not, why not?

We can't force anybody to do anything, that's why not.   But we can document a mechanism for doing it, and if implementation becomes widespread in home gateways, it's not unreasonable to think that devices that _don't_ depend on a captive portal for monetization will use these protocols rather than reinventing the wheel.   But bear in mind that this is a fairly big "if."

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Jul 2014 14:12:06 -0700

> We can safely assume that any device that is monetized through the cloud will do everything in its power to prevent us from accessing it, so that's really not the interesting test case.   The inter…

I believe we are at least in the fortunate situation that nobody's tried 
hard to do a naming
provider land grab yet, so there may yet be time to do the right thing.

> We can't force anybody to do anything, that's why not.   But we can document a mechanism for doing it, and if implementation becomes widespread in home gateways, it's not unreasonable to think that…
I mean a requirement for the homenet working group, of course. I'm not 
entirely sure what
the appetite is for wheel reinvention in this space is, but I'm guessing 
it's not that high if
this working group comes up with something that is workable, and gives 
CPE vendors something
to shoot for rather than a bunch of ad hoc point solutions requiring 
bilateral dev agreements.

We should be really clear that "CPE" !== "Router" too. If the Nest wants 
to be my DNS name
repository that gets mirrored out in Google's intrastructure somehow, 
that should OK too.
I think its main requirement is that it:

a) doesn't move around out of my homenet
b) is always on

Mike

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Tue, 15 Jul 2014 21:32:29 +0000

> (Hmm. We don’t seem to have any drafts on policy or management yet.)

There is some dependency on security for these.

Mark
> 
> Cheers,
> 
> -Markus
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 19:42:13 -0400

On Jul 15, 2014, at 5:12 PM, Michael Thomas <[email-masked]> wrote:
> I believe we are at least in the fortunate situation that nobody's tried hard to do a naming

That's not the point.   If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device without sending them your data, so chances are the device is going to just talk to their portal using a proprietary scheme and ignore what we want.   Which is fine; my point is not that they are evil, but just that the use case for this may not be quite as broad as we imagine.   I still think it's worth doing, and I hope that over time this stuff moves in the direction of more flexibility.   What we do in homenet can easily either make that easy or make it hard, so we should try to make it easy.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 15 Jul 2014 17:46:35 -0700

> That's not the point.   If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device withou…

Oh, ok. But this entire area is going to be pretty darn tricksey to get 
right, and we can have some hope
that after enough proprietary we-need-to-get-something-done from 
vendors, they'll be somewhat relieved
to have exactly One something that's standardized to support. I've seen 
this many times at $routervendor,
even when they have their own business model in mind. So we shouldn't be 
too fatalistic... the game is still
young on this account.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Jul 2014 21:55:57 -0400

On Jul 15, 2014, at 8:46 PM, Michael Thomas <[email-masked]> wrote:
> So we shouldn't be too fatalistic... the game is still
> young on this account.

I applaud and encourage your optimism.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Jul 2014 19:06:43 -0700

On Jul 15, 2014, at 5:46 PM, Michael Thomas <[email-masked]> wrote:

> Oh, ok. But this entire area is going to be pretty darn tricksey to get right, and we can have some hope
> that after enough proprietary we-need-to-get-something-done from vendors, they'll be somewhat relieved
> to have exactly One something that's standardized to support. I've seen this many times at $routervendor,
> even when they have their own business model in mind. So we shouldn't be too fatalistic... the game is still
> young on this account.

Dear Mike, 

http://tools.ietf.org/html/rfc6281 offers a fair amount of detail about safely leveraging home networks.  Further examination of this scheme shows selective publications of devices in DNS and expects other services to be indirectly shared by these devices.  It makes extensive use of ULAs that offer a stable basis for publishing addresses in DNS.

http://tools.ietf.org/html/rfc6890 and homenet arch also references use of ULAs.  http://tools.ietf.org/html/draft-ietf-homenet-arch-17#section-3.6.6

3.6.6.  ULAs as a hint of connection origin

The basic security related premise employed by mDNS can be confirmed by use of ULAs.  It is also conceivable anti-distribution protection schemes can be satisfied when ULAs have a common prefix.  There are also many home routers already able to combine GUA and ULAs.  Add L2TP and it seems we are done.

Regards,
Douglas Otis