--- 1/draft-ietf-dnssd-mdns-relay-01.txt 2019-03-11 15:20:18.174297774 -0700 +++ 2/draft-ietf-dnssd-mdns-relay-02.txt 2019-03-11 15:20:18.426303945 -0700 @@ -1,19 +1,19 @@ Network Working Group T. Lemon Internet-Draft Nibbhaya Consulting Intended status: Standards Track S. Cheshire -Expires: January 3, 2019 Apple Inc. - July 2, 2018 +Expires: September 12, 2019 Apple Inc. + March 11, 2019 Multicast DNS Discovery Relay - draft-ietf-dnssd-mdns-relay-01 + draft-ietf-dnssd-mdns-relay-02 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 +24,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 January 3, 2019. + This Internet-Draft will expire on September 12, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + Copyright (c) 2019 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 @@ -64,34 +64,34 @@ 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.7. Link State Discontinue . . . . . . . . . . . . . . . . . 16 8.8. Link Available . . . . . . . . . . . . . . . . . . . . . 16 8.9. Link Unavailable . . . . . . . . . . . . . . . . . . . . 16 8.10. Link Prefix . . . . . . . . . . . . . . . . . . . . . . . 16 9. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 18 - 9.1. Provisioned Objects . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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 Discovery [RFC6763]. @@ -292,42 +292,63 @@ 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 responds to the TLS Client Hello message from the - Client with a TLS user_canceled alert ([I-D.ietf-tls-tls13] - Section 6.1). + 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. 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, the Discovery Relay rejects the connection with a certificate_required alert ([I-D.ietf-tls-tls13] 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). + 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, + the client may be configured with the server's FQDN. In this case, + the client uses the server's FQDN as a Authentication Domain Name + [RFC8310] Section 7.1, and uses the authentication method described + 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 [RFC1035]. + 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. 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 @@ -645,20 +666,30 @@ Discovery Relays within such a network will be referred to in this section as a 'Discovery Domain'. Depending on the context, several different candidates for configuration of Discovery Proxies and Discovery Relays may be applicable. The simplest such mechanism is a manual configuration file, but regardless of provisioning mechanism, certain configuration information needs to be communicated to the devices, as outlined below. + In the example we provide here, we only refer to configuring of IP + addresses, private keys and certificates. It is also possible to use + FQDNs to identify servers; this then allows for the use of DANE + ([RFC8310] Section 8.2) or PKIX authentication [RFC6125]. Which + method is used is to some extent up to the implementation, but at a + minimum, it should be possible to associate an IP address with a + self-signed certificate, and it should be possible to validate both + self-signed and PKIX-authenticated certificates, with PKIX, DANE or a + pre-configured trust anchor. + 9.1. Provisioned Objects Three types of objects must be described in order for Discovery Proxies and Discovery Relays to be provisioned: Discovery Proxies, Multicast Links, and Discovery Relays. "Human-readable" below means actual words or proper names that will make sense to an untrained human being. "Machine-readable" means a name that will be used by machines to identify the entity to which the name refers. Each entity must have a machine-readable name and may have a human- readable name. No two entities can have the same human-readable @@ -719,26 +750,28 @@ The description of a Discovery Proxy consists of: name a machine-readable name used to reference this Discovery Proxy in provisioning. hr-name an optional human-readable name which can appear in provisioning, monitoring and debugging systems. Must be unique within a Discovery Domain. - public-key a public key that identifies the Discovery Proxy. This - key can be shared across services on the Discovery Proxy Host. - The public key is used both to uniquely identify the Discovery - Proxy and to authenticate connections from it. + certificate a certificate that identifies the Discovery Proxy. This + certificate can be shared across services on the Discovery Proxy + Host. The public key in the certificate is used both to uniquely + identify the Discovery Proxy and to authenticate connections from + it. The certificate should be signed by its own private key. - private-key the private key corresponding to the public key. + private-key the private key corresponding to the public key in the + certificate. source-ip-addresses a list of IP addresses that may be used by the Discovery Proxy when connecting to Discovery Relays. These addresses should be addresses that are configured on the Discovery Proxy Host. They should not be temporary addresses. All such addresses must be reachable within the Discovery Domain. public-ip-addresses a list of IP addresses that a Discovery Proxy listens on to receive requests from clients. This is not used for interoperation with Discovery Relays, but is mentioned here for @@ -765,29 +798,33 @@ The description of a Discovery Relay consists of: name a required machine-readable identifier used to reference the relay hr-name an optional human-readable name which can appear in provisioning, monitoring and debugging systems. Must be unique within a Discovery Domain. - public-key a public key that identifies the Discovery Relay. This - key 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 key may be used for both. The public key - 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. + 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]. - private-key the private key corresponding to the public key. + 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 physically connected. The private key should never be distributed to other hosts; all of @@ -820,37 +857,37 @@ by name. This approach is not required, but is simply shown as an example. In addition, the private keys for each proxy or relay must appear only in that proxy or relay's configuration file. The master file contains a list of Discovery Relays, Discovery Proxies and Multicast Links. Each object has a name and all the other data associated with it. We do not formally specify the format of the file, but it might look something like this: Relay upstairs - public-key xxx + certificate xxx listen-tuple 192.0.2.1 1917 listen-tuple fd00::1 1917 link upstairs-wifi link upstairs-wired client-whitelist main Relay downstairs - public-key yyy + certificate yyy listen-tuple 192.51.100.1 2088 listen-tuple fd00::2 2088 link downstairs-wifi link downstairs-wired client-whitelist main Proxy main - public-key zzz + certificate zzz address 203.1.113.1 Link upstairs-wifi id 1 name Upstairs Wifi Link upstairs-wired id 2 hr-name Upstairs Wired @@ -882,22 +919,22 @@ subscribe downstairs-wired When combined with the master file, this configuration is sufficient for the Discovery Proxy to identify and connect to the Discovery Relays that serve the links it is configured to support. 9.4. Discovery Relay Private Configuration The Discovery Relay configuration just needs to tell the Discovery Relay what name to use to find its configuration in the master file, - and what the private key is corresponding to its public key in the - master file. For example: + and what the private key is corresponding to its certificate (public + key) in the master file. For example: Relay Downstairs private-key yyy 10. Security Considerations Part of the purpose of the Multicast DNS Discovery Relay protocol is to place a simple relay, analogous to a BOOTP relay, into routers and similar devices that may not be updated frequently. The BOOTP [RFC0951] protocol has been around since 1985, and continues to be @@ -957,22 +994,22 @@ To be completed... 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-10 (work in progress), - June 2018. + 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. @@ -983,56 +1020,73 @@ 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, . + [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 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [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, . + [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, . + [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, + . + 13.2. Informative References [AdFam] "IANA Address Family Numbers Registry", . [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-01 (work - in progress), February 2018. + Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work + in progress), November 2018. - [NOTSENT] "TCP_NOTSENT_LOWAT socket option", July 2013, + [NOTSENT] Dumazet, E., "TCP_NOTSENT_LOWAT socket option", July 2013, . - [PRIO] "Prioritization Only Works When There's Pending Data to - Prioritize", January 2014, . + [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, DOI 10.17487/RFC0951, September 1985, . [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security @@ -1048,16 +1103,16 @@ Ted Lemon Nibbhaya Consulting P.O. Box 958 Brattleboro, Vermont 05301 United States of America Email: mellon@fugue.com Stuart Cheshire Apple Inc. - 1 Infinite Loop + One Apple Park Way Cupertino, California 95014 USA - Phone: +1 408 974 3207 + Phone: +1 (408) 996-1010 Email: cheshire@apple.com