idnits 2.17.1 draft-ietf-anima-reference-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TBC' is mentioned on line 691, but not defined == Missing Reference: 'Meyer97' is mentioned on line 775, but not defined == Unused Reference: 'I-D.behringer-anima-autonomic-addressing' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'RFC7404' is defined on line 990, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-behringer-anima-autonomic-addressing-02 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-02 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-04 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA M. Behringer, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Informational B. Carpenter 5 Expires: September 22, 2016 Univ. of Auckland 6 T. Eckert 7 Cisco 8 L. Ciavaglia 9 Alcatel Lucent 10 B. Liu 11 Huawei Technologies 12 J. Nobre 13 Federal University of Rio Grande do Sul 14 J. Strassner 15 Huawei Technologies 16 March 21, 2016 18 A Reference Model for Autonomic Networking 19 draft-ietf-anima-reference-model-01 21 Abstract 23 This document describes a reference model for Autonomic Networking. 24 The goal is to define how the various elements in an autonomic 25 context work together, to describe their interfaces and relations. 26 While the document is written as generally as possible, the initial 27 solutions are limited to the chartered scope of the WG. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 22, 2016. 46 Copyright Notice 48 Copyright (c) 2016 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 65 3. The Autonomic Network Element . . . . . . . . . . . . . . . . 4 66 3.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 4 67 4. The Autonomic Networking Infrastructure . . . . . . . . . . . 6 68 4.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.4. The Autonomic Control Plane . . . . . . . . . . . . . . . 8 72 4.5. Signaling Between Autonomic Nodes . . . . . . . . . . . . 8 73 4.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.7. Intent Distribution . . . . . . . . . . . . . . . . . . . 9 75 5. Functional Overview . . . . . . . . . . . . . . . . . . . . . 9 76 6. Security and Trust Infrastructure . . . . . . . . . . . . . . 11 77 6.1. Public Key Infrastructure . . . . . . . . . . . . . . . . 12 78 6.2. Domain Certificate . . . . . . . . . . . . . . . . . . . 12 79 6.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 12 80 6.4. Sub-Domains . . . . . . . . . . . . . . . . . . . . . . . 12 81 6.5. Cross-Domain Functionality . . . . . . . . . . . . . . . 13 82 7. Autonomic Service Agents (ASA) . . . . . . . . . . . . . . . 13 83 7.1. General Description of an ASA . . . . . . . . . . . . . . 13 84 7.2. Specific ASAs for the Enrolment Process . . . . . . . . . 13 85 7.2.1. The Enrolment ASA . . . . . . . . . . . . . . . . . . 13 86 7.2.2. The Enrolment Proxy ASA . . . . . . . . . . . . . . . 13 87 7.2.3. The Registrar ASA . . . . . . . . . . . . . . . . . . 13 88 8. Management and Programmability . . . . . . . . . . . . . . . 14 89 8.1. How an AN Network Is Managed . . . . . . . . . . . . . . 14 90 8.2. Intent (*) . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.3. Aggregated Reporting (*) . . . . . . . . . . . . . . . . 15 92 8.4. Feedback Loops to NOC(*) . . . . . . . . . . . . . . . . 16 93 8.5. Control Loops (*) . . . . . . . . . . . . . . . . . . . . 16 94 8.6. APIs (*) . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8.7. Data Model (*) . . . . . . . . . . . . . . . . . . . . . 17 96 9. Coordination Between Autonomic Functions (*) . . . . . . . . 18 97 9.1. The Coordination Problem (*) . . . . . . . . . . . . . . 18 98 9.2. A Coordination Functional Block (*) . . . . . . . . . . . 19 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 100 10.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . 20 101 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 102 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 103 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. Introduction 108 The document "Autonomic Networking - Definitions and Design Goals" 109 [RFC7575] explains the fundamental concepts behind Autonomic 110 Networking, and defines the relevant terms in this space. In section 111 5 it describes a high level reference model. This document defines 112 this reference model with more detail, to allow for functional and 113 protocol specifications to be developed in an architecturally 114 consistent, non-overlapping manner. While the document is written as 115 generally as possible, the initial solutions are limited to the 116 chartered scope of the WG. 118 As discussed in [RFC7575], the goal of this work is not to focus 119 exclusively on fully autonomic nodes or networks. In reality, most 120 networks will run with some autonomic functions, while the rest of 121 the network is traditionally managed. This reference model allows 122 for this hybrid approach. 124 This is a living document and will evolve with the technical 125 solutions developed in the ANIMA WG. Sections marked with (*) do not 126 represent current charter items. While this document must give a 127 long term architectural view, not all functions will be standardized 128 at the same time. 130 2. The Network View 132 This section describes the various elements in a network with 133 autonomic functions, and how these entities work together, on a high 134 level. Subsequent sections explain the detailed inside view for each 135 of the autonomic network elements, as well as the network functions 136 (or interfaces) between those elements. 138 Figure 1 shows the high level view of an Autonomic Network. It 139 consists of a number of autonomic nodes, which interact directly with 140 each other. Those autonomic nodes provide a common set of 141 capabilities across the network, called the "Autonomic Networking 142 Infrastructure" (ANI). The ANI provides functions like naming, 143 addressing, negotiation, synchronization, discovery and messaging. 145 Autonomic functions typically span several, possibly all nodes in the 146 network. The atomic entities of an autonomic function are called the 147 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 149 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 150 : : Autonomic Function 1 : : 151 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 152 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 153 : : : 154 : +- - - - - - - - - - - - - - + : 155 : : Autonomic Function 2 : : 156 : : ASA 2 : ASA 2 : : 157 : +- - - - - - - - - - - - - - + : 158 : : : 159 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 160 : Autonomic Networking Infrastructure : 161 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 162 +--------+ : +--------+ : +--------+ : +--------+ 163 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 164 +--------+ : +--------+ : +--------+ : +--------+ 166 Figure 1: High level view of an Autonomic Network 168 In a horizontal view, autonomic functions span across the network, as 169 well as the Autonomic Networking Infrastructure. In a vertical view, 170 a node always implements the ANI, plus it may have one or several 171 Autonomic Service Agents. 173 The Autonomic Networking Infrastructure (ANI) therefore is the 174 foundation for autonomic functions. The current charter of the ANIMA 175 WG is to specify the ANI, using a few autonomic functions as use 176 cases. 178 3. The Autonomic Network Element 180 3.1. Architecture 182 This section describes an autonomic network element and its internal 183 architecture. The reference model explained in the document 184 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 185 the sources of information that an autonomic service agent can 186 leverage: Self-knowledge, network knowledge (through discovery), 187 Intent, and feedback loops. Fundamentally, there are two levels 188 inside an autonomic node: the level of Autonomic Service Agents, and 189 the level of the Autonomic Networking Infrastructure, with the former 190 using the services of the latter. Figure 2 illustrates this concept. 192 +------------------------------------------------------------+ 193 | | 194 | +-----------+ +------------+ +------------+ | 195 | | Autonomic | | Autonomic | | Autonomic | | 196 | | Service | | Service | | Service | | 197 | | Agent 1 | | Agent 2 | | Agent 3 | | 198 | +-----------+ +------------+ +------------+ | 199 | ^ ^ ^ | 200 | - - | - - API level - -| - - - - - - - |- - - | 201 | V V V | 202 |------------------------------------------------------------| 203 | Autonomic Networking Infrastructure | 204 | - Data structures (ex: certificates, peer information) | 205 | - Autonomic Control Plane | 206 | - Autonomic Node Addressing | 207 | Discovery, negotiation and synchronisation functions | 208 | - Intent distribution | 209 | - Aggregated reporting and feedback loops | 210 | - Routing | 211 |------------------------------------------------------------| 212 | Basic Operating System Functions | 213 +------------------------------------------------------------+ 215 Figure 2: Model of an autonomic node 217 The Autonomic Networking Infrastructure (lower part of Figure 2) 218 contains node specific data structures, for example trust information 219 about itself and its peers, as well as a generic set of functions, 220 independent of a particular usage. This infrastructure should be 221 generic, and support a variety of Autonomic Service Agents (upper 222 part of Figure 2). The Autonomic Control Plane is the summary of all 223 interactions of the Autonomic Networking Infrastructure with other 224 nodes and services. 226 The use cases of "Autonomics" such as self-management, self- 227 optimisation, etc, are implemented as Autonomic Service Agents. They 228 use the services and data structures of the underlying autonomic 229 networking infrastructure. The underlying Autonomic Networking 230 Infrastructure should itself be self-managing. 232 The "Basic Operating System Functions" include the "normal OS", 233 including the network stack, security functions, etc. 235 Full AN nodes have the full Autonomic Networking Infrastructure, with 236 the full functionality described in this document. At a later stage 237 ANIMA may define a scope for constrained nodes with a reduced ANI and 238 well-defined minimal functionality. They are currently out of scope. 240 4. The Autonomic Networking Infrastructure 242 The Autonomic Networking Infrastructure provides a layer of common 243 functionality across an Autonomic Network. It comprises "must 244 implement" functions and services, as well as extensions. 246 An Autonomic Function, comprising of Autonomic Service Agents on 247 nodes, can rely on the fact that all nodes in the network implement 248 at least the "must implement" functions. 250 4.1. Naming 252 Inside a domain, each autonomic device should be assigned a name. 253 Basic considerations for forming the names is as the following: 255 o Uniqueness: The names must not collide within one autonomic 256 domain. It is acceptable that the names in different domains 257 collide, since they could be distinguished by domains. 259 o Consistency: The devices' naming should follow the same pattern 260 within a domain. 262 o Autonomic: The names must be assigned automatically without any 263 human intervention. 265 It is recommended that the names are generated by the autonomic nodes 266 themselves. 268 Specific naming convention is out of the scope of this document." 270 4.2. Addressing 272 Autonomic Service Agents (ASAs) need to communicate with each other, 273 using the autonomic addressing of the node they reside on. This 274 section describes the addressing approach of the Autonomic Networking 275 Infrastructure, used by ASAs. It does NOT describe addressing 276 approaches for the data plane of the network, which may be configured 277 and managed in the traditional way, or negotiated as a service of an 278 ASA. One use case for such an autonomic function is described in 279 [I-D.jiang-auto-addr-management]. The addressing of the Autonomic 280 Networking Infrastructure is in scope for this section, the address 281 space they negotiate for the data plane is not. 283 Autonomic addressing is a function of the Autonomic Networking 284 Infrastructure (lower part of Figure 2), specifically the Autonomic 285 Control Plane. ASAs do not have their own addresses. They may use 286 either API calls, or the autonomic addressing scheme of the Autonomic 287 Networking Infrastructure. 289 An autonomic addressing scheme has the following requirements: 291 o Zero-touch for simple networks: Simple networks should have 292 complete self-management of addressing, and not require any 293 central address management, tools, or address planning. 295 o Low-touch for complex networks: If complex networks require 296 operator input for autonomic address management, it should be 297 limited to high level guidance only, expressed in Intent. 299 o Flexibility: The addressing scheme must be flexible enough for 300 nodes to be able to move around, for the network to grow, split 301 and merge. 303 o Robustness: It should be as hard as possible for an administrator 304 to negatively affect addressing (and thus connectivity) in the 305 autonomic context. 307 o Support for virtualization: Autonomic Nodes may support Autonomic 308 Service Agents in different virtual machines or containers. The 309 addressing scheme should support this architecture. 311 o Simplicity: To make engineering simpler, and to give the human 312 administrator an easy way to trouble-shoot autonomic functions. 314 o Scale: The proposed scheme should work in any network of any size. 316 o Upgradability: The scheme must be able to support different 317 addressing concepts in the future. 319 The proposed addressing scheme is described in the document "An 320 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). 322 4.3. Discovery 324 Traditionally, most of the information a node requires is provided 325 through configuration or northbound interfaces. An autonomic 326 function should rely on such northbound interfaces minimally or not 327 at all, and therefore it needs to discover peers and other resources 328 in the network. This section describes various discovery functions 329 in an autonomic network. 331 Discovering nodes and their properties and capabilities: A core 332 function to establish an autonomic domain is the mutual discovery of 333 autonomic nodes, primarily adjacent nodes and secondarily off-link 334 peers. This may in principle either leverage existing discovery 335 mechanisms, or use new mechanisms tailored to the autonomic context. 336 An important point is that discovery must work in a network with no 337 predefined topology, ideally no manual configuration of any kind, and 338 with nodes starting up from factory condition or after any form of 339 failure or sudden topology change. 341 Discovering services: Network services such as AAA should also be 342 discovered and not configured. Service discovery is required for 343 such tasks. An autonomic network can either leverage existing 344 service discovery functions, or use a new approach, or a mixture. 346 Thus the discovery mechanism could either be fully integrated with 347 autonomic signaling (next section) or could use an independent 348 discovery mechanism such as DNS Service Discovery or Service Location 349 Protocol. This choice could be made independently for each Autonomic 350 Service Agent, although the infrastructure might require some minimal 351 lowest common denominator (e.g., for discovering the security 352 bootstrap mechanism, or the source of intent distribution, 353 Section 4.7). 355 The currently proposed protocol for node discovery is GRASP, 356 described in [I-D.ietf-anima-grasp]. 358 4.4. The Autonomic Control Plane 360 The totality of autonomic interactions forms the "Autonomic Control 361 Plane". This control plane can be either implemented in the global 362 routing table of a node, such as IGPs in today's networks; or it can 363 be provided as an overlay network. The document "An Autonomic 364 Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes 365 the details. 367 4.5. Signaling Between Autonomic Nodes 369 Autonomic nodes must communicate with each other, for example to 370 negotiate and/or synchronize technical objectives (i.e., network 371 parameters) of any kind and complexity. This requires some form of 372 signaling between autonomic nodes. Autonomic nodes implementing a 373 specific use case might choose their own signaling protocol, as long 374 as it fits the overall security model. However, in the general case, 375 any pair of autonomic nodes might need to communicate, so there needs 376 to be a generic protocol for this. A prerequisite for this is that 377 autonomic nodes can discover each other without any preconfiguration, 378 as mentioned above. To be generic, discovery and signaling must be 379 able to handle any sort of technical objective, including ones that 380 require complex data structures. The document "A Generic Discovery 381 and Negotiation Protocol for Autonomic Networking" 382 [I-D.ietf-anima-grasp] describes more detailed requirements for 383 discovery, negotiation and synchronization in an autonomic network. 384 It also defines a protocol, GRASP, for this purpose, including an 385 integrated but optional discovery protocol. 387 The currently proposed protocol for signalling is GRASP, described in 388 [I-D.ietf-anima-grasp]. It is expected to run inside the Autonomic 389 Control Plane (see Section 4.4). 391 4.6. Routing 393 All autonomic nodes in a domain must be able to communicate with each 394 other, and with autonomic nodes outside their own domain. Therefore, 395 an Autonomic Control Plane relies on a routing function. For 396 Autonomic Networks to be interoperable, they must all support one 397 common routing protocol. 399 The routing protocol is defined in the ACP document 400 [I-D.ietf-anima-autonomic-control-plane]. 402 4.7. Intent Distribution 404 [Editor's note: Intent is not yet in scope of the ANIMA charter as of 405 March 2016. The following information is provided to help understand 406 the long term ANIMA reference model.] 408 Intent is the policy language of an Autonomic Network; see 409 Section 8.2 for general information on Intent. The distribution of 410 Intent is also a function of the Autonomic Control Plane. It is 411 expected that Intent will be expressed as quite complex human- 412 readable data structures, and the distribution mechanism must be able 413 to support that. Some Intent items will need to be flooded to most 414 or all nodes, and other items of Intent may only be needed by a few 415 nodes. Various methods could be used to distribute Intent across an 416 autonomic domain. One approach is to treat it like any other 417 technical objective needing to be synchronized across a set of nodes. 418 In that case the autonomic signaling protocol could be used (previous 419 section). 421 5. Functional Overview 423 This section provides an overview on how the functions in the 424 Autonomic Networking Infrastructure work together, and how the 425 various documents about AN relate to each other. 427 The foundations of Autonomic Networking, definitions and gap analysis 428 in the context of the IETF are described in [RFC7575] and [RFC7576]. 430 Autonomic Networking is based on direct interactions between devices 431 of a domain. The Autonomic Networking Infrastructure (ANI) is 432 normally built on a hop-by-hop basis. Therefore, many interactions 433 in the ANI are based on the ANI adjacency table. There are 434 interactions that provide input into the adjacency table, and other 435 interactions that leverage the information contained in it. 437 The ANI adjacency table contains information about adjacent autonomic 438 nodes, at a minimum: node-ID, IP address in data plane, IP address in 439 ACP, domain, certificate. An autonomic node maintains this adjacency 440 table up to date. The adjacency table only contains information 441 about other nodes that are capable of Autonomic Networking; non- 442 autonomic nodes are normally not tracked here. However, the 443 information is tracked independently of the status of the peer nodes; 444 specifically, it contains information about non-enrolled nodes, nodes 445 of the same and other domains. The adjacency table MAY contain 446 information about the validity and trust of the adjacent autonomic 447 node's certificate, although all autonomic interactions must verify 448 validity and trust independently. 450 The adjacency table is fed by the following inputs: 452 o Link local discovery: This interaction happens in the data plane, 453 using IPv6 link local addressing only, because this addressing 454 type is itself autonomic. This way the nodes learns about all 455 autonomic nodes around itself. This is described in 456 [I-D.ietf-anima-grasp]. 458 o Vendor re-direct: A new device may receive information on where 459 its home network is through a vendor based MASA re-direct; this is 460 typically a routable address. See 461 [I-D.ietf-anima-bootstrapping-keyinfra]. 463 o Non-autonomic input: A node may be configured manually with an 464 autonomic peer; it could learn about autonomic nodes through DHCP 465 options, DNS, and other non-autonomic mechanisms. Generally such 466 non-autonomic mechansims require some administrator intervention. 467 The key purpose is to by-pass a non-autonomic device or network. 468 As this pertains to new devices, it is covered in Section 5.3 of 469 [I-D.ietf-anima-bootstrapping-keyinfra]. 471 The adjacency table is defining the behaviour of an autonomic node: 473 o If the node has not bootstrapped into a domain (i.e., doesn't have 474 a domain certificate), it rotates through all nodes in the 475 adjacency table that claim to have a domain, and will attempt 476 bootstrapping through them, one by one. One possible response is 477 a vendor MASA re-direct, which will be entered into the adjacency 478 table (see second bullet above). See 479 [I-D.ietf-anima-bootstrapping-keyinfra]. 481 o If the node has bootstrapped into a domain (i.e., has a domain 482 certificate), it will act as a proxy for neighboring nodes that 483 need to be bootstrapped. See 484 [I-D.ietf-anima-bootstrapping-keyinfra]. 486 o If the adjacent node has the same domain, it will authenticate 487 that adjacent node and establish the Autonomic Control Plane 488 (ACP). See [I-D.ietf-anima-autonomic-control-plane]. 490 o Other behaviours are possible, for example establishing the ACP 491 also with devices of a sub-domain, to other domains, etc. Those 492 will likely be controlled by Intent. They are outside scope for 493 the moment. Note that Intent is distributed through the ACP; 494 therefore, a node can only adapt Intent driven behaviour once it 495 has joined the ACP. At the moment, ANIMA does not consider 496 providing Intent outside the ACP; this can be considered later. 498 Once a node has joined the ACP, it will also learn the ACP addresses 499 of its adjacent nodes, and add them to the adjacency table, to allow 500 for communication inside the ACP. Further interactions will now 501 happen inside the ACP. At this moment, only negotiation / 502 synchronization via GRASP [I-D.ietf-anima-grasp] is being defined. 503 (Note that GRASP runs in the data plane, as an input in building the 504 adjacency table, as well as inside the ACP.) 506 Autonomic Functions consist of Autonomic Service Agents (ASAs). They 507 run logically above the AN Infrastructure, and may use the adjacency 508 table, the ACP, negotiation and synchronization through GRASP in the 509 ACP, Intent and other functions of the ANI. Since the ANI only 510 provides autonomic interactions within a domain, autonomic functions 511 can also use any other context on a node, specifically the global 512 data plane. 514 6. Security and Trust Infrastructure 516 An Autonomic Network is self-protecting. All protocols are secure by 517 default, without the requirement for the administrator to explicitly 518 configure security. 520 Autonomic nodes have direct interactions between themselves, which 521 must be secured. Since an autonomic network does not rely on 522 configuration, it is not an option to configure for example pre- 523 shared keys. A trust infrastructure such as a PKI infrastructure 524 must be in place. This section describes the principles of this 525 trust infrastructure. 527 A completely autonomic way to automatically and securely deploy such 528 a trust infrastructure is to set up a trust anchor for the domain, 529 and then use an approach as in the document "Bootstrapping Key 530 Infrastructures" [I-D.ietf-anima-bootstrapping-keyinfra]. 532 6.1. Public Key Infrastructure 534 An autonomic domain uses a PKI model. The root of trust is a 535 certification authority (CA). A registrar acts as a registration 536 authority (RA). 538 A minimum implementation of an autonomic domain contains one CA, one 539 Registrar, and network elements. 541 6.2. Domain Certificate 543 Each device in an autonomic domain uses a domain certificate to prove 544 its identity. [I-D.ietf-anima-bootstrapping-keyinfra] describes how 545 a new device receives a domain certificate, and the certificate 546 format. 548 6.3. The MASA 550 The Manufacturer Authorized Signing Authority (MASA) is a trusted 551 service for bootstrapping devices. The purpose of the MASA is to 552 provide ownership tracking of devices in a domain. The MASA provides 553 audit, authorization, and ownership tokens to the registrar during 554 the bootstrap process to assist in the authentication of devices 555 attempting to join an Autonomic Domain, and to allow a joining device 556 to validate whether it is joining the correct domain. The details 557 for MASA service, security, and usage are defined in 558 [I-D.ietf-anima-bootstrapping-keyinfra]. 560 6.4. Sub-Domains 562 By default, sub-domains are treated as different domains. This 563 implies no trust between a domain and its sub-domains, and no trust 564 between sub-domains of the same domain. Specifically, no ACP is 565 built, and Intent is valid only for the domain it is defined for 566 explicitly. 568 In the future, alternative trust models can be defined, for example 569 to allow full or limited trust between domain and sub-domain. 571 6.5. Cross-Domain Functionality 573 By default, different domains do not interoperate, no ACP is built 574 and no trust is implied between them. 576 In the future, models can be established where other domains can be 577 trusted in full or for limited operations between the domains. 579 7. Autonomic Service Agents (ASA) 581 This section describes how autonomic services run on top of the 582 Autonomic Networking Infrastructure. 584 7.1. General Description of an ASA 586 general concepts, such as sitting on top of the ANI, etc. Also needs 587 to explain that on a constrained node not all ASAs may run, so we 588 have two classes of ASAs: Ones that run on an unconstrained node, and 589 limited function ASAs that run also on constrained nodes. We expect 590 unconstrained nodes to support all ASAs. 592 7.2. Specific ASAs for the Enrolment Process 594 The following ASAs provide essential, required functionality in an 595 autonomic network, and are therefore mandatory to implement on 596 unconstrained autonomic nodes. 598 7.2.1. The Enrolment ASA 600 This section describes the function of an autonomic node to bootstrap 601 into the domain with the help of an enrolment proxy (see previous 602 section). [tbc] 604 7.2.2. The Enrolment Proxy ASA 606 This section describes the function of an autonomic node that helps a 607 non-enrolled, adjacent devices to enrol into the domain. [tbc] 609 7.2.3. The Registrar ASA 611 This section describes the registrar function in an autonomic 612 network. It explains the tasks of a registrar element, and how 613 registrars are placed in a network, redundancy between several, etc. 614 [tbc] 616 8. Management and Programmability 618 This section describes how an Autonomic Network is managed, and 619 programmed. 621 8.1. How an AN Network Is Managed 623 Autonomic management usually co-exists with traditional management 624 methods in most networks. Thus, autonomic behavior will be defined 625 for individual functions in most environments. In fact, the co- 626 existence is twofold: autonomic functions can use traditional methods 627 and protocols (e.g., SNMP and NETCONF) to perform management tasks; 628 and autonomic functions can conflict with behavior enforced by the 629 same traditional methods and protocols. 631 The autonomic intent is defined at a high level of abstraction. 632 However, since it is necessary to address individual managed 633 elements, autonomic management needs to communicate in lower-level 634 interactions (e.g., commands and requests). For example, it is 635 expected that the configuration of such elements be performed using 636 NETCONF and YANG modules as well as the monitoring be executed 637 through SNMP and MIBs. 639 Conflict can occur between autonomic default behavior, autonomic 640 intent, traditional management methods. Conflict resolution is 641 achieved in autonomic management through prioritization [RFC7575]. 642 The rationale is that manual and node-based management have a higher 643 priority over autonomic management. Thus, the autonomic default 644 behavior has the lowest priority, then comes the autonomic Intent 645 (medium priority), and, finally, the highest priority is taken by 646 node-specific network management methods, such as the use of command 647 line interfaces [RFC7575]. 649 8.2. Intent (*) 651 This section describes Intent, and how it is managed. Intent and 652 Policy-Based Network Management (PBNM) is already described inside 653 the IETF (e.g., PCIM and SUPA) and in other SDOs (e.g., DMTF and TMF 654 ZOOM). 656 Intent can be describe as an abstract, declarative, high-level policy 657 used to operate an autonomic domain, such as an enterprise network 658 [RFC7575]. Intent should be limited to high level guidance only, 659 thus it does not directly define a policy for every network element 660 separately. It is expected intent definitions from autonomic 661 function(s) and even from traditional network management elements. 663 Intent can be refined to lower level policies using different 664 approaches. This is expected in order to adapt the intent to the 665 capabilities of managed devices. Intent may contain role or function 666 information, which can be translated to specific nodes [RFC7575]. 667 One of the possible refinements of the intent is using Event- 668 Condition-Action (ECA) rules. 670 Different parameters may be configured for intents. These parameters 671 are usually provided by the human operator. Some of these parameters 672 can influence the behavior of specific autonomic functions as well as 673 the way the intent is used to manage the autonomic domain. 675 Some examples of parameters for intents are: 677 o Model version: The version of the model used to define the intent. 679 o Domain: The network scope in which the intent has effect. 681 o Name: The name of the intent which describes the intent for human 682 operators. 684 o Version: The version of the intent, which is primarly used to 685 control intent updates. 687 o Signature: The signature is used as a security mechanism to 688 provide authentication, integrity, and non-repudiation. 690 o Timestamp: The timestamp of the creation of the intent using the 691 format supported by the IETF [TBC]. 693 o Lifetime: The lifetime in which the intent may be observed. A 694 special case of the lifetime is the definition of permanent 695 intents. 697 8.3. Aggregated Reporting (*) 699 Autonomic Network should minimize the need for human intervention. 700 In terms of how the network should behave, this is done through an 701 autonomic intent provided by the human administrator. In an 702 analogous manner, the reports which describe the operational status 703 of the network should aggregate the information produced in different 704 network elements in order to present the effectiveness of autonomic 705 intent enforcement. Therefore, reporting in an autonomic network 706 should happen on a network-wide basis [RFC7575]. 708 Several events can occur in an autonomic network in the same way they 709 can happen in a traditional network. However, when reporting to a 710 human administrator, such events should be aggregated to avoid 711 advertisement about individual managed elements. In this context, 712 algorithms may be used to determine what should be reported (e.g., 713 filtering) and in which way and how different events are related to 714 each other. Besides that, an event in an individual element can be 715 compensated by changes in other elements to maintain a network-wide 716 level which is described in the autonomic intent. 718 Reporting in an autonomic network may be in the same abstraction 719 level of the intent. In this context, the visibility on current 720 operational status of an autonomic network can be used to switch to 721 different management modes. Despite the fact that autonomic 722 management should minimize the need for user intervention, possibly 723 there are some events that need to be addressed by human 724 administrator actions. 726 8.4. Feedback Loops to NOC(*) 728 Feedback loops are required in an autonomic network to allow the 729 intervention of a human administrator or central control systems, 730 while maintaining a default behaviour. Through a feedback loop an 731 administrator can be prompted with a default action, and has the 732 possibility to acknowledge or override the proposed default action. 734 8.5. Control Loops (*) 736 Control loops are used in autonomic networking to provide a generic 737 mechanism to enable the Autonomic System to adapt (on its own) to 738 various factors that can change the goals that the Autonomic System 739 is trying to achieve, or how those goals are achieved. For example, 740 as user needs, business goals, and the ANI itself changes, self- 741 adaptation enables the ANI to change the services and resources it 742 makes available to adapt to these changes. 744 Control loops operate to continuously observe and collect data that 745 enables the autonomic management system to understand changes to the 746 behavior of the system being managed, and then provide actions to 747 move the state of the system being managed toward a common goal. 748 Self-adaptive systems move decision-making from static, pre-defined 749 commands to dynamic processes computed at runtime. 751 Most autonomic systems use a closed control loop with feedback. Such 752 control loops SHOULD be able to be dynamically changed at runtime to 753 adapt to changing user needs, business goals, and changes in the ANI. 755 The document [draft-strassner-anima-control-loop] defines the 756 requirements for an autonomic control loop, describes different types 757 of control loops, and explains how control loops are used in an 758 autonomic system. 760 8.6. APIs (*) 762 Most APIs are static, meaning that they are pre-defined and represent 763 an invariant mechanism for operating with data. An Autonomic Network 764 SHOULD be able to use dynamic APIs in addition to static APIs. 766 A dynamic API is one that retrieves data using a generic mechanism, 767 and then enables the client to navigate the retrieved data and 768 operate on it. Such APIs typically use introspection and/or 769 reflection. Introspection enables software to examine the type and 770 properties of an object at runtime, while reflection enables a 771 program to manipulate the attributes, methods, and/or metadata of an 772 object. 774 APIs MUST be able to express and preserve semantics across different 775 domains. For example, software contracts [Meyer97] are based on the 776 principle that a software-intensive system, such as an Autonomic 777 Network, is a set of communicating components whose interaction is 778 based on precisely-defined specifications of the mutual obligations 779 that interacting components must respect. This typically includes 780 specifying: 782 o pre-conditions that MUST be satisfied before the method can start 783 execution 785 o post-conditions that MUST be satisfied when the method has 786 finished execution 788 o invariant attributes that MUST NOT change during the execution of 789 the method 791 8.7. Data Model (*) 793 The following definitions are taken from [supa-model]: 795 An information model is a representation of concepts of interest to 796 an environment in a form that is independent of data repository, data 797 definition language, query language, implementation language, and 798 protocol. In contrast, a data model is a representation of concepts 799 of interest to an environment in a form that is dependent on data 800 repository, data definition language, query language, implementation 801 language, and protocol (typically, but not necessarily, all three). 803 The utility of an information model is to define objects and their 804 relationships in a technology-neutral manner. This forms a 805 consensual vocabulary that the ANI and ASAs can use. A data model is 806 then a technology-specific mapping of all or part of the information 807 model to be used by all or part of the system. 809 A system may have multiple data models. Operational Support Systems, 810 for example, typically have multiple types of repositories, such as 811 SQL and NoSQL, to take advantage of the different properties of each. 812 If multiple data models are required by an Autonomic System, then an 813 information model SHOULD be used to ensure that the concepts of each 814 data model can be related to each other without technological bias. 816 A data model is essential for certain types of functions, such as a 817 MRACL. More generally, a data model can be used to define the 818 objects, attributes, methods, and relationships of a software system 819 (e.g., the ANI, an autonomic node, or an ASA). A data model can be 820 used to help design an API, as well as any language used to interface 821 to the Autonomic Network. 823 9. Coordination Between Autonomic Functions (*) 825 9.1. The Coordination Problem (*) 827 Different autonomic functions may conflict in setting certain 828 parameters. For example, an energy efficiency function may want to 829 shut down a redundant link, while a load balancing function would not 830 want that to happen. The administrator must be able to understand 831 and resolve such interactions, to steer autonomic network performance 832 to a given (intended) operational point. 834 Several interaction types may exist among autonomic functions, for 835 example: 837 o Cooperation: An autonomic function can improve the behavior or 838 performance of another autonomic function, such as a traffic 839 forecasting function used by a traffic allocation function. 841 o Dependency: An autonomic function cannot work without another one 842 being present or accessible in the autonomic network. 844 o Conflict: A metric value conflict is a conflict where one metric 845 is influenced by parameters of different autonomic functions. A 846 parameter value conflict is a conflict where one parameter is 847 modified by different autonomic functions. 849 Solving the coordination problem beyond one-by-one cases can rapidly 850 become intractable for large networks. Specifying a common 851 functional block on coordination is a first step to address the 852 problem in a systemic way. The coordination life-cycle consists in 853 three states: 855 o At build-time, a "static interaction map" can be constructed on 856 the relationship of functions and attributes. This map can be 857 used to (pre-)define policies and priorities on identified 858 conflicts. 860 o At deploy-time, autonomic functions are not yet active/acting on 861 the network. A "dynamic interaction map" is created for each 862 instance of each autonomic functions and on a per resource basis, 863 including the actions performed and their relationships. This map 864 provides the basis to identify conflicts that will happen at run- 865 time, categorize them and plan for the appropriate coordination 866 strategies/mechanisms. 868 o At run-time, when conflicts happen, arbitration is driven by the 869 coordination strategies. Also new dependencies can be observed 870 and inferred, resulting in an update of the dynamic interaction 871 map and adaptation of the coordination strategies and mechanisms. 873 Multiple coordination strategies and mechanisms exists and can be 874 devised. The set ranges from basic approaches such as random process 875 or token-based process, to approaches based on time separation and 876 hierarchical optimization, to more complex approaches such as multi- 877 objective optimization, and other control theory approaches and 878 algorithms family. 880 9.2. A Coordination Functional Block (*) 882 A common coordination functional block is a desirable component of 883 the ANIMA reference model. It provides a means to ensure network 884 properties and predictable performance or behavior such as stability, 885 and convergence, in the presence of several interacting autonomic 886 functions. 888 A common coordination function requires: 890 o A common description of autonomic functions, their attributes and 891 life-cycle. 893 o A common representation of information and knowledge (e.g., 894 interaction maps). 896 o A common "control/command" interface between the coordination 897 "agent" and the autonomic functions. 899 Guidelines, recommendations or BCPs can also be provided for aspects 900 pertaining to the coordination strategies and mechanisms. 902 10. Security Considerations 904 10.1. Threat Analysis 906 This is a preliminary outline of a threat analysis, to be expanded 907 and made more specific as the various Autonomic Networking 908 specifications evolve. 910 Since AN will hand over responsibility for network configuration from 911 humans or centrally established management systems to fully 912 distributed devices, the threat environment is also fully 913 distributed. On the one hand, that means there is no single point of 914 failure to act as an attractive target for bad actors. On the other 915 hand, it means that potentially a single misbehaving autonomic device 916 could launch a widespread attack, by misusing the distributed AN 917 mechanisms. For example, a resource exhaustion attack could be 918 launched by a single device requesting large amounts of that resource 919 from all its peers, on behalf of a non-existent traffic load. 920 Alternatively it could simply send false information to its peers, 921 for example by announcing resource exhaustion when this was not the 922 case. If security properties are managed autonomically, a 923 misbehaving device could attempt a distributed attack by requesting 924 all its peers to reduce security protections in some way. In 925 general, since autonomic devices run without supervision, almost any 926 kind of undesirable management action could in theory be attempted by 927 a misbehaving device. 929 If it is possible for an unauthorised device to act as an autonomic 930 device, or for a malicious third party to inject messages appearing 931 to come from an autonomic device, all these same risks would apply. 933 If AN messages can be observed by a third party, they might reveal 934 valuable information about network configuration, security 935 precautions in use, individual users, and their traffic patterns. If 936 encrypted, AN messages might still reveal some information via 937 traffic analysis, but this would be quite limited (for example, this 938 would be highly unlikely to reveal any specific information about 939 user traffic). AN messages are liable to be exposed to third parties 940 on any unprotected Layer 2 link, and to insider attacks even on 941 protected Layer 2 links. 943 11. IANA Considerations 945 This document requests no action by IANA. 947 12. Acknowledgements 949 Many people have provided feedback and input to this document: Sheng 950 Jiang, Roberta Maglione, Jonathan Hansford. 952 13. References 954 [I-D.behringer-anima-autonomic-addressing] 955 Behringer, M., "An Autonomic IPv6 Addressing Scheme", 956 draft-behringer-anima-autonomic-addressing-02 (work in 957 progress), October 2015. 959 [I-D.ietf-anima-autonomic-control-plane] 960 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 961 Autonomic Control Plane", draft-ietf-anima-autonomic- 962 control-plane-01 (work in progress), October 2015. 964 [I-D.ietf-anima-bootstrapping-keyinfra] 965 Pritikin, M., Richardson, M., Behringer, M., and S. 966 Bjarnason, "Bootstrapping Key Infrastructures", draft- 967 ietf-anima-bootstrapping-keyinfra-02 (work in progress), 968 March 2016. 970 [I-D.ietf-anima-grasp] 971 Bormann, C., Carpenter, B., and B. Liu, "A Generic 972 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 973 grasp-04 (work in progress), March 2016. 975 [I-D.jiang-auto-addr-management] 976 Jiang, S., Carpenter, B., and Q. Qiong, "Autonomic 977 Networking Use Case for Auto Address Management", draft- 978 jiang-auto-addr-management-00 (work in progress), April 979 2014. 981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, 983 DOI 10.17487/RFC2119, March 1997, 984 . 986 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 987 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 988 . 990 [RFC7404] Behringer, M. and E. Vyncke, "Using Only Link-Local 991 Addressing inside an IPv6 Network", RFC 7404, 992 DOI 10.17487/RFC7404, November 2014, 993 . 995 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 996 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 997 Networking: Definitions and Design Goals", RFC 7575, 998 DOI 10.17487/RFC7575, June 2015, 999 . 1001 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1002 Analysis for Autonomic Networking", RFC 7576, 1003 DOI 10.17487/RFC7576, June 2015, 1004 . 1006 Authors' Addresses 1008 Michael H. Behringer (editor) 1009 Cisco Systems 1010 Building D, 45 Allee des Ormes 1011 Mougins 06250 1012 France 1014 Email: mbehring@cisco.com 1016 Brian Carpenter 1017 Department of Computer Science 1018 University of Auckland 1019 PB 92019 1020 Auckland 1142 1021 New Zealand 1023 Email: brian.e.carpenter@gmail.com 1025 Toerless Eckert 1026 Cisco 1028 Email: eckert@cisco.com 1030 Laurent Ciavaglia 1031 Alcatel Lucent 1032 Route de Villejust 1033 Nozay 91620 1034 France 1036 Email: laurent.ciavaglia@alcatel-lucent.com 1037 Bing Liu 1038 Huawei Technologies 1039 Q14, Huawei Campus 1040 No.156 Beiqing Road 1041 Hai-Dian District, Beijing 100095 1042 P.R. China 1044 Email: leo.liubing@huawei.com 1046 Jeferson Campos Nobre 1047 Federal University of Rio Grande do Sul 1048 Av. Bento Goncalves, 9500 1049 Porto Alegre 91501-970 1050 Brazil 1052 Email: jcnobre@inf.ufrgs.br 1054 John Strassner 1055 Huawei Technologies 1056 2330 Central Expressway 1057 Santa Clara, CA 95050 1058 USA 1060 Email: john.sc.strassner@huawei.com