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

Ted Lemon <mellon@fugue.com> Wed, 04 July 2018 13:45 UTC

Return-Path: <mellon@fugue.com>
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 CFF81130F70 for <dnssd@ietfa.amsl.com>; Wed, 4 Jul 2018 06:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 jxhz26K8Mt4V for <dnssd@ietfa.amsl.com>; Wed, 4 Jul 2018 06:45:44 -0700 (PDT)
Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C916130F88 for <dnssd@ietf.org>; Wed, 4 Jul 2018 06:45:43 -0700 (PDT)
Received: by mail-qk0-x244.google.com with SMTP id u62-v6so2866153qkf.9 for <dnssd@ietf.org>; Wed, 04 Jul 2018 06:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHORzgOUJLRgKeTXYL12pbtDqt6+sEY1h9shWcPpE9M=; b=bf3umpM6bjK4GWe7JosJ4hd84EyXHS+eny7w22XSeyLD04rvlwkLf086NmatN/Sbnl Xaeo66I2bhvNczfphsHCq8ILCfgU7fPuH6ckTNQxjw5huWbIVTdVCH6Vs7aW2VIBak25 Bt204zkliNg2rzY0mHtYOWTxaj6gn6XQG9kyIrYy8Or0BsXGHYset1J68N/0Vzv3KvX8 xmmGxXbCUrTPPO5u4toRqIlmJ7EJBcu9WGXMP/dWbkqB2VJv7oZxYB7oxE7j+4aeyupc iNewJCiN4EpkfgHMqD+2IBuBIvbRDhlffow62CER5nRC7R3UrGRvPvSALygroGBtSOqe +avA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DHORzgOUJLRgKeTXYL12pbtDqt6+sEY1h9shWcPpE9M=; b=N8goKksh1VyOKEg3/Auzn61V3c8p287TXumQJ7VBlpx+rVbw7QPdx/BRht+hNkA8eR M0U4QnzZcZ4dxs4pjbgXwG/2JA33CyXz9vbMaiTUoxb1OKXfsHcmsT/K8cvm84eAqWwA F+MYjhxE3peXGzVVOo7JFNCN4XXjSkpMYawi8fF6I86hPKSQv4qfM82ytU94s1dAn1Bc hSm/XYdR6GBomgUtQVNpQBumVVBiAyMrKCyvr2oXX8RpSNMFLLTP/Q1GwJTW6hj09Cpe xg0UZX/f7meY89a3yml8JVZ2RXxAaK6F2vDUQTnWk7t+j1yqURDjO3omez2bFrdhZjnr pCbA==
X-Gm-Message-State: APt69E1TL5xuzl8y/+JKmLJCjEcBQ82ZGDvNmGDZE4GCJtgXWQKHu+Nn Bi5o/4DOlX0eq/wUYxzWtOGGh9Mb7rA=
X-Google-Smtp-Source: AAOMgpeiz/ZOqzvg2GmvnvZypjeinvreJGEAAsgX9F/D63GnV5FASl74m6Rg0S2TmmpGPz1I5eCj/g==
X-Received: by 2002:a37:65d8:: with SMTP id z207-v6mr1551008qkb.81.1530711942484; Wed, 04 Jul 2018 06:45:42 -0700 (PDT)
Received: from [10.0.100.12] (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id g18-v6sm2717710qtg.59.2018.07.04.06.45.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 06:45:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.13.1\))
From: Ted Lemon <mellon@fugue.com>
In-Reply-To: <87lgare65v.fsf@toke.dk>
Date: Wed, 4 Jul 2018 09:45:40 -0400
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
X-Mailer: Apple Mail (2.3445.100.13.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/iGLGH9jZJSH3WvMAsaeKlyuVpNw>
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: Wed, 04 Jul 2018 13:45:47 -0000

On Jul 4, 2018, at 4:50 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> David Schinazi <dschinazi@apple.com> writes:
> - It is not clear how to find the server to register with: Section 2
>  refers to RFC2136 and RFC3007 for the DNS Update mechanism, and to
>  RFC6763 Section 11 for information on how to discover the zones to
>  attempt registration in. So from my best reading of this, the client
>  should discover the relevant zones, then just send its signed updates
>  to any authoritative server for those zones. However, this prevents
>  implementing the registration logic as a proxy (as I'm currently
>  doing). So I feel like there should be a SRV lookup in there
>  somewhere? I seem to recall Stuart telling me that this is indeed
>  specified somewhere, but my google fu is failing me right now, and in
>  any case it's not clear from the draft how this process is supposed to
>  work.

I thought it was specified somewhere too, but it doesn't seem to be explicitly stated in RFC 6763.   In general, RFC 2136 says that any server authoritative for the zone can be sent a DNS update for that zone, and is directed to preferentially send updates to the master if it is reachable.

That said, Apple's implementation looks for a _dns-update._udp.<domain> SRV record, and it might make sense to specify that explicitly.   Also, this has been specified in such a way that the client need do minimal work before firing off the update.   Stuart and I have talked about using anycast to make this a single-transaction service in the default case, which would be particularly nice for low-power devices.   I didn't have time to spec that out in this version, but it's definitely an intended feature.

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

As for the address-based ACL, that's in fact what I'm using in the prototype.   Another way to do it would be to have an anycast listener in, for example, each homenet router, which only accepts updates from the local wire.   This listener would add its signature to the message and forward it in an encapsulation.   If we allow for a two-packet exchange for service registration, which I think is desirable, this may be worth specifying.   In an LLN I don't think it would be hard to do—it could be done at the edge of the mesh.

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

> - 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.   However, this breaks the LLN single-exchange use case, so I think there's an argument that it should be required on LLNs.   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.   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.

> [1] I'll add that since the -01 draft now says that the update should
>    always be for .local, how is a registration server supposed to know
>    which domain a client wants to register in? By source address only?

I think that in a network where there is more than one domain in which a registration could occur, something like that would indeed be required.   My base assumption in writing this text (which Stuart hasn't seen yet, because he's on vacation) is that in most cases where this will be used, either there will be only one registration domain, or else the link to which the service is attached will be sufficient to decide what domain to use.