idnits 2.17.1 draft-ietf-anima-reference-model-10.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 date (November 23, 2018) is 1981 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-17 == Outdated reference: A later version (-09) exists of draft-carpenter-anima-asa-guidelines-05 == Outdated reference: A later version (-10) exists of draft-ietf-anima-grasp-api-02 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-09 Summary: 0 errors (**), 0 flaws (~~), 6 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 4 Intended status: Informational B. Carpenter 5 Expires: May 27, 2019 Univ. of Auckland 6 T. Eckert 7 Futurewei Technologies Inc. 8 L. Ciavaglia 9 Nokia 10 J. Nobre 11 University of Vale do Rio dos Sinos 12 November 23, 2018 14 A Reference Model for Autonomic Networking 15 draft-ietf-anima-reference-model-10 17 Abstract 19 This document describes a reference model for Autonomic Networking 20 for managed networks. It defines the behaviour of an autonomic node, 21 how the various elements in an autonomic context work together, and 22 how autonomic services can use the infrastructure. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 27, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 4 60 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 5 61 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. The Adjacency Table . . . . . . . . . . . . . . . . . . . 6 63 3.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 8 64 3.3.1. State 1: Factory Default . . . . . . . . . . . . . . 8 65 3.3.2. State 2: Enrolled . . . . . . . . . . . . . . . . . . 9 66 3.3.3. State 3: In ACP . . . . . . . . . . . . . . . . . . . 9 67 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 10 68 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 12 72 4.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.6. The Autonomic Control Plane . . . . . . . . . . . . . . . 13 74 4.7. Information Distribution (*) . . . . . . . . . . . . . . 13 75 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 14 76 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 14 77 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 14 78 5.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 15 79 5.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 15 80 5.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 15 81 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 15 82 6.1. General Description of an ASA . . . . . . . . . . . . . . 15 83 6.2. ASA Life-Cycle Management . . . . . . . . . . . . . . . . 17 84 6.3. Specific ASAs for the Autonomic Network Infrastructure . 18 85 6.3.1. The enrollment ASAs . . . . . . . . . . . . . . . . . 18 86 6.3.2. The ACP ASA . . . . . . . . . . . . . . . . . . . . . 19 87 6.3.3. The Information Distribution ASA (*) . . . . . . . . 19 88 7. Management and Programmability . . . . . . . . . . . . . . . 19 89 7.1. Managing a (Partially) Autonomic Network . . . . . . . . 19 90 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 20 91 7.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 21 92 7.4. Feedback Loops to NOC (*) . . . . . . . . . . . . . . . . 21 93 7.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 22 94 7.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 22 95 7.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 23 96 8. Coordination Between Autonomic Functions (*) . . . . . . . . 24 97 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 24 98 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 25 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 9.1. Protection Against Outsider Attacks . . . . . . . . . . . 26 101 9.2. Risk of Insider Attacks . . . . . . . . . . . . . . . . . 27 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 104 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 107 13.2. Informative References . . . . . . . . . . . . . . . . . 28 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 110 1. Introduction 112 The document "Autonomic Networking - Definitions and Design Goals" 113 [RFC7575] explains the fundamental concepts behind Autonomic 114 Networking, and defines the relevant terms in this space, as well as 115 a high level reference model. [RFC7576] provides a gap analysis 116 between traditional and autonomic approaches. 118 This document defines this reference model with more detail, to allow 119 for functional and protocol specifications to be developed in an 120 architecturally consistent, non-overlapping manner. 122 As discussed in [RFC7575], the goal of this work is not to focus 123 exclusively on fully autonomic nodes or networks. In reality, most 124 networks will run with some autonomic functions, while the rest of 125 the network is traditionally managed. This reference model allows 126 for this hybrid approach. 128 For example, it is possible in an existing, non-autonomic network to 129 enrol devices in a traditional way, to bring up a trust 130 infrastructure with certificates. This trust infrastructure could 131 then be used to automatically bring up an Autonomic Control Plane 132 (ACP), and run traditional network operations over the secure and 133 self-healing ACP. See [I-D.ietf-anima-stable-connectivity] for a 134 description of this use case. 136 The scope of this model is therefore limited to networks that are to 137 some extent managed by skilled human operators, loosely referred to 138 as "professionally managed" networks. Unmanaged networks raise 139 additional security and trust issues that this model does not cover. 141 This document describes a first, simple, implementable phase of an 142 Autonomic Networking solution. It is expected that the experience 143 from this phase will be used in defining updated and extended 144 specifications over time. Some topics are considered architecturally 145 in this document, but are not yet reflected in the implementation 146 specifications. They are marked with an (*). 148 2. The Network View 150 This section describes the various elements in a network with 151 autonomic functions, and how these entities work together, on a high 152 level. Subsequent sections explain the detailed inside view for each 153 of the autonomic network elements, as well as the network functions 154 (or interfaces) between those elements. 156 Figure 1 shows the high level view of an Autonomic Network. It 157 consists of a number of autonomic nodes, which interact directly with 158 each other. Those autonomic nodes provide a common set of 159 capabilities across the network, called the "Autonomic Networking 160 Infrastructure" (ANI). The ANI provides functions like naming, 161 addressing, negotiation, synchronization, discovery and messaging. 163 Autonomic functions typically span several, possibly all nodes in the 164 network. The atomic entities of an autonomic function are called the 165 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 167 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 168 : : Autonomic Function 1 : : 169 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 170 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 171 : : : 172 : +- - - - - - - - - - - - - - + : 173 : : Autonomic Function 2 : : 174 : : ASA 2 : ASA 2 : : 175 : +- - - - - - - - - - - - - - + : 176 : : : 177 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 178 : Autonomic Networking Infrastructure : 179 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 180 +--------+ : +--------+ : +--------+ : +--------+ 181 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 182 +--------+ : +--------+ : +--------+ : +--------+ 184 Figure 1: High level view of an Autonomic Network 186 In a horizontal view, autonomic functions span across the network, as 187 well as the Autonomic Networking Infrastructure. In a vertical view, 188 a node always implements the ANI, plus it may have one or several 189 Autonomic Service Agents. ASAs may be standalone, or use other ASAs 190 in a hierarchical way. 192 The Autonomic Networking Infrastructure (ANI) therefore is the 193 foundation for autonomic functions. 195 3. The Autonomic Network Element 197 This section explains the general architecture of an Autonomic 198 Network Element (Section 3.1), how it tracks its surrounding 199 environment in an Adjacency Table (Section 3.2), and the state 200 machine which defines the behaviour of the network element 201 (Section 3.3), based on that adjacency table. 203 3.1. Architecture 205 This section describes an autonomic network element and its internal 206 architecture. The reference model explained in the document 207 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 208 the sources of information that an autonomic service agent can 209 leverage: Self-knowledge, network knowledge (through discovery), 210 Intent (see Section 7.2), and feedback loops. There are two levels 211 inside an autonomic node: the level of Autonomic Service Agents, and 212 the level of the Autonomic Networking Infrastructure, with the former 213 using the services of the latter. Figure 2 illustrates this concept. 215 +------------------------------------------------------------+ 216 | | 217 | +-----------+ +------------+ +------------+ | 218 | | Autonomic | | Autonomic | | Autonomic | | 219 | | Service | | Service | | Service | | 220 | | Agent 1 | | Agent 2 | | Agent 3 | | 221 | +-----------+ +------------+ +------------+ | 222 | ^ ^ ^ | 223 | - - | - - API level - -| - - - - - - - |- - - | 224 | V V V | 225 |------------------------------------------------------------| 226 | Autonomic Networking Infrastructure | 227 | - Data structures (ex: certificates, peer information) | 228 | - Generalized Autonomic Control Plane (GACP) | 229 | - Autonomic Node Addressing and naming | 230 | - Discovery, negotiation and synchronisation functions | 231 | - Distribution of Intent and other information | 232 | - Aggregated reporting and feedback loops | 233 | - Routing | 234 |------------------------------------------------------------| 235 | Basic Operating System Functions | 236 +------------------------------------------------------------+ 238 Figure 2: Model of an autonomic node 240 The Autonomic Networking Infrastructure (lower part of Figure 2) 241 contains node specific data structures, for example trust information 242 about itself and its peers, as well as a generic set of functions, 243 independent of a particular usage. This infrastructure should be 244 generic, and support a variety of Autonomic Service Agents (upper 245 part of Figure 2). It contains addressing and naming of autonomic 246 nodes, discovery, negotiation and synchronisation functions, 247 distribution of information, reporting and feedback loops, as well as 248 routing inside the Autonomic Control Plane. 250 The Generalized Autonomic Control Plane (GACP) is the summary of all 251 interactions of the Autonomic Networking Infrastructure with other 252 nodes and services. A specific implementation of the GACP is 253 referred to here as the Autonomic Control Plane (ACP), and described 254 in [I-D.ietf-anima-autonomic-control-plane]. 256 The use cases of "Autonomics" such as self-management, self- 257 optimisation, etc, are implemented as Autonomic Service Agents. They 258 use the services and data structures of the underlying Autonomic 259 Networking Infrastructure, which should be self-managing. 261 The "Basic Operating System Functions" include the "normal OS", 262 including the network stack, security functions, etc. 264 Full AN nodes have the full Autonomic Networking Infrastructure, with 265 the full functionality described in this document. At a later stage 266 ANIMA may define a scope for constrained nodes with a reduced ANI and 267 well-defined minimal functionality. They are currently out of scope. 269 3.2. The Adjacency Table 271 Autonomic Networking is based on direct interactions between devices 272 of a domain. The Autonomic Control Plane (ACP) is normally 273 constructed on a hop-by-hop basis. Therefore, many interactions in 274 the ANI are based on the ANI adjacency table. There are interactions 275 that provide input into the adjacency table, and other interactions 276 that leverage the information contained in it. 278 The ANI adjacency table contains information about adjacent autonomic 279 nodes, at a minimum: node-ID, IP address in data plane, IP address in 280 ACP, domain, certificate. An autonomic node maintains this adjacency 281 table up to date. The adjacency table only contains information 282 about other nodes that are capable of Autonomic Networking; non- 283 autonomic nodes are normally not tracked here. However, the 284 information is tracked independently of the status of the peer nodes; 285 specifically, it contains information about non-enrolled nodes, nodes 286 of the same and other domains. The adjacency table may contain 287 information about the validity and trust level of the adjacent 288 autonomic nodes. 290 The adjacency table is fed by the following inputs: 292 o Link local discovery: This interaction happens in the data plane, 293 using IPv6 link local addressing only, because this addressing 294 type is itself autonomic. This way the nodes learns about all 295 autonomic nodes around itself. The related standards track 296 documents ([I-D.ietf-anima-grasp], 297 [I-D.ietf-anima-bootstrapping-keyinfra], 298 [I-D.ietf-anima-autonomic-control-plane]) describe in detail how 299 link local discovery is used. 301 o Vendor re-direct: A new device may receive information on where 302 its home network is through a vendor based Manufacturer Authorized 303 Signing Authority (MASA, see Section 5.3) re-direct; this is 304 typically a routable address. 306 o Non-autonomic input: A node may be configured manually with an 307 autonomic peer; it could learn about autonomic nodes through DHCP 308 options, DNS, and other non-autonomic mechanisms. Generally such 309 non-autonomic mechansims require some administrator intervention. 310 The key purpose is to by-pass a non-autonomic device or network. 311 As this pertains to new devices, it is covered in appendix A and B 312 of [I-D.ietf-anima-bootstrapping-keyinfra]. 314 The adjacency table is defining the behaviour of an autonomic node: 316 o If the node has not bootstrapped into a domain (i.e., doesn't have 317 a domain certificate), it rotates through all nodes in the 318 adjacency table that claim to have a domain, and will attempt 319 bootstrapping through them, one by one. One possible response is 320 a re-direct via a vendor MASA, which will be entered into the 321 adjacency table (see second bullet above). See 322 [I-D.ietf-anima-bootstrapping-keyinfra] for details. 324 o If the adjacent node has the same domain, it will authenticate 325 that adjacent node and, if successful, establish the Autonomic 326 Control Plane (ACP). See 327 [I-D.ietf-anima-autonomic-control-plane]. 329 o Once the node is part of the ACP of a domain, it will use GRASP 330 [I-D.ietf-anima-grasp] to find Registrar(s) of its domain and 331 potentially other services. 333 o If the node is part of an ACP and has discovered at least one 334 Registrar in its domain via GRASP, it will start the "join 335 assistant" ASA, and act as a join assistant for neighboring nodes 336 that need to be bootstrapped. See Section 6.3.1.2 for details. 338 o Other behaviours are possible, for example establishing the ACP 339 also with devices of a sub-domain, to other domains, etc. Those 340 will likely be controlled by Intent. They are outside scope for 341 the moment. Note that Intent is distributed through the ACP; 342 therefore, a node can only adapt Intent driven behaviour once it 343 has joined the ACP. At the moment, ANIMA does not consider 344 providing Intent outside the ACP; this can be considered later. 346 Once a node has joined the ACP, it will also learn the ACP addresses 347 of its adjacent nodes, and add them to the adjacency table, to allow 348 for communication inside the ACP. Further autonomic domain 349 interactions will now happen inside the ACP. At this moment, only 350 negotiation / synchronization via GRASP [I-D.ietf-anima-grasp] is 351 being defined. (Note that GRASP runs in the data plane, as an input 352 in building the adjacency table, as well as inside the ACP.) 354 Autonomic Functions consist of Autonomic Service Agents (ASAs). They 355 run logically above the AN Infrastructure, and may use the adjacency 356 table, the ACP, negotiation and synchronization through GRASP in the 357 ACP, Intent and other functions of the ANI. Since the ANI only 358 provides autonomic interactions within a domain, autonomic functions 359 can also use any other context on a node, specifically the global 360 data plane. 362 3.3. State Machine 364 Autonomic Networking applies during the full life-cycle of a node. 365 This section describes a state machine of an autonomic node, 366 throughout its life. 368 A device is normally expected to store its domain specific identity, 369 the LDevID (see Section 5.2), in persistent storage, to be available 370 after a powercycle event. For device types that cannot store the 371 LDevID in persistent storage, a powercycle event is effectively 372 equivalent to a factory reset. 374 3.3.1. State 1: Factory Default 376 An autonomic node leaves the factory in this state. In this state, 377 the node has no domain specific configuration, specifically no 378 LDevID, and could be used in any particular target network. It does 379 however have a vendor/manufacturer specific ID, the IDevID [IDevID]. 380 Nodes without IDevID cannot be autonomically and securely enrolled 381 into a domain; they require manual pre-staging, in which case the 382 pre-staging takes them directly to state 2. 384 Transitions: 386 o Bootstrap event: The device enrols into a domain; as part of this 387 process it receives a domain identity (LDevID). If enrollment is 388 successful, the next state is state 2. See 389 [I-D.ietf-anima-bootstrapping-keyinfra] Section 3 for details on 390 enrollment. 392 o Powercycle event: The device loses all state tables. It remains 393 in state: 1. 395 3.3.2. State 2: Enrolled 397 An autonomic node is in the state "enrolled" if it has a domain 398 identity (LDevID), and has currently no ACP channel up. It may have 399 further configuration or state, for example if it had been in state 3 400 before, but lost all its ACP channels. The LDevID can only be 401 removed from a device through a factory reset, which also removes all 402 other state from the device. This ensures that a device has no stale 403 domain specific state when entering the "enrolled" state from state 404 1. 406 Transitions: 408 o Joining ACP: The device establishes an ACP channel to an adjacent 409 device. See [I-D.ietf-anima-autonomic-control-plane] for details. 410 Next state: 3. 412 o Factory reset: A factory reset removes all configuration and the 413 domain identity (LDevID) from the device. Next state: 1. 415 o Powercycle event: The device loses all state tables, but not its 416 domain identity (LDevID). it remains in state: 2. 418 3.3.3. State 3: In ACP 420 In this state, the autonomic node has at least one ACP channel to 421 another device. The node can now participate in further autonomic 422 transactions, such as starting autonomic service agents (e.g., it 423 must now enable the join assistant ASA, to help other devices to join 424 the domain. Other conditions may apply to such interactions, for 425 example to serve as a join assistant, the device must first discover 426 a bootstrap Registrar. 428 Transitions: 430 o Leaving ACP: The device drops the last (or only) ACP channel to an 431 adjacent device. Next state: 2. 433 o Factory reset: A factory reset removes all configuration and the 434 domain identity (LDevID) from the device. Next state: 1. 436 o Powercycle event: The device loses all state tables, but not its 437 domain identity (LDevID). Next state: 2. 439 4. The Autonomic Networking Infrastructure 441 The Autonomic Networking Infrastructure provides a layer of common 442 functionality across an Autonomic Network. It provides the 443 elementary functions and services, as well as extensions. An 444 Autonomic Function, comprising of Autonomic Service Agents on nodes, 445 uses the functions described in this section. 447 4.1. Naming 449 Inside a domain, each autonomic device should be assigned a unique 450 name. The naming scheme should be consistent within a domain. Names 451 are typically assigned by a Registrar at bootstrap time and 452 persistent over the lifetime of the device. All Registrars in a 453 domain must follow the same naming scheme. 455 In the absence of a domain specific naming scheme, a default naming 456 scheme should use the same logic as the addressing scheme discussed 457 in [I-D.ietf-anima-autonomic-control-plane]. The device name is then 458 composed of a Registrar ID (for example taking a MAC address of the 459 Registrar) and a device number. An example name would then look like 460 this: 462 0123-4567-89ab-0001 464 The first three fields are the MAC address, the fourth field is the 465 sequential number for the device. 467 4.2. Addressing 469 Autonomic Service Agents (ASAs) need to communicate with each other, 470 using the autonomic addressing of the Autonomic Networking 471 Infrastructure of the node they reside on. This section describes 472 the addressing approach of the Autonomic Networking Infrastructure, 473 used by ASAs. 475 Addressing approaches for the data plane of the network are outside 476 the scope of this document. These addressing approaches may be 477 configured and managed in the traditional way, or negotiated as a 478 service of an ASA. One use case for such an autonomic function is 479 described in [I-D.ietf-anima-prefix-management]. 481 Autonomic addressing is a function of the Autonomic Networking 482 Infrastructure (lower part of Figure 2), specifically the Autonomic 483 Control Plane. ASAs do not have their own addresses. They may use 484 either API calls, or the autonomic addressing scheme of the Autonomic 485 Networking Infrastructure. 487 An autonomic addressing scheme has the following requirements: 489 o Zero-touch for simple networks: Simple networks should have 490 complete self-management of addressing, and not require any 491 central address management, tools, or address planning. 493 o Low-touch for complex networks: If complex networks require 494 operator input for autonomic address management, it should be 495 limited to high level guidance only, expressed in Intent. 497 o Flexibility: The addressing scheme must be flexible enough for 498 nodes to be able to move around, for the network to grow, split 499 and merge. 501 o Robustness: It should be as hard as possible for an administrator 502 to negatively affect addressing (and thus connectivity) in the 503 autonomic context. 505 o Stability: The addressing scheme should be as stable as possible. 506 However, implementations need to be able to recover from 507 unexpected address changes. 509 o Support for virtualization: Autonomic functions can exist either 510 at the level of the physical network and physical devices, or at 511 the level of virtual machines, containers and networks. In 512 particular, Autonomic Nodes may support Autonomic Service Agents 513 in virtual entities. The infrastructure, including the addressing 514 scheme, should be able to support this architecture. 516 o Simplicity: To make engineering simpler, and to give the human 517 administrator an easy way to trouble-shoot autonomic functions. 519 o Scale: The proposed scheme should work in any network of any size. 521 o Upgradability: The scheme must be able to support different 522 addressing concepts in the future. 524 The proposed addressing scheme is described in the document "An 525 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). 527 4.3. Discovery 529 Traditionally, most of the information a node requires is provided 530 through configuration or northbound interfaces. An autonomic 531 function should rely on such northbound interfaces minimally or not 532 at all, and therefore it needs to discover peers and other resources 533 in the network. This section describes various discovery functions 534 in an autonomic network. 536 Discovering nodes and their properties and capabilities: A core 537 function to establish an autonomic domain is the mutual discovery of 538 autonomic nodes, primarily adjacent nodes and secondarily off-link 539 peers. This may in principle either leverage existing discovery 540 mechanisms, or use new mechanisms tailored to the autonomic context. 541 An important point is that discovery must work in a network with no 542 predefined topology, ideally no manual configuration of any kind, and 543 with nodes starting up from factory condition or after any form of 544 failure or sudden topology change. 546 Discovering services: Network services such as AAA should also be 547 discovered and not configured. Service discovery is required for 548 such tasks. An autonomic network can either leverage existing 549 service discovery functions, or use a new approach, or a mixture. 551 Thus the discovery mechanism could either be fully integrated with 552 autonomic signaling (next section) or could use an independent 553 discovery mechanism such as DNS Service Discovery or Service Location 554 Protocol. This choice could be made independently for each Autonomic 555 Service Agent, although the infrastructure might require some minimal 556 lowest common denominator (e.g., for discovering the security 557 bootstrap mechanism, or the source of information distribution, 558 Section 4.7). 560 Phase 1 of Autonomic Networking uses GRASP for discovery, described 561 in [I-D.ietf-anima-grasp]. 563 4.4. Signaling Between Autonomic Nodes 565 Autonomic nodes must communicate with each other, for example to 566 negotiate and/or synchronize technical objectives (i.e., network 567 parameters) of any kind and complexity. This requires some form of 568 signaling between autonomic nodes. Autonomic nodes implementing a 569 specific use case might choose their own signaling protocol, as long 570 as it fits the overall security model. However, in the general case, 571 any pair of autonomic nodes might need to communicate, so there needs 572 to be a generic protocol for this. A prerequisite for this is that 573 autonomic nodes can discover each other without any preconfiguration, 574 as mentioned above. To be generic, discovery and signaling must be 575 able to handle any sort of technical objective, including ones that 576 require complex data structures. The document "A Generic Autonomic 577 Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more 578 detailed requirements for discovery, negotiation and synchronization 579 in an autonomic network. It also defines a protocol, GRASP, for this 580 purpose, including an integrated but optional discovery protocol. 582 GRASP is normally expected to run inside the Autonomic Control Plane 583 (ACP; see Section 4.6) and to depend on the ACP for security. It may 584 run insecurely for a short time during bootstrapping. 586 An autonomic node will normally run a single instance of GRASP, used 587 by multiple ASAs. However, scenarios where multiple instances of 588 GRASP run in a single node, perhaps with different security 589 properties, are not excluded. 591 4.5. Routing 593 All autonomic nodes in a domain must be able to communicate with each 594 other, and later phases also with autonomic nodes outside their own 595 domain. Therefore, an Autonomic Control Plane relies on a routing 596 function. For Autonomic Networks to be interoperable, they must all 597 support one common routing protocol. 599 The routing protocol is defined in the ACP document 600 [I-D.ietf-anima-autonomic-control-plane]. 602 4.6. The Autonomic Control Plane 604 The "Autonomic Control Plane" carries the control protocols in an 605 autonomic network. In the architecture described here, it is 606 implemented as an overlay network. The document "An Autonomic 607 Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes 608 the implementation details suggested here. This document uses the 609 term "overlay" to mean a set of point-to-point adjacencies congruent 610 with the underlying interconnection topology. The terminology may 611 not be aligned with a common usage of the "overlay" term in routing 612 context. See [I-D.ietf-anima-stable-connectivity] for uses cases for 613 the ACP. 615 4.7. Information Distribution (*) 617 Certain forms of information require distribution across an autonomic 618 domain. The distribution of information runs inside the Autonomic 619 Control Plane. For example, Intent is distributed across an 620 autonomic domain, as explained in [RFC7575]. 622 Intent is the policy language of an Autonomic Network, see also 623 Section 7.2. It is a high level policy, and should change only 624 infrequently (order of days). Therefore, information such as Intent 625 should be simply flooded to all nodes in an autonomic domain, and 626 there is currently no perceived need to have more targeted 627 distribution methods. Intent is also expected to be monolithic, and 628 flooded as a whole. One possible method for distributing Intent, as 629 well as other forms of data, is discussed in 630 [I-D.liu-anima-grasp-distribution]. Intent and information 631 distribution are not part of phase 1 of ANIMA. 633 5. Security and Trust Infrastructure 635 An Autonomic Network is self-protecting. All protocols are secure by 636 default, without the requirement for the administrator to explicitly 637 configure security, with the exception of setting up a PKI 638 infrastructure. 640 Autonomic nodes have direct interactions between themselves, which 641 must be secured. Since an autonomic network does not rely on 642 configuration, it is not an option to configure, for example, pre- 643 shared keys. A trust infrastructure such as a PKI infrastructure 644 must be in place. This section describes the principles of this 645 trust infrastructure. In this first phase of autonomic networking, a 646 device is either within the trust domain and fully trusted, or 647 outside the trust domain and fully untrusted. 649 The default method to automatically bring up a trust infrastructure 650 is defined in the document "Bootstrapping Key Infrastructures" 651 [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this 652 enrollment process are described in Section 6.3. An autonomic node 653 must implement the enrollment and join assistant ASAs. The registrar 654 ASA may be implemented only on a sub-set of nodes. 656 5.1. Public Key Infrastructure 658 An autonomic domain uses a PKI model. The root of trust is a 659 certification authority (CA). A registrar acts as a registration 660 authority (RA). 662 A minimum implementation of an autonomic domain contains one CA, one 663 Registrar, and network elements. 665 5.2. Domain Certificate 667 Each device in an autonomic domain uses a domain certificate (LDevID) 668 to prove its identity. A new device uses its manufacturer provided 669 certificate (IDevID) during bootstrap, to obtain a domain 670 certificate. [I-D.ietf-anima-bootstrapping-keyinfra] describes how a 671 new device receives a domain certificate, and the certificate format. 673 5.3. The MASA 675 The Manufacturer Authorized Signing Authority (MASA) is a trusted 676 service for bootstrapping devices. The purpose of the MASA is to 677 provide ownership tracking of devices in a domain. The MASA provides 678 audit, authorization, and ownership tokens to the registrar during 679 the bootstrap process to assist in the authentication of devices 680 attempting to join an Autonomic Domain, and to allow a joining device 681 to validate whether it is joining the correct domain. The details 682 for MASA service, security, and usage are defined in 683 [I-D.ietf-anima-bootstrapping-keyinfra]. 685 5.4. Sub-Domains (*) 687 By default, sub-domains are treated as different domains. This 688 implies no trust between a domain and its sub-domains, and no trust 689 between sub-domains of the same domain. Specifically, no ACP is 690 built, and Intent is valid only for the domain it is defined for 691 explicitly. 693 In phase 2 of ANIMA, alternative trust models should be defined, for 694 example to allow full or limited trust between domain and sub-domain. 696 5.5. Cross-Domain Functionality (*) 698 By default, different domains do not interoperate, no ACP is built 699 and no trust is implied between them. 701 In the future, models can be established where other domains can be 702 trusted in full or for limited operations between the domains. 704 6. Autonomic Service Agents (ASA) 706 This section describes how autonomic services run on top of the 707 Autonomic Networking Infrastructure. 709 6.1. General Description of an ASA 711 An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent 712 implemented on an autonomic node that implements an autonomic 713 function, either in part (in the case of a distributed function) or 714 whole." Thus it is a process that makes use of the features provided 715 by the ANI to achieve its own goals, usually including interaction 716 with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or 717 otherwise. Of course it also interacts with the specific targets of 718 its function, using any suitable mechanism. Unless its function is 719 very simple, the ASA will need to handle overlapping asynchronous 720 operations. It may therefore be a quite complex piece of software in 721 its own right, forming part of the application layer above the ANI. 722 ASA design guidelines are available in 723 [I-D.carpenter-anima-asa-guidelines]. 725 Thus we can distinguish at least three classes of ASAs: 727 o Simple ASAs with a small footprint that could run anywhere. 729 o Complex, possibly multi-threaded ASAs that have a significant 730 resource requirement and will only run on selected nodes. 732 o A few 'infrastructure ASAs' that use basic ANI features in support 733 of the ANI itself, which must run in all autonomic nodes. These 734 are outlined in the following sections. 736 Autonomic nodes, and therefore their ASAs, know their own 737 capabilities and restrictions, derived from hardware, firmware or 738 pre-installed software: They are "self-aware". 740 The role of an autonomic node depends on Intent and on the 741 surrounding network behaviors, which may include forwarding 742 behaviors, aggregation properties, topology location, bandwidth, 743 tunnel or translation properties, etc. For example, a node may 744 decide to act as a backup node for a neighbor, if its capabilities 745 allow it to do so. 747 Following an initial discovery phase, the node properties and those 748 of its neighbors are the foundation of the behavior of a specific 749 node. A node and its ASAs have no pre-configuration for the 750 particular network in which they are installed. 752 Since all ASAs will interact with the ANI, they will depend on 753 appropriate application programming interfaces (APIs). It is 754 desirable that ASAs are portable between operating systems, so these 755 APIs need to be universal. An API for GRASP is described in 756 [I-D.ietf-anima-grasp-api]. 758 ASAs will in general be designed and coded by experts in a particular 759 technology and use case, not by experts in the ANI and its 760 components. Also, they may be coded in a variety of programming 761 languages, in particular including languages that support object 762 constructs as well as traditional variables and structures. The APIs 763 should be designed with these factors in mind. 765 It must be possible to run ASAs as non-privileged (user space) 766 processes except for those (such as the infrastructure ASAs) that 767 necessarily require kernel privilege. Also, it is highly desirable 768 that ASAs can be dynamically loaded on a running node. 770 Since autonomic systems must be self-repairing, it is of great 771 importance that ASAs are coded using robust programming techniques. 772 All run-time error conditions must be caught, leading to suitable 773 minimally disruptive recovery actions, also considering a complete 774 restart of the ASA. Conditions such as discovery failures or 775 negotiation failures must be treated as routine, with the ASA 776 retrying the failed operation, preferably with an exponential back- 777 off in the case of persistent errors. When multiple threads are 778 started within an ASA, these threads must be monitored for failures 779 and hangups, and appropriate action taken. Attention must be given 780 to garbage collection, so that ASAs never run out of resources. 781 There is assumed to be no human operator - again, in the worst case, 782 every ASA must be capable of restarting itself. 784 ASAs will automatically benefit from the security provided by the 785 ANI, and specifically by the ACP and by GRASP. However, beyond that, 786 they are responsible for their own security, especially when 787 communicating with the specific targets of their function. 788 Therefore, the design of an ASA must include a security analysis 789 beyond 'use ANI security.' 791 6.2. ASA Life-Cycle Management 793 ASAs operating on a given ANI may come from different providers and 794 pursue different objectives. Management of ASAs and its interactions 795 with the ANI should follow the same operating principles, hence 796 comply to a generic life-cycle management model. 798 The ASA life-cycle provides standard processes to: 800 o install ASA: copy the ASA code onto the node and start it, 802 o deploy ASA: associate the ASA instance with a (some) managed 803 network device(s) (or network function), 805 o control ASA execution: when and how an ASA executes its control 806 loop. 808 The life-cyle will cover the sequential states below: Installation, 809 Deployment, Operation and the transitional states in-between. This 810 Life-Cycle will also define which interactions ASAs have with the ANI 811 in between the different states. The noticeable interactions are: 813 o Self-description of ASA instances at the end of deployment: its 814 format needs to define the information required for the management 815 of ASAs by ANI entities 817 o Control of ASA control-loop during the operation: a signaling has 818 to carry formatted messages to control ASA execution (at least 819 starting and stopping the control loop) 821 6.3. Specific ASAs for the Autonomic Network Infrastructure 823 The following functions provide essential, required functionality in 824 an autonomic network, and are therefore mandatory to implement on 825 unconstrained autonomic nodes. They are described here as ASAs that 826 include the underlying infrastructure components, but implementation 827 details might vary. 829 The first three together support the trust enrollment process 830 described in Section 5. For details see 831 [I-D.ietf-anima-bootstrapping-keyinfra]. 833 6.3.1. The enrollment ASAs 835 6.3.1.1. The Pledge ASA 837 This ASA includes the function of an autonomic node that bootstraps 838 into the domain with the help of an join assitant ASA (see below). 839 Such a node is known as a Pledge during the enrollment process. This 840 ASA must be installed by default on all nodes that require an 841 autonomic zero-touch bootstrap. 843 6.3.1.2. The Join Assistant ASA 845 This ASA includes the function of an autonomic node that helps a non- 846 enrolled, adjacent devices to enroll into the domain. This ASA must 847 be installed on all nodes, although only one join assistant needs to 848 be active on a given LAN. See also 849 [I-D.ietf-anima-bootstrapping-keyinfra]. 851 6.3.1.3. The Join Registrar ASA 853 This ASA includes the join registrar function in an autonomic 854 network. This ASA does not need to be installed on all nodes, but 855 only on nodes that implement the Join Registrar function. 857 6.3.2. The ACP ASA 859 This ASA includes the ACP function in an autonomic network. In 860 particular it acts to discover other potential ACP nodes, and to 861 support the establishment and teardown of ACP channels. This ASA 862 must be installed on all nodes. For details see Section 4.6 and 863 [I-D.ietf-anima-autonomic-control-plane]. 865 6.3.3. The Information Distribution ASA (*) 867 This ASA is currently out of scope in ANIMA, and provided here only 868 as background information. 870 This ASA includes the information distribution function in an 871 autonomic network. In particular it acts to announce the 872 availability of Intent and other information to all other autonomic 873 nodes. This ASA does not need to be installed on all nodes, but only 874 on nodes that implement the information distribution function. For 875 details see Section 4.7. 877 Note that information distribution can be implemented as a function 878 in any ASA. See [I-D.liu-anima-grasp-distribution] for more details 879 on how information is suggested to be distributed. 881 7. Management and Programmability 883 This section describes how an Autonomic Network is managed, and 884 programmed. 886 7.1. Managing a (Partially) Autonomic Network 888 Autonomic management usually co-exists with traditional management 889 methods in most networks. Thus, autonomic behavior will be defined 890 for individual functions in most environments. Examples for overlap 891 are: 893 o Autonomic functions can use traditional methods and protocols 894 (e.g., SNMP and NETCONF) to perform management tasks, inside and 895 outside the ACP; 897 o Autonomic functions can conflict with behavior enforced by the 898 same traditional methods and protocols; 900 o Traditional functions can use the ACP, for example if reachability 901 on the data plane is not (yet) established. 903 The autonomic Intent is defined at a high level of abstraction. 904 However, since it is necessary to address individual managed 905 elements, autonomic management needs to communicate in lower-level 906 interactions (e.g., commands and requests). For example, it is 907 expected that the configuration of such elements be performed using 908 NETCONF and YANG modules as well as the monitoring be executed 909 through SNMP and MIBs. 911 Conflict can occur between autonomic default behavior, autonomic 912 Intent, traditional management methods. Conflict resolution is 913 achieved in autonomic management through prioritization [RFC7575]. 914 The rationale is that manual and node-based management have a higher 915 priority over autonomic management. Thus, the autonomic default 916 behavior has the lowest priority, then comes the autonomic Intent 917 (medium priority), and, finally, the highest priority is taken by 918 node-specific network management methods, such as the use of command 919 line interfaces. 921 7.2. Intent (*) 923 Intent is not covered in the current implementation specifications. 924 This section discusses a topic for further research. 926 This section gives an overview of Intent, and how it is managed. 927 Intent and Policy-Based Network Management (PBNM) is already 928 described inside the IETF (e.g., PCIM) and in other SDOs (e.g., DMTF 929 and TMF ZOOM). 931 Intent can be described as an abstract, declarative, high-level 932 policy used to operate an autonomic domain, such as an enterprise 933 network [RFC7575]. Intent should be limited to high level guidance 934 only, thus it does not directly define a policy for every network 935 element separately. 937 Intent can be refined to lower level policies using different 938 approaches. This is expected in order to adapt the Intent to the 939 capabilities of managed devices. Intent may contain role or function 940 information, which can be translated to specific nodes [RFC7575]. 941 One of the possible refinements of the Intent is using Event- 942 Condition-Action (ECA) rules. 944 Different parameters may be configured for Intent. These parameters 945 are usually provided by the human operator. Some of these parameters 946 can influence the behavior of specific autonomic functions as well as 947 the way the Intent is used to manage the autonomic domain. 949 Intent is discussed in more detail in [I-D.du-anima-an-intent]. 950 Intent as well as other types of information are distributed via 951 GRASP, see [I-D.liu-anima-grasp-distribution]. 953 7.3. Aggregated Reporting (*) 955 Aggregated reporting is not covered in the current implementation 956 specifications. This section discusses a topic for further research. 958 An Autonomic Network should minimize the need for human intervention. 959 In terms of how the network should behave, this is done through an 960 autonomic Intent provided by the human administrator. In an 961 analogous manner, the reports which describe the operational status 962 of the network should aggregate the information produced in different 963 network elements in order to present the effectiveness of autonomic 964 Intent enforcement. Therefore, reporting in an autonomic network 965 should happen on a network-wide basis [RFC7575]. 967 Multiple simultaneous events can occur in an autonomic network in the 968 same way they can happen in a traditional network. However, when 969 reporting to a human administrator, such events should be aggregated 970 to avoid notifications about individual managed elements. In this 971 context, algorithms may be used to determine what should be reported 972 (e.g., filtering) and in which way and how different events are 973 related to each other. Besides that, an event in an individual 974 element can be compensated by changes in other elements to maintain a 975 network-wide target which is described in the autonomic Intent. 977 Reporting in an autonomic network may be at the same abstraction 978 level as Intent. In this context, the aggregated view of current 979 operational status of an autonomic network can be used to switch to 980 different management modes. Despite the fact that autonomic 981 management should minimize the need for user intervention, possibly 982 there are some events that need to be addressed by human 983 administrator actions. 985 7.4. Feedback Loops to NOC (*) 987 Feedback loops are required in an autonomic network to allow the 988 intervention of a human administrator or central control systems, 989 while maintaining a default behaviour. Through a feedback loop an 990 administrator must be prompted with a default action, and has the 991 possibility to acknowledge or override the proposed default action. 993 Uni-directional notifications to the NOC, that do not propose any 994 default action, and do not allow an override as part of the 995 transaction are considered like traditional notification services, 996 such as syslog. They are expected to co-exist with autonomic 997 methods, but are not covered in this draft. 999 7.5. Control Loops (*) 1001 Control loops are not covered in the current implementation 1002 specifications. This section discusses a topic for further research. 1004 Control loops are used in autonomic networking to provide a generic 1005 mechanism to enable the Autonomic System to adapt (on its own) to 1006 various factors that can change the goals that the autonomic network 1007 is trying to achieve, or how those goals are achieved. For example, 1008 as user needs, business goals, and the ANI itself changes, self- 1009 adaptation enables the ANI to change the services and resources it 1010 makes available to adapt to these changes. 1012 Control loops operate to continuously observe and collect data that 1013 enables the autonomic management system to understand changes to the 1014 behavior of the system being managed, and then provide actions to 1015 move the state of the system being managed toward a common goal. 1016 Self-adaptive systems move decision-making from static, pre-defined 1017 commands to dynamic processes computed at runtime. 1019 Most autonomic systems use a closed control loop with feedback. Such 1020 control loops should be able to be dynamically changed at runtime to 1021 adapt to changing user needs, business goals, and changes in the ANI. 1023 7.6. APIs (*) 1025 APIs are not covered in the current implementation specifications. 1026 This section discusses a topic for further research. 1028 Most APIs are static, meaning that they are pre-defined and represent 1029 an invariant mechanism for operating with data. An Autonomic Network 1030 should be able to use dynamic APIs in addition to static APIs. 1032 A dynamic API is one that retrieves data using a generic mechanism, 1033 and then enables the client to navigate the retrieved data and 1034 operate on it. Such APIs typically use introspection and/or 1035 reflection. Introspection enables software to examine the type and 1036 properties of an object at runtime, while reflection enables a 1037 program to manipulate the attributes, methods, and/or metadata of an 1038 object. 1040 APIs must be able to express and preserve the semantics of data 1041 models. For example, software contracts [Meyer97] are based on the 1042 principle that a software-intensive system, such as an Autonomic 1043 Network, is a set of communicating components whose interaction is 1044 based on precisely-defined specifications of the mutual obligations 1045 that interacting components must respect. This typically includes 1046 specifying: 1048 o pre-conditions that must be satisfied before the method can start 1049 execution 1051 o post-conditions that must be satisfied when the method has 1052 finished execution 1054 o invariant attributes that must not change during the execution of 1055 the method 1057 7.7. Data Model (*) 1059 Data models are not covered in the current implementation 1060 specifications. This section discusses a topic for further research. 1062 The following definitions are adapted from 1063 [I-D.ietf-supa-generic-policy-data-model]: 1065 An information model is a representation of concepts of interest to 1066 an environment in a form that is independent of data repository, data 1067 definition language, query language, implementation language, and 1068 protocol. In contrast, a data model is a representation of concepts 1069 of interest to an environment in a form that is dependent on data 1070 repository, data definition language, query language, implementation 1071 language, and protocol (typically, but not necessarily, all three). 1073 The utility of an information model is to define objects and their 1074 relationships in a technology-neutral manner. This forms a 1075 consensual vocabulary that the ANI and ASAs can use. A data model is 1076 then a technology-specific mapping of all or part of the information 1077 model to be used by all or part of the system. 1079 A system may have multiple data models. Operational Support Systems, 1080 for example, typically have multiple types of repositories, such as 1081 SQL and NoSQL, to take advantage of the different properties of each. 1082 If multiple data models are required by an Autonomic System, then an 1083 information model should be used to ensure that the concepts of each 1084 data model can be related to each other without technological bias. 1086 A data model is essential for certain types of functions, such as a 1087 Model-Reference Adaptive Control Loop (MRACL). More generally, a 1088 data model can be used to define the objects, attributes, methods, 1089 and relationships of a software system (e.g., the ANI, an autonomic 1090 node, or an ASA). A data model can be used to help design an API, as 1091 well as any language used to interface to the Autonomic Network. 1093 8. Coordination Between Autonomic Functions (*) 1095 Coordination between autonomic functions is not covered in the 1096 current implementation specifications. This section discusses a 1097 topic for further research. 1099 8.1. The Coordination Problem (*) 1101 Different autonomic functions may conflict in setting certain 1102 parameters. For example, an energy efficiency function may want to 1103 shut down a redundant link, while a load balancing function would not 1104 want that to happen. The administrator must be able to understand 1105 and resolve such interactions, to steer autonomic network performance 1106 to a given (intended) operational point. 1108 Several interaction types may exist among autonomic functions, for 1109 example: 1111 o Cooperation: An autonomic function can improve the behavior or 1112 performance of another autonomic function, such as a traffic 1113 forecasting function used by a traffic allocation function. 1115 o Dependency: An autonomic function cannot work without another one 1116 being present or accessible in the autonomic network. 1118 o Conflict: A metric value conflict is a conflict where one metric 1119 is influenced by parameters of different autonomic functions. A 1120 parameter value conflict is a conflict where one parameter is 1121 modified by different autonomic functions. 1123 Solving the coordination problem beyond one-by-one cases can rapidly 1124 become intractable for large networks. Specifying a common 1125 functional block on coordination is a first step to address the 1126 problem in a systemic way. The coordination life-cycle consists in 1127 three states: 1129 o At build-time, a "static interaction map" can be constructed on 1130 the relationship of functions and attributes. This map can be 1131 used to (pre-)define policies and priorities on identified 1132 conflicts. 1134 o At deploy-time, autonomic functions are not yet active/acting on 1135 the network. A "dynamic interaction map" is created for each 1136 instance of each autonomic functions and on a per resource basis, 1137 including the actions performed and their relationships. This map 1138 provides the basis to identify conflicts that will happen at run- 1139 time, categorize them and plan for the appropriate coordination 1140 strategies/mechanisms. 1142 o At run-time, when conflicts happen, arbitration is driven by the 1143 coordination strategies. Also new dependencies can be observed 1144 and inferred, resulting in an update of the dynamic interaction 1145 map and adaptation of the coordination strategies and mechanisms. 1147 Multiple coordination strategies and mechanisms exist and can be 1148 devised. The set ranges from basic approaches such as random process 1149 or token-based process, to approaches based on time separation and 1150 hierarchical optimization, to more complex approaches such as multi- 1151 objective optimization, and other control theory approaches and 1152 algorithms family. 1154 8.2. A Coordination Functional Block (*) 1156 A common coordination functional block is a desirable component of 1157 the ANIMA reference model. It provides a means to ensure network 1158 properties and predictable performance or behavior such as stability, 1159 and convergence, in the presence of several interacting autonomic 1160 functions. 1162 A common coordination function requires: 1164 o A common description of autonomic functions, their attributes and 1165 life-cycle. 1167 o A common representation of information and knowledge (e.g., 1168 interaction maps). 1170 o A common "control/command" interface between the coordination 1171 "agent" and the autonomic functions. 1173 Guidelines, recommendations or BCPs can also be provided for aspects 1174 pertaining to the coordination strategies and mechanisms. 1176 9. Security Considerations 1178 In this section we distinguish outsider and insider attacks. In an 1179 outsider attack all network elements and protocols are securely 1180 managed and operating, and an outside attacker can sniff packets in 1181 transit, inject and replay packets. In an insider attack, the 1182 attacker has access to an autonomic node or other means (e.g. remote 1183 code execution in the node by exploiting ACP-independent 1184 vulnerabilities in the node platform) to produce arbitrary payloads 1185 on the protected ACP channels. 1187 If a system has vulnerabilities in the implementation or operation 1188 (configuration), an outside attacker can exploit such vulnerabilies 1189 to become an insider attacker. 1191 9.1. Protection Against Outsider Attacks 1193 Here, we assume that all systems involved in an autonomic network are 1194 secured and operated according to best current practices. These 1195 protection methods comprise traditional security implementation and 1196 operation methods (such as code security, strong randomization 1197 algorithms, strong passwords, etc.) as well as mechanisms specific to 1198 an autonomic network (such as a secured MASA service). 1200 Traditional security methods for both implementation and operation 1201 are outside scope for this document. 1203 AN specific protocols and methods must also follow traditional 1204 security methods, in that all packets that can be sniffed or injected 1205 by an outside attacker are: 1207 o protected against modification. 1209 o authenticated. 1211 o protected against replay attacks. 1213 o confidentiality protected (encrypted). 1215 o and that the AN protocols are robust against packet drops and man- 1216 in-the-middle attacks. 1218 How these requirements are met is covered in the AN standards track 1219 documents that define the methods used, specifically 1220 [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], and 1221 [I-D.ietf-anima-autonomic-control-plane]. 1223 Most AN messages run inside the cryptographically protected ACP. The 1224 unprotected AN messages outside the ACP are limited to a simple 1225 discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]: 1226 The "Discovery Unsolicited Link-Local (DULL)" message, with detailed 1227 rules on its usage. 1229 If AN messages can be observed by a third party, they might reveal 1230 valuable information about network configuration, security 1231 precautions in use, individual users, and their traffic patterns. If 1232 encrypted, AN messages might still reveal some information via 1233 traffic analysis. 1235 9.2. Risk of Insider Attacks 1237 An autonomic network consists of autonomic devices that form a 1238 distributed self-managing system. Devices within a domain have 1239 credentials issued from a common trust anchor and can use them to 1240 create mutual trust. This means that any device inside a trust 1241 domain can by default use all distributed functions in the entire 1242 autonomic domain in a malicious way. 1244 If an autonomic node or protocol has vulnerabilities or is not 1245 securely operated, an outside attacker has the following generic ways 1246 to take control of an autonomic network: 1248 o Introducing a fake device into the trust domain, by subverting the 1249 authentication methods. This depends on the correct 1250 specification, implementation and operation of the AN protocols. 1252 o Subverting a device which is already part of a trust domain, and 1253 modifying its behavior. This threat is not specific to the 1254 solution discussed in this document, and applies to all network 1255 solutions. 1257 o Exploiting potentially yet unknown protocol vulnerabilities in the 1258 AN or other protocols. Also this is a generic threat that applies 1259 to all network solutions. 1261 The above threats are in principle comparable to other solutions: In 1262 the presence of design, implementation or operational errors, 1263 security is no longer guaranteed. However, the distributed nature of 1264 AN, specifically the Autonomic Control Plane, increases the threat 1265 surface significantly. For example, a compromised device may have 1266 full IP reachability to all other devices inside the ACP, and can use 1267 all AN methods and protocols. 1269 For the next phase of the ANIMA work it is therefore recommended to 1270 introduce a sub-domain security model, to reduce the attack surface 1271 and not expose a full domain to a potential intruder. Furthermore, 1272 additional security mechanisms on the ASA level should be considered 1273 for high-risk autonomic functions. 1275 10. IANA Considerations 1277 This document requests no action by IANA. 1279 11. Acknowledgements 1281 Many people have provided feedback and input to this document: Sheng 1282 Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur 1283 Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, 1284 Tianran Zhou and Christian Hopps. 1286 12. Contributors 1288 Significant contributions to this document have been made by John 1289 Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia. 1291 13. References 1293 13.1. Normative References 1295 [I-D.ietf-anima-autonomic-control-plane] 1296 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1297 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1298 plane-18 (work in progress), August 2018. 1300 [I-D.ietf-anima-bootstrapping-keyinfra] 1301 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1302 S., and K. Watsen, "Bootstrapping Remote Secure Key 1303 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1304 keyinfra-17 (work in progress), November 2018. 1306 [I-D.ietf-anima-grasp] 1307 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1308 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1309 grasp-15 (work in progress), July 2017. 1311 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 1312 December 2009, . 1315 13.2. Informative References 1317 [I-D.carpenter-anima-asa-guidelines] 1318 Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre, 1319 "Guidelines for Autonomic Service Agents", draft- 1320 carpenter-anima-asa-guidelines-05 (work in progress), June 1321 2018. 1323 [I-D.du-anima-an-intent] 1324 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 1325 Behringer, "ANIMA Intent Policy and Format", draft-du- 1326 anima-an-intent-05 (work in progress), February 2017. 1328 [I-D.ietf-anima-grasp-api] 1329 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1330 Autonomic Signaling Protocol Application Program Interface 1331 (GRASP API)", draft-ietf-anima-grasp-api-02 (work in 1332 progress), June 2018. 1334 [I-D.ietf-anima-prefix-management] 1335 Jiang, S., Du, Z., and B. Carpenter, "Autonomic IPv6 Edge 1336 Prefix Management in Large-scale Networks", draft-ietf- 1337 anima-prefix-management-07 (work in progress), December 1338 2017. 1340 [I-D.ietf-anima-stable-connectivity] 1341 Eckert, T. and M. Behringer, "Using Autonomic Control 1342 Plane for Stable Connectivity of Network OAM", draft-ietf- 1343 anima-stable-connectivity-10 (work in progress), February 1344 2018. 1346 [I-D.ietf-supa-generic-policy-data-model] 1347 Halpern, J. and J. Strassner, "Generic Policy Data Model 1348 for Simplified Use of Policy Abstractions (SUPA)", draft- 1349 ietf-supa-generic-policy-data-model-04 (work in progress), 1350 June 2017. 1352 [I-D.liu-anima-grasp-distribution] 1353 Liu, B., Jiang, S., Xiao, X., Hecker, A., and Z. 1354 Despotovic, "Information Distribution in Autonomic 1355 Networking", draft-liu-anima-grasp-distribution-09 (work 1356 in progress), October 2018. 1358 [Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd 1359 edition)", Prentice-Hall, ISBN 978-0136291558, 1997. 1361 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1362 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1363 Networking: Definitions and Design Goals", RFC 7575, 1364 DOI 10.17487/RFC7575, June 2015, . 1367 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1368 Analysis for Autonomic Networking", RFC 7576, 1369 DOI 10.17487/RFC7576, June 2015, . 1372 Authors' Addresses 1374 Michael H. Behringer (editor) 1376 Email: Michael.H.Behringer@gmail.com 1378 Brian Carpenter 1379 Department of Computer Science 1380 University of Auckland 1381 PB 92019 1382 Auckland 1142 1383 New Zealand 1385 Email: brian.e.carpenter@gmail.com 1387 Toerless Eckert 1388 Futurewei Technologies Inc. 1389 2330 Central Expy 1390 Santa Clara 95050 1391 USA 1393 Email: tte@cs.fau.de 1395 Laurent Ciavaglia 1396 Nokia 1397 Villarceaux 1398 Nozay 91460 1399 FR 1401 Email: laurent.ciavaglia@nokia.com 1403 Jeferson Campos Nobre 1404 University of Vale do Rio dos Sinos 1405 Av. Unisinos, 950 1406 Sao Leopoldo 91501-970 1407 Brazil 1409 Email: jcnobre@unisinos.br