idnits 2.17.1 draft-mcfadden-opsec-endp-taxonomy-01.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-mcfadden-opsec-endp-evolve]), 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 16, 2021) is 983 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I-D:draft-mcfadden-opsec-endp-evolve' on line 48 looks like a reference -- Missing reference section? 'RFC2119' on line 140 looks like a reference -- Missing reference section? 'TECE' on line 243 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission M McFadden 2 Internet Draft internet policy advisors ltd 3 Intended status: Informational August 16, 2021 4 Expires: February 16, 2022 6 Evolution of Endpoint Security - A Taxonomy for Endpoints 7 draft-mcfadden-opsec-endp-taxonomy-01 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 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference 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 February 16, 2022. 32 Copyright Notice 34 Copyright (c) 2021 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 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 48 A separate document [I-D:draft-mcfadden-opsec-endp-evolve] attempts 49 to establish the capabilities and limitations of endpoint-only 50 security solutions and explore potential alternative approaches. 51 That document discusses endpoints in general terms. It has been 52 suggested that there are classes of endpoints that have different 53 characteristics. Those classes may have completely different threat 54 landscapes and the endpoints may have completely different security 55 capabilities. As a companion to the endpoint evolution draft, this 56 document provides a taxonomy of endpoints that is intended to 57 provide a foundation for further work on endpoint security evolution 58 and research on approaches to providing endpoint security 59 alternatives in a diverse group of settings. 61 Table of Contents 63 1. Introduction...................................................3 64 2. Conventions used in this document..............................3 65 3. Problem Statement..............................................4 66 4. The Endpoint in the EVOLVE draft...............................4 67 5. Taxonomy and Hierarchy.........................................5 68 6. Taxonomy.......................................................5 69 6.1. Traditional and Enterprise Computing Equipment [TECE].....6 70 6.1.1. Description..........................................6 71 6.1.2. Endpoint characteristics.............................6 72 6.2. Personal Computing Equipment..............................7 73 6.2.1. Description..........................................7 74 6.2.2. Endpoint characteristics.............................7 75 6.3. Human Interface Devices...................................8 76 6.3.1. Endpoint description.................................8 77 6.3.2. Endpoint characteristics.............................8 78 6.4. Human Sensor Devices......................................9 79 6.4.1. Endpoint characteristics............................10 80 6.5. Non-human Sensor Devices.................................10 81 6.5.1. Endpoint Description................................10 82 6.5.2. Endpoint characteristics............................11 83 6.6. Peripheral Computing Equipment and Embedded Endpoints....11 84 6.6.1. Endpoint Description................................11 85 6.6.2. Endpoint characteristics............................12 86 6.7. Application Layer Endpoints..............................12 87 6.7.1. Description.........................................12 88 6.7.2. Endpoint Characteristics............................13 89 6.8. Edge Network and Acquisition Endpoints...................13 90 6.8.1. Description.........................................13 91 6.8.2. Endpoint characteristics............................14 92 7. Security Considerations.......................................15 93 8. IANA Considerations...........................................15 94 9. References....................................................15 95 9.1. Informative References ..................................15 96 10. Acknowledgments..............................................15 97 Appendix A. Document History.....................................17 99 1. Introduction 101 A document entitled "Evolution of Endpoint Security - An Operational 102 Perspective (EVOLVE) [I-D. draft-mcfadden-opsec-endp-evolve-00] 103 attempts to initiate research into the limits of endpoint-only 104 security solutions. 106 This draft attempts to suggest a Taxonomy of Endpoints as a 107 foundation for further work on the EVOLVE draft. The goal is to 108 identify classes of endpoints with similar characteristics. Those 109 characteristics may lead to the discovery that the devices in a 110 particular category share similar characteristics for endpoint 111 security. 113 It is essential to understand that this taxonomy is intended as a 114 foundation for work on the EVOLVE draft and is not an all-purpose 115 guide to the enormous breadth of devices that are or could be 116 endpoints on public or private networks. Others have attempted to 117 provide classifications for end devices, but they are not focused on 118 the issues related to endpoint security. In addition, most are 119 almost immediately out-of-date when published. 121 This document takes a different approach: the taxonomy here is 122 intended to support the work of the EVOLVE draft and provide a 123 classification system that may make it possible to group endpoints 124 in related categories for the purpose of discussing their security 125 characteristics. While a general-purpose taxonomy of Internet 126 endpoints might be useful in a variety of settings, it is not the 127 intended goal of this document. 129 In addition, this document does not attempt to assess and document 130 the endpoint security characteristics of each part of the taxonomy. 131 The work of identifying advantages and limitations of specific 132 classes of endpoints is envisioned as future work on the EVOLVE 133 draft. 135 2. Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 3. Problem Statement 143 The EVOLVE draft attempts to provide an analysis of the current 144 state of the provision of endpoint security. It does that by 145 providing a provisional definition of an endpoint and then examining 146 the advantages and limitations of providing security at that 147 endpoint. 149 The original approach to the EVOLVE draft divides the universe of 150 endpoints into User Equipment (UE) and hosts - and then focuses 151 entirely on User Equipment. 153 User Equipment encompasses a very broad set of endpoints. It may be 154 possible to provide a stronger set of device type groupings. 155 Endpoints in the same groups may share security characteristics that 156 are particular to that group. The fundamental question is: can a 157 taxonomy of endpoint devices be created that allows for grouping of 158 endpoints that have similar security characteristics? 160 If it is possible to answer that question in the affirmative, then 161 research can be done on the security characteristics of each 162 category and influence the development of protocols that have the 163 greatest impact for those type of devices. 165 4. The Endpoint in the EVOLVE draft 167 The EVOLVE draft simplifies the representation of an endpoint by 168 providing the following model: 170 +------------------------------------------------+ 171 | | 172 | Application | 173 | | 174 |------------------------------------------------| 175 | | 176 | OS / Execution Environment | 177 | | 178 |------------------------------------------------| 179 | | 180 | Hardware | 181 | | 182 +------------------------------------------------+ 184 Figure 1 Endpoint Generalization in the EVOLVE draft 186 This simplification means that there are many combinations of 187 hardware, operating systems, execution environments and 188 applications. It also means that any of these three layers can be an 189 endpoint for the purposes of a discussion of endpoint security. 191 The EVOLVE draft suggests that we consider endpoints including those 192 which have a variety of power, computational, storage and network 193 capacities. It is possible that grouping devices with similar 194 characteristics will help in identifying categories of devices that 195 share similar endpoint security characteristics. 197 5. Taxonomy and Hierarchy 199 One suggestion for the taxonomy for endpoints is to consider a 200 hierarchy of endpoints that collects similar endpoint types in large 201 categories and then distinguishes between them in "sub-groups" or 202 lower levels of the taxonomy. 204 The advantage to using both the taxonomy and the EVOLVE draft is 205 that the groupings may provide a way to categorize threats and 206 mitigations to large classes of endpoints on the Internet while 207 providing the ability for differentiation. An example might be a 208 class of endpoints characterized as "constrained devices." 210 As an example, "constrained devices" might be further subdivided 211 into sub-classes such as sensors, embedded processors, specific (or, 212 special) purpose single-use processors, mesh gateways, and so forth. 213 It can even be imagined that the second level of the hierarchy could 214 be further subdivided by further distinguishing the endpoint types. 216 The current version of the draft does not take this approach. One of 217 the goals of the endpoint taxonomy is to provide enough 218 differentiation and specificity to ensure that a later version of 219 the EVOLVE draft can successfully discuss common threats and 220 mitigations for each of the categories in the taxonomy. By providing 221 an ever greater hierarchy of endpoint types, it becomes difficult to 222 scale the EVOLVE document that discusses threats and mitigations to 223 the highly specific endpoint types. 225 6. Taxonomy 227 Others have attempted to provide general-purpose taxonomy and device 228 classification guides (informative references to be provided in a 229 later draft version). In some settings automated detection and 230 classification of devices provides an essential step in providing 231 appropriate access control and security services. 233 General-purpose classification systems tend to ossify or become 234 enormously complex. Classification has come from commercial 235 entities, computer science organizations, the academic community and 236 even regional collections of cooperating national governments. 238 For the purposes of providing a taxonomy for the EVOLVE draft, we 239 limit the discussion to a taxonomy for endpoints only. We divide 240 endpoints into eight different classes and then attempt to carefully 241 describe the characteristics of devices in each class. 243 6.1. Traditional and Enterprise Computing Equipment [TECE] 245 6.1.1. Description 247 Traditional and Enterprise Computing Equipment is characterized by 248 its extremely high-capacity for transactional volume, storage and 249 shared user population. TECE forms the backbone of high-volume, 250 high-availability transactional computing and is provided in both 251 physical and virtualized forms. 253 Traditional computing endpoints are shared computing environments 254 characterized by centralized, shared computing. These endpoints are 255 often in large scale data centers. These endpoints are capable of 256 high-availability, substantial requirements for power and 257 environmental control. These endpoints are also characterized by 258 very complex operating systems and user environments. 260 6.1.2. Endpoint characteristics 262 o Cost - these endpoints are characterized by extremely high cost. 264 o Physical size - these are very large endpoints, not suitable or 265 intended for use by an individual. 267 o Network link characteristics - capable of supporting extremely 268 high bandwidth. 270 o User interface - very complex and shared among multiple 271 individuals. 273 o Processing power - extremely high processing capability. 275 o Physical power - requires substantial provision of electrical 276 power and environmental controls. 278 o Code complexity - Extremely high support for very complex code 279 including parallelism, multitasking and multithreaded execution. 281 6.2. Personal Computing Equipment 283 6.2.1. Description 285 These are endpoints designed or intended to be used by an 286 individual. They can be delivered as fixed, portable or virtual 287 instantiations of the endpoint. It should be noted that virtual 288 instantiations of endpoints introduce complexities in defining the 289 characteristics of the endpoints. In each case, the device supports 290 a mechanism for human-interface and has the capability for both 291 local storage and processing. The personal computing equipment class 292 is also characterized by relatively low cost and power requirements. 294 This class of endpoint is also characterized by the devices 295 supporting multiple purpose use. This class is divided into two 296 sub-classes: fixed and mobile endpoints. The mobile subclass is 297 further divided into four other subclasses: laptops, tablets, 298 intelligent phones, and ultraportable personal computing equipment. 300 Personal computing endpoints usually have at least one, and often 301 many, network links - often supporting a variety of network 302 connectivity technologies. These endpoints are also characterized 303 by having a human interface - either integral to the computing 304 device itself or supplied externally to the computing device. 306 6.2.2. Endpoint characteristics 308 o Cost - these endpoints have a huge range of costs, from extremely 309 inexpensive for simple "personal computer on a board" endpoints 310 to moderately expensive for specially configured laptop and fixed 311 devices. 313 o Physical size - the physical size of these devices range from 314 handheld to a small cabinet for fixed, desktop units. 316 o Network link characteristics - personal computing endpoints are 317 often characterized by supporting multiple connectivity 318 technologies. 320 o User interface - personal computing endpoints are characterized 321 by having user interfaces designed for an individual. The 322 interface varies from simple, text-based interaction to gesture, 323 touch and voice control. 325 o Processing power - these endpoints are characterized by a 326 significant range of processing power: from single CPU units to 327 endpoints that can support multiple concurrent processes. 329 o Physical power - personal computing endpoints are characterized 330 by using either traditional mains power or power supplied by a 331 battery. 333 o Code complexity - personal computing endpoints support complex 334 code and often parallel and multithreaded execution of code. 336 6.3. Human Interface Devices 338 6.3.1. Endpoint description 340 Human interface transactions begin with a task-related goal for a 341 user. This leads to a user behavior (such as pointing, typing or 342 touching) which occurs in the current computing environment. The 343 user's action then should trigger an event in the current computing 344 environment. 346 Early computer science research breaks the taxonomy for Human 347 Interface Devices into four large categories: input devices, 348 pointing devices, indirect pointing and speech recognition. More 349 recent research adds neural interfaces, VR sensors, and human 350 attribute sensors. In all of these cases, the endpoints have the 351 goal of providing a mechanism for user navigation, interconnection, 352 form filling, menu interaction, data entry or sensing of human input 353 (although not to be confused with the following category in the 354 taxonomy). The result is that this category of the taxonomy has been 355 characterized by extremely limited computing capability in the past. 356 In contemporary networks the human interface devices are far more 357 complex and, as a result, subject to a wider collections of risks as 358 endpoints. 360 Since human interface devices are often the mechanism that provides 361 control of a computing resource, attacks on those devices are of 362 particular concern. In the past, the idea that there was an 363 external threat to a mouse or a pointing device would be ignored. In 364 contrast, today's voice actuated input devices and VR interfaces are 365 sophisticated enough to represent a real platform for attack. 367 6.3.2. Endpoint characteristics 369 o Cost - these endpoints are typically low in cost compared to 370 traditional computing equipment. They are often closer in cost to 371 simple peripheral equipment rather than endpoints that provide 372 general purpose computing platforms. 374 o Physical size - these devices are meant to provide a human 375 interface and are sized appropriately to that use case. Examples 376 include those devices that are small enough to be handheld or 377 worn. 379 o Network link characteristics - human interface devices are 380 connected in a variety of ways. Early devices were wired to the 381 device to which they provided connectivity. More recently, these 382 devices have a network connection between them and the connected 383 device. Examples of this connection use Bluetooth or other, very 384 local network connections. These devices may have connections to 385 wider networks to support applications such as augmented reality. 387 o User interface - generally these devices provide a user interface 388 rather than having a distinct user interface of their own. More 389 complex human interface devices have limited interfaces for 390 settings and control of the device, and its connectivity and 391 function. 393 o Processing power - these devices are characterized by having 394 limited processing power. 396 o Physical power - most human interface devices are characterized 397 by having limited power requirements. They are sometimes powered 398 by their connection to the device. In other cases, they are 399 powered by a battery. 401 o Code complexity - human interface devices tend to have either no 402 or very limited capabilities to execute code. Modern interface 403 devices which support presentation of a virtual physical 404 environment are capable of executing the code needed to provide 405 the interface between the presentation of visual (and other) 406 stimuli while responding to gestures and movement of the person 407 using the device. 409 6.4. Human Sensor Devices 411 Description 413 These are endpoints whose primary purpose is to sense, store, 414 transmit or process information about a human being. These 415 endpoints are characterized as having use cases in health and 416 wellness monitoring, human performance enhancement, personalized 417 medicine and human safety. 419 The endpoints are characterized as sensor devices with the capacity 420 to sense, store and report on data collected on an individual. The 421 sensor may be multimodal. These endpoints are almost always 422 characterized by have a battery for power and having limited 423 storage, networking and processing capabilities. 425 6.4.1. Endpoint characteristics 427 o Cost - Human Sensor Endpoints can range in cost from very low 428 (for instance a heartbeat sensor) to quite expensive (a sensor 429 built into an implanted device). 431 o Physical size - human sensors are very small and almost always 432 portable. 434 o Network link characteristics - human sensors usually have a 435 single network like technology available and are capable of very 436 limited bandwidth utilization on that link. 438 o User interface - human sensors have extremely limited, or no, 439 user interface. 441 o Processing power - human sensors are characterized by having 442 limited processing power - often incorporating only the ability 443 to collect store and forward sensed information. 445 o Physical power - human sensors are characterized by being powered 446 by internal batteries 448 o Code complexity - human sensors are not usually capable of 449 running complex code. Often, the capability of the endpoint is to 450 simply sense, store and forward data without reporting and 451 analysis of that data. 453 6.5. Non-human Sensor Devices 455 6.5.1. Endpoint Description 457 These endpoints are capable of sensing, storage, communication and 458 possibly some computation. They are characterized by having very low 459 bandwidth radios, a battery for power, sensor technology and a small 460 processor. Unlike in Section 5.4, these devices are not intended to 461 sense human-related information. 463 Compared with Human Sensors, non-human sensors often have a variety 464 of communications technologies available - for instance, self- 465 organizing into mesh networks. 467 6.5.2. Endpoint characteristics 469 o Cost - Non-human Sensor Endpoints can range in cost from very low 470 (for instance, a simple temperature sensor) to quite expensive (a 471 sensor built into an implanted device. 473 o Physical size - Non-human sensors are often small and almost 474 always portable. 476 o Network link characteristics - Non-human sensors usually have a 477 single network like technology available but the topology of 478 those network links can be highly varied. Quite often these 479 devices are capable of very limited bandwidth utilization on the 480 link to which they are attached. 482 o User interface - non-human sensors have extremely limited, or no, 483 user interface. 485 o Processing power - non-human sensors are characterized by having 486 limited processing power - often incorporating only the ability 487 to collect store and forward sensed information. Some non-human 488 sensors have the capability to process stored data, but usually 489 this is limited. 491 o Physical power - non-human sensors often require very limited 492 amounts of power - very often provided by a battery. 494 o Code complexity - non-human sensors are not usually capable of 495 running complex code. Often, the capability of the endpoint is to 496 simply sense, store and forward data without reporting and 497 analysis of that data. 499 6.6. Peripheral Computing Equipment and Embedded Endpoints 501 6.6.1. Endpoint Description 503 These are endpoints that are "embedded" in devices that may have a 504 different primary function. An example is a network endpoint in a 505 printer that supports remote access, configuration and printing. 506 Another example is an endpoint in an appliance that has a different 507 primary function (for instance, a refrigerator). 509 In either case, the endpoint is characterized as being added to 510 another system, machine or peripheral. 512 These devices are characterized as being specialized for their 513 particular use case and function. Their specific characteristics 514 often depend upon the system, device or peripheral in which they are 515 being hosted. As an example, the embedded endpoint gets its 516 physical power and networking capabilities from the device in which 517 it is connected. 519 6.6.2. Endpoint characteristics 521 o Cost - almost never available as a standalone device - instead, 522 always embedded into the peripheral or system which is hosting 523 it. 525 o Physical size - almost always very small - to be embedded into 526 some other system or device. 528 o Network link characteristics - dependent on network services 529 available from the host device and not always IP-based. 531 o User interface - almost always provided by the "hosting" device. 532 Many embedded endpoints share a user interface with the 533 configuration and control tool for the underlying device. 535 o Processing power - usually limited and constrained by the use 536 case. Some embedded endpoints provide remote access to the 537 underlying resources provided by the processor. 539 o Physical power - generally supplied by the "host" system or 540 device. 542 o Code complexity - limited and almost always constrained by use 543 case. 545 6.7. Application Layer Endpoints 547 6.7.1. Description 549 A significant trend in the contemporary public Internet is to have 550 applications act as completely independent agents - a situation 551 where the application itself provides the necessary infrastructure 552 (for instance, domain name resolution) to provide services. An 553 example would be a web browser that independently resolved domain 554 names and established secure communication channels independently. 556 The traffic between the application and the servers it uses might 557 not be available for analysis by security software. As a result, 558 application-based endpoints would have the characteristic of having 559 to provide security services (for instance, traffic security or 560 malware detection) for itself. 562 This type of endpoint also has the characteristic of potentially 563 having adverse impacts on other applications running on the same 564 platform. For example, if several applications are provisioning 565 their own infrastructure services, then those services are being 566 duplicated on that platform. For security related infrastructure 567 there would be no common, platform-wide approach to securing the 568 applications or the traffic generated between the application and 569 external servers. 571 6.7.2. Endpoint Characteristics 573 o Cost - applications vary widely in cost and some are free. 575 o Physical size - based on code, application endpoints do not have 576 physical characteristics (e.g. size, power requirements, etc.). 578 o Network link characteristics - applications often use network 579 facilities provided by lower layers of the stack. In particular, 580 many application endpoints use the network services provided by 581 the underlying operating system that acts as the host for the 582 application. An emerging trend in both wired and wireless 583 networks is for the application to interface with the network 584 link to control or provide some of the network link services for 585 itself. An example of this would be an application that does DNS 586 resolution services for itself rather then depending on the 587 underlying operating system to provide that service. 589 o User interface - the application usually provides its own user 590 interface which can be minimal (for instance, command line 591 driven) or complex (windows or VR driven). 593 o Processing power - always dependent on the device on which the 594 application is hosted. 596 o Physical power - based on code, application endpoints do not have 597 physical requirements (e.g. power) 599 o Code complexity - highly variable. Applications can be very 600 simple or highly complex depending on the application's 601 requirements. 603 6.8. Edge Network and Acquisition Endpoints 605 6.8.1. Description 607 The emergence of intelligent devices and things has led to new 608 network designs where data is aggregated at points topologically 609 close to where the data is gathered. The gathered data can then 610 have the option to flow to nearby gateways, or a Wi-Fi/W-LAN (SD- 611 WAN) router/equipment, or the telco tower/rooftop towers. These 612 often perform an acquisition function that includes both aggregation 613 and data condensation. 615 They usually have some level of processing capability. The main task 616 for these devices is to collect the data from various other 617 endpoints and send the processed data upstream. In doing so, they 618 often perform some low-level data processing, such as data filtering 619 (which determines what data is sent/blocked) and data analytics. 621 The acquisition systems are often architected to talk to distributed 622 data centers and end devices; for instance, on a factory shop floor, 623 a CDN's edge PoP (Point of Presence), an edge colocation local, or a 624 metro regional datacenter for a Telco or IT Service Provider. 626 In all cases, these edge computing devices represent a newer class 627 of endpoints. These are endpoints that are not at the extreme edge 628 of the network, but provide services to the devices at those edges 629 (especially for those devices in the class discussed in section 6.4 630 and 6.5 above). 632 The threats and mitigations for this class of device is expected to 633 be significantly different from those in sections 6.4 and 6.5. 635 6.8.2. Endpoint characteristics 637 o Cost - highly variable. Edge network devices in 5G networks can 638 be very expensive. Aggregation nodes in sensor networks can be 639 very inexpensive. 641 o Physical size - highly variable. Edge network devices in 5G 642 networks can be larger than personal computing equipment. 643 Aggregation nodes in sensor networks can be as small as a circuit 644 board, battery and radio. 646 o Network link characteristics - by their nature, these devices 647 have at least a pair of network links. One of these links faces 648 toward the network where the data is being aggregated. The other 649 faces toward the network where the data is being processed, 650 analyzed or reported upon. 652 o User interface - these devices usually have a limited user 653 interface, characterized by the need to configure the device, 654 provide security and allow for management of the network links. 656 o Processing power - usually these devices have limited processing 657 power: their emphasis is on aggregation and management of data 658 flows between networks. 660 o Physical power - highly variable. Edge network devices in 5G 661 networks can require significant sources of secure and consistent 662 power. Aggregation nodes in sensor networks can often be 663 supported by a small battery. 665 o Code complexity - usually these devices have limited ability to 666 load and execute code. Since their emphasis is on aggregation and 667 management of data flows between networks, these devices usually 668 have minimal ability to run general purpose code. 670 7. Security Considerations 672 This draft is non-normative and simply attempts to provide a 673 taxonomy for endpoints. The goal of the taxonomy is to document that 674 there are classes of endpoints that have different characteristics. 675 Those classes may have completely different threat landscapes and 676 the endpoints may have completely different security capabilities. 678 In support of the work on the EVOLVE draft [I-D:draft-mcfadden- 679 opsec-endp-evolve-00], this draft provides a taxonomy of endpoints 680 that is intended to provide a foundation for further work on the 681 EVOLVE draft and research on approaches to providing endpoint 682 security alternatives in a diverse group of settings. 684 8. IANA Considerations 686 This memo contains no instructions or requests for IANA. The authors 687 continue to appreciate the efforts of IANA staff in support of the 688 IETF. 690 9. References 692 9.1. Informative References 694 [I-D. draft-mcfadden-opsec-endp-evolve-01], McFadden, M., "Evolution 695 of Endpoint Security - An Operational Perspective", Internet Draft 696 (work in progress), August 2021 698 10. Acknowledgments 700 The original idea for this draft came from another, now expired 701 draft. The authors of that draft intended a comprehensive 702 discussion of endpoint security and a clear description of how the 703 evolution of the Internet made endpoint security - on its own - 704 insufficient. 706 The author thanks those previous contributors: Arnaud Taddei, Bret 707 Jordan, Candid Wueest, Chris Larsen, Andre Engel, Kevin Roundy, 708 Yugiong Sun, and David Wells. 710 The author also extends his appreciation to the discussions in the 711 IAB Activity called model-t where the future of the Internet's 712 threat landscape has also been discussed. 714 This document was prepared using 2-Word-v2.0.template.dot. 716 Appendix A. Document History 718 [[ To be removed from the final document ]] 720 -00 722 Initial Internet Draft 724 -01 726 Minor editorial changes. 728 Authors' Addresses 730 Mark McFadden 731 Internet policy advisors ltd uk 732 6 Bridge Street 733 Chepstow, Wales NP16 5EY 734 United Kingdom 736 Phone: +44 2921 25 3649 737 Email: mark@internetpolicyadvisors.com