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:21 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 428F5131192 for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 14:21:21 -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 EDNrOHGPUfSK for <dnssd@ietfa.amsl.com>; Thu, 12 Jul 2018 14:21:18 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 680A8131193 for <dnssd@ietf.org>; Thu, 12 Jul 2018 14:21:18 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id y10-v6so14696226ioa.10 for <dnssd@ietf.org>; Thu, 12 Jul 2018 14:21:18 -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=jJHrngFdQenEfFJg/lLo86nGh0rsezfo36BmXy1/hN8=; b=egNzB7w8ZCDGz3hY7CpZV9RZtt/His8/MOrX+PVHl+lekk+YjaFjfUClGzPVPmDtOq ddzHSqb0P/kKGdWmeGmjltp7CvLsjGKG7otOvn9uFX4j+vzLRdYquKn4PZzjLA92XMtd eP7SqoeYxnWqqeg+B067J+lHTmc0F5hazkhUwKZm/OaJj9MVr38tqgHg8fhKwF5995D1 aTtqOX93oB6EZOS0OHPkQM9fbgC0lnmxCBLwQysWoyzg0SRqgfBBdgKMq8CslHkc4qwb QUOgI6Vt8yCEj/QLcuBggpoDT8Svdmvc+y+q1PdfyLAXoUkmd28tgZ7jzVWbIMi7rkC8 MJlw==
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=jJHrngFdQenEfFJg/lLo86nGh0rsezfo36BmXy1/hN8=; b=eIS7v+NdbiSM7p+IRhQdyX/xx0GiHNY6CslOBP0wuJ+cSBdCm+s2AeY6f8ZssN0lJp xrZe+q4CP295XKJY6Eg0m5hNEV29aRfeoqI0COZr4upbDJFVM55e6vMUcYPw7SV36Wot Af4T098JkjsECioVvxsqwHcuuUQUcH5ObTMAdamqp0ywz/RGQTceM1KGtPa0mHaixlZY faCdLEwnrL2OxWTbbzwPQ9TwAmQ5wtmG2RXfQpFP06EkrDgAPEDdlczychnSRCllAfcw dDEiaYUpoIIOAKCZ34Fn/HF0AAwgAGK0D7D3UIHknpW8cX4JJKmgA9eg0eat739YxAoA CGfQ==
X-Gm-Message-State: AOUpUlGuyRbnVMwyF0SxMgiIEtyZDdDmsJ7O/iDDcQyDBCKjz7hRFjTs s5jSsW/z7j1U1jKEmd/e7IXJLvBlRiPIWquZVv+4jQ==
X-Google-Smtp-Source: AAOMgpd4zmTuExy6iVJvEBQsYzialubwKoa/oQNfxCfScp1RZdpoRXYKw260L4IlgvJ3NFBBe5Tve2eAr6aaL1Je8iw=
X-Received: by 2002:a6b:b387:: with SMTP id c129-v6mr9081665iof.32.1531430477649; Thu, 12 Jul 2018 14:21:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 14:20:37 -0700 (PDT)
In-Reply-To: <871sc8b2n9.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>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 12 Jul 2018 17:20:37 -0400
Message-ID: <CAPt1N1=npjQS-AyuxtZ3DGLJw12-MA1NZa633maXbJs98rEHUQ@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="0000000000009e75340570d3f145"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/fOPwOG19aQdHTgzt1QcavIVglh4>
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:21:22 -0000

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.

What I mean regarding .arpa is that mDNS literally just multicasts updates
to x.y.z.q.in-addr.arpa. over mDNS.   So it's completely bypassing DNS
delegation of authority.   This will work just fine as long as the server
processing the update is able to be authoritative for the subdomain of
in-addr.arpa corresponding to its address space.   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.   IOW, it has to be in-addr.local in
the update, but it can be in-addr.arpa in the zone.

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

> Ted Lemon <mellon@fugue.com> writes:
>
> > It seems like the client should just keep maintaining whatever records
> > it maintains. If the server doesn't take some updates, then the client
> > can just keep trying. Otherwise the client has to somehow model the
> > state of the server, which seems unnecessary.
>
> Yeah, agreed.
>
> > As for A and AAAA records, this is an open question: how to handle it.
> > Is it a problem to allow a client to update arbitrary A and AAAA
> > records? The restriction of only updating the one that corresponds to
> > the source address used to send the update is there because we have
> > some reasonable assurance that the client actually has that address.
> > We could have some hack where we use the neighbor table to notice that
> > several addresses are associated with the same layer 2 address, but
> > that seems like not what we want to do.
>
> Why is it a problem that a client registers other addresses for its
> A(AAA) records? As long as it can't update the addresses of another name
> it can't spoof that service; if it sets another device's address as it's
> own name, it is just spoofing itself? It could be a problem for PTRs, of
> course, but not for A(AAA)?
>
> Maybe this could also be something that is left up to the registration
> server as a matter of policy? An example policy could be "only 1 address
> per subnet per name" or something... But since a client can just
> generate an infinite number of new names, I'm not really sure that buys
> much either...
>
> > mDNS seems to just use .arpa. I don't know how/if that works, but I
> > definitely don't see how to make it work with the DNS protocol.
>
> Wait, don't see how to make what work with the DNS protocol?
>
> -Toke
>