idnits 2.17.1 draft-deen-add-threats-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 13, 2020) is 1376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Contributors' is defined on line 168, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Adaptive DNS Discovery (ADD) G. Deen 3 Internet-Draft Comcast-NBCUniversal 4 Intended status: Informational July 13, 2020 5 Expires: January 14, 2021 7 Adaptive DNS Discovery Threats Here 8 draft-deen-add-threats-00 10 Abstract 12 DNS resolver discovery is designed to operate under a variety 13 different levels of trust in the underlying network. This document 14 describes the various trust types that DNS resolver discovery and 15 selection may take place under. Internet Draft. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 14, 2021. 34 Copyright Notice 36 Copyright (c) 2020 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 53 2. Classifications . . . . . . . . . . . . . . . . . . . . . . . 2 54 2.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2.2. Green or Trusted Networks . . . . . . . . . . . . . . . . 2 56 2.3. Yellow or Unknown Networks . . . . . . . . . . . . . . . 3 57 2.4. Red or Hostile Networks . . . . . . . . . . . . . . . . . 3 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 60 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 62 5.2. Informative References . . . . . . . . . . . . . . . . . 4 63 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 4 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1. Introduction 68 There are a variety of network environments users may interact with 69 where they will be discovering and selecting a DNS resolver each of 70 which presents a different threat level to the user. This document 71 attempts to establish a common set of threats classifications for 72 reference by Adaptive DNS Discovery (ADD) working group drafts. 74 1.1. Requirements Language 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [RFC2119]. 80 2. Classifications 82 2.1. Approach 84 There are many ways to classify and structure threat analysis the 85 approach used here is centered on the perspective of the user and how 86 much subjective trust they can place in different access network 87 situations that they may encounter. 89 2.2. Green or Trusted Networks 91 These are networks in which the user has an high sense of trust. 92 These are networks run by a trusted party who is known to the user 93 and is trusted by the user to operate the network with security and 94 operational integrity. While even the best run network can be 95 compromised by attackers or malware, the user has subjective trust 96 that the Green network is very unlikely to be compromised. 98 The user often has a relationship with the network operator - either 99 personally, as an employee, or by contract they user has entered into 100 such as with an ISP or Mobile Carrier. 102 Examples of Green Networks 104 o User's own home network 106 o User's organization, company, or enterprise network 108 o Mobile user's mobile network 110 o User's ISP network 112 2.3. Yellow or Unknown Networks 114 These are networks in which the user does not have any sense of trust 115 and yet has no sense or expectation that the network maybe 116 compromised or hostile. The network's threat level is simply 117 unknown. 119 These are networks which provided a service to visitors such as 120 public Wifi networks. 122 Examples of Yellow Networks 124 o School network 126 o Cafe or coffee shop network 128 o Airport network 130 o Hotel network 132 o Conference or event network 134 2.4. Red or Hostile Networks 136 These are networks in which the user has an high sense of potential 137 threats being present, but the use may have no other choice but to 138 use them. 140 These are networks which the user not only does not trust, but also 141 expects the network maybe doing things that the user does not want. 143 Red Networks 145 o War zone region network 146 o Hostile regime network 148 3. IANA Considerations 150 This memo includes no request to IANA. 152 All drafts are required to have an IANA considerations section (see 153 Guidelines for Writing an IANA Considerations Section in RFCs 154 [RFC5226] for a guide). If the draft does not require IANA to do 155 anything, the section contains an explicit statement that this is the 156 case (as above). If there are no requirements for IANA, the section 157 will be removed during conversion into an RFC by the RFC Editor. 159 4. Security Considerations 161 All drafts are required to have a security considerations section. 162 See RFC 3552 [RFC3552] for a guide. 164 5. References 166 5.1. Normative References 168 [Contributors] 169 Deen, G., "Authors", 2020. 171 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 172 Requirement Levels", BCP 14, RFC 2119, 173 DOI 10.17487/RFC2119, March 1997, 174 . 176 5.2. Informative References 178 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 179 Text on Security Considerations", BCP 72, RFC 3552, 180 DOI 10.17487/RFC3552, July 2003, 181 . 183 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 184 IANA Considerations Section in RFCs", RFC 5226, 185 DOI 10.17487/RFC5226, May 2008, 186 . 188 Appendix A. Additional Stuff 190 This becomes an Appendix. 192 Author's Address 194 Glenn Deen 195 Comcast-NBCUniversal 196 Universal City, California 91608 197 USA 199 Email: glenn_deen@comcast.com