idnits 2.17.1 draft-mcfadden-opsec-endp-taxonomy-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-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 (February 14, 2021) is 1161 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 153 looks like a reference -- Missing reference section? 'TECE' on line 256 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 February 14, 2021 4 Expires: August 14, 2021 6 Evolution of Endpoint Security - A Taxonomy for Endpoints 7 draft-mcfadden-opsec-endp-taxonomy-00 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 August 14, 2021. 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..............................4 65 3. Problem Statement..............................................4 66 4. The Endpoint in the EVOLVE draft...............................4 67 5. Taxonomy and Hierarchy.........................................5 68 6. Taxonomy.......................................................6 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.............................8 75 6.3. Human Interface Devices...................................8 76 6.3.1. Endpoint description.................................8 77 6.3.2. Endpoint characteristics.............................9 78 6.4. Human Sensor Devices.....................................10 79 6.4.1. Endpoint characteristics............................10 80 6.5. Non-human Sensor Devices.................................11 81 6.5.1. Endpoint Description................................11 82 6.5.2. Endpoint characteristics............................11 83 6.6. Peripheral Computing Equipment and Embedded Endpoints....12 84 6.6.1. Endpoint Description................................12 85 6.6.2. Endpoint characteristics............................12 86 6.7. Application Layer Endpoints..............................13 87 6.7.1. Description.........................................13 88 6.7.2. Endpoint Characteristics............................13 89 6.8. Edge Network and Acquisition Endpoints...................14 90 6.8.1. Description.........................................14 91 6.8.2. Endpoint characteristics............................15 92 7. Security Considerations.......................................15 93 8. IANA Considerations...........................................16 94 9. References....................................................16 95 9.1. Informative References ..................................16 96 10. Acknowledgments..............................................16 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 The EVOLVE introduction focuses on endpoints that are User Equipment 107 rather than hosts. Even so, this encompasses an enormous variety of 108 possible endpoints. EVOLVE takes a unified view of endpoints - 109 seeing them all as one type. 111 However, it seems reasonable to suggest that, in the huge variety of 112 types of endpoints, there are categories of similarity. These 113 categories are important because categories of endpoint devices may 114 share particular advantages or limitations for endpoint security. 115 While EVOLVE provides a clear model for understanding some of the 116 limitations of endpoint security in today's networks, it is very 117 likely that more specificity is needed. 119 This draft attempts to suggest a Taxonomy of Endpoints as a 120 foundation for further work on the EVOLVE draft. The goal is to 121 identify classes of endpoints with similar characteristics. Those 122 characteristics may lead to the discovery that the devices in a 123 particular category share similar characteristics for endpoint 124 security. 126 It is essential to understand that this taxonomy is intended as a 127 foundation for work on the EVOLVE draft and is not an all-purpose 128 guide to the enormous breadth of devices that are or could be 129 endpoints on public or private networks. Others have attempted to 130 provide classifications for end devices, but they are not focused on 131 the issues related to endpoint security. In addition, most are 132 almost immediately out-of-date when published. 134 This document takes a different approach: the taxonomy here is 135 intended to support the work of the EVOLVE draft and provide a 136 classification system that may make it possible to group endpoints 137 in related categories for the purpose of discussing their security 138 characteristics. While a general-purpose taxonomy of Internet 139 endpoints might be useful in a variety of settings, it is not the 140 intended goal of this document. 142 In addition, this document does not attempt to assess and document 143 the endpoint security characteristics of each part of the taxonomy. 144 The work of identifying advantages and limitations of specific 145 classes of endpoints is envisioned as future work on the EVOLVE 146 draft. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 3. Problem Statement 156 The EVOLVE draft attempts to provide an analysis of the current 157 state of the provision of endpoint security. It does that by 158 providing a provisional definition of an endpoint and then examining 159 the advantages and limitations of providing security at that 160 endpoint. 162 The original approach to the EVOLVE draft divides the universe of 163 endpoints into User Equipment (UE) and hosts - and then focuses 164 entirely on User Equipment. 166 User Equipment encompasses a very broad set of endpoints. It may be 167 possible to provide a stronger set of device type groupings. 168 Endpoints in the same groups may share security characteristics that 169 are particular to that group. The fundamental question is: can a 170 taxonomy of endpoint devices be created that allows for grouping of 171 endpoints that have similar security characteristics? 173 If it is possible to answer that question in the affirmative, then 174 research can be done on the security characteristics of each 175 category and influence the development of protocols that have the 176 greatest impact for those type of devices. 178 4. The Endpoint in the EVOLVE draft 180 The EVOLVE draft simplifies the representation of an endpoint by 181 providing the following model: 183 +------------------------------------------------+ 184 | | 185 | Application | 186 | | 187 |------------------------------------------------| 188 | | 189 | OS / Execution Environment | 190 | | 191 |------------------------------------------------| 192 | | 193 | Hardware | 194 | | 195 +------------------------------------------------+ 197 Figure 1 Endpoint Generalization in the EVOLVE draft 199 This simplification means that there are many combinations of 200 hardware, operating systems, execution environments and 201 applications. It also means that any of these three layers can be an 202 endpoint for the purposes of a discussion of endpoint security. 204 The EVOLVE draft suggests that we consider endpoints including those 205 which have a variety of power, computational, storage and network 206 capacities. It is possible that grouping devices with similar 207 characteristics will help in identifying categories of devices that 208 share similar endpoint security characteristics. 210 5. Taxonomy and Hierarchy 212 One suggestion for the taxonomy for endpoints is to consider a 213 hierarchy of endpoints that collects similar endpoint types in large 214 categories and then distinguishes between them in "sub-groups" or 215 lower levels of the taxonomy. 217 The advantage to using both the taxonomy and the EVOLVE draft is 218 that the groupings may provide a way to categorize threats and 219 mitigations to large classes of endpoints on the Internet while 220 providing the ability for differentiation. An example might be a 221 class of endpoints characterized as "constrained devices." 223 As an example, "constrained devices" might be further subdivided 224 into sub-classes such as sensors, embedded processors, specific (or, 225 special) purpose single-use processors, mesh gateways, and so forth. 226 It can even be imagined that the second level of the hierarchy could 227 be further subdivided by further distinguishing the endpoint types. 229 The current version of the draft does not take this approach. One of 230 the goals of the endpoint taxonomy is to provide enough 231 differentiation and specificity to ensure that a later version of 232 the EVOLVE draft can successfully discuss common threats and 233 mitigations for each of the categories in the taxonomy. By providing 234 an ever greater hierarchy of endpoint types, it becomes difficult to 235 scale the EVOLVE document that discusses threats and mitigations to 236 the highly specific endpoint types. 238 6. Taxonomy 240 Others have attempted to provide general-purpose taxonomy and device 241 classification guides (informative references to be provided in a 242 later draft version). In some settings automated detection and 243 classification of devices provides an essential step in providing 244 appropriate access control and security services. 246 General-purpose classification systems tend to ossify or become 247 enormously complex. Classification has come from commercial 248 entities, computer science organizations, the academic community and 249 even regional collections of cooperating national governments. 251 For the purposes of providing a taxonomy for the EVOLVE draft, we 252 limit the discussion to a taxonomy for endpoints only. We divide 253 endpoints into eight different classes and then attempt to carefully 254 describe the characteristics of devices in each class. 256 6.1. Traditional and Enterprise Computing Equipment [TECE] 258 6.1.1. Description 260 Traditional and Enterprise Computing Equipment is characterized by 261 its extremely high-capacity for transactional volume, storage and 262 shared user population. TECE forms the backbone of high-volume, 263 high-availability transactional computing and is provided in both 264 physical and virtualized forms. 266 Traditional computing endpoints are shared computing environments 267 characterized by centralized, shared computing. These endpoints are 268 often in large scale data centers. These endpoints are capable of 269 high-availability, substantial requirements for power and 270 environmental control. These endpoints are also characterized by 271 very complex operating systems and user environments. 273 6.1.2. Endpoint characteristics 275 o Cost - these endpoints are characterized by extremely high cost. 277 o Physical size - these are very large endpoints, not suitable or 278 intended for use by an individual. 280 o Network link characteristics - capable of supporting extremely 281 high bandwidth. 283 o User interface - very complex and shared among multiple 284 individuals. 286 o Processing power - extremely high processing capability. 288 o Physical power - requires substantial provision of electrical 289 power and environmental controls. 291 o Code complexity - Extremely high support for very complex code 292 including parallelism, multitasking and multithreaded execution. 294 6.2. Personal Computing Equipment 296 6.2.1. Description 298 These are endpoints designed or intended to be used by an 299 individual. They can be delivered as fixed, portable or virtual 300 instantiations of the endpoint. It should be noted that virtual 301 instantiations of endpoints introduce complexities in defining the 302 characteristics of the endpoints. In each case, the device supports 303 a mechanism for human-interface and has the capability for both 304 local storage and processing. The personal computing equipment class 305 is also characterized by relatively low cost and power requirements. 307 This class of endpoint is also characterized by the devices 308 supporting multiple purpose use. This class is divided into two 309 sub-classes: fixed and mobile endpoints. The mobile subclass is 310 further divided into four other subclasses: laptops, tablets, 311 intelligent phones, and ultraportable personal computing equipment. 313 Personal computing endpoints usually have at least one, and often 314 many, network links - often supporting a variety of network 315 connectivity technologies. These endpoints are also characterized 316 by having a human interface - either integral to the computing 317 device itself or supplied externally to the computing device. 319 6.2.2. Endpoint characteristics 321 o Cost - these endpoints have a huge range of costs, from extremely 322 inexpensive for simple "personal computer on a board" endpoints 323 to moderately expensive for specially configured laptop and fixed 324 devices. 326 o Physical size - the physical size of these devices range from 327 handheld to a small cabinet for fixed, desktop units. 329 o Network link characteristics - personal computing endpoints are 330 often characterized by supporting multiple connectivity 331 technologies. 333 o User interface - personal computing endpoints are characterized 334 by having user interfaces designed for an individual. The 335 interface varies from simple, text-based interaction to gesture, 336 touch and voice control. 338 o Processing power - these endpoints are characterized by a 339 significant range of processing power: from single CPU units to 340 endpoints that can support multiple concurrent processes. 342 o Physical power - personal computing endpoints are characterized 343 by using either traditional mains power or power supplied by a 344 battery. 346 o Code complexity - personal computing endpoints support complex 347 code and often parallel and multithreaded execution of code. 349 6.3. Human Interface Devices 351 6.3.1. Endpoint description 353 Human interface transactions begin with a task-related goal for a 354 user. This leads to a user behavior (such as pointing, typing or 355 touching) which occurs in the current computing environment. The 356 user's action then should trigger an event in the current computing 357 environment. 359 Early computer science research breaks the taxonomy for Human 360 Interface Devices into four large categories: input devices, 361 pointing devices, indirect pointing and speech recognition. More 362 recent research adds neural interfaces, VR sensors, and human 363 attribute sensors. In all of these cases, the endpoints have the 364 goal of providing a mechanism for user navigation, interconnection, 365 form filling, menu interaction, data entry or sensing of human input 366 (although not to be confused with the following category in the 367 taxonomy). The result is that this category of the taxonomy has been 368 characterized by extremely limited computing capability in the past. 369 In contemporary networks the human interface devices are far more 370 complex and, as a result, subject to a wider collections of risks as 371 endpoints. 373 Since human interface devices are often the mechanism that provides 374 control of a computing resource, attacks on those devices are of 375 particular concern. In the past, the idea that there was an 376 external threat to a mouse or a pointing device would be ignored. In 377 contrast, today's voice actuated input devices and VR interfaces are 378 sophisticated enough to represent a real platform for attack. 380 6.3.2. Endpoint characteristics 382 o Cost - these endpoints are typically low in cost compared to 383 traditional computing equipment. They are often closer in cost to 384 simple peripheral equipment rather than endpoints that provide 385 general purpose computing platforms. 387 o Physical size - these devices are meant to provide a human 388 interface and are sized appropriately to that use case. Examples 389 include those devices that are small enough to be handheld or 390 worn. 392 o Network link characteristics - human interface devices are 393 connected in a variety of ways. Early devices were wired to the 394 device to which they provided connectivity. More recently, these 395 devices have a network connection between them and the connected 396 device. Examples of this connection use Bluetooth or other, very 397 local network connections. These devices may have connections to 398 wider networks to support applications such as augmented reality. 400 o User interface - generally these devices provide a user interface 401 rather than having a distinct user interface of their own. More 402 complex human interface devices have limited interfaces for 403 settings and control of the device, and its connectivity and 404 function. 406 o Processing power - these devices are characterized by having 407 limited processing power. 409 o Physical power - most human interface devices are characterized 410 by having limited power requirements. They are sometimes powered 411 by their connection to the device. In other cases, they are 412 powered by a battery. 414 o Code complexity - human interface devices tend to have either no 415 or very limited capabilities to execute code. Modern interface 416 devices which support presentation of a virtual physical 417 environment are capable of executing the code needed to provide 418 the interface between the presentation of visual (and other) 419 stimuli while responding to gestures and movement of the person 420 using the device. 422 6.4. Human Sensor Devices 424 Description 426 These are endpoints whose primary purpose is to sense, store, 427 transmit or process information about a human being. These 428 endpoints are characterized as having use cases in health and 429 wellness monitoring, human performance enhancement, personalized 430 medicine and human safety. 432 The endpoints are characterized as sensor devices with the capacity 433 to sense, store and report on data collected on an individual. The 434 sensor may be multimodal. These endpoints are almost always 435 characterized by have a battery for power and having limited 436 storage, networking and processing capabilities. 438 6.4.1. Endpoint characteristics 440 o Cost - Human Sensor Endpoints can range in cost from very low 441 (for instance a heartbeat sensor) to quite expensive (a sensor 442 built into an implanted device). 444 o Physical size - human sensors are very small and almost always 445 portable. 447 o Network link characteristics - human sensors usually have a 448 single network like technology available and are capable of very 449 limited bandwidth utilization on that link. 451 o User interface - human sensors have extremely limited, or no, 452 user interface. 454 o Processing power - human sensors are characterized by having 455 limited processing power - often incorporating only the ability 456 to collect store and forward sensed information. 458 o Physical power - human sensors are characterized by being powered 459 by internal batteries 461 o Code complexity - human sensors are not usually capable of 462 running complex code. Often, the capability of the endpoint is to 463 simply sense, store and forward data without reporting and 464 analysis of that data. 466 6.5. Non-human Sensor Devices 468 6.5.1. Endpoint Description 470 These endpoints are capable of sensing, storage, communication and 471 possibly some computation. They are characterized by having very low 472 bandwidth radios, a battery for power, sensor technology and a small 473 processor. Unlike in Section 5.4, these devices are not intended to 474 sense human-related information. 476 Compared with Human Sensors, non-human sensors often have a variety 477 of communications technologies available - for instance, self- 478 organizing into mesh networks. 480 6.5.2. Endpoint characteristics 482 o Cost - Non-human Sensor Endpoints can range in cost from very low 483 (for instance, a simple temperature sensor) to quite expensive (a 484 sensor built into an implanted device. 486 o Physical size - Non-human sensors are often small and almost 487 always portable. 489 o Network link characteristics - Non-human sensors usually have a 490 single network like technology available but the topology of 491 those network links can be highly varied. Quite often these 492 devices are capable of very limited bandwidth utilization on the 493 link to which they are attached. 495 o User interface - non-human sensors have extremely limited, or no, 496 user interface. 498 o Processing power - non-human sensors are characterized by having 499 limited processing power - often incorporating only the ability 500 to collect store and forward sensed information. Some non-human 501 sensors have the capability to process stored data, but usually 502 this is limited. 504 o Physical power - non-human sensors often require very limited 505 amounts of power - very often provided by a battery. 507 o Code complexity - non-human sensors are not usually capable of 508 running complex code. Often, the capability of the endpoint is to 509 simply sense, store and forward data without reporting and 510 analysis of that data. 512 6.6. Peripheral Computing Equipment and Embedded Endpoints 514 6.6.1. Endpoint Description 516 These are endpoints that are "embedded" in devices that may have a 517 different primary function. An example is a network endpoint in a 518 printer that supports remote access, configuration and printing. 519 Another example is an endpoint in an appliance that has a different 520 primary function (for instance, a refrigerator). 522 In either case, the endpoint is characterized as being added to 523 another system, machine or peripheral. 525 These devices are characterized as being specialized for their 526 particular use case and function. Their specific characteristics 527 often depend upon the system, device or peripheral in which they are 528 being hosted. As an example, the embedded endpoint gets its 529 physical power and networking capabilities from the device in which 530 it is connected. 532 6.6.2. Endpoint characteristics 534 o Cost - almost never available as a standalone device - instead, 535 always embedded into the peripheral or system which is hosting 536 it. 538 o Physical size - almost always very small - to be embedded into 539 some other system or device. 541 o Network link characteristics - dependent on network services 542 available from the host device and not always IP-based. 544 o User interface - almost always provided by the "hosting" device. 545 Many embedded endpoints share a user interface with the 546 configuration and control tool for the underlying device. 548 o Processing power - usually limited and constrained by the use 549 case. Some embedded endpoints provide remote access to the 550 underlying resources provided by the processor. 552 o Physical power - generally supplied by the "host" system or 553 device. 555 o Code complexity - limited and almost always constrained by use 556 case. 558 6.7. Application Layer Endpoints 560 6.7.1. Description 562 A significant trend in the contemporary public Internet is to have 563 applications act as completely independent agents - a situation 564 where the application itself provides the necessary infrastructure 565 (for instance, domain name resolution) to provide services. An 566 example would be a web browser that independently resolved domain 567 names and established secure communication channels independently. 569 The traffic between the application and the servers it uses might 570 not be available for analysis by security software. As a result, 571 application-based endpoints would have the characteristic of having 572 to provide security services (for instance, traffic security or 573 malware detection) for itself. 575 This type of endpoint also has the characteristic of potentially 576 having adverse impacts on other applications running on the same 577 platform. For example, if several applications are provisioning 578 their own infrastructure services, then those services are being 579 duplicated on that platform. For security related infrastructure 580 there would be no common, platform-wide approach to securing the 581 applications or the traffic generated between the application and 582 external servers. 584 6.7.2. Endpoint Characteristics 586 o Cost - applications vary widely in cost and some are free. 588 o Physical size - based on code, application endpoints do not have 589 physical characteristics (e.g. size, power requirements, etc.). 591 o Network link characteristics - applications often use network 592 facilities provided by lower layers of the stack. In particular, 593 many application endpoints use the network services provided by 594 the underlying operating system that acts as the host for the 595 application. An emerging trend in both wired and wireless 596 networks is for the application to interface with the network 597 link to control or provide some of the network link services for 598 itself. An example of this would be an application that does DNS 599 resolution services for itself rather then depending on the 600 underlying operating system to provide that service. 602 o User interface - the application usually provides its own user 603 interface which can be minimal (for instance, command line 604 driven) or complex (windows or VR driven). 606 o Processing power - always dependent on the device on which the 607 application is hosted. 609 o Physical power - based on code, application endpoints do not have 610 physical requirements (e.g. power) 612 o Code complexity - highly variable. Applications can be very 613 simple or highly complex depending on the application's 614 requirements. 616 6.8. Edge Network and Acquisition Endpoints 618 6.8.1. Description 620 The emergence of intelligent devices and things has led to new 621 network designs where data is aggregated at points topologically 622 close to where the data is gathered. The gathered data can then 623 have the option to flow to nearby gateways, or a Wi-Fi/W-LAN (SD- 624 WAN) router/equipment, or the telco tower/rooftop towers. These 625 often perform an acquisition function that includes both aggregation 626 and data condensation. 628 They usually have some level of processing capability. The main task 629 for these devices is to collect the data from various other 630 endpoints and send the processed data upstream. In doing so, they 631 often perform some low-level data processing, such as data filtering 632 (which determines what data is sent/blocked) and data analytics. 634 The acquisition systems are often architected to talk to distributed 635 data centers and end devices; for instance, on a factory shop floor, 636 a CDN's edge PoP (Point of Presence), an edge colocation local, or a 637 metro regional datacenter for a Telco or IT Service Provider. 639 In all cases, these edge computing devices represent a newer class 640 of endpoints. These are endpoints that are not at the extreme edge 641 of the network, but provide services to the devices at those edges 642 (especially for those devices in the class discussed in section 6.4 643 and 6.5 above). 645 The threats and mitigations for this class of device is expected to 646 be significantly different from those in sections 6.4 and 6.5. 648 6.8.2. Endpoint characteristics 650 o Cost - highly variable. Edge network devices in 5G networks can 651 be very expensive. Aggregation nodes in sensor networks can be 652 very inexpensive. 654 o Physical size - highly variable. Edge network devices in 5G 655 networks can be larger than personal computing equipment. 656 Aggregation nodes in sensor networks can be as small as a circuit 657 board, battery and radio. 659 o Network link characteristics - by their nature, these devices 660 have at least a pair of network links. One of these links faces 661 toward the network where the data is being aggregated. The other 662 faces toward the network where the data is being processed, 663 analyzed or reported upon. 665 o User interface - these devices usually have a limited user 666 interface, characterized by the need to configure the device, 667 provide security and allow for management of the network links. 669 o Processing power - usually these devices have limited processing 670 power: their emphasis is on aggregation and management of data 671 flows between networks. 673 o Physical power - highly variable. Edge network devices in 5G 674 networks can require significant sources of secure and consistent 675 power. Aggregation nodes in sensor networks can often be 676 supported by a small battery. 678 o Code complexity - usually these devices have limited ability to 679 load and execute code. Since their emphasis is on aggregation and 680 management of data flows between networks, these devices usually 681 have minimal ability to run general purpose code. 683 7. Security Considerations 685 This draft is non-normative and simply attempts to provide a 686 taxonomy for endpoints. The goal of the taxonomy is to document that 687 there are classes of endpoints that have different characteristics. 688 Those classes may have completely different threat landscapes and 689 the endpoints may have completely different security capabilities. 691 In support of the work on the EVOLVE draft [I-D:draft-mcfadden- 692 opsec-endp-evolve-00], this draft provides a taxonomy of endpoints 693 that is intended to provide a foundation for further work on the 694 EVOLVE draft and research on approaches to providing endpoint 695 security alternatives in a diverse group of settings. 697 8. IANA Considerations 699 This memo contains no instructions or requests for IANA. The authors 700 continue to appreciate the efforts of IANA staff in support of the 701 IETF. 703 9. References 705 9.1. Informative References 707 [I-D. draft-mcfadden-opsec-endp-evolve-00], McFadden, M., "Evolution 708 of Endpoint Security - An Operational Perspective", Internet Draft 709 (work in progress), February 2021 711 10. Acknowledgments 713 The original idea for this draft came from another, now expired 714 draft. The authors of that draft intended a comprehensive 715 discussion of endpoint security and a clear description of how the 716 evolution of the Internet made endpoint security - on its own - 717 insufficient. 719 The author thanks those previous contributors: Arnaud Taddei, Bret 720 Jordan, Candid Wueest, Chris Larsen, Andre Engel, Kevin Roundy, 721 Yugiong Sun, and David Wells. 723 The author also extends his appreciation to the discussions in the 724 IAB Activity called model-t where the future of the Internet's 725 threat landscape has also been discussed. 727 This document was prepared using 2-Word-v2.0.template.dot. 729 Appendix A. Document History 731 [[ To be removed from the final document ]] 733 -00 735 Initial Internet Draft 737 Authors' Addresses 739 Mark McFadden 740 Internet policy advisors ltd uk 741 6 Bridge Street 742 Chepstow, Wales NP16 5EY 743 United Kingdom 745 Phone: +44 2921 25 3649 746 Email: mark@internetpolicyadvisors.com