Skip to main content

Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS
draft-btw-add-ipsecme-ike-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Mohamed Boucadair , Tirumaleswar Reddy.K , Dan Wing , Valery Smyslov
Last updated 2021-02-19
Replaced by draft-ietf-ipsecme-add-ike, RFC 9464
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-btw-add-ipsecme-ike-02
ADD                                                         M. Boucadair
Internet-Draft                                                    Orange
Intended status: Standards Track                                T. Reddy
Expires: August 23, 2021                                          McAfee
                                                                 D. Wing
                                                                  Citrix
                                                              V. Smyslov
                                                              ELVIS-PLUS
                                                       February 19, 2021

   Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for
                             Encrypted DNS
                      draft-btw-add-ipsecme-ike-02

Abstract

   This document specifies a new Internet Key Exchange Protocol Version
   2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS
   with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS-
   over-QUIC (DoQ).

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 August 23, 2021.

Copyright Notice

   Copyright (c) 2021 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

Boucadair, et al.        Expires August 23, 2021                [Page 1]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Sample Deployment Scenarios . . . . . . . . . . . . . . . . .   4
     3.1.  Roaming Enterprise Users  . . . . . . . . . . . . . . . .   4
     3.2.  VPN Service Provider  . . . . . . . . . . . . . . . . . .   4
     3.3.  DNS Offload . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  IKEv2 Configuration Payload Attribute Types for Encrypted DNS   5
     4.1.  ENCDNS_IP*_* Configuration Payload Attributes . . . . . .   5
     4.2.  ENCDNS_URI_TEMPLATE Configuration Payload Attribute . . .   6
   5.  IKEv2 Protocol Exchange . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Configuration Payload Attribute Types . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   This document specifies encrypted DNS configuration for an Internet
   Key Exchange Protocol Version 2 (IKEv2) [RFC7296] initiator,
   particularly the Authentication Domain Name (ADN) of DNS-over-HTTPS
   (DoH) [RFC8484], DNS-over-TLS (DoT) [RFC7858], or DNS-over-QUIC (DoQ)
   [I-D.ietf-dprive-dnsoquic].

   This document introduces new IKEv2 Configuration Payload Attribute
   Types (Section 4) for the support of DoT, DoH, and DoQ DNS servers.
   These attributes can be used to provision authentication domain
   names, a list of IP addresses, alternate port numbers, and a list of
   DoH URI Template.  The use of IKEv2 to provide these template is
   meant to allow deployments where customized DoH configuration (e.g.,
   per-subscriber or per-site) is required.

   Sample use cases are discussed in Section 3.  The Configuration
   Payload Attribute Types defined in this document are not specific to
   these deployments, but can also be used in other deployment contexts.
   It is out of the scope of this document to provide a comprehensive
   list of deployment contexts.

Boucadair, et al.        Expires August 23, 2021                [Page 2]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

   The encrypted DNS server hosted by the VPN provider can get a domain-
   validate certificate from a public CA.  The VPN client does not need
   to be provisioned with the root certificate of a private CA to
   authenticate the certificate of the encrypted DNS server.  The
   encrypted DNS server can run on private IP addresses and its access
   can be restricted to clients connected to the VPN.

   Note that, for many years, typical designs have often considered that
   the DNS server was usually located inside the protected domain, but
   could be located outside of it.  With encrypted DNS, the latter
   option becomes plausible.

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

   Also, this document makes use of the terms defined in [RFC7296].  In
   particular, readers should be familiar with "initiator" and
   "responder" terms used in that document.

   This document makes use of the following terms:

   'Do53':  refers to unencrypted DNS.

   'Encrypted DNS':  refers to as scheme where DNS messages are sent
      over an encrypted channel.  Examples of encrypted DNS are DoT,
      DoH, and DoQ.

   'ENCDNS_IP*_*':  refers to any IKEv2 Configuration Payload Attribute
      Types defined in Section 4.

   'ENCDNS_IP4_*':  refers to an IKEv2 Configuration Payload Attribute
      Type that carries one or multiple IPv4 addresses of an encrypted
      DNS server.

   'ENCDNS_IP6_*':  refers to an IKEv2 Configuration Payload Attribute
      Type that carries one or multiple IPv6 addresses of an encrypted
      DNS server.

Boucadair, et al.        Expires August 23, 2021                [Page 3]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

3.  Sample Deployment Scenarios

3.1.  Roaming Enterprise Users

   In this Enterprise scenario (Section 1.1.3 of [RFC7296]), a roaming
   user connects to the Enterprise network through an IPsec tunnel.  The
   split-tunnel Virtual Private Network (VPN) configuration allows the
   endpoint to access hosts that resides in the Enterprise network
   [RFC8598] using that tunnel; other traffic not destined to the
   Enterprise does not traverse the tunnel.  In contrast, a non-split-
   tunnel VPN configuration causes all traffic to traverse the tunnel
   into the enterprise.

   For both split- and non-split-tunnel configurations, the use of
   encrypted DNS instead of Do53 provides privacy and integrity
   protection along the entire path (rather than just to the VPN
   termination device) and can communicate the encrypted DNS server
   policies.

   For split-tunnel VPN configurations, the endpoint uses the
   Enterprise-provided encrypted DNS server to resolve internal-only
   domain names.

   For non-split-tunnel VPN configurations, the endpoint uses the
   Enterprise-provided encrypted DNS server to resolve both internal and
   external domain names.

   Enterprise networks are susceptible to internal and external attacks.
   To minimize that risk all enterprise traffic is encrypted
   (Section 2.1 of [I-D.arkko-farrell-arch-model-t]).

3.2.  VPN Service Provider

   Legacy VPN service providers usually preserve end-users' data
   confidentiality by sending all communication traffic through an
   encrypted tunnel.  A VPN service provider can also provide guarantees
   about the security of the VPN network by filtering malware and
   phishing domains.

   Browsers and OSes support DoH/DoT; VPN providers may no longer expect
   DNS clients to fallback to Do53 just because it is a closed network.

   The encrypted DNS server hosted by the VPN service provider can be
   securely discovered by the endpoint using the IKEv2 Configuration
   Payload Attribute Type.

Boucadair, et al.        Expires August 23, 2021                [Page 4]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

3.3.  DNS Offload

   VPN service providers typically allow split-tunnel VPN configuration
   in which users can choose applications that can be excluded from the
   tunnel.  For example, users may exclude applications that restrict
   VPN access.

   The encrypted DNS server hosted by the VPN service provider can be
   securely discovered by the endpoint using the IKEv2 Configuration
   Payload Attribute Type.

4.  IKEv2 Configuration Payload Attribute Types for Encrypted DNS

4.1.  ENCDNS_IP*_* Configuration Payload Attributes

   The ENCDNS_IP*_* IKEv2 Configuration Payload Attribute Types are used
   to configure a DoT, DoH, or DoQ DNS server.  All these attributes
   share the format shown in Figure 1.

                        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
   +-+-----------------------------+-------------------------------+
   |R|         Attribute Type      |            Length             |
   +-+-----------------------------+---------------+---------------+
   |          Port Number          |    RESERVED   | Num Addresses |
   +-------------------------------+---------------+---------------+
   |                                                               |
   ~                         IP Addresses                          ~
   |                                                               |
   +---------------------------------------------------------------+
   |                                                               |
   ~                  DNS Authentication Domain Name               ~
   |                                                               |
   +---------------------------------------------------------------+

                        Figure 1: Attributes Format

   The fields of the attribute shown in Figure 1 are as follows:

   o  R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be
      ignored on receipt (see Section 3.15.1 of [RFC7296] for details).

   o  Attribute Type (15 bits) - Identifier for Configuration Attribute
      Type; is set to one of the TBA1-TBA6 values listed in Section 7.1.

   o  Length (2 octets, unsigned integer) - Length of the data in
      octets.  In particular, this field is set to:

Boucadair, et al.        Expires August 23, 2021                [Page 5]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

      *  0 if the Configuration payload has types CFG_REQUEST or
         CFG_ACK.

      *  (2 + Length of the ADN + N * 4) for ENCDNS_IP4_* attributes if
         the Configuration payload of a has types CFG_REPLY or CFG_SET;
         N being the number of included IPv4 addresses ('Num
         addresses').

      *  (2 + Length of the ADN + N * 16) for ENCDNS_IP6_* attributes if
         the Configuration payload has types CFG_REPLY or CFG_SET; N
         being the number of included IPv6 addresses ('Num addresses').

   o  Port Number (2 octets, unsigned integer) - Indicates the port
      number to be used for the encrypted DNS.  As a reminder, the
      default port number is 853 for DoT and 443 for DoH.

   o  RESERVED (1 octet) - These bits are reserved for future use.
      These bits MUST be set to zero by the sender and MUST be ignored
      by the receiver.

   o  Num Addresses (1 octet) - Indicates the number of enclosed IPv4
      (for ENCDNS_IP4_* attribute types) or IPv6 (for ENCDNS_IP6_*
      attribute types) addresses.

   o  IP Address(es) (variable) - One or more IPv4 or IPv6 addresses to
      be used to reach the encrypted DNS identified by the name in the
      DNS Authentication Domain Name.

   o  Authentication Domain Name (variable) - A fully qualified domain
      name of the DoT, DoH, or DoQ DNS server following the syntax
      defined in [RFC5890].  The name MUST NOT contain any terminators
      (e.g., NULL, CR).

      An example of valid ADN for DoH server is "doh1.example.com".

4.2.  ENCDNS_URI_TEMPLATE Configuration Payload Attribute

   DoH servers may support more than one URI Template [RFC8484].  Also,
   if the resolver hosts several DoH services (e.g., no-filtering,
   blocking adult content, blocking malware), these services can be
   discovered as templates.

   Figure 2 depictes the format of the ENCDNS_URI_TEMPLATE IKEv2
   Configuration Payload Attribute Type whihc is used to configure DoH
   URI Template(s).

Boucadair, et al.        Expires August 23, 2021                [Page 6]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

                        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
   +-+-----------------------------+-------------------------------+
   |R|    ENCDNS_URI_TEMPLATE      |            Length             |
   +-+-----------------------------+---------------+---------------+
   |                                                               |
   ~                         uri-template-data                     ~
   |                             . . .                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each instance of the uri-template-data is formatted as follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
   |   uri-template-len            |          URI Template         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+

                Figure 2: DoH URI Template Attribute Format

   The fields of the attribute shown in Figure 2 are as follows:

   o  R (Reserved, 1 bit) - This bit MUST be set to zero and MUST be
      ignored on receipt (see Section 3.15.1 of [RFC7296] for details).

   o  Attribute Type (15 bits) - Identifier for Configuration Attribute
      Type; is set to ENCDNS_URI_TEMPLATE (TBA7) (see Section 7.1).

   o  Length (2 octets, unsigned integer) - Length of the data in
      octets.  In particular, this field is set to '0' if the
      Configuration payload has types CFG_REQUEST or CFG_ACK.

   o  uri-template-data (variable) - XXXX.

      An example of valid URI Template is "XXXX".

   How a DoH client makes use of the configured DoH services is out of
   the scope of this document.

5.  IKEv2 Protocol Exchange

   This section describes how an initiator can be configured with an
   encrypted DNS server (e.g., DoH, DoT) using IKEv2.

   Initiators indicate the support of an encrypted DNS in the
   CFG_REQUEST payloads by including one or multiple ENCDNS_IP*_*
   attributes, while responders supply the encrypted DNS configuration
   in the CFG_REPLY payloads.  Concretely:

Boucadair, et al.        Expires August 23, 2021                [Page 7]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

      If the initiator supports encrypted DNS, it includes one or more
      ENCDNS_IP*_* attributes in the CFG_REQUEST with the "Attribute
      Type" set to the requested encrypted DNS type (Section 4).  For
      each supported encrypted DNS type the initiator MUST include
      exactly one attribute with the Length field set to 0, so that no
      data is included for these attributes.  If DoH is requested, the
      initiator includes also ENCDNS_URI_TEMPLATE in the CFG_REQUEST
      with "Length" set to 0.

      For each ENCDNS_IP*_* attribute from the CFG_REQUEST, if the
      responder supports the corresponding encrypted DNS type, and
      absent any policy, the responder sends back an ENCDNS_IP*_*
      attribute in the CFG_REPLY with this encrypted DNS type and an
      appropriate list of IP addresses, a port number, and an ADN.  The
      list of IP addresses MUST NOT be empty.  Multiple instances of the
      same ENCDNS_IP*_* attribute MAY be returned if distinct ADNs (or
      port numbers) are to be returned by the responder.  If the
      responder includes ENCDNS_IP4_DOH or ENCDNS_IP6_DOH in the
      response, it MUST also include ENCDNS_URI_TEMPLATE carrying one or
      more URI Templates.

      If the CFG_REQUEST includes an ENCDNS_IP*_* attribute but the
      CFG_REPLY does not include an ENCDNS_IP*_* matching the requested
      encrypted DNS type, this is an indication that requested encrypted
      DNS type(s) is not supported by the responder or the responder is
      not configured to provide corresponding server addresses.

      The behavior of the responder if it receives both ENCDNS_IP*_* and
      INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS) attributes is policy-based
      and deployment-specific.  However, it is RECOMMENDED that if the
      responder includes at least one ENCDNS_IP*_* attribute in the
      reply, it should not include any of INTERNAL_IP4_DNS/
      INTERNAL_IP6_DNS attributes.

   The DNS client establishes an encrypted DNS session (e.g., DoT, DoH,
   DoQ) with the address(es) conveyed in ENCDNS_IP*_* and uses the
   mechanism discussed in Section 8 of [RFC8310] to authenticate the DNS
   server certificate using the authentication domain name conveyed in
   ENCDNS_IP*_*.

   If the IPsec connection is a split-tunnel configuration and the
   initiator negotiated INTERNAL_DNS_DOMAIN as per [RFC8598], the DNS
   client MUST resolve the internal names using ENCDNS_IP*_* DNS
   servers.

      Note: [RFC8598] requires INTERNAL_IP6_DNS (or INTERNAL_IP4_DNS)
      attribute to be mandatory present when INTERNAL_DNS_DOMAIN is

Boucadair, et al.        Expires August 23, 2021                [Page 8]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

      included.  This specification relaxes that constraint in the
      presence of ENCDNS_IP*_* attributes.

6.  Security Considerations

   This document adheres to the security considerations defined in
   [RFC7296].  In particular, this document does not alter the trust on
   the DNS configuration provided by a responder.

   Networks are susceptible to internal attacks as discussed in
   Section 3.2 of [I-D.arkko-farrell-arch-model-t].  Hosting encrypted
   DNS server even in case of split-VPN configuration minimizes the
   attack vector (e.g., a compromised network device cannot monitor/
   modify DNS traffic).  This specification describes a mechanism to
   restrict access to the DNS messages to only the parties that need to
   know.

   The initiator may trust the encrypted DNS servers supplied by means
   of IKEv2 from a trusted responder more than the locally provided DNS
   servers, especially in the case of connecting to unknown or untrusted
   networks (e.g., coffee shops or hotel networks).

   If IKEv2 responder has used NULL Authentication method [RFC7619] to
   authenticate itself, the initiator MUST NOT use returned ENCDNS_IP*_*
   servers configuration unless it is pre-configured in the OS or the
   browser.

   This specification does not extend the scope of accepting DNSSEC
   trust anchors beyond the usage guidelines defined in Section 6 of
   [RFC8598].

7.  IANA Considerations

7.1.  Configuration Payload Attribute Types

   This document requests IANA to assign the following new IKEv2
   Configuration Payload Attribute Types from the "IKEv2 Configuration
   Payload Attribute Types" namespace available at
   https://www.iana.org/assignments/ikev2-parameters/
   ikev2-parameters.xhtml#ikev2-parameters-21.

Boucadair, et al.        Expires August 23, 2021                [Page 9]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

                                    Multi-
      Value    Attribute Type       Valued  Length      Reference
      ------   -------------------  ------  ----------  ------------
      TBA1     ENCDNS_IP4_DOT        YES   0 or more   RFC XXXX
      TBA2     ENCDNS_IP6_DOT        YES   0 or more   RFC XXXX
      TBA3     ENCDNS_IP4_DOH        YES   0 or more   RFC XXXX
      TBA4     ENCDNS_IP6_DOH        YES   0 or more   RFC XXXX
      TBA5     ENCDNS_IP4_DOQ        YES   0 or more   RFC XXXX
      TBA6     ENCDNS_IP6_DOQ        YES   0 or more   RFC XXXX
      TBA7     ENCDNS_URI_TEMPLATE   YES   0 or more   RFC XXXX

8.  Acknowledgements

   Many thanks to Yoav Nir, Christian Jacquenet, Paul Wouters, and Tommy
   Pauly for the review and comments.

   Yoav and Paul suggested the use of one single attribute carrying both
   the name and an IP address instead of depending on the existing
   INTERNAL_IP6_DNS and INTERNAL_IP4_DNS attributes.

   Christian Huitema suiggested to return a port number in the
   attributes.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC7296]  Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
              Kivinen, "Internet Key Exchange Protocol Version 2
              (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
              2014, <https://www.rfc-editor.org/info/rfc7296>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Boucadair, et al.        Expires August 23, 2021               [Page 10]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

   [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,
              <https://www.rfc-editor.org/info/rfc8310>.

9.2.  Informative References

   [I-D.arkko-farrell-arch-model-t]
              Arkko, J. and S. Farrell, "Challenges and Changes in the
              Internet Threat Model", draft-arkko-farrell-arch-model-
              t-04 (work in progress), July 2020.

   [I-D.ietf-dprive-dnsoquic]
              Huitema, C., Mankin, A., and S. Dickinson, "Specification
              of DNS over Dedicated QUIC Connections", draft-ietf-
              dprive-dnsoquic-01 (work in progress), October 2020.

   [RFC7619]  Smyslov, V. and P. Wouters, "The NULL Authentication
              Method in the Internet Key Exchange Protocol Version 2
              (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
              <https://www.rfc-editor.org/info/rfc7619>.

   [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, May
              2016, <https://www.rfc-editor.org/info/rfc7858>.

   [RFC8484]  Hoffman, P. and P. McManus, "DNS Queries over HTTPS
              (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018,
              <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,
              January 2019, <https://www.rfc-editor.org/info/rfc8499>.

   [RFC8598]  Pauly, T. and P. Wouters, "Split DNS Configuration for the
              Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 8598, DOI 10.17487/RFC8598, May 2019,
              <https://www.rfc-editor.org/info/rfc8598>.

Authors' Addresses

   Mohamed Boucadair
   Orange
   Rennes  35000
   France

   Email: mohamed.boucadair@orange.com

Boucadair, et al.        Expires August 23, 2021               [Page 11]
Internet-Draft           IKEv2 for Encrypted DNS           February 2021

   Tirumaleswar Reddy
   McAfee, Inc.
   Embassy Golf Link Business Park
   Bangalore, Karnataka  560071
   India

   Email: TirumaleswarReddy_Konda@McAfee.com

   Dan Wing
   Citrix Systems, Inc.
   USA

   Email: dwing-ietf@fuggles.com

   Valery Smyslov
   ELVIS-PLUS
   RU

   Email: svan@elvis.ru

Boucadair, et al.        Expires August 23, 2021               [Page 12]