idnits 2.17.1 draft-mcfadden-endpoint-classification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 2, 2020) is 1271 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 139, but not defined == Missing Reference: 'TECE' is mentioned on line 234, but not defined == Unused Reference: '1' is defined on line 678, but no explicit reference was found in the text == Unused Reference: 'I-D:draft-taddei-smart-cless-introduction' is defined on line 683, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission M McFadden 2 Internet Draft internet policy advisors ltd 3 Intended status: Informational November 2, 2020 4 Expires: May 2, 2021 6 Endpoint Security Classification 7 draft-mcfadden-endpoint-classification-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 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 May 2, 2021. 32 Copyright Notice 34 Copyright (c) 2020 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 48 It seems reasonable to suggest that, despite the huge variety of 49 types of endpoints on the Internet, there are categories of 50 similarity. These categories are important because categories of 51 endpoint devices may share particular advantages or limitations for 52 endpoint security. This draft attempts to suggest a classification of 53 endpoints as a foundation for further work on operational security. 54 The goal is to identify classes of endpoints with similar 55 characteristics. Those characteristics may lead to the discovery that 56 the devices in a particular category share similar characteristics 57 for endpoint security. 59 Table of Contents 61 1. Introduction...................................................3 62 2. Conventions used in this document..............................3 63 3. Problem Statement..............................................4 64 4. Simplified Endpoint Schematic..................................4 65 5. Taxonomy and Hierarchy.........................................5 66 6. Taxonomy.......................................................5 67 6.1. Traditional and Enterprise Computing Equipment [TECE].....6 68 6.1.1. Description..........................................6 69 6.1.2. Endpoint characteristics.............................6 70 6.2. Personal Computing Equipment..............................6 71 6.2.1. Description..........................................6 72 6.2.2. Endpoint characteristics.............................7 73 6.3. Human Interface Devices...................................8 74 6.3.1. Endpoint description.................................8 75 6.3.2. Endpoint characteristics.............................8 76 6.4. Human Sensor Devices......................................9 77 6.4.1. Endpoint characteristics............................10 78 6.5. Non-human Sensor Devices.................................10 79 6.5.1. Endpoint Description................................10 80 6.5.2. Endpoint characteristics............................10 81 6.6. Peripheral Computing Equipment and Embedded Endpoints....11 82 6.6.1. Endpoint Description................................11 83 6.6.2. Endpoint characteristics............................12 84 6.7. Application Layer Endpoints..............................12 85 6.7.1. Description.........................................12 86 6.7.2. Endpoint Characteristics............................13 87 6.8. Edge Network and Acquisition Endpoints...................13 88 6.8.1. Description.........................................13 89 6.8.2. Endpoint characteristics............................14 90 7. Security Considerations.......................................15 91 8. IANA Considerations...........................................15 92 9. References....................................................15 93 9.1. Normative References.....................................15 94 9.2. Informative References...................................15 95 10. Acknowledgments..............................................15 96 Appendix A. Document History.....................................16 98 1. Introduction 100 A document entitled "BCP 72 - A Problem Statement [I-D. draft- 101 mcfadden-smart-threat-changes-01] suggests that the Internet's threat 102 landscape has changed significantly since the publication of BCP 72. 103 One of those changes is the evolution of security at endpoints. From 104 an operational viewpoint, the end-to-end principle has previously 105 focused activity on endpoint security. 107 Operational experience has identified limitations of endpoint-only 108 security solutions. Significant changes in technology, economics and 109 protocol development have impacted the provision of endpoint 110 security. 112 There are an enormous variety of endpoints on the Internet. It seems 113 a daunting task to try to make generalizations about endpoint 114 security when there is such diversity in the types of devices 115 connected to the Internet. 117 However, it seems reasonable to suggest that, despite the huge 118 variety of types of endpoints, there are categories of similarity. 119 These categories are important because categories of endpoint devices 120 may share particular advantages or limitations for endpoint security. 122 This draft attempts to suggest a classification of endpoints as a 123 foundation for further work on operational security. The goal is to 124 identify 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. While a general-purpose taxonomy of Internet endpoints 128 might be useful in a variety of settings, it is not the intended goal 129 of this document. 131 In addition, this document does not attempt to assess and document 132 the endpoint security characteristics of each part of the taxonomy. 134 2. Conventions used in this document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 3. Problem Statement 142 User Equipment encompasses a very broad set of endpoints. It may be 143 useful to provide a set of categories - or, groups - of endpoints 144 that have similar properties. Endpoints in the same groups may share 145 security characteristics that are particular to that group. The 146 fundamental question is: can a classification of endpoint devices be 147 created that allows for grouping of endpoints that have similar 148 security characteristics? And: is such a grouping - along with 149 operational experience on the Internet - useful in guiding future 150 security protocol design? 152 If it is possible to answer each of those questions in the 153 affirmative, then operational experience and research can be done on 154 the security characteristics of each category and influence the 155 development of protocols that have the greatest impact for those type 156 of devices. 158 4. Simplified Endpoint Schematic 160 A simplified representation of an endpoint is possible by making the 161 following generalization: 163 +------------------------------------------------+ 164 | | 165 | Application | 166 | | 167 |------------------------------------------------| 168 | | 169 | OS / Execution Environment | 170 | | 171 |------------------------------------------------| 172 | | 173 | Hardware | 174 | | 175 +------------------------------------------------+ 177 Figure 1 Endpoint Generalization 179 This simplification means that there are many combinations of 180 hardware, operating systems, execution environments and applications. 181 It also means that any of these three layers can be an endpoint for 182 the purposes of a discussion of endpoint security. 184 It is natural to suggest that we consider endpoints including those 185 which have a variety of power, computational, storage and network 186 capacities. It is possible that grouping devices with similar 187 characteristics will help in identifying categories of devices that 188 share similar endpoint security characteristics. 190 5. Taxonomy and Hierarchy 192 One suggestion for the taxonomy for endpoints is to consider a 193 hierarchy of endpoints that collects similar endpoint types in large 194 categories and then distinguishes between them in "sub-groups" or 195 lower levels of the taxonomy. 197 These groupings may provide a way to categorize threats and 198 mitigations to large classes of endpoints on the Internet while 199 providing the ability for differentiation. An example might be a 200 class of endpoints characterized as "constrained devices." 202 As an example, "constrained devices" might be further subdivided into 203 sub-classes such as sensors, embedded processors, specific (or, 204 special) purpose single-use processors, mesh gateways, and so forth. 205 It can even be imagined that the second level of the hierarchy could 206 be further subdivided by further distinguishing the endpoint types. 208 The current version of the draft does not take this approach. One of 209 the goals of the endpoint taxonomy is to provide enough 210 differentiation and specificity to ensure that a later operational 211 experience and research can successfully discuss common threats and 212 mitigations for each of the categories in the taxonomy. By providing 213 a ever greater hierarchy of endpoint types, it becomes difficult to 214 scale a future document that discusses threats and mitigations to the 215 highly specific endpoint types. 217 6. Taxonomy 219 Others have attempted to provide general-purpose taxonomy and device 220 classification guides. In some settings automated detection and 221 classification of devices provides an essential step in providing 222 appropriate access control and security services. 224 General-purpose classification systems tend to ossify or become 225 enormously complex. Classification has come from commercial entities, 226 computer science organizations, the academic community and even 227 regional collections of cooperating national governments. 229 Because of this, we limit the discussion to a taxonomy for endpoints 230 only. We divide endpoints into eight different classes and then 231 attempt to carefully describe the characteristics of devices in each 232 class. 234 6.1. Traditional and Enterprise Computing Equipment [TECE] 236 6.1.1. Description 238 Traditional and Enterprise Computing Equipment is characterized by 239 its extremely high-capacity for transactional volume, storage and 240 shared user population. TECE forms the backbone of high-volume, high- 241 availability transactional computing and is provided in both physical 242 and virtualized forms. 244 Traditional computing endpoints are shared computing environments 245 characterized by centralized, shared computing. These endpoints are 246 often in large scale data centers. These endpoints are capable of 247 high-availability, substantial requirements for power and 248 environmental control. These endpoints are also characterized by very 249 complex operating systems and user environments. 251 6.1.2. Endpoint characteristics 253 o Cost - these endpoints are characterized by extremely high cost. 255 o Physical size - these are very large endpoints, not suitable or 256 intended for use by an individual. 258 o Network link characteristics - capable of supporting extremely 259 high bandwidth. 261 o User interface - very complex and shared among multiple 262 individuals. 264 o Processing power - extremely high processing capability. 266 o Physical power - requires substantial provision of electrical 267 power and environmental controls. 269 o Code complexity - Extremely high support for very complex code 270 including parallelism, multitasking and multithreaded execution. 272 6.2. Personal Computing Equipment 274 6.2.1. Description 276 These are endpoints designed or intended to be used by an individual. 277 They can be delivered as fixed, portable or virtual instantiations of 278 the endpoint. It should be noted that virtual instantiations of 279 endpoints introduce complexities in defining the characteristics of 280 the endpoints. In each case, the device supports a mechanism for 281 human-interface and has the capability for both local storage and 282 processing. The personal computing equipment class is also 283 characterized by relatively low cost and power requirements. 285 This class of endpoint is also characterized by the devices 286 supporting multiple purpose use. This class is divided into two sub- 287 classes: fixed and mobile endpoints. The mobile subclass is further 288 divided into four other subclasses: laptops, tablets, intelligent 289 phones, and ultraportable personal computing equipment. 291 Personal computing endpoints usually have at least one, and often 292 many, network links - often supporting a variety of network 293 connectivity technologies. These endpoints are also characterized by 294 having a human interface - either integral to the computing device 295 itself or supplied externally to the computing device. 297 6.2.2. Endpoint characteristics 299 o Cost - these endpoints have a huge range of costs, from extremely 300 inexpensive for simple "personal computer on a board" endpoints to 301 moderately expensive for specially configured laptop and fixed 302 devices. 304 o Physical size - the physical size of these devices range from 305 handheld to a small cabinet for fixed, desktop units. 307 o Network link characteristics - personal computing endpoints are 308 often characterized by supporting multiple connectivity 309 technologies. 311 o User interface - personal computing endpoints are characterized by 312 having user interfaces designed for an individual. The interface 313 varies from simple, text-based interaction to gesture, touch and 314 voice control. 316 o Processing power - these endpoints are characterized by a 317 significant range of processing power: from single CPU units to 318 endpoints that can support multiple concurrent processes. 320 o Physical power - personal computing endpoints are characterized by 321 using either traditional mains power or power supplied by a 322 battery. 324 o Code complexity - personal computing endpoints support complex 325 code and often parallel and multithreaded execution of code. 327 6.3. Human Interface Devices 329 6.3.1. Endpoint description 331 Human interface transactions begin with a task-related goal for a 332 user. This leads to a user behavior (such as pointing, typing or 333 touching) which occurs in the current computing environment. The 334 user's action then should trigger an event in the current computing 335 environment. 337 Early computer science research breaks the taxonomy for Human 338 Interface Devices into four large categories: input devices, pointing 339 devices, indirect pointing and speech recognition. More recent 340 research adds neural interfaces, VR sensors, and human attribute 341 sensors. In all of these cases, the endpoints have the goal of 342 providing a mechanism for user navigation, interconnection, form 343 filling, menu interaction, data entry or sensing of human input 344 (although not to be confused with the following category in the 345 taxonomy). The result is that this category of the taxonomy has been 346 characterized by extremely limited computing capability in the past. 347 In contemporary networks the human interface devices are far more 348 complex and, as a result, subject to a wider collections of risks as 349 endpoints. 351 Since human interface devices are often the mechanism that provides 352 control of a computing resource, attacks on those devices are of 353 particular concern. In the past, the idea that there was an external 354 threat to a mouse or a pointing device would be ignored. In contrast, 355 today's voice actuated input devices and VR interfaces are 356 sophisticated enough to represent a real platform for attack. 358 6.3.2. Endpoint characteristics 360 o Cost - these endpoints are typically low in cost compared to 361 traditional computing equipment. They are often closer in cost to 362 simple peripheral equipment rather than endpoints that provide 363 general purpose computing platforms. 365 o Physical size - these devices are meant to provide a human 366 interface and are sized appropriately to that use case. Examples 367 include those devices that are small enough to be handheld or 368 worn. 370 o Network link characteristics - human interface devices are 371 connected in a variety of ways. Early devices were wired to the 372 device to which they provided connectivity. More recently, these 373 devices have a network connection between them and the connected 374 device. Examples of this connection use Bluetooth or other, very 375 local network connections. These devices may have connections to 376 wider networks to support applications such as augmented reality. 378 o User interface - generally these devices provide a user interface 379 rather than having a distinct user interface of their own. More 380 complex human interface devices have limited interfaces for 381 settings and control of the device, and its connectivity and 382 function. 384 o Processing power - these devices are characterized by having 385 limited processing power. 387 o Physical power - most human interface devices are characterized by 388 having limited power requirements. They are sometimes powered by 389 their connection to the device. In other cases, they are powered 390 by a battery. 392 o Code complexity - human interface devices tend to have either no 393 or very limited capabilities to execute code. Modern interface 394 devices which support presentation of a virtual physical 395 environment are capable of executing the code needed to provide 396 the interface between the presentation of visual (and other) 397 stimuli while responding to gestures and movement of the person 398 using the device. 400 6.4. Human Sensor Devices 402 Description 404 These are endpoints whose primary purpose is to sense, store, 405 transmit or process information about a human being. These endpoints 406 are characterized as having use cases in health and wellness 407 monitoring, human performance enhancement, personalized medicine and 408 human safety. 410 The endpoints are characterized as sensor devices with the capacity 411 to sense, store and report on data collected on an individual. The 412 sensor may be multimodal. These endpoints are almost always 413 characterized by have a battery for power and having limited storage, 414 networking and processing capabilities. 416 6.4.1. Endpoint characteristics 418 o Cost - Human Sensor Endpoints can range in cost from very low (for 419 instance a heartbeat sensor) to quite expensive (a sensor built 420 into an implanted device). 422 o Physical size - human sensors are very small and almost always 423 portable. 425 o Network link characteristics - human sensors usually have a single 426 network like technology available and are capable of very limited 427 bandwidth utilization on that link. 429 o User interface - human sensors have extremely limited, or no, user 430 interface. 432 o Processing power - human sensors are characterized by having 433 limited processing power - often incorporating only the ability to 434 collect store and forward sensed information. 436 o Physical power - human sensors are characterized by being powered 437 by internal batteries 439 o Code complexity - human sensors are not usually capable of running 440 complex code. Often, the capability of the endpoint is to simply 441 sense, store and forward data without reporting and analysis of 442 that data. 444 6.5. Non-human Sensor Devices 446 6.5.1. Endpoint Description 448 These endpoints are capable of sensing, storage, communication and 449 possibly some computation. They are characterized by having very low 450 bandwidth radios, a battery for power, sensor technology and a small 451 processor. Unlike in Section 5.4, these devices are not intended to 452 sense human-related information. 454 Compared with Human Sensors, non-human sensors often have a variety 455 of communications technologies available - for instance, self- 456 organizing into mesh networks. 458 6.5.2. Endpoint characteristics 460 o Cost - Non-human Sensor Endpoints can range in cost from very low 461 (for instance, a simple temperature sensor) to quite expensive (a 462 sensor built into an implanted device. 464 o Physical size - Non-human sensors are often small and almost 465 always portable. 467 o Network link characteristics - Non-human sensors usually have a 468 single network like technology available but the topology of those 469 network links can be highly varied. Quite often these devices are 470 capable of very limited bandwidth utilization on the link to which 471 they are attached. 473 o User interface - non-human sensors have extremely limited, or no, 474 user interface. 476 o Processing power - non-human sensors are characterized by having 477 limited processing power - often incorporating only the ability to 478 collect store and forward sensed information. Some non-human 479 sensors have the capability to process stored data, but usually 480 this is limited. 482 o Physical power - non-human sensors often require very limited 483 amounts of power - very often provided by a battery. 485 o Code complexity - non-human sensors are not usually capable of 486 running complex code. Often, the capability of the endpoint is to 487 simply sense, store and forward data without reporting and 488 analysis of that data. 490 6.6. Peripheral Computing Equipment and Embedded Endpoints 492 6.6.1. Endpoint Description 494 These are endpoints that are "embedded" in devices that may have a 495 different primary function. An example is a network endpoint in a 496 printer that supports remote access, configuration and printing. 497 Another example is an endpoint in an appliance that has a different 498 primary function (for instance, a refrigerator). 500 In either case, the endpoint is characterized as being added to 501 another system, machine or peripheral. 503 These devices are characterized as being specialized for their 504 particular use case and function. Their specific characteristics 505 often depend upon the system, device or peripheral in which they are 506 being hosted. As an example, the embedded endpoint gets its physical 507 power and networking capabilities from the device in which it is 508 connected. 510 6.6.2. Endpoint characteristics 512 o Cost - almost never available as a standalone device - instead, 513 always embedded into the peripheral or system which is hosting it. 515 o Physical size - almost always very small - to be embedded into 516 some other system or device. 518 o Network link characteristics - dependent on network services 519 available from the host device and not always IP-based. 521 o User interface - almost always provided by the "hosting" device. 522 Many embedded endpoints share a user interface with the 523 configuration and control tool for the underlying device. 525 o Processing power - usually limited and constrained by the use 526 case. Some embedded endpoints provide remote access to the 527 underlying resources provided by the processor. 529 o Physical power - generally supplied by the "host" system or 530 device. 532 o Code complexity - limited and almost always constrained by use 533 case. 535 6.7. Application Layer Endpoints 537 6.7.1. Description 539 A significant trend in the contemporary public Internet is to have 540 applications act as completely independent agents - a situation where 541 the application itself provides the necessary infrastructure (for 542 instance, domain name resolution) to provide services. An example 543 would be a web browser that independently resolved domain names and 544 established secure communication channels independently. 546 The traffic between the application and the servers it uses might not 547 be available for analysis by security software. As a result, 548 application-based endpoints would have the characteristic of having 549 to provide security services (for instance, traffic security or 550 malware detection) for itself. 552 This type of endpoint also has the characteristic of potentially 553 having adverse impacts on other applications running on the same 554 platform. For example, if several applications are provisioning their 555 own infrastructure services, then those services are being duplicated 556 on that platform. For security related infrastructure there would be 557 no common, platform-wide approach to securing the applications or the 558 traffic generated between the application and external servers. 560 6.7.2. Endpoint Characteristics 562 o Cost - applications vary widely in cost and some are free. 564 o Physical size - based on code, application endpoints do not have 565 physical characteristics (e.g. size, power requirements, etc.). 567 o Network link characteristics - applications often use network 568 facilities provided by lower layers of the stack. In particular, 569 many application endpoints use the network services provided by 570 the underlying operating system that acts as the host for the 571 application. An emerging trend in both wired and wireless networks 572 is for the application to interface with the network link to 573 control or provide some of the network link services for itself. 574 An example of this would be an application that does DNS 575 resolution services for itself rather then depending on the 576 underlying operating system to provide that service. 578 o User interface - the application usually provides its own user 579 interface which can be minimal (for instance, command line driven) 580 or complex (windows or VR driven). 582 o Processing power - always dependent on the device on which the 583 application is hosted. 585 o Physical power - based on code, application endpoints do not have 586 physical requirements (e.g. power) 588 o Code complexity - highly variable. Applications can be very simple 589 or highly complex depending on the application's requirements. 591 6.8. Edge Network and Acquisition Endpoints 593 6.8.1. Description 595 The emergence of intelligent devices and things has led to new 596 network designs where data is aggregated at points topologically 597 close to where the data is gathered. The gathered data can then have 598 the option to flow to nearby gateways, or a Wi-Fi/W-LAN (SD-WAN) 599 router/equipment, or the telco tower/rooftop towers. These often 600 perform an acquisition function that includes both aggregation and 601 data condensation. 603 They usually have some level of processing capability. The main task 604 for these devices is to collect the data from various other endpoints 605 and send the processed data upstream. In doing so, they often perform 606 some low-level data processing, such as data filtering (which 607 determines what data is sent/blocked) and data analytics. 609 The acquisition systems are often architected to talk to distributed 610 data centers and end devices; for instance, on a factory shop floor, 611 a CDN's edge PoP (Point of Presence), an edge colocation local, or a 612 metro regional datacenter for a Telco or IT Service Provider. 614 In all cases, these edge computing devices represent a newer class of 615 endpoints. These are endpoints that are not at the extreme edge of 616 the network, but provide services to the devices at those edges 617 (especially for those devices in the class discussed in section 6.4 618 and 6.5 above). 620 The threats and mitigations for this class of device is expected to 621 be significantly different from those in sections 6.4 and 6.5. 623 6.8.2. Endpoint characteristics 625 o Cost - highly variable. Edge network devices in 5G networks can be 626 very expensive. Aggregation nodes in sensor networks can be very 627 inexpensive. 629 o Physical size - highly variable. Edge network devices in 5G 630 networks can be larger than personal computing equipment. 631 Aggregation nodes in sensor networks can be as small as a circuit 632 board, battery and radio. 634 o Network link characteristics - by their nature, these devices have 635 at least a pair of network links. One of these links faces toward 636 the network where the data is being aggregated. The other faces 637 toward the network where the data is being processed, analyzed or 638 reported upon. 640 o User interface - these devices usually have a limited user 641 interface, characterized by the need to configure the device, 642 provide security and allow for management of the network links. 644 o Processing power - usually these devices have limited processing 645 power: their emphasis is on aggregation and management of data 646 flows between networks. 648 o Physical power - highly variable. Edge network devices in 5G 649 networks can require significant sources of secure and consistent 650 power. Aggregation nodes in sensor networks can often be supported 651 by a small battery. 653 o Code complexity - usually these devices have limited ability to 654 load and execute code. Since their emphasis is on aggregation and 655 management of data flows between networks, these devices usually 656 have minimal ability to run general purpose code. 658 7. Security Considerations 660 This draft is non-normative and simply attempts to provide a taxonomy 661 for endpoints. The goal of the taxonomy is to document that there are 662 classes of endpoints that have different characteristics. Those 663 classes may have completely different threat landscapes and the 664 endpoints may have completely different security capabilities. 666 This document is intended to support further work in that combines 667 operational security experience with guidance for security protocol 668 design. 670 8. IANA Considerations 672 This document has no requirements or actions for IANA. 674 9. References 676 9.1. Normative References 678 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 679 Levels", BCP 14, RFC 2119, March 1997. 681 9.2. Informative References 683 [I-D:draft-taddei-smart-cless-introduction] Taddei, A., Wueest, C., 684 Roundy, K., Lazanski, D., "Capabilities and Limitations of an 685 Endpoint-only Security Solution," https://tools.ietf.org/html/draft- 686 taddei-smart-cless-introduction-01, March 2020. 688 10. Acknowledgments 690 This document was prepared using 2-Word-v2.0.template.dot. 692 Appendix A. Document History 694 -00 696 Initial Internet Draft 698 Authors' Addresses 700 Mark McFadden 701 Internet policy advisors ltd 702 Chepstow Wales UK 704 Email: mark@internetpolicyadvisors.com