idnits 2.17.1 draft-mcfadden-smart-endpoint-taxonomy-for-cless-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D:draft-taddei-smart-cless-introduction]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 450 has weird spacing: '...es from the d...' -- The document date (July 8, 2019) is 1747 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D:draft-taddei-smart-cless-introduction' is mentioned on line 49, but not defined == Missing Reference: 'TECE' is mentioned on line 229, but not defined == Unused Reference: '1' is defined on line 556, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 566, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SMART M McFadden 2 Internet Draft internet policy advisors ltd 3 Intended status: Informational July 8, 2019 4 Expires: January 8, 2020 6 Endpoint Taxonomy for CLESS 7 draft-mcfadden-smart-endpoint-taxonomy-for-cless-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on January 8, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 A separate document [I-D:draft-taddei-smart-cless-introduction] 50 (CLESS) attempts to establish the capabilities and limitations of 51 endpoint-only security solutions and explore potential alternative 52 approaches. That document discusses endpoints in general terms. It 53 has been suggested that there are classes of endpoints that have 54 different characteristics. Those classes may have completely 55 different threat landscapes and the endpoints may have completely 56 different security capabilities. In support of the work on CLESS, 57 this document provides a taxonomy of endpoints that is intended to 58 provide a foundation for further work on CLESS and research on 59 approaches to providing endpoint security alternatives in a diverse 60 group of settings. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Conventions used in this document..............................4 66 3. Problem Statement..............................................4 67 4. The Endpoint in CLESS..........................................4 68 5. Taxonomy.......................................................5 69 5.1. Traditional and Enterprise Computing Equipment [TECE].....6 70 5.1.1. Description..........................................6 71 5.1.2. Endpoint characteristics.............................6 72 5.2. Personal Computing Equipment..............................6 73 5.2.1. Description..........................................6 74 5.2.2. Endpoint characteristics.............................7 75 5.3. Human Interface Devices...................................8 76 5.3.1. Endpoint description.................................8 77 5.3.2. Endpoint characteristics.............................8 78 5.4. Human Sensor Devices......................................8 79 5.4.1. Endpoint characteristics.............................8 80 5.5. Non-human Sensor Devices..................................9 81 5.5.1. Endpoint Description.................................9 82 5.5.2. Endpoint characteristics.............................9 83 5.6. Peripheral Computing Equipment and Embedded Endpoints....10 84 5.6.1. Endpoint Description................................10 85 5.6.2. Endpoint characteristics............................10 86 5.7. Internet Infrastructure Devices..........................11 87 5.7.1. Endpoint Description................................11 88 5.7.2. Endpoint characteristics............................11 89 5.8. Application Layer Endpoints..............................12 90 5.8.1. Description.........................................12 91 5.8.2. Endpoint Characteristics............................12 92 6. Security Considerations.......................................12 93 7. IANA Considerations...........................................12 94 8. References....................................................12 95 8.1. Normative References.....................................12 96 8.2. Informative References...................................13 97 9. Acknowledgments...............................................13 98 Appendix A. Document History.....................................14 100 1. Introduction 102 A document entitled "Capabilities and Limitations of an Endpoint-only 103 Security Solution (CLESS) [I-D. draft-taddei-smart-cless- 104 introduction-00] attempts to initiate research into the limits of 105 endpoint-only security solutions. The document identifies changes in 106 technology, economics and protocol development that have impacted the 107 provision of endpoint security. 109 The CLESS introduction focuses on endpoints that are User Equipment 110 rather than hosts. Even so, this encompasses an enormous variety of 111 possible endpoints. CLESS takes a unified view of endpoints - seeing 112 them all as one type. 114 However, it seems reasonable to suggest that, in the huge variety of 115 types of endpoints, there are categories of similarity. These 116 categories are important because categories of endpoint devices may 117 share particular advantages or limitations for endpoint security. 118 While CLESS provides a clear model for understanding some of the 119 limitations of endpoint security in today's networks, it is very 120 likely that more specificity is needed. 122 This draft attempts to suggest a Taxonomy of Endpoints as a 123 foundation for further work on CLESS. The goal is to identify 124 classes of endpoints with similar characteristics. Those 125 characteristics may lead to the discovery that the devices in a 126 particular category share similar characteristics for endpoint 127 security. 129 It is essential to understand that this taxonomy is intended as a 130 foundation for work on CLESS and is not an all-purpose guide to the 131 enormous breadth of devices that are or could be endpoints on public 132 or private networks. Others have attempted to provide classifications 133 for end devices, but they are not focused on the issues related to 134 endpoint security. In addition, most are almost immediately out-of- 135 date when published. 137 This document takes a different approach: the taxonomy here is 138 intended to support the work of CLESS and provide a classification 139 system that may make it possible to group endpoints in related 140 categories for the purpose of discussing their security 141 characteristics. While a general-purpose taxonomy of Internet 142 endpoints might be useful in a variety of settings, it is not the 143 intended goal of this document. 145 In addition, this document does not attempt to assess and document 146 the endpoint security characteristics of each part of the taxonomy. 147 The work of identifying advantages and limitations of specific 148 classes of endpoints is envisioned as future work on CLESS. 150 2. Conventions used in this document 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 3. Problem Statement 158 CLESS attempts to provide an analysis of the current state of the 159 provision of endpoint security. It does that by providing a 160 provisional definition of an endpoint and then examining the 161 advantages and limitations of providing security at that endpoint. 163 The original approach to CLESS divides the universe of endpoints into 164 User Equipment (UE) and hosts - and then focuses entirely on User 165 Equipment. 167 User Equipment encompasses a very broad set of endpoints. It may be 168 possible to provide a stronger set of device type groupings. 169 Endpoints in the same groups may share security chrematistics that 170 are particular to that group. The fundamental question is: can a 171 taxonomy of endpoint devices be created that allows for grouping of 172 endpoints that have similar security characteristics? 174 If it is possible to answer that question in the affirmative, then 175 research can be done on the security characteristics of each category 176 and influence the development of protocols that have the greatest 177 impact for those type of devices. 179 4. The Endpoint in CLESS 181 CLESS simplifies the representation of an endpoint by making the 182 following generalization: 184 +------------------------------------------------+ 185 | | 186 | Application | 187 | | 188 |------------------------------------------------| 189 | | 190 | OS / Execution Environment | 191 | | 192 |------------------------------------------------| 193 | | 194 | Hardware | 195 | | 196 +------------------------------------------------+ 198 Figure 1 Endpoint Generalization in CLESS 200 This simplification means that there are many combinations of 201 hardware, operating systems, execution environments and applications. 202 It also means that any of these three layers can be an endpoint for 203 the purposes of a discussion of endpoint security. 205 CLESS suggests that we consider endpoints including those which have 206 a variety of power, computational, storage and network capacities. It 207 is possible that grouping devices with similar characteristics will 208 help in identifying categories of devices that share similar endpoint 209 security characteristics. 211 5. Taxonomy 213 Others have attempted to provide general-purpose taxonomy and device 214 classification guides (informative references to be provided in a 215 later draft version). In some settings automated detection and 216 classification of devices provides an essential step in providing 217 appropriate access control and security services. 219 General-purpose classification systems tend to ossify or become 220 enormously complex. Classification has come from commercial entities, 221 computer science organizations, the academic community and even 222 regional collections of cooperating national governments. 224 For the purposes of providing a taxonomy for CLESS, we limit the 225 discussion to a taxonomy for endpoints only. We divide endpoints into 226 nine different classes and then attempt to carefully describe the 227 characteristics of devices in each class. 229 5.1. Traditional and Enterprise Computing Equipment [TECE] 231 5.1.1. Description 233 Traditional and Enterprise Computing Equipment is characterized by 234 its extremely high-capacity for transactional volume, storage and 235 shared user population. TECE forms the backbone of high-volume, high- 236 availability transactional computing and is provided in both physical 237 and virtualized forms. 239 Traditional computing endpoints are shared computing environments 240 characterized by centralized, shared computing. These endpoints are 241 often in large scale data centers. These endpoints are capable of 242 high-availability, substantial requirements for power and 243 environmental control. These endpoints are also characterized by very 244 complex operating systems and user environments. 246 5.1.2. Endpoint characteristics 248 o Cost - these endpoints are characterized by extremely high cost. 250 o Physical size - these are very large endpoints, not suitable or 251 intended for use by an individual. 253 o Network link characteristics - capable of supporting extremely 254 high bandwidth. 256 o User interface - very complex and shared among multiple 257 individuals. 259 o Processing power - extremely high processing capability. 261 o Physical power - requires substantial provision of electrical 262 power and environmental controls. 264 o Code complexity - Extremely high support for very complex code 265 including parallelism, multitaxking and multithreaded execution. 267 5.2. Personal Computing Equipment 269 5.2.1. Description 271 These are endpoints designed or intended to be used by an individual. 272 They can be delivered as fixed, portable or virtual instantiations of 273 the endpoint. It should be noted that virtual instantiations of 274 endpoints introduce complexities in defining the characteristics of 275 the endpoints. In each case, the device supports a mechanism for 276 human-interface and has the capability for both local storage and 277 processing. The personal computing equipment class is also 278 characterized by relatively low cost and power requirements. 280 This class of endpoint is also characterized by the devices 281 supporting multiple purpose use. This class is divided into two sub- 282 classes: fixed and mobile endpoints. The mobile subclass is further 283 divided into four other subclasses: laptops, tablets, intelligent 284 phones, and ultraportable personal computing equipment. 286 Personal computing endpoints usually have at least one, and often 287 many, network links - often supporting a variety of network 288 connectivity technologies. These endpoints are also characterized by 289 having a human interface - either integral to the computing device 290 itself or supplied externally to the computing device. 292 5.2.2. Endpoint characteristics 294 o Cost - these endpoints have a huge range of costs, from extremely 295 inexpensive for simple "personal computer on a board" endpoints to 296 moderately expensive for specially configured laptop and fixed 297 devices. 299 o Physical size - the physical size of these devices range from 300 handheld to a small cabinet for fixed, desktop units. 302 o Network link characteristics - personal computing endpoints are 303 often characterized by supporting multiple connectivity 304 technologies. 306 o User interface - personal computing endpoints are characterized by 307 having user interfaces designed for an individual. The interface 308 varies from simple, text-based interaction to gesture, touch and 309 voice control. 311 o Processing power - these endpoints are characterized by a 312 significant range of processing power: from single CPU units to 313 endpoints that can support multiple concurrent processes. 315 o Physical power - personal computing endpoints are characterized by 316 using either traditional mains power or power supplied by a 317 battery. 319 o Code complexity - personal computing endpoints support complex 320 code and often parallel and multithreaded execution of code. 322 5.3. Human Interface Devices 324 TBD. 326 5.3.1. Endpoint description 328 5.3.2. Endpoint characteristics 330 o Cost 332 o Physical size 334 o Network link characteristics 336 o User interface 338 o Processing power 340 o Physical power 342 o Code complexity 344 5.4. Human Sensor Devices 346 Description 348 These are endpoints whose primary purpose is to sense, store, 349 transmit or process information about a human being. These endpoints 350 are characterized as having use cases in health and wellness 351 monitoring, human performance enhancement, personalized medicine and 352 human safety. 354 The endpoints are characterized as sensor devices with the capacity 355 to sense, store and report on data collected on an individual. The 356 sensor may be multimodal. These endpoints are almost always 357 characterized by have a battery for power and having limited storage, 358 networking and processing capabilities. 360 5.4.1. Endpoint characteristics 362 o Cost - Human Sensor Endpoints can range in cost from very low (for 363 instance a heartbeat sensor) to quite expensive (a sensor built 364 into an implanted device). 366 o Physical size - human sensors are very small and almost always 367 portable. 369 o Network link characteristics - human sensors usually have a single 370 network like technology available and are capable of very limited 371 bandwidth utilization on that link. 373 o User interface - human sensors have extremely limited, or no, user 374 interface. 376 o Processing power - human sensors are characterized by having 377 limited processing power - often incorporating only the ability to 378 collect store and forward sensed information. 380 o Physical power - human sensors are characterized by being powered 381 by internal batteries 383 o Code complexity - human sensors are not usually capable of running 384 complex code. Often, the capability of the endpoint is to simply 385 sense, store and forward data without reporting and analysis of 386 that data. 388 5.5. Non-human Sensor Devices 390 5.5.1. Endpoint Description 392 These endpoints are capable of sensing, storage, communication and 393 possibly some computation. They are characterized by having very low 394 bandwidth radios, a battery for power, sensor technology and a small 395 processor. Unlike in Section 5.4, these devices are not intended to 396 sense human-related information. 398 Compared with Human Sensors, non-human sensors often have a variety 399 of communications technologies available - for instance, self- 400 organizing into mesh networks. 402 5.5.2. Endpoint characteristics 404 o Cost - Non-human Sensor Endpoints can range in cost from very low 405 (for instance, a simple temperature sensor) to quite expensive (a 406 sensor built into an implanted device. 408 o Physical size - Non-human sensors are often small and almost 409 always portable. 411 o Network link characteristics - Non-human sensors usually have a 412 single network like technology available but the topology of those 413 network links can be highly varied. Quite often these devices are 414 capable of very limited bandwidth utilization on the link to which 415 they are attached. 417 o User interface - non-human sensors have extremely limited, or no, 418 user interface. 420 o Processing power - non-human sensors are characterized by having 421 limited processing power - often incorporating only the ability to 422 collect store and forward sensed information. Some non-human 423 sensors have the capability to process stored data, but usually 424 this is limited. 426 o Physical power - - 428 o Code complexity - non-human sensors are not usually capable of 429 running complex code. Often, the capability of the endpoint is to 430 simply sense, store and forward data without reporting and 431 analysis of that data. 433 5.6. Peripheral Computing Equipment and Embedded Endpoints 435 5.6.1. Endpoint Description 437 These are endpoints that are "embedded" in devices that may have a 438 different primary function. An example is a network endpoint in a 439 printer that supports remote access, configuration and printing. 440 Another example is an endpoint in an appliance that has a different 441 primary function (for instance, a refrigerator). 443 In either case, the endpoint is characterized as being added to 444 another system, machine or peripheral. 446 These devices are characterized as being specialized for their 447 particular use case and function. Their specific characteristics 448 often depend upon the system, device or peripheral in which they are 449 being hosted. As an example, the embedded endpoint gets its physical 450 power and networking capabilities from the device in which it is 451 connected. 453 5.6.2. Endpoint characteristics 455 o Cost - almost never available as a standalone device - instead, 456 always embedded into the peripheral or system which is hosting it. 458 o Physical size - almost always very small - to be embedded into 459 some other system or device. 461 o Network link characteristics - dependent on network services 462 available from the host device and not always IP-based. 464 o User interface - almost always provided by the "hosting" device. 465 Many embedded endpoints share a user interface with the 466 configuration and control tool for the underlying device. 468 o Processing power - usually limited and constrained by the use 469 case. Some embedded endpoints provide remote access to the 470 underlying resources provided by the processor. 472 o Physical power - generally supplied by the "host" system or 473 device. 475 o Code complexity - limited and almost always constrained by use 476 case. 478 5.7. Internet Infrastructure Devices 480 5.7.1. Endpoint Description 482 Internet Infrastructure endpoints are the physical components that 483 are used to deploy a network. There is a huge variety of these 484 devices, but they all share two common properties: they are building 485 blocks of the underlying network infrastructure and they also can be 486 endpoints of a network conversation. 488 But, there's an important question here. CLESS specifically rules out 489 network infrastructure in its discussion. Should the taxonomy for 490 CLESS incorporate endpoints that are part of the network 491 infrastructure? Said a different way: is network infrastructure out 492 of scope for CLESS? 494 5.7.2. Endpoint characteristics 496 TBD, depending on the answer to the question in section 5.7.1 498 o Cost 500 o Physical size 502 o Network link characteristics 504 o User interface 506 o Processing power 508 o Physical power 510 o Code complexity 512 5.8. Application Layer Endpoints 514 5.8.1. Description 516 A significant trend in the contemporary public Internet is to have 517 applications act as completely independent agents - a situation where 518 the application itself provides the necessary infrastructure (for 519 instance, domain name resolution) to provide services. An example 520 would be a web browser that independently resolved domain names and 521 established secure communication channels independently. 523 The traffic between the application and the servers it uses might not 524 be available for analysis by security software. As a result, 525 application-based endpoints would have the characteristic of having 526 to provide security services (for instance, traffic security or 527 malware detection) for itself. 529 This type of endpoint also has the characteristic of potentially 530 having adverse impacts on other applications running on the same 531 platform. For example, if several applications are provisioning their 532 own infrastructure services, then those services are being duplicated 533 on that platform. For security related infrastructure there would be 534 no common, platform-wide approach to securing the applications or the 535 traffic generated between the application and external servers. 537 5.8.2. Endpoint Characteristics 539 TBD 541 6. Security Considerations 543 INFO (REMOVE): Every draft MUST have a Security Considerations 544 section. 546 TBD, descriptive 548 7. IANA Considerations 550 This document has no requirements or actions for IANA 552 8. References 554 8.1. Normative References 556 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 557 Levels", BCP 14, RFC 2119, March 1997. 559 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 560 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 561 Demon Internet Ltd., November 1997. 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 567 Syntax Specifications: ABNF", RFC 2234, Internet Mail 568 Consortium and Demon Internet Ltd., November 1997. 570 8.2. Informative References 572 TBD 574 9. Acknowledgments 576 This document was prepared using 2-Word-v2.0.template.dot. 578 Appendix A. Document History 580 [[ To be removed from the final document ]] 582 -0 584 Initial Internet Draft 586 Authors' Addresses 588 Mark McFadden 589 Internet policy advisors ltd 590 Madison Wisconsin US 592 Email: mark@internetpolicyadvisors.com 594 Phone: 595 Email: