Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt

Ted Lemon <mellon@fugue.com> Thu, 19 July 2018 11:51 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 7DAD9131058 for <dnssd@ietfa.amsl.com>; Thu, 19 Jul 2018 04:51:39 -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 Aivl7UADpSjf for <dnssd@ietfa.amsl.com>; Thu, 19 Jul 2018 04:51:36 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 212B7131093 for <dnssd@ietf.org>; Thu, 19 Jul 2018 04:51:36 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id q19-v6so6802648ioh.11 for <dnssd@ietf.org>; Thu, 19 Jul 2018 04:51:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pz8fSjzyPrigB4Q6wg75Ob6zai+oJ1MU2IcbHborFz8=; b=NVktB/G5syMN6ATrxpl9XLimC5NiAxD9uKjVOikSyi4T5GWJPiDk5uv6mY4JECu8Uz QjTOCs0jjWJpSP+FW1TtYH8cLPK8MsIj7c8flHU/+Bw8KzDcqV31F5IaH3YljCM3YnvX +S58wfcji6rQI5NzIS7ge1DsiPNRNxIJ9dJ+AQbNNye83r/ZcIY0e2P2rzb1X6IGKjX8 uY9hZOF1cmHTuvcAlOSq7s7J8+QeQ9Vh5sh5Rtyz4AstoTdYK7eV08YfWXaxqkeltEE0 MP3Sla+zwrS4NDtDyBRdA4J9jFpDJdkVY8D1upeqgyFsy30l3OnATpYDtPOVukxbIYgE K++A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pz8fSjzyPrigB4Q6wg75Ob6zai+oJ1MU2IcbHborFz8=; b=gSUOgX0vPIbA/6kOhq5j4O9T5lmvqTBwzXK9g02OZYIaHY0wpRPIAvwZ3hkBd/eVud Uy+Lfa56mLyW7TIveZlaAuiWb/RpvKQCLiOMmvhXb4ZYRuPRLzrqjpbq1+/ulSiULOaB f49UzUAwuvu7m3jpUoKefGgHQYL+n7YNKPbYJ6rXdgcR0Ub0mVVsDvLFiMvkjHH1HBGg AIUxYYpObzkjr6txxfuq/OV5jdRa73d0heuDRBpjtVQKpggbxzr1ny1xg4W21GPIZho9 UNIJ1uWefMeuq8sxdZeSdq8nlGYlDkZQeO69K/kJsvVhEGTJhl+t71HKJHl/yG9awI7V mG2Q==
X-Gm-Message-State: AOUpUlGJM4H4GT+2dVJoNaFUQwKKH6/phfjIPhvykPTiMgNGidHn52jX /MFcyPegckYeH2dH/t9SVsZoz3U0lRKE7uZKvtzu5YDXK48=
X-Google-Smtp-Source: AA+uWPydU20lw48lyLhVQbeAF7sHh/16bngVxMj7OCEgSVGgG6Bkl9i+uzKQK58O8xEUUWmaBkM2b50Mipv2fKA/oHg=
X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr8186840ioc.45.1532001095421; Thu, 19 Jul 2018 04:51:35 -0700 (PDT)
MIME-Version: 1.0
References: <153168722035.21892.2695151923270049902.idtracker@ietfa.amsl.com> <CAPt1N1mYtPRxP6F-JwKbWey3r_vSaNP5srbkf314gdjfdNe8mw@mail.gmail.com> <87d0vn7b5t.fsf@toke.dk> <CALX6+rAjz2FtsQkhNyp=xYjXovUJUMN5Bg5iRHSWzMTJaZtCjg@mail.gmail.com> <CAPt1N1kODz72aHwF0z-uhYo4tojwsLEQJwLyzP8zeUYXduFkyQ@mail.gmail.com> <87a7qq6fdk.fsf@toke.dk> <CAPt1N1k59CM8WG4HoqXkG-crUEJbk+KNppX_pgkVFdwbSxNDpw@mail.gmail.com> <CAPt1N1khnMaRE2oe5WEQmonB8AJcLeBm=OB=i1trbEuc=XiL5Q@mail.gmail.com> <B88554CD-2117-44CC-ACA0-F5ACB3F48F88@bangj.com> <CAPt1N1=42Wum5x0s4dJZUB1t2i7g-UUJwcmWKQV5HMM5mAYyQQ@mail.gmail.com> <0542F0E1-88BB-4EF5-9897-CB608E5792C9@bangj.com> <CAPt1N1mrr=od-HBEDoS+Bs7fHuHj1Kc0HU-+6+NvhCyWDywYLg@mail.gmail.com> <CAPt1N1nFj5DpkRepLQ=Jmk=Spx87tNcfUMGyJRuAT=26givYKw@mail.gmail.com> <8BC77FD3-B2E6-4980-A315-7595D250C49E@bangj.com> <CA15413D-D7FB-4923-9B51-A824FF6598D5@bangj.com> <3D4620BB-19AA-4190-8F9E-76A613661CC8@bangj.com> <CAPt1N1=MjxTvzRZmrY7btR0NDoa3R9bzp4+wiaq2onUGqQi3XA@mail.gmail.com> <2931BCE2-75B0-48BB-8F0C-7FDF7B51376D@bangj.com> <A08B1A77-0F6B-4A5B-8671-05EA14B4E104@bangj.com> <CAPt1N1nYCH616Jn7V9Bb_QsrASpy3g2P77hJFvqP681JfZaK5Q@mail.gmail.com> <A24B2575-CCEE-4921-819F-B8E3CD60F128@bangj.com> <CAPt1N1kJQeGfOLXZBH4TSDqW+e8TcG=MpTxJhdszUXZHQP0W=A@mail.gmail.com> <CAPt1N1kZz4jyJBU_0T-jC6ZRtNTuRbUS9E533SjE=_E7DwCCkw@mail.gmail.com> <A5A866F8-938F-42FB-AB41-D8AB4C7C0066@bangj.com> <CAPt1N1kcW8-Em2xx4h8C8cWa9a_oTXeV8MV529_UwPqZjmX0Ew@mail.gmail.com> <E1528FFE-BFBE-46BF-AAFB-78B264F7ECD9@timwattenberg.de>
In-Reply-To: <E1528FFE-BFBE-46BF-AAFB-78B264F7ECD9@timwattenberg.de>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 19 Jul 2018 07:51:24 -0400
Message-ID: <CAPt1N1m0-zmpnfCXo=NJwgUh=jMqVHzhhAZKigEQ+ZZSXD=7Sg@mail.gmail.com>
To: Tim Wattenberg <mail@timwattenberg.de>
Cc: Tom Pusateri <pusateri@bangj.com>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000016b390057158cd30"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/L3eKZiqi_Xtivbt2WRY_f4k_A7w>
Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt
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, 19 Jul 2018 11:51:49 -0000

Yes, the way this would work is that you would have to delete your ptr
 record and at least the SRV and TXT records on the service instance name
it points to. You would sign this with the KEY that is on the service
instance name. This could be authenticated using that key.

On Wed, Jul 18, 2018 at 10:47 PM Tim Wattenberg <mail@timwattenberg.de>
wrote:

> Ted,
> you said that deleting a service instance is not covered by the draft, I
> can see how a short lease time could mimic that functionality.
>
> However if we allow any DNS update operation on the PTRs besides adding a
> record, wouldn’t that actually still require checking the “ownership”?
> Otherwise a service could update another services’ lease time and by that
> “delete” the other service.
>
> On 18. Jul 2018, at 22:30, Ted Lemon <mellon@fugue.com> wrote:
>
> Depends on how the name change happens, but sure.   If a device has a
> name-change UI, it could use a very short update lease time, but the server
> might override it.   I guess we could define an SRP delete message that
> deletes all or part of a registration.
>
> On Wed, Jul 18, 2018 at 10:17 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>
>> So if a device changes it’s name, the old one could be around for a while
>> along side the new name.
>>
>> That might be confusing.
>>
>> Tom
>>
>> On Jul 18, 2018, at 10:06 PM, Ted Lemon <mellon@fugue.com> wrote:
>>
>> Okay, I've pushed fixes for the last couple of issues you guys brought
>> up.   I used _dnssd-srp._tcp instead of _dns-update._udp, but that's up for
>> debate.
>>
>>
>> https://github.com/StuartCheshire/draft-sctl-service-registration/commit/ce15160933b458a2da2346b6181ad89ed0ff1e11
>>
>> On Wed, Jul 18, 2018 at 9:36 PM, Ted Lemon <mellon@fugue.com> wrote:
>>
>>> Yes, that’s the correct behavior.
>>>
>>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <pusateri@bangj.com> wrote:
>>>
>>>> Yeah, that needs to be more explicit.
>>>>
>>>> If you try to do a delete, does the server send REFUSED?
>>>>
>>>> Thanks,
>>>> Tom
>>>>
>>>> On Jul 18, 2018, at 8:27 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>
>>>> You can't delete anything from a service name.   Maybe we need to say
>>>> that more explicitly.   Right now the protocol doesn't allow a service to
>>>> delete itself; only to add itself.   The assumption is that the service
>>>> will not know in advance that it is leaving the network, so service entries
>>>> get garbage collected, rather than being explicitly deleted.   Compare to
>>>> DHCPRELEASE in the DHCP protocol, which is pretty useless.
>>>>
>>>> On Wed, Jul 18, 2018 at 7:40 PM, Tom Pusateri <pusateri@bangj.com>
>>>> wrote:
>>>>
>>>>> You might not need a new KEY record for the PTR but you may need to
>>>>> follow the instance of the PTR to a KEY record to make sure you have
>>>>> permission to delete the PTR record.
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> On Jul 18, 2018, at 7:37 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>>>>>
>>>>> Tim and I were talking and we were wondering if one client could
>>>>> delete the PTR record for a service instance that another client created?
>>>>> Seems like it’s not protected and could be a denial of service attack? So
>>>>> you might need a KEY record the PTR record.
>>>>>
>>>>> Tom
>>>>>
>>>>> On Jul 18, 2018, at 1:08 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>>
>>>>> Hm, you're right, that's never stated explicitly.
>>>>>
>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <pusateri@bangj.com>
>>>>> wrote:
>>>>>
>>>>>> I don’t see anywhere in the document where the anycast update method
>>>>>> relies on UDP.
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>> On Jul 18, 2018, at 12:27 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>>>
>>>>>> Of course, you still have a very good point in that the anycast
>>>>>> update method relies on UDP, so sending the key multiple times isn't
>>>>>> desirable.   But I also don't see a way around this.   We could have the
>>>>>> server replicate the key, I guess.
>>>>>>
>>>>>> On Wed, Jul 18, 2018 at 12:25 PM, Tom Pusateri <pusateri@bangj.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Just saw this in Section 2: "By requiring the use of TCP, the
>>>>>>> possibility of off-network spoofing is eliminated”. So requiring TCP is
>>>>>>> already handled.
>>>>>>>
>>>>>>> Searching for _dns-update._udp.<domain> still seems odd but that’s
>>>>>>> been going on for a while a presume.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>>
>>>>>>> On Jul 18, 2018, at 12:15 PM, Tom Pusateri <pusateri@bangj.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Looking in the IANA registry, dns-update isn’t assigned for TCP. So
>>>>>>> either you search for _dns-update._udp.<domain> and use TCP or you
>>>>>>> register _tcp.
>>>>>>>
>>>>>>> And while you could use an EDNS(0) OPT RR to set the maximum UDP
>>>>>>> packet size larger than 512, you probably wouldn’t want to set it larger
>>>>>>> than the MTU and 1480 isn’t big enough for 3 KEYs plus other records.
>>>>>>>
>>>>>>> Tom
>>>>>>>
>>>>>>> On Jul 18, 2018, at 12:05 PM, Tom Pusateri <pusateri@bangj.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> If you are adding more KEY records, you will certainly exceed the
>>>>>>> UDP update size of 512 bytes. The draft doesn’t mention transport but maybe
>>>>>>> this should be restricted to TCP.
>>>>>>> The draft does mention searching for the update server using _dns-update._udp.<domain>.
>>>>>>> But then it won’t be able to use UDP for updates.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Tom
>>>>>>>
>>>>>>> On Jul 17, 2018, at 4:12 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>>>>
>>>>>>> Tim pointed out that we need to protect the Service Instance Name as
>>>>>>> well as the Host Description with a KEY record, because FCFS naming has to
>>>>>>> protect both the service description and the host description.   Here are
>>>>>>> the changes:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration/compare/ae53618d8231733701ccdda4d336692a529c9f6b...5c85181881b84ed1132d544e157df8da85874597
>>>>>>>
>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>>>>
>>>>>>>> The question of whether we update RFC6763 is basically "is there
>>>>>>>> text that is in RFC6763 that is no longer correct because of this
>>>>>>>> document."  I think the answer is no.
>>>>>>>>
>>>>>>>> On Mon, Jul 16, 2018 at 6:41 PM, Tom Pusateri <pusateri@bangj.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Ok, just checking. So given that 6763 semi-defines service
>>>>>>>>> registration protocol as DNS Dynamic Update, should this document claim it
>>>>>>>>> updates 6763?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Tom
>>>>>>>>>
>>>>>>>>> On Jul 16, 2018, at 6:01 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>>>>>>
>>>>>>>>> The title of RFC 6763 is DNS-Based Service Discovery.   So I tried
>>>>>>>>> to harmonize the document toward that—did I miss something?
>>>>>>>>>
>>>>>>>>> On Mon, Jul 16, 2018 at 5:59 PM, Tom Pusateri <pusateri@bangj.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> How is DNS-Based Service Discovery different from DNS Service
>>>>>>>>>> Discovery?
>>>>>>>>>>
>>>>>>>>>> Is this meant to distinguish from RFC 6763?
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Tom
>>>>>>>>>>
>>>>>>>>>> On Jul 16, 2018, at 5:46 PM, Ted Lemon <mellon@fugue.com> wrote:
>>>>>>>>>>
>>>>>>>>>> BTW, the current version of the document on github now includes
>>>>>>>>>> fixes for all the points that have been raised other than the ones I said I
>>>>>>>>>> wasn't going to fix:
>>>>>>>>>> https://github.com/StuartCheshire/draft-sctl-service-registration
>>>>>>>>>>
>>>>>>>>>> On Mon, Jul 16, 2018 at 5:29 PM, Ted Lemon <mellon@fugue.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <
>>>>>>>>>>> toke@toke.dk> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Ted Lemon <mellon@fugue.com> writes:
>>>>>>>>>>>>
>>>>>>>>>>>> Why can't it be just a Host Description? Might be useful for a
>>>>>>>>>>>> device
>>>>>>>>>>>> that just wants to register its name but doesn't (currently, or
>>>>>>>>>>>> ever)
>>>>>>>>>>>> advertise any services...
>>>>>>>>>>>>
>>>>>>>>>>>> Good question.   What does the working group think?   :)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> dnssd mailing list
>>>>>>>>>> dnssd@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> dnssd mailing list
>>>>>>>>> dnssd@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dnssd mailing list
>>>>>>> dnssd@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dnssd mailing list
>>>>>>> dnssd@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dnssd mailing list
>>>>>>> dnssd@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>> <https://www.ietf...org/mailman/listinfo/dnssd>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> dnssd mailing list
>>>>>> dnssd@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dnssd mailing list
>>>>> dnssd@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>
>>>>>
>>>>>
>>>>
>>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>