Subject: [homenet] Home DNS server for homenet

From: [email-masked]
Date: Fri, 02 Mar 2012 20:21:25 +0900 (JST)

Hello,

I have an idea of home DNS server written in section 3.4.9 of
homenet-arch-01.

Home gateways (CPE) have a DNS proxy function,
and all nodes in the network usually send DNS queries via the DNS proxy.

My idea is to add authoritative DNS server function of local zone to
home gateways.

A home gateway serves one forward local zone and local reverse zones
which the home gateway manage/offer by RA or DHCP.

The authoritative DNS server function accepts DNS dynamic updates
whose owner name is within the forward local zone and whose IP adress
is within the IP addresses which the home gateway manages.

When An end node starts, It gets IP/IPv6 address and DNS server
information, DNS domain name prefix information from the home gateway.
(option domain-name-servers and option domain-name in ISC dhcpd)
option domain-name can be used to provide the local forward zone name.

If the end node wants to register its name into home DNS server,
it sends DNS dynamic update to the DNS servers which it got by DHCP.

Clients can access the registered hostname using normal DNS lookup via
the DNS proxy.

There are many points to be cleared. But the idea may work well and
it does not require new protocol and rewriting clients.

It requires new home gateway (DNS proxy) and new dynamic update
program used by home servers.

If there are multiple subnets and multiple home gateways,
DNS protocol has enough functions
(relaying dynamic updates, zone transfers,...).

I think the idea works for both IPv4 with NAT and IPv6.

Does the idea work for homenet WG?
Or already discussed ?

If the idea is valuable, I will write a draft and sample DNS server.

Regards,

--
Kazunori Fujiwara, JPRS <[email-masked]>

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Mar 2012 09:25:30 +0000

> If the idea is valuable, I will write a draft and sample DNS server.

Fujiwara-san

Thanks for your note.  The idea of running a local authoritative zone alongside a forwarding proxy or full recursive server has been seen already, for example in the "dnsmasq" software used by many CPE vendors.

It is also listed as requirement LAN.DNS.6 in the Broadband Forum's TR-124 Issue 2.  As such a draft describing this is probably unnecessary.

Your DNS expertise would of course be much appreciated as we start to tackle the wider issues around naming in the Homenet, specifically:

1.  naming updates and queries between subnets
2.  integration (or otherwise) of unicast DNS and mDNS
3.  DNSSEC validation

kind regards,

Ray

---

From: Simon Kelley <[email-masked]>
Date: Mon, 05 Mar 2012 10:08:08 +0000

On 05/03/12 09:25, Ray Bellis wrote:
> The idea of running a local authoritative zone alongside a forwarding
> proxy or full recursive server has been seen already, for example in
> the "dnsmasq" software used by many CPE vendors.

I'm the principle author of dnsmasq, and on this list to try and make 
dnsmasq better in the Brave New World. I'm happy to get any suggestions 
on developments to dnsmasq that would further the Homenet remit, either 
on or off list. In the meantime I'll point out that the next release of 
dnsmasq, which features DHCPv6 and Router Advertisement support, is 
imminent.

Cheers,

Simon.

---

From: Jim Gettys <[email-masked]>
Date: Mon, 05 Mar 2012 09:02:16 -0500

> If the idea is valuable, I will write a draft and sample DNS server.
Note that CeroWrt (a derivative of OpenWrt in which we are doing our
bufferbloat work) has a full Bind 9.9 implementation you can experiment
with today, and that this has been our intent from the beginning, both
to simplify naming for users, and to get a DNSSEC implementation.

A dnsmasq implementation would be welcome, for a couple reasons:
competition is good, and it would likely be a lot smaller than ISC Bind
is.  But code that exists and runs trumps code not yet ready for
primetime....

We'd love to have some help to flesh this out properly; it needs
scripting support to get fully implemented the way we've envisioned it.

We don't currently use ISC DHCP, as it's currently (due to an
implementation crock being worked on) too big; there is a dibbler
implementation being shaken down.

See http://www.bufferbloat.net/projects/cerowrt
                    - Jim

---

From: Simon Perreault <[email-masked]>
Date: Mon, 05 Mar 2012 10:10:08 -0500

> It is also listed as requirement LAN.DNS.6 in the Broadband Forum's TR-124 Issue 2.  As such a draft describing this is probably unnecessary.

If I understand the original post correctly, it goes much further than 
just saying "home router MUST have an authoritative server". It 
specifies a new usage pattern of that server on the home net. That could 
mean new draft in this WG, wouldn't it?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Kazunori Fujiwara <[email-masked]>
Date: Tue, 06 Mar 2012 00:15:33 +0900 (JST)

Ray-san,

Thanks for your comments.

> From: Ray Bellis <[email-masked]>

I see. DHCP has enough function. RFC 2132 defines DHCP client host
name option, and RFC 4702 Section 3.2. "Client Desires to Update A
RRs" defines the option to DNS RR.

# I'm not aware that DHCPv6 has the same option.

Using DHC client host name option is easier than implementing DNS
Update client in each client.

"dnsmasq" seems to have enough function (except multiple subnets,
multiple upstreams).

Or a combintion of isc-dhcpd and BIND 9 may achieve all of DNS related
works.

> 1.  naming updates and queries between subnets

One upstream, and multiple subnets case, it may be solved by using one
DHCP server and multiple DHCP relay agents.

Multiple upstream case, manual configuration is necessary.  An end
user setup one DNS server which serves local zone and multiple
reverse zones. DHCP servers send updates to the DNS server.

> 2.  integration (or otherwise) of unicast DNS and mDNS

It is same as now.
Using different TLDs solves the problem.

> 3.  DNSSEC validation

DNS proxy can forward global queries to DNSSEC validators.
Local zones does not require DNSSEC validation, I think.

I thought to write I-D, but now, DHCP has enough capability,
I will consider the issure more.

Regards,

--
Kazunori Fujiwara, JPRS

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Mar 2012 15:20:55 +0000

On 5 Mar 2012, at 15:10, Simon Perreault wrote:

> That could mean new draft in this WG, wouldn't it?

It _might_, but IMHO not until we've addressed those "bigger picture" issues I mentioned.

In practise, all such CPE servers that I know of that implement the TR-124 requirement do it using the same usage pattern as Fujiwara-san described.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Mar 2012 15:33:51 +0000

On 5 Mar 2012, at 15:15, Kazunori Fujiwara wrote:

> RI see. DHCP has enough function. RFC 2132 defines DHCP client host

Me neither, although whether DHCPv6 actually gets used within the Homenet (as opposed to standard Neighbor Discovery) remains to be seen.

> Update client in each client.

Agreed, and it removes the need for the TSIG key management normally required for DNS Dynamic Updates.

> DHCP server and multiple DHCP relay agents.

I was more thinking about mDNS - there's no standardised mechanism (although drafts are forthcoming) for using "link-local mDNS" in multiple segments.

The options would appear to be either a multicast relay agent running on internal CPE, or an enhancement to mDNS to support "site-local" multicast.

> reverse zones. DHCP servers send updates to the DNS server.

The unicast case is likely simpler, but we also need to beware the case where the entire Homenet stops working because of the failure of a single "super node".

> Using different TLDs solves the problem.

It does, but without my co-chair hat on, I would prefer not to have different namespaces for unicast vs multicast naming and discovery mechanisms.

> DNS proxy can forward global queries to DNSSEC validators.

There are a lot of people who think that DNSSEC validation should be done as close to the host as possible.  I'm inclined to agree with them.

The downside is that one then needs a way to bootstrap the root's DNSSEC key, and also a way to replace it should the RFC 5011 automated trust anchor update mechanism become unusable.

> Local zones does not require DNSSEC validation, I think.

I'm undecided on that.

> I will consider the issure more.

Thank you - your input is much appreciated.

Ray

---

From: Kazunori Fujiwara <[email-masked]>
Date: Tue, 06 Mar 2012 00:35:15 +0900 (JST)

> From: Simon Perreault <[email-masked]>
>> Thanks for your note.  The idea of running a local authoritative zone
>> alongside a forwarding proxy or full recursive server has been seen
>> already, for example in the "dnsmasq" software used by many CPE
>> vendors.
>>
>> It is also listed as requirement LAN.DNS.6 in the Broadband Forum's
>> TR-124 Issue 2.  As such a draft describing this is probably
>> unnecessary.
> 
> specifies a new usage pattern of that server on the home net. That
> could mean new draft in this WG, wouldn't it?

I think an BCP document or implementation guide is necessary.

There are at least three points, I think.

+-----------------------+-------+------------------+----------------------
| function              ||mDNS  | DHCP             |
+-----------------------+-------+------------------+----------------------
| resolving:            || mDNS | normal DNS query via DNS proxy
| holding zones:        || mDNS | authoritative DNS server
+-----------------------++------+------------------+---------------------
| declaring client name || mDNS | DHCP client name | DNS update (directly)
+-----------------------++------+------------------+----------------------
|implementation         || mDNS |dnsmasq or DHCPD+BIND |  new
+-------------------------------------------------------------------------

mDNS requires special code to resolve the domain name. (Isn't it?)

dnsmasq has an authoritative server function in it.

--
Kazunori Fujiwara, JPRS

---

From: Michael Richardson <[email-masked]>
Date: Mon, 05 Mar 2012 17:05:13 -0500

In the DNS space, I would like the WG to declare the name-based
selection of DNS servers (what some want to do for walled gardens)
should be ruled harmful.

If some walled garden wants the name->AAAA mapping private, then 
just restrict queries to source addresses within the walled garden.
If necessary, add level of NS record.  

(IPv4 thinking would lead you to think you do not want to pollute
"public" DNS with RFC1918 A records, but IPv6 has no such problem)

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 06 Mar 2012 09:24:00 +1100

In message <[email-masked]>, Ray Bellis wr
ites:
> Me neither, although whether DHCPv6 actually gets used within the Homenet (as
>  opposed to standard Neighbor Discovery) remains to be seen.
> 

A significant percentage of home machines will roam and those
machines will need to be able to register their current address in
the DNS.  I do this today when my Mac roams.  TSIG is unavoidable
and cheap.  UPDATE itself is relatively cheap.

For PTR records TCP is a good enough authenticator for UPDATE.

> I was more thinking about mDNS - there's no standardised mechanism (although 
> drafts are forthcoming) for using "link-local mDNS" in multiple segments.
> 
> The options would appear to be either a multicast relay agent running on inte
> rnal CPE, or an enhancement to mDNS to support "site-local" multicast.
> 
> The unicast case is likely simpler, but we also need to beware the case where
>  the entire Homenet stops working because of the failure of a single "super n
> ode".
> 
> It does, but without my co-chair hat on, I would prefer not to have different
>  namespaces for unicast vs multicast naming and discovery mechanisms.
> 
> 
> >> 3.  DNSSEC validation
> > 
> There are a lot of people who think that DNSSEC validation should be done as 
> close to the host as possible.  I'm inclined to agree with them.
> 
> The downside is that one then needs a way to bootstrap the root's DNSSEC key,
>  and also a way to replace it should the RFC 5011 automated trust anchor upda
> te mechanism become unusable.
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 06 Mar 2012 10:15:45 -0500

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:
    Mark> A significant percentage of home machines will roam and those
    Mark> machines will need to be able to register their current
    Mark> address in the DNS.  I do this today when my Mac roams.  TSIG
    Mark> is unavoidable and cheap.  UPDATE itself is relatively cheap.

Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith
way to do key establishment so that TSIG can be initialized?

---

From: james woodyatt <[email-masked]>
Date: Tue, 06 Mar 2012 10:23:37 -0800

> way to do key establishment so that TSIG can be initialized?

The alternative is to delegate all that business to 3rd parties with big data centers in the proverbial cloud.  Yes, that means that you're relying on Internet service to be constantly available to resolve service locations on your local home network, but it does seem to work reasonably well today.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Dave Taht <[email-masked]>
Date: Tue, 6 Mar 2012 10:49:26 -0800

On Tue, Mar 6, 2012 at 10:23 AM, james woodyatt <[email-masked]> wrote:

> The alternative is to delegate all that business to 3rd parties with big
> data centers in the proverbial cloud.  Yes, that means that you're relying
> on Internet service to be constantly available to resolve service locations
> on your local home network, but it does seem to work reasonably well today.
>

In some parts of the world, maybe, like california.

Elsewhere, say in Nicaragua... not so much. I would personally prefer that
those designing this stuff with *any* dependencies on centralized services
spend some time doing research in south america, Libya, africa, eastern
europe, the australian outback, and places like that...

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

---

From: Jim Gettys <[email-masked]>
Date: Tue, 06 Mar 2012 14:00:32 -0500

On 03/06/2012 01:49 PM, Dave Taht wrote:
>
>
> On Tue, Mar 6, 2012 at 10:23 AM, james woodyatt <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Mar 6, 2012, at 07:15 , Michael Richardson <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > "Mark" == Mark Andrews <[email-masked] <mailto:[email-masked]>>
>     writes:
>     The alternative is to delegate all that business to 3rd parties
>     with big data centers in the proverbial cloud.  Yes, that means
>     that you're relying on Internet service to be constantly available
>     to resolve service locations on your local home network, but it
>     does seem to work reasonably well today.
>
>
> Elsewhere, say in Nicaragua... not so much. I would personally prefer
> that those designing this stuff with *any* dependencies on centralized
> services spend some time doing research in south america, Libya,
> africa, eastern europe, the australian outback, and places like that...
>
>

Or Peru, or Uruguay, or Uganda, or.... (given my OLPC experience).

I have to emphasise what Dave's saying here: requiring centralised
services to work at all is really a non-starter, not to mention what
happens when things break in the developed world. 

What's more, in those parts of the world, they can't afford either the
reliable connectivity or expensive kit in schools/houses and often use
off the shelf commodity home routers even in places we'd probably do
something much better.  My point of view is to do it right in the home,
so everyone benefits at the low end.
                - Jim

---

From: Randy Turner <[email-masked]>
Date: Tue, 6 Mar 2012 12:14:28 -0800

+1

---

From: Mark Andrews <[email-masked]>
Date: Wed, 07 Mar 2012 09:54:30 +1100

> way to do key establishment so that TSIG can be initialized?

For homes a shared key is fine or if you want a small database of
keys.

Businesses would use a shared database between the nameserver and
the provision system for storing the TSIG key associations.  The
TSIG key should be assigned as part of the machines registration
process.

The machines do the same thing in both environments.  Just the
implementation differs slightly.  TSIG is nothing more than a
name/secret pair.  One could go all the way to using GSS-TSIG but
that is overkill for the home network and for many small businesses.

The point is that the home router is expecting to see signed UPDATE
requests from both inside and outside and to potententially be a
master for zone transfers to external nameserver which publish the
zone to the world.  With IPv6 homes don't need to be second class
entities.

Mark

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Mar 2012 08:46:31 -0500

>> way to do key establishment so that TSIG can be initialized?

    Mark> For homes a shared key is fine or if you want a small database of
    Mark> keys.

You didn't answer my question!  I wasn't asking for justification, I was
asking for clarification of what you are proposing.

I imagine a situation where one plugs into the homenet with your laptop.
Some application/agent on the laptop realizes (via mDNS/Bonjour? via
DCHP? TBD) that this network supports IPv6, and supports persistent
names.  It asks you if you'd like to persist your name into the local
zone.  It has an option to say, "make this name follow me"(%).

There is a protocol exchange (TBD) with the designated homenet DNS
server(s), and this establishes a TSIG for later use.  
Same TSIG could also be used to update the reverse map, but as you
indicate, TCP from the address you want to update is probably good
enough for addresses considered "local".

While this might seems bit out of scope for homenet (to provide names for
laptops which are not at home), it's actually not.   Depending upon how
the protocol works, it might be another way to deal with the
mDNS/Bonjour-does-not-cross-link problem.   If the TSIG setup protocol
can be mediated(proxied) in a link-layer attached way, then it might be
that we do not need to make Bonjour cross links, as we can just use DNS.

(%)-one need not have a globally reachable name.  One might be
        registering into .homenet/.lan/.local.  This may be for the
        benefit of machines which are still at home, and which need to
        find your laptop.  Or the home user might have a global DNS
        name. The difference is really just a matter of NS/DS records.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 08 Mar 2012 12:20:11 +1100

In message <[email-masked]>, Michael Richardson writes:
> >>>>> "Mark" =3D=3D Mark Andrews <[email-masked]> writes:
>     Mark> In message <[email-masked]>, Michael Rich=
> ardson writes:
>     >> >>>>> "Mark" =3D=3D Mark Andrews <[email-masked]> writes:

Ok. Lets look at a working model that Microsoft has with AD.  You boot
the machine them a Adminstrator adds the machine to the AD domain using
the administrators credentials.

One can do essentially the same thing with TKEY and get a TSIG key
that can be stored.  The home owner would register the machine with
the router using TKEY.  The credentials used would allow registration
on behalf.  TKEY support sending additional data in the request we
only need a standard description on how to do "on behalf of".

Mark

---

From: Jim Gettys <[email-masked]>
Date: Wed, 07 Mar 2012 20:27:19 -0500

>         name. The difference is really just a matter of NS/DS records.

BTW, it appears Dave Taht has mDNS forwarding working between networks
in CeroWrt using Avah; but we need to do more testing.

I don't think that is the only place where we may have such issues; SNMP
comes to mind, but I don't know how commonly that is used in home
environments.
            - Jim

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Mar 2012 11:57:15 -0500

>>>>> "Jim" == Jim Gettys <[email-masked]> writes:

    Jim> BTW, it appears Dave Taht has mDNS forwarding working between
    Jim> networks in CeroWrt using Avah; but we need to do more testing.

so, basically it's just a proxy?

    Jim> I don't think that is the only place where we may have such
    Jim> issues; SNMP comes to mind, but I don't know how commonly that
    Jim> is used in home environments.  - Jim

SNMP is unused in home networks.
I don't know why there is any issue with SNMP though.

---

From: Dave Taht <[email-masked]>
Date: Thu, 8 Mar 2012 17:07:43 +0000

On Thu, Mar 8, 2012 at 4:57 PM, Michael Richardson <[email-masked]> wrote:
>    >> (%)-one need not have a globally reachable name.  One might be
>    >> registering into .homenet/.lan/.local.  This may be for the
>    >> benefit of machines which are still at home, and which need to
>    >> find your laptop.  Or the home user might have a global DNS
>    >> name. The difference is really just a matter of NS/DS records.
>

 yes. they call it a 'reflector'. From avaha-daemon's man page

Section [reflector]

enable-reflector= Takes a boolean value ("yes" or "no"). If set to
"yes" avahi-daemon will reflect incoming mDNS requests to all local
network interfaces, effectively allowing clients to browse mDNS/DNS-SD
services on all networks connected to the gateway. The gateway is
somewhat intelligent and should work with all kinds of mDNS traffic,
though some functionality is lost (specifically the unicast reply bit,
which is used rarely anyway). Make sure to not run multiple reflectors
between the same networks, this might cause them to play Ping Pong
with mDNS packets. Defaults to "no". reflect-ipv= Takes a boolean
value ("yes" or "no"). If set to "yes" and enable-reflector is
enabled, avahi-daemon will forward mDNS traffic between IPv4 and IPv6,
which is usually not recommended. Defaults to "no".

...

there are other problems with the mdns spec, notably the TTL figure is
fixed, making routing problematic, even if multicast routing worked
worth beans.

> I don't know why there is any issue with SNMP though.

The elephant in the room is that we no longer have E2E connectivity in
much of the world, so centralized polling utilities
such as those that use snmp, can't work through the multiple layers of NAT.

The edge has gone dark.

I wouldn't claim that snmp is unused in home networks, but it is
sorely underused, as the relevant monitoring utilities are complex to
setup and maintain.

I've been explicitly enabling snmp over ipv6, I note, and using tools
such as those available from 'dartware'

---

From: Dave Taht <[email-masked]>
Date: Thu, 8 Mar 2012 17:12:45 +0000

On Thu, Mar 8, 2012 at 1:20 AM, Mark Andrews <[email-masked]> wrote:
>>     >> >>>>> "Mark" =3D=3D Mark Andrews <[email-masked]> writes:
>>     >> Are you asking for a link-local/mDNS-across-the-homenet leap-of-faith
>>     >> way to do key establishment so that TSIG can be initialized?
>>

An implementation problem is that the 'publishable' quality is not
representable with things like bind9. Bind9 supports 'views', and in
my case, I have a 'us' (for inside the network) and 'them' view (for
everybody else). Inside the network, machines generally have rfc1918
addresses and ipv6 addresses, and outside, only ipv6 addresses.

So you need to update both views/databases in order to have a
consistent namespace. You don't want to leak the rfc1918 addresses to
the outside world, but you (probably) want to make your ipv6 addresses
available both inside and outside.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Mar 2012 14:59:38 -0500

>> You didn't answer my question!  I wasn't asking for
    >> justification, I was asking for clarification of what you are
    >> proposing.

...

    Mark> One can do essentially the same thing with TKEY and get a TSIG
    Mark> key that can be stored.  The home owner would register the
    Mark> machine with the router using TKEY.  The credentials used
    Mark> would allow registration on behalf.  TKEY support sending
    Mark> additional data in the request we only need a standard
    Mark> description on how to do "on behalf of".

So, we need no additional protocol, we just need a DHCP option to tell
the host that where this service is available.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Mar 2012 15:31:14 -0500

>>>>> "Dave" == Dave Taht <[email-masked]> writes:
    Dave> which is used rarely anyway). Make sure to not run multiple reflectors
    Dave> between the same networks, this might cause them to play Ping Pong
    Dave> with mDNS packets. Defaults to "no". reflect-ipv= Takes a
    Dave> boolean

In other words, don't have a loop.

homenet has assumed loops.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 08 Mar 2012 15:34:00 -0500

>> I don't know why there is any issue with SNMP though.

    Dave> The elephant in the room is that we no longer have E2E connectivity in
    Dave> much of the world, so centralized polling utilities
    Dave> such as those that use snmp, can't work through the multiple layers of NAT.

    Dave> The edge has gone dark.

I think the edge never had any light :-)

    Dave> I wouldn't claim that snmp is unused in home networks, but it is
    Dave> sorely underused, as the relevant monitoring utilities are complex to
    Dave> setup and maintain.

    Dave> I've been explicitly enabling snmp over ipv6, I note, and using tools
    Dave> such as those available from 'dartware'

I agree --- I've put IPv6 (non-connected networks) into a number of data
centre operations specifically so that I could use SNMP.  I am not
familiar with dartware... is it: http://www.intermapper.com/

I think that E2E into the home for SNMP is perhaps one of the things
that would motivate an ISP to support homenet.

---

From: Jim Gettys <[email-masked]>
Date: Thu, 08 Mar 2012 17:32:54 -0500

>     >> I don't know why there is any issue with SNMP though.

The specific worry is that when investigating why I couldn't see my home
printer, I came across a reference to the use of multicast SNMP possibly
being used for printer discovery.

I also remember there being a IPP multicast discovery "feature".

Again, I don't know if either of these are used much in practice,
whereas we know mDNS is used quite a lot.

It is wiggling worms like these that make me so convinced that "running
code" is the only way to find out what can actually be deployed.
                            - Jim

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 09:49:56 +1100

In message <CAA93jw44OXWgRoc5Gvof34muhG7=[email-masked]>
, Dave Taht writes:
> > In message <[email-masked]>, Michael Richardson w=
> rites:
> >> >>>>> "Mark" =3D3D=3D3D Mark Andrews <[email-masked]> writes:
> >> =A0 =A0 Mark> In message <[email-masked]>, Micha=
> el Rich=3D
> >> ardson writes:
> >> =A0 =A0 >> >>>>> "Mark" =3D3D=3D3D Mark Andrews <[email-masked]> writes:
> >> =A0 =A0 Mark> A significant percentage of home machines will roam and th=
> ose
> >> =A0 =A0 Mark> machines will need to be able to register their current
> >> =A0 =A0 Mark> address in the DNS. =A0I do this today when my Mac roams. =
> =A0TSIG
> >> =A0 =A0 Mark> is unavoidable and cheap. =A0UPDATE itself is relatively c=
> heap.
> >>
> >> =A0 =A0 >> Are you asking for a link-local/mDNS-across-the-homenet leap-=
> of-faith
> >> =A0 =A0 >> way to do key establishment so that TSIG can be initialized?
> >>
> >> =A0 =A0 Mark> For homes a shared key is fine or if you want a small data=
> base of
> >> =A0 =A0 Mark> keys.
> >>
> >> You didn't answer my question! =A0I wasn't asking for justification, I w=
> as
> > Ok. Lets look at a working model that Microsoft has with AD. =A0You boot
> > that can be stored. =A0The home owner would register the machine with
> > the router using TKEY. =A0The credentials used would allow registration
> > on behalf. =A0TKEY support sending additional data in the request we

Named already transfers in a zone, strips out any NSEC, DNSKEY,
NSEC3, NSEC3PARAM and RRSIG records to get a clean unsigned zone,
the signs the zone using a new set of DNSKEY records to perform
inline signing.  Filtering out RFC 1918 address in addition would
not be a major issue, basically you would have to define a acl to
determine what is filtered.  Zones are transferable between views.
UPDATE requests on the outside view can be forwarded to the inside
view, processed, the resulting zone is transfered, filtered and
signed.  This requires the inside view to be a superset of the
outside view.  If you don't give the inline signing zone a set of
DNSKEYs to work with it just serves the filtered version of the
zone.

> > PHONE: +61 2 9871 4742 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 INTERNET: marka@is=
> c.org
> --=20
> Dave T=E4ht

---

From: Mark Andrews <[email-masked]>
Date: Fri, 09 Mar 2012 10:04:23 +1100

> the host that where this service is available.

More a TKEY option.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Mar 2012 12:11:39 +0900

> If necessary, add level of NS record.

And do what in response to queries for that name coming from outside the
walled garden? Return REFUSED? Return NXDOMAIN? Drop the query? None of
these works, I think.

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 9 Mar 2012 04:42:02 +0000

I think that E2E into the home for SNMP is perhaps one of the things that would motivate an ISP to support homenet.

E2E network management and/or monitoring, yes. SNMP, at least on a public interface, maybe not so much. We may be entering a phase where ISPs consider blocking TCP/UDP 161.

The reason is that SNMP is becoming more and more widely abused. I still have no idea why for example (1) some gear ships with public as the default string and the daemon running by default as such, (2) some gear does not present the user with an interface to turn off SNMP or change the community string at all (so you may be stuck with on/public).

So maybe on SNMP, tread carefully. ;-)

Jason

---

From: Michael Richardson <[email-masked]>
Date: Fri, 09 Mar 2012 09:18:59 -0500

>>>>> "Lorenzo" == Lorenzo Colitti <[email-masked]> writes:

    >> If necessary, add level of NS record.

    Lorenzo> And do what in response to queries for that name coming
    Lorenzo> from outside the 
    Lorenzo> walled garden? Return REFUSED? Return NXDOMAIN? Drop the
    Lorenzo> query? None of 
    Lorenzo> these works, I think.

1) if you use an extra level of NS, then whomever asks for the AAAA
   will get a timeout.  By this, I mean:

   public example.com ns:
        walled.example.com IN    NS     ns.walled.example.com.
        ns.walled.example.com    IN     AAAA    4000:dead:beef::1

   (Let's assume that walled-gardens get clear Non-Connected Network
   allocation in 4000:/3, but it works fine with 2000:/3 space which is
   either un-advertised or firewalled)

   private walled.example.com ns:
        coolserver.walled.example.com   IN      AAAA 4000:dead:beef::2

   If you ask from within the walled garden, then you can talk to the
   4000:dead:beef:/48  network (and you do so from your 4000:/3 address),
   so you get an answer.

   If you ask from without, you get a timeout.  So even the name of the
   service is hidden, which is what I'm told the providers want.

2) if you do not use this extra level, but have a name server which
   the world can reach, then you can return whatever value you want.
   You can return a different AAAA too if you want.

But, tell how is this any different than what I'm told they originally
wanted, which is that we'd have:

        if($domain =~ /.*somesuffice.com$/) {
                   $ns = $walledgardendns;
        }

in applications and stub resolvers?    If you aren't in the walled
garden, what would the application do when $walledgardenns is not
reachable?

---

From: Jim Gettys <[email-masked]>
Date: Fri, 09 Mar 2012 09:38:47 -0500

On 03/08/2012 11:42 PM, Livingood, Jason wrote:
>
>     I think that E2E into the home for SNMP is perhaps one of the
>     things that would motivate an ISP to support homenet.
>
>
> E2E network management and/or monitoring, yes. SNMP, at least on a
> public interface, maybe not so much. We may be entering a phase where
> ISPs consider blocking TCP/UDP 161.  
>
> The reason is that SNMP is becoming more and more widely abused. I
> still have no idea why for example (1) some gear ships with public as
> the default string and the daemon running by default as such, (2) some
> gear does not present the user with an interface to turn off SNMP or
> change the community string at all (so you may be stuck with on/public). 
>
Just to make it clear, I was worrying about the possible use of
multicast to *discover* SNMP devices, and routing versus bridging where
the multicast packet might need forwarding to other networks in the
hime, not SNMP in general.  I had noted its possible use to *discover*
printers to initially configure them.
            - Jim

---

From: David Harrington <[email-masked]>
Date: Fri, 09 Mar 2012 10:22:52 -0500

Hi,

I am not promoting (nor discouraging) SNMP for home networks, but if you're
going to discuss it, let me just make sure the WG understands some of the
features of SNMP designed to be relevant to an IT department managing a home
network remotely (and other cross-admin domain use cases).

You want to avoid SNMPv1 and SNMPv2 over an untrusted network, because they
have only minimal security based on a shared password passed in cleartext in
every message  a community string.
The IETF has declared SNMPv1 and SNMPv2 Historic and NOT RECOMMENDED, so
certainly you should not write any recommendations for their use in homenet.

SNMP is a protocol designed to carry MIB information. That separation of
message from content is critically important, to enable protocols other than
SNMP to also carry MIB information.
If most end users do not use SNMPv1 because **MIB-based management** is too
complex and user-unfriendly for home use,  SNMPv3 will not solve that
problem. It uses the same MIB.
SNMPv1 is quite easy to configure  you just point it at an address and give
it the right community string.
SNMPv3 was designed to be secure, and has lots of security setup that would
baffle most home users.
However, IT departments wanting SNMP to reach into the home could consider
SNMPv3.

SNMPv3 offers authentication using negotiated methods - its own security,
SSH and TLS. (all IETF standards).
It offers authorization on a per-user-session basis using RADIUS, tied into
SSH and/or TLS.
While SNMPv1 and SNMPv3 both run over ports 161/162, SNMPv3 can distinguish
whether the authentication is done using community strings, SSH, TLS or the
SNMPv3 built-in security, and allow/deny accordingly.
SNMPv3 supports security fallback  e.g., if the network is flaky and you
cannot reach a CA, it can fall back to using the built-in SNMP security.

SNMPv3 offers MIB database access control (who can perform what operations
on which information)
Access control uses a tree-based approach, much like many graphical backup
applications; this allows policies to be defined, for example, at the
everything, the MIB module level, table level, or the object-level. Access
can be dynamically configured by using RADIUS to assign a user to a
predefined access policy (e.g., engineering vs accounting, Boston vs San
Jose, home vs in-office, help-desk vs routing-admin, and so on).
The authentication/authorization/MIB access control can be used to allow
users to manage certain aspects of their network, such as device discovery
and fault monitoring and host resources (RFC2790), while also allowing an
ISP to manage aspects of the home network.

SNMPv3 provides agents with a global identifier independent of their current
address.
This was designed specifically to handle dynamically-changing addresses,
such as from DHCP and NAT, or recognizing that a single agent is using
multiple interfaces with different addresses (important for correlating the
data received via multiple addresses for the same agent).

There is an SNMP proxy-mib that provides a message-header rewrite (but not
payload) between security approaches.
The proxy-mib can be used for proxying between SNMPv1 and SNMPv3 security.
For example, SNMPv1 can be used managing a trusted internal network or a
network with no SNMPv3 support, like a homenet, and then proxy to SNMPv3 for
carrying the data over an untrusted network like the Internet.
If no proxy rule applies, the message gets dropped, like a firewall.

In a NAT environment, or other environment that uses aggregation, you may or
may not want an ALG to do address translation in the payload. If you are
looking at a  server farm, some uses might be better served by seeing this
as one abstract aggregation; For performance and fault monitoring, you might
want to look at each individual server. See RFC2962.

I hope this helps provide more detail about relevant aspects of SNMP for
home networks.

--
David Harrington
Director, Transport Area
Internet Engineering Task Force (IETF)
[email-masked]
+1-603-828-1401

From:  Jason Livingood <[email-masked]>
Date:  Fri, 9 Mar 2012 04:42:02 +0000
To:  Michael Richardson <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc:  Dave Taht <[email-masked]>
Subject:  Re: [homenet] snmp for monitoring home network

> I think that E2E into the home for SNMP is perhaps one of the things that
> would motivate an ISP to support homenet.

E2E network management and/or monitoring, yes. SNMP, at least on a public
interface, maybe not so much. We may be entering a phase where ISPs consider
blocking TCP/UDP 161.

The reason is that SNMP is becoming more and more widely abused. I still
have no idea why for example (1) some gear ships with public as the default
string and the daemon running by default as such, (2) some gear does not
present the user with an interface to turn off SNMP or change the community
string at all (so you may be stuck with on/public).

Jason
_______________________________________________ homenet mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/homenet

---

From: David Harrington <[email-masked]>
Date: Fri, 09 Mar 2012 10:27:29 -0500

Hi,

I am not sure what proposal you are referring to.
I know multicast SNMP for discovery was proposed quite a few years ago,
but multicast SNMP would depend on the non-secure nature of SNMPv1 and a
well-known community string. This is at odds with the IETF declaring
SNMPv1 Historic and not recommended.

The multicast approach won't work with the built-in SNMPv3 security, and
to my knowledge all effort to do this (at least in IETF) was dropped
precipitously.
Hopefully, nobody is seriously considering this approach again, if it
builds on SNMPv1.

---

From: Jim Gettys <[email-masked]>
Date: Fri, 09 Mar 2012 11:00:41 -0500

> Hopefully, nobody is seriously considering this approach again, if it

I was just observing comments I came across in code being used for
printer discovery. 

That doesn't mean SNMP multicast is actually used significantly; it's
mostly an example of another protocol that *could* cause trouble when we
route rather than bridge everything inside the home.  Having
(apparently) demonstrated (we hope) that mDNS doesn't really present a
major problem by implementation, I still have concerns if there are
other protocols that matter that we'll have to worry about to get rid of
the bridging horror we face today.

I have *no* information that makes me think it's a *real* problem as
yet, and see no way to do so before having running code in the hands of
probably thousands of testers.  At the moment, we have code in the
hands  of testers of the fingers on one or two hands.... More testers
would be welcome....

I am encouraging everyone to think about potential problems that might
be caused by other multicast protocols that may be in use; knowing
sooner rather than later would be nice ;-).

And thanks for the details about SNMP, they are indeed reassuring.
                        - Jim

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Mar 2012 07:55:23 +1300

On 2012-03-10 05:00, Jim Gettys wrote:
...
> I was just observing comments I came across in code being used for

Why would we consider anything other than SLP for service discovery?

   Brian

---

From: Dave Taht <[email-masked]>
Date: Fri, 9 Mar 2012 11:25:32 -0800

> Why would we consider anything other than SLP for service discovery?

I don't know the cause of jg's printing issue. Wouldn't mind knowing,
but I doubt it's snmp.

However I note that zeroconf is the way
apparently apple is going, rather than SLP, since OS-X 10.2 and later,
according to wikipedai

and...

http://www.unixmen.com/201202-apple-orphans-linux-cups-features-handicaps-open-source-printing/

"CUPS Browsing, the pivotal process that detects cups-to-cups printer
queue on Linux will no longer be available. Up until now each CUPS
server typically sends UDP packets at 631 port to indicate its
availability for queuing.

Now, the new changes in CUPS 1.6 will not allow this browsing to
happen and will be replaced with DNS-SD. This is already the standard
for Mac OS X, but does not include Avahi support. Avahi is a  popular
system for zeroconf DNS-SD processes."

---

From: Paul Duffy <[email-masked]>
Date: Fri, 09 Mar 2012 14:42:39 -0500

> Why would we consider anything other than SLP for service discovery?

Its my understanding that mDNS/DNS-SD and UPnP SDDP have far more 
traction in the consumer space than SLP.

Please do correct if I'm wrong.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Mar 2012 07:58:34 +1300

> Please do correct if I'm wrong.

Aren't we trying to influence the future rather than document the
past?

We need a name-based service discovery solution. That's also a
requirement emerging from 6renum. I think we should decide what's
the best recommendation; it may end up being DNS-based, but this
is what SLP was designed for, so IMHO it should be considered.

This is clearly *not* what SNMP was designed for.

   Brian

---

From: Don Sturek <[email-masked]>
Date: Sat, 10 Mar 2012 13:21:36 -0800

Can I ask exactly where SLP has been deployed?   I spent some time
investigating discovery solutions (we ended up using mDNS) but I could not
find any significant deployments of SLP.

It really came down to uPnP and mDNS.......

Don

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 10 Mar 2012 14:02:50 -0800

> Aren't we trying to influence the future rather than document the
Brian,

I'm not sure of your point; mDNS and DNS-SD are Standards Track
drafts currently in the RFC-Editor queue and there are tens of millions
of deployed mDNS responders.  If SLP is running in my home, I'm
not aware of it.

> is what SLP was designed for, so IMHO it should be considered.
Just as homenet has "Largest Possible Subnets", "Fewest Topology
Assumptions", and "Self Organizing" principles, perhaps we should
also consider "Fewest Protocols" as well.  To my mind, using DNS for
both service discovery and name resolution has many advantages.
These are documented in the above mentioned drafts, but I would
just point out three: simple DNS-based discovery is trivial to add to
an existing resolver, mDNS has been demonstrated in constrained
environments (e.g. it places limits on name length and character
set), and it is based on a well-understood (and well-supported)
protocol.  There may be good reasons to consider SLP, but I'd
like to see how these line up against the home net goals.

I will add that I've co-authored a draft that considers extending mDNS
to site scope and would like to receive any comments people have:
https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/

Thanks, -K-

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 11 Mar 2012 12:53:16 +1300

Cutting to the chase (and this answers Don too):

> There may be good reasons to consider SLP, but I'd

Exactly. It's perfectly fine by me if SLP is not the right
answer for future homenets, but this should be a goal-based
decision, not based on what happens to be deployed on
single-subnet homenets today.

Regards
   Brian

---

From: Jim Gettys <[email-masked]>
Date: Sat, 10 Mar 2012 19:39:06 -0500

> single-subnet homenets today.

I agree Brian.

My concern is just figuring out if there are any practical issues in
already deployed discovery protocols (e.g. mDNS, uPnP) or wiggling
things we don't know about in a corner that will stand in the way of
making *real* home *networks*, that are actually networks, rather than
our current bridged disasters that people call home routers, but really
aren't... 

When there were discussions about routing versus bridging in homenet
early on, there was quite a bit of scepticism that routing can be made
to work without unforseen practical problems: we're trying to answer
that along the way in our CeroWrt work.  So far, thinks look ok. But I
believe first all in "running code", much more than hand-waving....
                    - Jim

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Mar 2012 00:47:05 +0000

> single-subnet homenets today.

Indeed; the arch text is capturing those goals, so some discussion and 
definition of those is very welcome.  

Tim

---

From: Don Sturek <[email-masked]>
Date: Sat, 10 Mar 2012 17:25:11 -0800

Hi Brian,

To be honest, I was not wedded to mDNS (or xmDNS though I am down as the
author) but frankly that or uPnP seemed to be the only game in town when
we made our selection.

I was actually told by several people to avoid SLP since it was deployed
in no real numbers anywhere and the code base was considered large for the
devices we were targeting (I have to say the deployment numbers and
experience we the main deciding factors, not the limited code size
numbers.....).

I would be happy to be proved wrong but it does seem that mDNS and uPnP
seem to be the solutions with traction and deployment experience.

If Homenet wants to go down the SLP path then I think we (the Homenet
group) need to provide justification on why that choice is better than
what is currently deployed.

Don

---

From: Randy Turner <[email-masked]>
Date: Sat, 10 Mar 2012 18:19:09 -0800

Zero configuration seems to be a goal of our work…it would be unfortunate if the output of the previous IETF "zeroconf" WG wasn't put to good use, or if not sufficient, extended.

Randy

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Mar 2012 22:38:17 -0500

On Mar 10, 2012, at 9:19 PM, Randy Turner <[email-masked]> wrote:
> it would be unfortunate if the output of the previous IETF "zeroconf" WG wasn't put to good use, or if not sufficient, extended.

Why do you say that?

---

From: Randy Turner <[email-masked]>
Date: Sat, 10 Mar 2012 19:51:10 -0800

Just seems like the IETF has tried to address one of our requirements (zero configuration) in the past -- if the IETF has already published proposed standards for zero configuration, why wouldn't we look at this first?  Or at least "cherry pick" what we like from this effort.

R.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Mar 2012 23:12:13 -0500

> Just seems like the IETF has tried to address one of our requirements (zero configuration) in the past -- if the IETF has already published proposed standards for zero configuration, why wouldn't w…

I think it would be better to decide what problem we are trying to solve, and then think about how we'd like to solve it, and then see if there are solutions available that we can leverage to solve the problem, rather than predisposing any decision-making process towards choosing the output of the zeroconf working group.   Certainly it would be irresponsible to entirely fail to consider zeroconf work, but the problems it set out to solve, and the way it solved them, are not particularly applicable to the homenet scenario.   If you use zeroconf work as a starting point, you probably won't get to a very satisfying destination.

---

From: Randy Turner <[email-masked]>
Date: Sat, 10 Mar 2012 20:24:38 -0800

According to the zeroconf charter, home networking and SOHO environments were a primary target of the zeroconf work.  I don't think the zeroconf and homenet scenarios are as divergent as you indicate, but I agree on letting things play out a bit more to determine the problem(s) we're trying to solve. 

R.

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 10 Mar 2012 20:33:41 -0800

On Sat, Mar 10, 2012 at 7:51 PM, Randy Turner <[email-masked]> wrote:
>
> Just seems like the IETF has tried to address one of our requirements (zero
> configuration) in the past -- if the IETF has already published proposed
> standards for zero configuration, why wouldn't we look at this first?  Or at
> least "cherry pick" what we like from this effort.
>
> R.
>

This seems like a good place to briefly describe the mDNS extensions we
proposed in https://datatracker.ietf.org/doc/draft-lynn-homenet-site-mdns/

LLNs are a primary target.  Since an LLN's definition of "link-local" means
first-hop neighbors, the first change is to use the site-local multicast
address FF05::FB to make sure the whole mesh is covered.  Next, since
the behavior of name resolution for .local names is completely defined by
the mDNS draft (and tens of millions of extant resolvers) we decided to
define another special TLD .site.  As there are currently no legacy
implementations, we have some latitude to modify the way certain fields
like hop limit are used.

When it comes to routing behavior, there are three possibilities: a router
*always* forwards xmDNS out the other "in scope" ports (e.g. this is
the defined behavior of interior mesh nodes), a router *never* forwards
xmDNS (e.g. across the HAN/ISP border), or it *may* forward xmDNS.
This last one is tricky one.  The xmDNS draft does not take a position
(yet, anyway) on how to define a site boundary.  It may be that there are
several in a single homenet.  We probably don't want LLNs to be over-
whelmed by discovery packets from an adjacent ethernet link and might
choose to put a proxy there instead; one that selectively forwards requests
or at least shapes the traffic at that border.

I note that the current arch draft is virtually silent on the matter of multi-
cast forwarding.  It seems to me that we really must ultimately declare
multicast forwarding to in or out of scope.  I favor the former, since we
should anticipate applications like multi-player online games or media
distribution inside the home.  One possible candidate is MLD Proxy
(RFC 4605) but then we'd have to come up with a way to form a tree.

-K-

---

From: Kerry Lynn <[email-masked]>
Date: Sat, 10 Mar 2012 20:40:12 -0800

On Sat, Mar 10, 2012 at 8:12 PM, Ted Lemon <[email-masked]> wrote:
> I think it would be better to decide what problem we are trying to solve,
> and then think about how we'd like to solve it, and then see if there are
> solutions available that we can leverage to solve the problem, rather than
> predisposing any decision-making process towards choosing the output of the
> zeroconf working group.   Certainly it would be irresponsible to entirely
> fail to consider zeroconf work, but the problems it set out to solve, and
> the way it solved them, are not particularly applicable to the homenet
> scenario.   If you use zeroconf work as a starting point, you probably won't
> get to a very satisfying destination.
>
I think Ralph offered an initial set of requirements for Naming and Service
Discovery.  Do you have additional requirements to add, or think that any
of Ralph's points are out of scope?  IOW, what's the consensus opinion on
the "problem we are trying to solve"?

---

From: Paul Duffy <[email-masked]>
Date: Thu, 15 Mar 2012 13:26:34 -0400

> Aren't we trying to influence the future rather than document the

Agreed.  The initial discussion re: service discovery should be 
requirements driven.

I'll admit guilt re: starting to jump to a pre-mature conclusion.  
Partly driven by issue fatigue.   I've been involved with this same 
requirements based discussion re: zero touch service discovery now 
within several venues, over many years.  Its largely the same cast of 
characters.  SLP vs DNS-SD vs uPnP  SDDP.

At some point, there needs to be a practical incorporation of which way 
the wind is blowing, unless there are compelling reasons to do otherwise.

> This is clearly *not* what SNMP was designed for.

Totally agree.  Particularly in light of the fact that IETF has 
acknowledged SNMP is typically used only for poll based status monitoring.

---

From: David Harrington <[email-masked]>
Date: Thu, 15 Mar 2012 14:08:39 -0400

Agreed.

On 3/15/12 1:26 PM, "Paul Duffy" <[email-masked]> wrote:

>      Re: [homenet] Discovery [snmp for monitoring home network]
>      
>    within several venues, over many years.  Its largely the same cast
>    of characters.  SLP vs DNS-SD vs uPnP  SDDP.
>    
>    At some point, there needs to be a practical incorporation of which
>    way the wind is blowing, unless there are compelling reasons to do
>    otherwise.
>    
>    
>      
>