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 Høiland-Jørgensen <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
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… David Schinazi
- [dnssd] The DNSSD WG has placed draft-sctl-servic… IETF Secretariat
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Ted Lemon
- Re: [dnssd] The DNSSD WG has placed draft-sctl-se… Toke Høiland-Jørgensen