Skip to main content

Reputation Verified Selection of Upstream Encrypted Resolvers
draft-schwartz-add-ddr-forwarders-02

Document Type Active Internet-Draft (candidate for add WG)
Authors Benjamin M. Schwartz , Chris Box
Last updated 2022-07-08
RFC stream Internet Engineering Task Force (IETF)
Formats
Stream WG state Call For Adoption By WG Issued
Polled for WG adoption but not adopted
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-schwartz-add-ddr-forwarders-02
add                                                          B. Schwartz
Internet-Draft                                                Google LLC
Intended status: Standards Track                                  C. Box
Expires: 9 January 2023                                               BT
                                                             8 July 2022

     Reputation Verified Selection of Upstream Encrypted Resolvers
                  draft-schwartz-add-ddr-forwarders-02

Abstract

   This draft describes an extension to the Discovery of Designated
   Resolvers (DDR) standard, enabling use of encrypted DNS in the
   presence of legacy DNS forwarders.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the mailing list
   (add@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/add/.

   Source for this draft and an issue tracker can be found at
   https://github.com/bemasc/ddr-forwarders.

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 9 January 2023.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Schwartz & Box           Expires 9 January 2023                 [Page 1]
Internet-Draft             DDR and Forwarders                  July 2022

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Reputation Verified Selection (RVS) . . . . . . . . . . . . .   4
     3.1.  Reputation systems  . . . . . . . . . . . . . . . . . . .   6
     3.2.  Using resolvers of intermediate reputation  . . . . . . .   6
   4.  Management of local blocking functionality  . . . . . . . . .   7
     4.1.  Local implementation with DNR . . . . . . . . . . . . . .   7
     4.2.  Local implementation with DDR . . . . . . . . . . . . . .   7
     4.3.  Move upstream . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Compatibility issues that can arise from cross-forwarder
           upgrade . . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Split-horizon namespaces  . . . . . . . . . . . . . . . .   8
       5.1.1.  Mitigation: NXDOMAIN Fallback . . . . . . . . . . . .   8
     5.2.  Interposable domains  . . . . . . . . . . . . . . . . . .   8
       5.2.1.  Mitigation: Exemption list  . . . . . . . . . . . . .   9
     5.3.  Caching . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.3.1.  Mitigation: Stub caches . . . . . . . . . . . . . . .   9
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   9
     6.1.  Privacy gains . . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Privacy losses  . . . . . . . . . . . . . . . . . . . . .   9
       6.2.1.  Mitigation: Open multiple connections . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     7.1.  Redirection . . . . . . . . . . . . . . . . . . . . . . .  10
       7.1.1.  Possible weakness: Stale reputation . . . . . . . . .  10
       7.1.2.  Possible weakness: Inappropriate reputation . . . . .  10
     7.2.  Forensic logging  . . . . . . . . . . . . . . . . . . . .  11
       7.2.1.  Network-layer logging . . . . . . . . . . . . . . . .  11
       7.2.2.  DNS-layer logging . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

Schwartz & Box           Expires 9 January 2023                 [Page 2]
Internet-Draft             DDR and Forwarders                  July 2022

1.  Introduction

   The Discovery of Designated Resolvers specification [DDR] describes a
   mechanism for clients to learn about the encrypted protocols
   supported by a DNS server.  It also describes a client validation
   policy that has strong security properties.

   Recent estimates suggest that a large fraction, perhaps a majority,
   of residential internet users in the United States and Europe rely on
   local DNS forwarders that are not compatible with DDR.  This is
   because they are accessed via a private IP address, which TLS
   certificates cannot normally prove ownership of.  Many such devices
   also face significant hurdles in being upgraded to support encrypted
   DNS, so it is likely that a large installed base of legacy DNS
   forwarders, providing Do53 on a private IP address, will remain for
   some years.

   A client in such a network that wants to use the network's DNS
   resolver is forced to use Do53.  It is therefore vulnerable to
   passive surveillance both on the local network, and between this
   network and the upstream provider, even if the upstream DNS resolver
   supports encrypted DNS.

   Many of these attacks can be mitigated by using the method described
   in this document.  In a nutshell the process is as follows.

   1.  The client begins DDR discovery, querying for _dns.resolver.arpa.

   2.  The legacy DNS forwarder, since it does not understand DDR,
       forwards this query upstream.

   3.  The upstream recursive resolver, which supports DDR, replies with
       details of how to access its encrypted DNS service.

   4.  The client receives this response and performs Reputation
       Verified Selection (see Section 3).

   5.  On successful completion, the client may commence using encrypted
       DNS towards the upstream resolver.  This is known as Cross-
       Forwarder Upgrade.

   By this process, Do53 is replaced with encrypted DNS for most
   queries.  The client may wish to continue to send locally-relevant
   queries (e.g. .local) towards the legacy DNS forwarder.

Schwartz & Box           Expires 9 January 2023                 [Page 3]
Internet-Draft             DDR and Forwarders                  July 2022

1.1.  Scope

   This document describes the interaction between DDR and legacy DNS
   forwarders.

   DNS forwarders and resolvers that are implemented with awareness of
   DDR are out of scope, as they are not affected by this discussion
   (although see Security Considerations, Section 7).

   IPv6-only networks whose default DNS server has a Global Unicast
   Address are out of scope, even if this server is actually a simple
   forwarder.  If the DNS server does not use a private IP address, it
   is not a "legacy DNS forwarder" under this draft's definition.

2.  Conventions and Definitions

   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.

   Private IP Address - Any IP address reserved for loopback [RFC1122],
   link-local [RFC3927], private [RFC1918], local [RFC4193], or Carrier-
   Grade NAT [RFC6598] use.

   Legacy DNS Forwarder - An apparent DNS resolver, known to the client
   only by a private IP address, that forwards the client's queries to
   an upstream resolver, and has not been updated with any knowledge of
   DDR.

   Cross-Forwarder Upgrade - Establishment and use of a direct,
   encrypted connection between the client and the upstream resolver.

3.  Reputation Verified Selection (RVS)

   Reputation Verified Selection (RVS) is a method for validating
   whether connection using DDR is allowed.  Clients MAY use RVS when
   (a) the local DNS server is identified by a Private IP address and
   (b) the DDR SVCB resolution process does not produce any Encrypted
   DNS endpoints that have this IP address in their A or AAAA records.
   RVS then proceeds as follows:

   1.  The client connects to one of the indicated Encrypted DNS
       endpoints.

   2.  The client receives a certificate, which it verifies to a
       suitable root of trust.

Schwartz & Box           Expires 9 January 2023                 [Page 4]
Internet-Draft             DDR and Forwarders                  July 2022

   3.  For each identity (e.g.  SubjectAltName) in the certificate, the
       client constructs a Resolver Identity:

       *  For DNS over TLS and DNS over QUIC, the Resolver Identity is
          an IP address or hostname and the port number used for the
          connection.

       *  For DNS over HTTPS, the Resolver Identity is a URI Template in
          absolute form, containing the port number used for the
          connection and path indicated by dohpath.

   4.  The client determines the reputation of each Resolver Identity
       derived from the certificate.

   5.  The maximum (i.e. most favorable) reputation is the reputation of
       this connection.

   Successful validation then permits cross-forwarder upgrade.

      OPEN QUESTION: Would it be better to use the SVCB TargetName to
      select a single Resolver Identity?  This would avoid the need to
      enumerate the certificate's names, but it would require the use of
      SNI (unlike standard DDR), and would not be compatible with all
      upstream encrypted resolvers.

      OPEN QUESTION: Can we simplify the resolver identity to just a
      domain name?  This would make reputation systems easier, but it
      would not allow distinct reputation for different colocated
      resolution services, so reputation providers would have to be sure
      that no approved resolver has other interesting colocated
      services.

   This process MUST be repeated whenever a new TLS session is
   established, but reputation scores for each resolver endpoint MAY be
   cached.

   For DNS over HTTPS, the :authority pseudo-header MUST reflect the
   Resolver Identity with the most favorable reputation, to ensure that
   the HTTP requests are well-formed and are directed to the intended
   service.  If the Resolver Identity is a wildcard, the reputation
   system MUST replace it with a valid hostname that matches the
   wildcard.

   Assessing reputation limits the ability of a DDR forgery attack to
   cause harm, as it will only allow an attacker to direct clients to a
   resolver they consider trustworthy.  Major DoH client implementations
   already include lists of known or trusted resolvers
   [CHROME-DOH][MICROSOFT-DOH][MOZILLA-TRR].

Schwartz & Box           Expires 9 January 2023                 [Page 5]
Internet-Draft             DDR and Forwarders                  July 2022

   Clients SHOULD start by checking the resolver endpoint with the
   numerically lowest SVCB SvcPriority.  Clients MAY wait until a DNS
   query triggers an Encrypted DNS connection attempt before performing
   this verification.

   If RVS encounters an error or rejects the server, the client MUST NOT
   send encrypted DNS queries to that server.  If RVS rejects all
   compatible ServiceMode records, the client MUST fall back to the
   unencrypted resolver (i.e. plaintext DNS on port 53).

3.1.  Reputation systems

   Embedding a list of known trusted resolvers in a client is only one
   possible model for assessing the reputation of a resolver.  In future
   a range of online reputation services might be available to be
   queried, each returning an answer according to their own specific
   criteria.  These might involve answers on other properties such as
   jurisdiction, or certification by a particular body.  It is out of
   scope for this document to define these query methods, other than to
   note that designers should be aware of bootstrapping problems.  It is
   the client's decision as to how to combine these answers, possibly
   using additional metadata (e.g. location), to make a determination of
   reputation.

3.2.  Using resolvers of intermediate reputation

   If the determined reputation is a binary "definitely trustworthy" or
   "definitely malicious", the client's recommended action is clear.
   However, intermediate trust levels are also possible (e.g. "probably
   safe", "newly launched").  In these cases there are some options
   clients can consider:

   *  The client can simply decline to the use the encrypted service.
      In this case, unless there is another option, the client will fall
      back to Do53.

   *  The client can ask the user about a specific domain names that
      appear in the certificate.  These names might be recognizable to
      the user, e.g. as that of an ISP.  It's also possible to present
      more details about why a Resolver Identity lacks some element of
      reputation.

   *  The client can use the encrypted service for a limited time, as a
      means of mitigating interception attacks.  For example, if the
      client limits the DDR response TTL to 5 minutes, this ensures that
      any attacker can continue to redirect queries for at most 5
      minutes after they have left the local network.

Schwartz & Box           Expires 9 January 2023                 [Page 6]
Internet-Draft             DDR and Forwarders                  July 2022

4.  Management of local blocking functionality

   Certain local DNS forwarders block access to domains associated with
   malware and other threats.  Others block based on the category of
   service provided by those domains, e.g. domains hosting services that
   are not appropriate for a work or school environment.  In the short
   term to ensure this service is not lost due to a cross-forwarder
   upgrade, the maintainers can simply add "resolver.arpa" to their
   actively curated list of domains to block.  This pattern has been
   deployed by Mozilla, with the domain "use-application-dns.net"
   [MOZILLA-CANARY].

   In the long term, it is best for filtering DNS forwarders to
   implement support for encrypted DNS.  The following subsections
   describe some ways to implement this.

4.1.  Local implementation with DNR

   The local forwarder can be upgraded to one that implements an
   encrypted DNS service discoverable through DNR.  This requires a TLS
   certificate on the local device, proving ownership of the chosen
   Authentication Domain Name (ADN).  Onward queries to the internet
   SHOULD also be protected with encryption.

4.2.  Local implementation with DDR

   If the local forwarder can be upgraded to offer an encrypted DNS
   service, this can then be made discoverable through classic DDR.  If
   the device has a private IP (as presumed for RVS), a self-signed
   certificate is sufficient as long as the client supports the
   Opportunistic Discovery mode of DDR.  Onward queries to the internet
   SHOULD also be protected with encryption.

4.3.  Move upstream

   The blocking functionality can be moved to the upstream resolver.
   Cross-forwarder upgrade then enables the service to continue, as long
   as the upstream resolver has sufficient reputation.

5.  Compatibility issues that can arise from cross-forwarder upgrade

   Legacy DNS forwarders sometimes provide various additional services
   that would be lost in the event of a cross-forwarder upgrade.  For
   all of these, a possible general mitigation is to provide users or
   administrators with the ability to control whether DDR is used with
   legacy forwarders.  For example, this control could be provided via a
   preference, or via a notification upon discovering a new upstream
   resolver.  Specific mitigations are also described below.

Schwartz & Box           Expires 9 January 2023                 [Page 7]
Internet-Draft             DDR and Forwarders                  July 2022

5.1.  Split-horizon namespaces

   Some local network resolvers contain additional names that are not
   resolvable in the global DNS.  A simple cross-forwarder upgrade might
   lose access to these local names.  Clients SHOULD be aware of well-
   known suffixes (e.g. .local, .home.arpa.) that require local
   resolution.  Dynamic discovery of local prefixes would help this
   issue.  To address any remaining ones, the following mitigation can
   be used.

5.1.1.  Mitigation: NXDOMAIN Fallback

   In "NXDOMAIN Fallback", the client repeats a query to the unencrypted
   resolver if the encrypted resolver returns NXDOMAIN.  This allows the
   resolution of local names, provided they do not collide with globally
   resolvable names (as required by [RFC2826]).

   This is similar to the fallback behavior currently deployed in
   Mozilla Firefox [FIREFOX-FALLBACK].

   NXDOMAIN Fallback results in slight changes to the security and
   privacy properties of encrypted DNS.  Queries for nonexistent names
   no longer have protection against a local passive adversary, and
   local names are revealed to the upstream resolver.

   NXDOMAIN Fallback is only applicable when a legacy DNS forwarder
   might be present, i.e. the unencrypted resolver has a private IP
   address, and the encrypted resolver has a different IP address.  In
   other DDR configurations, any local names are expected to resolve
   similarly on both resolvers.

5.2.  Interposable domains

   An "interposable domain" is a domain whose owner deliberately allows
   resolvers to forge certain responses.  This arrangement is most
   common for search engines, which often support a configuration where
   resolvers forge a CNAME record to direct all clients to a child-
   appropriate instance of the search engine
   [DUCK-CNAME][BING-CNAME][GOOGLE-CNAME].

   Future deployments of interposable domains can instruct
   administrators to enable or disable DDR when adding the forged
   record, but forged records in legacy DNS forwarders could be lost due
   to a cross-forwarder upgrade.

Schwartz & Box           Expires 9 January 2023                 [Page 8]
Internet-Draft             DDR and Forwarders                  July 2022

5.2.1.  Mitigation: Exemption list

   There are a small number of pre-existing interposable domains,
   largely of interest only to web browsers.  Clients can maintain a
   list of relevant interposable domains and resolve them only via the
   network's resolver.

5.3.  Caching

   Many legacy DNS forwarders also provide a shared cache for all
   network users.  Cross-forwarder upgrades will bypass this cache,
   resulting in slower DNS resolution for some queries.

5.3.1.  Mitigation: Stub caches

   Clients can compensate partially for any loss of shared caching by
   implementing local DNS caches.  This mitigation is already widely
   deployed in browsers and operating systems.

6.  Privacy Considerations

6.1.  Privacy gains

   The conservative validation policy results in no encryption when a
   legacy DNS forwarder is present.  This leaves the user's query
   activity vulnerable to passive monitoring [RFC7258], either on the
   local network or between the user and the upstream resolver.

   Reputation Verified Selection enables the use of encrypted transport
   in these configurations, reducing exposure to a passive surveillance
   adversary.

6.2.  Privacy losses

   In some legacy DNS forwarder implementations, the upstream resolver
   is not able to determine whether two queries were issued by the same
   client inside the network.  It can only see aggregated queries being
   made by the forwarder.  [DDR] to a non-local resolver requires
   individual encrypted DNS connections from each device, revealing
   which queries were made by the same client.  RVS shares this
   property.

Schwartz & Box           Expires 9 January 2023                 [Page 9]
Internet-Draft             DDR and Forwarders                  July 2022

6.2.1.  Mitigation: Open multiple connections

   If the above issue is a concern, clients MAY open multiple
   connections to the designated encrypted resolver with separate local
   state (e.g.  TLS session tickets), and distribute queries among them.
   This may reduce the upstream resolver's ability to link queries that
   came from a single client.

7.  Security Considerations

   When the client uses the conservative validation policy described in
   [DDR], the client can establish a secure DDR connection only in the
   absence of an active attacker.  An on-path attacker can impersonate
   the resolver and intercept all queries, by preventing the DDR
   upgrade.

   This basic security analysis also applies if the client uses
   Reputation Verified Selection.  However, the detailed security
   properties differ, as discussed in this section.

7.1.  Redirection

   An on-path attacker might be located on the local network, or between
   the local network and the upstream resolver.  In either case, the
   attacker can redirect the client to a resolver of the attacker's
   choice, _as long as that resolver meets the client's requirements for
   reputation_. Hence the reputation system is essential to the security
   of the user.

   Weaknesses in the reputation system could reopen this class of
   vulnerabilities.

7.1.1.  Possible weakness: Stale reputation

   If a previously-reputable resolver is compromised, users can be
   redirected to it while this reputation remains high.  Once an attack
   has been detected, it should be reported to relevant reputation
   services so that they can revise their assessment of this resolver.

7.1.2.  Possible weakness: Inappropriate reputation

   The reputation of a resolver might depend on aspects of the client's
   connection context, e.g. their geographic location.  For example, a
   local ISP's resolver could be reputable for clients in its service
   area, but suspicious for clients on distant continent.  Accordingly,
   very large reputation systems may need to customize their results
   based on the context.

Schwartz & Box           Expires 9 January 2023                [Page 10]
Internet-Draft             DDR and Forwarders                  July 2022

7.2.  Forensic logging

7.2.1.  Network-layer logging

   With the conservative validation policy, a random sample of IP
   packets is likely sufficient for manual retrospective detection of a
   DNS redirection attack.

   With Reputation Verified Selection, local forensic logs must capture
   a specific packet (the attacker's DDR designation response) to enable
   retrospective detection of a redirection attack.

7.2.1.1.  Additional Mitigation: Log all DDR responses

   Redirection attacks are largely mitigated by RVS, but the loss of
   network-layer logging for such attacks can be mitigated by logging
   all DDR responses, or more generally all DNS responses.  This makes
   retrospective attack detection straightforward, as the attacker's DDR
   response will indicate an unexpected server.

7.2.2.  DNS-layer logging

   DNS-layer forensic logging conducted by a legacy DNS forwarder would
   be lost in a cross-forwarder upgrade.

7.2.2.1.  Solution: Plan to upgrade

   Forwarders that want to observe all queries from RVS clients should
   plan to implement DDR or DNR.  In the short term it is possible for
   the forwarder to disable DDR by responding negatively to
   _dns.resolver.arpa, but this is not recommended long-term as it
   prevents confidentiality protection.

8.  References

8.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/rfc/rfc2119>.

   [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/rfc/rfc8174>.

8.2.  Informative References

Schwartz & Box           Expires 9 January 2023                [Page 11]
Internet-Draft             DDR and Forwarders                  July 2022

   [BING-CNAME]
              "Block adult content with SafeSearch - Map at a network
              level", n.d., <https://help.bing.microsoft.com/#apex/bing/
              en-us/10003/0>.

   [CHROME-DOH]
              "DoH providers: criteria, process for Chrome", n.d.,
              <https://docs.google.com/document/d/128i2YTV2C7T6Gr3I-
              81zlQ-_Lprnsp24qzy_20Z1Psw/edit>.

   [DDR]      Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", Work in
              Progress, Internet-Draft, draft-ietf-add-ddr-08, 5 July
              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
              add-ddr-08>.

   [DUCK-CNAME]
              "Force Safe Search at a Network Level", n.d.,
              <https://help.duckduckgo.com/duckduckgo-help-
              pages/features/safe-search/>.

   [FIREFOX-FALLBACK]
              "About our rollout of DNS over HTTPS", n.d.,
              <https://support.mozilla.org/en-US/kb/firefox-dns-over-
              https#w_about-our-rollout-of-dns-over-https>.

   [GOOGLE-CNAME]
              "Keep SafeSearch turned on for your school, workplace, or
              home network", n.d.,
              <https://support.google.com/websearch/
              answer/186669?hl=en>.

   [MICROSOFT-DOH]
              "Determine which DoH servers are on the known server
              list", n.d., <https://docs.microsoft.com/en-us/windows-
              server/networking/dns/doh-client-support#determine-which-
              doh-servers-are-on-the-known-server-list>.

   [MOZILLA-CANARY]
              "Canary domain - use-application-dns.net", n.d.,
              <https://support.mozilla.org/en-US/kb/canary-domain-use-
              application-dnsnet>.

   [MOZILLA-TRR]
              "Mozilla Policy Requirements for DNS over HTTPs Partners",
              n.d., <https://wiki.mozilla.org/Security/DOH-resolver-poli
              cy#Mozilla_Policy_Requirements_for_DNS_over_HTTPs_Partners
              >.

Schwartz & Box           Expires 9 January 2023                [Page 12]
Internet-Draft             DDR and Forwarders                  July 2022

   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122,
              DOI 10.17487/RFC1122, October 1989,
              <https://www.rfc-editor.org/rfc/rfc1122>.

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
              J., and E. Lear, "Address Allocation for Private
              Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
              February 1996, <https://www.rfc-editor.org/rfc/rfc1918>.

   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May
              2000, <https://www.rfc-editor.org/rfc/rfc2826>.

   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
              Configuration of IPv4 Link-Local Addresses", RFC 3927,
              DOI 10.17487/RFC3927, May 2005,
              <https://www.rfc-editor.org/rfc/rfc3927>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <https://www.rfc-editor.org/rfc/rfc4193>.

   [RFC6598]  Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
              M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
              Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April
              2012, <https://www.rfc-editor.org/rfc/rfc6598>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <https://www.rfc-editor.org/rfc/rfc7258>.

Acknowledgments

   Thanks to Anthony Lieuallen and Eric Orth for early reviews of a
   previous draft.

Authors' Addresses

   Benjamin Schwartz
   Google LLC
   Email: bemasc@google.com

   Chris Box
   BT
   Email: chris.box@bt.com

Schwartz & Box           Expires 9 January 2023                [Page 13]