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

Toke Høiland-Jørgensen <> Thu, 05 July 2018 17:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF82F130F66 for <>; Thu, 5 Jul 2018 10:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4sW6HhwtnkJw for <>; Thu, 5 Jul 2018 10:02:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4533130F52 for <>; Thu, 5 Jul 2018 10:02:11 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=20161023; t=1530810126; bh=44phiMOOg3CD4HyOt9Amjas2VQKEp+tE0WwM0TNXVXc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PA5c38S0cHk7td5gtDE48kKpCktGr1IolHaOr4GKK4WL0RovkW31MSSEB9FII6g+J PhmyZVKj1+mkGSUHwL5dbEr4L/7HKQa/u1vqICvoaj9wVWM9nNgIohGwLdIyx2ZgrY AnBhaMXsUlXZ+zhwKjdaMf6wpID41O0s+9nk54qB9AZaajxFBbjWxIWbFMS60eyFMx ikKHQNJvO7x27hrHbMgkwB64i01CtQpaDupko/Ykco6CfWy6QTYUJ+SdIeulVVSEIN eTRUcKWk9FmOTehk7LLax3ln30/dPFQXNCl5JI77jiTZxCuqhJG76KXbiOIk1dcd7u dgF04SV6yCKxQ==
To: Ted Lemon <>
Cc: David Schinazi <>, dnssd <>
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 05 Jul 2018 19:02:04 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jul 2018 17:02:27 -0000

Ted Lemon <> writes:

> That said, Apple's implementation looks for a
> _dns-update._udp.<domain> SRV record, and it might make sense to
> specify that explicitly.

Yeah, I think Stuart explained this to me at some point. But I'm not
sure if "ask Stuart" is sufficiently discoverable, so mentioning it in
the document might be a good idea ;)

>> - Address-based ACLs: Obviously, in most cases a client should only be
>>  able to perform registration if it is actually on the right network.
>>  Firewalling off the ports from outside the relevant networks is a way
>>  to ensure this, but it is somewhat of a crude tool. For one, it
>>  prevents a single registration server / proxy from serving multiple
>>  networks[1]. For another, it prevents a use case where a client is only
>>  allowed *initial* registration (when the key is first cached) from
>>  inside the network, but is allowed to subsequently update the same
>>  record from anywhere. This is useful to, for instance, have my laptop
>>  maintain even when visiting another
>>  network.
> That's a good point—I hadn't thought about enabling the off-site
> update. There are security implications of that, of course: it could
> be a foothold for an informed attacker. I'm not convinced that it
> should be permitted by default, and indeed in the homenet scenario,
> for example, I would say that it should not be permitted by default.
> There may be scenarios where it makes sense.

Sure, by all means hide it behind a big "I know what I'm doing" button,
or something. I just don't want the standard to rule out the possibility

>>  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?

>> - 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?

> That said, this is existing technology, which is widely deployed, and
> often deployed in very tiny devices. I don't think it's hard to
> implement, and I am a little surprised that you think it is.

I said "harder", not "hard" ;)

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

> Is it really that it's hard to implement, or is it that you don't
> think it's important, don't know how to implement it, and therefore
> would prefer not to? That's a perfectly valid position to take, but
> it's not what you said.

I think it's not important enough to put in the effort to implement it,

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...