idnits 2.17.1 draft-ietf-anima-stable-connectivity-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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2016) is 3023 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.behringer-anima-reference-model' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-autonomic-control-plane' is defined on line 691, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-bootstrapping-keyinfra' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-an-gap-analysis' is defined on line 702, but no explicit reference was found in the text == Unused Reference: 'I-D.irtf-nmrg-autonomic-network-definitions' is defined on line 707, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 714, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-01 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA T. Eckert 3 Internet-Draft M. Behringer 4 Intended status: Informational Cisco 5 Expires: July 16, 2016 January 13, 2016 7 Using Autonomic Control Plane for Stable Connectivity of Network OAM 8 draft-ietf-anima-stable-connectivity-00 10 Abstract 12 OAM (Operations, Administration and Management) processes for data 13 networks are often subject to the problem of circular dependencies 14 when relying on network connectivity of the network to be managed for 15 the OAM operations itself. Provisioning during device/network bring 16 up tends to be far less easy to automate than service provisioning 17 later on, changes in core network functions impacting reachability 18 can not be automated either because of ongoing connectivity 19 requirements for the OAM equipment itself, and widely used OAM 20 protocols are not secure enough to be carried across the network 21 without security concerns. 23 This document describes how to integrate OAM processes with the 24 autonomic control plane (ACP) in Autonomic Networks (AN). to provide 25 stable and secure connectivity for those OAM processes. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 16, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Self dependent OAM connectivity . . . . . . . . . . . . . 2 63 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 64 1.3. Leveraging the ACP . . . . . . . . . . . . . . . . . . . 3 65 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Stable connectivity for centralized OAM operations . . . 4 67 2.1.1. Simple connectivity for non-autonomic NOC application 68 devices . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.1.2. Limitations and enhancement overview . . . . . . . . 5 70 2.1.3. Simultaneous ACP and data plane connectivity . . . . 6 71 2.1.4. IPv4 only NOC application devices . . . . . . . . . . 7 72 2.1.5. Path selection policies . . . . . . . . . . . . . . . 8 73 2.1.6. Autonomic NOC device/applications . . . . . . . . . . 10 74 2.1.7. Encryption of data-plane connections . . . . . . . . 10 75 2.1.8. Long term direction of the solution . . . . . . . . . 11 76 2.2. Stable connectivity for distributed network/OAM functions 12 77 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 4. No IPv4 for ACP . . . . . . . . . . . . . . . . . . . . . . . 14 79 5. Further considerations . . . . . . . . . . . . . . . . . . . 14 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 82 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 1.1. Self dependent OAM connectivity 90 OAM (Operations, Administration and Management) processes for data 91 networks are often subject to the problem of circular dependencies 92 when relying on network connectivity of the network to be managed for 93 the OAM operations itself: 95 The ability to perform OAM operations on a network device requires 96 first the execution of OAM procedures necessary to create network 97 connectivity to that device in all intervening devices. This 98 typically leads to sequential, 'expanding ring configuration' from a 99 NOC. It also leads to tight dependencies between provisioning tools 100 and security enrollment of devices. Any process that wants to enroll 101 multiple devices along a newly deployed network topology needs to 102 tightly interlock with the provisioning process that creates 103 connectivity before the enrollment can move on to the next device. 105 When performing change operations on a network, it likewise is 106 necessary to understand at any step of that process that there is no 107 interruption of connectivity that could lead to removal of 108 connectivity to remote devices. This includes especially change 109 provisioning of routing, security and addressing policies in the 110 network that often occur through mergers and acquisitions, the 111 introduction of IPv6 or other mayor re-hauls in the infrastructure 112 design. 114 All this circular dependencies make OAM processes complex and 115 potentially fragile. When automation is being used, for example 116 through provisioning systems or network controllers, this complexity 117 extends into that automation software. 119 1.2. Data Communication Networks (DCNs) 121 In the late 1990'th and early 2000, IP networks became the method of 122 choice to build separate OAM networks for the communications 123 infrastructure in service providers. This concept was standardized 124 in G.7712/Y.1703 and called "Data Communications Networks" (DCN). 125 These where (and still are) physically separate IP(/MPLS) networks 126 that provide access to OAM interfaces of all equipment that had to be 127 managed, from PSTN switches over optical equipment to nowadays 128 ethernet and IP/MPLS production network equipment. 130 Such DCN provide stable connectivity not subject to aforementioned 131 problems because they are separate network entirely, so change 132 configuration of the production IP network is done via the DCN but 133 never affects the DCN configuration. Of course, this approach comes 134 at a cost of buying and operating a separate network and this cost is 135 not feasible for many networks, most notably smaller service 136 providers, most enterprises and typical IoT networks. 138 1.3. Leveraging the ACP 140 One goal of the Autonomic Networks Autonomic Control plane (ACP) is 141 to provide similar stable connectivity as a DCN, but without having 142 to build a separate DCN. It is clear that such 'in-band' approach 143 can never achieve fully the same level of separation, but the goal is 144 to get as close to it as possible. 146 This solution approach has several aspects. One aspect is designing 147 the implementation of the ACP in network devices to make it actually 148 perform without interruption by changes in what we will call in this 149 document the "data-plane", aka: the operator or controller configured 150 services planes of the network equipment. This aspect is not 151 currently covered in this document. 153 Another aspect is how to leverage the stable IPv6 connectivity 154 provided by the ACP to build actual OAM solutions. This is the 155 current scope of this document. 157 2. Solutions 159 2.1. Stable connectivity for centralized OAM operations 161 In the most common case, OAM operations will be performed by one or 162 more applications running on a variety of centralized NOC systems 163 that communicate with network devices. We describe differently 164 advanced approaches to leverage the ACP for stable connectivity 165 leveraging the ACP. The descriptions will show that there is a wide 166 range of options, some of which are simple, some more complex. 168 Most easily we think there are three stages of interest: 170 o There are simple options described first that we consider to be 171 good starting points to operationalize the use of the ACP for 172 stable connectivity. 174 o The are more advanced intermediate options that try to establish 175 backward compatibility with existing deployed approached such as 176 leveraging NAT. Selection and deployment of these approaches 177 needs to be carefully vetted to ensure that they provide positive 178 RoI. This very much depends on the operational processes of the 179 network operator. 181 o It seems clearly feasible to build towards a long-term 182 configuration that provides all the desired operational, zero 183 touch and security benefits of an autonomic network, but a range 184 of details for this still have to be worked out. 186 2.1.1. Simple connectivity for non-autonomic NOC application devices 188 In the most simple deployment case, the ACP extends all the way into 189 the NOC via a network device that is set up to provide access into 190 the ACP natively to non-autonomic devices. It acts as the default- 191 router to those hosts and provides them with only IPv6 connectivity 192 into the ACP - but no IPv4 connectivity. NOC devices with this setup 193 need to support IPv6 but require no other modifications to leverage 194 the ACP. 196 This setup is sufficient for troubleshooting OAM operations such as 197 SSH into network devices, NMS that perform SNMP read operations for 198 status checking, for software downloads into autonomic devices and so 199 on. In conjunction with otherwise unmodified OAM operations via 200 separate NOC devices/applications it can provide a good subset of the 201 interesting stable connectivity goals from the ACP. 203 Because the ACP provides 'only' for IPv6 connectivity, and because 204 the addressing provided by the ACP does not include any addressing 205 structure that operations in a NOC often relies on to recognize where 206 devices are on the network, it is likely highly desirable to set up 207 DNS so that the ACP IPv6 addresses of autonomic devices are known via 208 domain names with logical names. For example, if DNS in the network 209 was set up with names for network devices as 210 devicename.noc.example.com, then the ACP address of that device could 211 be mapped to devicename-acp.noc.exmaple.com. 213 2.1.2. Limitations and enhancement overview 215 This most simple type of attachment of NOC applications to the ACP 216 suffers from a range of limitations: 218 1. NOC applications can not directly probe whether the desired so 219 called 'data-plane' network connectivity works because they do 220 not directly have access to it. This problem is not dissimilar 221 to probing connectivity for other services (such as VPN services) 222 that they do not have direct access to, so the NOC may already 223 employ appropriate mechanisms to deal with this issue (probing 224 proxies). 226 2. NOC applications need to support IPv6 which often is still not 227 the case in many enterprise networks. 229 3. Performance of the ACP will be limited versus normal 'data-plane' 230 connectivity. The setup of the ACP will often support only non- 231 hardware accelerated forwarding. Running a large amount of 232 traffic through the ACP, especially for tasks where it is not 233 necessary will reduce its performance/effectiveness for those 234 operations where it is necessary or highly desirable. 236 4. Security of the ACP is reduced by exposing the ACP natively (and 237 unprotected) into a LAN In the NOC where the NOC devices are 238 attached to it. 240 These four problems can be tackled independently of each other by 241 solution improvements. Combining these solutions improvements 242 together ultimately leads towards the the target long term solution. 244 2.1.3. Simultaneous ACP and data plane connectivity 246 Simultaneous connectivity to both ACP and data-plane can be achieved 247 in a variety of ways. If the data-plane is only IPv4, then any 248 method for dual-stack attachment of the NOC device/application will 249 suffice: IPv6 connectivity from the NOC provides access via the ACP, 250 IPv4 will provide access via the data-plane. If as explained above 251 in the most simple case, an autonomic device supports native 252 attachment to the ACP, and the existing NOC setup is IPv4 only, then 253 it could be sufficient to simply attach the ACP device(s) as the IPv6 254 default-router to the NOC LANs and keep the existing IPv4 default 255 router setup unchanged. 257 If the data-plane of the network is also supporting IPv6, then the 258 NOC devices that need access to the ACP should have a dual-homing 259 IPv6 setup. One option is to make the NOC devices multi-homed with 260 one logical or physical IPv6 interface connecting to the data-plane, 261 and another into the ACP. The LAN that provides access to the ACP 262 should then be given an IPv6 prefix that shares a common prefix with 263 the IPv6 ULA of the ACP so that the standard IPv6 interface selection 264 rules on the NOC host would result in the desired automatic selection 265 of the right interface: towards the ACP facing interface for 266 connections to ACP addresses, and towards the data-plane interface 267 for anything else. If this can not be achieved automatically, then 268 it needs to be done via simple IPv6 static routes in the NOC host. 270 Providing two virtual (eg: dot1q subnet) connections into NOC hosts 271 may be seen as undesired complexity. In that case the routing policy 272 to provide access to both ACP and data-plane via IPv6 needs to happen 273 in the NOC network itself: The NOC application device gets a single 274 attachment interface but still with the same two IPv6 addresses as in 275 before - one for use towards the ACP, one towards the data-plane. 276 The first-hop router connecting to the NOC application device would 277 then have separate interfaces: one towards the data-plane, one 278 towards the ACP. Routing of traffic from NOC application hosts would 279 then have to be based on the source IPv6 address of the host: Traffic 280 from the address designated for ACP use would get routed towards the 281 ACP, traffic from the designated data-plane address towards the data- 282 plane. 284 In the most simple case, we get the following topology: Existing NOC 285 application devices connect via an existing NOClan and existing first 286 hop Rtr1 to the data-plane. Rtr1 is not made autonomic, but instead 287 the edge router of the Autonomic network ANrtr is attached via a 288 separate interface to Rtr1 and ANrtr provides access to the ACP via 289 ACPaccessLan. Rtr1 is configured with the above described IPv6 290 source routing policies and the NOC-app-devices are given the 291 secondary IPv6 address for connectivity into the ACP. 293 --... (data-plane) 294 NOC-app-device(s) -- NOClan -- Rtr1 295 --- ACPaccessLan -- ANrtr ... (ACP) 297 Figure 1 299 If Rtr1 was to be upgraded to also implement Autonomic Networking and 300 the ACP, the picture would change as follows: 302 ---- ... (data-plane) 303 NOC-app-device(s) ---- NOClan --- ANrtr1 304 . . ---- ... (ACP) 305 \-/ 306 (ACP to data-plane loopback) 308 Figure 2 310 In this case, ANrtr1 would have to implement some more advanced 311 routing such as cross-VRF routing because the data-plane and ACP are 312 most likely run via separate VRFs. A simple short-term workaround 313 could be a physical external loopback cable into two ports of ANrtr1 314 to connect the data-plane and ACP VRF as shown in the picture. 316 2.1.4. IPv4 only NOC application devices 318 With the ACP being intentionally IPv6 only, attachment of IPv4 only 319 NOC application devices to the ACP requires the use of IPv4 to IPv6 320 NAT. This NAT setup could for example be done in Rt1r1 in above 321 picture to also support IPv4 only NOC application devices connected 322 to NOClan. 324 To support connections initiated from IPv4 only NOC applications 325 towards the ACP of network devices, it is necessary to create a 326 static mapping of ACP IPv6 addresses into an unused IPv4 address 327 space and dynamic or static mapping of the IPv4 NOC application 328 device address (prefix) into IPv6 routed in the ACP. The main issue 329 in this setup is the mapping of all ACP IPv6 addresses to IPv4. 330 Without further network intelligence, this needs to be a 1:1 address 331 mapping because the prefix used for ACP IPv6 addresses is too long to 332 be mapped directly into IPv4 on a prefix basis. 334 One could implement in router software dynamic mappings by leveraging 335 DNS, but it seems highly undesirable to implement such complex 336 technologies for something that ultimately is a temporary problem 337 (IPv4 only NOC application devices). With today's operational 338 directions it is likely more preferable to automate the setup of 1:1 339 NAT mappings in that NAT router as part of the automation process of 340 network device enrollment into the ACP. 342 The ACP can also be used for connections initiated by the network 343 device into the NOC application devices. For example syslog from 344 autonomic devices. In this case, static mappings of the NOC 345 application devices IPv4 addresses are required. This can easily be 346 done with a static prefix mapping into IPv6. 348 Overall, the use of NAT is especially subject to the RoI 349 considerations, but the methods described here may not be too 350 different from the same problems encountered totally independent of 351 AN/ACP when some parts of the network are to introduce IPv6 but NOC 352 application devices are not (yet) upgradeable. 354 2.1.5. Path selection policies 356 As mentioned above, the ACP is not expected to have high performance 357 because its primary goal is connectivity and security, and for 358 existing networ device platforms this often means that it is a lot 359 more effort to implement that additional connectivity with hardware 360 acceleration than without - especially because of the desire to 361 support full encryption across the ACP to achieve the desired 362 security. 364 Some of these issues may go away in the future with further adoption 365 of the ACP and network device designs that better tender to the needs 366 of a separate OAM plane, but it is wise to plan for even long-term 367 designs of the solution that does NOT depend on high-performance of 368 the ACP. This is opposite to the expectation that future NOC 369 application devices will have IPv6, so that any considerations for 370 IPv4/NAT in this solution are temporary. 372 To solve the expected performance limitations of the ACP, we do 373 expect to have the above describe dual-connectivity via both ACP and 374 data-plane between NOC application devices and AN devices with ACP. 375 The ACP connectivity is expected to always be there (as soon as a 376 device is enrolled), but the data-plane connectivity is only present 377 under normal operations but will not be present during eg: early 378 stages of device bootstrap, failures, provisioning mistakes or during 379 network configuration changes. 381 The desired policy is therefore as follows: In the absence of further 382 security considerations (see below), traffic between NOC application 383 and AN devices should prefer data-plane connectivity and resort only 384 to using the ACP when necessary, unless it is an operation known to 385 be so much tied to the cases where the ACP is necessary that it makes 386 no sense to try using the data plane. An example here is of course 387 the SSH connection from the NOC into a network device to troubleshoot 388 network connectivity. This could easily always rely on the ACP. 389 Likewise, if a NOC application is known to transmit large amounts of 390 data, and it uses the ACP, then its performance need to be controlled 391 so that it will not overload the ACP performance. Typical examples 392 of this are software downloads. 394 There is a wide range of methods to build up these policies. We 395 describe a few: 397 DNS can be used to set up names for the same network devices but with 398 different addresses assigned: One name (name.noc.example.com) with 399 only the data-plane address(es) (IPv4 and/or IPv6) to be used for 400 probing connectivity or performing routine software downloads that 401 may stall/fail when there are connectivity issues. One name (name- 402 acp.noc.example.com) with only the ACP reachable address of the 403 device for troubleshooting and probing/discovery that is desired to 404 always only use the ACP. One name with data plane and ACP addresses 405 (name-both.noc.example.com). 407 Traffic policing and/or shaping of at the ACP edge in the NOC can be 408 used to throttle applications such as software download into the ACP. 410 MP-TCP is a very attractive candidate to automate the use of both 411 data-plane and ACP and minimize or fully avoid the need for the above 412 mentioned logical names to pre-set the desired connectivity (data- 413 plane-only, ACP only, both). For example, a set-up for non MP-TCP 414 aware applications would be as follows: 416 DNS naming is set up to provide the ACP IPv6 address of network 417 devices. Unbeknownst to the application, MP-TCP is used. MP-TCP 418 mutually discovers between the NOC and network device the data-plane 419 address and caries all traffic across it when that MP-TCP sub-flow 420 across the data-plane can be built. 422 In the Autonomic network devices where data-plane and ACP are in 423 separate VRFs, it is clear that this type of MP-TCP sub-flow creation 424 across different VRFs is new/added functionality. Likewise the 425 policies of preferring a particular address (NOC-device) or VRF (AN 426 device) for the traffic is potentially also a policy not provided as 427 a standard. 429 2.1.6. Autonomic NOC device/applications 431 Setting up connectivity between the NOC and autonomic devices when 432 the NOC device itself is non-autonomic is as mentioned in the 433 beginning a security issue. It also results as shown in the previous 434 paragraphs in a range of connectivity considerations, some of which 435 may be quite undesirable or complex to operationalize. 437 Making NOC application devices autonomic and having them participate 438 in the ACP is therefore not only a highly desirable solution to the 439 security issues, but can also provide a likely easier 440 operationalization of the ACP because it minimizes NOC-special edge 441 considerations - the ACP is simply built all the way automatically, 442 even inside the NOC and only authorized and authenticate NOC devices/ 443 applications will have access to it. 445 Supporting the ACP all the way into an application device requires 446 implementing the following aspects in it: AN bootstrap/enrollment 447 mechanisms, the secure channel for the ACP and at least the host side 448 of IPv6 routing setup for the ACP. Minimally this could all be 449 implemented as an application and be made available to the host OS 450 via eg: a tap driver to make the ACP show up as another IPv6 enabled 451 interface. 453 Having said this: If the structure of NOC applications is transformed 454 through virtualization anyhow, then it may be considered equally 455 secure and appropriate to construct a (physical) NOC application 456 system by combining a virtual AN/ACP enabled router with non-AN/ACP 457 enabled NOC-application VMs via a hypervisor, leveraging the 458 configuration options described in the previous sections but jut 459 virtualizing them. 461 2.1.7. Encryption of data-plane connections 463 When combining ACP and data-plane connectivity for availability and 464 performance reasons, this too has an impact on security: When using 465 the ACP, the traffic will be mostly encryption protected, especially 466 when considering the above described use of AN application devices. 467 If instead the data-plane is used, then this is not the case anymore 468 unless it is done by the application. 470 The most simple solution for this problem exists when using AN NOC 471 application devices, because in that case the communicating AN NOC 472 application and the AN network device have certificates through the 473 AN enrollment process that they can mutually trust (same AN domain). 474 In result, data-plane connectivity that does support this can simply 475 leverage TLS/dTLS with mutual AN-domain certificate authentication - 476 and does not incur new key management. 478 If this automatic security benefit is seen as most important, but a 479 "full" ACP stack into the NOC application device is unfeasible, then 480 it would still be possible to design a stripped down version of AN 481 functionality for such NOC hosts that only provides enrollment of the 482 NOC host into the AN domain to the extend that the host receives an 483 AN domain certificate, but without directly participating in the ACP 484 afterwards. Instead, the host would just leverage TLS/dTLS using its 485 AN certificate via the data-plane with AN network devices as well as 486 indirectly via the ACP with the above mentioned in-NOC network edge 487 connectivity into the ACP. 489 When using the ACP itself, TLS/dTLS for the transport layer between 490 NOC application and network device is somewhat of a double price to 491 pay (ACP also encrypts) and could potentially be optimized away, but 492 given the assumed lower performance of the ACP, it seems that this is 493 an unnecessary optimization. 495 2.1.8. Long term direction of the solution 497 If we consider what potentially could be the most lightweight and 498 autonomic long term solution based on the technologies described 499 above, we see the following direction: 501 1. NOC applications should at least support IPv6. IPv4/IPv6 NAT in 502 the network to enable use of ACP is long term undesirable. 503 Having IPv4 only applications automatically leverage IPv6 504 connectivity via host-stack options is likely non-feasible (NOTE: 505 this has still to be vetted more). 507 2. Build the ACP as a lightweight application for NOC application 508 devices so ACP extends all the way into the actual NOC 509 application devices. 511 3. Leverage and as necessary enhance MP-TCP with automatic dual- 512 connectivity: If the MP-TCP unaware application is using ACP 513 connectivity, the policies used should add sub-flow(s) via the 514 data-plane and prefer them. 516 4. Consider how to best map NOC application desires to underlying 517 transport mechanisms: With the above mentioned 3 points, not all 518 options are covered. Depending on the OAM operation, one may 519 still want only ACP, only data-plane, or automatically prefer one 520 over the other and/or use the ACP with low performance or high- 521 performance (for emergency OAM actions such as countering DDoS). 522 It is as of today not clear what the simplest set of tools is to 523 enable explicitly the choice of desired behavior of each OAM 524 operations. The use of the above mentioned DNS and MP-TCP 525 mechanisms is a start, but this will require additional thoughts. 526 This is likely a specific case of the more generic scope of TAPS. 528 2.2. Stable connectivity for distributed network/OAM functions 530 The ACP can provide common direct-neighbor discovery and capability 531 negotiation and stable and secure connectivity for functions running 532 distributed in network devices. It can therefore eliminate the need 533 to re-implement similar functions in each distributed function in the 534 network. Today, every distributed protocol does this with functional 535 elements usually called "Hello" mechanisms and with often protocol 536 specific security mechanisms. 538 KARP has tried to start provide common directions and therefore 539 reduce the re-invention of at least some of the security aspects, but 540 it only covers routing-protocols and it is unclear how well it 541 applicable to a potentially wider range of network distributed agents 542 such as those performing distributed OAM functions. The ACP can help 543 in these cases. 545 This section is TBD for further iterations of this draft. 547 3. Security Considerations 549 We discuss only security considerations not covered in the 550 appropriate sub-sections of the solutions described. 552 Even though ACPs are meant to be isolated, explicit operator 553 misconfiguration to connect to insecure OAM equipment and/or bugs in 554 ACP devices may cause leakage into places where it is not expected. 555 Mergers/Aquisitions and other complex network reconfigurations 556 affecting the NOC are typical examples. 558 ULA addressing as proposed in this document is preferred over 559 globally reachable addresses because it is not routed in the global 560 Internet and will therefore be subject to more filtering even in 561 places where specific ULA addresses are being used. 563 Randomn ULA addressing provides more than sufficient protection 564 against address collision even though there is no central assignment 565 authority. This is helped by the expectation, that ACPs are never 566 expected to connect all together, but only few ACPs may ever need to 567 connect together, eg: when mergers and aquisitions occur. 569 If packets with unexpected ULA addresses are seen and one expects 570 them to be from another networks ACP from which they leaked, then 571 some form of ULA prefix registrastion (not allocation) can be 572 beneficial. Some voluntary registries exist, for example 573 https://www.sixxs.net/tools/grh/ula/, although none of them is 574 preferrable because of being operated by some recognized authority. 575 If an operator would want to make its ULA prefix known, it might need 576 to register it with multiple existing registries. 578 ULA Centrally assigned ULA addresses (ULA-C) was an attempt to 579 introduce centralized registration of randomnly assigned addresses 580 and potentially even carve out a different ULA prefix for such 581 addresses. This proposal is currently not proceeding, and it is 582 questionable whether the stable connectivity use case provides 583 sufficient motivation to revive this effort. 585 Using current registration options implies that there will not be 586 reverse DNS mapping for ACP addresses. For that one will have to 587 rely on looking up the unknown/unexpected network prefix in the 588 registry registry to determine the owner of these addresses. 590 Reverse DNS resolution may be beneficial for specific already 591 deployed insecure legacy protocols on NOC OAM systems that intend to 592 communicate via the ACP (eg: TFTP) and leverages reverse-DNS for 593 authentication. Given how the ACP provides path security except 594 potentially for the last-hop in the NOC, the ACP does make it easier 595 to extend the lifespan of such protocols in a secure fashion as far 596 to just the transport is concerned. The ACP does not make reverse 597 DNS lookup a secure authentication method though. Any current and 598 future protocols must rely on secure end-to-end communications (TLD, 599 dTLS) and identification and authentication via the certificates 600 assigned to both ends. This is enabled by the certificate mechanisms 601 of the ACP. 603 If DNS and especially reverse DNS are set up, then it should be set 604 up in an automated fashion, linked to the autonomic registrar backend 605 so that the DNS and reverse DNS records are actually derived from the 606 subject name elements of the ACP device certificates in the same way 607 as the autonomic devices themselves will derive their ULA addresses 608 from their certificates to ensure correct and consistent DNS entries. 610 If an operator feels that reverse DNS records are beneficial to its 611 own operations but that they should not be made available publically 612 for "security" by concealment reasons, then the case of ACP DNS 613 entries is probably one of the least problematic use cases for split- 614 DNS: The ACP DNS names are only needed for the NOC applications 615 intending to use the ACP - but not network wide across the 616 enterprise. 618 4. No IPv4 for ACP 620 The ACP is targeted to be IPv6 only, and the prior explanations in 621 this document show that this can lead to some complexity when having 622 to connect IPv4 only NOC solutions, and that it will be impossible to 623 leverage the ACP when the OAM agents on an ACP network device do not 624 support IPv6. Therefore, the question was raised whether the ACP 625 should optionally also support IPv4. 627 The decision not to include IPv4 for ACP as something that is 628 considered in the use cases in this document is because of the 629 following reasons: 631 In SP networks that have started to support IPv6, often the next 632 planned step is to consider moving out IPv4 from a native transport 633 as just a service on the edge. There is no benefit/need for multiple 634 parallel transport families within the network, and standardizing on 635 one reduces OPEX and improves reliability. This evolution in the 636 data plane makes it highly unlikely that investing development cycles 637 into IPv4 support for ACP will have a longer term benefit or enough 638 critical short-term use-cases. Support for only IPv4 for ACP is 639 purely a strategic choice to focus on the known important long term 640 goals. 642 In other type of networks as well, we think that efforts to support 643 autonomic networking is better spent in ensuring that one address 644 family will be support so all use cases will long-term work with it, 645 instead of duplicating effort into IPv4. Especially because auto- 646 addressing for the ACP with IPv4 would be more ecomplex than in IPv6 647 due to the the IPv4 addressing space. 649 5. Further considerations 651 6. IANA Considerations 653 This document requests no action by IANA. 655 7. Acknowledgements 657 This work originated from an Autonomic Networking project at cisco 658 Systems, which started in early 2010 including customers involved in 659 the design and early testing. Many people contributed to the aspects 660 described in this document, including in alphabetical order: BL 661 Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi 662 Kumar Vadapalli. The author would also like to thank Michael 663 Richardson, James Woodyatt and Brian Carpenter for their review and 664 comments. 666 8. Change log [RFC Editor: Please remove] 668 00: Changed title/dates. 670 individual-02: Updated references. 672 individual-03: Modified ULA text to not suggest ULA-C as much 673 better anymore, but still mention it. 675 individual-02: Added explanation why no IPv4 for ACP. 677 individual-01: Added security section discussing the role of 678 address prefix selection and DNS for ACP. Title change to 679 emphasize focus on OAM. Expanded abstract. 681 individual-00: Initial version. 683 9. References 685 [I-D.behringer-anima-reference-model] 686 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 687 Liu, B., Jeff, J., and J. Strassner, "A Reference Model 688 for Autonomic Networking", draft-behringer-anima- 689 reference-model-04 (work in progress), October 2015. 691 [I-D.ietf-anima-autonomic-control-plane] 692 Behringer, M., Bjarnason, S., BL, B., and T. Eckert, "An 693 Autonomic Control Plane", draft-ietf-anima-autonomic- 694 control-plane-01 (work in progress), October 2015. 696 [I-D.ietf-anima-bootstrapping-keyinfra] 697 Pritikin, M., Richardson, M., Behringer, M., and S. 698 Bjarnason, "Bootstrapping Key Infrastructures", draft- 699 ietf-anima-bootstrapping-keyinfra-01 (work in progress), 700 October 2015. 702 [I-D.irtf-nmrg-an-gap-analysis] 703 Jiang, S., Carpenter, B., and M. Behringer, "General Gap 704 Analysis for Autonomic Networking", draft-irtf-nmrg-an- 705 gap-analysis-06 (work in progress), April 2015. 707 [I-D.irtf-nmrg-autonomic-network-definitions] 708 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 709 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 710 Networking - Definitions and Design Goals", draft-irtf- 711 nmrg-autonomic-network-definitions-07 (work in progress), 712 March 2015. 714 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 715 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 716 . 718 Authors' Addresses 720 Toerless Eckert 721 Cisco 723 Email: eckert@cisco.com 725 Michael H. Behringer 726 Cisco 728 Email: mbehring@cisco.com