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

Ted Lemon <mellon@fugue.com> Thu, 12 July 2018 21:33 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 6C0EF13119A for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 14:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, 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 F8dYg3RjkjHV for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 14:33:10 -0700 (PDT)
Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9D006130E18 for <dnssd@ietf.org>; Thu, 12 Jul 2018 14:33:10 -0700 (PDT)
Received: by mail-io0-x22a.google.com with SMTP id l14-v6so19601374iob.7 for <dnssd@ietf.org>; Thu, 12 Jul 2018 14:33:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wJSGz8Q3w/rimRdcUFnzpUFhkLsOQF4e+h3OeEUFO9I=; b=uwc821Fo5k+TXRtxrEZCjhT5tj2cUPcsBKhBcz8Wm8H780bAfsCBMSdGVyub7FAc1e VSsFIjaVX7DSKgLtxK5BxMlp5tNEC3ufgqImJmZ/JgHN2OzFLgtdQmtMZajxOdQNMOGU 45kqKiJDvSzabz6Iu04JpqzljruFKhwIbDR/hOjAYDNQmXSXU/Xi99ZmvKoALuCcLuD5 OGDMhdqayFpTMOMR5rai8X9ervdWftQlT5Yn6XGAlAD9Z6rFLZOXphb9bcXv71nWIpgx jtDHThZOf3usXQ7KGK9U1iNE6vLmYqcrGtW0DLBXxABTarmHbKqi3legJZW6jIpfTFif AUYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wJSGz8Q3w/rimRdcUFnzpUFhkLsOQF4e+h3OeEUFO9I=; b=ZlWYd34oFOqsxO7KTH3EYmrGdlP2biFqyMIUwqKJXn5aDvuTHWVVY6dIF3et4E1FuL Xb0M9QCvJnAi1IHYtwetg+1wzEV63ZUVX+NZ6tUC28rTsQ1O+Nyi4vZt9wHsUgIgWl2E qQI4M/e9M5pYE6nTUlyqnWY3Zlo+luLFozKX3KyfcdaZrOxRy9jKI2b+Ighpmehc0n1o lpplgkLP0rHnU+hGh4oEil49dzvnr5RcBt25qL3YWn1hUfRtOlNoTNZIfqej7VuzHHNv VK5R880x9h98UkC33q0LjSYztdG5L1ktwEyiwGHfvQjJ7kiNrVsw9KXed2houe/eEB65 0xDg==
X-Gm-Message-State: AOUpUlEfqUOiizbV5zHfdfNDVggHjAss8atG+HGARhSvgp2NA0oXjg21 TA989QzTQ391Rk8n/SIIciq1aaLLWuvNBi6OnNvHiA==
X-Google-Smtp-Source: AAOMgpde8Dwx0qxABDLW7C3J4pbGorFIp6jIu/M/aO1H7KHM0A2F77xRw2kKZe+dDUwh7IPIMXYF5XLbgdCrYztZcPY=
X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr30342888ioe.85.1531431189987; Thu, 12 Jul 2018 14:33:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:32:29 -0700 (PDT)
In-Reply-To: <87tvp49mb6.fsf@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> <A667C059-FEBB-4159-A053-0B7AFE35F5FD@fugue.com> <87r2kbcl3h.fsf@toke.dk> <CAPt1N1=kNRiNLMEkSjMmcG+U5Bg6OACkQTAkO6t1b-rzYnza0w@mail.gmail.com> <87fu0obuua.fsf@toke.dk> <CAPt1N1=ktPp-T8fg17fAaT=FznDytnXr2N3Uz1rUL+En_QOKUA@mail.gmail.com> <874lh4bicx.fsf@toke.dk> <CAPt1N1mLA3knwxW0R9Ayb29Og4hh=y+6X9OaPSZW58noYv-4+A@mail.gmail.com> <871sc8b2n9.fsf@toke.dk> <CAPt1N1=npjQS-AyuxtZ3DGLJw12-MA1NZa633maXbJs98rEHUQ@mail.gmail.com> <87tvp49mb6.fsf@toke.dk>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 12 Jul 2018 17:32:29 -0400
Message-ID: <CAPt1N1kp+bt3bcrH9_V0R+M-_tVTH8GjUCj8vEueT7UDP++TOQ@mail.gmail.com>
To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>
Cc: David Schinazi <dschinazi@apple.com>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000013de220570d41c53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/7B3qZDIx6_mpQ2XPbxfLW9vIh6E>
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: Thu, 12 Jul 2018 21:33:12 -0000

Yes, this requires separate registrations for IPv4 and IPv6.   I think
that's okay.   What's a bit chancy is that it also means that if you have a
ULA and a GUA, you have to pick one, or do two updates.   As for NAT, I
think we have to assume that the network is not double-natted.   If it's a
homenet, that will be true.   If it's a campus network, that will be true.
 If it's a bunch of crappy routers plugged together, it's unlikely that
service registration will be available anyway, so we don't care.   Do you
buy that?   :)

On Thu, Jul 12, 2018 at 5:27 PM, Toke Høiland-Jørgensen <toke@toke.dk>
wrote:

> Ted Lemon <mellon@fugue.com> writes:
>
> > The only reason I think it would be a serious problem for a service to
> > register an IP address other than its own is that it could be used as
> > a way to wedge in an attack.
>
> Right. But if we want to protect against that we'd need to only allow
> registrations for the IP we are talking to; which means separate
> registrations for IPv4 and IPv6. And for v4 it would probably mean a
> requirement for on-link presence, since anything that is not on-link is
> likely to have at least one layer of NAT in-between...
>
> > The real sticky wicket is that you can't update two zones in the same
> > update, but that's not really what you were talking about.
>
> Ah, right, then it makes sense. I may have been ignoring this part of
> the spec in my implementation ;)
>
> -Toke
>