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

Ted Lemon <mellon@fugue.com> Mon, 09 July 2018 22:29 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 1FBB1130E80 for <dnssd@ietfa.amsl.com>; Mon, 9 Jul 2018 15:29:07 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 aYhLQ-7JVAUX for <dnssd@ietfa.amsl.com>; Mon, 9 Jul 2018 15:29:03 -0700 (PDT)
Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 449FF130DC3 for <dnssd@ietf.org>; Mon, 9 Jul 2018 15:29:03 -0700 (PDT)
Received: by mail-qt0-x243.google.com with SMTP id b15-v6so16771970qtp.11 for <dnssd@ietf.org>; Mon, 09 Jul 2018 15:29:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w7T2h3BwcwKaXCsyr+f3l81v15EBoIQjhzSdsMALehM=; b=yEy12WnqEre3ARjQ+Td1j+98UtMrRnj0wAGt7zKyNx3ah+L+ba0AepsBBYxSYECHaU BSdUGC7fDSx3fwBFeAj3yuy8DHfemQv/Of760qraGGGTB4nzpHBpM5Pyu3P3EPAK6qzl 2EQOB0z9QyZYR+KvFiBYf+inhtD2r031WYBm6Z/Jko7FX5w/a6kwXFHkLgjelRZTUEYr z5fdvNherZ6KkeexDimUBX7z3IZ/n2KWR3UYrGzY3Wro0Q7UofVFvd6e6sADqmtiIddW GD9gYO/FBME+g/f1x/dTKglIIS/tRRRY2x+ECCTAXRE52rNUnBjPFH8IBwnm4I3HSDah wkYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w7T2h3BwcwKaXCsyr+f3l81v15EBoIQjhzSdsMALehM=; b=KRQ4fn+im35CZ4Df1y7TrRmF1DaTZq1Ru584VzZAk3XgpzscqP2vEKZvWMIETPEIok EZY4dI0i2bdfSTqfQYl+NGLhe0voJeFEYGadZ/H+KfCS+PDAIoTVPhxsI8EADxa2/KYA qNJ0ZOfF9IQJ6ZV8oNEGVHkW4Wosa0mHiQbQWlGPAiqYTwQHuaIsu2VwhQqh7PI17gmt K1KR5RQ6Gv3G7/0xuMXU+DS3zlMIPgtaXuGIfjJXqS/9a7kDNlVJZDDzrl2iFQbyui0f n7UxBNS3oq6LVENhoICgsimtwFuNxd9/48hstYK9C+yKWpqAaa7Y1sa1TX60zYfr9FZe YwaA==
X-Gm-Message-State: APt69E32Jmoo4dn8HTxBvGdqgC2Sv3Qom8pyuGRevZITgbBMsn7rIgMv 5oT/tQWjzz+mVcvTPsIOAi/KSGIsS4c=
X-Google-Smtp-Source: AAOMgpd5oxvmZp4cqhuFsRLZp9TKbl2rl0fjD8Shku5uMwLO09emz5sChBAsRg9VAjoDlTHeZVJg5A==
X-Received: by 2002:aed:2518:: with SMTP id v24-v6mr20909334qtc.151.1531175342281; Mon, 09 Jul 2018 15:29:02 -0700 (PDT)
Received: from [10.0.100.12] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id d39-v6sm13339093qta.60.2018.07.09.15.29.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 15:29:01 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <A667C059-FEBB-4159-A053-0B7AFE35F5FD@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D7156CD1-6D13-461B-9E08-F924CC2D0EB3"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.15\))
Date: Mon, 9 Jul 2018 18:29:00 -0400
In-Reply-To: <87in5td3ar.fsf@toke.dk>
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
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> <87in5td3ar.fsf@toke.dk>
X-Mailer: Apple Mail (2.3445.100.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/s5WpKKsHX_UTEe7kpkhUGyKxnf0>
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.27
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: Mon, 09 Jul 2018 22:29:08 -0000

On Jul 5, 2018, at 1:02 PM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 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 ;)

Agreed.

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

Sure.

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

I think there are three cases we should consider here:
Homenet
Campus net
LLN
In the case of Homenet, I think TCP works fine, except that we can expect to see LLNs in most homenets going forward.   So TCP doesn't entirely work fine, and managing this edge case is tricky.   We'd need to define a heuristic for how the LLN edge router(s) validate updates from the LLN.

Actually, I think the Campus net case is pretty much the same.   So okay, that means that if we can figure out how to do one thing on LLNs and another thing in all other cases, maybe that's the answer.   I'd just as soon avoid DNS cookies—they don't add any value over TCP in this case as far as I know.   We'd have to forbid 0RTT, because the whole point of using TCP is to validate that the IP address that sent the update can receive a reply.

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

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

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.   But we need to figure out how to address this.

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