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

[Tim Wicinski <[e-mail]>]

I've read this draft and I support its adoption.   One thing to add to the
document once it's adopted that any DNS naming involving _underscore names
addresses the new BCP from DNSOP draft-ietf-dnsop-attrleaf

Tim


On Thu, Jul 19, 2018 at 7:55 AM, Ted Lemon <[e-mail]> wrote:

> The service registration domain is its own domain, not one of th link
> domains. Disambiguation is done in the UI. If there are two services in two
> different domains with the same name otherwise, these would appear in the
> UI with the same name, annotated with the link name. SRP names would follow
> the same convention.
>
> I think this is talked about in the service discovery broker document.
>
> On Thu, Jul 19, 2018 at 7:32 AM Tom Pusateri <[e-mail]> wrote:
>
>> And I think this is a general problem to solve for unicast updates, not
>> necessarily a SRP thing.
>>
>> For instance, while the discovery proxy separates IP subnets which a
>> unique subdomain to avoid collision, using regular unicast update to a
>> discovery proxy doesn’t know about IP subnet subdomains and uses a shared
>> namespace. The unicast name collision problem exists there too.
>>
>> I haven’t read the mDNS relay spec in detail enough to know if it
>> collapses the namespace or abides by the IP subnet subdomain separate
>> namespaces.
>>
>> But this may be something Stuart already solved. I’m just not aware of
>> the solution.
>>
>> Thanks,
>> Tom
>>
>>
>> On Jul 18, 2018, at 11:34 PM, Tom Pusateri <[e-mail]> wrote:
>>
>> Speaking of name changes, you may need to handle name collision in a
>> special way. Since devices can’t see other devices names, they can’t easily
>> create unique names. So if there are 10 light bulbs from the same vendor
>> all starting to register the instance name “light bulb”, the first will
>> succeed and the others get YXDOMAIN. The second one will realize the name
>> is taken but not know how to necessarily create a new name that is unique.
>> The tenth light bulb might go through 9 iterations before generating a
>> unique name. The traditional name collision avoidance mechanism with mDNS
>> of incrementing a numerical suffix doesn’t work very well when you don’t
>> know how many there are.
>>
>> It might be better to suggest a random suffix instead of a numerical one
>> or some other mechanism of generating unique names from the beginning. But
>> then they won’t look human readable so I don’t know if that is a
>> consideration.
>>
>> Thanks,
>> Tom
>>
>>
>>
>> On Jul 18, 2018, at 10:30 PM, Ted Lemon <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>>
>>>> Yes, that’s the correct behavior.
>>>>
>>>> On Wed, Jul 18, 2018 at 9:30 PM Tom Pusateri <[e-mail]>
>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>> 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 <[e-mail]> 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 <[e-mail]> wrote:
>>>>>>
>>>>>> Hm, you're right, that's never stated explicitly.
>>>>>>
>>>>>> On Wed, Jul 18, 2018 at 12:48 PM, Tom Pusateri <[e-mail]>
>>>>>> 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 <[e-mail]> 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 <[e-mail]>
>>>>>>> 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 <[e-mail]>
>>>>>>>> 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 <[e-mail]>
>>>>>>>> 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 <[e-mail]> 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/ae53618d8231733701ccdda4d33669
>>>>>>>> 2a529c9f6b...5c85181881b84ed1132d544e157df8da85874597
>>>>>>>>
>>>>>>>> On Mon, Jul 16, 2018 at 6:42 PM, Ted Lemon <[e-mail]>
>>>>>>>> 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 <[e-mail]>
>>>>>>>>> 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 <[e-mail]> 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 <[e-mail]
>>>>>>>>>> > 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 <[e-mail]> 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 <[e-mail]>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Jul 16, 2018 at 5:27 PM, Toke Høiland-Jørgensen <
>>>>>>>>>>>> [e-mail]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ted Lemon <[e-mail]> 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
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> dnssd mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> dnssd mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> dnssd mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> dnssd mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>> <https://www.ietf...org/mailman/listinfo/dnssd>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dnssd mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dnssd mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>
>> _______________________________________________
>> dnssd mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>
>>
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>
>