A 'Time Since Registration' Resource Record for Multicast DNS
draft-tllq-tsr-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ted Lemon , Liang Qin | ||
| Last updated | 2022-04-24 | ||
| Stream | (None) | ||
| Formats | plain text html xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tllq-tsr-01
Internet Engineering Task Force T. Lemon
Internet-Draft 秦 良 (L. Qin)
Intended status: Standards Track Apple Inc.
Expires: 26 October 2022 24 April 2022
A 'Time Since Registration' Resource Record for Multicast DNS
draft-tllq-tsr-01
Abstract
This document defines a new DNS Resource Record (RR) to be used with
multicast DNS. The new RR is used to communicate the time at which
the set of RRsets on a domain name were first registered.
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 26 October 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Lemon & Qin Expires 26 October 2022 [Page 1]
Internet-Draft TSR RR for mDNS April 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Time Since Registered Resource Record . . . . . . . . . . . . 3
3. mDNS Registrar Behavior . . . . . . . . . . . . . . . . . . . 4
4. Internal Handling of TSR records . . . . . . . . . . . . . . 4
5. Timeliness of Conflict Resolution . . . . . . . . . . . . . . 5
6. Legacy Registrars . . . . . . . . . . . . . . . . . . . . . . 5
7. When to Use TSR . . . . . . . . . . . . . . . . . . . . . . . 5
8. Registrant API considerations . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
11. Informative References . . . . . . . . . . . . . . . . . . . 6
12. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
Unlike the Internet Domain Name service, 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 mechanism for conflict resolution is simple: 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. In
this case, no network transaction is required: the mDNS registrar
immediately detects the conflict and addresses it in one of two ways,
depending on what the service requested. The first alternative is
that the registrar will report the conflict to the server an error,
which the server must fix. Alternatively, the server may have
indicated that the mDNS registrar should automatically choose a new
name for it, in which case the mDNS registrar does so automatically.
Once any local conflicts have been resolved, the mDNS registrar sends
a series of multicast probes to the 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 26 October 2022 [Page 2]
Internet-Draft TSR RR for mDNS April 2022
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.
This works well for devices acting on their own behalf. However, in
the case of advertising proxies, it works poorly: typically an
advertising proxy is proxying the contents of its proxy database
using mDNS. The source of truth for information in that database is
some host that has registered with the proxy, for example using the
Service Replication Protocol (SRP).
In the case of an advertising proxy proxying an SRP database, what we
want is not the oldest information, but the newest. When the SRP
client is able to continue registering with the same SRP server, this
works well. However, if SRP is being managed using anycast
registration, there is no guarantee that an SRP client will register
with the same server each time.
When the SRP client registers with a different server, the behavior
we expect 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 seen on the network, as separate services.
This creates a new burden on consumers of that service: they need to
parse through the whole list of services of that type, using metadata
from the TXT record in the registration if needed to determine that
service A and service A' are the same service.
This document proposes an enhancement to the current conflict
resolution algorithm for mDNS, which allows an mDNS proxy to report
when it received the registration using a new Time Since Registered
RR, which is attached to the name of the registration.
2. Time Since Registered Resource Record
The Time Since Registered (TSR) RR is attached to the name for which
the TSR RR is asserting a registration time. The TSR RR contains the
time in seconds since the most recent registration that has been
received. This time is computed at the time that the mDNS message is
transmitted, and can be treated by the receiver as relative to the
current time.
The resource record is formatted as described in Section 3.2.1 of
[RFC1035]. The RDATA consists of the time offset in the form of a
32-bit unsigned number in network byte order.
Lemon & Qin Expires 26 October 2022 [Page 3]
Internet-Draft TSR RR for mDNS April 2022
3. mDNS Registrar Behavior
When probing, an mDNS registrar reports the TSR for the name for
which it is probing. When an mDNS Registrar receives a probe, it
checks to see if it has any registration that conflicts with the
probe announcement. If it does, it compares its internal TSR with
the TSR reported in the probe. If the TSR in the probe is more
recent than the internal TSR, the internal registration is marked as
stale, and the registrar does not respond to the probe. If the TSR
in the probe is older than the internal TSR, the registrar reports a
conflict as usual.
Note that because TSR computations are affected by network latency,
comparisons can't be considered accurate. It is therefore necessary
to tolerate some degree of error. As a general rule, a probe
containing a TSR that arrives at a registrar for which the timestamp
comparison is close to zero should be assumed to be more recent than
the registrar's copy: since the registrar already has a registration,
that registration most likely arrived before the registration that
triggered the probe.
The Service Registration Protocol uses DNS update, and it takes a
significant amount of time for a DNS update client to abandon one DNS
server for another, so in the absence of significant congestion-
related jitter in packet arrival times, it should never be the case
that two SRP proxies receive an SRP update at the same time from the
same client. Given that SRP generally does not operate across
network infrastructure operator boundaries, such delays are unlikely.
Also, if such a situation does occur, the updates should contain the
same data, and therefore should not be seen by the mDNS registrar as
being in conflict.
When a probe succeeds, the registrar that did the probe then
announces the new service. Registrars receiving this announcement
that have internal registrations that conflict with it, which are
marked stale, then remove the internal registration and report this
event to the proxy that did the registration.
4. Internal Handling of TSR records
The TSR record that is sent on the wire is expressed in seconds
relative to the time of registration. In order to derive a TSR
record, the registrar must remember the time at which the
registration occurred. This time is recorded as an absolute time,
not a relative time. We will refer to it as the TSR timestamp. When
sending a TSR RR, the registrar computes the difference between the
TSR timestamp, which must always be in the past, and the current
system time. This difference is converted to seconds, and that value
Lemon & Qin Expires 26 October 2022 [Page 4]
Internet-Draft TSR RR for mDNS April 2022
is then sent as the TSR RR.
5. Timeliness of Conflict Resolution
It is expected that if a conflict exists, it will be recent, and will
be resolved quickly. Different systems may be able to record shorter
or longer time differences, but because of this expectation of
recentness, mDNS registrars should never 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.
6. Legacy Registrars
An mDNS registrar that does not support TSR will treat the TSR record
as part of the registration. Since the TSR record is only sent in
probes, it will never be erroneously reported to any client that is
browsing for services. If a legacy mDNS registrar and an mDNS
registrar that supports TSR both advertise the same service, the
conflict resolution rules described in RFC6762 will be followed.
7. When to Use TSR
TSR is only relevant for mDNS proxies. It SHOULD NOT be used by
regular (non-proxy) mDNS registrants. An mDNS registrant that is a
proxy MUST explicitly request that a TSR be used for conflict
resolution. mDNS registrars MUST NOT record a TSR timestamp unless
the registrant has specifically requested it.
8. Registrant API considerations
When an mDNS proxy registers a service and requests the use of a TSR
timestamp, 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 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 server 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 TSR timestamp.
Lemon & Qin Expires 26 October 2022 [Page 5]
Internet-Draft TSR RR for mDNS April 2022
9. Security Considerations
The TSR RR is an optimization: it ameliorates an edge case for mDNS
proxies. A malicious host on the same link could use the TSR RR 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. In the case of
proxied mDNS registrations, an attacker can in fact deny service by
superseding existing registrations.
However, such an attacker could achieve the same effect simply by
responding to probes with conflict announcements. Furthermore, such
an attack would cause noticeable problems on the network which the
network operator would then take steps to correct.
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.
The use of TSR provides a novel way of attacking some mDNS services,
but the ground truth is that if security is not provided at the
application layer, this novel attack actually provides no new
advantage to the attacker.
10. IANA Considerations
IANA is requested to allocate a new RR Type from the DNS Resource
Record (RR) TYPEs registry for the 'Time Since Registered' Resource
Record. The type shall be 'TSR'. The value shall be allocated by
IANA. The Meaning shall be 'Multicast DNS Time Since Registered".
Reference shall refer to this document, once published. There is no
template specified, and IANA shall determine the registration date.
11. Informative References
12. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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., "Automatic Replication of DNS-SD Service
Registration Protocol Zones", Work in Progress, Internet-
Lemon & Qin Expires 26 October 2022 [Page 6]
Internet-Draft TSR RR for mDNS April 2022
Draft, draft-lemon-srp-replication-01, 7 November 2021,
<https://datatracker.ietf.org/doc/html/draft-lemon-srp-
replication-01>.
Authors' Addresses
Ted Lemon
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: mellon@fugue.com
Liang Qin
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Email: Leonqin0101@gmail.com
Additional contact information:
秦良
Apple Inc.
One Apple Park Way
Cupertino, California 95014
United States of America
Lemon & Qin Expires 26 October 2022 [Page 7]