Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)

Abtin Keshavarzian <abtink@google.com> Sat, 19 December 2020 05:25 UTC

Return-Path: <abtink@google.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 597E83A0EC8 for <dnssd@ietfa.amsl.com>; Fri, 18 Dec 2020 21:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 injm704QWj12 for <dnssd@ietfa.amsl.com>; Fri, 18 Dec 2020 21:25:52 -0800 (PST)
Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 848E13A0EC6 for <dnssd@ietf.org>; Fri, 18 Dec 2020 21:25:52 -0800 (PST)
Received: by mail-qv1-xf2c.google.com with SMTP id l14so2037133qvh.2 for <dnssd@ietf.org>; Fri, 18 Dec 2020 21:25:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=otKpZ4ah3ilWcNX80oZagg/tVfkHqNtXTtE7Nj8wYVc=; b=sTz4heuDGm2zZtEBvlo9i4NJF71OLEK2AaPh+v/inXf2tWik4wFBOrf4bpzhCr2a+s DUjIzUQPtIUoKe0vYm8eEvn3ABq9+wEhm48sO2IkJLbVY6JdjybYO0IxKeUU6Jl2PRv3 Y7R9Er+LQlYUNS6rsaKY7feRsb4ihV8QLb2aQ6YTFq0C78U7wuo4zPY2TDuDSBI96XZQ rFDoaGdWRBo2x3sFZ0dPtIngITR6j15RU8k4Vx1oKr1VBdM+C+qeAshuCn7/e7M7wdTY lz4tsTq6f2298rr9ljmoFR3lZq6YpKevWbLAr8tM/qdVCAQun7xVzP5YTmK3WwHGScvt FOlA==
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=otKpZ4ah3ilWcNX80oZagg/tVfkHqNtXTtE7Nj8wYVc=; b=IdS5ST9CT0ugyPTh/ikjsOwAfYOIVw7sw9IxcN5wDyJteW7DqwkhacJicsvk4pjT2/ PMlTFp6kVOyakjaN+R4e18qPr6W09aQxeX86jW/ETJ0G5x9WNiW+/Gf3YlaxOhzSd1Ps 1t6fq/APPxhrHqbVHDH/wiWSolBaAkVD4yOtMdVp2MOpamn/wgEbA7TihwCtajEtgrYR 2lCpn44u58Xvggkwk7Bf4urHQPJww3qkoGt9NdEYjUCGU7dYQd1Jugm/xfYHeSXjmPPc 4d9vWs/SOIwma7qjEr94hpkqbO7O2OMdItG/qojqNfTXd9n8rc1k4aOHHOScO+cH6EaU W3ng==
X-Gm-Message-State: AOAM5331AnzkkNYsCOmb1fhzAhrPxKNtq7Uj9pkecIKy9xyon1kw4cr8 9O2C1yUL0EcRgO7o0oeOy+sFeOX2XcIScBAd4TVRJQ==
X-Google-Smtp-Source: ABdhPJz7eGFbJdYaNMO/IxuvKXqzbzGTN6XLWUnaZdbmUQ169RfOkT0boSShkxzzEXqqLurqdbB7WX4+UCexsaxwARA=
X-Received: by 2002:ad4:4426:: with SMTP id e6mr8281610qvt.51.1608355551208; Fri, 18 Dec 2020 21:25:51 -0800 (PST)
MIME-Version: 1.0
References: <CACce4dTbWCVwBityepJpb5FF4Rv43+DUev_0Ka+rVT9exZrJzA@mail.gmail.com> <031C980F-D8B6-4051-8DC0-D8417FDBBD0F@fugue.com> <CACce4dQZ708aaMdvmwhEurHDSdFAvLbzwpDWz=viig_2cX75Dw@mail.gmail.com> <680A60B6-BD88-475E-91ED-48F23036A7C8@fugue.com> <CAJ5Rr7bDSMv1uPDPXppG9e4OUEU7oriK9tVKD20=P3Kgb2q=0g@mail.gmail.com> <741BC8D6-CFEF-453B-8F89-A6B102A37DAA@fugue.com> <CAJ5Rr7Yw33y2k=wo-ZXzFNP77=bucRcr2LxJxf+98e5oqK+fsw@mail.gmail.com> <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com>
In-Reply-To: <6B728DF0-5EE8-4EE6-9E95-98EF4D03D865@fugue.com>
From: Abtin Keshavarzian <abtink@google.com>
Date: Fri, 18 Dec 2020 21:25:40 -0800
Message-ID: <CACce4dToa2+FiYgzp5AvZjO7-UfHy5VSSZ4ED+PkHMVPBZTQAA@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Kangping Dong <wgtdkp@google.com>, DNSSD <dnssd@ietf.org>, Jonathan Hui <jonhui@google.com>, Rongli Sun <rongli@google.com>
Content-Type: multipart/alternative; boundary="0000000000004dfc9a05b6ca75d2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/BsZbJjoFTSmvvq-LbHDQj3xoBKA>
Subject: Re: [dnssd] SRP Update - removing individual services (draft-ietf-dnssd-srp-06)
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 19 Dec 2020 05:25:54 -0000

Thanks Ted for very quick draft 7.
I read it through. It's clear and overall looks great. Thanks :)

One question/suggestion on section "2.3.1.2 Service Description
Instruction".
I like this added text:

> if there is no "Add to an RRset" SRV RR, then there is an existing
> SRV RR on the name specified in the "Delete all RRsets from a
> name" update that to a hostname for which there is a Host
> Description Instruction in the SRP Update, and there is a KEY RR
> on that name which matches the key with which the SRP Update was
> signed.

This is ensuring that a client is only allowed to remove service instances
that were previously added by the client itself.

I was considering this (corner-case) situation:
- Suppose a client sends an SRP update message to remove a service and add
a new one.
- Server checks the msg and it is all ok, so it sends a response
- But somehow the response is dropped and the client does not get it.
- Client then retransmits the same SRP update message (with remove and
add).
- Now on the server, the corresponding SRV RR (associated with the service
instance) no longer exists (since it was removed from the first update msg).
- I think in this case, we still want the server to consider the second SRP
Update as valid.

So considering the RRset for the service instance name being removed (for
which we have "Delete all RRsets from a name" with no follow-on "Add to an
RRset" SRV RR):
- if SRV RR do exists on server, we require server to verify that it was
added by same host and key.
- but if it does not exist, the server would be ok with it (basically just
ignore the delete of the non-existing RRset), and consider the SRP update
msg valid.

Does it sound ok?

-------

I also found two small typos:

1) In section 2.3.1.1 (Service Discovery Instruction) last bullet point,
- ... is an "Delete an RR from ... -> is a "Delete an RR from

2) Right before section 6.2
... credentialsto to update ... -> credentials to update

Thanks,
Abtin.

On Fri, Dec 18, 2020 at 3:01 PM Ted Lemon <mellon@fugue.com> wrote:

> On Dec 18, 2020, at 9:23 AM, Kangping Dong <wgtdkp@google.com> wrote:
>
> Sounds good, thanks! Looking forward to the 07 draft!
>
>
> Not sure if you guys are on the mailing list, so FYI I have updated the
> document:
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-07
>
>
>
>