Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

[Ted Lemon <[e-mail]>]

I just did a somewhat larger-than-expected update to the document to
capture Toke's comments thus far.   I also got a surprise guest review from
a friend of mine, Tamara Kemper, who revealed a few opportunities to make
the document clearer and better scoped.  In the process of doing these two
things I noticed that I'd fairly significantly misstated how SRV records
work and left out some important details.   The new document fixes all of
these things (I hope).   Sorry for adding so much text during an adoption
call, but I didn't want to leave it for later because it would have made
reading the document kind of unpleasant for Stuart, who I hope will review
it this weekend, and if I hadn't done it now it would have taken at least
twice as long later.  The good news is that I'm pretty chuffed about the
quality of the document now.

You can see the diffs here:
https://github.com/StuartCheshire/draft-sctl-service-registration/commit/51b7cb54300fea7e44e8e7dee49c17e9f598b3ba
The text of the document is here:
https://github.com/StuartCheshire/draft-sctl-service-registration/blob/master/draft-sctl-service-registration.txt

I don't think this substantially changes what we'll discuss in Montreal,
but attendees who want to give technical feedback at the mic should
probably read this version.

On Tue, Jul 10, 2018 at 8:48 AM, Toke Høiland-Jørgensen <[e-mail]>
wrote:

> Ted Lemon <[e-mail]> writes:
>
> >>>> So another way to ensure this source verification is needed, I think.
> >>>> The way I implemented it is to have the registration server only speak
> >>>> TCP; that way, source address spoofing is not possible (as that would
> >>>> make the handshake fail), and the server can simply implement a
> >>>> straight-forward ACL policy.
> >>>
> >>> This could also work, or we could use DNS cookies, but it breaks the
> >>> LLN use case.
> >>
> >> Wouldn't it be possible to specify both?
> >
> > I'm coming around to thinking this might be a good idea for some
> > cases, but I also think that the anycast use case needs to be
> > preserved, and that ought to be a simple two-message exchange in the
> > success case. The problem is deciding when TCP makes sense.
>
> Couldn't that just be left up to the client? I.e., the network SHOULD
> provide both, clients MUST support both and if the network only supports
> one use that; but if the network supports both, the client is free to
> pick whatever makes the most sense for its use case.
>
> I'm a little worried that this would lead to too many permutations to
> test interoperability, and/or just lead to cherry-picking. But it's
> definitely easier to specify than coming up for rules for when to do
> what... :)
>
> >>>> - It is not quite clear to me whether the sleep proxy described in
> >>>> section 4 is an optional feature or if its meant to be mandatory.
> >>>> Stuart explained its usefulness for devices that power off when not in
> >>>> use, requiring this function will mean that registration servers will
> >>>> need to be on the local link, which is somewhat limiting. Also, the
> >>>> implementation complexity goes way up (I certainly don't plan to
> >>>> implement this feature :)). So I think having a way for the server to
> >>>> signal "no, I can't perform sleep proxying" to the client would be
> >>>> good to allow things to fail in a graceful way.
> >>>
> >>> Sleep proxy is advertised as a service, so devices that don't
> >>> implement it can not advertise it.
> >>
> >> Ah, great. As long as its in spec to not advertise that service, that's
> >> good enough for me.
> >>
> >>> However, this breaks the LLN single-exchange use case, so I think
> >>> there's an argument that it should be required on LLNs.
> >>
> >> Hmm, I'm not sure I quite understand what you mean by single-exchange
> >> use case, then?
> >
> > An LLN device should be able to register with a sleep proxy without
> > first discovering a specific sleep proxy with which to register. It
> > should IOW be able to send a single DNS Update packet to an anycast
> > address and get back a response of "yes, we have set up a sleep proxy
> > for you."
>
> Right. And how is it supposed to discover which anycast address to use?
> Or is that going to be a special address assigned as part of the
> standard?
>
> >> What I mean is that to do sleep proxying (as I read the spec) requires
> >> raw sockets, or some other way to answer neighbour requests on the
> >> sleeping device's behalf. Which generally tends to be a privileged
> >> operation, and raises the complexity from "just answer DNS requests".
> >> And of course it requires link-local presence, which means it either
> >> requires automation (such as in homenet), or lots of manual
> >> configuration.
> >
> > Right. This is actually a really key point that we'd utterly missed.
> > Since we are supporting multiple subnets, the current sleep proxy
> > paradigm doesn't work. That doesn't mean it _can't_ work, but it is
> > different than what we'd had in mind, and is in fact more work than
> > we'd been assuming. Thanks for poking a hole in this blind spot!
>
> Haha, you're welcome ;)
>
> > I'm not sure what the answer is here—on a homenet it's not too hard to
> > imagine a solution; on an LLN I think it's not a problem, but it's
> > definitely a problem for the campus use case. I don't think this is an
> > impediment to adoption, because the registration protocol is useful
> > whether it supports the sleep proxy use case or not.
>
> Agreed.
>
> > But we need to figure out how to address this.
>
> Hmm, only thing that comes to mind is doing the proxying at layer 3
> instead; i.e., advertise the proxy's address in DNS and forward packets
> to the sleeping device using encapsulation or (*shudder*) two-way NAT.
> That would require the proxy to stay in the loop for everything to be
> transparent, though, so not sure if it's a good solution...
>
> >> I think it's not important enough to put in the effort to implement it,
> >> basically.
> >>
> >> Note that this is for my use case; I can totally agree that requiring it
> >> for homenet makes sense; but service registration can be useful in other
> >> contexts as well...
> >
> > I'm curious if I've listed the contexts that you care about, or if I
> > missed some. What contexts do you have in mind?
>
> I think my use case is covered by the campus use case, more or less.
> I.e., a managed network where devices should be able to register
> themselves automatically in (global) DNS with a minimum of
> configuration.
>
> I use it to find devices on my network; if I just configure devices to
> run the registration daemon, and put the right discovery PTR records in
> the network-local recursive resolver, I will be able to find them by
> hostname on the local link, and the registration server can be
> configured to (selectively) put things into global DNS as well. Since
> I run this on different networks, I run registration proxy in the cloud,
> where it services several networks (with different domain names). So
> anything that requires link-local presence is a hassle to support...
>
> -Toke
>