--- 1/draft-ietf-dnssd-mdns-relay-02.txt 2020-07-13 17:13:56.176385223 -0700 +++ 2/draft-ietf-dnssd-mdns-relay-03.txt 2020-07-13 17:13:56.236386752 -0700 @@ -1,19 +1,18 @@ Network Working Group T. Lemon -Internet-Draft Nibbhaya Consulting -Intended status: Standards Track S. Cheshire -Expires: September 12, 2019 Apple Inc. - March 11, 2019 +Internet-Draft S. Cheshire +Intended status: Standards Track Apple Inc. +Expires: January 14, 2021 July 13, 2020 Multicast DNS Discovery Relay - draft-ietf-dnssd-mdns-relay-02 + draft-ietf-dnssd-mdns-relay-03 Abstract This document complements the specification of the Discovery Proxy for Multicast DNS-Based Service Discovery. It describes a lightweight relay mechanism, a Discovery Relay, which, when present on a link, allows remote clients, not attached to that link, to perform mDNS discovery operations on that link. Status of This Memo @@ -24,25 +23,25 @@ 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 September 12, 2019. + This Internet-Draft will expire on January 14, 2021. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -58,112 +57,133 @@ 4. Connections between Clients and Relays (details) . . . . . . 8 5. Traffic from Relays to Clients . . . . . . . . . . . . . . . 10 6. Traffic from Clients to Relays . . . . . . . . . . . . . . . 12 7. Discovery Proxy Behavior . . . . . . . . . . . . . . . . . . 13 8. DSO TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. mDNS Link Data Request . . . . . . . . . . . . . . . . . 14 8.2. mDNS Link Data Discontinue . . . . . . . . . . . . . . . 14 8.3. Link Identifier . . . . . . . . . . . . . . . . . . . . . 15 8.4. Encapsulated mDNS Message . . . . . . . . . . . . . . . . 15 8.5. IP Source . . . . . . . . . . . . . . . . . . . . . . . . 15 - 8.6. Link State Request . . . . . . . . . . . . . . . . . . . 15 + 8.6. Link State Request . . . . . . . . . . . . . . . . . . . 16 8.7. Link State Discontinue . . . . . . . . . . . . . . . . . 16 8.8. Link Available . . . . . . . . . . . . . . . . . . . . . 16 8.9. Link Unavailable . . . . . . . . . . . . . . . . . . . . 16 - 8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 17 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 19 - 9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 19 - 9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 20 - 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 21 - 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 22 - 9.3. Discovery Proxy Private Configuration . . . . . . . . . . 24 - 9.4. Discovery Relay Private Configuration . . . . . . . . . . 24 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 - 13.2. Informative References . . . . . . . . . . . . . . . . . 28 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 + 9.1.1. Multicast Link . . . . . . . . . . . . . . . . . . . 20 + 9.1.2. Discovery Proxy . . . . . . . . . . . . . . . . . . . 21 + 9.1.3. Discovery Relay . . . . . . . . . . . . . . . . . . . 22 + 9.2. Configuration Files . . . . . . . . . . . . . . . . . . . 23 + 9.3. Discovery Proxy Private Configuration . . . . . . . . . . 25 + 9.4. Discovery Relay Private Configuration . . . . . . . . . . 25 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 + 13.2. Informative References . . . . . . . . . . . . . . . . . 29 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction The Discovery Proxy for Multicast DNS-Based Service Discovery - [I-D.ietf-dnssd-hybrid] is a mechanism for discovering services on a - subnetted network through the use of Discovery Proxies, which issue - Multicast DNS (mDNS) requests [RFC6762] on various multicast links in - the network on behalf of a remote host performing DNS-Based Service + [RFC8766] is a mechanism for discovering services on a subnetted + network through the use of Discovery Proxies, which issue Multicast + DNS (mDNS) requests [RFC6762] on various multicast links in the + network on behalf of a remote host performing DNS-Based Service Discovery [RFC6763]. In the original Discovery Proxy specification, it is imagined that for every multicast link on which services will be discovered, a host will be present running a full Discovery Proxy. This document - introduces a lightweight Discovery Relay that can be used to provide - discovery services on a multicast link without requiring a full - Discovery Proxy on every multicast link. + introduces a lightweight Discovery Relay that can be used in + conjunction with a Discovery Proxy to provide discovery services on a + multicast link without requiring a full Discovery Proxy on every + multicast link. - Since the primary purpose of a Discovery Relay is providing remote - virtual interface functionality to Discovery Proxies, this document - is written with that usage in mind. However, in principle, a - Discovery Relay could be used by any properly authorized client. In - the context of this specification, a Discovery Proxy is a client to - the Discovery Relay. This document uses the terms "Discovery Proxy" - and "Client" somewhat interchangably; the term "Client" is used when - we are talking about the communication between the Client and the - Relay, and the term "Discovery Proxy" when we are referring - specifically to a Discovery Relay Client that also happens to be - acting as a Discovery Proxy. + The primary purpose of a Discovery Relay is providing remote virtual + interface functionality to Discovery Proxies, and this document is + written with that usage in mind. However, in principle, a Discovery + Relay could be used by any properly authorized client. In the + context of this specification, a Discovery Proxy is a client to the + Discovery Relay. This document uses the terms "Discovery Proxy" and + "Client" somewhat interchangably; the term "Client" is used when we + are talking about the communication between the Client and the Relay, + and the term "Discovery Proxy" when we are referring specifically to + a Discovery Relay Client that also happens to be a Discovery Proxy. + One example of another kind of device that can be a client of a + Discovery Relay is an Advertising Proxy [AdProx]. The Discovery Relay operates by listening for TCP connections from Clients. When a Client connects, the connection is authenticated and secured using TLS. The Client can then specify one or more multicast links from which it wishes to receive mDNS traffic. The Client can also send messages to be transmitted on its behalf on one or more of - those multicast links. DNS Stateful Operations (DSO) - [I-D.ietf-dnsop-session-signal] is used as a framework for conveying - interface and IP header information associated with each message. - DSO formats its messages using type-length-value (TLV) data - structures. This document defines additional DSO TLV types, used to - implement the Discovery Relay functionality. + those multicast links. DNS Stateful Operations (DSO) [RFC8490] is + used as a framework for conveying interface and IP header information + associated with each message. DSO formats its messages using type- + length-value (TLV) data structures. This document defines additional + DSO TLV types, used to implement the Discovery Relay functionality. The Discovery Relay functions essentially as a set of one or more remote virtual interfaces for the Client, one on each multicast link to which the Discovery Relay is connected. In a complex network, it is possible that more than one Discovery Relay will be connected to the same multicast link; in this case, the Client ideally should only be using one such Relay Proxy per multicast link, since using more than one will generate duplicate traffic. How such duplication is detected and avoided is out of scope for this document; in principle it could be detected using HNCP [RFC7788] or configured using some sort of orchestration software in conjunction with NETCONF [RFC6241] or CPE WAN Management Protocol [TR-069]. + Use of a Discovery Relay can be considered similar to using Virtual + LAN (VLAN) trunk ports to give a Discovery Proxy device a virtual + presence on multiple links or broadcast domains. The difference is + that while a VLAN trunk port operates at the link layer and delivers + all link-layer traffic to the Discovery Proxy device, a Discovery + Relay operates further up the network stack and selectively delivers + only relevant Multicast DNS traffic. Also, VLAN trunk ports are + generally only available within a single administrative domain and + require link-layer configuration and connectivity, whereas the + Discovery Relay protocol, which runs over TCP, can be used between + any two devices with IP connectivity to each other. + 2. Terminology + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. These words may also appear in this + document in lower case as plain English words, absent their normative + meanings. + The following definitions may be of use: Client A network service that uses a Discovery Relay to send and receive mDNS multicast traffic on a remote link, to enable it to communicate with mDNS Agents on that remote link. mDNS Agent A host which sends and/or responds to mDNS queries directly on its local link(s). Examples include network cameras, networked printers, networked home electronics, etc. Discovery Proxy A network service which receives well-formed questions using the DNS protocol, performs multicast DNS queries - to answer those questions, and responds with those answers using - the DNS protocol. A Discovery Proxy that can communicate with - remote mDNS Agents, using the services of a Discovery Relay, is a - Client of the Discovery Relay. + to find answers to those questions, and responds with those + answers using the DNS protocol. A Discovery Proxy that can + communicate with remote mDNS Agents, using the services of a + Discovery Relay, is a Client of the Discovery Relay. Discovery Relay A network service which relays mDNS messages received on a local link to a Client, and on behalf of that Client can transmit mDNS messages on a local link. multicast link A maximal set of network connection points, such that any host connected to any connection point in the set may send a packet with a link-local multicast destination address (specifically the mDNS link-local multicast destination address [RFC6762]) that will be received by all hosts connected to all @@ -192,142 +212,146 @@ Relay may accept connections. silently discard When a message that is not supported or not permitted is received, and the required response to that message is to "silently discard" it, that means that no response is sent by the service that is discarding the message to the service that sent it. The service receiving the message may log the event, and may also count such events: "silently" does not preclude such behavior. + Take care when reading this document not to confuse the terms + "Discovery Proxy" and "Discovery Relay". A Discovery Proxy [RFC8766] + provides Multicast DNS discovery service to remote clients. A + Discovery Relay is a simple software entity that provides virtual + link connectivity to one or more Discovery Proxies or other Discovery + Relay clients. + 3. Protocol Overview - This document describes a way for Clients to communicate with mDNS - agents on remote multicast links to which they are not directly + This document describes a way for a Client to communicate with mDNS + agents on remote multicast links to which the client is not directly connected, using a Discovery Relay. As such, there are two parts to the protocol: connections between Clients and Discovery Relays, and communications between Discovery Relays and mDNS agents. 3.1. Connections between Clients and Relays (overview) Discovery Relays listen for incoming connection requests. Connections between Clients and Discovery Relays are established by Clients. Connections are authenticated and encrypted using TLS, with both client and server certificates. Connections are long-lived: a Client is expected to send many queries over a single connection, and Discovery Relays will forward all mDNS traffic from subscribed interfaces over the connection. The stream encapsulated in TLS will carry DNS frames as in the DNS TCP protocol [RFC1035] Section 4.2.2. However, all messages will be - DSO messages [I-D.ietf-dnsop-session-signal]. There will be four - types of such messages between Discovery Relays and Clients: + DSO messages [RFC8490]. There will be four types of such messages + between Discovery Relays and Clients: o Control messages from Client to Relay o Link status messages from Relay to Client - o Encapsulated mDNS query messages from Client to Relay + o Encapsulated mDNS messages from Client to Relay - o Encapsulated mDNS response messages from Relay to Client + o Encapsulated mDNS messages from Relay to Client Clients can send four different control messages to Relays: Link State Request, Link State Discontinue, Link Data Request and Link Data Discontinue. The first two are used by the Client to request that the Relay report on the set of links that can be requested, and to request that it discontinue such reporting. The second two are used by the Client to indicate to the Discovery Relay that mDNS messages from one or more specified multicast links are to be relayed to the Client, and to subsequently stop such relaying. Link Status messages from a Discovery Relay to the Client inform the Client that a link has become available, or that a formerly-available link is no longer available. - Encapsulated mDNS response messages from a Discovery Relay to a - Client are sent whenever an mDNS response message is received on a - multicast link to which the Discovery Relay has subscribed. + Encapsulated mDNS messages from a Discovery Relay to a Client are + sent whenever an mDNS message is received on a multicast link to + which the Discovery Relay has subscribed. - Encapsulated query mDNS messages from a Client to a Discovery Relay - cause the Discovery Relay to transmit the mDNS query message on the - specified multicast link to which the Discovery Relay host is - directly attached. + Encapsulated mDNS messages from a Client to a Discovery Relay cause + the Discovery Relay to transmit the mDNS message on the specified + multicast link to which the Discovery Relay host is directly + attached. During periods with no traffic flowing, Clients are responsible for generating any necessary keepalive traffic, as stated in the DSO - specification [I-D.ietf-dnsop-session-signal]. + specification [RFC8490]. 3.2. mDNS Messages On Multicast Links Discovery Relays listen for mDNS traffic on all configured multicast links that have at least one active subscription from a Client. When - an mDNS response message is received on a multicast link, it is - forwarded on every open Client connection that is subscribed to mDNS - traffic on that multicast link. In the event of congestion, where a - particular Client connection has no buffer space for an mDNS message - that would otherwise be forwarded to it, the mDNS message is not - forwarded to it. Normal mDNS retry behavior is used to recover from - this sort of packet loss. Discovery Relays are not expected to - buffer more than a few mDNS packets. Excess mDNS packets are - silently discarded. In practice this is not expected to be a issue. - Particularly on networks like Wi-Fi, multicast packets are - transmitted at rates ten or even a hundred times slower than unicast - packets. This means that even at peak multicast packets rates, it is - likely that a unicast TCP connection will able to carry those packets - with ease. + an mDNS message is received on a multicast link, it is forwarded on + every open Client connection that is subscribed to mDNS traffic on + that multicast link. In the event of congestion, where a particular + Client connection has no buffer space for an mDNS message that would + otherwise be forwarded to it, the mDNS message is not forwarded to + it. Normal mDNS retry behavior is used to recover from this sort of + packet loss. Discovery Relays are not expected to buffer more than a + few mDNS packets. Excess mDNS packets are silently discarded. In + practice this is not expected to be a issue. Particularly on + networks like Wi-Fi, multicast packets are transmitted at rates ten + or even a hundred times slower than unicast packets. This means that + even at peak multicast packets rates, it is likely that a unicast TCP + connection will able to carry those packets with ease. - Clients send encapsulated mDNS query messages they wish to have sent - on their behalf on remote multicast link(s) on which the Client has - an active subscription. A Discovery Relay will not transmit mDNS - query packets on any multicast link on which the Client does not have - an active subscription, since it makes no sense for a Client to ask - to have a query sent on its behalf if it's not able to receive the + Clients send encapsulated mDNS messages they wish to have sent on + their behalf on remote multicast link(s) on which the Client has an + active subscription. A Discovery Relay will not transmit mDNS + packets on any multicast link on which the Client does not have an + active subscription, since it makes no sense for a Client to ask to + have a query sent on its behalf if it's not able to receive the responses to that query. 4. Connections between Clients and Relays (details) When a Discovery Relay starts, it opens a passive TCP listener to receive incoming connection requests from Clients. This listener may be bound to one or more source IP addresses, or to the wildcard address, depending on the implementation. When a connection is received, the relay must first validate that it is a connection to an IP address to which connections are allowed. For example, it may be that only connections to ULAs are allowed, or to the IP addresses configured on certain interfaces. If the listener is bound to a specific IP address, this check is unnecessary. If the relay is using an IP address whitelist, the next step is for the relay to verify that that the source IP address of the connection is on its whitelist. If the connection is not permitted either because of the source address or the destination address, the Discovery Relay closes the connection. If possible, before closing the connection, the Discovery Relay first sends a TLS user_canceled - alert ([I-D.ietf-tls-tls13] Section 6.1). Discovery Relays SHOULD - refuse to accept TCP connections to invalid destination addresses, - rather than accepting and then closing the connection, if this is - possible. + alert ([RFC8446] Section 6.1). Discovery Relays SHOULD refuse to + accept TCP connections to invalid destination addresses, rather than + accepting and then closing the connection, if this is possible. Otherwise, the Discovery Relay will attempt to complete a TLS handshake with the Client. Clients are required to send the - post_handshake_auth extension ([I-D.ietf-tls-tls13] Section 4.2.5). - If a Discovery Relay receives a ClientHello message with no + post_handshake_auth extension ([RFC8446] Section 4.2.5). If a + Discovery Relay receives a ClientHello message with no post_handshake_auth extension, the Discovery Relay rejects the - connection with a certificate_required alert ([I-D.ietf-tls-tls13] - Section 6.2). + connection with a certificate_required alert ([RFC8446] Section 6.2). Once the TLS handshake is complete, the Discovery Relay MUST request - post-handshake authentication as described in ([I-D.ietf-tls-tls13] - Section 4.6.2). If the Client refuses to send a certificate, or the - key presented does not match the key associated with the IP address - from which the connection originated, or the CertificateVerify does - not validate, the connection is dropped with the TLS access_denied - alert ([I-D.ietf-tls-tls13] Section 6.2). + post-handshake authentication ([RFC8446] Section 4.6.2). If the + Client refuses to send a certificate, or the key presented does not + match the key associated with the IP address from which the + connection originated, or the CertificateVerify does not validate, + the connection is dropped with the TLS access_denied alert ([RFC8446] + Section 6.2). Clients MUST validate server certificates. If the client is configured with a server IP address and certificate, it can validate the server by comparing the certificate offered by the server to the certificate that was provided: they should be the same. If the certificate includes a Distinguished Name that is a fully-qualified domain name, the client SHOULD present that domain name to the server in an SNI request. Rather than being configured with an IP address and a certificate, @@ -337,23 +362,23 @@ in [RFC8310] section 8.1, if the certificate is signed by a root authority the client trusts, or the method described in section 8.2 of the same document if not. If neither method is available, then a locally-configured copy of the server certificate can be used, as in the previous paragraph. Once the connection is established and authenticated, it is treated as a DNS TCP connection [RFC7766]. Aliveness of connections between Clients and Relays is maintained as - described in Section 4 of [I-D.ietf-dnsop-session-signal]. Clients - must also honor the 'Retry Delay' TLV (section 5 of - [I-D.ietf-dnsop-session-signal]) if sent by the Discovery Relay. + described in Section 4 of the DSO specification [RFC8490]. Clients + must also honor the 'Retry Delay' TLV (section 5 of [RFC8490]) if + sent by the Discovery Relay. Clients SHOULD avoid establishing more than one connection to a specific Discovery Relay. However, there may be situations where multiple connections to the same Discovery Relay are unavoidable, so Discovery Relays MUST be willing to accept multiple connections from the same Client. In order to know what links to request, the Client can be configured with a list of links supported by the Relay. However, in some networking contexts, dynamic changes in the availability of links are @@ -373,119 +398,118 @@ indicating the multicast link from which traffic is requested. When an mDNS Link Data Request message is received, the Discovery Relay validates that it recognizes the link identifier, and that forwarding is enabled for that link. If both checks are successful, it MUST send a response with RCODE=0 (NOERROR). If the link identifier is not recognized, it sends a response with RCODE=3 (NXDOMAIN/Name Error). If forwarding from that link to the Client is not enabled, it sends a response with RCODE=5 (REFUSED). If the relay cannot satisfy the request for some other reason, for example - resource exhaustion, it sends a response with RCODE=2 (SERVFAIL). It - is not an error to request a recognized link identifier which is not - yet available; the Discovery Relay accepts the request, and begins - forwarding packets when the link becomes available. + resource exhaustion, it sends a response with RCODE=2 (SERVFAIL). If the requested link is valid, the Relay begins forwarding all mDNS - response messages from that link to the Client. Delivery is not - guaranteed: if there is no buffer space, packets will be dropped. It - is expected that regular mDNS retry processing will take care of - retransmission of lost packets. The amount of buffer space is - implementation dependent, but generally should not be more than the - bandwidth delay product of the TCP connection [RFC1323]. The - Discovery Relay should use the TCP_NOTSENT_LOWAT mechanism - [NOTSENT][PRIO] or equivalent, to avoid building up a backlog of data - in excess of the amount necessary to have in flight to fill the - bandwidth delay product of the TCP connection. + messages from that link to the Client. Delivery is not guaranteed: + if there is no buffer space, packets will be dropped. It is expected + that regular mDNS retry processing will take care of retransmission + of lost packets. The amount of buffer space is implementation + dependent, but generally should not be more than the bandwidth delay + product of the TCP connection [RFC7323]. The Discovery Relay should + use the TCP_NOTSENT_LOWAT mechanism [NOTSENT][PRIO] or equivalent, to + avoid building up a backlog of data in excess of the amount necessary + to have in flight to fill the bandwidth delay product of the TCP + connection. - Encapsulated mDNS response messages from Relays to Clients are framed - within DSO messages. Each DSO message can contain multiple TLVs, but - only a single encapsulated mDNS message is conveyed per DSO message. - Each forwarded mDNS response message is sent in an Encapsulated mDNS - Message TLV (Section 8.4). The source IP address and port of the - message MUST be encoded in an IP Source TLV (Section 8.5). The - multicast link on which the message was received MUST be encoded in a - Link Identifier TLV (Section 8.3). As described in the DSO - specification [I-D.ietf-dnsop-session-signal], a Client MUST silently - ignore unrecognized Additional TLVs in mDNS messages, and MUST NOT - discard mDNS messages that include unrecognized Additional TLVs. + Encapsulated mDNS messages from Relays to Clients are framed within + DSO messages. Each DSO message can contain multiple TLVs, but only a + single encapsulated mDNS message is conveyed per DSO message. Each + forwarded mDNS message is sent in an Encapsulated mDNS Message TLV + (Section 8.4). The source IP address and port of the message MUST be + encoded in an IP Source TLV (Section 8.5). The multicast link on + which the message was received MUST be encoded in a Link Identifier + TLV (Section 8.3). As described in the DSO specification [RFC8490], + a Client MUST silently ignore unrecognized Additional TLVs in mDNS + messages, and MUST NOT discard mDNS messages that include + unrecognized Additional TLVs. A Client may discontinue listening for mDNS messages on a particular multicast link by sending a DSO message containing an mDNS Link Data - Discontinue TLV (Section 8.2). Subsequent messages from that link - that had previously been queued may arrive after listening has been - discontinued. The Client should silently discard such messages. The - Discovery Relay MUST discontinue generating such messages as soon as - the request is received. The Discovery Relay does not respond to - this message other than to discontinue forwarding mDNS messages from - the specified links. + Discontinue TLV (Section 8.2). The Discovery Relay MUST discontinue + forwarding mDNS messages when the Link Data Discontinue request is + received. However, messages from that link that had previously been + queued may arrive after the Client has discontinued its listening. + The Client should silently discard such messages. The Discovery + Relay does not respond to the Link Data Discontinue message other + than to discontinue forwarding mDNS messages from the specified + links. 6. Traffic from Clients to Relays - Like mDNS traffic from relays, each mDNS query message sent by a - Client to a Discovery Relay is communicated in an Encapsulated mDNS - Message TLV (Section 8.4) within a DSO message. Each message MUST - contain exactly one Link Identifier TLV (Section 8.3). The Discovery - Relay will transmit the mDNS query message to the mDNS port and - multicast address on the link specified in the message using the - specified IP address family. + Like mDNS traffic from relays, each mDNS message sent by a Client to + a Discovery Relay is communicated in an Encapsulated mDNS Message TLV + (Section 8.4) within a DSO message. Each message MUST contain + exactly one Link Identifier TLV (Section 8.3). The Discovery Relay + will transmit the mDNS message to the mDNS port and multicast address + on the link specified in the message using the specified IP address + family. Although the communication between Clients and Relays uses the DNS stream protocol and DNS Stateless Operations, there is no case in - which a Client would legitimately send a DNS query (something other - than a DSO message) to a Relay. Therefore, if a Relay receives a - message other than a DSO message, it MUST respond with a REFUSED - result code. The reason not to simply drop the connection is that it - might result in a continual reconnection loop. + which a Client would legitimately send a DNS query (or anything else + other than a DSO message) to a Relay. Therefore, if a Relay receives + any message other than a DSO message, it MUST immediately abort that + DSO session with a TCP reset (RST). When defining this behavior, the working group considered making it possible to specify more than one link identifier in an mDNSMessage - TLV. A superficial evaluation of this suggests that this would be a + TLV. A superficial evaluation of this suggested that this might be a useful optimization, since when a query is issued, it will often be - issued to all links. However, because of the way mDNS handles - retries, it will almost never be the case that the exact same message - will be sent on more than one link. Therefore, the complexity that - this optimization adds is in no way justified by the potential - benefit, and this idea has been abandoned. + issued to all links. However, on many link types, like Wi-Fi, + multicast traffic is expensive + [I-D.ietf-mboned-ieee802-mcast-problems] and should be generated + frugally, so providing convenient ways to generate additional + multicast traffic was determined to be an unwise optimization. In + addition, because of the way mDNS handles retries, it will almost + never be the case that the exact same message will be sent on more + than one link. Therefore, the complexity that this optimization adds + is not justified by the potential benefit, and this idea has been + abandoned. 7. Discovery Proxy Behavior Discovery Proxies treat multicast links for which Discovery Relay service is being used as if they were virtual interfaces; in other words, a Discovery Proxy serving multiple remote multicast links - using multiple Discovery Relays behaves the same as a Discovery Proxy - serving multiple local multicast links using multiple physical - network interfaces. In this section we refer to multicast links - served directly by the Discovery Proxy as locally-connected links, - and multicast links served through the Discovery Relay as relay- - connected links. + using multiple remote Discovery Relays behaves the same as a + Discovery Proxy serving multiple local multicast links using multiple + local physical network interfaces. In this section we refer to + multicast links served directly by the Discovery Proxy as locally- + connected links, and multicast links served through the Discovery + Relay as relay-connected links. A relay-connected link can be + thought of as similar to a link that a Discovery Proxy connects to + using a USB Ethernet interface, just with a very long USB cable (that + runs over TCP). - When a Discovery Proxy receives a DNSSD query from a Client via - unicast, it will generate mDNS query messages on the relevant - multicast link(s) for which it is acting as a proxy. For locally- - connected link(s), those query messages will be sent directly. For - relay-connected link(s), the query messages will be sent through the - Discovery Relay that is being used to serve that multicast link. + When a Discovery Proxy receives a DNS query from a DNS client via + unicast, it will generate corresponding mDNS query messages on the + relevant multicast link(s) for which it is acting as a proxy. For + locally-connected link(s), those query messages will be sent + directly. For relay-connected link(s), the query messages will be + sent through the Discovery Relay that is being used to serve that + multicast link. Responses from devices on locally-connected links are processed normally. Responses from devices on relay-connected links are received by the Discovery Relay, encapsulated, and forwarded to the Client; the Client then processes these messages using the link- identifying information included in the encapsulation. - Discovery Proxies do not generally respond to mDNS queries on relay- - connected links. The one exception is responding to the Domain - Enumeration queries used to bootstrap unicast service discovery - ("lb._dns-sd._udp.local", etc.) [RFC6763]. Apart from these Domain - Enumeration queries, if any other mDNS query is received from a - Discovery Relay, the Discovery Proxy silently discards it. - In principle it could be the case that some device is capable of performing service discovery using Multicast DNS, but not using traditional unicast DNS. Responding to mDNS queries received from the Discovery Relay could address this use case. However, continued reliance on multicast is counter to the goals of the current work in service discovery, and to benefit from wide-area service discovery such client devices should be updated to support service discovery using unicast queries. 8. DSO TLVs @@ -507,81 +531,86 @@ The mDNS Link Data Request TLV can only be used as a primary TLV, and requires an acknowledgement. At most one mDNS Link Data Request TLV may appear in a DSO message. To request multiple link subscriptions, multiple separate DSO messages are sent, each containing a single mDNS Link Data Request TLV. A Client MUST NOT request a link if it already has an active subscription to that link on the same DSO connection. If a Discovery - Relay receives a duplicate link subscription request, it SHOULD - immediately abort that DSO session. + Relay receives a duplicate link subscription request, it MUST + immediately abort that DSO session with a TCP reset (RST). 8.2. mDNS Link Data Discontinue The mDNS Link Data Discontinue TLV is used by Clients to unsubscribe to mDNS messages on the specified multicast link. DSO-TYPE is TBD-D. DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family followed by the 32-bit link identifier, a 32-bit unsigned integer in network (big endian) byte order, as described in Section 9. - The mDNS Link Data Discontinue TLV can only be used as a primary TLV, - and is not acknowledged. + The mDNS Link Data Discontinue TLV can only be used as a DSO + unidirectional message TLV, and is not acknowledged. At most one mDNS Link Data Discontinue TLV may appear in a DSO message. To unsubscribe from multiple links, multiple separate DSO messages are sent, each containing a single mDNS Link Data Discontinue TLV. 8.3. Link Identifier This option is used both in DSO messages from Discovery Relays to Clients that contain received mDNS messages, and from Clients to Discovery Relays that contain mDNS messages to be transmitted on the multicast link. In the former case, it indicates the multicast link on which the message was received; in the latter case, it indicates the multicast link on which the message should be transmitted. DSO- TYPE is TBD-L. DSO-LENGTH is always 5. DSO-DATA is the 8-bit address family followed by the link identifier, a 32-bit unsigned integer in network (big endian) byte order, as described in Section 9. - The Link Identifier TLV can only be used as an additional TLV. + The Link Identifier TLV can only be used as an additional TLV. The + Link Identifier TLV can only appear at most once in a Discovery Relay + DSO message. 8.4. Encapsulated mDNS Message The Encapsulated mDNS Message TLV is used to communicate an mDNS message that a Relay is forwarding from a multicast link to a Client, or that a Client is sending to a Relay for transmission on a multicast link. Only the application-layer payload of the mDNS message is carried in the DSO "Encapsulated mDNS Message" TLV, i.e., just the DNS message itself, beginning with the DNS Message ID, not the IP or UDP headers. The DSO-TYPE for this TLV is TBD-M. DSO- LENGTH is the length of the encapsulated mDNS message. DSO-DATA is the content of the encapsulated mDNS message. - The Encapsulated mDNS Message TLV can only be used as a primary TLV, - and is not acknowledged. + The Encapsulated mDNS Message TLV can only be used as a DSO + unidirectional message TLV, and is not acknowledged. 8.5. IP Source The IP Source TLV is used to report the IP source address and port from which an mDNS message was received. This TLV is present in DSO messages from Discovery Relays to Clients that contain encapsulated mDNS messages. DSO-TYPE is TBD-S. DSO-LENGTH is either 6, for an IPv4 address, or 18, for an IPv6 address. DSO-DATA is the two-byte - source port, followed by the 4- or 16-byte IP Address, both in the - canonical byte order (i.e., the same representation as used in the - UDP and IP packet headers, with no byte swapping). + source port, followed by the 4- or 16-byte IP Address. Both port and + address are in the canonical byte order (i.e., the same + representation as used in the UDP and IP packet headers, with no byte + swapping). - The IP Source TLV can only be used as an additional TLV. + The IP Source TLV can only be used as an additional TLV. The IP + Source TLV can only appear at most once in a Discovery Relay DSO + message. 8.6. Link State Request The Link State Request TLV requests that the Discovery Relay report link changes. When the relay is reporting link changes and a new link becomes available, it sends a Link Available message to the Client. When a link becomes unavailable, it sends a Link Unavailable message to the Client. If there are links available when the request is received, then for each such link the relay immediately sends a Link Available Message to the Client. DSO-TYPE is TBD-P. DSO-LENGTH @@ -592,42 +621,42 @@ a Link Available TLV: it is just a response to the Link State Request message. 8.7. Link State Discontinue The Link State Discontinue TLV requests that the Discovery Relay stop reporting on the availability of links supported by the relay. This cancels the effect of a Link State Request TLV. DSO-TYPE is TBD-Q. DSO-LENGTH is 0. - The mDNS Link State Discontinue TLV can only be used as a primary - TLV, and is not acknowledged. + The mDNS Link State Discontinue TLV can only be used as a DSO + unidirectional message TLV, and is not acknowledged. 8.8. Link Available The Link Available TLV is used by Discovery Relays to indicate to Clients that a new link has become available. The format is the same as the Link Identifier TLV. DSO-TYPE is TBD-V. The Link Available TLV may be accompanied by one or more Link Prefix TLVs which indicate IP prefixes the Relay knows to be present on the link. - The mDNS Link Available TLV can only be used as a primary TLV, and is - not acknowledged. + The mDNS Link Available TLV can only be used as a DSO unidirectional + message TLV, and is not acknowledged. 8.9. Link Unavailable The Link Unavailable TLV is used by Discovery Relays to indicate to Clients that an existing link has become unavailable. The format is the same as the Link Identifier TLV. DSO-TYPE is TBD-U. - The mDNS Link Unavailable TLV can only be used as a primary TLV, and - is not acknowledged. + The mDNS Link Unavailable TLV can only be used as a DSO + unidirectional message TLV, and is not acknowledged. 8.10. Link Prefix The Link Prefix TLV represents an IP address or prefix configured on a link. The length is 17 for an IPv6 address or prefix, and 5 for an IPv4 address or prefix. The TLV consists of a prefix length, between 0 and 32 for IPv4 or between 0 and 128 for IPv6, represented as a single byte. This is followed by the IP address, either four or sixteen bytes. DSO-TYPE is TBD-K. @@ -700,55 +729,53 @@ The description of a multicast link consists of: link-identifier A 32-bit identifier that uniquely identifies that link within the Discovery Domain. Each link MUST have exactly one such identifier. Link Identifiers do not have any special semantics, and are not intended to be human-readable. ldh-name A fully-qualified domain name for the multicast link that is used to form an LDH domain name as described in section 5.3 of - the Discovery Proxy specification [I-D.ietf-dnssd-hybrid]. This - name is used to identify the link during provisioning, and must be - present. + the Discovery Proxy specification [RFC8766]. This name is used to + identify the link during provisioning, and must be present. hr-name A human-readable user-friendly fully-qualified domain name for the multicast link. This name MUST be unique within the Discovery Domain. Each multicast link MUST have exactly one such name. The hr-name MAY be the same as the ldh-name. (The hr-name is allowed to contain spaces, punctuation and rich text, but it is not required to do so.) The ldh-name and hr-name can be used to form the LDH and human- - readable domain names as described in [I-D.ietf-dnssd-hybrid], - section 5.3. + readable domain names as described in [RFC8766], section 5.3. Note that the ldh-name and hr-name can be used in two different ways. On a small home network with little or no human administrative configuration, link names may be directly visible to the user. For example, a search in 'home.arpa' on a small home network may discover services on both ethernet.home.arpa and wi-fi.home.arpa. In the case of a home user who has one Ethernet-connected printer and one Wi-Fi- connected printer, discovering that they have one printer on ethernet.home.arpa and another on wi-fi.home.arpa is understandable and meaningful. On a large corporate network with hundreds of Wi-Fi access points, the individual link names of the hundreds of multicast links are less likely to be useful to end users. In these cases, Discovery Broker - functionality [I-D.sctl-discovery-broker] is used to translate the - many link names to something more meaningful to users. For example, - in a building with 50 Wi-Fi access points, each with their own link - names, services on all the different physical links may be presented - to the user as appearing in 'headquarters.example.com'. In this - case, the individual link names can be thought of similar to MAC + functionality [I-D.sctl-discovery-broker] may be used to translate + the many link names to something more meaningful to users. For + example, in a building with 50 Wi-Fi access points, each with their + own link names, services on all the different physical links may be + presented to the user as appearing in 'headquarters.example.com'. In + this case, the individual link names can be thought of similar to MAC addresses or IPv6 addresses. They are used internally by the software as unique identifiers, but generally are not exposed to end users. 9.1.2. Discovery Proxy The description of a Discovery Proxy consists of: name a machine-readable name used to reference this Discovery Proxy in provisioning. @@ -803,25 +830,26 @@ hr-name an optional human-readable name which can appear in provisioning, monitoring and debugging systems. Must be unique within a Discovery Domain. certificate a certificate that identifies the Discovery Relay. This certificate can be shared across services on the Discovery Relay Host. Indeed, if a Discovery Proxy and Discovery Relay are running on the same host, the same certificate can be used for both. The public key in the certificate uniquely identifies the - Discovery Relay and is used by the Discovery Proxy to verify that - it is talking to the intended Discovery Relay after a TLS - connection has been established. The certificate must either be - signed by its own key, or have a signature chain that can be - validated using PKIX authentication [RFC6125]. + Discovery Relay and is used by a Discovery Relay Client (e.g., a + Discovery Proxy) to verify that it is talking to the intended + Discovery Relay after a TLS connection has been established. The + certificate must either be signed by its own key, or have a + signature chain that can be validated using PKIX authentication + [RFC6125]. private-key the private key corresponding to the public key in the certificate. listen-tuple a list of IP address/port tuples that may be used to connect to the Discovery Relay. The relay may be configured to listen on all addresses on a single port, but this is not required, so the port as well as the address must be specified. multicast links a list of multicast links to which this relay is @@ -878,29 +906,29 @@ link downstairs-wifi link downstairs-wired client-whitelist main Proxy main certificate zzz address 203.1.113.1 Link upstairs-wifi id 1 - name Upstairs Wifi + hr-name Upstairs Wifi Link upstairs-wired id 2 hr-name Upstairs Wired Link downstairs-wifi id 3 - name Downstairs Wifi + hr-name Downstairs Wifi Link downstairs-wired id 4 hr-name Downstairs Wired 9.3. Discovery Proxy Private Configuration The Discovery Proxy configuration contains enough information to identify which Discovery Proxy is being configured, enumerate the list of multicast links it is intended to serve, and provide keying @@ -939,100 +967,80 @@ similar devices that may not be updated frequently. The BOOTP [RFC0951] protocol has been around since 1985, and continues to be useful today. The BOOTP protocol uses no encryption, and in many enterprise networks this is considered acceptable. In contrast, the Discovery Relay protocol requires TLS 1.3. A concern is that after 20 or 30 years, TLS 1.3, or some of the encryption algorithms it uses, may become obsolete, rendering devices that require it unusable. Our assessment is that TLS 1.3 probably will be around for many years to come. TLS 1.0 [RFC2246] was used for about a decade, and similarly TLS 1.2 [RFC5246] was also used for about a decade. We - expect TLS 1.3 [I-D.ietf-tls-tls13] to have at least that lifespan. - In addition, recent IETF efforts are pushing for better software - update practices for devices like routers, for other security - reasons, making it likely that in ten years time it will be less - common to be using routers that haven't had a software update for ten - years. However, authors of encryption specifications and libraries - should be aware of the potential backwards compatibility issues if an + expect TLS 1.3 [RFC8446] to have at least that lifespan. In + addition, recent IETF efforts are pushing for better software update + practices for devices like routers, for other security reasons, + making it likely that in ten years time it will be less common to be + using routers that haven't had a software update for ten years. + However, authors of encryption specifications and libraries should be + aware of the potential backwards compatibility issues if an encryption algorithm becomes deprecated. This specification RECOMMENDS that if an encryption algorithm becomes deprecated, then rather than remove that encryption algorithm entirely, encryption libraries should disable that encryption algorithm by default, but leave the code present with an option for client software to enable it in special cases, such as a recent Client talking to an ancient Discovery Relay. Using no encryption, like BOOTP, would eliminate this backwards compatibility concern, but we feel that in such a future hypothetical scenario, using even a weak encryption algorithm still makes passive eavesdropping and tampering harder, and is preferable to using no encryption at all. 11. IANA Considerations The IANA is kindly requested to update the DSO Type Codes Registry - [I-D.ietf-dnsop-session-signal] by allocating codes for each of the - TBD type codes listed in the following table, and by updating this - document, here and in Section 8. Each type code should list this - document as its reference document. + [RFC8490] by allocating codes for each of the TBD type codes listed + in the following table, and by updating this document, here and in + Section 8. Each type code should list this document as its reference + document. - +--------+----------+---------------------------+ - | Opcode | Status | Name | - +--------+----------+---------------------------+ + +----------+----------+---------------------------+ + | DSO-TYPE | Status | Name | + +----------+----------+---------------------------+ | TBD-R | Standard | Link Data Request | | TBD-D | Standard | Link Data Discontinue | | TBD-L | Standard | Link Identifier | | TBD-M | Standard | Encapsulated mDNS Message | | TBD-S | Standard | IP Source | | TBD-P | Standard | Link State Request | | TBD-Q | Standard | Link State Discontinue | | TBD-V | Standard | Link Available | | TBD-U | Standard | Link Unavailable | | TBD-K | Standard | Link Prefix | - +--------+----------+---------------------------+ + +----------+----------+---------------------------+ DSO Type Codes to be allocated 12. Acknowledgments - To be completed... + Thanks to Derek Atkins for the secdir early review. 13. References 13.1. Normative References - [I-D.ietf-dnsop-session-signal] - Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., - Lemon, T., and T. Pusateri, "DNS Stateful Operations", - draft-ietf-dnsop-session-signal-20 (work in progress), - December 2018. - - [I-D.ietf-dnssd-hybrid] - Cheshire, S., "Discovery Proxy for Multicast DNS-Based - Service Discovery", draft-ietf-dnssd-hybrid-08 (work in - progress), March 2018. - - [I-D.ietf-tls-tls13] - Rescorla, E., "The Transport Layer Security (TLS) Protocol - Version 1.3", draft-ietf-tls-tls13-28 (work in progress), - March 2018. - - [I-D.sctl-discovery-broker] - Cheshire, S. and T. Lemon, "Service Discovery Broker", - draft-sctl-discovery-broker-00 (work in progress), July - 2017. - [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . - [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions - for High Performance", RFC 1323, DOI 10.17487/RFC1323, May - 1992, . + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol @@ -1040,45 +1048,76 @@ . [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, DOI 10.17487/RFC6762, February 2013, . [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, . + [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. + Scheffenegger, Ed., "TCP Extensions for High Performance", + RFC 7323, DOI 10.17487/RFC7323, September 2014, + . + [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles for DNS over TLS and DNS over DTLS", RFC 8310, DOI 10.17487/RFC8310, March 2018, . + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + . + + [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., + Lemon, T., and T. Pusateri, "DNS Stateful Operations", + RFC 8490, DOI 10.17487/RFC8490, March 2019, + . + + [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based + Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June + 2020, . + 13.2. Informative References [AdFam] "IANA Address Family Numbers Registry", - . + . + + [AdProx] Cheshire, S. and T. Lemon, "Advertising Proxy for DNS-SD + Service Registration Protocol", draft-sctl-advertising- + proxy-00 (work in progress), July 2020. [I-D.ietf-mboned-ieee802-mcast-problems] Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless - Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work - in progress), November 2018. + Media", draft-ietf-mboned-ieee802-mcast-problems-11 (work + in progress), December 2019. + + [I-D.sctl-discovery-broker] + Cheshire, S. and T. Lemon, "Service Discovery Broker", + draft-sctl-discovery-broker-00 (work in progress), July + 2017. [NOTSENT] Dumazet, E., "TCP_NOTSENT_LOWAT socket option", July 2013, . [PRIO] Chan, W., "Prioritization Only Works When There's Pending Data to Prioritize", January 2014, . [RFC0951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, @@ -1094,25 +1133,26 @@ DOI 10.17487/RFC5246, August 2008, . [TR-069] Broadband Forum, "CPE WAN Management Protocol", November 2013, . Authors' Addresses Ted Lemon - Nibbhaya Consulting - P.O. Box 958 - Brattleboro, Vermont 05301 + Apple Inc. + One Apple Park Way + Cupertino, California 95014 United States of America - Email: mellon@fugue.com + Phone: +1 (408) 996-1010 + Email: elemon@apple.com Stuart Cheshire Apple Inc. One Apple Park Way Cupertino, California 95014 - USA + United States of America Phone: +1 (408) 996-1010 Email: cheshire@apple.com