Subject: [dnssd] draft-sctl-service-registration call for adoption

From: Tom Pusateri <[email-masked]>
Date: Thu, 19 Jul 2018 10:53:11 -0400

I’ll put this on the mailing list for the benefit of those not at the meeting today.

The document draft-sctl-service-registration is not a general purpose Service Registration Protocol. It has made many compromises to allow registration in a single Update message for constrained devices but there is no encryption or authentication/authorization mechanism that can be used outside an administrative domain.

Since RFC 6763 summarizes in Appendix A:
      Service discovery requires a service registration protocol.
      DNS already has one: DNS Dynamic Update

DNS Dynamic Update is generic and can handle service registration from anywhere under any conditions. But it’s chatty and so there is a need for something that is more efficient for constrained devices.

draft-sctl-service-registration does this by instructing you how to use DNS Dynamic Update is a particular way. It’s a profile of usage.

Therefore, I don’t think we should call this Service Registration Protocol which is a generic name because it isn’t a generic solution. 

I propose “DNS Update Profile for Constrained Services”.

Without a name change, I don’t support adoption of this draft.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 11:34:54 -0400

Tom, there are a couple of problems with what you've said.   First, the
goal of SRP is actually to provide a general solution for registering
services to be discovered using DNSSD.   It is not for constrained devices
only, although that is certainly one case where it's valuable.   So we
can't call it a registration protocol only for constrained devices.

Secondly, this is DNS Update.   It's just that DNS Update without something
like this *doesn't work* as a registration protocol, and we've seen that
because DNS-SD over DNS hasn't taken the world by storm in the years since
it's been published.   This specification is intended to correct this
problem, not to provide a second protocol that can be used in a constrained
set of cases.

It's true that FCFS doesn't work for all use cases.   This specification
acknowledges that and talks about how to address the problem.   We've also
had discussions about this at the mic.   This protocol is however the
enabling technology required to solve those problems as well.   Those will
be subsets of this, rather than this being a subset of those.

So although I understand where you are coming from, I do not agree with
your analysis of the situation.

On Thu, Jul 19, 2018 at 10:53 AM, Tom Pusateri <[email-masked]> wrote:

> The document draft-sctl-service-registration is not a general purpose
> Service Registration Protocol. It has made many compromises to allow
> registration in a single Update message for constrained devices but there
> is no encryption or authentication/authorization mechanism that can be used
> outside an administrative domain.
>
> DNS Dynamic Update is generic and can handle service registration from
> anywhere under any conditions. But it’s chatty and so there is a need for
> something that is more efficient for constrained devices.
>
> draft-sctl-service-registration does this by instructing you how to use
> DNS Dynamic Update is a particular way. It’s a profile of usage.
>
> Therefore, I don’t think we should call this Service Registration Protocol
> which is a generic name because it isn’t a generic solution.
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 19 Jul 2018 18:23:53 +0200

Ted Lemon <[email-masked]> writes:

> services to be discovered using DNSSD. It is not for constrained
> devices only, although that is certainly one case where it's valuable.
> So we can't call it a registration protocol only for constrained
> devices.
>
> Secondly, this is DNS Update. It's just that DNS Update without
> something like this *doesn't work* as a registration protocol, and
> we've seen that because DNS-SD over DNS hasn't taken the world by
> storm in the years since it's been published. This specification is
> intended to correct this problem, not to provide a second protocol
> that can be used in a constrained set of cases.
>
> acknowledges that and talks about how to address the problem. We've
> also had discussions about this at the mic. This protocol is however
> the enabling technology required to solve those problems as well.
> Those will be subsets of this, rather than this being a subset of
> those.
>
> So although I understand where you are coming from, I do not agree
> with your analysis of the situation.

As someone whose primary interest in this draft is naming devices across
(logical) admin boundaries, I can only agree with Ted here. This is by
no means just a thing for constrained devices.

Oh, and I do also support adoption of the draft, if that hasn't been
clear from my previous messages :)

-Toke

---

From: Tom Pusateri <[email-masked]>
Date: Thu, 19 Jul 2018 14:27:37 -0400

> On Jul 19, 2018, at 12:23 PM, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 
> Ted Lemon <[email-masked] <mailto:[email-masked]>> writes:
> 

While you want it to be used for this purpose, it’s not really designed for crossing administrative boundaries.

1. You need encryption which it can’t do because of the multiple packets required to do key management.
2. DNS Update does solve the administrative boundary problem at the expense of more packets back and forth to the update server. That isn’t a problem for you.
3. You don’t need the features this draft is good at.
4. This draft could do more than constrained devices but then DNS Update already does it.

Tom

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 19 Jul 2018 20:35:18 +0200

Tom Pusateri <[email-masked]> writes:

> While you want it to be used for this purpose, it’s not really
> designed for crossing administrative boundaries.
>

No, I don't.

> 2. DNS Update does solve the administrative boundary problem at the
> expense of more packets back and forth to the update server. That
> isn’t a problem for you.

I don't care about the number of packets going back and forth, no. What
I care about is not having to distribute keys and configuration to
devices.

> 3. You don’t need the features this draft is good at.

Such as FCFS/TOFU authentication, you mean? Where is that in DNS update?

> 4. This draft could do more than constrained devices but then DNS

See above.

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 15:09:08 -0400

You actually talked in your presentation on the charter about an SRP
relay.   I think that is a good approach for Toke's use case.   I don't
think there is any way to do service registration across administrative
boundaries without some kind of trust mechanism of this sort.

On Thu, Jul 19, 2018 at 2:27 PM, Tom Pusateri <[email-masked]> wrote:

> expense of more packets back and forth to the update server. That isn’t a
> problem for you.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 19 Jul 2018 21:18:06 +0200

Ted Lemon <[email-masked]> writes:

> relay. I think that is a good approach for Toke's use case.

I disagree. I don't want to run a relay.

> I don't think there is any way to do service registration across
> administrative boundaries without some kind of trust mechanism of this
> sort.

Sure there is: source address validation.

Say I run a dyndns service at dyndns.example.org. I provide an admin
interface where someone can register and pick a subdomain, say
myhome.dyndns.example.org, and register their IPv6 prefix. I then
configure my registration server to accept updates from that v6 prefix
for subdomains of myhome.dyndns.example.org on a TOFU basis. All the
user then has to do is add regserver.dynsdns.example.org as their
_dns-update._tcp.myhome.dynsdns.example.org SRV record on their home
network, and presto, all their devices can now register themselves in
global DNS.

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 15:19:04 -0400

Sure, but there are privacy implications to that approach.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 19 Jul 2018 21:21:25 +0200

> Sure, but there are privacy implications to that approach.

Yeah, I'm assuming that things going into global DNS are public by
default...

-Toke

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 15:47:52 -0400

Indeed.   But I don't think we can assume that the DNS SRP stuff goes into
is always public.