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

Tom Pusateri <pusateri@bangj.com> Thu, 19 July 2018 02:17 UTC

Return-Path: <pusateri@bangj.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 34E2D130ED3 for <dnssd@ietfa.amsl.com>; Wed, 18 Jul 2018 19:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 KrrDebdhldeZ for <dnssd@ietfa.amsl.com>; Wed, 18 Jul 2018 19:17:47 -0700 (PDT)
Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3E9130FFA for <dnssd@ietf.org>; Wed, 18 Jul 2018 19:17:47 -0700 (PDT)
Received: from [25.56.120.46] (unknown [24.114.80.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E0776C93; Wed, 18 Jul 2018 22:15:54 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-510EEA27-D43D-4E2B-9644-A3DF19A918BF
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPhone Mail (16A5327f)
In-Reply-To: <CAPt1N1kZz4jyJBU_0T-jC6ZRtNTuRbUS9E533SjE=_E7DwCCkw@mail.gmail.com>
Date: Wed, 18 Jul 2018 22:17:42 -0400
Cc: dnssd <dnssd@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <A5A866F8-938F-42FB-AB41-D8AB4C7C0066@bangj.com>
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> <CAP t1N1=N=9UEb5Dm4AwV8GA5oJ=k4aVtCatPpgTwZ-dWf4zLgg@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>
To: Ted Lemon <mellon@fugue.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/rju0FxsN3zM4_ziUZKDguWtA8ns>
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 02:17:55 -0000

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