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

[Abtin Keshavarzian <[e-mail]>]

Hi Ted,

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).

Overall in my opinion, the design seems very reasonable and good.

There are couple of questions and some thoughts around them that I'd like
to sync with you. They are all related to the SRPL Host message.

My understanding is that during routine operation, whenever an SRP update
message from an SRP client is successfully processed, the peer (which
processed it) will embed the SRP update message in an SRPL Host (within an
SRPL Host Message TLV) and will send it to all partner peers. This sounds
like a good model to me for syncing the peers during routine operation.

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.

The other possibility is to assume/require that all SRPL SRP servers
use/accept the same lease intervals (I personally prefer the former way
better since it adds more flexibility).

---------

The other questions are related to the use of SRPL Host messages during
initial synchronization.

The SRP server should have all the registered service entries in its
database but it may not necessarily keep the SRP  update messages that
registered them. But in the SRPL Host message we want to embed an SRP
update message.

My first thought was that we can have the SRP server save the last update
message from each SRP client, but then services may be registered at
different times and in many different SRP update messages. So I guess this
may not work in all cases.

My next thought was that the SRP server peer should be able to construct an
SRP update message based on the info it has, but there are some tricky
situations with this.

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.

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 appreciate your thoughts on these.

Thanks,
Abtin.