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

[Toke Høiland-Jørgensen <[e-mail]>]

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