idnits 2.17.00 (12 Aug 2021) /tmp/idnits46383/draft-tllq-tsr-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...DNS proxies. It SHOULD NOT be used by...' RFC 2119 keyword, line 214: '... proxy MUST explicitly request that ...' RFC 2119 keyword, line 215: '... mDNS registrars MUST NOT record a TSR...' RFC 2119 keyword, line 221: '...stamp, the proxy MUST specify when it ...' RFC 2119 keyword, line 251: '...hat rely on mDNS MUST NOT assume that ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (24 April 2022) is 20 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Lemon 3 Internet-Draft 秦 良 (L. Qin) 4 Intended status: Standards Track Apple Inc. 5 Expires: 26 October 2022 24 April 2022 7 A 'Time Since Registration' Resource Record for Multicast DNS 8 draft-tllq-tsr-01 10 Abstract 12 This document defines a new DNS Resource Record (RR) to be used with 13 multicast DNS. The new RR is used to communicate the time at which 14 the set of RRsets on a domain name were first registered. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 26 October 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Time Since Registered Resource Record . . . . . . . . . . . . 3 51 3. mDNS Registrar Behavior . . . . . . . . . . . . . . . . . . . 4 52 4. Internal Handling of TSR records . . . . . . . . . . . . . . 4 53 5. Timeliness of Conflict Resolution . . . . . . . . . . . . . . 5 54 6. Legacy Registrars . . . . . . . . . . . . . . . . . . . . . . 5 55 7. When to Use TSR . . . . . . . . . . . . . . . . . . . . . . . 5 56 8. Registrant API considerations . . . . . . . . . . . . . . . . 5 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 11. Informative References . . . . . . . . . . . . . . . . . . . 6 60 12. Normative References . . . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 Unlike the Internet Domain Name service, with its authority servers 66 and delegation of authority, Multicast DNS has no single source of 67 authority. Because of this, mDNS has a mechanism, conflict 68 resolution Section 9 of [RFC6762], for detecting and fixing conflicts 69 in mDNS advertisements. 71 The current mechanism for conflict resolution is simple: when a new 72 service is to be advertised, the server that wishes to advertise its 73 service typically registers the service with a central mDNS registrar 74 on the host on which it is running. 76 This mDNS registrar may have an internal database of services already 77 registered, and may detect a conflict with one of those services. In 78 this case, no network transaction is required: the mDNS registrar 79 immediately detects the conflict and addresses it in one of two ways, 80 depending on what the service requested. The first alternative is 81 that the registrar will report the conflict to the server an error, 82 which the server must fix. Alternatively, the server may have 83 indicated that the mDNS registrar should automatically choose a new 84 name for it, in which case the mDNS registrar does so automatically. 86 Once any local conflicts have been resolved, the mDNS registrar sends 87 a series of multicast probes to the local network to see if any other 88 host has already registered a service the conflicts with the proposed 89 new service. If such a service is present on the network, the mDNS 90 registrar follows the same process previously described, either 91 reporting the error to the server or automatically choosing a new 92 name. 94 The effect of this approach is that generally whichever server first 95 registers a service under a particular name wins. If a server comes 96 along later and registers the same service with conflicting 97 information, the newcomer's information is rejected. 99 This works well for devices acting on their own behalf. However, in 100 the case of advertising proxies, it works poorly: typically an 101 advertising proxy is proxying the contents of its proxy database 102 using mDNS. The source of truth for information in that database is 103 some host that has registered with the proxy, for example using the 104 Service Replication Protocol (SRP). 106 In the case of an advertising proxy proxying an SRP database, what we 107 want is not the oldest information, but the newest. When the SRP 108 client is able to continue registering with the same SRP server, this 109 works well. However, if SRP is being managed using anycast 110 registration, there is no guarantee that an SRP client will register 111 with the same server each time. 113 When the SRP client registers with a different server, the behavior 114 we expect with the current conflict resolution approach is that the 115 SRP client will be given a new name, and both the old (stale) 116 advertisement (A) and the new (more recent) advertisement (A') will 117 be seen on the network, as separate services. 119 This creates a new burden on consumers of that service: they need to 120 parse through the whole list of services of that type, using metadata 121 from the TXT record in the registration if needed to determine that 122 service A and service A' are the same service. 124 This document proposes an enhancement to the current conflict 125 resolution algorithm for mDNS, which allows an mDNS proxy to report 126 when it received the registration using a new Time Since Registered 127 RR, which is attached to the name of the registration. 129 2. Time Since Registered Resource Record 131 The Time Since Registered (TSR) RR is attached to the name for which 132 the TSR RR is asserting a registration time. The TSR RR contains the 133 time in seconds since the most recent registration that has been 134 received. This time is computed at the time that the mDNS message is 135 transmitted, and can be treated by the receiver as relative to the 136 current time. 138 The resource record is formatted as described in Section 3.2.1 of 139 [RFC1035]. The RDATA consists of the time offset in the form of a 140 32-bit unsigned number in network byte order. 142 3. mDNS Registrar Behavior 144 When probing, an mDNS registrar reports the TSR for the name for 145 which it is probing. When an mDNS Registrar receives a probe, it 146 checks to see if it has any registration that conflicts with the 147 probe announcement. If it does, it compares its internal TSR with 148 the TSR reported in the probe. If the TSR in the probe is more 149 recent than the internal TSR, the internal registration is marked as 150 stale, and the registrar does not respond to the probe. If the TSR 151 in the probe is older than the internal TSR, the registrar reports a 152 conflict as usual. 154 Note that because TSR computations are affected by network latency, 155 comparisons can't be considered accurate. It is therefore necessary 156 to tolerate some degree of error. As a general rule, a probe 157 containing a TSR that arrives at a registrar for which the timestamp 158 comparison is close to zero should be assumed to be more recent than 159 the registrar's copy: since the registrar already has a registration, 160 that registration most likely arrived before the registration that 161 triggered the probe. 163 The Service Registration Protocol uses DNS update, and it takes a 164 significant amount of time for a DNS update client to abandon one DNS 165 server for another, so in the absence of significant congestion- 166 related jitter in packet arrival times, it should never be the case 167 that two SRP proxies receive an SRP update at the same time from the 168 same client. Given that SRP generally does not operate across 169 network infrastructure operator boundaries, such delays are unlikely. 170 Also, if such a situation does occur, the updates should contain the 171 same data, and therefore should not be seen by the mDNS registrar as 172 being in conflict. 174 When a probe succeeds, the registrar that did the probe then 175 announces the new service. Registrars receiving this announcement 176 that have internal registrations that conflict with it, which are 177 marked stale, then remove the internal registration and report this 178 event to the proxy that did the registration. 180 4. Internal Handling of TSR records 182 The TSR record that is sent on the wire is expressed in seconds 183 relative to the time of registration. In order to derive a TSR 184 record, the registrar must remember the time at which the 185 registration occurred. This time is recorded as an absolute time, 186 not a relative time. We will refer to it as the TSR timestamp. When 187 sending a TSR RR, the registrar computes the difference between the 188 TSR timestamp, which must always be in the past, and the current 189 system time. This difference is converted to seconds, and that value 190 is then sent as the TSR RR. 192 5. Timeliness of Conflict Resolution 194 It is expected that if a conflict exists, it will be recent, and will 195 be resolved quickly. Different systems may be able to record shorter 196 or longer time differences, but because of this expectation of 197 recentness, mDNS registrars should never report a TSR of longer than 198 seven days. It's reasonable to expect that every mDNS implementation 199 should be able to remember time intervals of at least seven days. 201 6. Legacy Registrars 203 An mDNS registrar that does not support TSR will treat the TSR record 204 as part of the registration. Since the TSR record is only sent in 205 probes, it will never be erroneously reported to any client that is 206 browsing for services. If a legacy mDNS registrar and an mDNS 207 registrar that supports TSR both advertise the same service, the 208 conflict resolution rules described in RFC6762 will be followed. 210 7. When to Use TSR 212 TSR is only relevant for mDNS proxies. It SHOULD NOT be used by 213 regular (non-proxy) mDNS registrants. An mDNS registrant that is a 214 proxy MUST explicitly request that a TSR be used for conflict 215 resolution. mDNS registrars MUST NOT record a TSR timestamp unless 216 the registrant has specifically requested it. 218 8. Registrant API considerations 220 When an mDNS proxy registers a service and requests the use of a TSR 221 timestamp, the proxy MUST specify when it received the registration. 222 In order to support this, the API is required not only to allow the 223 registrant to specify that TSR is wanted, but must also provide a way 224 for the proxy to specify an absolute time at which the registration 225 was received. 227 This is important, for example, in the case of SRP Replication 228 [I-D.lemon-srp-replication], where an SRP server may receive a 229 registration from a peer during startup synchronization. This 230 registration will have occurred at some significant amount of time in 231 the past, and so it would be incorrect for the mDNS proxy receiving 232 the registration to use the time that the mDNS proxy registers the 233 service as the TSR timestamp. 235 9. Security Considerations 237 The TSR RR is an optimization: it ameliorates an edge case for mDNS 238 proxies. A malicious host on the same link could use the TSR RR to 239 win conflict resolution processes. However, because TSR is only used 240 by proxies, this technique will not work for normal mDNS service 241 registrations: in that case, normal mDNS conflict resolution is done, 242 and the attacker gains no benefit from using TSR. In the case of 243 proxied mDNS registrations, an attacker can in fact deny service by 244 superseding existing registrations. 246 However, such an attacker could achieve the same effect simply by 247 responding to probes with conflict announcements. Furthermore, such 248 an attack would cause noticeable problems on the network which the 249 network operator would then take steps to correct. 251 Protocols that rely on mDNS MUST NOT assume that mDNS service is 252 secure or private. If security (authentication, authorization and/or 253 secrecy) are needed, these must be provided at the application layer. 254 The use of TSR provides a novel way of attacking some mDNS services, 255 but the ground truth is that if security is not provided at the 256 application layer, this novel attack actually provides no new 257 advantage to the attacker. 259 10. IANA Considerations 261 IANA is requested to allocate a new RR Type from the DNS Resource 262 Record (RR) TYPEs registry for the 'Time Since Registered' Resource 263 Record. The type shall be 'TSR'. The value shall be allocated by 264 IANA. The Meaning shall be 'Multicast DNS Time Since Registered". 265 Reference shall refer to this document, once published. There is no 266 template specified, and IANA shall determine the registration date. 268 11. Informative References 270 12. Normative References 272 [RFC1035] Mockapetris, P., "Domain names - implementation and 273 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 274 November 1987, . 276 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 277 DOI 10.17487/RFC6762, February 2013, 278 . 280 [I-D.lemon-srp-replication] 281 Lemon, T., "Automatic Replication of DNS-SD Service 282 Registration Protocol Zones", Work in Progress, Internet- 283 Draft, draft-lemon-srp-replication-01, 7 November 2021, 284 . 287 Authors' Addresses 289 Ted Lemon 290 Apple Inc. 291 One Apple Park Way 292 Cupertino, California 95014 293 United States of America 294 Email: mellon@fugue.com 296 Liang Qin 297 Apple Inc. 298 One Apple Park Way 299 Cupertino, California 95014 300 United States of America 301 Email: Leonqin0101@gmail.com 303 Additional contact information: 305 秦良 306 Apple Inc. 307 One Apple Park Way 308 Cupertino, California 95014 309 United States of America