idnits 2.17.1 draft-ietf-anima-reference-model-07.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 (August 24, 2018) is 2072 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-06 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: February 25, 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 August 24, 2018 14 A Reference Model for Autonomic Networking 15 draft-ietf-anima-reference-model-07 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 https://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 February 25, 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 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. It can participate in further autonomic 422 transactions, such as starting autonomic service agents. For example 423 it must now enable the join assistant ASA, to help other devices to 424 join the domain. Other conditions may apply to such interactions, 425 for example to serve as a join assistant, the device must first 426 discover 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 Out of scope are addressing approaches for the data plane of the 476 network, which may be configured and managed in the traditional way, 477 or negotiated as a service of an ASA. One use case for such an 478 autonomic function is described in 479 [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 Nodes may support Autonomic 510 Service Agents in different virtual machines or containers. The 511 addressing scheme should support this architecture. 513 o Simplicity: To make engineering simpler, and to give the human 514 administrator an easy way to trouble-shoot autonomic functions. 516 o Scale: The proposed scheme should work in any network of any size. 518 o Upgradability: The scheme must be able to support different 519 addressing concepts in the future. 521 The proposed addressing scheme is described in the document "An 522 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). 524 4.3. Discovery 526 Traditionally, most of the information a node requires is provided 527 through configuration or northbound interfaces. An autonomic 528 function should rely on such northbound interfaces minimally or not 529 at all, and therefore it needs to discover peers and other resources 530 in the network. This section describes various discovery functions 531 in an autonomic network. 533 Discovering nodes and their properties and capabilities: A core 534 function to establish an autonomic domain is the mutual discovery of 535 autonomic nodes, primarily adjacent nodes and secondarily off-link 536 peers. This may in principle either leverage existing discovery 537 mechanisms, or use new mechanisms tailored to the autonomic context. 538 An important point is that discovery must work in a network with no 539 predefined topology, ideally no manual configuration of any kind, and 540 with nodes starting up from factory condition or after any form of 541 failure or sudden topology change. 543 Discovering services: Network services such as AAA should also be 544 discovered and not configured. Service discovery is required for 545 such tasks. An autonomic network can either leverage existing 546 service discovery functions, or use a new approach, or a mixture. 548 Thus the discovery mechanism could either be fully integrated with 549 autonomic signaling (next section) or could use an independent 550 discovery mechanism such as DNS Service Discovery or Service Location 551 Protocol. This choice could be made independently for each Autonomic 552 Service Agent, although the infrastructure might require some minimal 553 lowest common denominator (e.g., for discovering the security 554 bootstrap mechanism, or the source of information distribution, 555 Section 4.7). 557 Phase 1 of Autonomic Networking uses GRASP for discovery, described 558 in [I-D.ietf-anima-grasp]. 560 4.4. Signaling Between Autonomic Nodes 562 Autonomic nodes must communicate with each other, for example to 563 negotiate and/or synchronize technical objectives (i.e., network 564 parameters) of any kind and complexity. This requires some form of 565 signaling between autonomic nodes. Autonomic nodes implementing a 566 specific use case might choose their own signaling protocol, as long 567 as it fits the overall security model. However, in the general case, 568 any pair of autonomic nodes might need to communicate, so there needs 569 to be a generic protocol for this. A prerequisite for this is that 570 autonomic nodes can discover each other without any preconfiguration, 571 as mentioned above. To be generic, discovery and signaling must be 572 able to handle any sort of technical objective, including ones that 573 require complex data structures. The document "A Generic Autonomic 574 Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more 575 detailed requirements for discovery, negotiation and synchronization 576 in an autonomic network. It also defines a protocol, GRASP, for this 577 purpose, including an integrated but optional discovery protocol. 579 GRASP is normally expected to run inside the Autonomic Control Plane 580 (ACP; see Section 4.6) and to depend on the ACP for security. It may 581 run insecurely for a short time during bootstrapping. 583 An autonomic node will normally run a single instance of GRASP, used 584 by multiple ASAs. However, scenarios where multiple instances of 585 GRASP run in a single node, perhaps with different security 586 properties, are not excluded. 588 4.5. Routing 590 All autonomic nodes in a domain must be able to communicate with each 591 other, and later phases also with autonomic nodes outside their own 592 domain. Therefore, an Autonomic Control Plane relies on a routing 593 function. For Autonomic Networks to be interoperable, they must all 594 support one common routing protocol. 596 The routing protocol is defined in the ACP document 597 [I-D.ietf-anima-autonomic-control-plane]. 599 4.6. The Autonomic Control Plane 601 The "Autonomic Control Plane" carries the control protocols in an 602 autonomic network. This control plane can be either implemented in 603 the global routing table of a node, such as IGPs in today's networks; 604 or it can be provided as an overlay network. The document "An 605 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) 606 describes the implementation details suggested here. See 607 [I-D.ietf-anima-stable-connectivity] for uses cases for the ACP. 609 4.7. Information Distribution (*) 611 Certain forms of information require distribution across an autonomic 612 domain. The distribution of information runs inside the Autonomic 613 Control Plane. For example, Intent is distributed across an 614 autonomic domain, as explained in [RFC7575]. 616 Intent is the policy language of an Autonomic Network, see also 617 Section 7.2. It is a high level policy, and should change only 618 infrequently (order of days). Therefore, information such as Intent 619 should be simply flooded to all nodes in an autonomic domain, and 620 there is currently no perceived need to have more targeted 621 distribution methods. Intent is also expected to be monolithic, and 622 flooded as a whole. One possible method for distributing Intent, as 623 well as other forms of data, is discussed in 625 [I-D.liu-anima-grasp-distribution]. Intent and information 626 distribution are not part of phase 1 of ANIMA. 628 5. Security and Trust Infrastructure 630 An Autonomic Network is self-protecting. All protocols are secure by 631 default, without the requirement for the administrator to explicitly 632 configure security, with the exception of setting up a PKI 633 infrastructure. 635 Autonomic nodes have direct interactions between themselves, which 636 must be secured. Since an autonomic network does not rely on 637 configuration, it is not an option to configure, for example, pre- 638 shared keys. A trust infrastructure such as a PKI infrastructure 639 must be in place. This section describes the principles of this 640 trust infrastructure. 642 The default method to automatically bring up a trust infrastructure 643 is defined in the document "Bootstrapping Key Infrastructures" 644 [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this 645 enrollment process are described in Section 6.3. An autonomic node 646 must implement the enrollment and join assistant ASAs. The registrar 647 ASA may be implemented only on a sub-set of nodes. 649 5.1. Public Key Infrastructure 651 An autonomic domain uses a PKI model. The root of trust is a 652 certification authority (CA). A registrar acts as a registration 653 authority (RA). 655 A minimum implementation of an autonomic domain contains one CA, one 656 Registrar, and network elements. 658 5.2. Domain Certificate 660 Each device in an autonomic domain uses a domain certificate (LDevID) 661 to prove its identity. A new device uses its manufacturer provided 662 certificate (IDevID) during bootstrap, to obtain a domain 663 certificate. [I-D.ietf-anima-bootstrapping-keyinfra] describes how a 664 new device receives a domain certificate, and the certificate format. 666 5.3. The MASA 668 The Manufacturer Authorized Signing Authority (MASA) is a trusted 669 service for bootstrapping devices. The purpose of the MASA is to 670 provide ownership tracking of devices in a domain. The MASA provides 671 audit, authorization, and ownership tokens to the registrar during 672 the bootstrap process to assist in the authentication of devices 673 attempting to join an Autonomic Domain, and to allow a joining device 674 to validate whether it is joining the correct domain. The details 675 for MASA service, security, and usage are defined in 676 [I-D.ietf-anima-bootstrapping-keyinfra]. 678 5.4. Sub-Domains (*) 680 By default, sub-domains are treated as different domains. This 681 implies no trust between a domain and its sub-domains, and no trust 682 between sub-domains of the same domain. Specifically, no ACP is 683 built, and Intent is valid only for the domain it is defined for 684 explicitly. 686 In phase 2 of ANIMA, alternative trust models should be defined, for 687 example to allow full or limited trust between domain and sub-domain. 689 5.5. Cross-Domain Functionality (*) 691 By default, different domains do not interoperate, no ACP is built 692 and no trust is implied between them. 694 In the future, models can be established where other domains can be 695 trusted in full or for limited operations between the domains. 697 6. Autonomic Service Agents (ASA) 699 This section describes how autonomic services run on top of the 700 Autonomic Networking Infrastructure. 702 6.1. General Description of an ASA 704 An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent 705 implemented on an autonomic node that implements an autonomic 706 function, either in part (in the case of a distributed function) or 707 whole." Thus it is a process that makes use of the features provided 708 by the ANI to achieve its own goals, usually including interaction 709 with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or 710 otherwise. Of course it also interacts with the specific targets of 711 its function, using any suitable mechanism. Unless its function is 712 very simple, the ASA will need to handle overlapping asynchronous 713 operations. It may therefore be a quite complex piece of software in 714 its own right, forming part of the application layer above the ANI. 715 ASA design guidelines are available in 716 [I-D.carpenter-anima-asa-guidelines]. 718 Thus we can distinguish at least three classes of ASAs: 720 o Simple ASAs with a small footprint that could run anywhere. 722 o Complex, possibly multi-threaded ASAs that have a significant 723 resource requirement and will only run on selected nodes. 725 o A few 'infrastructure ASAs' that use basic ANI features in support 726 of the ANI itself, which must run in all autonomic nodes. These 727 are outlined in the following sections. 729 Autonomic nodes, and therefore their ASAs, know their own 730 capabilities and restrictions, derived from hardware, firmware or 731 pre-installed software: They are "self-aware". 733 The role of an autonomic node depends on Intent and on the 734 surrounding network behaviors, which may include forwarding 735 behaviors, aggregation properties, topology location, bandwidth, 736 tunnel or translation properties, etc. For example, a node may 737 decide to act as a backup node for a neighbor, if its capabilities 738 allow it to do so. 740 Following an initial discovery phase, the device properties and those 741 of its neighbors are the foundation of the behavior of a specific 742 device. A device and its ASAs have no pre-configuration for the 743 particular network in which they are installed. 745 Since all ASAs will interact with the ANI, they will depend on 746 appropriate application programming interfaces (APIs). It is 747 desirable that ASAs are portable between operating systems, so these 748 APIs need to be universal. An API for GRASP is described in 749 [I-D.ietf-anima-grasp-api]. 751 ASAs will in general be designed and coded by experts in a particular 752 technology and use case, not by experts in the ANI and its 753 components. Also, they may be coded in a variety of programming 754 languages, in particular including languages that support object 755 constructs as well as traditional variables and structures. The APIs 756 should be designed with these factors in mind. 758 It must be possible to run ASAs as non-privileged (user space) 759 processes except for those (such as the infrastructure ASAs) that 760 necessarily require kernel privilege. Also, it is highly desirable 761 that ASAs can be dynamically loaded on a running node. 763 Since autonomic systems must be self-repairing, it is of great 764 importance that ASAs are coded using robust programming techniques. 765 All run-time error conditions must be caught, leading to suitable 766 recovery actions, with a complete restart of the ASA as a last 767 resort. Conditions such as discovery failures or negotiation 768 failures must be treated as routine, with the ASA retrying the failed 769 operation, preferably with an exponential back-off in the case of 770 persistent errors. When multiple threads are started within an ASA, 771 these threads must be monitored for failures and hangups, and 772 appropriate action taken. Attention must be given to garbage 773 collection, so that ASAs never run out of resources. There is 774 assumed to be no human operator - again, in the worst case, every ASA 775 must be capable of restarting itself. 777 ASAs will automatically benefit from the security provided by the 778 ANI, and specifically by the ACP and by GRASP. However, beyond that, 779 they are responsible for their own security, especially when 780 communicating with the specific targets of their function. 781 Therefore, the design of an ASA must include a security analysis 782 beyond 'use ANI security.' 784 6.2. ASA Life-Cycle Management 786 ASAs operating on a given ANI may come from different providers and 787 pursue different objectives. Management of ASAs and its interactions 788 with the ANI should follow the same operating principles, hence 789 comply to a generic life-cycle management model. 791 The ASA life-cycle provides standard processes to: 793 o install ASA: copy the ASA code onto the host and start it, 795 o deploy ASA: associate the ASA instance with a (some) managed 796 network device(s) (or network function), 798 o control ASA execution: when and how an ASA executes its control 799 loop. 801 The life-cyle will cover the sequential states below: Installation, 802 Deployment, Operation and the transitional states in-between. This 803 Life-Cycle will also define which interactions ASAs have with the ANI 804 in between the different states. The noticeable interactions are: 806 o Self-description of ASA instances at the end of deployment: its 807 format needs to define the information required for the management 808 of ASAs by ANI entities 810 o Control of ASA control-loop during the operation: a signaling has 811 to carry formatted messages to control ASA execution (at least 812 starting and stopping the control loop) 814 6.3. Specific ASAs for the Autonomic Network Infrastructure 816 The following functions provide essential, required functionality in 817 an autonomic network, and are therefore mandatory to implement on 818 unconstrained autonomic nodes. They are described here as ASAs that 819 include the underlying infrastructure components, but implementation 820 details might vary. 822 The first three together support the trust enrollment process 823 described in Section 5. For details see 824 [I-D.ietf-anima-bootstrapping-keyinfra]. 826 6.3.1. The enrollment ASAs 828 6.3.1.1. The Pledge ASA 830 This ASA includes the function of an autonomic node that bootstraps 831 into the domain with the help of an join assitant ASA (see below). 832 Such a node is known as a Pledge during the enrollment process. This 833 ASA must be installed by default on all nodes that require an 834 autonomic zero-touch bootstrap. 836 6.3.1.2. The Join Assistant ASA 838 This ASA includes the function of an autonomic node that helps a non- 839 enrolled, adjacent devices to enroll into the domain. This ASA must 840 be installed on all nodes, although only one join assistant needs to 841 be active on a given LAN. See also 842 [I-D.ietf-anima-bootstrapping-keyinfra]. 844 6.3.1.3. The Join Registrar ASA 846 This ASA includes the join registrar function in an autonomic 847 network. This ASA does not need to be installed on all nodes, but 848 only on nodes that implement the Join Registrar function. 850 6.3.2. The ACP ASA 852 This ASA includes the ACP function in an autonomic network. In 853 particular it acts to discover other potential ACP nodes, and to 854 support the establishment and teardown of ACP channels. This ASA 855 must be installed on all nodes. For details see Section 4.6 and 856 [I-D.ietf-anima-autonomic-control-plane]. 858 6.3.3. The Information Distribution ASA (*) 860 This ASA is currently out of scope in ANIMA, and provided here only 861 as background information. 863 This ASA includes the information distribution function in an 864 autonomic network. In particular it acts to announce the 865 availability of Intent and other information to all other autonomic 866 nodes. This ASA does not need to be installed on all nodes, but only 867 on nodes that implement the information distribution function. For 868 details see Section 4.7. 870 Note that information distribution can be implemented as a function 871 in any ASA. See [I-D.liu-anima-grasp-distribution] for more details 872 on how information is suggested to be distributed. 874 7. Management and Programmability 876 This section describes how an Autonomic Network is managed, and 877 programmed. 879 7.1. Managing a (Partially) Autonomic Network 881 Autonomic management usually co-exists with traditional management 882 methods in most networks. Thus, autonomic behavior will be defined 883 for individual functions in most environments. Examples for overlap 884 are: 886 o Autonomic functions can use traditional methods and protocols 887 (e.g., SNMP and NETCONF) to perform management tasks, inside and 888 outside the ACP; 890 o Autonomic functions can conflict with behavior enforced by the 891 same traditional methods and protocols; 893 o Traditional functions can use the ACP, for example if reachability 894 on the data plane is not (yet) established. 896 The autonomic Intent is defined at a high level of abstraction. 897 However, since it is necessary to address individual managed 898 elements, autonomic management needs to communicate in lower-level 899 interactions (e.g., commands and requests). For example, it is 900 expected that the configuration of such elements be performed using 901 NETCONF and YANG modules as well as the monitoring be executed 902 through SNMP and MIBs. 904 Conflict can occur between autonomic default behavior, autonomic 905 Intent, traditional management methods. Conflict resolution is 906 achieved in autonomic management through prioritization [RFC7575]. 907 The rationale is that manual and node-based management have a higher 908 priority over autonomic management. Thus, the autonomic default 909 behavior has the lowest priority, then comes the autonomic Intent 910 (medium priority), and, finally, the highest priority is taken by 911 node-specific network management methods, such as the use of command 912 line interfaces. 914 7.2. Intent (*) 916 Intent is not covered in the current implementation specifications. 917 This section is for informational purposes, for following phases of 918 standardization. 920 This section gives an overview of Intent, and how it is managed. 921 Intent and Policy-Based Network Management (PBNM) is already 922 described inside the IETF (e.g., PCIM) and in other SDOs (e.g., DMTF 923 and TMF ZOOM). 925 Intent can be described as an abstract, declarative, high-level 926 policy used to operate an autonomic domain, such as an enterprise 927 network [RFC7575]. Intent should be limited to high level guidance 928 only, thus it does not directly define a policy for every network 929 element separately. 931 Intent can be refined to lower level policies using different 932 approaches. This is expected in order to adapt the Intent to the 933 capabilities of managed devices. Intent may contain role or function 934 information, which can be translated to specific nodes [RFC7575]. 935 One of the possible refinements of the Intent is using Event- 936 Condition-Action (ECA) rules. 938 Different parameters may be configured for Intent. These parameters 939 are usually provided by the human operator. Some of these parameters 940 can influence the behavior of specific autonomic functions as well as 941 the way the Intent is used to manage the autonomic domain. 943 Intent is discussed in more detail in [I-D.du-anima-an-intent]. 944 Intent as well as other types of information are distributed via 945 GRASP, see [I-D.liu-anima-grasp-distribution]. 947 7.3. Aggregated Reporting (*) 949 Aggregated reporting is not covered in the current implementation 950 specifications. This section is for informational purposes, for 951 following phases of standardization. 953 An Autonomic Network should minimize the need for human intervention. 954 In terms of how the network should behave, this is done through an 955 autonomic Intent provided by the human administrator. In an 956 analogous manner, the reports which describe the operational status 957 of the network should aggregate the information produced in different 958 network elements in order to present the effectiveness of autonomic 959 Intent enforcement. Therefore, reporting in an autonomic network 960 should happen on a network-wide basis [RFC7575]. 962 Multiple simultaneous events can occur in an autonomic network in the 963 same way they can happen in a traditional network. However, when 964 reporting to a human administrator, such events should be aggregated 965 to avoid notifications about individual managed elements. In this 966 context, algorithms may be used to determine what should be reported 967 (e.g., filtering) and in which way and how different events are 968 related to each other. Besides that, an event in an individual 969 element can be compensated by changes in other elements to maintain a 970 network-wide target which is described in the autonomic Intent. 972 Reporting in an autonomic network may be at the same abstraction 973 level as Intent. In this context, the aggregated view of current 974 operational status of an autonomic network can be used to switch to 975 different management modes. Despite the fact that autonomic 976 management should minimize the need for user intervention, possibly 977 there are some events that need to be addressed by human 978 administrator actions. 980 7.4. Feedback Loops to NOC (*) 982 Feedback loops are required in an autonomic network to allow the 983 intervention of a human administrator or central control systems, 984 while maintaining a default behaviour. Through a feedback loop an 985 administrator can be prompted with a default action, and has the 986 possibility to acknowledge or override the proposed default action. 988 7.5. Control Loops (*) 990 Control loops are not covered in the current implementation 991 specifications. This section is for informational purposes, for 992 following phases of standardization. 994 Control loops are used in autonomic networking to provide a generic 995 mechanism to enable the Autonomic System to adapt (on its own) to 996 various factors that can change the goals that the autonomic network 997 is trying to achieve, or how those goals are achieved. For example, 998 as user needs, business goals, and the ANI itself changes, self- 999 adaptation enables the ANI to change the services and resources it 1000 makes available to adapt to these changes. 1002 Control loops operate to continuously observe and collect data that 1003 enables the autonomic management system to understand changes to the 1004 behavior of the system being managed, and then provide actions to 1005 move the state of the system being managed toward a common goal. 1006 Self-adaptive systems move decision-making from static, pre-defined 1007 commands to dynamic processes computed at runtime. 1009 Most autonomic systems use a closed control loop with feedback. Such 1010 control loops should be able to be dynamically changed at runtime to 1011 adapt to changing user needs, business goals, and changes in the ANI. 1013 7.6. APIs (*) 1015 APIs are not covered in the current implementation specifications. 1016 This section is for informational purposes, for following phases of 1017 standardization. 1019 Most APIs are static, meaning that they are pre-defined and represent 1020 an invariant mechanism for operating with data. An Autonomic Network 1021 should be able to use dynamic APIs in addition to static APIs. 1023 A dynamic API is one that retrieves data using a generic mechanism, 1024 and then enables the client to navigate the retrieved data and 1025 operate on it. Such APIs typically use introspection and/or 1026 reflection. Introspection enables software to examine the type and 1027 properties of an object at runtime, while reflection enables a 1028 program to manipulate the attributes, methods, and/or metadata of an 1029 object. 1031 APIs must be able to express and preserve the semantics of data 1032 models. For example, software contracts [Meyer97] are based on the 1033 principle that a software-intensive system, such as an Autonomic 1034 Network, is a set of communicating components whose interaction is 1035 based on precisely-defined specifications of the mutual obligations 1036 that interacting components must respect. This typically includes 1037 specifying: 1039 o pre-conditions that must be satisfied before the method can start 1040 execution 1042 o post-conditions that must be satisfied when the method has 1043 finished execution 1045 o invariant attributes that must not change during the execution of 1046 the method 1048 7.7. Data Model (*) 1050 Data models are not covered in the current implementation 1051 specifications. This section is for informational purposes, for 1052 following phases of standardization. 1054 The following definitions are adapted from 1055 [I-D.ietf-supa-generic-policy-data-model]: 1057 An information model is a representation of concepts of interest to 1058 an environment in a form that is independent of data repository, data 1059 definition language, query language, implementation language, and 1060 protocol. In contrast, a data model is a representation of concepts 1061 of interest to an environment in a form that is dependent on data 1062 repository, data definition language, query language, implementation 1063 language, and protocol (typically, but not necessarily, all three). 1065 The utility of an information model is to define objects and their 1066 relationships in a technology-neutral manner. This forms a 1067 consensual vocabulary that the ANI and ASAs can use. A data model is 1068 then a technology-specific mapping of all or part of the information 1069 model to be used by all or part of the system. 1071 A system may have multiple data models. Operational Support Systems, 1072 for example, typically have multiple types of repositories, such as 1073 SQL and NoSQL, to take advantage of the different properties of each. 1074 If multiple data models are required by an Autonomic System, then an 1075 information model should be used to ensure that the concepts of each 1076 data model can be related to each other without technological bias. 1078 A data model is essential for certain types of functions, such as a 1079 Model-Reference Adaptive Control Loop (MRACL). More generally, a 1080 data model can be used to define the objects, attributes, methods, 1081 and relationships of a software system (e.g., the ANI, an autonomic 1082 node, or an ASA). A data model can be used to help design an API, as 1083 well as any language used to interface to the Autonomic Network. 1085 8. Coordination Between Autonomic Functions (*) 1087 Coordination between autonomic functions is not covered in the 1088 current implementation specifications. This section is for 1089 informational purposes, for following phases of standardization. 1091 8.1. The Coordination Problem (*) 1093 Different autonomic functions may conflict in setting certain 1094 parameters. For example, an energy efficiency function may want to 1095 shut down a redundant link, while a load balancing function would not 1096 want that to happen. The administrator must be able to understand 1097 and resolve such interactions, to steer autonomic network performance 1098 to a given (intended) operational point. 1100 Several interaction types may exist among autonomic functions, for 1101 example: 1103 o Cooperation: An autonomic function can improve the behavior or 1104 performance of another autonomic function, such as a traffic 1105 forecasting function used by a traffic allocation function. 1107 o Dependency: An autonomic function cannot work without another one 1108 being present or accessible in the autonomic network. 1110 o Conflict: A metric value conflict is a conflict where one metric 1111 is influenced by parameters of different autonomic functions. A 1112 parameter value conflict is a conflict where one parameter is 1113 modified by different autonomic functions. 1115 Solving the coordination problem beyond one-by-one cases can rapidly 1116 become intractable for large networks. Specifying a common 1117 functional block on coordination is a first step to address the 1118 problem in a systemic way. The coordination life-cycle consists in 1119 three states: 1121 o At build-time, a "static interaction map" can be constructed on 1122 the relationship of functions and attributes. This map can be 1123 used to (pre-)define policies and priorities on identified 1124 conflicts. 1126 o At deploy-time, autonomic functions are not yet active/acting on 1127 the network. A "dynamic interaction map" is created for each 1128 instance of each autonomic functions and on a per resource basis, 1129 including the actions performed and their relationships. This map 1130 provides the basis to identify conflicts that will happen at run- 1131 time, categorize them and plan for the appropriate coordination 1132 strategies/mechanisms. 1134 o At run-time, when conflicts happen, arbitration is driven by the 1135 coordination strategies. Also new dependencies can be observed 1136 and inferred, resulting in an update of the dynamic interaction 1137 map and adaptation of the coordination strategies and mechanisms. 1139 Multiple coordination strategies and mechanisms exist and can be 1140 devised. The set ranges from basic approaches such as random process 1141 or token-based process, to approaches based on time separation and 1142 hierarchical optimization, to more complex approaches such as multi- 1143 objective optimization, and other control theory approaches and 1144 algorithms family. 1146 8.2. A Coordination Functional Block (*) 1148 A common coordination functional block is a desirable component of 1149 the ANIMA reference model. It provides a means to ensure network 1150 properties and predictable performance or behavior such as stability, 1151 and convergence, in the presence of several interacting autonomic 1152 functions. 1154 A common coordination function requires: 1156 o A common description of autonomic functions, their attributes and 1157 life-cycle. 1159 o A common representation of information and knowledge (e.g., 1160 interaction maps). 1162 o A common "control/command" interface between the coordination 1163 "agent" and the autonomic functions. 1165 Guidelines, recommendations or BCPs can also be provided for aspects 1166 pertaining to the coordination strategies and mechanisms. 1168 9. Security Considerations 1170 In this section we distinguish outsider and insider attacks. In an 1171 outsider attack all network elements and protocols are securely 1172 managed and operating, and an outside attacker can sniff packets in 1173 transit, inject and replay packets. In an insider attack, the 1174 attacker has access to an autonomic node or other means (e.g. remote 1175 code execution in the node by exploiting ACP-independent 1176 vulnerabilities in the node platform) to produce arbitrary payloads 1177 on the protected ACP channels. 1179 If a system has vulnerabilities in the implementation or operation 1180 (configuration), an outside attacker can exploit such vulnerabilies 1181 to become an insider attacker. 1183 9.1. Protection Against Outsider Attacks 1185 Here, we assume that all systems involved in an autonomic network are 1186 secured and operated according to best current practices. These 1187 protection methods comprise traditional security implementation and 1188 operation methods (such as code security, strong randomization 1189 algorithms, strong passwords, etc.) as well as mechanisms specific to 1190 an autonomic network (such as a secured MASA service). 1192 Traditional security methods for both implementation and operation 1193 are outside scope for this document. 1195 AN specific protocols and methods must also follow traditional 1196 security methods, in that all packets that can be sniffed or injected 1197 by an outside attacker are: 1199 o protected against modification. 1201 o authenticated. 1203 o protected against replay attacks. 1205 o encrypted. 1207 o and that the AN protocols are robust against packet drops and man- 1208 in-the-middle attacks. 1210 How these requirements are met is covered in the AN standards track 1211 documents that define the methods used, specifically 1212 [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], and 1213 [I-D.ietf-anima-autonomic-control-plane]. 1215 Most AN messages run inside the cryptographically protected ACP. The 1216 unprotected AN messages outside the ACP are limited to a simple 1217 discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]: 1218 The "Discovery Unsolicited Link-Local (DULL)" message, with detailed 1219 rules on its usage. 1221 If AN messages can be observed by a third party, they might reveal 1222 valuable information about network configuration, security 1223 precautions in use, individual users, and their traffic patterns. If 1224 encrypted, AN messages might still reveal some information via 1225 traffic analysis, but this would be quite limited (for example, this 1226 would be highly unlikely to reveal any specific information about 1227 user traffic). 1229 9.2. Risk of Insider Attacks 1231 An autonomic network consists of autonomic devices that form a 1232 distributed self-managing system. Devices within a domain share a 1233 common trust anchor and thus implicitly trust each other. This means 1234 that any device inside a trust domain can by default use all 1235 distributed functions in the entire autonomic domain in a malicious 1236 way. 1238 If an autonomic node or protocol has vulnerabilities or is not 1239 securely operated, an outside attacker has the following generic ways 1240 to take control of an autonomic network: 1242 o Introducing a fake device into the trust domain, by subverting the 1243 authentication methods. This depends on the correct 1244 specification, implementation and operation of the AN protocols. 1246 o Subverting a device which is already part of a trust domain, and 1247 modifying its behavior. This threat is not specific to the 1248 solution discussed in this document, and applies to all network 1249 solutions. 1251 o Exploiting potentially yet unknown protocol vulnerabilities in the 1252 AN or other protocols. Also this is a generic threat that applies 1253 to all network solutions. 1255 The above threats are in principle comparable to other solutions: In 1256 the presence of design, implementation or operational errors, 1257 security is no longer guaranteed. However, the distributed nature of 1258 AN, specifically the Autonomic Control Plane, increases the threat 1259 surface significantly. For example, a compromised device may have 1260 full IP reachability to all other devices inside the ACP, and can use 1261 all AN methods and protocols. 1263 For the next phase of the ANIMA work it is therefore recommended to 1264 introduce a sub-domain security model, to reduce the attack surface 1265 and not expose a full domain to a potential intruder. Furthermore, 1266 additional security mechanisms on the ASA level should be considered 1267 for high-risk autonomic functions. 1269 10. IANA Considerations 1271 This document requests no action by IANA. 1273 11. Acknowledgements 1275 Many people have provided feedback and input to this document: Sheng 1276 Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur 1277 Hecker. Useful reviews were made by Joel Halpern, Radia Perlman and 1278 Tianran Zhou. 1280 12. Contributors 1282 Significant contributions to this document have been made by John 1283 Strassner and Bing Liu from Huawei, and Pierre Peloso from Nokia. 1285 13. References 1287 13.1. Normative References 1289 [I-D.ietf-anima-autonomic-control-plane] 1290 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1291 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1292 plane-18 (work in progress), August 2018. 1294 [I-D.ietf-anima-bootstrapping-keyinfra] 1295 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1296 S., and K. Watsen, "Bootstrapping Remote Secure Key 1297 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1298 keyinfra-16 (work in progress), June 2018. 1300 [I-D.ietf-anima-grasp] 1301 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1302 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1303 grasp-15 (work in progress), July 2017. 1305 13.2. Informative References 1307 [I-D.carpenter-anima-asa-guidelines] 1308 Carpenter, B., Ciavaglia, L., Jiang, S., and P. Pierre, 1309 "Guidelines for Autonomic Service Agents", draft- 1310 carpenter-anima-asa-guidelines-05 (work in progress), June 1311 2018. 1313 [I-D.du-anima-an-intent] 1314 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 1315 Behringer, "ANIMA Intent Policy and Format", draft-du- 1316 anima-an-intent-05 (work in progress), February 2017. 1318 [I-D.ietf-anima-grasp-api] 1319 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1320 Autonomic Signaling Protocol Application Program Interface 1321 (GRASP API)", draft-ietf-anima-grasp-api-02 (work in 1322 progress), June 2018. 1324 [I-D.ietf-anima-prefix-management] 1325 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 1326 IPv6 Edge Prefix Management in Large-scale Networks", 1327 draft-ietf-anima-prefix-management-07 (work in progress), 1328 December 2017. 1330 [I-D.ietf-anima-stable-connectivity] 1331 Eckert, T. and M. Behringer, "Using Autonomic Control 1332 Plane for Stable Connectivity of Network OAM", draft-ietf- 1333 anima-stable-connectivity-10 (work in progress), February 1334 2018. 1336 [I-D.ietf-supa-generic-policy-data-model] 1337 Halpern, J. and J. Strassner, "Generic Policy Data Model 1338 for Simplified Use of Policy Abstractions (SUPA)", draft- 1339 ietf-supa-generic-policy-data-model-04 (work in progress), 1340 June 2017. 1342 [I-D.liu-anima-grasp-distribution] 1343 Liu, B., Jiang, S., Xiao, X., Hecker, A., and Z. 1344 Despotovic, "Information Distribution in Autonomic 1345 Networking", draft-liu-anima-grasp-distribution-06 (work 1346 in progress), July 2018. 1348 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 1349 December 2009, . 1352 [Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd 1353 edition)", Prentice-Hall, ISBN 978-0136291558, 1997. 1355 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1356 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1357 Networking: Definitions and Design Goals", RFC 7575, 1358 DOI 10.17487/RFC7575, June 2015, 1359 . 1361 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1362 Analysis for Autonomic Networking", RFC 7576, 1363 DOI 10.17487/RFC7576, June 2015, 1364 . 1366 Authors' Addresses 1368 Michael H. Behringer (editor) 1370 Email: Michael.H.Behringer@gmail.com 1371 Brian Carpenter 1372 Department of Computer Science 1373 University of Auckland 1374 PB 92019 1375 Auckland 1142 1376 New Zealand 1378 Email: brian.e.carpenter@gmail.com 1380 Toerless Eckert 1381 Futurewei Technologies Inc. 1382 2330 Central Expy 1383 Santa Clara 95050 1384 USA 1386 Email: tte@cs.fau.de 1388 Laurent Ciavaglia 1389 Nokia 1390 Villarceaux 1391 Nozay 91460 1392 FR 1394 Email: laurent.ciavaglia@nokia.com 1396 Jeferson Campos Nobre 1397 University of Vale do Rio dos Sinos 1398 Av. Unisinos, 950 1399 Sao Leopoldo 91501-970 1400 Brazil 1402 Email: jcnobre@unisinos.br