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

[Ted Lemon <[e-mail]>]

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

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

FWIW, I think the main issue with low-power devices is that when you are in
a sleepy mode, you don't want to turn the radio on too often. From that
perspective, as long as we know when to turn the radio on, I don't think
the actual time we turn it on matters much. There may be transports with
precise time-slice characteristics that would prevent this from working,
and they wouldn't be able to conform to this. We could make it a SHOULD and
explain this—devices that can't do this tend to be part of ecosystems like
Thread where there's an additional spec that can say how such devices
behave in that specific environment.


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

Yeah, I meant 65%-85%. DHCP uses 85%—I think that's generally a better
number than 75%. I think going much past that isn't a good idea, though—it
doesn't give you much of a window to survive temporary outages. Maybe 20%
variance is more than we need though. Probably 80-85% would be perfectly
adequate.


> 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 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 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.
>
>
> Personal thought: "Servers MUST have a minimum interval before which they
> will not accept" could be made a bit easier to parse, e.g. "Servers MUST
> have a minimum interval for accepting Refreshes. Such messages that arrive
> before that time MUST be silently ignored."
>

Yes, that's a good clarification.