idnits 2.17.1 draft-ietf-anima-reference-model-05.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 (October 19, 2017) is 2382 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-10 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-07) exists of draft-ietf-anima-prefix-management-05 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-05 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-04 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: April 22, 2018 Univ. of Auckland 6 T. Eckert 7 Futurewei Technologies Inc. 8 L. Ciavaglia 9 P. Peloso 10 Nokia 11 B. Liu 12 Huawei Technologies 13 J. Nobre 14 Federal University of Rio Grande do Sul 15 J. Strassner 16 Huawei Technologies 17 October 19, 2017 19 A Reference Model for Autonomic Networking 20 draft-ietf-anima-reference-model-05 22 Abstract 24 This document describes a reference model for Autonomic Networking. 25 The goal is to define how the various elements in an autonomic 26 context work together, to describe their interfaces and relations. 27 While the document is written as generally as possible, the initial 28 solutions are limited to the chartered scope of the WG. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 22, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 4 66 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 5 67 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5 68 3.2. The Adjacency Table . . . . . . . . . . . . . . . . . . . 6 69 3.3. State Machine . . . . . . . . . . . . . . . . . . . . . . 8 70 3.3.1. State 1: Factory Default . . . . . . . . . . . . . . 8 71 3.3.2. State 2: Enrolled . . . . . . . . . . . . . . . . . . 8 72 3.3.3. State 3: In ACP . . . . . . . . . . . . . . . . . . . 9 73 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 9 74 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 10 76 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 77 4.4. Signaling Between Autonomic Nodes . . . . . . . . . . . . 12 78 4.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.6. The Autonomic Control Plane . . . . . . . . . . . . . . . 12 80 4.7. Information Distribution (*) . . . . . . . . . . . . . . 13 81 5. Security and Trust Infrastructure . . . . . . . . . . . . . . 13 82 5.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 13 83 5.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 14 84 5.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.4. Sub-Domains (*) . . . . . . . . . . . . . . . . . . . . . 14 86 5.5. Cross-Domain Functionality (*) . . . . . . . . . . . . . 14 87 6. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 14 88 6.1. General Description of an ASA . . . . . . . . . . . . . . 14 89 6.2. ASA Life-Cycle Management . . . . . . . . . . . . . . . . 16 90 6.3. Specific ASAs for the Autonomic Network Infrastructure . 17 91 6.3.1. The enrollment ASAs . . . . . . . . . . . . . . . . . 17 92 6.3.2. The ACP ASA . . . . . . . . . . . . . . . . . . . . . 17 93 6.3.3. The Information Distribution ASA (*) . . . . . . . . 18 94 7. Management and Programmability . . . . . . . . . . . . . . . 18 95 7.1. Managing a (Partially) Autonomic Network . . . . . . . . 18 96 7.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 19 97 7.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 19 98 7.4. Feedback Loops to NOC(*) . . . . . . . . . . . . . . . . 20 99 7.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 20 100 7.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 21 101 7.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 21 102 8. Coordination Between Autonomic Functions (*) . . . . . . . . 22 103 8.1. The Coordination Problem (*) . . . . . . . . . . . . . . 22 104 8.2. A Coordination Functional Block (*) . . . . . . . . . . . 23 105 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 106 9.1. Protection Against Outsider Attacks . . . . . . . . . . . 24 107 9.2. Risk of Insider Attacks . . . . . . . . . . . . . . . . . 25 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 109 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 26 112 12.2. Informative References . . . . . . . . . . . . . . . . . 27 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 115 1. Introduction 117 The document "Autonomic Networking - Definitions and Design Goals" 118 [RFC7575] explains the fundamental concepts behind Autonomic 119 Networking, and defines the relevant terms in this space, as well as 120 a high level reference model. [RFC7576] provides a gap analysis 121 between traditional and autonomic approaches. 123 This document defines this reference model with more detail, to allow 124 for functional and protocol specifications to be developed in an 125 architecturally consistent, non-overlapping manner. While the 126 document is written as generally as possible, the initial solutions 127 are limited to the chartered scope of the WG. 129 As discussed in [RFC7575], the goal of this work is not to focus 130 exclusively on fully autonomic nodes or networks. In reality, most 131 networks will run with some autonomic functions, while the rest of 132 the network is traditionally managed. This reference model allows 133 for this hybrid approach. 135 This document describes phase 1 of an Autonomic Networking solution, 136 and covers primarily the WG items of the ANIMA WG as of July 2017. 137 Sections marked with (*) do not represent chartered items at this 138 time. New WG items will require an update to this document, or 139 potentially a new document. 141 2. The Network View 143 This section describes the various elements in a network with 144 autonomic functions, and how these entities work together, on a high 145 level. Subsequent sections explain the detailed inside view for each 146 of the autonomic network elements, as well as the network functions 147 (or interfaces) between those elements. 149 Figure 1 shows the high level view of an Autonomic Network. It 150 consists of a number of autonomic nodes, which interact directly with 151 each other. Those autonomic nodes provide a common set of 152 capabilities across the network, called the "Autonomic Networking 153 Infrastructure" (ANI). The ANI provides functions like naming, 154 addressing, negotiation, synchronization, discovery and messaging. 156 Autonomic functions typically span several, possibly all nodes in the 157 network. The atomic entities of an autonomic function are called the 158 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 160 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 161 : : Autonomic Function 1 : : 162 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 163 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 164 : : : 165 : +- - - - - - - - - - - - - - + : 166 : : Autonomic Function 2 : : 167 : : ASA 2 : ASA 2 : : 168 : +- - - - - - - - - - - - - - + : 169 : : : 170 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 171 : Autonomic Networking Infrastructure : 172 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 173 +--------+ : +--------+ : +--------+ : +--------+ 174 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 175 +--------+ : +--------+ : +--------+ : +--------+ 177 Figure 1: High level view of an Autonomic Network 179 In a horizontal view, autonomic functions span across the network, as 180 well as the Autonomic Networking Infrastructure. In a vertical view, 181 a node always implements the ANI, plus it may have one or several 182 Autonomic Service Agents. 184 The Autonomic Networking Infrastructure (ANI) therefore is the 185 foundation for autonomic functions. The current charter of the ANIMA 186 WG is to specify the ANI, using a few autonomic functions as use 187 cases. 189 3. The Autonomic Network Element 191 3.1. Architecture 193 This section describes an autonomic network element and its internal 194 architecture. The reference model explained in the document 195 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 196 the sources of information that an autonomic service agent can 197 leverage: Self-knowledge, network knowledge (through discovery), 198 Intent, and feedback loops. There are two levels inside an autonomic 199 node: the level of Autonomic Service Agents, and the level of the 200 Autonomic Networking Infrastructure, with the former using the 201 services of the latter. Figure 2 illustrates this concept. 203 +------------------------------------------------------------+ 204 | | 205 | +-----------+ +------------+ +------------+ | 206 | | Autonomic | | Autonomic | | Autonomic | | 207 | | Service | | Service | | Service | | 208 | | Agent 1 | | Agent 2 | | Agent 3 | | 209 | +-----------+ +------------+ +------------+ | 210 | ^ ^ ^ | 211 | - - | - - API level - -| - - - - - - - |- - - | 212 | V V V | 213 |------------------------------------------------------------| 214 | Autonomic Networking Infrastructure | 215 | - Data structures (ex: certificates, peer information) | 216 | - Autonomic Control Plane (ACP) | 217 | - Autonomic Node Addressing | 218 | Discovery, negotiation and synchronisation functions | 219 | - Distribution of Intent and other information | 220 | - Aggregated reporting and feedback loops | 221 | - Routing | 222 |------------------------------------------------------------| 223 | Basic Operating System Functions | 224 +------------------------------------------------------------+ 226 Figure 2: Model of an autonomic node 228 The Autonomic Networking Infrastructure (lower part of Figure 2) 229 contains node specific data structures, for example trust information 230 about itself and its peers, as well as a generic set of functions, 231 independent of a particular usage. This infrastructure should be 232 generic, and support a variety of Autonomic Service Agents (upper 233 part of Figure 2). The Autonomic Control Plane (ACP) is the summary 234 of all interactions of the Autonomic Networking Infrastructure with 235 other nodes and services. 237 The use cases of "Autonomics" such as self-management, self- 238 optimisation, etc, are implemented as Autonomic Service Agents. They 239 use the services and data structures of the underlying Autonomic 240 Networking Infrastructure, which should be self-managing. 242 The "Basic Operating System Functions" include the "normal OS", 243 including the network stack, security functions, etc. 245 Full AN nodes have the full Autonomic Networking Infrastructure, with 246 the full functionality described in this document. At a later stage 247 ANIMA may define a scope for constrained nodes with a reduced ANI and 248 well-defined minimal functionality. They are currently out of scope. 250 3.2. The Adjacency Table 252 Autonomic Networking is based on direct interactions between devices 253 of a domain. The Autonomic Networking Infrastructure (ANI) is 254 normally built on a hop-by-hop basis. Therefore, many interactions 255 in the ANI are based on the ANI adjacency table. There are 256 interactions that provide input into the adjacency table, and other 257 interactions that leverage the information contained in it. 259 The ANI adjacency table contains information about adjacent autonomic 260 nodes, at a minimum: node-ID, IP address in data plane, IP address in 261 ACP, domain, certificate. An autonomic node maintains this adjacency 262 table up to date. The adjacency table only contains information 263 about other nodes that are capable of Autonomic Networking; non- 264 autonomic nodes are normally not tracked here. However, the 265 information is tracked independently of the status of the peer nodes; 266 specifically, it contains information about non-enrolled nodes, nodes 267 of the same and other domains. The adjacency table may contain 268 information about the validity and trust of the adjacent autonomic 269 node's certificate, although all autonomic interactions must verify 270 validity and trust independently. 272 The adjacency table is fed by the following inputs: 274 o Link local discovery: This interaction happens in the data plane, 275 using IPv6 link local addressing only, because this addressing 276 type is itself autonomic. This way the nodes learns about all 277 autonomic nodes around itself. This is described in 278 [I-D.ietf-anima-grasp]. 280 o Vendor re-direct: A new device may receive information on where 281 its home network is through a vendor based MASA re-direct; this is 282 typically a routable address. See 283 [I-D.ietf-anima-bootstrapping-keyinfra]. 285 o Non-autonomic input: A node may be configured manually with an 286 autonomic peer; it could learn about autonomic nodes through DHCP 287 options, DNS, and other non-autonomic mechanisms. Generally such 288 non-autonomic mechansims require some administrator intervention. 289 The key purpose is to by-pass a non-autonomic device or network. 290 As this pertains to new devices, it is covered in Appendix A and B 291 of [I-D.ietf-anima-bootstrapping-keyinfra]. 293 The adjacency table is defining the behaviour of an autonomic node: 295 o If the node has not bootstrapped into a domain (i.e., doesn't have 296 a domain certificate), it rotates through all nodes in the 297 adjacency table that claim to have a domain, and will attempt 298 bootstrapping through them, one by one. One possible response is 299 a vendor MASA re-direct, which will be entered into the adjacency 300 table (see second bullet above). See 301 [I-D.ietf-anima-bootstrapping-keyinfra]. 303 o If the adjacent node has the same domain, it will authenticate 304 that adjacent node and, if successful, establish the Autonomic 305 Control Plane (ACP). See 306 [I-D.ietf-anima-autonomic-control-plane]. 308 o Once the node is part of the ACP of a domain, it will use GRASP 309 discovery [I-D.ietf-anima-grasp] to find Registrar(s) of its 310 domain and potentially other services. 312 o If the node is part of an ACP and has discovered via GRASP at 313 least one Registrar in its domain, it will start the "join 314 assistant" ASA, and act as a join assistant for neighboring nodes 315 that need to be bootstrapped. See 316 [I-D.ietf-anima-bootstrapping-keyinfra]. 318 o Other behaviours are possible, for example establishing the ACP 319 also with devices of a sub-domain, to other domains, etc. Those 320 will likely be controlled by Intent. They are outside scope for 321 the moment. Note that Intent is distributed through the ACP; 322 therefore, a node can only adapt Intent driven behaviour once it 323 has joined the ACP. At the moment, ANIMA does not consider 324 providing Intent outside the ACP; this can be considered later. 326 Once a node has joined the ACP, it will also learn the ACP addresses 327 of its adjacent nodes, and add them to the adjacency table, to allow 328 for communication inside the ACP. Further autonomic domain 329 interactions will now happen inside the ACP. At this moment, only 330 negotiation / synchronization via GRASP [I-D.ietf-anima-grasp] is 331 being defined. (Note that GRASP runs in the data plane, as an input 332 in building the adjacency table, as well as inside the ACP.) 333 Autonomic Functions consist of Autonomic Service Agents (ASAs). They 334 run logically above the AN Infrastructure, and may use the adjacency 335 table, the ACP, negotiation and synchronization through GRASP in the 336 ACP, Intent and other functions of the ANI. Since the ANI only 337 provides autonomic interactions within a domain, autonomic functions 338 can also use any other context on a node, specifically the global 339 data plane. 341 3.3. State Machine 343 Autonomic Networking applies during the full life-cycle of a node. 344 This section describes a state machine of an autonomic node, 345 throughout its life. 347 3.3.1. State 1: Factory Default 349 An autonomic node is leaving the factory in this state. In this 350 state, the node has no domain specific configuration, specifically no 351 LDevID, and could be used in any particular target network. It does 352 however have a vendor/manufacturer specific ID, the IDevID [IDevID]. 353 Nodes without IDevID cannot be autonomically and securely enrolled 354 into a domain; they require manual pre-staging, in which case the 355 pre-staging takes them directly to state 2. 357 Transitions: 359 o Bootstrap event: The device enrols into a domain; as part of this 360 process it receives a domain identity (LDevID). If enrollment is 361 successful, the next state is state 2. See 362 [I-D.ietf-anima-bootstrapping-keyinfra] Section 3 for details on 363 enrollment. 365 3.3.2. State 2: Enrolled 367 An autonomic node is in the state "enrolled" if it has a domain 368 identity (LDevID). It may have further configuration or state, for 369 example if it had been in state 3 before, but lost all its ACP 370 channels. The LDevID can only be removed from a device through a 371 factory reset, which also removes all other state from the device. 372 This ensures that a device has no stale domain specific state when 373 entering the "enrolled" state from state 1. 375 Transitions: 377 o Joining ACP: The device establishes an ACP channel to an adjacent 378 device. See [I-D.ietf-anima-autonomic-control-plane] for details. 379 Next state: 3. 381 o Factory reset: A factory reset removes all configuration and the 382 domain identity (LDevID) from the device. Next state: 1. 384 3.3.3. State 3: In ACP 386 In this state, the autonomic node has at least one ACP channel to 387 another device. It can participate in further autonomic 388 transactions, such as starting autonomic service agents. For example 389 it must now enable the join assistant ASA, to help other devices to 390 join the domain. Other conditions may apply to such interactions, 391 for example to serve as a join assistant, the device must first 392 discover a bootstrap Registrar. 394 Transitions: 396 o Leaving ACP: The device drops the last (or only) ACP channel to an 397 adjacent device. Next state: 2. 399 o Factory reset: A factory reset removes all configuration and the 400 domain identity (LDevID) from the device. Next state: 1. 402 4. The Autonomic Networking Infrastructure 404 The Autonomic Networking Infrastructure provides a layer of common 405 functionality across an Autonomic Network. It provides the 406 elementary functions and services, as well as extensions. An 407 Autonomic Function, comprising of Autonomic Service Agents on nodes, 408 uses the functions described in this section. 410 4.1. Naming 412 Inside a domain, each autonomic device should be assigned a unique 413 name. The naming scheme should be consistent within a domain. Names 414 are typically assigned by a Registrar at bootstrap time and 415 persistent over the lifetime of the device. All Registrars in a 416 domain must follow the same naming scheme. 418 In the absence of a domain specific naming scheme, a default naming 419 scheme should use the same logic as the addressing scheme discussed 420 in [I-D.ietf-anima-autonomic-control-plane]. The device name is then 421 composed of a Registrar ID (for example taking a MAC address of the 422 Registrar) and a device number. An example name would then look like 423 this: 425 0123-4567-89ab-0001 427 The first three fields are the MAC address, the fourth field is the 428 sequential number for the device. 430 4.2. Addressing 432 Autonomic Service Agents (ASAs) need to communicate with each other, 433 using the autonomic addressing of the Autonomic Networking 434 Infrastructure of the node they reside on. This section describes 435 the addressing approach of the Autonomic Networking Infrastructure, 436 used by ASAs. 438 Out of scope are addressing approaches for the data plane of the 439 network, which may be configured and managed in the traditional way, 440 or negotiated as a service of an ASA. One use case for such an 441 autonomic function is described in 442 [I-D.ietf-anima-prefix-management]. 444 Autonomic addressing is a function of the Autonomic Networking 445 Infrastructure (lower part of Figure 2), specifically the Autonomic 446 Control Plane. ASAs do not have their own addresses. They may use 447 either API calls, or the autonomic addressing scheme of the Autonomic 448 Networking Infrastructure. 450 An autonomic addressing scheme has the following requirements: 452 o Zero-touch for simple networks: Simple networks should have 453 complete self-management of addressing, and not require any 454 central address management, tools, or address planning. 456 o Low-touch for complex networks: If complex networks require 457 operator input for autonomic address management, it should be 458 limited to high level guidance only, expressed in Intent. 460 o Flexibility: The addressing scheme must be flexible enough for 461 nodes to be able to move around, for the network to grow, split 462 and merge. 464 o Robustness: It should be as hard as possible for an administrator 465 to negatively affect addressing (and thus connectivity) in the 466 autonomic context. 468 o Stability: The addressing scheme should be as stable as possible. 469 However, implementations need to be able to recover from 470 unexpected address changes. 472 o Support for virtualization: Autonomic Nodes may support Autonomic 473 Service Agents in different virtual machines or containers. The 474 addressing scheme should support this architecture. 476 o Simplicity: To make engineering simpler, and to give the human 477 administrator an easy way to trouble-shoot autonomic functions. 479 o Scale: The proposed scheme should work in any network of any size. 481 o Upgradability: The scheme must be able to support different 482 addressing concepts in the future. 484 The proposed addressing scheme is described in the document "An 485 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). 487 4.3. Discovery 489 Traditionally, most of the information a node requires is provided 490 through configuration or northbound interfaces. An autonomic 491 function should rely on such northbound interfaces minimally or not 492 at all, and therefore it needs to discover peers and other resources 493 in the network. This section describes various discovery functions 494 in an autonomic network. 496 Discovering nodes and their properties and capabilities: A core 497 function to establish an autonomic domain is the mutual discovery of 498 autonomic nodes, primarily adjacent nodes and secondarily off-link 499 peers. This may in principle either leverage existing discovery 500 mechanisms, or use new mechanisms tailored to the autonomic context. 501 An important point is that discovery must work in a network with no 502 predefined topology, ideally no manual configuration of any kind, and 503 with nodes starting up from factory condition or after any form of 504 failure or sudden topology change. 506 Discovering services: Network services such as AAA should also be 507 discovered and not configured. Service discovery is required for 508 such tasks. An autonomic network can either leverage existing 509 service discovery functions, or use a new approach, or a mixture. 511 Thus the discovery mechanism could either be fully integrated with 512 autonomic signaling (next section) or could use an independent 513 discovery mechanism such as DNS Service Discovery or Service Location 514 Protocol. This choice could be made independently for each Autonomic 515 Service Agent, although the infrastructure might require some minimal 516 lowest common denominator (e.g., for discovering the security 517 bootstrap mechanism, or the source of information distribution, 518 Section 4.7). 520 Phase 1 of Autonomic Networking uses GRASP for discovery, described 521 in [I-D.ietf-anima-grasp]. 523 4.4. Signaling Between Autonomic Nodes 525 Autonomic nodes must communicate with each other, for example to 526 negotiate and/or synchronize technical objectives (i.e., network 527 parameters) of any kind and complexity. This requires some form of 528 signaling between autonomic nodes. Autonomic nodes implementing a 529 specific use case might choose their own signaling protocol, as long 530 as it fits the overall security model. However, in the general case, 531 any pair of autonomic nodes might need to communicate, so there needs 532 to be a generic protocol for this. A prerequisite for this is that 533 autonomic nodes can discover each other without any preconfiguration, 534 as mentioned above. To be generic, discovery and signaling must be 535 able to handle any sort of technical objective, including ones that 536 require complex data structures. The document "A Generic Autonomic 537 Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more 538 detailed requirements for discovery, negotiation and synchronization 539 in an autonomic network. It also defines a protocol, GRASP, for this 540 purpose, including an integrated but optional discovery protocol. 542 GRASP is normally expected to run inside the Autonomic Control Plane 543 (ACP; see Section 4.6) and to depend on the ACP for security. It may 544 run insecurely for a short time during bootstrapping. 546 An autonomic node will normally run a single instance of GRASP, used 547 by multiple ASAs. However, scenarios where multiple instances of 548 GRASP run in a single node, perhaps with different security 549 properties, are not excluded. 551 4.5. Routing 553 All autonomic nodes in a domain must be able to communicate with each 554 other, and with autonomic nodes outside their own domain. Therefore, 555 an Autonomic Control Plane relies on a routing function. For 556 Autonomic Networks to be interoperable, they must all support one 557 common routing protocol. 559 The routing protocol is defined in the ACP document 560 [I-D.ietf-anima-autonomic-control-plane]. 562 4.6. The Autonomic Control Plane 564 The totality of autonomic interactions forms the "Autonomic Control 565 Plane". This control plane can be either implemented in the global 566 routing table of a node, such as IGPs in today's networks; or it can 567 be provided as an overlay network. The document "An Autonomic 568 Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes 569 the details. 571 4.7. Information Distribution (*) 573 Certain forms of information require distribution across an autonomic 574 domain. The distribution of information runs inside the Autonomic 575 Control Plane. For example, Intent is distributed across an 576 autonomic domain, as explained in [RFC7575]. 578 Intent is the policy language of an Autonomic Network, see also 579 Section 7.2. It is a high level policy, and should change only 580 infrequently (order of days). Therefore, information such as Intent 581 should be simply flooded to all nodes in an autonomic domain, and 582 there is currently no perceived need to have more targeted 583 distribution methods. Intent is also expected to be monolithic, and 584 flooded as a whole. One possible method for distributing Intent, as 585 well as other forms of data, is discussed in 586 [I-D.liu-anima-grasp-distribution]. Intent and information 587 distribution are not part of phase 1 of ANIMA. 589 5. Security and Trust Infrastructure 591 An Autonomic Network is self-protecting. All protocols are secure by 592 default, without the requirement for the administrator to explicitly 593 configure security. 595 Autonomic nodes have direct interactions between themselves, which 596 must be secured. Since an autonomic network does not rely on 597 configuration, it is not an option to configure for example pre- 598 shared keys. A trust infrastructure such as a PKI infrastructure 599 must be in place. This section describes the principles of this 600 trust infrastructure. 602 The default method to automatically bring up a trust infrastructure 603 is defined in the document "Bootstrapping Key Infrastructures" 604 [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this 605 enrollment process are described in Section 6.3. An autonomic node 606 must implement the enrollment and join assistant ASAs. The registrar 607 ASA may be implemented only on a sub-set of nodes. 609 5.1. Public Key Infrastructure 611 An autonomic domain uses a PKI model. The root of trust is a 612 certification authority (CA). A registrar acts as a registration 613 authority (RA). 615 A minimum implementation of an autonomic domain contains one CA, one 616 Registrar, and network elements. 618 5.2. Domain Certificate 620 Each device in an autonomic domain uses a domain certificate to prove 621 its identity. [I-D.ietf-anima-bootstrapping-keyinfra] describes how 622 a new device receives a domain certificate, and the certificate 623 format. 625 5.3. The MASA 627 The Manufacturer Authorized Signing Authority (MASA) is a trusted 628 service for bootstrapping devices. The purpose of the MASA is to 629 provide ownership tracking of devices in a domain. The MASA provides 630 audit, authorization, and ownership tokens to the registrar during 631 the bootstrap process to assist in the authentication of devices 632 attempting to join an Autonomic Domain, and to allow a joining device 633 to validate whether it is joining the correct domain. The details 634 for MASA service, security, and usage are defined in 635 [I-D.ietf-anima-bootstrapping-keyinfra]. 637 5.4. Sub-Domains (*) 639 By default, sub-domains are treated as different domains. This 640 implies no trust between a domain and its sub-domains, and no trust 641 between sub-domains of the same domain. Specifically, no ACP is 642 built, and Intent is valid only for the domain it is defined for 643 explicitly. 645 In phase 2 of ANIMA, alternative trust models should be defined, for 646 example to allow full or limited trust between domain and sub-domain. 648 5.5. Cross-Domain Functionality (*) 650 By default, different domains do not interoperate, no ACP is built 651 and no trust is implied between them. 653 In the future, models can be established where other domains can be 654 trusted in full or for limited operations between the domains. 656 6. Autonomic Service Agents (ASA) 658 This section describes how autonomic services run on top of the 659 Autonomic Networking Infrastructure. 661 6.1. General Description of an ASA 663 An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent 664 implemented on an autonomic node that implements an autonomic 665 function, either in part (in the case of a distributed function) or 666 whole." Thus it is a process that makes use of the features provided 667 by the ANI to achieve its own goals, usually including interaction 668 with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or 669 otherwise. Of course it also interacts with the specific targets of 670 its function, using any suitable mechanism. Unless its function is 671 very simple, the ASA will need to be multi-threaded so that it can 672 handle overlapping asynchronous operations. It may therefore be a 673 quite complex piece of software in its own right, forming part of the 674 application layer above the ANI. 676 Thus we can distinguish at least three classes of ASAs: 678 o Simple ASAs with a small footprint that could run anywhere. 680 o Complex, multi-threaded ASAs that have a significant resource 681 requirement and will only run on selected nodes. 683 o A few 'infrastructure ASAs' that use basic ANI features in support 684 of the ANI itself, which must run in all autonomic nodes. These 685 are outlined in the following sections. 687 Autonomic nodes, and therefore their ASAs, will be self-aware. Every 688 autonomic node will be loaded with various functions and ASAs and 689 will be aware of its own capabilities, typically decided by the 690 hardware, firmware or pre-installed software. Its exact role may 691 depend on Intent and on the surrounding network behaviors, which may 692 include forwarding behaviors, aggregation properties, topology 693 location, bandwidth, tunnel or translation properties, etc. The 694 surrounding topology will depend on the network planning. Following 695 an initial discovery phase, the device properties and those of its 696 neighbors are the foundation of the behavior of a specific device. A 697 device and its ASAs have no pre-configuration for the particular 698 network in which they are installed. 700 Since all ASAs will interact with the ANI, they will depend on 701 appropriate application programming interfaces (APIs). It is 702 desirable that ASAs are portable between operating systems, so these 703 APIs need to be universal. An API for GRASP is described in 704 [I-D.liu-anima-grasp-api]. 706 ASAs will in general be designed and coded by experts in a particular 707 technology and use case, not by experts in the ANI and its 708 components. Also, they may be coded in a variety of programming 709 languages, in particular including languages that support object 710 constructs as well as traditional variables and structures. The APIs 711 should be designed with these factors in mind. 713 It must be possible to run ASAs as non-privileged (user space) 714 processes except for those (such as the infrastructure ASAs) that 715 necessarily require kernel privilege. Also, it is highly desirable 716 that ASAs can be dynamically loaded on a running node. 718 Since autonomic systems must be self-repairing, it is of great 719 importance that ASAs are coded using robust programming techniques. 720 All run-time error conditions must be caught, leading to suitable 721 recovery actions, with a complete restart of the ASA as a last 722 resort. Conditions such as discovery failures or negotiation 723 failures must be treated as routine, with the ASA retrying the failed 724 operation, preferably with an exponential back-off in the case of 725 persistent errors. When multiple threads are started within an ASA, 726 these threads must be monitored for failures and hangups, and 727 appropriate action taken. Attention must be given to garbage 728 collection, so that ASAs never run out of resources. There is 729 assumed to be no human operator - again, in the worst case, every ASA 730 must be capable of restarting itself. 732 ASAs will automatically benefit from the security provided by the 733 ANI, and specifically by the ACP and by GRASP. However, beyond that, 734 they are responsible for their own security, especially when 735 communicating with the specific targets of their function. 736 Therefore, the design of an ASA must include a security analysis 737 beyond 'use ANI security.' 739 6.2. ASA Life-Cycle Management 741 ASAs operating on a given ANI may come from different providers and 742 pursue different objectives. Whichever the ASA, its management and 743 its interactions with the ANI must follow the same operating 744 principles, hence comply to a generic life-cycle management model. 746 The ASA life-cycle provides standard processes to: 748 o install ASA: copy the ASA code onto the host and start it, 750 o deploy ASA: associate the ASA instance with a (some) managed 751 network device(s) (or network function), 753 o control ASA execution: when and how an ASA executes its control 754 loop. 756 The life-cyle will cover the sequential states below: Installation, 757 Deployment, Operation and the transitional states in-between. This 758 Life-Cycle will also define which interactions ASAs have with the ANI 759 in between the different states. The noticeable interactions are: 761 o Self-description of ASA instances at the end of deployment: its 762 format needs to define the information required for the management 763 of ASAs by ANI entities 765 o Control of ASA control-loop during the operation: a signaling has 766 to carry formatted messages to control ASA execution (at least 767 starting and stopping control loop) 769 6.3. Specific ASAs for the Autonomic Network Infrastructure 771 The following functions provide essential, required functionality in 772 an autonomic network, and are therefore mandatory to implement on 773 unconstrained autonomic nodes. They are described here as ASAs that 774 include the underlying infrastructure components, but implementation 775 details might vary. 777 The first three together support the trust enrollment process 778 described in Section 5. For details see 779 [I-D.ietf-anima-bootstrapping-keyinfra]. 781 6.3.1. The enrollment ASAs 783 6.3.1.1. The Pledge ASA 785 This ASA includes the function of an autonomic node that bootstraps 786 into the domain with the help of an join assitant ASA (see below). 787 Such a node is known as a Pledge during the enrollment process. This 788 ASA must be installed by default on all nodes that require an 789 autonomic zero-touch bootstrap. 791 6.3.1.2. The Join Assistant ASA 793 This ASA includes the function of an autonomic node that helps a non- 794 enrolled, adjacent devices to enroll into the domain. This ASA must 795 be installed on all nodes, although only one join assistant needs to 796 be active on a given LAN. 798 6.3.1.3. The Join Registrar ASA 800 This ASA includes the join registrar function in an autonomic 801 network. This ASA does not need to be installed on all nodes, but 802 only on nodes that implement the Join Registrar function. 804 6.3.2. The ACP ASA 806 This ASA includes the ACP function in an autonomic network. In 807 particular it acts to discover other potential ACP nodes, and to 808 support the establishment and teardown of ACP channels. This ASA 809 must be installed on all nodes. For details see Section 4.6 and 810 [I-D.ietf-anima-autonomic-control-plane]. 812 6.3.3. The Information Distribution ASA (*) 814 This ASA is currently out of scope in ANIMA, and provided here only 815 as background information. 817 This ASA includes the information distribution function in an 818 autonomic network. In particular it acts to announce the 819 availability of Intent and other information to all other autonomic 820 nodes. This ASA does not need to be installed on all nodes, but only 821 on nodes that implement the information distribution function. For 822 details see Section 4.7. 824 Note that information distribution can be implemented as a function 825 in any ASA. See [I-D.liu-anima-grasp-distribution] for more details 826 on how information is suggested to be distributed. 828 7. Management and Programmability 830 This section describes how an Autonomic Network is managed, and 831 programmed. 833 7.1. Managing a (Partially) Autonomic Network 835 Autonomic management usually co-exists with traditional management 836 methods in most networks. Thus, autonomic behavior will be defined 837 for individual functions in most environments. Examples for overlap 838 are: 840 o Autonomic functions can use traditional methods and protocols 841 (e.g., SNMP and NETCONF) to perform management tasks, inside and 842 outside the ACP; 844 o Autonomic functions can conflict with behavior enforced by the 845 same traditional methods and protocols; 847 o Traditional functions can use the ACP, for example if reachability 848 on the data plane is not (yet) established. 850 The autonomic Intent is defined at a high level of abstraction. 851 However, since it is necessary to address individual managed 852 elements, autonomic management needs to communicate in lower-level 853 interactions (e.g., commands and requests). For example, it is 854 expected that the configuration of such elements be performed using 855 NETCONF and YANG modules as well as the monitoring be executed 856 through SNMP and MIBs. 858 Conflict can occur between autonomic default behavior, autonomic 859 Intent, traditional management methods. Conflict resolution is 860 achieved in autonomic management through prioritization [RFC7575]. 861 The rationale is that manual and node-based management have a higher 862 priority over autonomic management. Thus, the autonomic default 863 behavior has the lowest priority, then comes the autonomic Intent 864 (medium priority), and, finally, the highest priority is taken by 865 node-specific network management methods, such as the use of command 866 line interfaces. 868 7.2. Intent (*) 870 Intent is not covered by the ANIMA charter at the time of this 871 writing. This section is for informational purposes only. 873 This section gives an overview of Intent, and how it is managed. 874 Intent and Policy-Based Network Management (PBNM) is already 875 described inside the IETF (e.g., PCIM and SUPA) and in other SDOs 876 (e.g., DMTF and TMF ZOOM). 878 Intent can be described as an abstract, declarative, high-level 879 policy used to operate an autonomic domain, such as an enterprise 880 network [RFC7575]. Intent should be limited to high level guidance 881 only, thus it does not directly define a policy for every network 882 element separately. 884 Intent can be refined to lower level policies using different 885 approaches. This is expected in order to adapt the Intent to the 886 capabilities of managed devices. Intent may contain role or function 887 information, which can be translated to specific nodes [RFC7575]. 888 One of the possible refinements of the Intent is using Event- 889 Condition-Action (ECA) rules. 891 Different parameters may be configured for Intent. These parameters 892 are usually provided by the human operator. Some of these parameters 893 can influence the behavior of specific autonomic functions as well as 894 the way the Intent is used to manage the autonomic domain. 896 Intent is discussed in more detail in [I-D.du-anima-an-intent]. 897 Intent as well as other types of information are distributed via 898 GRASP, see [I-D.liu-anima-grasp-distribution]. 900 7.3. Aggregated Reporting (*) 902 At the time of this writing, aggregated reporting is not in the ANIMA 903 charter. This section is provided for information only. 905 Autonomic Network should minimize the need for human intervention. 906 In terms of how the network should behave, this is done through an 907 autonomic Intent provided by the human administrator. In an 908 analogous manner, the reports which describe the operational status 909 of the network should aggregate the information produced in different 910 network elements in order to present the effectiveness of autonomic 911 Intent enforcement. Therefore, reporting in an autonomic network 912 should happen on a network-wide basis [RFC7575]. 914 Several events can occur in an autonomic network in the same way they 915 can happen in a traditional network. However, when reporting to a 916 human administrator, such events should be aggregated to avoid 917 advertisement about individual managed elements. In this context, 918 algorithms may be used to determine what should be reported (e.g., 919 filtering) and in which way and how different events are related to 920 each other. Besides that, an event in an individual element can be 921 compensated by changes in other elements to maintain a network-wide 922 level which is described in the autonomic Intent. 924 Reporting in an autonomic network may be in the same abstraction 925 level of the Intent. In this context, the visibility on current 926 operational status of an autonomic network can be used to switch to 927 different management modes. Despite the fact that autonomic 928 management should minimize the need for user intervention, possibly 929 there are some events that need to be addressed by human 930 administrator actions. 932 7.4. Feedback Loops to NOC(*) 934 Feedback loops are required in an autonomic network to allow the 935 intervention of a human administrator or central control systems, 936 while maintaining a default behaviour. Through a feedback loop an 937 administrator can be prompted with a default action, and has the 938 possibility to acknowledge or override the proposed default action. 940 7.5. Control Loops (*) 942 Control loops are used in autonomic networking to provide a generic 943 mechanism to enable the Autonomic System to adapt (on its own) to 944 various factors that can change the goals that the autonomic network 945 is trying to achieve, or how those goals are achieved. For example, 946 as user needs, business goals, and the ANI itself changes, self- 947 adaptation enables the ANI to change the services and resources it 948 makes available to adapt to these changes. 950 Control loops operate to continuously observe and collect data that 951 enables the autonomic management system to understand changes to the 952 behavior of the system being managed, and then provide actions to 953 move the state of the system being managed toward a common goal. 954 Self-adaptive systems move decision-making from static, pre-defined 955 commands to dynamic processes computed at runtime. 957 Most autonomic systems use a closed control loop with feedback. Such 958 control loops should be able to be dynamically changed at runtime to 959 adapt to changing user needs, business goals, and changes in the ANI. 961 7.6. APIs (*) 963 Most APIs are static, meaning that they are pre-defined and represent 964 an invariant mechanism for operating with data. An Autonomic Network 965 should be able to use dynamic APIs in addition to static APIs. 967 A dynamic API is one that retrieves data using a generic mechanism, 968 and then enables the client to navigate the retrieved data and 969 operate on it. Such APIs typically use introspection and/or 970 reflection. Introspection enables software to examine the type and 971 properties of an object at runtime, while reflection enables a 972 program to manipulate the attributes, methods, and/or metadata of an 973 object. 975 APIs must be able to express and preserve the semantics of data 976 models. For example, software contracts [Meyer97] are based on the 977 principle that a software-intensive system, such as an Autonomic 978 Network, is a set of communicating components whose interaction is 979 based on precisely-defined specifications of the mutual obligations 980 that interacting components must respect. This typically includes 981 specifying: 983 o pre-conditions that must be satisfied before the method can start 984 execution 986 o post-conditions that must be satisfied when the method has 987 finished execution 989 o invariant attributes that must not change during the execution of 990 the method 992 7.7. Data Model (*) 994 The following definitions are adapted from 995 [I-D.ietf-supa-generic-policy-data-model]: 997 An information model is a representation of concepts of interest to 998 an environment in a form that is independent of data repository, data 999 definition language, query language, implementation language, and 1000 protocol. In contrast, a data model is a representation of concepts 1001 of interest to an environment in a form that is dependent on data 1002 repository, data definition language, query language, implementation 1003 language, and protocol (typically, but not necessarily, all three). 1005 The utility of an information model is to define objects and their 1006 relationships in a technology-neutral manner. This forms a 1007 consensual vocabulary that the ANI and ASAs can use. A data model is 1008 then a technology-specific mapping of all or part of the information 1009 model to be used by all or part of the system. 1011 A system may have multiple data models. Operational Support Systems, 1012 for example, typically have multiple types of repositories, such as 1013 SQL and NoSQL, to take advantage of the different properties of each. 1014 If multiple data models are required by an Autonomic System, then an 1015 information model should be used to ensure that the concepts of each 1016 data model can be related to each other without technological bias. 1018 A data model is essential for certain types of functions, such as a 1019 MRACL. More generally, a data model can be used to define the 1020 objects, attributes, methods, and relationships of a software system 1021 (e.g., the ANI, an autonomic node, or an ASA). A data model can be 1022 used to help design an API, as well as any language used to interface 1023 to the Autonomic Network. 1025 8. Coordination Between Autonomic Functions (*) 1027 8.1. The Coordination Problem (*) 1029 Different autonomic functions may conflict in setting certain 1030 parameters. For example, an energy efficiency function may want to 1031 shut down a redundant link, while a load balancing function would not 1032 want that to happen. The administrator must be able to understand 1033 and resolve such interactions, to steer autonomic network performance 1034 to a given (intended) operational point. 1036 Several interaction types may exist among autonomic functions, for 1037 example: 1039 o Cooperation: An autonomic function can improve the behavior or 1040 performance of another autonomic function, such as a traffic 1041 forecasting function used by a traffic allocation function. 1043 o Dependency: An autonomic function cannot work without another one 1044 being present or accessible in the autonomic network. 1046 o Conflict: A metric value conflict is a conflict where one metric 1047 is influenced by parameters of different autonomic functions. A 1048 parameter value conflict is a conflict where one parameter is 1049 modified by different autonomic functions. 1051 Solving the coordination problem beyond one-by-one cases can rapidly 1052 become intractable for large networks. Specifying a common 1053 functional block on coordination is a first step to address the 1054 problem in a systemic way. The coordination life-cycle consists in 1055 three states: 1057 o At build-time, a "static interaction map" can be constructed on 1058 the relationship of functions and attributes. This map can be 1059 used to (pre-)define policies and priorities on identified 1060 conflicts. 1062 o At deploy-time, autonomic functions are not yet active/acting on 1063 the network. A "dynamic interaction map" is created for each 1064 instance of each autonomic functions and on a per resource basis, 1065 including the actions performed and their relationships. This map 1066 provides the basis to identify conflicts that will happen at run- 1067 time, categorize them and plan for the appropriate coordination 1068 strategies/mechanisms. 1070 o At run-time, when conflicts happen, arbitration is driven by the 1071 coordination strategies. Also new dependencies can be observed 1072 and inferred, resulting in an update of the dynamic interaction 1073 map and adaptation of the coordination strategies and mechanisms. 1075 Multiple coordination strategies and mechanisms exist and can be 1076 devised. The set ranges from basic approaches such as random process 1077 or token-based process, to approaches based on time separation and 1078 hierarchical optimization, to more complex approaches such as multi- 1079 objective optimization, and other control theory approaches and 1080 algorithms family. 1082 8.2. A Coordination Functional Block (*) 1084 A common coordination functional block is a desirable component of 1085 the ANIMA reference model. It provides a means to ensure network 1086 properties and predictable performance or behavior such as stability, 1087 and convergence, in the presence of several interacting autonomic 1088 functions. 1090 A common coordination function requires: 1092 o A common description of autonomic functions, their attributes and 1093 life-cycle. 1095 o A common representation of information and knowledge (e.g., 1096 interaction maps). 1098 o A common "control/command" interface between the coordination 1099 "agent" and the autonomic functions. 1101 Guidelines, recommendations or BCPs can also be provided for aspects 1102 pertaining to the coordination strategies and mechanisms. 1104 9. Security Considerations 1106 In this section we distinguish outsider and insider attacks. In an 1107 outsider attack all network elements and protocols are securely 1108 managed and operating, and an outside attacker can sniff packets in 1109 transit, inject and replay packets. In an insider attack, the 1110 attacker has access to an autonomic node or other means (e.g. remote 1111 code execution in the node by exploiting ACP-independent 1112 vulnerabilities in the node platform) to produce arbitrary payloads 1113 on the protected ACP channels. 1115 If a system has vulnerabilities in the implementation or operation 1116 (configuration), an outside attacker can exploit such vulnerabilies 1117 to become an insider attacker. 1119 9.1. Protection Against Outsider Attacks 1121 Here, we assume that all systems involved in an autonomic network are 1122 secured and operated according to best current practices. These 1123 protection methods comprise traditional security implementation and 1124 operation methods (such as code security, strong randomization 1125 algorithms, strong passwords, etc.) as well as mechanisms specific to 1126 an autonomic network (such as a secured MASA service). 1128 Traditional security methods for both implementation and operation 1129 are outside scope for this document. 1131 AN specific protocols and methods must also follow traditional 1132 security methods, in that all packets that can be sniffed or injected 1133 by an outside attacker are: 1135 o protected against modification. 1137 o authenticated. 1139 o protected against replay attacks. 1141 o encrypted. 1143 o and that the AN protocols are robust against packet drops and man- 1144 in-the-middle attacks. 1146 How these requirements are met is covered in the AN standards track 1147 documents that define the methods used, specifically 1148 [I-D.ietf-anima-bootstrapping-keyinfra], [I-D.ietf-anima-grasp], and 1149 [I-D.ietf-anima-autonomic-control-plane]. 1151 Most AN messages run inside the cryptographically protected ACP. The 1152 not protected AN messages outside the ACP are limited to a simple 1153 discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]: 1154 The "Discovery Unsolicited Link-Local (DULL)" message, with detailed 1155 rules on its usage. 1157 If AN messages can be observed by a third party, they might reveal 1158 valuable information about network configuration, security 1159 precautions in use, individual users, and their traffic patterns. If 1160 encrypted, AN messages might still reveal some information via 1161 traffic analysis, but this would be quite limited (for example, this 1162 would be highly unlikely to reveal any specific information about 1163 user traffic). 1165 9.2. Risk of Insider Attacks 1167 An autonomic network consists of autonomic devices that form a 1168 distributed self-managing system. Devices within a domain share a 1169 common trust anchor and thus implicitly trust each other. This means 1170 that any device inside a trust domain can by default use all 1171 distributed functions in the entire autonomic domain in a malicious 1172 way. 1174 If an autonomic node or protocol has vulnerabilities or is not 1175 securely operated, an outside attacker has the following generic ways 1176 to take control of an autonomic network: 1178 o Introducing a fake device into the trust domain, by subverting the 1179 authentication methods. This depends on the correct 1180 specification, implementation and operation of the AN protocols. 1182 o Subverting a device which is already part of a trust domain, and 1183 modifying its behavior. This threat is not specific to the 1184 solution discussed in this document, and applies to all network 1185 solutions. 1187 o Exploiting potentially yet unknown protocol vulnerabilities in the 1188 AN or other protocols. Also this is a generic threat that applies 1189 to all network solutions. 1191 The above threats are in principle comparable to other solutions: In 1192 the presence of design, implementation or operational errors, 1193 security is no longer guaranteed. However, the distributed nature of 1194 AN, specifically the Autonomic Control Plane, increases the threat 1195 surface significantly. For example, a compromised device may have 1196 full IP reachability to all other devices inside the ACP, and can use 1197 all AN methods and protocols. 1199 For the next phase of the ANIMA work it is therefore recommended to 1200 introduce a sub-domain security model, to reduce the attack surface 1201 and not expose a full domain to a potential intruder. Furthermore, 1202 additional security mechanisms on the ASA level should be considered 1203 for high-risk autonomic functions. 1205 10. IANA Considerations 1207 This document requests no action by IANA. 1209 11. Acknowledgements 1211 Many people have provided feedback and input to this document: Sheng 1212 Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman, Artur 1213 Hecker. 1215 12. References 1217 12.1. Normative References 1219 [I-D.ietf-anima-autonomic-control-plane] 1220 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 1221 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1222 plane-10 (work in progress), September 2017. 1224 [I-D.ietf-anima-bootstrapping-keyinfra] 1225 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1226 S., and K. Watsen, "Bootstrapping Remote Secure Key 1227 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1228 keyinfra-07 (work in progress), July 2017. 1230 [I-D.ietf-anima-grasp] 1231 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1232 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1233 grasp-15 (work in progress), July 2017. 1235 12.2. Informative References 1237 [I-D.du-anima-an-intent] 1238 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 1239 Behringer, "ANIMA Intent Policy and Format", draft-du- 1240 anima-an-intent-05 (work in progress), February 2017. 1242 [I-D.ietf-anima-prefix-management] 1243 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 1244 IPv6 Edge Prefix Management in Large-scale Networks", 1245 draft-ietf-anima-prefix-management-05 (work in progress), 1246 August 2017. 1248 [I-D.ietf-supa-generic-policy-data-model] 1249 Halpern, J. and J. Strassner, "Generic Policy Data Model 1250 for Simplified Use of Policy Abstractions (SUPA)", draft- 1251 ietf-supa-generic-policy-data-model-04 (work in progress), 1252 June 2017. 1254 [I-D.liu-anima-grasp-api] 1255 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1256 Autonomic Signaling Protocol Application Program Interface 1257 (GRASP API)", draft-liu-anima-grasp-api-05 (work in 1258 progress), October 2017. 1260 [I-D.liu-anima-grasp-distribution] 1261 Liu, B. and S. Jiang, "Information Distribution over 1262 GRASP", draft-liu-anima-grasp-distribution-04 (work in 1263 progress), May 2017. 1265 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 1266 December 2009, . 1269 [Meyer97] Meyer, B., "Object-Oriented Software Construction (2nd 1270 edition)", Prentice-Hall, ISBN 978-0136291558, 1997. 1272 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1273 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1274 Networking: Definitions and Design Goals", RFC 7575, 1275 DOI 10.17487/RFC7575, June 2015, . 1278 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1279 Analysis for Autonomic Networking", RFC 7576, 1280 DOI 10.17487/RFC7576, June 2015, . 1283 Authors' Addresses 1285 Michael H. Behringer (editor) 1287 Email: Michael.H.Behringer@gmail.com 1289 Brian Carpenter 1290 Department of Computer Science 1291 University of Auckland 1292 PB 92019 1293 Auckland 1142 1294 New Zealand 1296 Email: brian.e.carpenter@gmail.com 1298 Toerless Eckert 1299 Futurewei Technologies Inc. 1300 2330 Central Expy 1301 Santa Clara 95050 1302 USA 1304 Email: tte@cs.fau.de 1306 Laurent Ciavaglia 1307 Nokia 1308 Villarceaux 1309 Nozay 91460 1310 FR 1312 Email: laurent.ciavaglia@nokia.com 1314 Peloso Pierre 1315 Nokia 1316 Villarceaux 1317 Nozay 91460 1318 FR 1320 Email: pierre.peloso@nokia.com 1321 Bing Liu 1322 Huawei Technologies 1323 Q14, Huawei Campus 1324 No.156 Beiqing Road 1325 Hai-Dian District, Beijing 100095 1326 P.R. China 1328 Email: leo.liubing@huawei.com 1330 Jeferson Campos Nobre 1331 Federal University of Rio Grande do Sul 1332 Av. Bento Goncalves, 9500 1333 Porto Alegre 91501-970 1334 Brazil 1336 Email: jcnobre@inf.ufrgs.br 1338 John Strassner 1339 Huawei Technologies 1340 2330 Central Expressway 1341 Santa Clara, CA 95050 1342 USA 1344 Email: john.sc.strassner@huawei.com