| Homenet | D. Migault |
| Internet-Draft | Ericsson |
| Intended status: Standards Track | R. Weber |
| Expires: October 21, 2020 | Akamai |
| T. Mrugalski | |
| Internet Systems Consortium, Inc. | |
| C. Griffiths | |
| W. Cloetens | |
| April 19, 2020 |
DHCPv6 Options for Home Network Authoritative Naming Service
draft-ietf-homenet-naming-architecture-dhc-options-07
This document defines DHCPv6 options so any agnostic Homnet Naming Authority (HNA) can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. In most cases, the outsourcing mechanism is transparent for the end user.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 21, 2020.
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 described in the Simplified BSD License.
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.
The reader is expected to be familiar with [I-D.ietf-homenet-front-end-naming-delegation] and its terminology section. This section defines terms that have not been defined in [I-D.ietf-homenet-front-end-naming-delegation]:
[I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet Naming Authority (HNA) outsources the Public Homenet Zone to an Outsourcing Infrastructure.
In most cases the setting of the relation between the HNA and the Outsourcing Infrastructure is not fully automated and involves the end user. More specifically, the Outsourcing Infrastructure needs to be able to authenticate the HNA as well as needs to ensure the HNA owns the Registered Homenet Domain. As a result, the Outsourcing Infrastructure is likely to be provided by a registrar.
This document describes DHCPv6 options that leverage a relation between the ISP and an end user to fully automated these steps. This enables an end user to provide the home network configuration to the DHCPv6 server, so an HNA can outsource without any configuration. In this case, outsourcing is achieved with zero-config and is resilient to HNA change. This may provide the ability for an ISP to provide a default outsourcing service to its customers, however this service can be used by the end user for any specific Homenet registered domain, not just the ones provided by the ISP and as such benefits the end user.
The overall principle is that the HNA advertises the DHCPv6 server of its Public Key. This Public Key will be used by the HNA for the authentication during the TLS key exchange between the HNA and the Distribution Master (DM) of the Public Homenet Zone and the Reverse Homenet Zone. Note that a specific relation between the DHCPv6 server and the DM is required. When the DHCPv6 server is managed by the ISP, such relation exist between DHCPv6 server and the DM of the Reverse Homenet Zone. Such relation may also exist - but not necessarily - between the DHCPv6 server and the DM of the Public Homenet Zone. The DHCHv6 server provides the HNA the FQDN and Public Keys of the respective DMs.
This document assumes the link between the HNA and the DHCPv6 server is trustworthy for example using [I-D.ietf-dhc-sedhcpv6].
This section illustrates how a HNA receives the necessary information via DHCPv6 options to outsource its authoritative naming service on the Outsourcing Infrastructure. For the sake of simplicity, this section assumes that the DHCPv6 server is able to communicate to the various DNS servers and to provide them the public key associated with the HNA. Once each server got the public key, the HNA can proceed to transactions in an authenticated and secure way.
This scenario has been chosen as it is believed to be the most popular scenario. This document does not ignore scenarios where the DHCP Server does not have privileged relations with the DM.
These cases are discussed latter in Section 9. Such scenario does not necessarily require configuration for the end user and can also be zero-config.
The scenario is as follows:
This section details the payload of the DHCPv6 options.
The Client Public Key Option (OPTION_PUBLIC_KEY) indicates the Client Public Key that is used to authenticate the HNA. This option is defined in [I-D.ietf-dhc-sedhcpv6].
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PUBLIC_KEY | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | / Public Key Data / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{ #fig-public-key title=”Client Public Key Option”}
The Synchronization Server Option (OPTION_SYNC_SERVER) provides information necessary for the HNA to upload the Homenet Zone to the Synchronization Server. Finally, the option provides the authentication methods that are available to perform the upload. The upload is performed via a DNS primary / secondary architecture or DNS updates.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DIST_MASTER | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / DM FQDN / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{ #fig-name-srv-set title=”Synchronization Server Option”}
The Reverse Synchronization Server Option (OPTION_REVERSE_SYNC_SERVER) provides information necessary for the HNA to upload the Homenet Zone to the Synchronization Server. The option provides the authentication methods that are available to perform the upload. The upload is performed via a DNS primary / secondary architecture or DNS updates.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_DIST_MASTER | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Server Port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | / Reverse DM FQDN / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Reverse Synchronization Server Option
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regards to option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it. In particular, when configured the DHCP Server sends the Zone Template Option, Synchronization Server Option, Reverse Synchronization Server Option when requested by the DHCPv6 client by including necessary option codes in its ORO.
The DHCP Server may receive a Client Public Key Option (OPTION_PUBLIC_KEY) from the HNA. Upon receipt of this DHCPv6 option, the DHCP Server SHOULD acknowledge the reception of the Client Public Key Option as described and communicate this credential to the available DM and Reverse DM unless not configured to do so.
A HNA may update its Client Public Key by sending a new value in the Client Public Key Option (OPTION_PUBLIC_KEY) as this document assumes the link between the HNA and the DHCP Server is considered authenticated and trusted. The server SHOULD process received Client Public Key Option sent by the client unless not configured to do so.
The DHCPv6 client SHOULD send a Client Public Key Option (OPTION_PUBLIC_KEY) to the DHCP Server. This Client Public Key authenticates the HNA.
The DHCPv6 client sends a ORO with the necessary option codes: Zone Template Option, Synchronization Server Option and Reverse Synchronization Server Option.
Upon receiving a DHCP option described in this document in the Reply message, the HNA SHOULD publish the zone as described in [I-D.ietf-homenet-front-end-naming-delegation].
There are no additional requirements for the DHCP Relay agents.
The DHCP options detailed in this document is: * OPTION_CLIENT_KEY: TBD1 * OPTION_REGISTERED_DOMAIN: TBD2 * OPTION_SYNC_SERVER: TBD3 * OPTION_REVERSE_SYNC_SERVER: TBD4
It is recommended that the (Reverse) Homenet Zone is signed with DNSSEC. The zone may be signed by the HNA or by a third party. We recommend the zone to be signed by the HNA, and that the signed zone is uploaded.
The channel MUST be secured because the HNA provides authentication credentials. Unsecured channel may result in HNA impersonation attacks.
The document considers that the channel between the HNA and the ISP DHCP Server is trusted. More specifically, the HNA is authenticated and the exchanged messages are protected. The current document does not specify how to secure the channel. [RFC3315] proposes a DHCP authentication and message exchange protection, [RFC4301], [RFC7296] propose to secure the channel at the IP layer.
HNA have not been designed for handling heavy load. The HNA are exposed on the Internet, and their IP address is publicly published on the Internet via the DNS. This makes the Home Network sensitive to Deny of Service Attacks. The resulting outsourcing architecture is described in [I-D.ietf-homenet-front-end-naming-delegation]. This document shows how the outsourcing architecture can be automatically set.
We would like to thank Marcin Siodelski and Bernie Volz for their comments on the design of the DHCPv6 options. We would also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their remarks on the architecture design. The designed solution has been largely been inspired by Mark Andrews’s document [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We also thank Ray Hunter for its reviews, its comments and for suggesting an appropriated terminology.
This section details various scenarios and discuss their impact on the end user.
The base scenario is the one described in Section 3. It is typically the one of an ISP that manages the DHCP Server, and all DNS servers.
The end user subscribes to the ISP (foo), and at subscription time registers for example.foo as its Registered Homenet Domain example.foo.
When the HNA is plugged (at least the first time), it provides its Client Public Key to the DHCP Server. In this scenario, the DHCP Server and the DNS Servers are managed by the ISP so the DHCP Server can provide authentication credentials of the HNA to enable secure authenticated transaction with the DM and the Reverse DM.
The main advantage of this scenario is that the naming architecture is configured automatically and transparently for the end user. The drawbacks are that the end user uses a Registered Homenet Domain managed by the ISP and that it relies on the ISP naming infrastructure.
This section considers the case when the end user wants its home network to use example.com as a Registered Homenet Domain instead of example.foo that has been assigned by the ISP. We also suppose that example.com is not managed by the ISP.
This can also be achieved without any configuration. When the end user buys the domain name example.com, it may request to redirect the name example.com to example.foo using static redirection with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME [I-D.sury-dnsext-cname-dname].
This configuration is performed once when the domain name example.com is registered. The only information the end user needs to know is the domain name assigned by the ISP. Once this configuration is done no additional configuration is needed anymore. More specifically, the HNA may be changed, the zone can be updated as in Section 10 without any additional configuration from the end user.
The main advantage of this scenario is that the end user benefits from the Zero Configuration of the Base Scenario Section 10. Then, the end user is able to register for its home network an unlimited number of domain names provided by an unlimited number of different third party providers.
The drawback of this scenario may be that the end user still rely on the ISP naming infrastructure. Note that the only case this may be inconvenient is when the DNS Servers provided by the ISPs results in high latency.
This scenario considers that the end user uses example.com as a Registered Homenet Domain, and does not want to rely on the authoritative servers provided by the ISP.
In this section we limit the outsourcing to the DM and Public Authoritative Server(s) to a third party. The Reverse Public Authoritative Server(s) and Reverse Synchronization Server remain managed by the ISP as the IP prefix is managed by the ISP.
Outsourcing DM and Public Authoritative Server(s) requires:
The main advantage of this scenario is that the DNS infrastructure is completely outsourced to the third party. Most likely the Client Public Key that authenticate the HNA needs to be configured for every HNA. Configuration is expected to be HNA live-long.
This scenario considers a HNA connected to multiple ISPs.
Suppose the HNA has been configured each of its interfaces independently with each ISPS as described in Section 10. Each ISP provides a different Registered Homenet Domain. The HNA Client Public Key may be shared between the HNA and the multiple ISPs.
The protocol and DHCPv6 options described in this document are fully compatible with a HNA connected to multiple ISPs with multiple Registered Homenet Domains. However, the HNA should be able to handle different Registered Homenet Domains. This is an implementation issue which is outside the scope of the current document.
If a HNA is not able to handle multiple Registered Homenet Domains, the HNA may remain connected to multiple ISP with a single Registered Homenet Domain. In this case, the one party is chosen to host the Registered Homenet Domain.
This entity may be one of the ISP or a third party. Note that having multiple ISPs can be motivated for bandwidth aggregation, or connectivity fail-over. In the case of connectivity fail-over, the fail-over concerns the access network and a failure of the access network may not impact the core network where the DM Server and Public Authoritative Primaries are hosted. In that sense, choosing one of the ISP even in a scenario of multiple ISPs may make sense. However, for sake of simplicity, this scenario assumes that a third party has be chosen to host the Registered Homenet Domain. The DNS settings for each ISP is described in Section 10.1 and Section 10.2. With the configuration described in Section 10.1, the HNA is expect to be able to handle multiple Homenet Registered Domain, as the third party redirect to one of the ISPs Servers. With the configuration described in Section 10.2, DNS zone are hosted and maintained by the third party. A single DNS(SEC) Homenet Zone is built and maintained by the HNA. This latter configuration is likely to match most HNA implementations.
The protocol and DHCPv6 options described in this document are fully compatible with a HNA connected to multiple ISPs. To configure or not and how to configure the HNA depends on the HNA facilities. Section 10 and Section 10.1 require the HNA to handle multiple Registered Homenet Domain, whereas Section 10.2 does not have such requirement.
| [I-D.andrews-dnsop-pd-reverse] | Andrews, M., "Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation", Internet-Draft draft-andrews-dnsop-pd-reverse-02, November 2013. |
| [I-D.ietf-dhc-sedhcpv6] | Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T. and D. Zhang, "Secure DHCPv6", Internet-Draft draft-ietf-dhc-sedhcpv6-21, February 2017. |
| [I-D.ietf-homenet-front-end-naming-delegation] | Migault, D., Weber, R., Richardson, M., Hunter, R., Griffiths, C. and W. Cloetens, "Outsourcing Home Network Authoritative Naming Service", Internet-Draft draft-ietf-homenet-front-end-naming-delegation-10, March 2020. |
| [I-D.sury-dnsext-cname-dname] | Sury, O., "CNAME+DNAME Name Redirection", Internet-Draft draft-sury-dnsext-cname-dname-00, April 2010. |