idnits 2.17.1 draft-ietf-anima-reference-model-04.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 945: '... control loops SHOULD be able to be ...' RFC 2119 keyword, line 957: '... SHOULD be able to use dynamic APIs ...' RFC 2119 keyword, line 967: '... APIs MUST be able to express and pr...' RFC 2119 keyword, line 975: '...-conditions that MUST be satisfied bef...' RFC 2119 keyword, line 978: '...-conditions that MUST be satisfied whe...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 3, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Meyer97' is mentioned on line 968, but not defined == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-06 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-06 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-14 == Outdated reference: A later version (-07) exists of draft-ietf-anima-prefix-management-04 == Outdated reference: A later version (-06) exists of draft-liu-anima-grasp-api-04 == Outdated reference: A later version (-13) exists of draft-liu-anima-grasp-distribution-04 Summary: 2 errors (**), 0 flaws (~~), 8 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: January 4, 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 July 3, 2017 19 A Reference Model for Autonomic Networking 20 draft-ietf-anima-reference-model-04 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 January 4, 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. How an AN Network Is Managed . . . . . . . . . . . . . . 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. Consequences of a Distributed System . . . . . . . . . . 24 107 9.2. Security Mechanisms . . . . . . . . . . . . . . . . . . . 25 108 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 109 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 113 1. Introduction 115 The document "Autonomic Networking - Definitions and Design Goals" 116 [RFC7575] explains the fundamental concepts behind Autonomic 117 Networking, and defines the relevant terms in this space, as well as 118 a high level reference model. [RFC7576] provides a gap analysis 119 between traditional and autonomic approaches. 121 This document defines this reference model with more detail, to allow 122 for functional and protocol specifications to be developed in an 123 architecturally consistent, non-overlapping manner. While the 124 document is written as generally as possible, the initial solutions 125 are limited to the chartered scope of the WG. 127 As discussed in [RFC7575], the goal of this work is not to focus 128 exclusively on fully autonomic nodes or networks. In reality, most 129 networks will run with some autonomic functions, while the rest of 130 the network is traditionally managed. This reference model allows 131 for this hybrid approach. 133 This document describes phase 1 of an Autonomic Networking solution, 134 and covers primarily the WG items of the ANIMA WG as of July 2017. 135 Sections marked with (*) do not represent chartered items at this 136 time. New WG items will require an update to this document, or 137 potentially a new document. 139 2. The Network View 141 This section describes the various elements in a network with 142 autonomic functions, and how these entities work together, on a high 143 level. Subsequent sections explain the detailed inside view for each 144 of the autonomic network elements, as well as the network functions 145 (or interfaces) between those elements. 147 Figure 1 shows the high level view of an Autonomic Network. It 148 consists of a number of autonomic nodes, which interact directly with 149 each other. Those autonomic nodes provide a common set of 150 capabilities across the network, called the "Autonomic Networking 151 Infrastructure" (ANI). The ANI provides functions like naming, 152 addressing, negotiation, synchronization, discovery and messaging. 154 Autonomic functions typically span several, possibly all nodes in the 155 network. The atomic entities of an autonomic function are called the 156 "Autonomic Service Agents" (ASA), which are instantiated on nodes. 158 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 159 : : Autonomic Function 1 : : 160 : ASA 1 : ASA 1 : ASA 1 : ASA 1 : 161 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 162 : : : 163 : +- - - - - - - - - - - - - - + : 164 : : Autonomic Function 2 : : 165 : : ASA 2 : ASA 2 : : 166 : +- - - - - - - - - - - - - - + : 167 : : : 168 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 169 : Autonomic Networking Infrastructure : 170 +- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 171 +--------+ : +--------+ : +--------+ : +--------+ 172 | Node 1 |--------| Node 2 |--------| Node 3 |----...-----| Node n | 173 +--------+ : +--------+ : +--------+ : +--------+ 175 Figure 1: High level view of an Autonomic Network 177 In a horizontal view, autonomic functions span across the network, as 178 well as the Autonomic Networking Infrastructure. In a vertical view, 179 a node always implements the ANI, plus it may have one or several 180 Autonomic Service Agents. 182 The Autonomic Networking Infrastructure (ANI) therefore is the 183 foundation for autonomic functions. The current charter of the ANIMA 184 WG is to specify the ANI, using a few autonomic functions as use 185 cases. 187 3. The Autonomic Network Element 189 3.1. Architecture 191 This section describes an autonomic network element and its internal 192 architecture. The reference model explained in the document 193 "Autonomic Networking - Definitions and Design Goals" [RFC7575] shows 194 the sources of information that an autonomic service agent can 195 leverage: Self-knowledge, network knowledge (through discovery), 196 Intent, and feedback loops. There are two levels inside an autonomic 197 node: the level of Autonomic Service Agents, and the level of the 198 Autonomic Networking Infrastructure, with the former using the 199 services of the latter. Figure 2 illustrates this concept. 201 +------------------------------------------------------------+ 202 | | 203 | +-----------+ +------------+ +------------+ | 204 | | Autonomic | | Autonomic | | Autonomic | | 205 | | Service | | Service | | Service | | 206 | | Agent 1 | | Agent 2 | | Agent 3 | | 207 | +-----------+ +------------+ +------------+ | 208 | ^ ^ ^ | 209 | - - | - - API level - -| - - - - - - - |- - - | 210 | V V V | 211 |------------------------------------------------------------| 212 | Autonomic Networking Infrastructure | 213 | - Data structures (ex: certificates, peer information) | 214 | - Autonomic Control Plane (ACP) | 215 | - Autonomic Node Addressing | 216 | Discovery, negotiation and synchronisation functions | 217 | - Distribution of Intent and other information | 218 | - Aggregated reporting and feedback loops | 219 | - Routing | 220 |------------------------------------------------------------| 221 | Basic Operating System Functions | 222 +------------------------------------------------------------+ 224 Figure 2: Model of an autonomic node 226 The Autonomic Networking Infrastructure (lower part of Figure 2) 227 contains node specific data structures, for example trust information 228 about itself and its peers, as well as a generic set of functions, 229 independent of a particular usage. This infrastructure should be 230 generic, and support a variety of Autonomic Service Agents (upper 231 part of Figure 2). The Autonomic Control Plane (ACP) is the summary 232 of all interactions of the Autonomic Networking Infrastructure with 233 other nodes and services. 235 The use cases of "Autonomics" such as self-management, self- 236 optimisation, etc, are implemented as Autonomic Service Agents. They 237 use the services and data structures of the underlying Autonomic 238 Networking Infrastructure, which should be self-managing. 240 The "Basic Operating System Functions" include the "normal OS", 241 including the network stack, security functions, etc. 243 Full AN nodes have the full Autonomic Networking Infrastructure, with 244 the full functionality described in this document. At a later stage 245 ANIMA may define a scope for constrained nodes with a reduced ANI and 246 well-defined minimal functionality. They are currently out of scope. 248 3.2. The Adjacency Table 250 Autonomic Networking is based on direct interactions between devices 251 of a domain. The Autonomic Networking Infrastructure (ANI) is 252 normally built on a hop-by-hop basis. Therefore, many interactions 253 in the ANI are based on the ANI adjacency table. There are 254 interactions that provide input into the adjacency table, and other 255 interactions that leverage the information contained in it. 257 The ANI adjacency table contains information about adjacent autonomic 258 nodes, at a minimum: node-ID, IP address in data plane, IP address in 259 ACP, domain, certificate. An autonomic node maintains this adjacency 260 table up to date. The adjacency table only contains information 261 about other nodes that are capable of Autonomic Networking; non- 262 autonomic nodes are normally not tracked here. However, the 263 information is tracked independently of the status of the peer nodes; 264 specifically, it contains information about non-enrolled nodes, nodes 265 of the same and other domains. The adjacency table may contain 266 information about the validity and trust of the adjacent autonomic 267 node's certificate, although all autonomic interactions must verify 268 validity and trust independently. 270 The adjacency table is fed by the following inputs: 272 o Link local discovery: This interaction happens in the data plane, 273 using IPv6 link local addressing only, because this addressing 274 type is itself autonomic. This way the nodes learns about all 275 autonomic nodes around itself. This is described in 276 [I-D.ietf-anima-grasp]. 278 o Vendor re-direct: A new device may receive information on where 279 its home network is through a vendor based MASA re-direct; this is 280 typically a routable address. See 281 [I-D.ietf-anima-bootstrapping-keyinfra]. 283 o Non-autonomic input: A node may be configured manually with an 284 autonomic peer; it could learn about autonomic nodes through DHCP 285 options, DNS, and other non-autonomic mechanisms. Generally such 286 non-autonomic mechansims require some administrator intervention. 287 The key purpose is to by-pass a non-autonomic device or network. 288 As this pertains to new devices, it is covered in Appendix A and B 289 of [I-D.ietf-anima-bootstrapping-keyinfra]. 291 The adjacency table is defining the behaviour of an autonomic node: 293 o If the node has not bootstrapped into a domain (i.e., doesn't have 294 a domain certificate), it rotates through all nodes in the 295 adjacency table that claim to have a domain, and will attempt 296 bootstrapping through them, one by one. One possible response is 297 a vendor MASA re-direct, which will be entered into the adjacency 298 table (see second bullet above). See 299 [I-D.ietf-anima-bootstrapping-keyinfra]. 301 o If the adjacent node has the same domain, it will authenticate 302 that adjacent node and, if successful, establish the Autonomic 303 Control Plane (ACP). See 304 [I-D.ietf-anima-autonomic-control-plane]. 306 o Once the node is part of the ACP of a domain, it will use GRASP 307 discovery [I-D.ietf-anima-grasp] to find Registrar(s) of its 308 domain and potentiall other services. 310 o If the node is part of an ACP and has discovered via GRASP at 311 least one Registrar in its domain, it will start the "join 312 assistant" ASA, and act as a join assistant for neighboring nodes 313 that need to be bootstrapped. See 314 [I-D.ietf-anima-bootstrapping-keyinfra]. 316 o Other behaviours are possible, for example establishing the ACP 317 also with devices of a sub-domain, to other domains, etc. Those 318 will likely be controlled by Intent. They are outside scope for 319 the moment. Note that Intent is distributed through the ACP; 320 therefore, a node can only adapt Intent driven behaviour once it 321 has joined the ACP. At the moment, ANIMA does not consider 322 providing Intent outside the ACP; this can be considered later. 324 Once a node has joined the ACP, it will also learn the ACP addresses 325 of its adjacent nodes, and add them to the adjacency table, to allow 326 for communication inside the ACP. Further autonomic domain 327 interactions will now happen inside the ACP. At this moment, only 328 negotiation / synchronization via GRASP [I-D.ietf-anima-grasp] is 329 being defined. (Note that GRASP runs in the data plane, as an input 330 in building the adjacency table, as well as inside the ACP.) 331 Autonomic Functions consist of Autonomic Service Agents (ASAs). They 332 run logically above the AN Infrastructure, and may use the adjacency 333 table, the ACP, negotiation and synchronization through GRASP in the 334 ACP, Intent and other functions of the ANI. Since the ANI only 335 provides autonomic interactions within a domain, autonomic functions 336 can also use any other context on a node, specifically the global 337 data plane. 339 3.3. State Machine 341 Autonomic Networking applies during the full life-cycle of a node. 342 This section describes a state machine of an autonomic node, 343 throughout its life. 345 3.3.1. State 1: Factory Default 347 An autonomic node is leaving the factory in this state. In this 348 state, the node has no domain specific configuration, specifically no 349 LDevID, and could be used in any particular target network. It does 350 however have a vendor/manufacturer specific ID, the IDevID [IDevID]. 351 Nodes without IDevID cannot be autonomically and securely enrolled 352 into a domain; they require manual pre-staging, in which case the 353 pre-staging takes them directly to state 2. 355 Transitions: 357 o Bootstrap event: The device enrols into a domain; as part of this 358 process it receives a domain identity (LDevID). If enrollment is 359 successful, the next state is state 2. See 360 [I-D.ietf-anima-bootstrapping-keyinfra] Section 3 for details on 361 enrollment. 363 3.3.2. State 2: Enrolled 365 An autonomic node is in the state "enrolled" if it has a domain 366 identity (LDevID). It may have further configuration or state, for 367 example if it had been in state 3 before, but lost all its ACP 368 channels. The LDevID can only be removed from a device through a 369 factory reset, which also removes all other state from the device. 370 This ensures that a device has no stale domain specific state when 371 entering the "enrolled" state from state 1. 373 Transitions: 375 o Joining ACP: The device establishes an ACP channel to an adjacent 376 device. See [I-D.ietf-anima-autonomic-control-plane] for details. 377 Next state: 3. 379 o Factory reset: A factory reset removes all configuration and the 380 domain identity (LDevID) from the device. Next state: 1. 382 3.3.3. State 3: In ACP 384 In this state, the autonomic node has at least one ACP channel to 385 another device. It can participate in further autonomic 386 transactions, such as starting autonomic service agents. For example 387 it must now enable the join assistant ASA, to help other devices to 388 join the domain. Other conditions may apply to such interactions, 389 for example to serve as a join assistant, the device must first 390 discover a bootstrap Registrar. 392 Transitions: 394 o Leaving ACP: The device drops the last (or only) ACP channel to an 395 adjacent device. Next state: 2. 397 o Factory reset: A factory reset removes all configuration and the 398 domain identity (LDevID) from the device. Next state: 1. 400 4. The Autonomic Networking Infrastructure 402 The Autonomic Networking Infrastructure provides a layer of common 403 functionality across an Autonomic Network. It comprises "must 404 implement" functions and services, as well as extensions. 406 An Autonomic Function, comprising of Autonomic Service Agents on 407 nodes, can rely on the fact that all nodes in the network implement 408 at least the "must implement" functions. 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 426 The first three fields are the MAC address, the fourth field is the 427 sequential number for the device. 429 4.2. Addressing 431 Autonomic Service Agents (ASAs) need to communicate with each other, 432 using the autonomic addressing of the Autonomic Networking 433 Infrastructure of the node they reside on. This section describes 434 the addressing approach of the Autonomic Networking Infrastructure, 435 used by ASAs. 437 Out of scope are addressing approaches for the data plane of the 438 network, which may be configured and managed in the traditional way, 439 or negotiated as a service of an ASA. One use case for such an 440 autonomic function is described in 441 [I-D.ietf-anima-prefix-management]. 443 Autonomic addressing is a function of the Autonomic Networking 444 Infrastructure (lower part of Figure 2), specifically the Autonomic 445 Control Plane. ASAs do not have their own addresses. They may use 446 either API calls, or the autonomic addressing scheme of the Autonomic 447 Networking Infrastructure. 449 An autonomic addressing scheme has the following requirements: 451 o Zero-touch for simple networks: Simple networks should have 452 complete self-management of addressing, and not require any 453 central address management, tools, or address planning. 455 o Low-touch for complex networks: If complex networks require 456 operator input for autonomic address management, it should be 457 limited to high level guidance only, expressed in Intent. 459 o Flexibility: The addressing scheme must be flexible enough for 460 nodes to be able to move around, for the network to grow, split 461 and merge. 463 o Robustness: It should be as hard as possible for an administrator 464 to negatively affect addressing (and thus connectivity) in the 465 autonomic context. 467 o Stability: The addressing scheme should be as stable as possible. 468 However, implementations need to be able to recover from 469 unexpected address changes. 471 o Support for virtualization: Autonomic Nodes may support Autonomic 472 Service Agents in different virtual machines or containers. The 473 addressing scheme should support this architecture. 475 o Simplicity: To make engineering simpler, and to give the human 476 administrator an easy way to trouble-shoot autonomic functions. 478 o Scale: The proposed scheme should work in any network of any size. 480 o Upgradability: The scheme must be able to support different 481 addressing concepts in the future. 483 The proposed addressing scheme is described in the document "An 484 Autonomic Control Plane" ([I-D.ietf-anima-autonomic-control-plane]). 486 4.3. Discovery 488 Traditionally, most of the information a node requires is provided 489 through configuration or northbound interfaces. An autonomic 490 function should rely on such northbound interfaces minimally or not 491 at all, and therefore it needs to discover peers and other resources 492 in the network. This section describes various discovery functions 493 in an autonomic network. 495 Discovering nodes and their properties and capabilities: A core 496 function to establish an autonomic domain is the mutual discovery of 497 autonomic nodes, primarily adjacent nodes and secondarily off-link 498 peers. This may in principle either leverage existing discovery 499 mechanisms, or use new mechanisms tailored to the autonomic context. 500 An important point is that discovery must work in a network with no 501 predefined topology, ideally no manual configuration of any kind, and 502 with nodes starting up from factory condition or after any form of 503 failure or sudden topology change. 505 Discovering services: Network services such as AAA should also be 506 discovered and not configured. Service discovery is required for 507 such tasks. An autonomic network can either leverage existing 508 service discovery functions, or use a new approach, or a mixture. 510 Thus the discovery mechanism could either be fully integrated with 511 autonomic signaling (next section) or could use an independent 512 discovery mechanism such as DNS Service Discovery or Service Location 513 Protocol. This choice could be made independently for each Autonomic 514 Service Agent, although the infrastructure might require some minimal 515 lowest common denominator (e.g., for discovering the security 516 bootstrap mechanism, or the source of information distribution, 517 Section 4.7). 519 Phase 1 of Autonomic Networking uses GRASP for discovery, described 520 in [I-D.ietf-anima-grasp]. 522 4.4. Signaling Between Autonomic Nodes 524 Autonomic nodes must communicate with each other, for example to 525 negotiate and/or synchronize technical objectives (i.e., network 526 parameters) of any kind and complexity. This requires some form of 527 signaling between autonomic nodes. Autonomic nodes implementing a 528 specific use case might choose their own signaling protocol, as long 529 as it fits the overall security model. However, in the general case, 530 any pair of autonomic nodes might need to communicate, so there needs 531 to be a generic protocol for this. A prerequisite for this is that 532 autonomic nodes can discover each other without any preconfiguration, 533 as mentioned above. To be generic, discovery and signaling must be 534 able to handle any sort of technical objective, including ones that 535 require complex data structures. The document "A Generic Autonomic 536 Signaling Protocol (GRASP)" [I-D.ietf-anima-grasp] describes more 537 detailed requirements for discovery, negotiation and synchronization 538 in an autonomic network. It also defines a protocol, GRASP, for this 539 purpose, including an integrated but optional discovery protocol. 541 GRASP is normally expected to run inside the Autonomic Control Plane 542 (ACP; see Section 4.6) and to depend on the ACP for security. It may 543 run insecurely for a short time during bootstrapping. 545 An autonomic node will normally run a single instance of GRASP, used 546 by multiple ASAs. However, scenarios where multiple instances of 547 GRASP run in a single node, perhaps with different security 548 properties, are not excluded. 550 4.5. Routing 552 All autonomic nodes in a domain must be able to communicate with each 553 other, and with autonomic nodes outside their own domain. Therefore, 554 an Autonomic Control Plane relies on a routing function. For 555 Autonomic Networks to be interoperable, they must all support one 556 common routing protocol. 558 The routing protocol is defined in the ACP document 559 [I-D.ietf-anima-autonomic-control-plane]. 561 4.6. The Autonomic Control Plane 563 The totality of autonomic interactions forms the "Autonomic Control 564 Plane". This control plane can be either implemented in the global 565 routing table of a node, such as IGPs in today's networks; or it can 566 be provided as an overlay network. The document "An Autonomic 567 Control Plane" ([I-D.ietf-anima-autonomic-control-plane]) describes 568 the details. 570 4.7. Information Distribution (*) 572 Certain forms of information, such as Intent, must be distributed 573 across an autonomic domain. The distribution of information is also 574 a function of the Autonomic Control Plane. One form of such 575 information is Intent. Intent is the policy language of an Autonomic 576 Network; see Section 7.2 for general information on Intent. It is a 577 high level policy, and should change only infrequently (order of 578 days). Therefore, information such as Intent should be simply 579 flooded to all nodes in an autonomic domain, and there is currently 580 no perceived need to have more targeted distribution methods. Intent 581 is also expected to be monolithic, and flooded as a whole. One 582 possible method for distributing Intent, as well as other forms of 583 data, is discussed in [I-D.liu-anima-grasp-distribution]. Intent and 584 information distribution are not part of phase 1 of ANIMA. 586 5. Security and Trust Infrastructure 588 An Autonomic Network is self-protecting. All protocols are secure by 589 default, without the requirement for the administrator to explicitly 590 configure security. 592 Autonomic nodes have direct interactions between themselves, which 593 must be secured. Since an autonomic network does not rely on 594 configuration, it is not an option to configure for example pre- 595 shared keys. A trust infrastructure such as a PKI infrastructure 596 must be in place. This section describes the principles of this 597 trust infrastructure. 599 The default method to automatically bring up a trust infrastructure 600 is defined in the document "Bootstrapping Key Infrastructures" 601 [I-D.ietf-anima-bootstrapping-keyinfra]. The ASAs required for this 602 enrollment process are described in Section 6.3. An autonomic node 603 must implement the enrollment and join assistant ASAs. The registrar 604 ASA may be implemented only on a sub-set of nodes. 606 5.1. Public Key Infrastructure 608 An autonomic domain uses a PKI model. The root of trust is a 609 certification authority (CA). A registrar acts as a registration 610 authority (RA). 612 A minimum implementation of an autonomic domain contains one CA, one 613 Registrar, and network elements. 615 5.2. Domain Certificate 617 Each device in an autonomic domain uses a domain certificate to prove 618 its identity. [I-D.ietf-anima-bootstrapping-keyinfra] describes how 619 a new device receives a domain certificate, and the certificate 620 format. 622 5.3. The MASA 624 The Manufacturer Authorized Signing Authority (MASA) is a trusted 625 service for bootstrapping devices. The purpose of the MASA is to 626 provide ownership tracking of devices in a domain. The MASA provides 627 audit, authorization, and ownership tokens to the registrar during 628 the bootstrap process to assist in the authentication of devices 629 attempting to join an Autonomic Domain, and to allow a joining device 630 to validate whether it is joining the correct domain. The details 631 for MASA service, security, and usage are defined in 632 [I-D.ietf-anima-bootstrapping-keyinfra]. 634 5.4. Sub-Domains (*) 636 By default, sub-domains are treated as different domains. This 637 implies no trust between a domain and its sub-domains, and no trust 638 between sub-domains of the same domain. Specifically, no ACP is 639 built, and Intent is valid only for the domain it is defined for 640 explicitly. 642 In phase 2 of ANIMA, alternative trust models should be defined, for 643 example to allow full or limited trust between domain and sub-domain. 645 5.5. Cross-Domain Functionality (*) 647 By default, different domains do not interoperate, no ACP is built 648 and no trust is implied between them. 650 In the future, models can be established where other domains can be 651 trusted in full or for limited operations between the domains. 653 6. Autonomic Service Agents (ASA) 655 This section describes how autonomic services run on top of the 656 Autonomic Networking Infrastructure. 658 6.1. General Description of an ASA 660 An Autonomic Service Agent (ASA) is defined in [RFC7575] as "An agent 661 implemented on an autonomic node that implements an autonomic 662 function, either in part (in the case of a distributed function) or 663 whole." Thus it is a process that makes use of the features provided 664 by the ANI to achieve its own goals, usually including interaction 665 with other ASAs via the GRASP protocol [I-D.ietf-anima-grasp] or 666 otherwise. Of course it also interacts with the specific targets of 667 its function, using any suitable mechanism. Unless its function is 668 very simple, the ASA will need to be multi-threaded so that it can 669 handle overlapping asynchronous operations. It may therefore be a 670 quite complex piece of software in its own right, forming part of the 671 application layer above the ANI. 673 Thus we can distinguish at least three classes of ASAs: 675 o Simple ASAs with a small footprint that could run anywhere. 677 o Complex, multi-threaded ASAs that have a significant resource 678 requirement and will only run on selected nodes. 680 o A few 'infrastructure ASAs' that use basic ANI features in support 681 of the ANI itself, which must run in all autonomic nodes. These 682 are outlined in the following sections. 684 Autonomic nodes, and therefore their ASAs, will be self-aware. Every 685 autonomic node will be loaded with various functions and ASAs and 686 will be aware of its own capabilities, typically decided by the 687 hardware, firmware or pre-installed software. Its exact role may 688 depend on Intent and on the surrounding network behaviors, which may 689 include forwarding behaviors, aggregation properties, topology 690 location, bandwidth, tunnel or translation properties, etc. The 691 surrounding topology will depend on the network planning. Following 692 an initial discovery phase, the device properties and those of its 693 neighbors are the foundation of the behavior of a specific device. A 694 device and its ASAs have no pre-configuration for the particular 695 network in which they are installed. 697 Since all ASAs will interact with the ANI, they will depend on 698 appropriate application programming interfaces (APIs). It is 699 desirable that ASAs are portable between operating systems, so these 700 APIs need to be universal. An API for GRASP is described in 701 [I-D.liu-anima-grasp-api]. 703 ASAs will in general be designed and coded by experts in a particular 704 technology and use case, not by experts in the ANI and its 705 components. Also, they may be coded in a variety of programming 706 languages, in particular including languages that support object 707 constructs as well as traditional variables and structures. The APIs 708 should be designed with these factors in mind. 710 It must be possible to run ASAs as non-privileged (user space) 711 processes except for those (such as the infrastructure ASAs) that 712 necessarily require kernel privilege. Also, it is highly desirable 713 that ASAs can be dynamically loaded on a running node. 715 Since autonomic systems must be self-repairing, it is of great 716 importance that ASAs are coded using robust programming techniques. 717 All run-time error conditions must be caught, leading to suitable 718 recovery actions, with a complete restart of the ASA as a last 719 resort. Conditions such as discovery failures or negotiation 720 failures must be treated as routine, with the ASA retrying the failed 721 operation, preferably with an exponential back-off in the case of 722 persistent errors. When multiple threads are started within an ASA, 723 these threads must be monitored for failures and hangups, and 724 appropriate action taken. Attention must be given to garbage 725 collection, so that ASAs never run out of resources. There is 726 assumed to be no human operator - again, in the worst case, every ASA 727 must be capable of restarting itself. 729 ASAs will automatically benefit from the security provided by the 730 ANI, and specifically by the ACP and by GRASP. However, beyond that, 731 they are responsible for their own security, especially when 732 communicating with the specific targets of their function. 733 Therefore, the design of an ASA must include a security analysis 734 beyond 'use ANI security.' 736 6.2. ASA Life-Cycle Management 738 ASAs operating on a given ANI may come from different providers and 739 pursue different objectives. Whichever the ASA, its management and 740 its interactions with the ANI must follow the same operating 741 principles, hence comply to a generic life-cycle management model. 743 The ASA life-cycle provides standard processes to: 745 o install ASA: copy the ASA code onto the host and start it, 747 o deploy ASA: associate the ASA instance with a (some) managed 748 network device(s) (or network function), 750 o control ASA execution: when and how an ASA executes its control 751 loop. 753 The life-cyle will cover the sequential states below: Installation, 754 Deployment, Operation and the transitional states in-between. This 755 Life-Cycle will also define which interactions ASAs have with the ANI 756 in between the different states. The noticeable interactions are: 758 o Self-description of ASA instances at the end of deployment: its 759 format needs to define the information required for the management 760 of ASAs by ANI entities 762 o Control of ASA control-loop during the operation: a signaling has 763 to carry formatted messages to control ASA execution (at least 764 starting and stopping control loop) 766 6.3. Specific ASAs for the Autonomic Network Infrastructure 768 The following functions provide essential, required functionality in 769 an autonomic network, and are therefore mandatory to implement on 770 unconstrained autonomic nodes. They are described here as ASAs that 771 include the underlying infrastructure components, but implementation 772 details might vary. 774 The first three together support the trust enrollment process 775 described in Section 5. For details see 776 [I-D.ietf-anima-bootstrapping-keyinfra]. 778 6.3.1. The enrollment ASAs 780 6.3.1.1. The Pledge ASA 782 This ASA includes the function of an autonomic node that bootstraps 783 into the domain with the help of an join assitant ASA (see below). 784 Such a node is known as a Pledge during the enrollment process. This 785 ASA must be installed by default on all nodes that require an 786 autonomic zero-touch bootstrap. 788 6.3.1.2. The Join Assistant ASA 790 This ASA includes the function of an autonomic node that helps a non- 791 enrolled, adjacent devices to enroll into the domain. This ASA must 792 be installed on all nodes, although only one join assistant needs to 793 be active on a given LAN. 795 6.3.1.3. The Join Registrar ASA 797 This ASA includes the join registrar function in an autonomic 798 network. This ASA does not need to be installed on all nodes, but 799 only on nodes that implement the Join Registrar function. 801 6.3.2. The ACP ASA 803 This ASA includes the ACP function in an autonomic network. In 804 particular it acts to discover other potential ACP nodes, and to 805 support the establishment and teardown of ACP channels. This ASA 806 must be installed on all nodes. For details see Section 4.6 and 807 [I-D.ietf-anima-autonomic-control-plane]. 809 6.3.3. The Information Distribution ASA (*) 811 This ASA is currently out of scope in ANIMA, and provided here only 812 as background information. 814 This ASA includes the information distribution function in an 815 autonomic network. In particular it acts to announce the 816 availability of Intent and other information to all other autonomic 817 nodes. This ASA does not need to be installed on all nodes, but only 818 on nodes that implement the information distribution function. For 819 details see Section 4.7. 821 7. Management and Programmability 823 This section describes how an Autonomic Network is managed, and 824 programmed. 826 7.1. How an AN Network Is Managed 828 Autonomic management usually co-exists with traditional management 829 methods in most networks. Thus, autonomic behavior will be defined 830 for individual functions in most environments. In fact, the co- 831 existence is twofold: autonomic functions can use traditional methods 832 and protocols (e.g., SNMP and NETCONF) to perform management tasks; 833 and autonomic functions can conflict with behavior enforced by the 834 same traditional methods and protocols. 836 The autonomic Intent is defined at a high level of abstraction. 837 However, since it is necessary to address individual managed 838 elements, autonomic management needs to communicate in lower-level 839 interactions (e.g., commands and requests). For example, it is 840 expected that the configuration of such elements be performed using 841 NETCONF and YANG modules as well as the monitoring be executed 842 through SNMP and MIBs. 844 Conflict can occur between autonomic default behavior, autonomic 845 Intent, traditional management methods. Conflict resolution is 846 achieved in autonomic management through prioritization [RFC7575]. 847 The rationale is that manual and node-based management have a higher 848 priority over autonomic management. Thus, the autonomic default 849 behavior has the lowest priority, then comes the autonomic Intent 850 (medium priority), and, finally, the highest priority is taken by 851 node-specific network management methods, such as the use of command 852 line interfaces. 854 7.2. Intent (*) 856 Intent is not covered by the ANIMA charter at the time of this 857 writing. This section is for informational purposes only. 859 This section gives an overview of Intent, and how it is managed. 860 Intent and Policy-Based Network Management (PBNM) is already 861 described inside the IETF (e.g., PCIM and SUPA) and in other SDOs 862 (e.g., DMTF and TMF ZOOM). 864 Intent can be described as an abstract, declarative, high-level 865 policy used to operate an autonomic domain, such as an enterprise 866 network [RFC7575]. Intent should be limited to high level guidance 867 only, thus it does not directly define a policy for every network 868 element separately. It is expected Intent definitions from autonomic 869 function(s) and even from traditional network management elements. 871 Intent can be refined to lower level policies using different 872 approaches. This is expected in order to adapt the Intent to the 873 capabilities of managed devices. Intent may contain role or function 874 information, which can be translated to specific nodes [RFC7575]. 875 One of the possible refinements of the Intent is using Event- 876 Condition-Action (ECA) rules. 878 Different parameters may be configured for Intent. These parameters 879 are usually provided by the human operator. Some of these parameters 880 can influence the behavior of specific autonomic functions as well as 881 the way the Intent is used to manage the autonomic domain. 883 Intent is discussed in more detail in [I-D.du-anima-an-intent]. 884 Intent as well as other types of information are distributed via 885 GRASP, see [I-D.liu-anima-grasp-distribution]. 887 7.3. Aggregated Reporting (*) 889 At the time of this writing, aggregated reporting is not in the ANIMA 890 charter. This section is provided for information only. 892 Autonomic Network should minimize the need for human intervention. 893 In terms of how the network should behave, this is done through an 894 autonomic Intent provided by the human administrator. In an 895 analogous manner, the reports which describe the operational status 896 of the network should aggregate the information produced in different 897 network elements in order to present the effectiveness of autonomic 898 Intent enforcement. Therefore, reporting in an autonomic network 899 should happen on a network-wide basis [RFC7575]. 901 Several events can occur in an autonomic network in the same way they 902 can happen in a traditional network. However, when reporting to a 903 human administrator, such events should be aggregated to avoid 904 advertisement about individual managed elements. In this context, 905 algorithms may be used to determine what should be reported (e.g., 906 filtering) and in which way and how different events are related to 907 each other. Besides that, an event in an individual element can be 908 compensated by changes in other elements to maintain a network-wide 909 level which is described in the autonomic Intent. 911 Reporting in an autonomic network may be in the same abstraction 912 level of the Intent. In this context, the visibility on current 913 operational status of an autonomic network can be used to switch to 914 different management modes. Despite the fact that autonomic 915 management should minimize the need for user intervention, possibly 916 there are some events that need to be addressed by human 917 administrator actions. 919 7.4. Feedback Loops to NOC(*) 921 Feedback loops are required in an autonomic network to allow the 922 intervention of a human administrator or central control systems, 923 while maintaining a default behaviour. Through a feedback loop an 924 administrator can be prompted with a default action, and has the 925 possibility to acknowledge or override the proposed default action. 927 7.5. Control Loops (*) 929 Control loops are used in autonomic networking to provide a generic 930 mechanism to enable the Autonomic System to adapt (on its own) to 931 various factors that can change the goals that the Autonomic System 932 is trying to achieve, or how those goals are achieved. For example, 933 as user needs, business goals, and the ANI itself changes, self- 934 adaptation enables the ANI to change the services and resources it 935 makes available to adapt to these changes. 937 Control loops operate to continuously observe and collect data that 938 enables the autonomic management system to understand changes to the 939 behavior of the system being managed, and then provide actions to 940 move the state of the system being managed toward a common goal. 941 Self-adaptive systems move decision-making from static, pre-defined 942 commands to dynamic processes computed at runtime. 944 Most autonomic systems use a closed control loop with feedback. Such 945 control loops SHOULD be able to be dynamically changed at runtime to 946 adapt to changing user needs, business goals, and changes in the ANI. 948 The document [I-D.strassner-anima-control-loops] defines the 949 requirements for an autonomic control loop, describes different types 950 of control loops, and explains how control loops are used in an 951 autonomic system. 953 7.6. APIs (*) 955 Most APIs are static, meaning that they are pre-defined and represent 956 an invariant mechanism for operating with data. An Autonomic Network 957 SHOULD be able to use dynamic APIs in addition to static APIs. 959 A dynamic API is one that retrieves data using a generic mechanism, 960 and then enables the client to navigate the retrieved data and 961 operate on it. Such APIs typically use introspection and/or 962 reflection. Introspection enables software to examine the type and 963 properties of an object at runtime, while reflection enables a 964 program to manipulate the attributes, methods, and/or metadata of an 965 object. 967 APIs MUST be able to express and preserve semantics across different 968 domains. For example, software contracts [Meyer97] are based on the 969 principle that a software-intensive system, such as an Autonomic 970 Network, is a set of communicating components whose interaction is 971 based on precisely-defined specifications of the mutual obligations 972 that interacting components must respect. This typically includes 973 specifying: 975 o pre-conditions that MUST be satisfied before the method can start 976 execution 978 o post-conditions that MUST be satisfied when the method has 979 finished execution 981 o invariant attributes that MUST NOT change during the execution of 982 the method 984 7.7. Data Model (*) 986 The following definitions are taken from [supa-model]: 988 An information model is a representation of concepts of interest to 989 an environment in a form that is independent of data repository, data 990 definition language, query language, implementation language, and 991 protocol. In contrast, a data model is a representation of concepts 992 of interest to an environment in a form that is dependent on data 993 repository, data definition language, query language, implementation 994 language, and protocol (typically, but not necessarily, all three). 996 The utility of an information model is to define objects and their 997 relationships in a technology-neutral manner. This forms a 998 consensual vocabulary that the ANI and ASAs can use. A data model is 999 then a technology-specific mapping of all or part of the information 1000 model to be used by all or part of the system. 1002 A system may have multiple data models. Operational Support Systems, 1003 for example, typically have multiple types of repositories, such as 1004 SQL and NoSQL, to take advantage of the different properties of each. 1005 If multiple data models are required by an Autonomic System, then an 1006 information model SHOULD be used to ensure that the concepts of each 1007 data model can be related to each other without technological bias. 1009 A data model is essential for certain types of functions, such as a 1010 MRACL. More generally, a data model can be used to define the 1011 objects, attributes, methods, and relationships of a software system 1012 (e.g., the ANI, an autonomic node, or an ASA). A data model can be 1013 used to help design an API, as well as any language used to interface 1014 to the Autonomic Network. 1016 8. Coordination Between Autonomic Functions (*) 1018 8.1. The Coordination Problem (*) 1020 Different autonomic functions may conflict in setting certain 1021 parameters. For example, an energy efficiency function may want to 1022 shut down a redundant link, while a load balancing function would not 1023 want that to happen. The administrator must be able to understand 1024 and resolve such interactions, to steer autonomic network performance 1025 to a given (intended) operational point. 1027 Several interaction types may exist among autonomic functions, for 1028 example: 1030 o Cooperation: An autonomic function can improve the behavior or 1031 performance of another autonomic function, such as a traffic 1032 forecasting function used by a traffic allocation function. 1034 o Dependency: An autonomic function cannot work without another one 1035 being present or accessible in the autonomic network. 1037 o Conflict: A metric value conflict is a conflict where one metric 1038 is influenced by parameters of different autonomic functions. A 1039 parameter value conflict is a conflict where one parameter is 1040 modified by different autonomic functions. 1042 Solving the coordination problem beyond one-by-one cases can rapidly 1043 become intractable for large networks. Specifying a common 1044 functional block on coordination is a first step to address the 1045 problem in a systemic way. The coordination life-cycle consists in 1046 three states: 1048 o At build-time, a "static interaction map" can be constructed on 1049 the relationship of functions and attributes. This map can be 1050 used to (pre-)define policies and priorities on identified 1051 conflicts. 1053 o At deploy-time, autonomic functions are not yet active/acting on 1054 the network. A "dynamic interaction map" is created for each 1055 instance of each autonomic functions and on a per resource basis, 1056 including the actions performed and their relationships. This map 1057 provides the basis to identify conflicts that will happen at run- 1058 time, categorize them and plan for the appropriate coordination 1059 strategies/mechanisms. 1061 o At run-time, when conflicts happen, arbitration is driven by the 1062 coordination strategies. Also new dependencies can be observed 1063 and inferred, resulting in an update of the dynamic interaction 1064 map and adaptation of the coordination strategies and mechanisms. 1066 Multiple coordination strategies and mechanisms exists and can be 1067 devised. The set ranges from basic approaches such as random process 1068 or token-based process, to approaches based on time separation and 1069 hierarchical optimization, to more complex approaches such as multi- 1070 objective optimization, and other control theory approaches and 1071 algorithms family. 1073 8.2. A Coordination Functional Block (*) 1075 A common coordination functional block is a desirable component of 1076 the ANIMA reference model. It provides a means to ensure network 1077 properties and predictable performance or behavior such as stability, 1078 and convergence, in the presence of several interacting autonomic 1079 functions. 1081 A common coordination function requires: 1083 o A common description of autonomic functions, their attributes and 1084 life-cycle. 1086 o A common representation of information and knowledge (e.g., 1087 interaction maps). 1089 o A common "control/command" interface between the coordination 1090 "agent" and the autonomic functions. 1092 Guidelines, recommendations or BCPs can also be provided for aspects 1093 pertaining to the coordination strategies and mechanisms. 1095 9. Security Considerations 1097 9.1. Consequences of a Distributed System 1099 An autonomic network consists of autonomic devices that form a 1100 distributed self-managing system. Devices within a domain share a 1101 common trust anchor and thus implicitly trust each other. This means 1102 that any device inside a trust domain can by default use all 1103 distributed functions in the entire autonomic domain in a malicious 1104 way. 1106 An outside attacker has the following generic ways to take control of 1107 an autonomic network: 1109 o Introducing a fake device into the trust domain, by subverting the 1110 authentication methods. This is covered in detail in 1111 [I-D.ietf-anima-bootstrapping-keyinfra]. 1113 o Subverting a device which is already part of a trust domain, and 1114 modifying its behavior. This threat is not specific to the 1115 solution discussed in this document, and applies to all network 1116 solutions. 1118 o Exploiting potentially yet unknown protocol vulnerabilities in the 1119 AN or other protocols. Also this is a generic threat that applies 1120 to all network solutions. 1122 The above threats are in principle comparable to other solutions. 1123 However, the distributed nature of AN, specifically the Autonomic 1124 Control Plane, increases the threat surface. For example, a 1125 compromised device may have full IP reachability to all other devices 1126 inside the ACP, and can use all AN methods and protocols. 1128 For the next phase of the ANIMA work it is therefore recommended to 1129 introduce a sub-domain security model, to reduce the attack surface 1130 and not expose a full domain to a potential intruder. Furthermore, 1131 additional security mechanisms on the ASA level should be considered 1132 for high-risk autonomic functions. 1134 Most AN messages run inside the encrypted ACP. The not protected AN 1135 messages outside the ACP are limited to simple discovery methods. 1136 See Section 2.5.2 of [I-D.ietf-anima-grasp] for a list of such 1137 messages. If AN messages can be observed by a third party, they 1138 might reveal valuable information about network configuration, 1139 security precautions in use, individual users, and their traffic 1140 patterns. If encrypted, AN messages might still reveal some 1141 information via traffic analysis, but this would be quite limited 1142 (for example, this would be highly unlikely to reveal any specific 1143 information about user traffic). 1145 9.2. Security Mechanisms 1147 The components of the ANI must each include appropriate security 1148 mechanisms. In particular, the ACP must provide security against 1149 interception, forgery, and replay of any messages sent over the ACP. 1150 The signaling protocol may rely on this protection, but must also 1151 provide for security when running without an ACP. All components of 1152 the security bootstrap process must of course themselves be secured. 1153 All ASAs must make use of the ANI's security, and must be carefully 1154 designed so that they do not create security "holes" in the boundary 1155 of the whole AN system. 1157 10. IANA Considerations 1159 This document requests no action by IANA. 1161 11. Acknowledgements 1163 Many people have provided feedback and input to this document: Sheng 1164 Jiang, Roberta Maglione, Jonathan Hansford, Jason Coleman. 1166 12. References 1168 [I-D.du-anima-an-intent] 1169 Du, Z., Jiang, S., Nobre, J., Ciavaglia, L., and M. 1170 Behringer, "ANIMA Intent Policy and Format", draft-du- 1171 anima-an-intent-05 (work in progress), February 2017. 1173 [I-D.ietf-anima-autonomic-control-plane] 1174 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 1175 Control Plane", draft-ietf-anima-autonomic-control- 1176 plane-06 (work in progress), March 2017. 1178 [I-D.ietf-anima-bootstrapping-keyinfra] 1179 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1180 S., and K. Watsen, "Bootstrapping Remote Secure Key 1181 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1182 keyinfra-06 (work in progress), May 2017. 1184 [I-D.ietf-anima-grasp] 1185 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1186 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1187 grasp-14 (work in progress), July 2017. 1189 [I-D.ietf-anima-prefix-management] 1190 Jiang, S., Du, Z., Carpenter, B., and Q. Sun, "Autonomic 1191 IPv6 Edge Prefix Management in Large-scale Networks", 1192 draft-ietf-anima-prefix-management-04 (work in progress), 1193 June 2017. 1195 [I-D.liu-anima-grasp-api] 1196 Carpenter, B., Liu, B., Wang, W., and X. Gong, "Generic 1197 Autonomic Signaling Protocol Application Program Interface 1198 (GRASP API)", draft-liu-anima-grasp-api-04 (work in 1199 progress), June 2017. 1201 [I-D.liu-anima-grasp-distribution] 1202 Liu, B. and S. Jiang, "Information Distribution over 1203 GRASP", draft-liu-anima-grasp-distribution-04 (work in 1204 progress), May 2017. 1206 [I-D.strassner-anima-control-loops] 1207 Strassner, J., Halpern, J., and M. Behringer, "The Use of 1208 Control Loops in Autonomic Networking", draft-strassner- 1209 anima-control-loops-01 (work in progress), April 2016. 1211 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 1212 December 2009, . 1215 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1216 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1217 Networking: Definitions and Design Goals", RFC 7575, 1218 DOI 10.17487/RFC7575, June 2015, 1219 . 1221 [RFC7576] Jiang, S., Carpenter, B., and M. Behringer, "General Gap 1222 Analysis for Autonomic Networking", RFC 7576, 1223 DOI 10.17487/RFC7576, June 2015, 1224 . 1226 Authors' Addresses 1228 Michael H. Behringer (editor) 1230 Email: Michael.H.Behringer@gmail.com 1231 Brian Carpenter 1232 Department of Computer Science 1233 University of Auckland 1234 PB 92019 1235 Auckland 1142 1236 New Zealand 1238 Email: brian.e.carpenter@gmail.com 1240 Toerless Eckert 1241 Futurewei Technologies Inc. 1242 2330 Central Expy 1243 Santa Clara 95050 1244 USA 1246 Email: tte@cs.fau.de 1248 Laurent Ciavaglia 1249 Nokia 1250 Villarceaux 1251 Nozay 91460 1252 FR 1254 Email: laurent.ciavaglia@nokia.com 1256 Peloso Pierre 1257 Nokia 1258 Villarceaux 1259 Nozay 91460 1260 FR 1262 Email: pierre.peloso@nokia.com 1264 Bing Liu 1265 Huawei Technologies 1266 Q14, Huawei Campus 1267 No.156 Beiqing Road 1268 Hai-Dian District, Beijing 100095 1269 P.R. China 1271 Email: leo.liubing@huawei.com 1272 Jeferson Campos Nobre 1273 Federal University of Rio Grande do Sul 1274 Av. Bento Goncalves, 9500 1275 Porto Alegre 91501-970 1276 Brazil 1278 Email: jcnobre@inf.ufrgs.br 1280 John Strassner 1281 Huawei Technologies 1282 2330 Central Expressway 1283 Santa Clara, CA 95050 1284 USA 1286 Email: john.sc.strassner@huawei.com