Re: [dnssd] Please review substantive changes to Update Lease

[Tim Wicinski <[e-mail]>]

On Thu, Feb 2, 2023 at 1:26 PM Chris Box <[e-mail]> wrote:

> Everyone,
>
> In this latest draft, several things have changed in the text that will
> impact implementations. So PLEASE take a look and decide whether you are
> happy with them. We need your input to confirm if this gets your seal of
> approval, or if you'd like to see some changes. Either option is fine, but
> I'd like to get a version of this draft shipped before we meet in 116.
>
> To make it easier, I'll identify them below. The full draft-04 text is at
> https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-04.html.
>
> Section 4.1 now has this, committed in
> https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/commit/0e0da091040b56d6abc6223277819ab770f31591
> <https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/pull/18/files>
>
> When sending an initial update, the requestor MUST delay the initial
>> transmission by a random amount of time across the range of 0-3000
>> milliseconds, with a granularity of no more than 10 milliseconds. This
>> prevents synchronization of multiple devices of the same type at a site
>> upon recovery from a power failure. This requirement applies only to the
>> initial update on startup: since renews include a random factor as well,
>> any synchronization that occurs after such an event should quickly
>> normalize.
>
>
> My personal thought on this, wearing no hats, is to wonder how realistic
> is 10ms accuracy for a low-power device? I understand the rationale, which
> is to permit 300 different slots in which the transmission could occur.
> However I wonder if the granularity ought to be a softer requirement. Views
> from implementers needed.
>

I figure folks are also considering the more and more movement to PTP on
devices in general.


> Section 5.2 has this, committed in
> https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/pull/18/files
>
> In order to prevent records expiring, requestors MUST Refresh resource
>> records after approximately 75% of the original lease has elapsed. This
>> interval MUST be adjusted randomly by +/-10% so that after a network
>> restart, subsequent Renews do not remain synchronized across devices
>> affected by the power failure.
>
>
> Personal thought again: does this mean the client code should aim for a
> range of 65% to 85% of the original lease? Or does it mean 67.5% to 82.5%?
> I don't think it really matters either way, but it would be good to be
> clear about our intention. We should also ask ourselves if there are valid
> reasons why refresh should occur later than 85%.
>
>
I saw Ted mention 65%-85% and that gives a broader range.

>
> There now follow some changes that avoid using SHOULD on its own (i.e.
> without discussion of why you might need to deviate from it). These are all
> committed in
> https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/pull/20/files
>
>
> Section 5.2.1
>
>> In doing so, the requestor includes in the Refresh message all existing
>> updates to the server, including those not yet close to expiration, so long
>> as at least one resource record in the message has elapsed at least 75% of
>> its original lease. If the requestor uses UDP, the requestor MUST NOT
>> coalesce Refresh messages if doing so would cause truncation of the
>> message; in this case, the requestor should either send multiple messages
>> should use TCP to send the entire update at once.
>
>
>
This sentence seems wonky:

 If the requestor uses UDP, the requestor MUST NOT coalesce Refresh
messages if doing so would cause truncation of the message;
in this case, the requestor should either send multiple messages should use
TCP to send the entire update at once.

Maybe "or should use TCP to send the entire update"?


Finally, section 8's security considerations are rewritten and greatly
> expanded. The commit was
> https://github.com/dnssd-wg/draft-ietf-dnssd-update-lease/pull/19/files.
>
> Section 8 <https://rfc-editor.org/rfc/rfc2136#section-8> of [RFC2136
>> <https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-04.html#RFC2136>]
>> describes problems that can occur around DNS updates. Servers implementing
>> this specification should follow these recommendations.
>> Several additional issues can arise when relying on Update Lease. First,
>> a too-long lease time is not much different than no lease time: the records
>> associated with this lease time will effectively never be cleaned
>
>
"Several additional issues can arise when relying on Update Lease."

could this be "when relying on an Update Lease"?



> up. Servers implementing Update Lease should have a default upper bound on
>> the maximum acceptable value both for the LEASE and KEY-LEASE values sent
>> by the client. Servers MAY provide a way for the operator to change this
>> upper limit. We recommend that the default values for these limits should
>> be 24 hours and 7 days, respectively.
>> The second issue is that a too-short lease can result in increased server
>> load and a failure to persist data subject to such a short lease. Servers
>> implementing Update Lease MUST have a default minimum lease
>
>
This sentence reads odd to me (but this could be me).

The second issue is that a lease which is too short can result in increased
server load and a failure to persist data for such a lease.



> interval that is acceptable. We recommend a minimum of 30 seconds for both
>> the LEASE and KEY-LEASE intervals.
>> There may be some cost associated with renewing leases. A malicious (or
>> buggy) client could renew at a high rate in order to overload the server
>> more than it would be overloaded by query traffic. This risk is present for
>> regular DNS update as well. Servers MUST have a minimum interval before
>> which they will not accept a Refresh for a recently updated record. Such
>> messages MUST be silently ignored.
>> Some authentication strategy should be used when accepting DNS updates.
>> Shared secret [RFC8945
>> <https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-04.html#RFC8945>]
>> or public key signing should be required. Keys should have limited
>> authority: compromise of a key should not result in compromise of the
>> entire contents of one or more zones managed by the server. Key management
>> strategy is out of scope for this document, however. An example of a key
>> management strategy can be found in [I-D.ietf-dnssd-srp
>> <https://www.ietf.org/archive/id/draft-ietf-dnssd-update-lease-04.html#I-D.ietf-dnssd-srp>],
>> which uses "first come, first-served naming" rather than an explicit trust
>> establishment process to conver update permission to a set of records.
>
>
>
Key management strategy is out of scope for this document, however.

Can we drop the "however"?  It just is.


thanks for grinding this out Ted


tim



>