idnits 2.17.1 draft-behringer-anima-reference-model-00.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 date (October 17, 2014) is 3451 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-carpenter-anima-gdn-protocol-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-04 Summary: 1 error (**), 0 flaws (~~), 3 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 4 Intended status: Informational B. Carpenter 5 Expires: April 20, 2015 Univ. of Auckland 6 T. Eckert 7 Cisco 8 October 17, 2014 10 A Reference Model for Autonomic Networking 11 draft-behringer-anima-reference-model-00 13 Abstract 15 This document describes a reference model for Autonomic Networking. 16 The goal is to define how the various elements in an autonomic 17 context work together, to describe their interfaces and relations. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 20, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. The Network View . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Entities in an Autonomic Network . . . . . . . . . . . . . . 3 56 3.1. The Network Element . . . . . . . . . . . . . . . . . . . 3 57 3.2. The Registrar Element . . . . . . . . . . . . . . . . . . 4 58 3.3. The MASA . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Trust Infrastructure . . . . . . . . . . . . . . . . . . . . 5 62 7. Autonomic Control Plane . . . . . . . . . . . . . . . . . . . 5 63 7.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.2. Negotiation and Synchronisation . . . . . . . . . . . . . 6 65 7.3. Intent Distribution . . . . . . . . . . . . . . . . . . . 6 66 7.4. Reporting . . . . . . . . . . . . . . . . . . . . . . . . 6 67 7.5. Feedback Loops . . . . . . . . . . . . . . . . . . . . . 6 68 7.6. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Hybrid Approach with Non-Autonomic Functions . . . . . . . . 7 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9.1. Threat Analysis . . . . . . . . . . . . . . . . . . . . . 7 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 12. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 75 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 The document "Autonomic Networking - Definitions and Design Goals" 81 [I-D.irtf-nmrg-autonomic-network-definitions] explains the 82 fundamental concepts behind Autonomic Networking, and defines the 83 relevant terms in this space. In section 5 it describes a high level 84 reference model. This document defines this reference model with 85 more detail, to allow for functional and protocol specifications to 86 be developed in an architecturally consistent, non-overlapping 87 manner. 89 As discussed in [I-D.irtf-nmrg-autonomic-network-definitions], the 90 goal of this work is not to focus exclusively on fully autonomic 91 nodes or networks. In reality, most networks will run with some 92 autonomic functions, while the rest of the network is traditionally 93 managed. This reference model allows for this hybrid approach. 95 2. The Network View 97 This section describes the various elements in a network with 98 autonomic functions, and how these entities work together, on a high 99 level. Subsequent sections explain the detailed inside view for each 100 of the autonomic network elements, as well as the network functions 101 (or interfaces) between those elements. 103 Autonomic entities include: 105 o Network elements: A network element can be a fully or partially 106 autonomic node. It runs autonomic functions, and interacts with 107 other autonomic nodes. 109 o Registrar: Security is a fundamental requirement in an autonomic 110 network. For nodes and services to securely interact without the 111 need to provision shared secrets, a trust infrastructure must be 112 in place. The registrar is the trust anchor in an autonomic 113 domain. 115 o MASA: The MASA is service for devices of a particular vendor. It 116 can validate the identity of devices that are to be used in an 117 autonomic domain, assert which device is owned by which domain, 118 etc. 120 3. Entities in an Autonomic Network 122 This section describes all the elements in an autonomic network, 123 their function, internal organisation and architecture. In the 124 network view in Section 2, this section describes the "boxes". The 125 following sections describes how those boxes interact, and the 126 necessary means to do so (addressing, routing, etc). 128 3.1. The Network Element 130 This section describes an autonomic network element and its internal 131 architecture. The reference model explained in 132 [I-D.irtf-nmrg-autonomic-network-definitions] shows the sources of 133 information that an autonomic service agent can leverage: Self- 134 knowledge, network knowledge (through discovery), Intent, and 135 feedback loops. Fundamentally, there are two levels inside an 136 autonomic node: the level of autonomic service agents, which uses the 137 functions of the autonomic networking infrastructure. Figure 1 138 illustrates this concept. 140 +------------------------------------------------------------+ 141 | | 142 | +-----------+ +------------+ +------------+ | 143 | | Autonomic | | Autonomic | | Autonomic | | 144 | | Service | | Service | | Service | | 145 | | Agent 1 | | Agent 2 | | Agent 3 | | 146 | +-----------+ +------------+ +------------+ | 147 | ^ ^ ^ | 148 | | | | | 149 | V V V | 150 |------------------------------------------------------------| 151 | Autonomic Networking Infrastructure | 152 | - Data structures (ex: certificates, peer information) | 153 | - discovery, negotiation and synchronisation functions | 154 | - intent distribution | 155 | - aggregated reporting and feedback loops | 156 | - routing | 157 |------------------------------------------------------------| 158 | Standard Operating System Functions | 159 +------------------------------------------------------------+ 161 Figure 1 163 The Autonomic Networking Infrastructure (lower part of Figure 1) 164 contains node specific data structures, for example trust information 165 about itself and its peers, as well as a generic set of functions, 166 independent of a particular usage. This infrastructure should be 167 generic, and support a variety of Autonomic Service Agents (upper 168 part of Figure 1). The Autonomic Control Plane is the summary of all 169 interactions of the Autonomic Networking Infrastructure with other 170 nodes and services. 172 The use cases of "Autonomics" such as self-management, self- 173 optimisation, etc, are implemented as Autonomic Service Agents. They 174 use the services and data structures of the underlying autonomic 175 networking infrastructure. The underlying Autonomic Networking 176 Infrastructure should itself be self-managing. 178 3.2. The Registrar Element 180 This section describes the registrar function in an autonomic 181 network. It explains the tasks of a registrar element, and how 182 registrars are placed in a network, redundancy between several, etc. 183 [tbc] 185 3.3. The MASA 187 tbc 189 4. Naming 191 Inside a domain, each autonomic device needs a domain specific 192 identifier. [tbc] 194 5. Addressing 196 tbc 198 6. Trust Infrastructure 200 Autonomic nodes have direct interactions between themselves, which 201 must be secured. Since an autonomic network does not rely on 202 configuration, it is not an option to configure for example pre- 203 shared keys. A trust infrastructure such as a PKI infrastructure 204 must be in place. This section describes the principles of this 205 trust infrastructure. 207 A completely autonomic way to automatically and securely deploy such 208 a trust infrastructure is to set up a trust anchor for the domain, 209 and then use an approach as in the document "Bootstrapping Key 210 Infrastructures" [I-D.pritikin-bootstrapping-keyinfrastructures]. 212 7. Autonomic Control Plane 214 This section describes how autonomic nodes interact. In the network 215 view in Section 2 this section describes the "lines" and "arrows" 216 between nodes. The summary of autonomic interactions forms the 217 "Autonomic Control Plane". This control plane can be either 218 implemented in the global routing table of a node, such as IGPs in 219 today's networks; or it can be provided as an overlay network, as 220 described in [I-D.behringer-autonomic-control-plane]. This section 221 describes the function of the autonomic control plane, independent of 222 its implementation. 224 7.1. Discovery 226 Traditionally, most of the information a node requires is provided 227 through configuration or northbound interfaces. An autonomic 228 function should only minimally rely on such northbound interfaces, 229 therefore it needs to discover resources in the network. This 230 section describes various discovery functions in an autonomic 231 network. 233 Discovering nodes and their properties: A core function to establish 234 an autonomic domain is the discovery of autonomic nodes, primarily 235 adjacent nodes. This may either leverage existing neigbhour 236 discovery mechanisms, or new mechanisms. 238 Discovering services: Network services such as AAA should also be 239 discovered and not configured. Service discovery is required for 240 such tasks. An autonomic network can either leverage existing 241 service discovery functions, or build a new approach. 243 7.2. Negotiation and Synchronisation 245 Autonomic nodes must negotiate and/or synchronise parameters, etc. 246 The document "A Generic Discovery and Negotiation Protocol for 247 Autonomic Networking" [I-D.carpenter-anima-gdn-protocol] explains 248 requirements for negotiation and synchronisation in an autonomic 249 network, and a protocol for this purpose. 251 7.3. Intent Distribution 253 The distribution of intent is also a function of the Autonomic 254 Control Plane. Various methods can be used to distribute intent 255 across an autonomic domain. 257 7.4. Reporting 259 An autonomic network offers through the autonomic control plane the 260 possibility to aggregate information inside the network, before 261 sending it to the admin of the network. While this can be seen or 262 implemented as a specific form of negotiation, the use case is 263 different and therefore mentioned here explicitly. 265 7.5. Feedback Loops 267 Feedback loops are required in an autonomic network to allow 268 administrator intervention, while maintaining a default behaviour. 269 Through a feedback loop an administrator can be prompted with a 270 default action, and has the possibility to acknowledge or override 271 the proposed default action. 273 7.6. Routing 275 All autonomic nodes in a domain must be able to communicate with each 276 other, and with autonomic nodes outside their own domain. Therefore, 277 an Autonomic Control Plane relies on a routing function. 279 8. Hybrid Approach with Non-Autonomic Functions 281 This section explains how autonomic functions can co-exist with non- 282 autonomic functions, and how a potential overlap is managed. (tbc) 284 9. Security Considerations 286 9.1. Threat Analysis 288 This is a preliminary outline of a threat analysis, to be expanded 289 and made more specific as the various Autonomic Networking 290 specifications evolve. 292 Since AN will hand over responsibility for network configuration from 293 humans or centrally established management systems to fully 294 distributed devices, the threat environment is also fully 295 distributed. On the one hand, that means there is no single point of 296 failure to act as an attractive target for bad actors. On the other 297 hand, it means that potentially a single misbehaving autonomic device 298 could launch a widespread attack, by misusing the distributed AN 299 mechanisms. For example, a resource exhaustion attack could be 300 launched by a single device requesting large amounts of that resource 301 from all its peers, on behalf of a non-existent traffic load. 302 Alternatively it could simply send false information to its peers, 303 for example by announcing resource exhaustion when this was not the 304 case. If security properties are managed autonomically, a 305 misbehaving device could attempt a distributed attack by requesting 306 all its peers to reduce security protections in some way. In 307 general, since autonomic devices run without supervision, almost any 308 kind of undesirable management action could in theory by attempted by 309 a misbehaving device. 311 If it is possible for an unauthorised device to act as an autonomic 312 device, or for a malicious third party to inject messages appearing 313 to come from an autonomic device, all these same risks would apply. 315 If AN messages can be observed by a third party, they might reveal 316 valuable information about network configuration, security 317 precautions in use, individual users, and their traffic patterns. If 318 encrypted, AN messages might still reveal some information via 319 traffic analysis, but this would be quite limited (for example, this 320 would be highly unlikely to reveal any specific information about 321 user traffic). AN messages are liable to be exposed to third parties 322 on any unprotected Layer 2 link, and to insider attacks even on 323 protected Layer 2 links. 325 10. IANA Considerations 327 This document requests no action by IANA. 329 11. Acknowledgements 331 tbc 333 12. Change log [RFC Editor: Please remove] 335 00: Initial version. 337 13. References 339 [I-D.behringer-autonomic-control-plane] 340 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 341 Autonomic Control Plane", draft-behringer-autonomic- 342 control-plane-00 (work in progress), June 2014. 344 [I-D.carpenter-anima-gdn-protocol] 345 Carpenter, B., Jiang, S., and B. Liu, "A Generic Discovery 346 and Negotiation Protocol for Autonomic Networking", draft- 347 carpenter-anima-gdn-protocol-00 (work in progress), 348 October 2014. 350 [I-D.irtf-nmrg-autonomic-network-definitions] 351 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 352 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 353 Networking - Definitions and Design Goals", draft-irtf- 354 nmrg-autonomic-network-definitions-04 (work in progress), 355 October 2014. 357 [I-D.pritikin-bootstrapping-keyinfrastructures] 358 Pritikin, M., Behringer, M., and S. Bjarnason, 359 "Bootstrapping Key Infrastructures", draft-pritikin- 360 bootstrapping-keyinfrastructures-01 (work in progress), 361 September 2014. 363 Authors' Addresses 365 Michael H. Behringer (editor) 366 Cisco 368 Email: mbehring@cisco.com 369 Brian Carpenter 370 Department of Computer Science 371 University of Auckland 372 PB 92019 373 Auckland 1142 374 New Zealand 376 Email: brian.e.carpenter@gmail.com 378 Toerless Eckert 379 Cisco 381 Email: eckert@cisco.com