idnits 2.17.1 draft-sctl-advertising-proxy-02.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (12 July 2021) is 1012 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) ** Downref: Normative reference to an Informational RFC: RFC 6760 == Outdated reference: A later version (-25) exists of draft-ietf-dnssd-srp-09 == Outdated reference: A later version (-15) exists of draft-ietf-mboned-ieee802-mcast-problems-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSSD S. Cheshire 3 Internet-Draft T. Lemon 4 Intended status: Standards Track Apple Inc. 5 Expires: 13 January 2022 12 July 2021 7 Advertising Proxy for DNS-SD Service Registration Protocol 8 draft-sctl-advertising-proxy-02 10 Abstract 12 An Advertising Proxy allows a device that accepts service 13 registrations using Service Registration Protocol (SRP) to make those 14 registrations visible to legacy clients that only implement Multicast 15 DNS. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 13 January 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Conventions and Terminology Used in This Document . . . . 3 52 2. Advertising Proxy . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Name Conflicts . . . . . . . . . . . . . . . . . . . . . 3 54 2.1.1. Name Conflicts in Managed Namespaces . . . . . . . . 5 55 2.2. Data Translation . . . . . . . . . . . . . . . . . . . . 6 56 2.3. No Text-Encoding Translation . . . . . . . . . . . . . . 6 57 2.4. No Address Suppression . . . . . . . . . . . . . . . . . 6 58 2.5. No Support for Reconfirm . . . . . . . . . . . . . . . . 7 59 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 5.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 DNS-Based Service Discovery [RFC6763] [ROADMAP] was designed to 69 facilitate Zero Configuration IP Networking [RFC6760] [ZC]. 70 When used with Multicast DNS [RFC6762] with ".local" domain names 71 [RFC6761] this works well on a single link (a single broadcast 72 domain). 74 There is also a desire to have DNS-Based Service Discovery work 75 between multiple links that aren't part of the same broadcast domain 76 [RFC7558]. Even within a single Wi-Fi broadcast domain it is 77 beneficial to reduce multicast traffic, because, in comparison to 78 Wi-Fi unicast traffic, Wi-Fi multicast is inefficient, slow, and 79 unreliable [MCAST]. 81 There are three complementary ways that this move towards decreased 82 reliance on multicast is achieved. 84 One variant is pure end-to-end unicast, with services using unicast 85 Service Registration Protocol [SRP] to register with a service 86 registry, and clients using unicast DNS Push Notification 87 subscriptions [RFC8765] over DNS Stateful Operations [RFC8490] to 88 communicate with the service registry to discover and track changes 89 to those registered services. 91 A second variant is a hybrid approach that facilitates legacy devices 92 that only implement link-local Multicast DNS (like your ten-year-old 93 network laser printer) having their services discovered by remote 94 clients using a unicast DNS Push Notifications session to a Discovery 95 Proxy [RFC8766]. 97 The third variant, documented here, is a logical complement to the 98 second variant. It enables legacy clients (that only implement link- 99 local Multicast DNS) to discover services registered (using unicast) 100 with a service registry. The service registry accepts service 101 registrations using unicast Service Registration Protocol [SRP], and 102 makes those service registrations visible, both to remote clients 103 using unicast DNS Push Notifications [RFC8765] and, using the 104 Advertising Proxy mechanism documented here, to local clients using 105 Multicast DNS [RFC6762]. 107 1.1. Conventions and Terminology Used in This Document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in 112 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 2. Advertising Proxy 117 An Advertising Proxy can be a component of any DNS authoritative 118 server, though it logically makes most sense as a component of a 119 service registry (a DNS authoritative server that implements Service 120 Registration Protocol [SRP]). A client can send registration 121 requests for any valid DNS records to a service registry, though in 122 practice the most common use is to register the PTR, SRV and TXT 123 records that describe a DNS-SD service [RFC6763], and the A and AAAA 124 records that give the IPv4 and IPv6 addresses of the target host 125 where that service can be reached. 127 When a service registry accepts a registration request for DNS 128 records, a service registry that implements an Advertising Proxy also 129 advertises equivalent records using Multicast DNS on one or more 130 configured local multicast-capable interfaces. An Advertising Proxy 131 could also advertise on one or more configured remote multicast- 132 capable interfaces using a Multicast DNS Relay [RELAY]. For the 133 purposes of this document, a local multicast-capable interface 134 directly attached to the host and a remote multicast-capable 135 interface connected via a relay are considered to be equivalent. 137 2.1. Name Conflicts 139 In the event that an SRP client attempts to register a record with a 140 name that was already created in that registry by a different SRP 141 client, or is otherwise disallowed by policy, a name conflict is 142 reported and the new client is required to choose a new name. 144 Similarly, Multicast DNS implements first-come-first-served name 145 allocation. When a registered record is advertised using Multicast 146 DNS it may suffer a name conflict if a conflicting Multicast DNS 147 record with that name already exists on that link. In the case of 148 network failure and subsequent recovery, Multicast DNS can also 149 signal name conflicts at a later time during the life of a record 150 registration. For example, if the network link is partitioned at the 151 time of record registration, the name conflict may not be discovered 152 until later when the partition is healed. 154 Specifically, a name conflict can occur: 156 1. During the SRP validation process, because another SRP client has 157 already registered the same name. 159 2. Immediately while the Advertising Proxy is registering the name, 160 if the Multicast DNS uniqueness probes detect a conflicting 161 record. 163 3. After the name has been successfully registered, but before the 164 response has been sent to the client. 166 4. After the initial response has been sent to the client. 168 In the first three cases, the client can be notified of the conflict 169 at the time of registration, and is expected to choose a new name. 170 In the last case, SRP clients must be coded defensively to handle the 171 case where an apparently successful record registration is later 172 determined to be in conflict, just as existing Multicast DNS clients 173 have to be coded defensively to handle late conflicts gracefully. 174 With a sleepy SRP client there may be no way to notify it of the 175 conflict until it next re-registers. In the case of late conflicts, 176 the service registry with Advertising Proxy capability is responsible 177 for selecting a temporary new name to be used until the client 178 renews. When the client next renews, the service registry informs 179 the client of the new name the service registry selected on its 180 behalf. The client can choose to accept that new name, or select a 181 new name of its own choosing. 183 The registration process has several steps. First the hostname 184 claimed by the SRP client must be registered. Once this has 185 succeeded, the Advertising Proxy can register all of the service 186 instances that point to that hostname. When all of these 187 registrations have succeeded, the service registry can finally send 188 its response to the SRP client. If any of them fail, they must all 189 be removed and the client notified of the failure. If the failure is 190 a result of a name conflict, the response code should be YXDOMAIN. 191 Other SRP failures are documented in the SRP specification. Any 192 other failures not contemplated in the SRP specification return 193 SERVFAIL. 195 2.1.1. Name Conflicts in Managed Namespaces 197 In some cases, the name conflict resolution behavior described above 198 is neither needed nor desirable. For instance, when the set of 199 expected SRP clients is known to include only clients added with some 200 kind of commissioning or on-boarding protocol that guarantees that 201 hostnames are unique, it may cause serious problems to rename such a 202 device. 204 In this situation, the Advertising Proxy behavior should be 205 different: it should be assumed that all names registered with SRP 206 that survive SRP's first-come, first-serve name conflict detection 207 are indeed as intended. Any conflict that may be discovered as a 208 result of advertising those names using mDNS can be assumed to either 209 be an error or an attack, and there is no benefit to renaming such a 210 device: it will not be usable under its new name. 212 In this case, the Advertising Proxy simply performs normal SRP first- 213 come, first-serve naming and then updates its local idea of the SRP 214 namespace. This update is then reflected in mDNS. If a conflict is 215 detected, the Advertising Proxy schedules a new attempt to claim the 216 name at some time in the future: long enough that these re-attempts 217 to not generate excessive multicast traffic, but short enough that an 218 accidental conflict is cured in a reasonable timeframe. 220 The downside to this approach is that if the device on the multicast 221 network persists in claiming the name, the SRP client that claimed it 222 will be unreachable. Networks that use Advertising Proxies 223 configured to behave in this way should provide a way to rename the 224 device that is suffering the conflict. However, if the failure is 225 the result of a malicious attack by a device on the multicast 226 network, that device will have to be identified and removed before 227 the attack can be eliminated. 229 In order to address this problem, it may be advisable to provide with 230 a way for the advertising proxy to inform the mDNS service that it 231 should continue to advertise the name that is in conflict, rather 232 than ceasing to do so when the conflict is detected. 234 2.2. Data Translation 236 As with a Discovery Proxy [RFC8766] some translation needs to be 237 performed before the Advertising Proxy makes the registered unicast 238 data visible using Multicast DNS. Specifically, the unicast DNS 239 domain name suffix configured for Advertising Proxy use is stripped 240 off and replaced with the top-level label "local". 242 2.3. No Text-Encoding Translation 244 As with a Discovery Proxy [RFC8766], an Advertising Proxy does no 245 translation between text encodings [RFC6055]. Specifically, an 246 Advertising Proxy does no translation between Punycode encoding 247 [RFC3492] and UTF-8 encoding [RFC3629], either in the owner name of 248 DNS records or anywhere in the RDATA of DNS records (such as the 249 RDATA of PTR records, SRV records, NS records, or other record types 250 like TXT, where it is ambiguous whether the RDATA may contain DNS 251 names). All bytes are treated as-is with no attempt at text-encoding 252 translation. A server implementing DNS-based Service Discovery 253 [RFC6763] will use UTF-8 encoding for its unicast DNS-based record 254 registrations, which the Advertising Proxy passes through without any 255 text-encoding translation to the Multicast DNS subsystem. Queries 256 from peers on the configured multicast-capable interface are answered 257 directly from the advertised data without any text-encoding 258 translation. 260 2.4. No Address Suppression 262 Unlike a Discovery Proxy [RFC8766], an Advertising Proxy does not 263 need to selectively suppress link-local [RFC3927] [RFC4862] or other 264 addresses. Since the clients of the service registry are registering 265 their records in a unicast DNS namespace, there is a presumption they 266 they will only register addresses with sufficient scope to be usable 267 by the anticipated clients. No further filtering or suppression by 268 the service registry is required. In most cases it is acceptable for 269 devices registering with a service registry to register all of their 270 available addresses, and a client implementing Happy Eyeballs 271 [RFC8305] connecting to that service will automatically select an 272 appropriate address to use. 274 2.5. No Support for Reconfirm 276 For network efficiency, Multicast DNS [RFC6762] uses fairly long 277 record lifetimes (typically 75 minutes). When a client is unable to 278 reach a service that it discovered, Multicast DNS provides a 279 "reconfirm" mechanism that enables the client to signal to the 280 Multicast DNS subsystem that its cached data may be suspect, which 281 causes the Multicast DNS subsystem to reissue queries, and remove the 282 stale records if the queries are not answered. 284 Similarly, when using unicast service discovery with a Discovery 285 Proxy [RFC8766], the DNS Push Notifications [RFC8765] protocol 286 provides the RECONFIRM mechanism to signal that the Discovery Proxy 287 should perform a local Multicast DNS reconfirm operation to re-verify 288 the validity of the records. 290 When an Advertising Proxy is used, to support legacy clients that 291 only implement Multicast DNS, reconfirm operations have no effect. 292 If a device uses unicast Service Registration Protocol [SRP] to 293 register its services with a service registry with Advertising Proxy 294 capability, and the device then gets disconnected from the network, 295 the Advertising Proxy will continue to advertise those records until 296 the registrations expire. If a client discovers the service instance 297 using Multicast DNS and is unable to reach it, and uses a Multicast 298 DNS reconfirm operation to re-verify the validity of the records, 299 then the Advertising Proxy will continue to answer on behalf of the 300 departed device until the record registrations expire. The 301 Advertising Proxy has no reliable way to determine whether the 302 additional Multicast DNS queries are due to a reconfirm operation, or 303 due to other routine causes, like a client being rebooted, or 304 disconnecting and then reconnecting to the network. The service 305 registry has no reliable automatic way to determine whether a device 306 that registered records has failed or disconnected from the network. 307 Particularly with sleepy battery powered devices, the service 308 registry does not know what active duty cycle any given service is 309 expected to provide. 311 Consequently, reconfirm operations are not supported with an 312 Advertising Proxy. In cases where use of the reconfirm mechanism is 313 important, clients should be upgraded to use the unicast DNS Push 314 Notifications [RFC8765] protocol's RECONFIRM message. This RECONFIRM 315 message provides an unambiguous signal to the service registry that 316 it may be retaining stale records. (A future update to the Service 317 Registration Protocol document [SRP] will consider ways that this 318 unambiguous signal can be used to trigger expedited removal of stale 319 data.) 321 3. Security Considerations 323 An Advertising Proxy may made data visible to eavesdroppers on the 324 configured multicast-capable link(s). 326 4. IANA Considerations 328 This document has no IANA actions. 330 5. References 332 5.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 340 to Replace the AppleTalk Name Binding Protocol (NBP)", 341 RFC 6760, DOI 10.17487/RFC6760, February 2013, 342 . 344 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 345 RFC 6761, DOI 10.17487/RFC6761, February 2013, 346 . 348 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 349 DOI 10.17487/RFC6762, February 2013, 350 . 352 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 353 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 354 . 356 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 357 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 358 May 2017, . 360 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 361 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 362 RFC 8490, DOI 10.17487/RFC8490, March 2019, 363 . 365 [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", 366 RFC 8765, DOI 10.17487/RFC8765, June 2020, 367 . 369 [SRP] Lemon, T. and S. Cheshire, "Service Registration Protocol 370 for DNS-Based Service Discovery", Work in Progress, 371 Internet-Draft, draft-ietf-dnssd-srp-09, 11 January 2021, 372 . 375 5.2. Informative References 377 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 378 for Internationalized Domain Names in Applications 379 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 380 . 382 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 383 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 384 2003, . 386 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 387 Configuration of IPv4 Link-Local Addresses", RFC 3927, 388 DOI 10.17487/RFC3927, May 2005, 389 . 391 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 392 Address Autoconfiguration", RFC 4862, 393 DOI 10.17487/RFC4862, September 2007, 394 . 396 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 397 Encodings for Internationalized Domain Names", RFC 6055, 398 DOI 10.17487/RFC6055, February 2011, 399 . 401 [RFC7558] Lynn, K., Cheshire, S., Blanchet, M., and D. Migault, 402 "Requirements for Scalable DNS-Based Service Discovery 403 (DNS-SD) / Multicast DNS (mDNS) Extensions", RFC 7558, 404 DOI 10.17487/RFC7558, July 2015, 405 . 407 [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: 408 Better Connectivity Using Concurrency", RFC 8305, 409 DOI 10.17487/RFC8305, December 2017, 410 . 412 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 413 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 414 2020, . 416 [MCAST] Perkins, C. E., McBride, M., Stanley, D., Kumari, W., and 417 J. C. Zuniga, "Multicast Considerations over IEEE 802 418 Wireless Media", Work in Progress, Internet-Draft, draft- 419 ietf-mboned-ieee802-mcast-problems-13, 4 February 2021, 420 . 423 [RELAY] Lemon, T. and S. Cheshire, "Multicast DNS Discovery 424 Relay", Work in Progress, Internet-Draft, draft-ietf- 425 dnssd-mdns-relay-04, 22 February 2021, 426 . 429 [ROADMAP] Cheshire, S., "Service Discovery Road Map", Work in 430 Progress, Internet-Draft, draft-cheshire-dnssd-roadmap-03, 431 23 October 2018, . 434 [ZC] Cheshire, S. and D. H. Steinberg, "Zero Configuration 435 Networking: The Definitive Guide", O'Reilly Media, Inc., 436 ISBN 0-596-10100-7, December 2005. 438 Authors' Addresses 440 Stuart Cheshire 441 Apple Inc. 442 One Apple Park Way 443 Cupertino, California 95014 444 United States of America 446 Phone: +1 (408) 996-1010 447 Email: cheshire@apple.com 449 Ted Lemon 450 Apple Inc. 451 One Apple Park Way 452 Cupertino, California 95014 453 United States of America 455 Phone: +1 (408) 996-1010 456 Email: elemon@apple.com