Internet-Draft RADIUS for Encrypted DNS October 2022
Boucadair & Reddy Expires 8 April 2023 [Page]
Workgroup:
opsawg
Internet-Draft:
draft-ietf-opsawg-add-encrypted-dns-02
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Boucadair
Orange
T. Reddy
Nokia

RADIUS Extensions for Encrypted DNS

Abstract

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.

Status of This Memo

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 8 April 2023.

▲

Table of Contents

1. Introduction

In the context of broadband services, Internet Service Providers (ISPs) usually provide DNS resolvers to their customers. To that aim, ISPs deploy dedicated mechanisms (e.g., DHCP [RFC2132] [RFC8415], IPv6 Router Advertisement [RFC4861]) to advertise a list of DNS recursive servers to their customers. Typically, 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 resolver. 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 resolver. 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
Figure 1: An Example of RADIUS IPv6 Encrypted DNS Exchange

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 Discovery of Network-designated Resolvers (DNR) procedure defined in [I-D.ietf-add-dnr] is then followed between the DHCPv6 client and the DHCPv6 server.

Should any encrypted DNS-related information (e.g., Authentication Domain Name (ADN), IPv6 address) change, the RADIUS server sends a RADIUS Change-of-Authorization (CoA) message [RFC5176] that carries the RADIUS IPv6-Encrypted-DNS Attributes to the NAS. Once that message is received and validated by the NAS, it replies with a RADIUS CoA ACK message. The NAS replaces the old encrypted DNS resolver information with the new one and sends a DHCPv6 Reconfigure message which leads the DHCPv6 client to initiate a Renew/Reply message exchange with the DHCPv6 server.

In deployments where the NAS behaves as a DHCPv6 relay agent, the procedure discussed in Section 3 of [RFC7037] can be followed. To that aim, Section 6.3 updates the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" registry ([DHCP-RADIUS]).

Figure 2 shows another example where a CPE is provided with an encrypted DNS resolver, but the CPE uses DHCPv4 to retrieve its encrypted DNS resolver.

+-------------+           +-------------+             +-------+
|     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
Figure 2: An Example of RADIUS IPv4 Encrypted DNS Exchange

Other deployment scenarios can be envisaged, such as returning customized service parameters (e.g., different DoH URI Templates) as a function of the service/policies/preferences that are set by a 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.

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.

This document makes use of the terms defined in [RFC8499]. The following additional terms are used:

DHCP:
refers to both DHCPv4 [RFC2132] and DHCPv6 [RFC8415].
Encrypted DNS:
refers to a scheme where DNS exchanges are transported over an encrypted channel. Examples of encrypted DNS are DoT, DoH, and DoQ.
Encrypted DNS resolver:
refers to a resolver (Section 6 of [RFC8499]) that supports encrypted DNS.
*-Encrypted-DNS:
refers to IPv6-Encrypted-DNS and IPv4-Encrypted-DNS Attributes.
Encrypted-DNS-*:
refers to any of the following attributes: Encrypted-DNS-ADN, Encrypted-DNS-IPv6-Address, Encrypted-DNS-IPv4-Address, Encrypted-DNS-SvcParams, and Encrypted-DNS-SvcPriority.

3. Encrypted DNS RADIUS Attributes

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. The definition of the attributes follows 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 ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of IPv6-Encrypted-DNS and IPv4-Encrypted-DNS Attributes

The value fields of *-Encrypted-DNS and Encrypted-DNS-* Attributes are encoded in clear and not encrypted as, for example, Tunnel-Password Attribute [RFC2868].

3.1. IPv6-Encrypted-DNS Attribute

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 (Section 3.1.9 of [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 resolver. 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

  • This field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and the entire length of the embedded TLVs.

Extended-Type

Value

  • This field contains a set of TLVs as follows:

    Encrypted-DNS-ADN TLV:
    The IPv6-Encrypted-DNS Attribute MUST include exactly one instance of Encrypted-DNS-ADN TLV (Section 3.3.1).
    Encrypted-DNS-IPv6-Address TLV:
    The IPv6-Encrypted-DNS Attribute SHOULD include one or multiple instances of Encrypted-DNS-IPv6-Address TLV (Section 3.3.2). If multiple instances are included, they are ordered in the preference for use. In contexts where putting additional complexity on requesting hosts is acceptable, returning an ADN only (that is, no Encrypted-DNS-IPv6-Address TLV is returned) can be considered.
    Encrypted-DNS-SvcParams TLV:
    The IPv6-Encrypted-DNS Attribute SHOULD include one instance of Encrypted-DNS-SvcParams TLV (Section 3.3.4).
    Encrypted-DNS-SvcPriority TLV:
    The IPv6-Encrypted-DNS Attribute SHOULD include one instance of Encrypted-DNS-SvcPriority TLV (Section 3.3.5).

The IPv6-Encrypted-DNS Attribute is associated with the following identifier: 241.TBA1.

3.2. IPv4-Encrypted-DNS Attribute

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 (Section 3.1.9 of [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 resolver. 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

  • This field indicates the total length, in octets, of all fields of this attribute, including the Type, Length, Extended-Type, and the entire length of the embedded TLVs.

Extended-Type

Value

  • This field contains a set of TLVs as follows:

    Encrypted-DNS-ADN TLV:
    The IPv4-Encrypted-DNS Attribute MUST include exactly one instance of Encrypted-DNS-ADN TLV (Section 3.3.1).
    Encrypted-DNS-IPv4-Address TLV:
    The IPv4-Encrypted-DNS Attribute SHOULD include one or multiple instances of Encrypted-DNS-IPv4-Address TLV (Section 3.3.3). In contexts where putting additional complexity on requesting hosts is acceptable, returning an ADN only (that is, no Encrypted-DNS-IPv4-Address TLV is returned) can be considered.
    Encrypted-DNS-SvcParams TLV:
    The IPv4-Encrypted-DNS Attribute SHOULD include one instance of Encrypted-DNS-SvcParams TLV (Section 3.3.4).
    Encrypted-DNS-SvcPriority TLV:
    The IPv4-Encrypted-DNS Attribute SHOULD include one instance of Encrypted-DNS-SvcPriority TLV (Section 3.3.5).

The IPv4-Encrypted-DNS Attribute is associated with the following identifier: 241.TBA2.

3.3. RADIUS TLVs for Encrypted DNS

The TLVs defined in the following subsections use the format defined in Section 2.3 of [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].

3.3.1. Encrypted-DNS-ADN TLV

TLV-Type

TLV-Length

  • Length of included ADN + 2 octets.

Data Type

TLV-Value

  • This field includes a fully qualified domain name of the encrypted DNS resolver. This field is formatted as specified in Section 10 of [RFC8415].

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).

3.3.2. Encrypted-DNS-IPv6-Address TLV

TLV-Type

TLV-Length

  • Eighteen octets.

Data Type

TLV-Value

  • This field includes an IPv6 address (128 bits) of the encrypted DNS resolver.

    The Encrypted-DNS-IPv6-Address attribute MUST NOT include multicast (Section 2.7 of [RFC4291]) and loopback addresses [RFC6890].

This TLV is identified as 241.TBA1.TBA4 as part of the IPv6-Encrypted-DNS Attribute (Section 3.1).

3.3.3. Encrypted-DNS-IPv4-Address TLV

TLV-Type

TLV-Length

  • Six octets.

Data Type

TLV-Value

  • This field includes an IPv4 address (32 bits) of the encrypted DNS resolver.

    The Encrypted-DNS-IPv4-Address attribute MUST NOT include multicast (Section 4 of [RFC1112]) and loopback addresses [RFC6890].

This TLV is identified as 241.TBA2.TBA5 as part of the IPv4-Encrypted-DNS Attribute (Section 3.2).

3.3.4. Encrypted-DNS-SvcParams TLV

TLV-Type

TLV-Length

  • Length of included service parameters + 2 octets.

Data Type

TLV-Value

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).

3.3.5. Encrypted-DNS-SvcPriority TLV

TLV-Type

TLV-Length

  • Six octets.

Data Type

TLV-Value

  • Specifies the priority (unsigned16) of this *-Encrypted-DNS instance compared to other instances, right justified, and the unused bits in this field MUST be set to zero. The value is interpreted following the rules specified in Section 2.4.1 of [I-D.ietf-dnsop-svcb-https].

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).

4. Security Considerations

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 Section 7 of [I-D.ietf-add-dnr].

5. Table of Attributes

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+      241.TBA1 IPv6-Encrypted-DNS
 0+      0+      0        0         0+      241.TBA2 IPv4-Encrypted-DNS

CoA-Request CoA-ACK CoA-NACK #        Attribute
  0+          0       0      241.TBA1 IPv6-Encrypted-DNS
  0+          0       0      241.TBA2 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.

6. IANA Considerations

6.1. New RADIUS Attributes

IANA is requested to assign two new RADIUS attribute types from the IANA registry "Radius Attribute Types" [RADIUS-Types]:

Table 1: Encrypted DNS RADIUS Attributes
Value Description Data Type Reference
241.TBA1 IPv6-Encrypted-DNS tlv This-Document
241.TBA2 IPv4-Encrypted-DNS tlv This-Document

6.2. RADIUS Encrypted DNS TLVs

IANA is requested to create a new subregistry called "RADIUS Encrypted DNS TLVs" under the "Radius Attribute Types" registry [RADIUS-Types].

The registration procedure for this subregistry is "Standards Action" as defined in (Section 4.9 of [RFC8126]).

The subregistry is initially populated as follows:

  • Note to the RFC Editor: Please replace TBA3-TBA7 with the corresponding values assigned from the 1-5 range.
Table 2: Initial RADIUS Encrypted DNS TLVs
Value Description Data Type Reference
0 Reserved This-Document
TBA3 Encrypted-DNS-ADN string This-Document, Section 3.3.1
TBA4 Encrypted-DNS-IPv6-Address ipv6addr This-Document, Section 3.3.2
TBA5 Encrypted-DNS-IPv4-Address ipv4addr This-Document, Section 3.3.3
TBA6 Encrypted-DNS-SvcParams string This-Document, Section 3.3.4
TBA7 Encrypted-DNS-SvcPriority integer This-Document, Section 3.3.5
6-255 Unassigned

6.3. New RADIUS Attribute Permitted in DHCPv6 RADIUS Option

IANA is requested to add the following entry to the "RADIUS Attributes Permitted in DHCPv6 RADIUS Option" subregistry in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry [DHCP-RADIUS]:

Table 3: New RADIUS Attribute Permitted in DHCPv6 RADIUS Option
Type Code Attribute Reference
241.TBA1 IPv6-Encrypted-DNS This-Document

7. Acknowledgements

Thanks to Christian Jacquenet, Neil Cook, Alan Dekok, Joe Clarke, Qin Wu, Dirk von-Hugo, Tom Petch, and Chongfeng Xie for the review and suggestions.

Thanks to Ben Schwartz and Bernie Volz for the comments.

8. References

8.1. Normative References

[I-D.ietf-add-svcb-dns]
Schwartz, B., "Service Binding Mapping for DNS Servers", Work in Progress, Internet-Draft, draft-ietf-add-svcb-dns-07, , <https://www.ietf.org/archive/id/draft-ietf-add-svcb-dns-07.txt>.
[I-D.ietf-dnsop-svcb-https]
Schwartz, B., Bishop, M., and E. Nygren, "Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)", Work in Progress, Internet-Draft, draft-ietf-dnsop-svcb-https-10, , <https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-10.txt>.
[RFC1112]
Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, , <https://www.rfc-editor.org/info/rfc1112>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2865]
Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, , <https://www.rfc-editor.org/info/rfc2865>.
[RFC4291]
Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, , <https://www.rfc-editor.org/info/rfc4291>.
[RFC6158]
DeKok, A., Ed. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, DOI 10.17487/RFC6158, , <https://www.rfc-editor.org/info/rfc6158>.
[RFC6890]
Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, , <https://www.rfc-editor.org/info/rfc6890>.
[RFC6929]
DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, , <https://www.rfc-editor.org/info/rfc6929>.
[RFC8044]
DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, , <https://www.rfc-editor.org/info/rfc8044>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415]
Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, , <https://www.rfc-editor.org/info/rfc8415>.

8.2. Informative References

[DHCP-RADIUS]
IANA, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", <https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml>.
[I-D.ietf-add-dnr]
Boucadair, M., Reddy, T., Wing, D., Cook, N., and T. Jensen, "DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)", Work in Progress, Internet-Draft, draft-ietf-add-dnr-13, , <https://www.ietf.org/archive/id/draft-ietf-add-dnr-13.txt>.
[RADIUS-Types]
IANA, "RADIUS Types", <http://www.iana.org/assignments/radius-types>.
[RFC2132]
Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, DOI 10.17487/RFC2132, , <https://www.rfc-editor.org/info/rfc2132>.
[RFC2868]
Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, DOI 10.17487/RFC2868, , <https://www.rfc-editor.org/info/rfc2868>.
[RFC4014]
Droms, R. and J. Schnizlein, "Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option", RFC 4014, DOI 10.17487/RFC4014, , <https://www.rfc-editor.org/info/rfc4014>.
[RFC4861]
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, , <https://www.rfc-editor.org/info/rfc4861>.
[RFC5176]
Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, , <https://www.rfc-editor.org/info/rfc5176>.
[RFC6614]
Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, , <https://www.rfc-editor.org/info/rfc6614>.
[RFC6911]
Dec, W., Ed., Sarikaya, B., Zorn, G., Ed., Miles, D., and B. Lourdelet, "RADIUS Attributes for IPv6 Access Networks", RFC 6911, DOI 10.17487/RFC6911, , <https://www.rfc-editor.org/info/rfc6911>.
[RFC7037]
Yeh, L. and M. Boucadair, "RADIUS Option for the DHCPv6 Relay Agent", RFC 7037, DOI 10.17487/RFC7037, , <https://www.rfc-editor.org/info/rfc7037>.
[RFC7858]
Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, , <https://www.rfc-editor.org/info/rfc7858>.
[RFC8484]
Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, , <https://www.rfc-editor.org/info/rfc8484>.
[RFC8499]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, , <https://www.rfc-editor.org/info/rfc8499>.
[RFC9250]
Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, , <https://www.rfc-editor.org/info/rfc9250>.

Authors' Addresses

Mohamed Boucadair
Orange
35000 Rennes
France
Tirumaleswar Reddy
Nokia
India