Subject: Re: [dnssd] SRPL: SRP replication (draft-lemon-srp-replication-00) - questions/ideas

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2021 14:48:16 -0400

On Sat, Sep 25, 2021 at 2:47 PM Abtin Keshavarzian <[email-masked]>
wrote:

> I have been reading the SRP replication draft (
> https://www.ietf.org/archive/id/draft-lemon-srp-replication-00.html) and
> the related RFCs (like DSO).
> 1) How can we sync the accepted lease and key lease intervals for the
> registered entries across SRP servers using SRPL?
>
> - The SRP update message itself contains the lease and key lease values,
> but these are what the SRP client requested (or wished to get).
> - The accepted lease intervals are included in the SRP update response
> that the original SRP server peer will send back to the SRP client.
> - I guess we may need a way to inform the accepted lease intervals from
> the peer to SRPL partner peers.
>
> One way I can think of is to add a new secondary TLV (e.g., SRPL Lease
> Intervals) as part of SRPL Host message.
>

I think this is correct—we need a lease time secondary TLV. If the server
policy restricts the lease to a smaller value, I think we just have to
accept the value that the original server accepted.

2) What to do with the signature in the SRP update message? The SRP server
> does know the public key of the SRP client (host), but it needs the private
> key to be able to do the ECDSA signing of the message, so cannot sign it.
>
> - One way around this is to make the signature optional in the SRP update
> messages which are embedded in an SRPL Host message. But I am not sure if I
> like this, since it (kind of) requires special/different treatment of SRP
> update messages in this case on a partner peer.
>

I think the answer here is to keep all of the messages that have affected
the current set of registrations for a specific host. I've done a sample
implementation of this, and it seems straightforward—whenever we get an
update, we reference the message both from the host and from the instances;
when an instance is deleted for whatever reason, that message is
dereferences, and at some point all the instances created by that message
are removed, at which point the message is collected. So at any time if we
want to replicate the full state of an SRP client to another SRP server
during synchronization, we just send all the messages we received, in order.

We probably want to include a time offset and accepted lease times in the
messages, rather than relying on TLV ordering to say which time goes with
which update message.

3) How to convey the remaining lease times for multiple registered services
> (from the same SRP client) to the partner peer in the SRPL Host and its
> embedded SRP update message?
>
> - An SRP client may register multiple services at different times (and in
> different SRP update messages).
> - So at the time of SRPL initial synchronization, services from the same
> host/client can have different remaining lease times.
> - We have "SRPL Time Offset TLV" in an SRPL Host message, but this seems
> to apply to the host and all the entries.
> - I guess we may need a way to be able to share the remaining lease times
> per service entry.
>
> One way I can think of (which may address both 2 & 3) is to use the SRPL
> Host message only during routine operation, and then during initial
> synchronization we define and use a new type of SRPL message with new TLVs
> (e.g. an SRPL Service TLV) to include all the info about the host and all
> of its service(s) in the TLVs.
>

 I think if we include accepted lease information as you suggested with
each update message, that solves this problem.

Thanks for doing this work—it's really helpful to have another implementor
noticing the things I missed. I completely forgot about the "multiple
updates" issue!

---

From: Abtin Keshavarzian <[email-masked]>
Date: Wed, 13 Oct 2021 14:05:56 -0700

Thanks Ted.

I agree and I think it all makes sense and good.

So we can change the SRPL Host Message TLV to have the following info:

   - Timeout field (`uint32_t`)  (similar to Timeout TLV)
   - Two `uint32` fields for Lease and KeyLease (accepted intervals by
   server).
   - Followed by "SRP Update message" itself.

Few smaller things to sync on:

In the SRPL Hostname TLV we assume the value (host name) is full DNS name
encoded in DNS wire format.

Related to DSO Inactivity timeout. In SRPL we use the default values (15
sec). But I think we assume that once we establish an SRPL session, it is
considered as an active ongoing operation (i.e., DSO session will stay open
and practically the inactivity timeout is always cleared).

Does it make sense?
Thanks,
Abtin.

On Wed, Oct 13, 2021 at 11:48 AM Ted Lemon <[email-masked]> wrote:

> 3) How to convey the remaining lease times for multiple registered
>> services (from the same SRP client) to the partner peer in the SRPL Host
>> and its embedded SRP update message?
>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Oct 2021 17:31:45 -0400

On Wed, Oct 13, 2021 at 5:06 PM Abtin Keshavarzian <[email-masked]>
wrote:

> Yup.

> encoded in DNS wire format.

Yes, I should have specified that. :)

> and practically the inactivity timeout is always cleared).

Yes. That should also be made explicit.

I realized just now that it's probably worth making clear that if we have
an update that adds an instance, and then later the instance is removed,
but the instance was added along with an instance that /wasn't/ removed, we
need to keep the message that removed the instance as well as the message
that added it, until the original instance expiry time. Right now my
instance deletes these records as soon as the host lease expires, but this
is incorrect—it should be saving them until the key lease expires.

---

From: Abtin Keshavarzian <[email-masked]>
Date: Wed, 13 Oct 2021 16:03:34 -0700

> is incorrect—it should be saving them until the key lease expires.

I agree. Good point.