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