idnits 2.17.1 draft-irtf-nmrg-an-gap-analysis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 1, 2015) is 3275 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-homenet-prefix-assignment-05 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5575 (Obsoleted by RFC 8955) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Management Research Group S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational B. Carpenter 5 Expires: November 2, 2015 Univ. of Auckland 6 M. Behringer 7 Cisco Systems 8 May 1, 2015 10 General Gap Analysis for Autonomic Networking 11 draft-irtf-nmrg-an-gap-analysis-06 13 Abstract 15 This document is a product of the IRTF's Network Management Research 16 Group. It provides a problem statement and general gap analysis for 17 an IP-based Autonomic Network that is mainly based on distributed 18 network devices. The document provides a background by reviewing the 19 current status of autonomic aspects of IP networks and the extent to 20 which current network management depends on centralisation and human 21 administrators. Finally the document outlines the general features 22 missing from current network abilities that are needed in the ideal 23 Autonomic Network concept. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 2, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Automatic and Autonomic Aspects of Current IP Networks . . . 3 62 3.1. IP Address Management and DNS . . . . . . . . . . . . . . 3 63 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3.3. Configuration of Default Router in a Host . . . . . . . . 5 65 3.4. Hostname Lookup . . . . . . . . . . . . . . . . . . . . . 5 66 3.5. User Authentication and Accounting . . . . . . . . . . . 6 67 3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.7. State Synchronization . . . . . . . . . . . . . . . . . . 7 69 4. Current Non-Autonomic Behaviors . . . . . . . . . . . . . . . 7 70 4.1. Building a New Network . . . . . . . . . . . . . . . . . 7 71 4.2. Network Maintenance and Management . . . . . . . . . . . 8 72 4.3. Security Setup . . . . . . . . . . . . . . . . . . . . . 9 73 4.4. Troubleshooting and Recovery . . . . . . . . . . . . . . 9 74 5. Features Needed by Autonomic Networks . . . . . . . . . . . . 10 75 5.1. More Coordination among Devices or Network Partitions . . 11 76 5.2. Reusable Common Components . . . . . . . . . . . . . . . 11 77 5.3. Secure Control Plane . . . . . . . . . . . . . . . . . . 12 78 5.4. Less Configuration . . . . . . . . . . . . . . . . . . . 12 79 5.5. Forecasting and Dry Runs . . . . . . . . . . . . . . . . 13 80 5.6. Benefit from Knowledge . . . . . . . . . . . . . . . . . 13 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 84 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 14 85 10. Informative References . . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 88 1. Introduction 90 The general goals and relevant definitions for Autonomic Networking 91 are discussed in [I-D.irtf-nmrg-autonomic-network-definitions]. In 92 summary, the fundamental goal of an Autonomic Network is self- 93 management, including self-configuration, self-optimization, self- 94 healing and self-protection. Whereas interior gateway routing 95 protocols such as OSPF and IS-IS largely exhibit these properties, 96 most other aspects of networking require top-down configuration, 97 often involving human administrators and a considerable degree of 98 centralisation. In essence Autonomic Networking is putting all 99 network configurations onto the same footing as routing, limiting 100 manual or database-driven configuration to an essential minimum. It 101 should be noted that this is highly unlikely to eliminate the need 102 for human administrators, because many of their essential tasks will 103 remain. The idea is to eliminate tedious and error-prone tasks, for 104 example manual calculations, cross-checking between two different 105 configuration files, or tedious data entry. Higher level operational 106 tasks, and complex trouble-shooting, will remain to be done by 107 humans. 109 This document represents the consensus of the IRTF's network 110 management research group (NMRG). It first provides background by 111 identifying examples of partial autonomic behavior in the Internet, 112 and by describing important areas of non-autonomic behavior. Based 113 on these observations, it then describes missing general mechanisms 114 which would allow autonomic behaviours to be added throughout the 115 Internet. 117 2. Terminology 119 The terminology defined in 120 [I-D.irtf-nmrg-autonomic-network-definitions] is used in this 121 document. 123 3. Automatic and Autonomic Aspects of Current IP Networks 125 This section discusses the history and current status of automatic or 126 autonomic operations in various aspects of network configuration, in 127 order to establish a baseline for the gap analysis. In particular, 128 routing protocols already contain elements of autonomic processes, 129 such as information exchange and state synchronization. 131 3.1. IP Address Management and DNS 133 For many years, there was no alternative to completely manual and 134 static management of IP addresses and their prefixes. Once a site 135 had received an IPv4 address assignment (usually a Class C /24 or 136 Class B /16, and rarely a Class A /8) it was a matter of paper-and- 137 pencil design of the subnet plan (if relevant) and the addressing 138 plan itself. Subnet prefixes were manually configured into routers, 139 and /32 addresses were assigned administratively to individual host 140 computers, and configured manually by system administrators. Records 141 were typically kept in a plain text file or a simple spreadsheet. 143 Clearly this method was clumsy and error-prone as soon as a site had 144 more than a few tens of hosts, but it had to be used until DHCP 146 [RFC2131] became a viable solution during the second half of the 147 1990s. DHCP made it possible to avoid manual configuration of 148 individual hosts (except, in many deployments, for a small number of 149 servers configured with static addresses). Even so, prefixes had to 150 be manually assigned to subnets and their routers, and DHCP servers 151 had to be configured accordingly. 153 In terms of management, there is a linkage between IP address 154 management and DNS management, because DNS mappings typically need to 155 be appropriately synchronized with IP address assignments. At 156 roughly the same time as DHCP came into widespread use, it became 157 very laborious to manually maintain DNS source files in step with IP 158 address assignments. Because of reverse DNS lookup, it also became 159 necessary to synthesise DNS names even for hosts that only played the 160 role of clients. Therefore, it became necessary to synchronise DHCP 161 server tables with forward and reverse DNS. For this reason, 162 Internet Protocol address management tools emerged, as discussed for 163 the case of renumbering in [RFC7010]. These are, however, 164 centralised solutions that do not exhibit autonomic properties as 165 defined in [I-D.irtf-nmrg-autonomic-network-definitions]. 167 A related issue is prefix delegation, especially in IPv6 when more 168 than one prefix may be delegated to the same physical subnet. DHCPv6 169 Prefix Delegation [RFC3633] is a useful solution, but it requires 170 specific configuration so cannot be considered autonomic. How this 171 topic is to be handled in home networks is still in discussion 172 [I-D.ietf-homenet-prefix-assignment]. Still further away is 173 autonomic assignment and delegation of routeable IPv4 subnet 174 prefixes. 176 An IPv6 network needs several aspects of host address assignments to 177 be configured. The network might use stateless address 178 autoconfiguration [RFC4862] or DHCPv6 [RFC3315] in stateless or 179 stateful modes, and there are various alternative forms of Interface 180 Identifier [RFC7136]. 182 Another feature is the possibility of Dynamic DNS Update [RFC2136]. 183 With appropriate security, this is an automatic approach, where no 184 human intervention is required to create the DNS records for a host 185 after it acquires a new address. However, there are coexistence 186 issues with a traditional DNS setup, as described in [RFC7010]. 188 3.2. Routing 190 Since a very early stage, it has been a goal that Internet routing 191 should be self-healing when there is a failure of some kind in the 192 routing system (i.e. a link or a router goes wrong). Also, the 193 problem of finding optimal routes through a network was identified 194 many years ago as a problem in mathematical graph theory, for which 195 well known algorithms were discovered (the Dijkstra and Bellman-Ford 196 algorithms). Thus routing protocols became largely autonomic from 197 the start, as it was clear that manual configuration of routing 198 tables for a large network was impractical. 200 IGP routers do need some initial configuration data to start up the 201 autonomic routing protocol. Also, BGP-4 routers need detailed static 202 configuration of routing policy data. 204 3.3. Configuration of Default Router in a Host 206 Originally this was a manual operation. Since the deployment of 207 DHCP, this has been automatic as far as most IPv4 hosts are 208 concerned, but the DHCP server must be appropriately configured. In 209 simple environments such as a home network, the DHCP server resides 210 in the same box as the default router, so this configuration is also 211 automatic. In more complex environments, where an independent DHCP 212 server or a local DHCP relay is used, DHCP configuration is more 213 complex and not automatic. 215 In IPv6 networks, the default router is provided by Router 216 Advertisement messages [RFC4861] from the router itself, and all IPv6 217 hosts make use of it. The router may also provide more complex Route 218 Information Options. The process is essentially autonomic as far as 219 all IPv6 hosts are concerned, and DHCPv6 is not involved. However, 220 there are still open issues when more than one prefix is in use on a 221 subnet and more than one first-hop router may be available as a 222 result (see for example [RFC6418]). 224 3.4. Hostname Lookup 226 Originally host names were looked up in a static table, often 227 referred to as "hosts.txt" from its traditional file name. When the 228 DNS was deployed during the 1980s, all hosts needed DNS resolver 229 code, and needed to be configured with the IP addresses (not the 230 names) of suitable DNS servers. Like the default router, these were 231 originally manually configured. Today, they are provided 232 automatically via DHCP or DHCPv6 [RFC3315]. For IPv6 end systems, 233 there is also a way for them to be provided automatically via a 234 Router Advertisement option. However, the DHCP or DHCPv6 server, or 235 the IPv6 router, need to be configured with the appropriate DNS 236 server addresses. Additionally, some networks deploy Multicast DNS 237 [RFC6762] locally to provide additional automation of the name space. 239 3.5. User Authentication and Accounting 241 Originally, user authentication and accounting was mainly based on 242 physical connectivity and the degree of trust that follows from 243 direct connectivity. Network operators charged based on the set up 244 of dedicated physical links with users. Automated user 245 authentication was introduced by Point-to-Point Protocol [RFC1661], 246 [RFC1994] and RADIUS protocol [RFC2865], [RFC2866] in the early 247 1990s. As long as a user completes online authentication through the 248 RADIUS protocol, the accounting for that user starts on the 249 corresponding AAA server automatically. This mechanism enables 250 business models with charging based on traffic based or time based 251 usage. However, the management of user authentication information 252 remains manual by network administrators. It also becomes complex in 253 the case of mobile users who roam between operators, since prior 254 relationships between the operators are needed. 256 3.6. Security 258 Security has many aspects that need configuration and are therefore 259 candidates to become autonomic. On the other hand, it is essential 260 that a network's central policy should be applied strictly for all 261 security configurations. As a result security has largely been based 262 on centrally imposed configurations. 264 Many aspects of security depend on policy, for example password 265 rules, privacy rules, firewall rulesets, intrusion detection and 266 prevention settings, VPN configurations, and the choice of 267 cryptographic algorithms. Policies are by definition human made and 268 will therefore also persist in an autonomic environment. However, 269 policies are becoming more high-level, abstracting addressing for 270 example, and focusing on the user or application. The methods to 271 manage, distribute and apply policy, and to monitor compliance and 272 violations could be autonomic. 274 Today, many security mechanisms show some autonomic properties. For 275 example user authentication via 802.1x allows automatic mapping of 276 users after authentication into logical contexts (typically VLANs). 277 While today configuration is still very important, the overall 278 mechanism displays signs of self-adaption to changing situations. 280 BGP Flowspec [RFC5575] allows a partially autonomic threat defense 281 mechanism, where threats are identified, the flow information is 282 automatically distributed, and counter-actions can be applied. Today 283 typically a human operator is still in the loop to check correctness, 284 but over time such mechanisms can become more autonomic. 286 Negotiation capabilities, present in many security protocols, also 287 display simple autonomic behaviours. In this case a security policy 288 about algorithm strength can be configured into servers but will 289 propagate automatically to clients. 291 3.7. State Synchronization 293 Another area where autonomic processes between peers are involved is 294 state synchronization. In this case, several devices start out with 295 inconsistent state and go through a peer-to-peer procedure after 296 which their states are consistent. Many autonomic or automatic 297 processes include some degree of implicit state synchronization. 298 Network time synchronization [RFC5905] is a well-established explicit 299 example, guaranteeing that a participating node's clock state is 300 synchronized with reliable time servers within a defined margin of 301 error, without any overall point of control of the synchronization 302 process. 304 4. Current Non-Autonomic Behaviors 306 In current networks, many operations are still heavily dependent on 307 human intelligence and decision, or on centralised top-down network 308 management systems. These operations are the targets of Autonomic 309 Networking technologies. The ultimate goal of Autonomic Networking 310 is to replace human and automated operations by autonomic functions, 311 so that the networks can run independently without depending on a 312 human or NMS system for routine details, while maintaining central 313 control where required. Of course, there would still be the absolute 314 minimum of human input required, particularly during the network 315 building stage, and during emergencies and difficult trouble- 316 shooting. 318 This section analyzes the existing human and central dependencies in 319 typical current networks and suggests cases where they could in 320 principle be replaced by autonomic behaviors. 322 4.1. Building a New Network 324 Building a network requires the operator to analyze the requirements 325 of the new network, design a deployment architecture and topology, 326 decide device locations and capacities, set up hardware, design 327 network services, choose and enable required protocols, configure 328 each device and each protocol, set up central user authentication and 329 accounting policies and databases, design and deploy security 330 mechanisms, etc. 332 Overall, these jobs are quite complex work that cannot become fully 333 autonomic in the foreseeable future. However, part of these jobs may 334 be able to become autonomic, such as detailed device and protocol 335 configurations and database population. The initial network 336 management policies/behaviors may also be transplanted from other 337 networks and automatically localized. 339 4.2. Network Maintenance and Management 341 Network maintenance and management are very different for ISP 342 networks and enterprise networks. ISP networks have to change much 343 more frequently than enterprise networks, given the fact that ISP 344 networks have to serve a large number of customers who have very 345 diversified requirements. The current rigid model is that network 346 administrators design a limited number of services for customers to 347 order. New requirements of network services may not be able to be 348 met quickly by human management. Given a real-time request, the 349 response must be autonomic, in order to be flexible and quickly 350 deployed. However, behind the interface, describing abstracted 351 network information and user authorization management may have to 352 depend on human intelligence from network administrators in the 353 foreseeable future. User identification integration/consolidation 354 among networks or network services is another challenge for Autonomic 355 Network access. Currently, many end users have to manually manage 356 their user accounts and authentication information when they switch 357 among networks or network services. 359 Classical network maintenance and management mainly manages the 360 configuration of network devices. Tools have been developed to 361 enable remote management and make such management easier. However, 362 the decision about each configuration detail depends either on human 363 intelligence or rigid templates. One or the other of these is 364 therefore the source of all network configuration errors - either the 365 human was wrong, or the template was wrong (or both). This is also a 366 barrier to increasing the utility of network resources, because the 367 human managers cannot respond quickly enough to network events, such 368 as traffic bursts, that were not foreseen in the template. For 369 example, currently, a light load is often assumed in network design 370 because there is no mechanism to properly handle a sudden traffic 371 flood. It is therefore common to avoid performance collapses caused 372 by traffic overload by configuring idle resources, with an 373 overprovisioning ratio of at least 2 being normal [Xiao02]. 375 There are grounds for concern that the introduction of new, more 376 flexible, methods of network configuration, typified by software- 377 defined networking (SDN), will only make the management problem more 378 complex unless the details are managed automatically or 379 autonomically. There is no doubt that SDN creates both the necessity 380 and the opportunity for automation of configuration management, e.g., 382 [Kim13]. This topic is discussed from a service provider viewpoint 383 in [RFC7149]. 385 Autonomic decision processes for configuration would enable dynamic 386 management of network resources (by managing resource-relevant 387 configuration). Self-adapting network configuration would adjust the 388 network into the best possible situation, which also prevents 389 configuration errors from having lasting impact. 391 4.3. Security Setup 393 Setting up security for a network generally requires very detailed 394 human intervention, or relies entirely on default configurations that 395 may be too strict or too risky for the particular situation of the 396 network. While some aspects of security are intrinsically top-down 397 in nature (e.g. broadcasting a specific security policy to all 398 hosts), others could be self-managed within the network. 400 In an Autonomic Network, where nodes within a domain have a mutually 401 verifiable domain identity, security processes could run entirely 402 automatically. Nodes could identify each other securely, negotiating 403 required security settings and even shared keys if needed. The 404 location of trust anchors (certificate authority, registration 405 authority), certificate revocation lists, policy server, etc., can be 406 found by service discovery. Transactions such as a certificate 407 revocation list download can be authenticated via a common trust 408 anchor. Policy distribution can also be entirely automated, and 409 secured via a common trust anchor. 411 These concepts lead to a network where the intrinsic security is 412 automatic and applied by default, i.e., a "self-protecting" network. 413 For further discussion, see [I-D.behringer-default-secure] 415 4.4. Troubleshooting and Recovery 417 Current networks suffer difficulties in locating the cause of network 418 failures. Although network devices may issue many warnings while 419 running, most of them are not sufficiently precise to be identified 420 as errors. Some of them are early warnings that would not develop 421 into real errors. Others are in effect random noise. During a major 422 failure, many different devices will issue multiple warnings within a 423 short time, causing overload for the NMS and the operators. However, 424 for many scenarios, human experience is still vital to identify real 425 issues and locate them. This situation may be improved by 426 automatically associating warnings from multiple network devices 427 together. Also, introducing automated learning techniques (comparing 428 current warnings with historical relationships between warnings and 429 actual faults) could increase the possibility and success rate of 430 Autonomic Network diagnoses and troubleshooting. 432 Depending on the network errors, some of them may always require 433 human interventions, particularly for hardware failures. However, 434 autonomic network management behavior may help to reduce the impact 435 of errors, for example by switching traffic flows around. Today this 436 is usually manual (except for classical routing updates). Fixing 437 software failures and configuration errors currently depends on 438 humans, and may even involve rolling back software versions and 439 rebooting hardware. Such problems could be autonomically corrected 440 if there were diagnostics and recovery functions defined in advance 441 for them. This would fulfill the concept of self-healing. 443 Another possible autonomic function is predicting device failures or 444 overloads before they occur. A device could predict its own failure 445 and warn its neighbors; or a device could predict its neighbor's 446 failure. In either case, an Autonomic Network could respond as if 447 the failure had already occurred by routing around the problem and 448 reporting the failure, with no disturbance to users. The criteria 449 for predicting failure could be temperature, battery status, bit 450 error rates, etc. The criteria for predicting overload could be 451 increasing load factor, latency, jitter, congestion loss, etc. 453 5. Features Needed by Autonomic Networks 455 There are innumerable properties of network devices and end systems 456 that today need to be configured either manually, by scripting, or by 457 using a management protocol such as NETCONF [RFC6241]. In an 458 Autonomic Network, all of these would need to either have 459 satisfactory default values or be configured automatically. Some 460 examples are parameters for tunnels of various kinds, flows (in an 461 SDN context), quality of service, service function chaining, energy 462 management, system identification and NTP configuration, but the list 463 is endless. 465 The task of Autonomic Networking is to incrementally build up 466 individual autonomic processes that could progressively be combined 467 to respond to every type of network event. Building on the preceding 468 background information, and on the reference model in 469 [I-D.irtf-nmrg-autonomic-network-definitions], this section outlines 470 the gaps and missing features in general terms, and in some cases 471 mentions general design principles that should apply. 473 5.1. More Coordination among Devices or Network Partitions 475 Network services are dependent on a number of devices and parameters 476 to be in place in a certain order. For example after a power failure 477 a coordinated sequence of "return to normal" operations is desirable 478 (e.g., switches and routers first, DNS servers second, etc.). Today, 479 the correct sequence of events is either known only by a human 480 administrator, or automated in a central script. In a truly 481 Autonomic Network, elements should understand their dependencies, and 482 be able to resolve them locally. 484 In order to make right or good decisions autonomically, the network 485 devices need to know more information than just reachability 486 (routing) information from the relevant or neighbor devices. There 487 are dependencies between such information and configurations, which 488 devices must be able to derive for themselves. 490 There are therefore increased requirements for horizontal information 491 exchange in the networks. Particularly, three types of interaction 492 among peer network devices are needed for autonomic decisions: 493 discovery (to find neighbours and peers), synchronization (to agree 494 on network status) and negotiation (when things need to be changed). 495 Thus there is a need for reusable discovery, synchronization and 496 negotiation mechanisms, which would support the discovery of many 497 different types of device, the synchronization of many types of 498 parameter and the negotiation of many different types of objective. 500 5.2. Reusable Common Components 502 Elements of autonomic functions already exist today, within many 503 different protocols. However, all such functions have their own 504 discovery, transport, messaging and security mechanisms as well as 505 non-autonomic management interfaces. Each protocol has its own 506 version of the above-mentioned functions to serve specific and narrow 507 purposes. It is often difficult to extend an existing protocol to 508 serve different purposes. Therefore, in order to provide the 509 reusable discovery, synchronization and negotiation mechanism 510 mentioned above, it is desirable to develop a set of reusable common 511 protocol components for Autonomic Networking. These components 512 should be: 514 o Able to identify other devices, users and processes securely. 516 o Able to automatically secure operations, based on the above 517 identity scheme. 519 o Able to manage any type of information and information flows. 521 o Able to discover peer devices and services for various autonomic 522 service agents (or autonomic functions). 524 o Able to support closed-loop operations when needed to provide 525 self-managing functions involving more than one device. 527 o Separable from the specific autonomic service agents (or autonomic 528 functions). 530 o Reusable by other autonomic functions. 532 5.3. Secure Control Plane 534 The common components will in effect act as a control plane for 535 autonomic operations. This control plane might be implemented in- 536 band as functions of the target network, in an overlay network, or 537 even out-of-band in a separate network. Autonomic operations will be 538 capable of changing how the network operates and allocating resources 539 without human intervention or knowledge, so it is essential that they 540 are secure. Therefore the control plane must be designed to be 541 secure against forged autonomic operations and man-in-the middle 542 attacks, and as secure as reasonably possible against denial of 543 service attacks. It must be decided whether the control plane needs 544 to be resistant to unwanted monitoring, i.e., whether encryption is 545 required. 547 5.4. Less Configuration 549 Many existing protocols have been defined to be as flexible as 550 possible. Consequently, these protocols need numerous initial 551 configurations to start operations. There are choices and options 552 that are irrelevant in any particular case, some of which target 553 corner cases. Furthermore, in protocols that have existed for years, 554 some design considerations are no longer relevant, since the 555 underlying hardware technologies have evolved meanwhile. To 556 appreciate the scale of this problem, consider that more than 160 557 DHCP otions have been defined for IPv4. Even sample router 558 configuration files readily available on line contain more than 200 559 lines of commands. There is therefore considerable scope for 560 simplifying the operational tools for configuration of common 561 protocols, even if the underlying protocols themselves cannot be 562 simplified. 564 From another perspective, the deep reason why human decisions are 565 often needed mainly result from the lack of information. When a 566 device can collect enough information horizontally from other 567 devices, it should be able to decide many parameters by itself, 568 instead of receiving them from top-down configuration. 570 It is desired that top-down management is reduced in Autonomic 571 Networking. Ideally, only the abstract Intent is needed from the 572 human administrators. Neither users nor administrators should need 573 to create and maintain detailed policies and profiles; if they are 574 needed, they should be built autonomically. The local parameters 575 should be decided by distributed Autonomic Nodes themselves, either 576 from historic knowledge, analytics of current conditions, closed 577 logical decision loops, or a combination of all. 579 5.5. Forecasting and Dry Runs 581 In a conventional network, there is no mechanism for trying something 582 out safely. That means that configuration changes have to be 583 designed in the abstract and their probable effects have to be 584 estimated theoretically. In principle, an alternative to this would 585 be to test the changes on a complete and realistic network simulator. 586 However, this is a practical impossibility for a large network which 587 is constantly changing, even if an accurate simulation could be 588 performed. There is therefore a risk that applying changes to a 589 running network will cause a failure of some kind. An autonomic 590 network could fill this gap by supporting a closed loop "dry run" 591 mode in which each configuration change could be tested out 592 dynamically in the control plane without actually affecting the data 593 plane. If the results are satisfactory, the change could be made 594 live on the running network. If there is a consistency problem such 595 as over-commitment of resources or incompatibility with another 596 configuration setting, the change could be rolled back dynamically 597 with no impact on traffic or users. 599 5.6. Benefit from Knowledge 601 The more knowledge and experience we have, the better decisions we 602 can take. It is the same for networks and network management. When 603 one component in the network lacks knowledge that affects what it 604 should do, and another component has that knowledge, we usually rely 605 on a human operator or a centralised management tool to convey the 606 knowledge. 608 Up to now, the only available network knowledge is usually the 609 current network status inside a given device or relevant current 610 status from other devices. 612 However, historic knowledge is very helpful to make correct 613 decisions, in particular to reduce network oscillation or to manage 614 network resources over time. Transplantable knowledge from other 615 networks can be helpful to initially set up a new network or new 616 network devices. Knowledge of relationships between network events 617 and network configuration may help a network to decide the best 618 parameters according to real performance feedback. 620 In addition to such historic knowledge, powerful data analytics of 621 current network conditions may also be a valuable source of knowledge 622 that can be exploited directly by Autonomic Nodes. 624 6. Security Considerations 626 This document is focused on what is missing to allow autonomic 627 network configuration, including of course security settings. 628 Therefore, it does not itself create any new security issues. It is 629 worth underlining that autonomic technology must be designed with 630 strong security properties from the start, since a network with 631 vulnerable autonomic functions would be at great risk. 633 7. IANA Considerations 635 This memo includes no request to IANA. 637 8. Acknowledgements 639 The authors would like to acknowledge the valuable comments made by 640 participants in the IRTF Network Management Research Group. Reviews 641 by Kevin Fall and Rene Struik were especially helpful. 643 This document was produced using the xml2rfc tool [RFC2629]. 645 9. Change log [RFC Editor: Please remove] 647 draft-irtf-nmrg-an-gap-analysis-06: RFC Editor comments actioned, 648 2015-05-01. 650 draft-irtf-nmrg-an-gap-analysis-05: IESG Review comments actioned, 651 2015-03-23. 653 draft-irtf-nmrg-an-gap-analysis-04: Additional IRSG Review comments 654 actioned, 2015-03-04. 656 draft-irtf-nmrg-an-gap-analysis-03: IRSG Review comments actioned, 657 2014-12-11. 659 draft-irtf-nmrg-an-gap-analysis-02: Review comments actioned, 660 2014-10-02. 662 draft-irtf-nmrg-an-gap-analysis-01: RG comments added and more 663 content in "Approach toward Autonomy" section, 2014-08-30. 665 draft-irtf-nmrg-an-gap-analysis-00: RG comments added, 2014-04-02. 667 draft-jiang-nmrg-an-gap-analysis-00: original version, 2014-02-14. 669 10. Informative References 671 [I-D.behringer-default-secure] 672 Behringer, M., Pritikin, M., and S. Bjarnason, "Making The 673 Internet Secure By Default", draft-behringer-default- 674 secure-00 (work in progress), January 2014. 676 [I-D.ietf-homenet-prefix-assignment] 677 Pfister, P., Paterson, B., and J. Arkko, "Distributed 678 Prefix Assignment Algorithm", draft-ietf-homenet-prefix- 679 assignment-05 (work in progress), April 2015. 681 [I-D.irtf-nmrg-autonomic-network-definitions] 682 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 683 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 684 Networking - Definitions and Design Goals", draft-irtf- 685 nmrg-autonomic-network-definitions-07 (work in progress), 686 March 2015. 688 [Kim13] Kim, H. and N. Feamster, "Improving Network Management 689 with Software Defined Networking", IEEE Communications 690 Magazine, Pages 114-119, February 2013. 692 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 693 RFC 1661, July 1994. 695 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 696 Protocol (CHAP)", RFC 1994, August 1996. 698 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 699 2131, March 1997. 701 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 702 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 703 RFC 2136, April 1997. 705 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 706 June 1999. 708 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 709 "Remote Authentication Dial In User Service (RADIUS)", RFC 710 2865, June 2000. 712 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 714 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 715 and M. Carney, "Dynamic Host Configuration Protocol for 716 IPv6 (DHCPv6)", RFC 3315, July 2003. 718 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 719 Host Configuration Protocol (DHCP) version 6", RFC 3633, 720 December 2003. 722 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 723 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 724 September 2007. 726 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 727 Address Autoconfiguration", RFC 4862, September 2007. 729 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 730 and D. McPherson, "Dissemination of Flow Specification 731 Rules", RFC 5575, August 2009. 733 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 734 Time Protocol Version 4: Protocol and Algorithms 735 Specification", RFC 5905, June 2010. 737 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 738 Bierman, "Network Configuration Protocol (NETCONF)", RFC 739 6241, June 2011. 741 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 742 Provisioning Domains Problem Statement", RFC 6418, 743 November 2011. 745 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 746 February 2013. 748 [RFC7010] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. 749 George, "IPv6 Site Renumbering Gap Analysis", RFC 7010, 750 September 2013. 752 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 753 Interface Identifiers", RFC 7136, February 2014. 755 [RFC7149] Boucadair, M. and C. Jacquenet, "Software-Defined 756 Networking: A Perspective from within a Service Provider 757 Environment", RFC 7149, March 2014. 759 [Xiao02] Xiao, X. and others, "A Practical Approach for Providing 760 QoS in the Internet Backbone", IEEE Communications 761 Magazine, Pages 56-59, December 2002. 763 Authors' Addresses 765 Sheng Jiang 766 Huawei Technologies Co., Ltd 767 Q14, Huawei Campus, No.156 Beiqing Road 768 Hai-Dian District, Beijing, 100095 769 P.R. China 771 Email: jiangsheng@huawei.com 773 Brian Carpenter 774 Department of Computer Science 775 University of Auckland 776 PB 92019 777 Auckland 1142 778 New Zealand 780 Email: brian.e.carpenter@gmail.com 782 Michael H. Behringer 783 Cisco Systems 784 Building D, 45 Allee des Ormes 785 Mougins 06250 786 France 788 Email: mbehring@cisco.com