idnits 2.17.1 draft-ietf-anima-reference-model-09.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 6, 2018) is 1995 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-16 == 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 10, 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 6, 2018 14 A Reference Model for Autonomic Networking 15 draft-ietf-anima-reference-model-09 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 10, 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 . . . . . . . . . . . . . . . . . . . . . 18 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 (*) . . . . . . . . . . . . . . . . 20 92 7.4. Feedback Loops to NOC (*) . . . . . . . . . . . . . . . . 21 93 7.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 21 94 7.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 22 95 7.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 23 96 8. Coordination Between Autonomic Functions (*) . . . . . . . . 23 97 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 23 98 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 25 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25 100 9.1. Protection Against Outsider Attacks . . . . . . . . . . . 25 101 9.2. Risk of Insider Attacks . . . . . . . . . . . . . . . . . 26 102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 103 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 104 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 105 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 27 107 13.2. Informative References . . . . . . . . . . . . . . . . . 28 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 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. See 609 [I-D.ietf-anima-stable-connectivity] for uses cases for the ACP. 611 4.7. Information Distribution (*) 613 Certain forms of information require distribution across an autonomic 614 domain. The distribution of information runs inside the Autonomic 615 Control Plane. For example, Intent is distributed across an 616 autonomic domain, as explained in [RFC7575]. 618 Intent is the policy language of an Autonomic Network, see also 619 Section 7.2. It is a high level policy, and should change only 620 infrequently (order of days). Therefore, information such as Intent 621 should be simply flooded to all nodes in an autonomic domain, and 622 there is currently no perceived need to have more targeted 623 distribution methods. Intent is also expected to be monolithic, and 624 flooded as a whole. One possible method for distributing Intent, as 625 well as other forms of data, is discussed in 626 [I-D.liu-anima-grasp-distribution]. Intent and information 627 distribution are not part of phase 1 of ANIMA. 629 5. Security and Trust Infrastructure 631 An Autonomic Network is self-protecting. All protocols are secure by 632 default, without the requirement for the administrator to explicitly 633 configure security, with the exception of setting up a PKI 634 infrastructure. 636 Autonomic nodes have direct interactions between themselves, which 637 must be secured. Since an autonomic network does not rely on 638 configuration, it is not an option to configure, for example, pre- 639 shared keys. A trust infrastructure such as a PKI infrastructure 640 must be in place. This section describes the principles of this 641 trust infrastructure. In this first phase of autonomic networking, a 642 device is either within the trust domain and fully trusted, or 643 outside the trust domain and fully untrusted. 645 The default method to automatically bring up a trust infrastructure 646 is defined in the document "Bootstrapping Key Infrastructures" 647 [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this 648 enrollment process are described in Section 6.3. An autonomic node 649 must implement the enrollment and join assistant ASAs. The registrar 650 ASA may be implemented only on a sub-set of nodes. 652 5.1. Public Key Infrastructure 654 An autonomic domain uses a PKI model. The root of trust is a 655 certification authority (CA). A registrar acts as a registration 656 authority (RA). 658 A minimum implementation of an autonomic domain contains one CA, one 659 Registrar, and network elements. 661 5.2. Domain Certificate 663 Each device in an autonomic domain uses a domain certificate (LDevID) 664 to prove its identity. A new device uses its manufacturer provided 665 certificate (IDevID) during bootstrap, to obtain a domain 666 certificate. [I-D.ietf-anima-bootstrapping-keyinfra] describes how a 667 new device receives a domain certificate, and the certificate format. 669 5.3. The MASA 671 The Manufacturer Authorized Signing Authority (MASA) is a trusted 672 service for bootstrapping devices. The purpose of the MASA is to 673 provide ownership tracking of devices in a domain. The MASA provides 674 audit, authorization, and ownership tokens to the registrar during 675 the bootstrap process to assist in the authentication of devices 676 attempting to join an Autonomic Domain, and to allow a joining device 677 to validate whether it is joining the correct domain. The details 678 for MASA service, security, and usage are defined in 679 [I-D.ietf-anima-bootstrapping-keyinfra]. 681 5.4. Sub-Domains (*) 683 By default, sub-domains are treated as different domains. This 684 implies no trust between a domain and its sub-domains, and no trust 685 between sub-domains of the same domain. Specifically, no ACP is 686 built, and Intent is valid only for the domain it is defined for 687 explicitly. 689 In phase 2 of ANIMA, alternative trust models should be defined, for 690 example to allow full or limited trust between domain and sub-domain. 692 5.5. Cross-Domain Functionality (*) 694 By default, different domains do not interoperate, no ACP is built 695 and no trust is implied between them. 697 In the future, models can be established where other domains can be 698 trusted in full or for limited operations between the domains. 700 6. Autonomic Service Agents (ASA) 702 This section describes how autonomic services run on top of the 703 Autonomic Networking Infrastructure. 705 6.1. General Description of an ASA 707 An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent 708 implemented on an autonomic node that implements an autonomic 709 function, either in part (in the case of a distributed function) or 710 whole." Thus it is a process that makes use of the features provided 711 by the ANI to achieve its own goals, usually including interaction 712 with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or 713 otherwise. Of course it also interacts with the specific targets of 714 its function, using any suitable mechanism. Unless its function is 715 very simple, the ASA will need to handle overlapping asynchronous 716 operations. It may therefore be a quite complex piece of software in 717 its own right, forming part of the application layer above the ANI. 718 ASA design guidelines are available in 719 [I-D.carpenter-anima-asa-guidelines]. 721 Thus we can distinguish at least three classes of ASAs: 723 o Simple ASAs with a small footprint that could run anywhere. 725 o Complex, possibly multi-threaded ASAs that have a significant 726 resource requirement and will only run on selected nodes. 728 o A few 'infrastructure ASAs' that use basic ANI features in support 729 of the ANI itself, which must run in all autonomic nodes. These 730 are outlined in the following sections. 732 Autonomic nodes, and therefore their ASAs, know their own 733 capabilities and restrictions, derived from hardware, firmware or 734 pre-installed software: They are "self-aware". 736 The role of an autonomic node depends on Intent and on the 737 surrounding network behaviors, which may include forwarding 738 behaviors, aggregation properties, topology location, bandwidth, 739 tunnel or translation properties, etc. For example, a node may 740 decide to act as a backup node for a neighbor, if its capabilities 741 allow it to do so. 743 Following an initial discovery phase, the node properties and those 744 of its neighbors are the foundation of the behavior of a specific 745 node. A node and its ASAs have no pre-configuration for the 746 particular network in which they are installed. 748 Since all ASAs will interact with the ANI, they will depend on 749 appropriate application programming interfaces (APIs). It is 750 desirable that ASAs are portable between operating systems, so these 751 APIs need to be universal. An API for GRASP is described in 752 [I-D.ietf-anima-grasp-api]. 754 ASAs will in general be designed and coded by experts in a particular 755 technology and use case, not by experts in the ANI and its 756 components. Also, they may be coded in a variety of programming 757 languages, in particular including languages that support object 758 constructs as well as traditional variables and structures. The APIs 759 should be designed with these factors in mind. 761 It must be possible to run ASAs as non-privileged (user space) 762 processes except for those (such as the infrastructure ASAs) that 763 necessarily require kernel privilege. Also, it is highly desirable 764 that ASAs can be dynamically loaded on a running node. 766 Since autonomic systems must be self-repairing, it is of great 767 importance that ASAs are coded using robust programming techniques. 768 All run-time error conditions must be caught, leading to suitable 769 minimally disruptive recovery actions, also considering a complete 770 restart of the ASA. Conditions such as discovery failures or 771 negotiation failures must be treated as routine, with the ASA 772 retrying the failed operation, preferably with an exponential back- 773 off in the case of persistent errors. When multiple threads are 774 started within an ASA, these threads must be monitored for failures 775 and hangups, and appropriate action taken. Attention must be given 776 to garbage collection, so that ASAs never run out of resources. 777 There is assumed to be no human operator - again, in the worst case, 778 every ASA must be capable of restarting itself. 780 ASAs will automatically benefit from the security provided by the 781 ANI, and specifically by the ACP and by GRASP. However, beyond that, 782 they are responsible for their own security, especially when 783 communicating with the specific targets of their function. 784 Therefore, the design of an ASA must include a security analysis 785 beyond 'use ANI security.' 787 6.2. ASA Life-Cycle Management 789 ASAs operating on a given ANI may come from different providers and 790 pursue different objectives. Management of ASAs and its interactions 791 with the ANI should follow the same operating principles, hence 792 comply to a generic life-cycle management model. 794 The ASA life-cycle provides standard processes to: 796 o install ASA: copy the ASA code onto the node and start it, 798 o deploy ASA: associate the ASA instance with a (some) managed 799 network device(s) (or network function), 801 o control ASA execution: when and how an ASA executes its control 802 loop. 804 The life-cyle will cover the sequential states below: Installation, 805 Deployment, Operation and the transitional states in-between. This 806 Life-Cycle will also define which interactions ASAs have with the ANI 807 in between the different states. The noticeable interactions are: 809 o Self-description of ASA instances at the end of deployment: its 810 format needs to define the information required for the management 811 of ASAs by ANI entities 813 o Control of ASA control-loop during the operation: a signaling has 814 to carry formatted messages to control ASA execution (at least 815 starting and stopping the control loop) 817 6.3. Specific ASAs for the Autonomic Network Infrastructure 819 The following functions provide essential, required functionality in 820 an autonomic network, and are therefore mandatory to implement on 821 unconstrained autonomic nodes. They are described here as ASAs that 822 include the underlying infrastructure components, but implementation 823 details might vary. 825 The first three together support the trust enrollment process 826 described in Section 5. For details see 827 [I-D.ietf-anima-bootstrapping-keyinfra]. 829 6.3.1. The enrollment ASAs 831 6.3.1.1. The Pledge ASA 833 This ASA includes the function of an autonomic node that bootstraps 834 into the domain with the help of an join assitant ASA (see below). 835 Such a node is known as a Pledge during the enrollment process. This 836 ASA must be installed by default on all nodes that require an 837 autonomic zero-touch bootstrap. 839 6.3.1.2. The Join Assistant ASA 841 This ASA includes the function of an autonomic node that helps a non- 842 enrolled, adjacent devices to enroll into the domain. This ASA must 843 be installed on all nodes, although only one join assistant needs to 844 be active on a given LAN. See also 845 [I-D.ietf-anima-bootstrapping-keyinfra]. 847 6.3.1.3. The Join Registrar ASA 849 This ASA includes the join registrar function in an autonomic 850 network. This ASA does not need to be installed on all nodes, but 851 only on nodes that implement the Join Registrar function. 853 6.3.2. The ACP ASA 855 This ASA includes the ACP function in an autonomic network. In 856 particular it acts to discover other potential ACP nodes, and to 857 support the establishment and teardown of ACP channels. This ASA 858 must be installed on all nodes. For details see Section 4.6 and 859 [I-D.ietf-anima-autonomic-control-plane]. 861 6.3.3. The Information Distribution ASA (*) 863 This ASA is currently out of scope in ANIMA, and provided here only 864 as background information. 866 This ASA includes the information distribution function in an 867 autonomic network. In particular it acts to announce the 868 availability of Intent and other information to all other autonomic 869 nodes. This ASA does not need to be installed on all nodes, but only 870 on nodes that implement the information distribution function. For 871 details see Section 4.7. 873 Note that information distribution can be implemented as a function 874 in any ASA. See [I-D.liu-anima-grasp-distribution] for more details 875 on how information is suggested to be distributed. 877 7. Management and Programmability 879 This section describes how an Autonomic Network is managed, and 880 programmed. 882 7.1. Managing a (Partially) Autonomic Network 884 Autonomic management usually co-exists with traditional management 885 methods in most networks. Thus, autonomic behavior will be defined 886 for individual functions in most environments. Examples for overlap 887 are: 889 o Autonomic functions can use traditional methods and protocols 890 (e.g., SNMP and NETCONF) to perform management tasks, inside and 891 outside the ACP; 893 o Autonomic functions can conflict with behavior enforced by the 894 same traditional methods and protocols; 896 o Traditional functions can use the ACP, for example if reachability 897 on the data plane is not (yet) established. 899 The autonomic Intent is defined at a high level of abstraction. 900 However, since it is necessary to address individual managed 901 elements, autonomic management needs to communicate in lower-level 902 interactions (e.g., commands and requests). For example, it is 903 expected that the configuration of such elements be performed using 904 NETCONF and YANG modules as well as the monitoring be executed 905 through SNMP and MIBs. 907 Conflict can occur between autonomic default behavior, autonomic 908 Intent, traditional management methods. Conflict resolution is 909 achieved in autonomic management through prioritization [RFC7575]. 910 The rationale is that manual and node-based management have a higher 911 priority over autonomic management. Thus, the autonomic default 912 behavior has the lowest priority, then comes the autonomic Intent 913 (medium priority), and, finally, the highest priority is taken by 914 node-specific network management methods, such as the use of command 915 line interfaces. 917 7.2. Intent (*) 919 Intent is not covered in the current implementation specifications. 920 This section discusses a topic for further research. 922 This section gives an overview of Intent, and how it is managed. 923 Intent and Policy-Based Network Management (PBNM) is already 924 described inside the IETF (e.g., PCIM) and in other SDOs (e.g., DMTF 925 and TMF ZOOM). 927 Intent can be described as an abstract, declarative, high-level 928 policy used to operate an autonomic domain, such as an enterprise 929 network [RFC7575]. Intent should be limited to high level guidance 930 only, thus it does not directly define a policy for every network 931 element separately. 933 Intent can be refined to lower level policies using different 934 approaches. This is expected in order to adapt the Intent to the 935 capabilities of managed devices. Intent may contain role or function 936 information, which can be translated to specific nodes [RFC7575]. 937 One of the possible refinements of the Intent is using Event- 938 Condition-Action (ECA) rules. 940 Different parameters may be configured for Intent. These parameters 941 are usually provided by the human operator. Some of these parameters 942 can influence the behavior of specific autonomic functions as well as 943 the way the Intent is used to manage the autonomic domain. 945 Intent is discussed in more detail in [I-D.du-anima-an-intent]. 946 Intent as well as other types of information are distributed via 947 GRASP, see [I-D.liu-anima-grasp-distribution]. 949 7.3. Aggregated Reporting (*) 951 Aggregated reporting is not covered in the current implementation 952 specifications. This section discusses a topic for further research. 954 An Autonomic Network should minimize the need for human intervention. 955 In terms of how the network should behave, this is done through an 956 autonomic Intent provided by the human administrator. In an 957 analogous manner, the reports which describe the operational status 958 of the network should aggregate the information produced in different 959 network elements in order to present the effectiveness of autonomic 960 Intent enforcement. Therefore, reporting in an autonomic network 961 should happen on a network-wide basis [RFC7575]. 963 Multiple simultaneous events can occur in an autonomic network in the 964 same way they can happen in a traditional network. However, when 965 reporting to a human administrator, such events should be aggregated 966 to avoid notifications about individual managed elements. In this 967 context, algorithms may be used to determine what should be reported 968 (e.g., filtering) and in which way and how different events are 969 related to each other. Besides that, an event in an individual 970 element can be compensated by changes in other elements to maintain a 971 network-wide target which is described in the autonomic Intent. 973 Reporting in an autonomic network may be at the same abstraction 974 level as Intent. In this context, the aggregated view of current 975 operational status of an autonomic network can be used to switch to 976 different management modes. Despite the fact that autonomic 977 management should minimize the need for user intervention, possibly 978 there are some events that need to be addressed by human 979 administrator actions. 981 7.4. Feedback Loops to NOC (*) 983 Feedback loops are required in an autonomic network to allow the 984 intervention of a human administrator or central control systems, 985 while maintaining a default behaviour. Through a feedback loop an 986 administrator must be prompted with a default action, and has the 987 possibility to acknowledge or override the proposed default action. 989 Uni-directional notifications to the NOC, that do not propose any 990 default action, and do not allow an override as part of the 991 transaction are considered like traditional notification services, 992 such as syslog. They are expected to co-exist with autonomic 993 methods, but are not covered in this draft. 995 7.5. Control Loops (*) 997 Control loops are not covered in the current implementation 998 specifications. This section discusses a topic for further research. 1000 Control loops are used in autonomic networking to provide a generic 1001 mechanism to enable the Autonomic System to adapt (on its own) to 1002 various factors that can change the goals that the autonomic network 1003 is trying to achieve, or how those goals are achieved. For example, 1004 as user needs, business goals, and the ANI itself changes, self- 1005 adaptation enables the ANI to change the services and resources it 1006 makes available to adapt to these changes. 1008 Control loops operate to continuously observe and collect data that 1009 enables the autonomic management system to understand changes to the 1010 behavior of the system being managed, and then provide actions to 1011 move the state of the system being managed toward a common goal. 1012 Self-adaptive systems move decision-making from static, pre-defined 1013 commands to dynamic processes computed at runtime. 1015 Most autonomic systems use a closed control loop with feedback. Such 1016 control loops should be able to be dynamically changed at runtime to 1017 adapt to changing user needs, business goals, and changes in the ANI. 1019 7.6. APIs (*) 1021 APIs are not covered in the current implementation specifications. 1022 This section discusses a topic for further research. 1024 Most APIs are static, meaning that they are pre-defined and represent 1025 an invariant mechanism for operating with data. An Autonomic Network 1026 should be able to use dynamic APIs in addition to static APIs. 1028 A dynamic API is one that retrieves data using a generic mechanism, 1029 and then enables the client to navigate the retrieved data and 1030 operate on it. Such APIs typically use introspection and/or 1031 reflection. Introspection enables software to examine the type and 1032 properties of an object at runtime, while reflection enables a 1033 program to manipulate the attributes, methods, and/or metadata of an 1034 object. 1036 APIs must be able to express and preserve the semantics of data 1037 models. For example, software contracts [Meyer97] are based on the 1038 principle that a software-intensive system, such as an Autonomic 1039 Network, is a set of communicating components whose interaction is 1040 based on precisely-defined specifications of the mutual obligations 1041 that interacting components must respect. This typically includes 1042 specifying: 1044 o pre-conditions that must be satisfied before the method can start 1045 execution 1047 o post-conditions that must be satisfied when the method has 1048 finished execution 1050 o invariant attributes that must not change during the execution of 1051 the method 1053 7.7. Data Model (*) 1055 Data models are not covered in the current implementation 1056 specifications. This section discusses a topic for further research. 1058 The following definitions are adapted from 1059 [I-D.ietf-supa-generic-policy-data-model]: 1061 An information model is a representation of concepts of interest to 1062 an environment in a form that is independent of data repository, data 1063 definition language, query language, implementation language, and 1064 protocol. In contrast, a data model is a representation of concepts 1065 of interest to an environment in a form that is dependent on data 1066 repository, data definition language, query language, implementation 1067 language, and protocol (typically, but not necessarily, all three). 1069 The utility of an information model is to define objects and their 1070 relationships in a technology-neutral manner. This forms a 1071 consensual vocabulary that the ANI and ASAs can use. A data model is 1072 then a technology-specific mapping of all or part of the information 1073 model to be used by all or part of the system. 1075 A system may have multiple data models. Operational Support Systems, 1076 for example, typically have multiple types of repositories, such as 1077 SQL and NoSQL, to take advantage of the different properties of each. 1078 If multiple data models are required by an Autonomic System, then an 1079 information model should be used to ensure that the concepts of each 1080 data model can be related to each other without technological bias. 1082 A data model is essential for certain types of functions, such as a 1083 Model-Reference Adaptive Control Loop (MRACL). More generally, a 1084 data model can be used to define the objects, attributes, methods, 1085 and relationships of a software system (e.g., the ANI, an autonomic 1086 node, or an ASA). A data model can be used to help design an API, as 1087 well as any language used to interface to the Autonomic Network. 1089 8. Coordination Between Autonomic Functions (*) 1091 Coordination between autonomic functions is not covered in the 1092 current implementation specifications. This section discusses a 1093 topic for further research. 1095 8.1. The Coordination Problem (*) 1097 Different autonomic functions may conflict in setting certain 1098 parameters. For example, an energy efficiency function may want to 1099 shut down a redundant link, while a load balancing function would not 1100 want that to happen. The administrator must be able to understand 1101 and resolve such interactions, to steer autonomic network performance 1102 to a given (intended) operational point. 1104 Several interaction types may exist among autonomic functions, for 1105 example: 1107 o Cooperation: An autonomic function can improve the behavior or 1108 performance of another autonomic function, such as a traffic 1109 forecasting function used by a traffic allocation function. 1111 o Dependency: An autonomic function cannot work without another one 1112 being present or accessible in the autonomic network. 1114 o Conflict: A metric value conflict is a conflict where one metric 1115 is influenced by parameters of different autonomic functions. A 1116 parameter value conflict is a conflict where one parameter is 1117 modified by different autonomic functions. 1119 Solving the coordination problem beyond one-by-one cases can rapidly 1120 become intractable for large networks. Specifying a common 1121 functional block on coordination is a first step to address the 1122 problem in a systemic way. The coordination life-cycle consists in 1123 three states: 1125 o At build-time, a "static interaction map" can be constructed on 1126 the relationship of functions and attributes. This map can be 1127 used to (pre-)define policies and priorities on identified 1128 conflicts. 1130 o At deploy-time, autonomic functions are not yet active/acting on 1131 the network. A "dynamic interaction map" is created for each 1132 instance of each autonomic functions and on a per resource basis, 1133 including the actions performed and their relationships. This map 1134 provides the basis to identify conflicts that will happen at run- 1135 time, categorize them and plan for the appropriate coordination 1136 strategies/mechanisms. 1138 o At run-time, when conflicts happen, arbitration is driven by the 1139 coordination strategies. Also new dependencies can be observed 1140 and inferred, resulting in an update of the dynamic interaction 1141 map and adaptation of the coordination strategies and mechanisms. 1143 Multiple coordination strategies and mechanisms exist and can be 1144 devised. The set ranges from basic approaches such as random process 1145 or token-based process, to approaches based on time separation and 1146 hierarchical optimization, to more complex approaches such as multi- 1147 objective optimization, and other control theory approaches and 1148 algorithms family. 1150 8.2. A Coordination Functional Block (*) 1152 A common coordination functional block is a desirable component of 1153 the ANIMA reference model. It provides a means to ensure network 1154 properties and predictable performance or behavior such as stability, 1155 and convergence, in the presence of several interacting autonomic 1156 functions. 1158 A common coordination function requires: 1160 o A common description of autonomic functions, their attributes and 1161 life-cycle. 1163 o A common representation of information and knowledge (e.g., 1164 interaction maps). 1166 o A common "control/command" interface between the coordination 1167 "agent" and the autonomic functions. 1169 Guidelines, recommendations or BCPs can also be provided for aspects 1170 pertaining to the coordination strategies and mechanisms. 1172 9. Security Considerations 1174 In this section we distinguish outsider and insider attacks. In an 1175 outsider attack all network elements and protocols are securely 1176 managed and operating, and an outside attacker can sniff packets in 1177 transit, inject and replay packets. In an insider attack, the 1178 attacker has access to an autonomic node or other means (e.g. remote 1179 code execution in the node by exploiting ACP-independent 1180 vulnerabilities in the node platform) to produce arbitrary payloads 1181 on the protected ACP channels. 1183 If a system has vulnerabilities in the implementation or operation 1184 (configuration), an outside attacker can exploit such vulnerabilies 1185 to become an insider attacker. 1187 9.1. Protection Against Outsider Attacks 1189 Here, we assume that all systems involved in an autonomic network are 1190 secured and operated according to best current practices. These 1191 protection methods comprise traditional security implementation and 1192 operation methods (such as code security, strong randomization 1193 algorithms, strong passwords, etc.) as well as mechanisms specific to 1194 an autonomic network (such as a secured MASA service). 1196 Traditional security methods for both implementation and operation 1197 are outside scope for this document. 1199 AN specific protocols and methods must also follow traditional 1200 security methods, in that all packets that can be sniffed or injected 1201 by an outside attacker are: 1203 o protected against modification. 1205 o authenticated. 1207 o protected against replay attacks. 1209 o confidentiality protected (encrypted). 1211 o and that the AN protocols are robust against packet drops and man- 1212 in-the-middle attacks. 1214 How these requirements are met is covered in the AN standards track 1215 documents that define the methods used, specifically 1216 [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], and 1217 [I-D.ietf-anima-autonomic-control-plane]. 1219 Most AN messages run inside the cryptographically protected ACP. The 1220 unprotected AN messages outside the ACP are limited to a simple 1221 discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]: 1222 The "Discovery Unsolicited Link-Local (DULL)" message, with detailed 1223 rules on its usage. 1225 If AN messages can be observed by a third party, they might reveal 1226 valuable information about network configuration, security 1227 precautions in use, individual users, and their traffic patterns. If 1228 encrypted, AN messages might still reveal some information via 1229 traffic analysis. 1231 9.2. Risk of Insider Attacks 1233 An autonomic network consists of autonomic devices that form a 1234 distributed self-managing system. Devices within a domain have 1235 credentials issued from a common trust anchor and can use them to 1236 create mutual trust. This means that any device inside a trust 1237 domain can by default use all distributed functions in the entire 1238 autonomic domain in a malicious way. 1240 If an autonomic node or protocol has vulnerabilities or is not 1241 securely operated, an outside attacker has the following generic ways 1242 to take control of an autonomic network: 1244 o Introducing a fake device into the trust domain, by subverting the 1245 authentication methods. This depends on the correct 1246 specification, implementation and operation of the AN protocols. 1248 o Subverting a device which is already part of a trust domain, and 1249 modifying its behavior. This threat is not specific to the 1250 solution discussed in this document, and applies to all network 1251 solutions. 1253 o Exploiting potentially yet unknown protocol vulnerabilities in the 1254 AN or other protocols. Also this is a generic threat that applies 1255 to all network solutions. 1257 The above threats are in principle comparable to other solutions: In 1258 the presence of design, implementation or operational errors, 1259 security is no longer guaranteed. However, the distributed nature of 1260 AN, specifically the Autonomic Control Plane, increases the threat 1261 surface significantly. For example, a compromised device may have 1262 full IP reachability to all other devices inside the ACP, and can use 1263 all AN methods and protocols. 1265 For the next phase of the ANIMA work it is therefore recommended to 1266 introduce a sub-domain security model, to reduce the attack surface 1267 and not expose a full domain to a potential intruder. Furthermore, 1268 additional security mechanisms on the ASA level should be considered 1269 for high-risk autonomic functions. 1271 10. IANA Considerations 1273 This document requests no action by IANA. 1275 11. Acknowledgements 1277 Many people have provided feedback and input to this document: Sheng 1278 Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur 1279 Hecker. Useful reviews were made by Joel Halpern, Radia Perlman, 1280 Tianran Zhou and Christian Hopps. 1282 12. Contributors 1284 Significant contributions to this document have been made by John 1285 Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia. 1287 13. References 1289 13.1. Normative References 1291 [I-D.ietf-anima-autonomic-control-plane] 1292 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1293 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1294 plane-18 (work in progress), August 2018. 1296 [I-D.ietf-anima-bootstrapping-keyinfra] 1297 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1298 S., and K. Watsen, "Bootstrapping Remote Secure Key 1299 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1300 keyinfra-16 (work in progress), June 2018. 1302 [I-D.ietf-anima-grasp] 1303 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1304 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1305 grasp-15 (work in progress), July 2017. 1307 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 1308 December 2009, . 1311 13.2. Informative References 1313 [I-D.carpenter-anima-asa-guidelines] 1314 Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre, 1315 "Guidelines for Autonomic Service Agents", draft- 1316 carpenter-anima-asa-guidelines-05 (work in progress), June 1317 2018. 1319 [I-D.du-anima-an-intent] 1320 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 1321 Behringer, "ANIMA Intent Policy and Format", draft-du- 1322 anima-an-intent-05 (work in progress), February 2017. 1324 [I-D.ietf-anima-grasp-api] 1325 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1326 Autonomic Signaling Protocol Application Program Interface 1327 (GRASP API)", draft-ietf-anima-grasp-api-02 (work in 1328 progress), June 2018. 1330 [I-D.ietf-anima-prefix-management] 1331 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 1332 IPv6 Edge Prefix Management in Large-scale Networks", 1333 draft-ietf-anima-prefix-management-07 (work in progress), 1334 December 2017. 1336 [I-D.ietf-anima-stable-connectivity] 1337 Eckert, T. and M. Behringer, "Using Autonomic Control 1338 Plane for Stable Connectivity of Network OAM", draft-ietf- 1339 anima-stable-connectivity-10 (work in progress), February 1340 2018. 1342 [I-D.ietf-supa-generic-policy-data-model] 1343 Halpern, J. and J. Strassner, "Generic Policy Data Model 1344 for Simplified Use of Policy Abstractions (SUPA)", draft- 1345 ietf-supa-generic-policy-data-model-04 (work in progress), 1346 June 2017. 1348 [I-D.liu-anima-grasp-distribution] 1349 Liu, B., Jiang, S., Xiao, X., Hecker, A., and Z. 1350 Despotovic, "Information Distribution in Autonomic 1351 Networking", draft-liu-anima-grasp-distribution-09 (work 1352 in progress), October 2018. 1354 [Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd 1355 edition)", Prentice-Hall, ISBN 978-0136291558, 1997. 1357 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1358 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1359 Networking: Definitions and Design Goals", RFC 7575, 1360 DOI 10.17487/RFC7575, June 2015, . 1363 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1364 Analysis for Autonomic Networking", RFC 7576, 1365 DOI 10.17487/RFC7576, June 2015, . 1368 Authors' Addresses 1370 Michael H. Behringer (editor) 1372 Email: Michael.H.Behringer@gmail.com 1374 Brian Carpenter 1375 Department of Computer Science 1376 University of Auckland 1377 PB 92019 1378 Auckland 1142 1379 New Zealand 1381 Email: brian.e.carpenter@gmail.com 1382 Toerless Eckert 1383 Futurewei Technologies Inc. 1384 2330 Central Expy 1385 Santa Clara 95050 1386 USA 1388 Email: tte@cs.fau.de 1390 Laurent Ciavaglia 1391 Nokia 1392 Villarceaux 1393 Nozay 91460 1394 FR 1396 Email: laurent.ciavaglia@nokia.com 1398 Jeferson Campos Nobre 1399 University of Vale do Rio dos Sinos 1400 Av. Unisinos, 950 1401 Sao Leopoldo 91501-970 1402 Brazil 1404 Email: jcnobre@unisinos.br