Adaptive DNS Discovery (ADD) | G. Deen |
Internet-Draft | Comcast-NBCUniversal |
Intended status: Informational | July 13, 2020 |
Expires: January 14, 2021 |
Adaptive DNS Discovery Threats Here
draft-deen-add-threats-00
DNS resolver discovery is designed to operate under a variety different levels of trust in the underlying network. This document describes the various trust types that DNS resolver discovery and selection may take place under. Internet Draft.
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 January 14, 2021.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
There are a variety of network environments users may interact with where they will be discovering and selecting a DNS resolver each of which presents a different threat level to the user. This document attempts to establish a common set of threats classifications for reference by Adaptive DNS Discovery (ADD) working group drafts.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
There are many ways to classify and structure threat analysis the approach used here is centered on the perspective of the user and how much subjective trust they can place in different access network situations that they may encounter.
These are networks in which the user has an high sense of trust. These are networks run by a trusted party who is known to the user and is trusted by the user to operate the network with security and operational integrity. While even the best run network can be compromised by attackers or malware, the user has subjective trust that the Green network is very unlikely to be compromised.
The user often has a relationship with the network operator - either personally, as an employee, or by contract they user has entered into such as with an ISP or Mobile Carrier.
Examples of Green Networks
These are networks in which the user does not have any sense of trust and yet has no sense or expectation that the network maybe compromised or hostile. The network's threat level is simply unknown.
These are networks which provided a service to visitors such as public Wifi networks.
Examples of Yellow Networks
These are networks in which the user has an high sense of potential threats being present, but the use may have no other choice but to use them.
These are networks which the user not only does not trust, but also expects the network maybe doing things that the user does not want.
Red Networks
This memo includes no request to IANA.
All drafts are required to have an IANA considerations section (see Guidelines for Writing an IANA Considerations Section in RFCs for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.
All drafts are required to have a security considerations section. See RFC 3552 for a guide.
[Contributors] | Deen, G., "Authors", 2020. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC3552] | Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003. |
[RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008. |
This becomes an Appendix.