Internet DRAFT - draft-tllq-tsr
draft-tllq-tsr
Internet Engineering Task Force T. Lemon
Internet-Draft Apple Inc.
Intended status: Standards Track 秦 良 (L. Qin)
Expires: 5 September 2024 4 March 2024
Multicast DNS conflict resolution using the Time Since Received (TSR)
EDNS option
draft-tllq-tsr-04
Abstract
This document specifies a new conflict resolution mechanism for DNS,
for use in cases where the advertisement is being proxied, rather
than advertised directly, e.g. when using a combined DNS-SD
Advertising Proxy and SRP registrar. A new EDNS option is defined
that communicates the time at which the set of resource records on a
particular DNS owner name was most recently updated.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lemon & Qin Expires 5 September 2024 [Page 1]
Internet-Draft TSR EDNS option for mDNS March 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Current Behavior . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Time Since Received EDNS Option . . . . . . . . . . . . . . . 5
3. mDNS Registrar Behavior . . . . . . . . . . . . . . . . . . . 6
3.1. When sending an mDNS message . . . . . . . . . . . . . . 6
3.2. When processing an mDNS message . . . . . . . . . . . . . 6
4. mDNS querier behavior when processing an mDNS message . . . . 6
5. The effect of network latency on time computations . . . . . 7
6. Internal Handling of TSR data . . . . . . . . . . . . . . . . 7
7. Timeliness of Conflict Resolution . . . . . . . . . . . . . . 7
8. Legacy Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
9. When to Use TSR . . . . . . . . . . . . . . . . . . . . . . . 8
10. Registrant API considerations . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
13. Informative References . . . . . . . . . . . . . . . . . . . 9
14. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Unlike the Domain Name System [RFC1034], with its authority servers
and delegation of authority, Multicast DNS has no single source of
authority. Because of this, mDNS has a mechanism, conflict
resolution (Section 9 of [RFC6762]) for detecting and fixing
conflicts in mDNS advertisements.
The current goal of mDNS conflict resolution is to prevent a new
service being advertised from taking the place of an existing service
with the same name that is already being advertised. This goal,
however, assumes that the entity advertising an mDNS service is in
fact authoritative for that service. In the case of an Advertising
Proxy [I-D.sctl-advertising-proxy], this is not the case: the source
of truth for the service being advertised is an SRP
[I-D.ietf-dnssd-srp] client.
Lemon & Qin Expires 5 September 2024 [Page 2]
Internet-Draft TSR EDNS option for mDNS March 2024
On a link with more than one SRP registrar, an SRP client may
register with one SRP registrar, and then subsequently update its
registration on a different SRP registrar. Both SRP registrars may
be acting as advertising proxies. If so, the original server may
still be advertising the old SRP registration using mDNS. If the
information in the new SRP registration is identical to that in the
old registration, this is not a problem. However if some information
has changed (e.g., a new IP address has been added, or a TXT record
updated), then the new registration will be seen to be in conflict
with the old registration.
In the case of such a supposed conflict, the current behavior of mDNS
is for the older (stale) registration to win, and the newer (current)
information to be discarded. This behavior, which is entirely
correct for services that are advertising on their own behalf, is
exactly wrong when a service registration is being proxied.
1.1. Current Behavior
When a new service is to be advertised, the server that wishes to
advertise its service typically registers the service with a central
mDNS registrar on the host on which it is running. This mDNS
registrar may have an internal database of services already
registered, and may detect a conflict with one of those services.
This can be true whether the conflicting database entry is data for
which the mDNS registrar is authoritative, or data it has received
via mDNS and cached.
In the case of such a conflict, no network transaction is required:
the mDNS registrar detects it locally. It addresses the conflict in
one of two ways. The first alternative is that the mDNS registrar
will report the conflict to the server as an error, which the server
must fix. Alternatively, the server may have indicated that the mDNS
mDNS registrar should automatically choose a new name for it, in
which case the mDNS registrar does so automatically, without
notifying the server.
Once any locally-detectable conflicts have been resolved, the mDNS
registrar probes (see Section 8.1 of [RFC6762]) local network to see
if any other host has already registered a service the conflicts with
the proposed new service. If such a service is present on the
network, the mDNS registrar follows the same process previously
described, either reporting the error to the server or automatically
choosing a new name.
Lemon & Qin Expires 5 September 2024 [Page 3]
Internet-Draft TSR EDNS option for mDNS March 2024
The effect of this approach is that generally whichever server first
registers a service under a particular name wins. If a server comes
along later and registers the same service with conflicting
information, the newcomer’s information is rejected.
1.2. Problem Statement
The current behavior works well for services registering on their own
behalf. However, for example in the case of an SRP registrar, it
works poorly: an SRP registrar acting as an advertising proxy proxies
the contents of its registration dataset(s) using mDNS. The source
of truth for information in such datasets is whatever service has
registered with the SRP registrar, not the SRP registrar itself.
In the case of an advertising proxy proxying an SRP dataset, what we
want is not the oldest information, but the newest. When the SRP
client is able to continue registering with the same SRP registrar,
this works well: stale data is automatically removed and replaced
with current data. However, if more than one SRP registrar is
available, and for some reason the original SRP registrar with which
the registration was completed is still operating but no longer
reachable (e.g., in the case of a network partition), the SRP client
will wind up registering with a different SRP registrar. Similarly,
if the SRP service is being advertised using an anycast address,
there is no guarantee that the SRP renewal will be delivered to the
same SRP registrar.
When the SRP client registers with a different SRP registrar, the
behavior we get with the current conflict resolution approach is that
the SRP client will be given a new name, and both the old (stale)
advertisement (A) and the new (more recent) advertisement (A’) will
be discoverable as separate services.
This creates a new burden on consumers of such services: they need to
parse through the whole list of services of their type, using
metadata from the TXT record in the service instance data, if
possible, to determine that service A and service A’ are the same
service. If no such information is present in the TXT record, the
only way to determine that one of these two registrations is stale is
to attempt to use the advertised service, which may no longer be
reachable if, for example, the change that produced the conflict was
an IP address change. When the SRP lease for the stale service
expires, that service's advertisement will be removed, and the
service will no longer be discoverable under the original name, even
if the IP address hasn't changed.
Lemon & Qin Expires 5 September 2024 [Page 4]
Internet-Draft TSR EDNS option for mDNS March 2024
This document proposes an enhancement to the current conflict
resolution algorithm for mDNS, which allows an mDNS proxy to report
the time at which it received the registration it is newly
advertising. This is done using a new Time Since Received RR, which
is attached to the name of the registration.
2. Time Since Received EDNS Option
The Time Since Received (TSR) EDNS option references a specific RR in
the answer, authority or additional sections of an mDNS message.
This option specific to an owner name, not to an individual RRset.
When a service registration is successful, the mDNS registrar records
the wall clock time at which the registration request was received.
This may be the current time, or a time specified by a proxy service
that is doing the registration. This time is only recorded if the
service requesting the registration specifies it; otherwise, the time
of receipt is not recorded. The registrar also has the public key
that was used in the registration.
The TSR EDNS option consists of three fields: the RR offset (two byte
integer in network byte order), a key hash (32 bytes), and a time
offset (four bytes).
The RR offset points to the first name in a given section of the mDNS
Message for which the TSR is in effect. The first answer is at
offset 0, the second answer at offset 1 and so on. Or if there is
only one answer but also an authority record, the first authority
record is at offset 2. If following that record there is a record in
the additional section (including the OPT RR itself), that record
would be at offset 3. Questions can't have TSRs associated with
them, and hence the counting starts with the first answer, not the
first question.
If there are multiple records in the mDNS Message with the same owner
name, only one TSR option is emitted for that name, and it applies to
every RR in the mDNS Message with that owner name. It is not
possible in the SRP protocol for two updates at two different times
to contain records that apply to the same name.
The second field, the key hash, is an SHA-256 hash (TBD) of the
public key that was used to authenticate the SRP update that most
recently updated the RRs on the owner name to which the TSR option
applies.
Lemon & Qin Expires 5 September 2024 [Page 5]
Internet-Draft TSR EDNS option for mDNS March 2024
The TSR time offset field contains the difference, in seconds,
between the the time at which the TSR record is being generated and
the time of receipt for recorded for that owner name. If this
difference is greater than seven days (7 * 24 * 60 * 60), the mDNS
registrar MUST use a value of seven days rather than the larger
value.
3. mDNS Registrar Behavior
3.1. When sending an mDNS message
When constructing an mDNS message, the mDNS registrar includes one
TSR option for each unique owner name for any RR added to the mDNS
message for which the mDNS registrar is authoritative and which was
registered using SRP.
3.2. When processing an mDNS message
When an mDNS registrar receives an mDNS message query, it processes
it as usual, unless it discovers a conflict. When data in the mDNS
message conflicts with data in the mDNS querier's authority database,
as described in Section 8.1 of [RFC6762], this is considered to be a
conflict.
When a conflict detected for which a TSR record in the mDNS message
is applicable, and the local record was also registered using SRP,
the registrar checks to see if the key hashes match. If they do not,
then the conflict is processed as usual. If either the mDNS record
or the local authoritative record does not contain TSR information,
the conflict is processed as usual.
When both versions of the data have TSR records, and the key hashes
match, if the record in the mDNS response is more recent, the local
authoritative data is discarded from the authority dtheatabase and
the SRP registrar function is notified that that data is stale.
If, however, the version of the data received in the mDNS response is
less recent than the authoritative data, the registrar ignores the
data in the mDNS response.
4. mDNS querier behavior when processing an mDNS message
As with with the mDNS registrar case, when an mDNS querier receives
an mDNS Message, it compares TSR information in the local cache with
the TSR information in the message. If TSR information is present in
both locations, and the data in the mDNS message is more recent, the
information in the cache is replaced with the information in the mDNS
message. Otherwise, the information in the mDNS message is ignored.
Lemon & Qin Expires 5 September 2024 [Page 6]
Internet-Draft TSR EDNS option for mDNS March 2024
Note that some mDNS registrars only answer internal queries out of
cache, and populate their cache using information they receive both
from their own mDNS announcements and answers and from information
received in responses sent by other mDNS registrars. In addition to
the behavior described for mDNS registrars, such mDNS registrars MUST
also implement the behavior described here for queriers with respect
to cache updates.
5. The effect of network latency on time computations
Because TSR computations are affected by network latency, comparisons
can’t be considered accurate. It is therefore necessary to tolerate
some amount of error. In practice, however, it should generally not
be the case that two advertising proxies receive SRP updates from the
same SRP client at nearly the same time. So it should always be the
case either that there is a clear ordering to the timestamps, or that
there is no conflict in the data. For example with anycast, a
retransmission could go to a different SRP registrar, but in this
case both servers would simultaneously receive identical data, so the
close ordering or even equality of the timestamps should not affect
the outcome.
6. Internal Handling of TSR data
The TSR option that is sent on the wire is expressed in seconds
relative to the time of receipt of the registration. In order to
derive the time to send in a TSR option, the registrar must remember
the time at which the registration occurred. This time is recorded
as an absolute time, not a relative time. We refer to this as the
time of receipt. When constructing a TSR option, the registrar
computes the difference between the current time and the time of
receipt, which must always be in the past. This difference, which
should be a positive integer, is converted to seconds, and that
unsigned value is then used to synthesize the TSR RR.
7. Timeliness of Conflict Resolution
It is expected that if a conflict exists, it will be recent, and will
be resolved quickly. Different hosts may be able to record shorter
or longer time differences. However, because of this expectation of
recentness, mDNS registrars should never need to report a TSR of
longer than seven days. It’s reasonable to expect that every mDNS
implementation should be able to remember time intervals of at least
seven days.
Lemon & Qin Expires 5 September 2024 [Page 7]
Internet-Draft TSR EDNS option for mDNS March 2024
8. Legacy Behavior
y mDNS registrars and queriers that do not support the TSR option are
expected to ignore the option, so they will behave as if no TSR
option was sent. This may result in such registrars temporarily
caching stale data. However, in the normal course of processing,
more recent data will win. In cases where it does not, the Reconfirm
process which is part of [RFC6762] already works to clear stale data:
since we expect SRP servers to implement TSR, by the time a Reconfirm
is attempted, all authoritative stale data should have been cleared.
9. When to Use TSR
TSR is only relevant for mDNS proxies. Regular (non-proxy) mDNS
registrants are not expected to use it, since it will produce the
wrong behavior for this use case. An mDNS registrant that is a proxy
MUST explicitly request that a TSR be used for conflict resolution.
mDNS registrars MUST NOT record a time of receipt unless the
registrant has specifically requested it.
10. Registrant API considerations
When an mDNS proxy registers a service and requests the use of a time
of receipt, the proxy MUST specify when it received the registration.
In order to support this, the API is required not only to allow the
registrant to specify that TSR conflict resolution is wanted, but
must also provide a way for the proxy to specify an absolute time at
which the registration was received.
This is important, for example, in the case of SRP Replication
[I-D.lemon-srp-replication], where an SRP registrar may receive a
registration from a peer during startup synchronization. This
registration will have occurred at some significant amount of time in
the past, and so it would be incorrect for the mDNS proxy receiving
the registration to use the time that the mDNS proxy registers the
service as the time of receipt.
11. Security Considerations
The TSR option is an optimization: it ameliorates an edge case for
mDNS proxies. A malicious host on the same link could use the TSR
option to win conflict resolution processes. However, because TSR is
only used by proxies, this technique will not work for normal mDNS
service registrations: in that case, normal mDNS conflict resolution
is done, and the attacker gains no benefit from using TSR.
Lemon & Qin Expires 5 September 2024 [Page 8]
Internet-Draft TSR EDNS option for mDNS March 2024
Whether or not an mDNS registration has a recorded time of receipt,
an attacker can deny service by announcing its own conflicting data
and then answering the subsequent probe as described in Section 9 of
[RFC6762]. Because it does not include a TSR record in its authority
section, it can win the simultaneous conflict resolution process that
follows its bogus announcement.
So the TSR-based conflict resolution process creates no new
vulnerability. Addressing the existing vulnerability is out of scope
for this document. Protocols that rely on mDNS MUST NOT assume that
mDNS service is secure or private. If security (authentication,
authorization and/or secrecy) are needed, these must be provided at
the application layer, or by using DNSSEC rather than mDNS for
service discovery.
12. IANA Considerations
IANA is requested to allocate a new OPT RR option code from the DNS
EDNS0 Option Codes (OPT) registry for the 'Time Since Received'
Option. The Name shall be 'mDNS-TSR'. The value shall be allocated
by IANA. The meaning shall be 'Multicast DNS Time Since Received".
Reference shall refer to this document, once published. IANA shall
determine the registration date.
13. Informative References
14. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[I-D.lemon-srp-replication]
Lemon, T., Keshavarzian, A., and J. Hui, "Automatic
Replication of DNS-SD Service Registration Protocol
Zones", Work in Progress, Internet-Draft, draft-lemon-srp-
replication-03, 22 February 2023,
<https://datatracker.ietf.org/doc/html/draft-lemon-srp-
replication-03>.
Lemon & Qin Expires 5 September 2024 [Page 9]
Internet-Draft TSR EDNS option for mDNS March 2024
[I-D.sctl-advertising-proxy]
Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD
Service Registration Protocol", Work in Progress,
Internet-Draft, draft-sctl-advertising-proxy-02, 12 July
2021, <https://datatracker.ietf.org/doc/html/draft-sctl-
advertising-proxy-02>.
[I-D.ietf-dnssd-srp]
Lemon, T. and S. Cheshire, "Service Registration Protocol
for DNS-Based Service Discovery", Work in Progress,
Internet-Draft, draft-ietf-dnssd-srp-25, 4 March 2024,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
ietf-dnssd-srp/>.
Authors' Addresses
Ted Lemon
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: mellon@fugue.com
Liang Qin
Email: Leonqin0101@gmail.com
Additional contact information:
秦良
Lemon & Qin Expires 5 September 2024 [Page 10]
