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

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Dec 2020 18:35:51 -0500

Thanks, Abtin!

To be quite frank, using a zero lease time was a quick hack, which only does well if the only use case is that the whole device is going offline and hence wants to take all its services offline. This is a fairly common use case in mDNS, but I hadn’t really thought about the fact that your use case also makes a lot of sense, and isn’t properly addressed by my quick hack.

For the use case you are proposing, I think the approach we agreed on in the off-list conversation you are referring to indeed makes more sense. One slight clarification, from your second point in your summary: the lease time would be the normal lease time.

What would be different would be that a delete would appear in the message with no following add. This is sufficient to delete the old service. It would be permitted under the conditions you describe. The new service that was added, and the host record being renewed, would have the new lease time; the old service would be immediately removed.

Does that make sense??

> On Dec 17, 2020, at 5:55 PM, Abtin Keshavarzian <[email-masked]> wrote:
> 
> Hi all,
> 
> Would like to summarize some questions/discussions we had on an email exchange (with Ted, Kangping, Jonathan, and Rongli) related to SRP and the process for removing individual service(s).
> 
> First a quick (personal) note, I have been reading the RSP spec recently. I think it is a very well-written and easy-to-read/follow. So I want to give thanks and kudos to guys who were involved (Ted, Stuart, others). 
> 
> -------
> 
> There may be use-cases where we want to remove a previously added/registered service. The question is how to realize this.
> 
> I think this can be done by sending two SRP Update message:
> - First one removing all services/host-info (with lease time zero)
> - Followed by another SR Update re-adding services (excluding the ones removed) and host-info
> 
> However, it'd be good if this can be done more efficiently with a single SRP update message. 
>  
> - Currently SRP considers the message to be valid if it includes zero or more Service Discovery and Descriptions, and exactly one Host Description.
> - The idea is to extend spec to allow Update msg to include Service Discovery/Description (without Host Description) with lease time zero to use for removing services.
> - The update message needs to include the key RR and be signed.
> - The server would accept the removal of service only if the key matches the previously registered key associated with the host and the service, and if the signature is valid.
> 
> Thoughts?
> 
> Abtin.

---

From: Abtin Keshavarzian <[email-masked]>
Date: Thu, 17 Dec 2020 14:55:07 -0800

Hi all,

Would like to summarize some questions/discussions we had on an email
exchange (with Ted, Kangping, Jonathan, and Rongli) related to SRP and the
process for removing individual service(s).

First a quick (personal) note, I have been reading the RSP spec recently. I
think it is a very well-written and easy-to-read/follow. So I want to give
thanks and kudos to guys who were involved (Ted, Stuart, others).

-------

There may be use-cases where we want to remove a previously
added/registered service. The question is how to realize this.

I think this can be done by sending two SRP Update message:
- First one removing all services/host-info (with lease time zero)
- Followed by another SR Update re-adding services (excluding the ones
removed) and host-info

However, it'd be good if this can be done more efficiently with a single
SRP update message.

- Currently SRP considers the message to be valid if it includes zero or
more Service Discovery and Descriptions, and exactly one Host Description.
- The idea is to extend spec to allow Update msg to include Service
Discovery/Description (without Host Description) with lease time zero to
use for removing services.
- The update message needs to include the key RR and be signed.
- The server would accept the removal of service only if the key matches
the previously registered key associated with the host and the service, and
if the signature is valid.

Thoughts?

Abtin.

---

From: Abtin Keshavarzian <[email-masked]>
Date: Thu, 17 Dec 2020 16:40:41 -0800

Thanks Ted,

Yes, that makes sense and sounds simpler. :)
I think it also allows multiple adds and removes, all, to happen from the
same SRP update message.

Let me try to describe some details:

- In "Service Description Instruction", we allow a "Delete all RRSet from a
name", with possibly no follow-up adds.
- When a service is being deleted, we can consider allowing KEY RR "Add to
an RRSet" for instance name to be optionally included, to have the server
keep the instance name reserved (if desired).  Does it make sense?
- In "Service Discovery Instruction" I think we need to allow delete as
well (I guess "Delete an RR from an RR set" for PTR RR)?
- We continue to require SRP Update msg to always include exactly one "Host
Description".

Does this all sound good/reasonable? Anything I may have missed?

Sorry I think I misunderstood the earlier discussion. Somehow I associated
the remove to require registering with zero lease time.

Thanks,
Abtin.

On Thu, Dec 17, 2020 at 3:35 PM Ted Lemon <[email-masked]> wrote:

> Thanks, Abtin!
>
> To be quite frank, using a zero lease time was a quick hack, which only
> does well if the only use case is that the whole device is going offline
> and hence wants to take all its services offline. This is a fairly common
> use case in mDNS, but I hadn’t really thought about the fact that your use
> case also makes a lot of sense, and isn’t properly addressed by my quick
> hack.
>
> For the use case you are proposing, I think the approach we agreed on in
> the off-list conversation you are referring to indeed makes more sense. One
> slight clarification, from your second point in your summary: the lease
> time would be the normal lease time.
>
> What would be different would be that a delete would appear in the message
> with no following add. This is sufficient to delete the old service. It
> would be permitted under the conditions you describe. The new service that
> was added, and the host record being renewed, would have the new lease
> time; the old service would be immediately removed.
>
> Does that make sense??
>
> First a quick (personal) note, I have been reading the RSP spec recently.
> I think it is a very well-written and easy-to-read/follow. So I want to
> give thanks and kudos to guys who were involved (Ted, Stuart, others).
>
> -------
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Dec 2020 21:07:01 -0500

On Dec 17, 2020, at 7:40 PM, Abtin Keshavarzian <[email-masked]> wrote:
> - In "Service Description Instruction", we allow a "Delete all RRSet from a name", with possibly no follow-up adds. 

Yes.

> - When a service is being deleted, we can consider allowing KEY RR "Add to an RRSet" for instance name to be optionally included, to have the server keep the instance name reserved (if desired).  Does it make sense?

We could allow this, but KEY RRs are large, so we might prefer not to.

> - In "Service Discovery Instruction" I think we need to allow delete as well (I guess "Delete an RR from an RR set" for PTR RR)?

Yes, and the RR has to be pointing to a Service Description Instruction which is also being deleted.

> - We continue to require SRP Update msg to always include exactly one "Host Description". 

Yes.

> Does this all sound good/reasonable? Anything I may have missed?

It sounds fine. I’m curious what others think about this.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Dec 2020 08:20:49 -0500

On Dec 17, 2020, at 11:02 PM, Kangping Dong <[email-masked]> wrote:
> I'd like to summary my understanding of what current SRP-draft-06 is doing/allowing:
> We can add services separately. like, we can add "service-1" and in the first SRP update and "service-2" in the second SRP update.
> We can only remove all the services together with its host because "exactly one Host Description Instruction" is a MUST for each SRP update.
> But the spec seems, is not enforcing this behavior:
> Therefore, SRP servers MAY remove all
> service instances pointing to a host when a host is removed, even if
> the SRP client doesn't remove them explicitly.
> If we cannot remove individual service without removing the host, should the "MAY" be a MUST?
> Otherwise, there may be no efficient way to clean up the service until the lease time expires.

Yes, I think this is an oversight in the specification. What my implementation actually does is to remove all the entries when we see a “lease 0” update with a valid host record that’s signed with the right key.

> To remove a service registration, the SRP client retransmits its most
> recent update with an Update Lease option that has a LEASE value of
> zero.
> Does it remove only the services in my most recent update or all services I have ever registered?

My implementation does the latter. It tracks what services are registered per host.

> This is what
> I was confused about and thought we can remove individual service. As we cannot remove individual service,
> I think we don't need to retransmit the most recent update: It may be more efficient to always transmit a
> SRP update with only Host Description Instruction and zero lease time. Thoughts?

Yes.

> For the current use model, I agree it will work for most cases and removing individual service may be rare
> (even there are, it can be done with a "removing all" and an add). So I don't have a strong opinion to support it.

I don’t think we really have enough data to say. In the interests of being general, I think it’s probably worth specifying how to remove individual services. This is what I’d originally intended—I did the “lease time 0” hack because it was expedient, not because it was the right thing to do.

I’ll spin a -07 later today if I have time that makes this change and addresses your other concerns from above, and then if you’re willing, you guys can review my changes and see if they are sufficient.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Dec 2020 18:01:18 -0500

On Dec 18, 2020, at 9:23 AM, Kangping Dong <[email-masked]> 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/ <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 <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 <https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-07>

---

From: Abtin Keshavarzian <[email-masked]>
Date: Fri, 18 Dec 2020 21:25:40 -0800

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 <[email-masked]> wrote:

> https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/
>
> https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-07
>
>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 19 Dec 2020 07:16:00 -0500

> Does it sound ok?

Yes, that’s a great correction. Thanks!

---

From: Ted Lemon <[email-masked]>
Date: Sat, 19 Dec 2020 07:17:29 -0500

Actually, on second thought, maybe the right thing to do is check for the KEY RR and not the SRV RR. If the key matches, the delete is okay. If there are no records on the name, the delete is okay.

---

From: Kangping Dong <[email-masked]>
Date: Fri, 18 Dec 2020 12:02:34 +0800

Hi Ted,

I'd like to summary my understanding of what current SRP-draft-06 is
doing/allowing:

   1. We can add services separately. like, we can add "service-1" and in
   the first SRP update and "service-2" in the second SRP update.
   2. We can only remove all the services together with its host because
   "exactly one Host Description Instruction" is a MUST for each SRP update.

> If we cannot remove individual service without removing the host, should
the "MAY" be a MUST?
Otherwise, there may be no efficient way to clean up the service until the
lease time expires.

> Does it remove only the services in my most recent update or all services
I have ever registered? This is what
I was confused about and thought we can remove individual service. As we
cannot remove individual service,
I think we don't need to retransmit the most recent update: It may be more
efficient to always transmit a
SRP update with only Host Description Instruction and zero lease time.
Thoughts?

For the current use model, I agree it will work for most cases and removing
individual service may be rare
(even there are, it can be done with a "removing all" and an add). So I
don't have a strong opinion to support it.

BRs,
Kangping

On Fri, Dec 18, 2020 at 10:07 AM Ted Lemon <[email-masked]> wrote:

> - In "Service Description Instruction", we allow a "Delete all RRSet from
> a name", with possibly no follow-up adds.
>
>
> Yes.
>

---

From: Kangping Dong <[email-masked]>
Date: Fri, 18 Dec 2020 22:23:18 +0800

BRs,
Kangping

On Fri, Dec 18, 2020 at 9:20 PM Ted Lemon <[email-masked]> wrote:

> Yes, I think this is an oversight in the specification. What my
> implementation actually does is to remove all the entries when we see a
> “lease 0” update with a valid host record that’s signed with the right key.
>
> I have ever registered?
> I don’t think we really have enough data to say. In the interests of being
> general, I think it’s probably worth specifying how to remove individual
> services. This is what I’d originally intended—I did the “lease time 0”
> hack because it was expedient, not because it was the right thing to do.
>
> I’ll spin a -07 later today if I have time that makes this change and
> addresses your other concerns from above, and then if you’re willing, you
> guys can review my changes and see if they are sufficient.
>
>

---

From: Kangping Dong <[email-masked]>
Date: Sat, 19 Dec 2020 23:11:12 +0800

Hi Ted,

Thanks for creating the 07 draft so quickly! The change overall looks good
to me and I agree we should check the KEY RR rather than the SRV RR.

I have some questions when reading the related sections:

1. in 2.2.5.5.2. Removing some published services
<https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#section-2.2.5.5.2>,
we have:

> The second alternative is to send a normal SRP update, but as in the first
> alternative,

including a Service Discovery Instruction and a Service Description that
> *delete* the service being removed.

Should the "*delete*" be "*replace*"?

2. What's the use case of supporting multiple TXT RRs?
in section *2.3.1.2. Service Description Instruction
<https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-service-description-instruc>*,
we have:

> zero or more "Add to an RRset" TXT RRs,
>

Are there real use cases that we need more than one TXT RRs? What is the
expected behavior
for the advertising proxy to publish this service with multiple TXT RRs? (I
think DNS-SD requires
a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated to
form a new TXT RR?
If there is no such use case, should we require a single TXT RR? It will be
easier to implement on both
client and server side and consistent with DNS-SD. thoughts?

BRs,
Kangping

On Sat, Dec 19, 2020 at 8:17 PM Ted Lemon <[email-masked]> wrote:

> Actually, on second thought, maybe the right thing to do is check for the
> KEY RR and not the SRV RR. If the key matches, the delete is okay. If there
> are no records on the name, the delete is okay.
>

---

From: Kangping Dong <[email-masked]>
Date: Sat, 19 Dec 2020 23:34:07 +0800

Sorry, another question :)

In section 2.3.1. Validation of Adds
<https://www.ietf.org/archive/id/draft-ietf-dnssd-srp-07.html#name-validation-of-adds>,
we have:

 SRP Updates consist of a set of *instructions* that together add or remove
> one or more services.

Each instruction consists either of a single add, a single delete, or a
> delete optionally followed by an add.

When an instruction contains a delete and an add, the delete MUST precede
> the add.

What is the use case of the "single add"? To my understanding,  the "delete
+ add" pattern is
for resetting the service to our current SRP update. So the "single add"
pattern is for updating
the existing service, for example, adding one more AAAA RR, right?

I think, for most SRP clients, it will be more convenient for them to track
all IP Addresses and
always update with the whole IP addresses list rather than depending on
this "update" model
and register the addresses separately. The server, I think can also be
simplified. Thoughts?

Another issue with this sentence is that, the Service & Host Description
Invalidation requires:

> exactly one "Delete all RRsets from a name" RR,

Seems disallowing the "single add" pattern?

BRs,
Kangping

On Sat, Dec 19, 2020 at 11:11 PM Kangping Dong <[email-masked]> wrote:

>> The second alternative is to send a normal SRP update, but as in the
>> first alternative,
>
> for the advertising proxy to publish this service with multiple TXT RRs?
> (I think DNS-SD requires
> a single TXT RR, is it correct?) Should multiple TXT RRs be concatenated
> to form a new TXT RR?
> If there is no such use case, should we require a single TXT RR? It will
> be easier to implement on both

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 19 Dec 2020 08:05:46 -0800

On Sat, Dec 19, 2020 at 7:34 AM Kangping Dong <[email-masked]> wrote:

>  SRP Updates consist of a set of *instructions* that together add or
>> remove one or more services.
>
> What is the use case of the "single add"? To my understanding,  the
> "delete + add" pattern is
> I think, for most SRP clients, it will be more convenient for them to
> track all IP Addresses and

I believe the "single add" refers to a given instruction in the SRP Update.
Section 2.3.1.1 Service Discovery Instruction allows exactly one "Add to an
RRSet".

Maybe the "Validation of Adds" section name should be updated given that
the draft now supports "remove-only" instructions?

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 19 Dec 2020 08:07:44 -0800

> are no records on the name, the delete is okay.

I agree on checking for the KEY RR.

--
Jonathan Hui

---

From: Jonathan Hui <[email-masked]>
Date: Sat, 19 Dec 2020 08:14:36 -0800

> client and server side and consistent with DNS-SD. thoughts?

RFC 6763 Section 6.8 Service Instances with MultipleTXT Records
<https://tools.ietf.org/html/rfc6763#section-6.8> discusses this. However,
the end of the referenced section also states:

   Future protocol designs should not follow this bad
   example by mimicking this inadequacy of the LPR printing protocol.

So I guess the question is whether we can/should mandate this future going
forward in SRP?

--
Jonathan Hui

---

From: Kangping Dong <[email-masked]>
Date: Sun, 20 Dec 2020 13:51:16 +0800

> <https://tools.ietf.org/html/rfc6763#section-6.8> discusses this.
> However, the end of the referenced section also states:
>
> Thanks Jonathan, I missed that section.

> forward in SRP?
Exactly. I would prefer we explicitly disallow multiple TXT records for
SRP.

BRs,
Kangping

On Sun, Dec 20, 2020 at 12:14 AM Jonathan Hui <[email-masked]> wrote:

> <https://tools.ietf.org/html/rfc6763#section-6.8> discusses this.
> However, the end of the referenced section also states:
>

---

From: Abtin Keshavarzian <[email-masked]>
Date: Sat, 19 Dec 2020 23:38:14 -0800

> are no records on the name, the delete is okay.

Thanks Ted. I agree. This sounds good (and simpler).

On Sat, Dec 19, 2020 at 9:51 PM Kangping Dong <[email-masked]> wrote:

>> So I guess the question is whether we can/should mandate this future
>> going forward in SRP?
>>
>> --
>> Jonathan Hui
>>
>>