idnits 2.17.1 draft-behringer-anima-reference-model-02.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2015) is 3242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-addressing-00 == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-control-plane-02 == Outdated reference: A later version (-04) exists of draft-carpenter-anima-gdn-protocol-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational B. Carpenter 5 Expires: December 13, 2015 Univ. of Auckland 6 T. Eckert 7 Cisco 8 L. Ciavaglia 9 Alcatel Lucent 10 B. Liu 11 Huawei Technologies 12 June 11, 2015 14 A Reference Model for Autonomic Networking 15 draft-behringer-anima-reference-model-02 17 Abstract 19 This document describes a reference model for Autonomic Networking. 20 The goal is to define how the various elements in an autonomic 21 context work together, to describe their interfaces and relations. 22 While the document is written as generally as possible, the initial 23 solutions are limited to the chartered scope of the WG. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 13, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 62 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Unconstrained AN Nodes . . . . . . . . . . . . . . . . . 5 64 3.3. Constrained AN Nodes (*) . . . . . . . . . . . . . . . . 6 65 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 66 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 8 70 4.5. Intent Distribution . . . . . . . . . . . . . . . . . . . 8 71 4.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.7. The Autonomic Control Plane . . . . . . . . . . . . . . . 8 73 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 8 74 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 9 75 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 9 76 5.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 9 78 5.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 9 79 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 9 80 6.1. General Description of an ASA . . . . . . . . . . . . . . 10 81 6.2. Specific ASAs for the Enrolment Process . . . . . . . . . 10 82 6.2.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 10 83 6.2.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 10 84 6.2.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 10 85 7. Management and Programmability . . . . . . . . . . . . . . . 10 86 7.1. How an AN Network Is Managed . . . . . . . . . . . . . . 10 87 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 11 88 7.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 11 89 7.4. Feedback Loops to NOC(*) . . . . . . . . . . . . . . . . 11 90 7.5. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 11 91 7.6. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 11 92 8. Coordination Between Autonomic Functions (*) . . . . . . . . 11 93 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 11 94 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 12 95 9. Hybrid Approach with Non-Autonomic Functions (*) . . . . . . 13 96 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 97 10.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 13 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 100 13. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 104 1. Introduction 106 The document "Autonomic Networking - Definitions and Design Goals" 107 [I-D.irtf-nmrg-autonomic-network-definitions] explains the 108 fundamental concepts behind Autonomic Networking, and defines the 109 relevant terms in this space. In section 5 it describes a high level 110 reference model. This document defines this reference model with 111 more detail, to allow for functional and protocol specifications to 112 be developed in an architecturally consistent, non-overlapping 113 manner. While the document is written as generally as possible, the 114 initial solutions are limited to the chartered scope of the WG. 116 As discussed in [I-D.irtf-nmrg-autonomic-network-definitions], the 117 goal of this work is not to focus exclusively on fully autonomic 118 nodes or networks. In reality, most networks will run with some 119 autonomic functions, while the rest of the network is traditionally 120 managed. This reference model allows for this hybrid approach. 122 This is a living document and will evolve with the technical 123 solutions developed in the ANIMA WG. Sections marked with (*) do not 124 represent current charter items. While this document must give a 125 long term architectural view, not all functions will be standardized 126 at the same time. 128 2. The Network View 130 This section describes the various elements in a network with 131 autonomic functions, and how these entities work together, on a high 132 level. Subsequent sections explain the detailed inside view for each 133 of the autonomic network elements, as well as the network functions 134 (or interfaces) between those elements. 136 Figure 1 shows the high level view of an Autonomic Network. It 137 consists of a number of autonomic nodes, which interact directly with 138 each other. Those autonomic nodes provide a common set of 139 capabilities across the network, called the "Autonomic Networking 140 Infrastructure" (ANI). The ANI provides functions like naming, 141 addressing, negotiation, synchronization, discovery and messaging. 143 Autonomic functions typically span several, possibly all nodes in the 144 network. The atomic entities of an autonomic function are called the 145 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 147 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 148 : : Autonomic Function 1 : : 149 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 150 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 151 : : : 152 : +- - - - - - - - - - - - - - + : 153 : : Autonomic Function 2 : : 154 : : ASA 2 : ASA 2 : : 155 : +- - - - - - - - - - - - - - + : 156 : : : 157 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 158 : Autonomic Networking Infrastructure : 159 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 160 +--------+ : +--------+ : +--------+ : +--------+ 161 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 162 +--------+ : +--------+ : +--------+ : +--------+ 164 Figure 1: High level view of an Autonomic Network 166 In a horizontal view, autonomic functions span across the network, as 167 well as the Autonomic Networking Infrastructure. In a vertical view, 168 a node always implements the ANI, plus it may have one or several 169 Autonomic Service Agents. 171 The Autonomic Networking Infrastructure (ANI) therefore is the 172 foundation for autonomic functions. The current charter of the ANIMA 173 WG is to specify the ANI, using a few autonomic functions as use 174 cases. 176 3. The Autonomic Network Element 178 3.1. Architecture 180 This section describes an autonomic network element and its internal 181 architecture. The reference model explained in 182 [I-D.irtf-nmrg-autonomic-network-definitions] shows the sources of 183 information that an autonomic service agent can leverage: Self- 184 knowledge, network knowledge (through discovery), Intent, and 185 feedback loops. Fundamentally, there are two levels inside an 186 autonomic node: the level of Autonomic Service Agents, and the level 187 of the Autonomic Networking Infrastructure, with the former using the 188 services of the latter. Figure 2 illustrates this concept. 190 +------------------------------------------------------------+ 191 | | 192 | +-----------+ +------------+ +------------+ | 193 | | Autonomic | | Autonomic | | Autonomic | | 194 | | Service | | Service | | Service | | 195 | | Agent 1 | | Agent 2 | | Agent 3 | | 196 | +-----------+ +------------+ +------------+ | 197 | ^ ^ ^ | 198 | - - | - - API level - -| - - - - - - - |- - - | 199 | V V V | 200 |------------------------------------------------------------| 201 | Autonomic Networking Infrastructure | 202 | - Data structures (ex: certificates, peer information) | 203 | - Autonomic Control Plane | 204 | - discovery, negotiation and synchronisation functions | 205 | - Intent distribution | 206 | - aggregated reporting and feedback loops | 207 | - routing | 208 |------------------------------------------------------------| 209 | Basic Operating System Functions | 210 +------------------------------------------------------------+ 212 Figure 2: Model of an autonomic node 214 The Autonomic Networking Infrastructure (lower part of Figure 2) 215 contains node specific data structures, for example trust information 216 about itself and its peers, as well as a generic set of functions, 217 independent of a particular usage. This infrastructure should be 218 generic, and support a variety of Autonomic Service Agents (upper 219 part of Figure 2). The Autonomic Control Plane is the summary of all 220 interactions of the Autonomic Networking Infrastructure with other 221 nodes and services. 223 The use cases of "Autonomics" such as self-management, self- 224 optimisation, etc, are implemented as Autonomic Service Agents. They 225 use the services and data structures of the underlying autonomic 226 networking infrastructure. The underlying Autonomic Networking 227 Infrastructure should itself be self-managing. 229 The "Basic Operating System Functions" include the "normal OS", 230 including the network stack, security functions, etc. 232 3.2. Unconstrained AN Nodes 234 Unconstrained nodes have the full ANI, with the full functionality 235 (details to be worked out). They support all the capabilities 236 outlined in the rest of the document. [tbc] 238 3.3. Constrained AN Nodes (*) 240 Constrained nodes have a reduced ANI, with a well-defined minimal 241 functionality (details to be worked out): They do need to be able to 242 join the network, and communicate with at least a helper node which 243 has full ANI functionality. Capabilities of constrained nodes need 244 to be defined here. [tbc] 246 4. The Autonomic Networking Infrastructure 248 The Autonomic Networking Infrastructure provides a layer of common 249 functionality across an Autonomic Network. It comprises "must 250 implement" functions and services, as well as extensions. 252 An Autonomic Function, comprising of Autonomic Service Agents on 253 nodes, can rely on the fact that all nodes in the network implement 254 at least the "must implement" functions. 256 4.1. Naming 258 Inside a domain, each autonomic device needs a domain specific 259 identifier. [tbc] 261 4.2. Addressing 263 Autonomic Service Agents (ASAs) need addressing to communicate with 264 each other. This section describes the addressing approach of the 265 Autonomic Networking Infrastructure, used by ASAs. It does NOT 266 describe addressing approaches for the data plane of the network, 267 which may be configured and managed in the traditional way. ASAs may 268 provide a service to negotiate address space, or addressing 269 mechanisms for the date plane. One use case for such an autonomic 270 function is described in [I-D.jiang-auto-addr-management]. The 271 addressing the ASAs use is in scope for this section, the address 272 space they negotiate for the data plane is not. 274 It is generally desirable to make the addressing scheme of the 275 Autonomic Networking Infrastructure as self-managing (autonomic) as 276 possible. 278 This section is currently under discussion. We currently believe 279 that we should address the following questions: 281 o How addressing inside the Autonomic Control Plane (ACP) 282 [I-D.behringer-anima-autonomic-control-plane] is assigned and 283 managed autonomically. 285 o Whether, if there is no separated ACP, Autonomic Service Agents 286 (ASAs) shall have their own address space, or whether they should 287 use the address space configured by the administrator. 289 o How addressing is handled in the presence of non-autonomic nodes. 291 o Prefix assignment to interfaces. 293 o Whether links and link interfaces should get routable address 294 space, or whether link local addressing is sufficient. 296 o How the address space used in the Autonomic Networking 297 Infrastructure is assigned and managed. 299 It is not clear at this point whether a specific address scheme 300 should be included in this document, or whether this document should 301 only define the requirements. This is for further discussion. 303 The document [I-D.behringer-anima-autonomic-addressing] describes one 304 way to autonomically assign loopback addresses to autonomic nodes, in 305 an autonomic, self-managed way. Other ideas and suggestions are 306 strongly encouraged. 308 4.3. Discovery 310 Traditionally, most of the information a node requires is provided 311 through configuration or northbound interfaces. An autonomic 312 function should only minimally rely on such northbound interfaces, 313 therefore it needs to discover resources in the network. This 314 section describes various discovery functions in an autonomic 315 network. 317 Discovering nodes and their properties: A core function to establish 318 an autonomic domain is the discovery of autonomic nodes, primarily 319 adjacent nodes. This may either leverage existing neighbour 320 discovery mechanisms, or new mechanisms. 322 Discovering services: Network services such as AAA should also be 323 discovered and not configured. Service discovery is required for 324 such tasks. An autonomic network can either leverage existing 325 service discovery functions, or build a new approach. 327 Thus the discovery mechanism could either be fully integrated with 328 negotiation and synchronization (next section) or could use an 329 independent discovery mechanism such as DNS Service Discovery or 330 Service Location Protocol. This choice is made independently for 331 each Autonomic Service Agent. 333 4.4. Signaling Between Autonomic Nodes 335 Autonomic nodes must communicate with each other, for example to 336 negotiate and/or synchronize network parameters of any kind and 337 complexity. This requires some form of signaling between autonomic 338 nodes. The document "A Generic Discovery and Negotiation Protocol 339 for Autonomic Networking" [I-D.carpenter-anima-gdn-protocol] 340 describes requirements for negotiation and synchronization in an 341 autonomic network. It also defines a protocol, GDNP, for this 342 purpose, including an integrated but optional discovery protocol. 344 4.5. Intent Distribution 346 Intent is the policy language of an Autonomic Network, see 347 Section 7.2 for general information on Intent. The distribution of 348 Intent is also a function of the Autonomic Control Plane. Various 349 methods can be used to distribute Intent across an autonomic domain. 351 4.6. Routing 353 All autonomic nodes in a domain must be able to communicate with each 354 other, and with autonomic nodes outside their own domain. Therefore, 355 an Autonomic Control Plane relies on a routing function. For 356 Autonomic Networks to be interoperable, they must all support one 357 common routing protocol. 359 4.7. The Autonomic Control Plane 361 The totality of autonomic interactions forms the "Autonomic Control 362 Plane". This control plane can be either implemented in the global 363 routing table of a node, such as IGPs in today's networks; or it can 364 be provided as an overlay network, as described in 365 [I-D.behringer-anima-autonomic-control-plane]. 367 The ACP can be operated in two ways: 1) as a separate virtual overlay 368 network, as described in 369 [I-D.behringer-anima-autonomic-control-plane]. or 2), in the global 370 routing table. This sections discusses implications of both choices. 372 Also: Need to address how a separated ACP and an inline ACP 373 cooperate. 375 5. Security and Trust Infrastructure 377 An Autonomic Network is self-protecting. All protocols are secure by 378 default, without the requirement for the administrator to explicitly 379 configure security. 381 Autonomic nodes have direct interactions between themselves, which 382 must be secured. Since an autonomic network does not rely on 383 configuration, it is not an option to configure for example pre- 384 shared keys. A trust infrastructure such as a PKI infrastructure 385 must be in place. This section describes the principles of this 386 trust infrastructure. 388 A completely autonomic way to automatically and securely deploy such 389 a trust infrastructure is to set up a trust anchor for the domain, 390 and then use an approach as in the document "Bootstrapping Key 391 Infrastructures" [I-D.pritikin-bootstrapping-keyinfrastructures]. 393 5.1. Public Key Infrastructure 395 An autonomic domain uses a PKI model. The root of trust is a 396 certification authority (CA). A registrar acts as a registration 397 authority (RA). 399 A minimum implementation of an autonomic domain contains one CA, one 400 Registrar, and network elements. 402 5.2. Domain Certificate 404 We need to define how the fields in a domain certificate are to be 405 used. [tbc] 407 5.3. The MASA 409 Explain briefly the function, point to 410 [I-D.pritikin-bootstrapping-keyinfrastructures]. [tbc] 412 5.4. Sub-Domains (*) 414 Explain how sub-domains are handled. (tbc) 416 5.5. Cross-Domain Functionality (*) 418 Explain how trust is handled between different domains. (tbc) 420 6. Autonomic Service Agents (ASA) 422 This section describes how autonomic services run on top of the 423 Autonomic Networking Infrastructure. 425 6.1. General Description of an ASA 427 general concepts, such as sitting on top of the ANI, etc. Also needs 428 to explain that on a constrained node (see Section 3.3) not all ASAs 429 may run, so we have two classes of ASAs: Ones that run on an 430 unconstrained node, and limited function ASAs that run also on 431 constrained nodes. We expect unconstrained nodes to support all 432 ASAs. 434 6.2. Specific ASAs for the Enrolment Process 436 The following ASAs provide essential, required functionality in an 437 autonomic network, and are therefor mandatory to implement on 438 unconstrained autonomic nodes. 440 6.2.1. The Enrolment ASA 442 This section describes the function of an autonomic node to bootstrap 443 into the domain with the help of an enrolment proxy (see previous 444 section). [tbc] 446 6.2.2. The Enrolment Proxy ASA 448 This section describes the function of an autonomic node that helps a 449 non-enrolled, adjacent devices to enrol into the domain. [tbc] 451 6.2.3. The Registrar ASA 453 This section describes the registrar function in an autonomic 454 network. It explains the tasks of a registrar element, and how 455 registrars are placed in a network, redundancy between several, etc. 456 [tbc] 458 7. Management and Programmability 460 This section describes how an Autonomic Network is managed, and 461 programmed. 463 7.1. How an AN Network Is Managed 465 Explain co-existence of traditional methods (SNMP, syslog, NETCONF, 466 etc) with new, autonomic methods. Those are: Intent, Aggregated 467 Reporting and feedback loops to the NOC. [tbc] 469 7.2. Intent (*) 471 This section describes Intent, and how it is managed. Explaining 472 ingest of intent, distribution, the nature (on top of what's in 473 [I-D.irtf-nmrg-autonomic-network-definitions]). That intent is 474 signed, time stamps, etc. Probably pointing back to 475 [I-D.irtf-nmrg-autonomic-network-definitions]. (Note intent 476 distribution is handled in Section 4.5) [tbc] 478 7.3. Aggregated Reporting (*) 480 An autonomic network offers through the autonomic control plane the 481 possibility to aggregate information inside the network, before 482 sending it to the admin of the network. While this can be seen or 483 implemented as a specific form of negotiation, the use case is 484 different and therefore mentioned here explicitly. 486 7.4. Feedback Loops to NOC(*) 488 Feedback loops are required in an autonomic network to allow the 489 intervention of a human administrator or central control systems, 490 while maintaining a default behaviour. Through a feedback loop an 491 administrator can be prompted with a default action, and has the 492 possibility to acknowledge or override the proposed default action. 494 7.5. APIs (*) 496 Need considerations for APIs: How can ASAs use the ANI? Where do we 497 need APIs? [tbc] 499 7.6. Data Model (*) 501 Need considerations for a data model. What it should cover, scope. 502 [tbc] 504 8. Coordination Between Autonomic Functions (*) 506 8.1. The Coordination Problem (*) 508 Different autonomic functions may conflict in setting certain 509 parameters. For example, an energy efficiency function may want to 510 shut down a redundant link, while a load balancing function would not 511 want that to happen. The administrator must be able to understand 512 and resolve such interactions, to steer autonomic network performance 513 to a given (intended) operational point. 515 Several interaction types may exist among autonomic functions, for 516 example: 518 o Cooperation: An autonomic function can improve the behavior or 519 performance of another autonomic function, such as a traffic 520 forecasting function used by a traffic allocation function. 522 o Dependency: An autonomic function cannot work without another one 523 being present or accessible in the autonomic network. 525 o Conflict: A metric value conflict is a conflict where one metric 526 is influenced by parameters of different autonomic functions. A 527 parameter value conflict is a conflict where one parameter is 528 modified by different autonomic functions. 530 Solving the coordination problem beyond one-by-one cases can rapidly 531 become intractable for large networks. Specifying a common 532 functional block on coordination is a first step to address the 533 problem in a systemic way. The coordination life-cycle consists in 534 three states: 536 o At build-time, a "static interaction map" can be constructed on 537 the relationship of functions and attributes. This map can be 538 used to (pre-)define policies and priorities on identified 539 conflicts. 541 o At deploy-time, autonomic functions are not yet active/acting on 542 the network. A "dynamic interaction map" is created for each 543 instance of each autonomic functions and on a per resource basis, 544 including the actions performed and their relationships. This map 545 provides the basis to identify conflicts that will happen at run- 546 time, categorize them and plan for the appropriate coordination 547 strategies/mechanisms. 549 o At run-time, when conflicts happen, arbitration is driven by the 550 coordination strategies. Also new dependencies can be observed 551 and inferred, resulting in an update of the dynamic interaction 552 map and adaptation of the coordination strategies and mechanisms. 554 Multiple coordination strategies and mechanisms exists and can be 555 devised. The set ranges from basic approaches such as random process 556 or token-based process, to approaches based on time separation and 557 hierarchical optimization, to more complex approaches such as multi- 558 objective optimization, and other control theory approaches and 559 algorithms family. 561 8.2. A Coordination Functional Block (*) 563 A common coordination functional block is a desirable component of 564 the ANIMA reference model. It provides a means to ensure network 565 properties and predictable performance or behavior such as stability, 566 and convergence, in the presence of several interacting autonomic 567 functions. 569 A common coordination function requires: 571 o A common description of autonomic functions, their attributes and 572 life-cycle. 574 o A common representation of information and knowledge (e.g., 575 interaction maps). 577 o A common "control/command" interface between the coordination 578 "agent" and the autonomic functions. 580 Guidelines, recommendations or BCPs can also be provided for aspects 581 pertaining to the coordination strategies and mechanisms. 583 9. Hybrid Approach with Non-Autonomic Functions (*) 585 This section explains how autonomic functions can co-exist with non- 586 autonomic functions, and how a potential overlap is managed. This is 587 all about conflict resolution. Maybe we should re-name that section? 588 [I-D.irtf-nmrg-autonomic-network-definitions] already mentions this. 589 Maybe we don't need much more here. (tbc) 591 10. Security Considerations 593 10.1. Threat Analysis 595 This is a preliminary outline of a threat analysis, to be expanded 596 and made more specific as the various Autonomic Networking 597 specifications evolve. 599 Since AN will hand over responsibility for network configuration from 600 humans or centrally established management systems to fully 601 distributed devices, the threat environment is also fully 602 distributed. On the one hand, that means there is no single point of 603 failure to act as an attractive target for bad actors. On the other 604 hand, it means that potentially a single misbehaving autonomic device 605 could launch a widespread attack, by misusing the distributed AN 606 mechanisms. For example, a resource exhaustion attack could be 607 launched by a single device requesting large amounts of that resource 608 from all its peers, on behalf of a non-existent traffic load. 609 Alternatively it could simply send false information to its peers, 610 for example by announcing resource exhaustion when this was not the 611 case. If security properties are managed autonomically, a 612 misbehaving device could attempt a distributed attack by requesting 613 all its peers to reduce security protections in some way. In 614 general, since autonomic devices run without supervision, almost any 615 kind of undesirable management action could in theory be attempted by 616 a misbehaving device. 618 If it is possible for an unauthorised device to act as an autonomic 619 device, or for a malicious third party to inject messages appearing 620 to come from an autonomic device, all these same risks would apply. 622 If AN messages can be observed by a third party, they might reveal 623 valuable information about network configuration, security 624 precautions in use, individual users, and their traffic patterns. If 625 encrypted, AN messages might still reveal some information via 626 traffic analysis, but this would be quite limited (for example, this 627 would be highly unlikely to reveal any specific information about 628 user traffic). AN messages are liable to be exposed to third parties 629 on any unprotected Layer 2 link, and to insider attacks even on 630 protected Layer 2 links. 632 11. IANA Considerations 634 This document requests no action by IANA. 636 12. Acknowledgements 638 Many people have provided feedback and input to this document: Sheng 639 Jiang, Roberta Maglione, Jonathan Hansford. 641 13. Change log [RFC Editor: Please remove] 643 00: Initial version. 645 14. References 647 [I-D.behringer-anima-autonomic-addressing] 648 Behringer, M., "An Autonomic IPv6 Addressing Scheme", 649 draft-behringer-anima-autonomic-addressing-00 (work in 650 progress), April 2015. 652 [I-D.behringer-anima-autonomic-control-plane] 653 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 654 Autonomic Control Plane", draft-behringer-anima-autonomic- 655 control-plane-02 (work in progress), March 2015. 657 [I-D.carpenter-anima-gdn-protocol] 658 Carpenter, B. and B. Liu, "A Generic Discovery and 659 Negotiation Protocol for Autonomic Networking", draft- 660 carpenter-anima-gdn-protocol-03 (work in progress), April 661 2015. 663 [I-D.irtf-nmrg-autonomic-network-definitions] 664 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 665 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 666 Networking - Definitions and Design Goals", draft-irtf- 667 nmrg-autonomic-network-definitions-07 (work in progress), 668 March 2015. 670 [I-D.jiang-auto-addr-management] 671 Jiang, S., Carpenter, B., and Q. Qiong, "Autonomic 672 Networking Use Case for Auto Address Management", draft- 673 jiang-auto-addr-management-00 (work in progress), April 674 2014. 676 [I-D.pritikin-bootstrapping-keyinfrastructures] 677 Pritikin, M., Behringer, M., and S. Bjarnason, 678 "Bootstrapping Key Infrastructures", draft-pritikin- 679 bootstrapping-keyinfrastructures-01 (work in progress), 680 September 2014. 682 Authors' Addresses 684 Michael H. Behringer (editor) 685 Cisco 687 Email: mbehring@cisco.com 689 Brian Carpenter 690 Department of Computer Science 691 University of Auckland 692 PB 92019 693 Auckland 1142 694 New Zealand 696 Email: brian.e.carpenter@gmail.com 698 Toerless Eckert 699 Cisco 701 Email: eckert@cisco.com 702 Laurent Ciavaglia 703 Alcatel Lucent 704 Route de Villejust 705 Nozay 91620 706 France 708 Email: laurent.ciavaglia@alcatel-lucent.com 710 Bing Liu 711 Huawei Technologies 712 Q14, Huawei Campus 713 No.156 Beiqing Road 714 Hai-Dian District, Beijing 100095 715 P.R. China 717 Email: leo.liubing@huawei.com