| Internet-Draft | RADIUS for Encrypted DNS | June 2022 |
| Boucadair & Reddy | Expires 9 December 2022 | [Page] |
This document specifies new Remote Authentication Dial-In User Service (RADIUS) attributes that carry an authentication domain name, a list of IP addresses, and a set of service parameters of encrypted DNS resolvers.¶
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 9 December 2022.¶
Copyright (c) 2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
In the context of broadband services, ISPs traditionally provide DNS resolvers to their customers. To that aim, ISPs deploy dedicated mechanisms to advertise a list of DNS Recursive DNS server(s) to their customers (e.g., DHCP, IPv6 Router Advertisement). The information used to populate DHCP messages and/or IPv6 Router Advertisements relies upon specific Remote Authentication Dial-In User Service (RADIUS) [RFC2865] attributes such as the DNS-Server-IPv6-Address Attribute specified in [RFC6911].¶
With the advent of Encrypted DNS (e.g., DNS-over-HTTPS (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ) [RFC9250]), additional means are required to provision hosts with network-designated Encrypted DNS. To fill that void, [I-D.ietf-add-dnr] leverages existing protocols such as DHCP and IPv6 Router Advertisement to provide hosts with the required information to connect to an Encrypted DNS server. However, there are no RADIUS attributes that can be used to populate the discovery messages discussed in [I-D.ietf-add-dnr].¶
This document specifies two new RADIUS attributes: IPv6-Encrypted-DNS (Section 3.1) and IPv4-Encrypted-DNS (Section 3.2) Attributes. These two attributes are specified in order to accommodate both IPv4 and IPv6 deployment contexts while taking into account the constraints in Section 3.4 of [RFC6158].¶
Typical deployment scenarios are similar to those described, for instance, in Section 2 of [RFC6911]. Some of these deployments may rely upon the mechanisms defined in [RFC4014] or [RFC7037], which allows a Network Access Server (NAS) to pass attributes obtained from a RADIUS server to a DHCP server. For illustration purposes, Figure 1 shows an example where a Customer Premises Equipment (CPE) is provided with an Encrypted DNS server. This example assumes that the NAS embeds both RADIUS client and DHCPv6 server capabilities.¶
+-------------+ +-------------+ +-------+
| CPE | | NAS | | AAA |
|DHCPv6 client| |DHCPv6 server| |Server |
+------+------+ +------+------+ +---+---+
| | |
o-----DHCPv6 Solicit----->| |
| o----Access-Request ---->|
| | |
| |<----Access-Accept------o
| | IPv6-Encrypted-DNS |
|<--DHCPv6 Advertisement--o |
| (OPTION_V6_DNR) | |
| | |
o-----DHCPv6 Request----->| |
| | |
|<------DHCPv6 Reply------o |
| (OPTION_V6_DNR) | |
| | |
DHCPv6 RADIUS
Upon receipt of the DHCPv6 Solicit message from a CPE, the NAS sends a RADIUS Access-Request message to the Authentication, Authorization, and Accounting (AAA) server. Once the AAA server receives the request, it replies with an Access-Accept message (possibly after having sent a RADIUS Access-Challenge message and assuming the CPE is entitled to connect to the network) that carries a list of parameters to be used for this session, and which include the Encrypted DNS information. The content of the IPv6-Encrypted-DNS Attribute is then used by the NAS to complete the DHCPv6 procedure that the CPE initiated to retrieve information about the encrypted DNS service to use. The procedure defined in [I-D.ietf-add-dnr] is thus followed between the DHCPv6 client and the DHCPv6 server. The same procedure is followed between the DHCPv6 client on endpoints serviced by the CPE and the DHCPv6 server on CPE.¶
Upon change of the any Encrypted DNS-related information (e.g., ADN, IPv6 address), the RADIUS server sends a RADIUS CoA message [RFC5176] that carries the RADIUS IPv6-Encrypted-DNS Attributed to the NAS. Once that message is accepted by the NAS, it replies with a RADIUS CoA ACK message. The NAS replaces the old Encrypted DNS server information with the new one and sends a DHCPv6 Reconfigure message to cause the DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6 server.¶
Figure 2 shows another example where a CPE is provided with an Encrypted DNS server, but the CPE uses DHCPv4 to retrieve its Encrypted DNS server.¶
+-------------+ +-------------+ +-------+
| CPE | | NAS | | AAA |
|DHCPv4 client| |DHCPv4 server| |Server |
+------+------+ +------+------+ +---+---+
| | |
o------DHCPDISCOVER------>| |
| o----Access-Request ---->|
| | |
| |<----Access-Accept------o
| | IPv4-Encrypted-DNS |
|<-----DHCPOFFER----------o |
| (OPTION_V4_DNR) | |
| | |
o-----DHCPREQUEST-------->| |
| (OPTION_V4_DNR) | |
| | |
|<-------DHCPACK----------o |
| (OPTION_V4_DNR) | |
| | |
DHCPv4 RADIUS
Other deployment scenarios can be envisaged, such as returning customized service parameters (e.g., different DoH URI) as a function of the service/policies/preferences that are set by a home network administrator. How an administrator indicates its service/policies/preferences to an AAA server is out of scope.¶
This document adheres to [RFC8044] for defining the new attributes.¶
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.¶
This document makes use of the terms defined in [RFC8499]. The following additional terms are used:¶
Both IPv6-Encrypted-DNS and IPv4-Encrypted-DNS have the same format shown in Figure 3. The description of the fields is provided in Sections 3.1 and 3.2.¶
These attributes and their embedded TLVs (Section 3.3) are defined with globally unique names and follow the guidelines in Section 2.7.1 of [RFC6929].¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value fields of *-Encrypted-DNS and Encrypted-DNS-* Attributes are encoded in clear and not encrypted as, for example, Tunnel-Password Attribute [RFC2868].¶
This attribute is of type "tlv" as defined in Section 2.3 of [RFC6929].¶
The IPv6-Encrypted-DNS Attribute includes the authentication domain name, a list of IPv6 addresses, and a set of service parameters of an encrypted DNS resolver [I-D.ietf-add-dnr].¶
Because multiple IPv6-Encrypted-DNS Attributes may be provisioned to a requesting host, multiple instances of the IPv6-Encrypted-DNS attribute MAY be included; each instance of the attribute carries a distinct Encrypted DNS server. These TLVs SHOULD be processed following their service priority (i.e., smaller service priority indicates a higher preference).¶
The IPv6-Encrypted-DNS Attribute MAY appear in a RADIUS Access-Accept packet. It MAY also appear in a RADIUS Access-Request packet as a hint to the RADIUS server to indicate a preference. However, the server is not required to honor such a preference.¶
The IPv6-Encrypted-DNS Attribute MAY appear in a RADIUS CoA-Request packet.¶
The IPv6-Encrypted-DNS Attribute MAY appear in a RADIUS Accounting-Request packet.¶
The IPv6-Encrypted-DNS Attribute MUST NOT appear in any other RADIUS packet.¶
The IPv6-Encrypted-DNS Attribute is structured as follows:¶
Type¶
Length¶
Extended-Type¶
Value¶
This field contains a set of TLVs as follows:¶
The IPv6-Encrypted-DNS Attribute is associated with the following identifier: 241.TBA1.¶
This attribute is of type "tlv" as defined in Section 2.3 of [RFC6929].¶
The IPv4-Encrypted-DNS Attribute includes the authentication domain name, a list of IPv4 addresses, and a set of service parameters of an encrypted DNS resolver [I-D.ietf-add-dnr].¶
Because multiple IPv4-Encrypted-DNS attributes may be provisioned to a requesting host, multiple instances of the IPv4-Encrypted-DNS attribute MAY be included; each instance of the attribute carries a distinct Encrypted DNS server. These TLVs SHOULD be processed following their service priority (i.e., smaller service priority indicates a higher preference).¶
The IPv4-Encrypted-DNS Attribute MAY appear in a RADIUS Access-Accept packet. It MAY also appear in a RADIUS Access-Request packet as a hint to the RADIUS server to indicate a preference. However, the server is not required to honor such a preference.¶
The IPv4-Encrypted-DNS Attribute MAY appear in a RADIUS CoA-Request packet.¶
The IPv4-Encrypted-DNS Attribute MAY appear in a RADIUS Accounting-Request packet.¶
The IPv4-Encrypted-DNS Attribute MUST NOT appear in any other RADIUS packet.¶
The IPv4-Encrypted-DNS Attribute is structured as follows:¶
Type¶
Length¶
Extended-Type¶
Value¶
This field contains a set of TLVs as follows:¶
The IPv4-Encrypted-DNS Attribute is associated with the following identifier: 241.TBA2.¶
The TLVs defined in the following subsections use the format defined in [RFC6929]. These TLVs have the same name and number when encapsulated in any of the parent attributes defined in Sections 3.1 and 3.2.¶
The encoding of the "Value" field of these TLVs follows the recommendation of [RFC6158].¶
TLV-Type¶
TLV-Length¶
Data Type¶
TLV-Value¶
This TLV is identified as 241.TBA1.TBA3 when included in the IPv6-Encrypted-DNS Attribute (Section 3.1) and as 241.TBA2.TBA3 when included in the IPv4-Encrypted-DNS Attribute (Section 3.2).¶
TLV-Type¶
TLV-Length¶
Data Type¶
TLV-Value¶
This field includes an IPv6 address (128 bits) of the Encrypted DNS server.¶
The Encrypted-DNS-IPv6-Address attribute MUST NOT include multicast and host loopback addresses [RFC6890].¶
This TLV is identified as 241.TBA1.TBA4 as part of the IPv6-Encrypted-DNS Attribute (Section 3.1).¶
TLV-Type¶
TLV-Length¶
Data Type¶
TLV-Value¶
This field includes an IPv4 address (32 bits) of the Encrypted DNS server.¶
The Encrypted-DNS-IPv4-Address attribute MUST NOT include multicast and host loopback addresses.¶
This TLV is identified as 241.TBA1.TBA5 as part of the IPv4-Encrypted-DNS Attribute (Section 3.2).¶
TLV-Type¶
TLV-Length¶
Data Type¶
TLV-Value¶
Specifies a set of service parameters that are encoded following the rules in Section 2.1 of [I-D.ietf-dnsop-svcb-https]. At least the following service parameters are RECOMMENDED to be supported by an implementation:¶
The service parameters MUST NOT include "ipv4hint" or "ipv6hint" SvcParams as they are superseded by the included IP addresses.¶
This TLV is identified as 241.TBA1.TBA6 when included in the IPv6-Encrypted-DNS Attribute (Section 3.1) and as 241.TBA2.TBA6 when included in the IPv4-Encrypted-DNS Attribute (Section 3.2).¶
TLV-Type¶
TLV-Length¶
Data Type¶
TLV-Value¶
This TLV is identified as 241.TBA1.TBA7 when included in the IPv6-Encrypted-DNS Attribute (Section 3.1) and as 241.TBA2.TBA7 when included in the IPv4-Encrypted-DNS Attribute (Section 3.2).¶
RADIUS-related security considerations are discussed in [RFC2865].¶
This document targets deployments where a trusted relationship is in place between the RADIUS client and server with communication optionally secured by IPsec or Transport Layer Security (TLS) [RFC6614].¶
Security considerations (including traffic theft) are discussed in [I-D.ietf-add-dnr].¶
The following table provides a guide as what type of RADIUS packets that may contain these attributes, and in what quantity.¶
Access- Access- Access- Challenge Acct. # Attribute Request Accept Reject Request 0+ 0+ 0 0 0+ TBA1 IPv6-Encrypted-DNS 0+ 0+ 0 0 0+ TBA2 IPv4-Encrypted-DNS CoA-Request CoA-ACK CoA-NACK # Attribute 0+ 0 0 TBA1 IPv6-Encrypted-DNS 0+ 0 0 TBA1 IPv4-Encrypted-DNS¶
The following table defines the meaning of the above table entries:¶
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet.¶
IANA is requested to assign two new RADIUS attribute types from the IANA registry "Radius Attribute Types" located at http://www.iana.org/assignments/radius-types:¶
Type Description Data Type Reference -------- ------------------ --------- ------------- 241.TBA1 IPv6-Encrypted-DNS tlv This-Document 241.TBA2 IPv4-Encrypted-DNS tlv This-Document¶
IANA is requested to create a new registry called "RADIUS Encrypted DNS TLVs". The registry is initially populated as follows:¶
Value Description Data Type Reference ----- ------------------------- --------- ------------- 0 Reserved 1 Encrypted-DNS-ADN text Section 3.3.1 2 Encrypted-DNS-IPv6-Address ipv6addr Section 3.3.2 3 Encrypted-DNS-IPv4-Address ipv4addr Section 3.3.3 4 Encrypted-DNS-SvcParams string Section 3.3.4 5 Encrypted-DNS-SvcPriority integer Section 3.3.5 6-255 Unassigned¶
Thanks to Christian Jacquenet, Neil Cook, and Alan Dekok for the review and suggestions.¶
Thanks to Ben Schwartz for the comments.¶