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

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

Return-Path: <toke@toke.dk>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF82F130F66 for <dnssd@ietfa.amsl.com>; Thu, 5 Jul 2018 10:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sW6HhwtnkJw for <dnssd@ietfa.amsl.com>; Thu, 5 Jul 2018 10:02:12 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [52.28.52.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4533130F52 for <dnssd@ietf.org>; Thu, 5 Jul 2018 10:02:11 -0700 (PDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; 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 <mellon@fugue.com>
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
In-Reply-To: <AC270951-0AA4-45D0-9F1A-83067489BF27@fugue.com>
References: <153064569308.5111.7449468818446130425.idtracker@ietfa.amsl.com> <EB70166C-B64B-4509-909D-76978CA00A36@apple.com> <87lgare65v.fsf@toke.dk> <AC270951-0AA4-45D0-9F1A-83067489BF27@fugue.com>
Date: Thu, 05 Jul 2018 19:02:04 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87in5td3ar.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/tqk92S2B08Ui4cF3r0byuc4Y9c0>
Subject: Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jul 2018 17:02:27 -0000

Ted Lemon <mellon@fugue.com> 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 my-laptop.myhome.example.org 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
entirely.

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

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

-Toke