From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8368.txt | 1347 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1347 insertions(+) create mode 100644 doc/rfc/rfc8368.txt (limited to 'doc/rfc/rfc8368.txt') diff --git a/doc/rfc/rfc8368.txt b/doc/rfc/rfc8368.txt new file mode 100644 index 0000000..ce61d68 --- /dev/null +++ b/doc/rfc/rfc8368.txt @@ -0,0 +1,1347 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Eckert, Ed. +Request for Comments: 8368 Huawei +Category: Informational M. Behringer +ISSN: 2070-1721 May 2018 + + + Using an Autonomic Control Plane for Stable Connectivity of + Network Operations, Administration, and Maintenance (OAM) + +Abstract + + Operations, Administration, and Maintenance (OAM), as per BCP 161, + for data networks is often subject to the problem of circular + dependencies when relying on connectivity provided by the network to + be managed for the OAM purposes. + + Provisioning while bringing up devices and networks tends to be more + difficult to automate than service provisioning later on. Changes in + core network functions impacting reachability cannot be automated + because of ongoing connectivity requirements for the OAM equipment + itself, and widely used OAM protocols are not secure enough to be + carried across the network without security concerns. + + This document describes how to integrate OAM processes with an + autonomic control plane in order to provide stable and secure + connectivity for those OAM processes. This connectivity is not + subject to the aforementioned circular dependencies. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It has been approved for publication by the Internet + Engineering Steering Group (IESG). Not all documents approved by the + IESG are candidates for any level of Internet Standard; see Section 2 + of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8368. + + + + + + + + + +Eckert & Behringer Informational [Page 1] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +Copyright Notice + + Copyright (c) 2018 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Self-Dependent OAM Connectivity . . . . . . . . . . . . . 3 + 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 + 1.3. Leveraging a Generalized Autonomic Control Plane . . . . 4 + 2. GACP Requirements . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Stable Connectivity for Centralized OAM . . . . . . . . . 6 + 3.1.1. Simple Connectivity for Non-GACP-Capable + NMS Hosts . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1.2. Challenges and Limitations of Simple Connectivity . . 8 + 3.1.3. Simultaneous GACP and Data-Plane Connectivity . . . . 9 + 3.1.4. IPv4-Only NMS Hosts . . . . . . . . . . . . . . . . . 10 + 3.1.5. Path Selection Policies . . . . . . . . . . . . . . . 12 + 3.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 16 + 3.1.7. Encryption of Data-Plane Connections . . . . . . . . 16 + 3.1.8. Long-Term Direction of the Solution . . . . . . . . . 17 + 3.2. Stable Connectivity for Distributed Network/OAM . . 18 + 4. Architectural Considerations . . . . . . . . . . . . . . . . 18 + 4.1. No IPv4 for GACP . . . . . . . . . . . . . . . . . . . . 18 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 7.2. Informative References . . . . . . . . . . . . . . . . . 22 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + + + + + + + + +Eckert & Behringer Informational [Page 2] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +1. Introduction + +1.1. Self-Dependent OAM Connectivity + + Operations, Administration, and Maintenance (OAM), as per BCP 161 + [RFC6291], for data networks is often subject to the problem of + circular dependencies when relying on the connectivity service + provided by the network to be managed. OAM can easily but + unintentionally break the connectivity required for its own + operations. Avoiding these problems can lead to complexity in OAM. + This document describes this problem and how to use an autonomic + control plane to solve it without further OAM complexity. + + The ability to perform OAM on a network device requires first the + execution of OAM necessary to create network connectivity to that + device in all intervening devices. This typically leads to + sequential "expanding ring configuration" from a Network Operations + Center (NOC). It also leads to tight dependencies between + provisioning tools and security enrollment of devices. Any process + that wants to enroll multiple devices along a newly deployed network + topology needs to tightly interlock with the provisioning process + that creates connectivity before the enrollment can move on to the + next device. + + Likewise, when performing change operations on a network, it is + necessary to understand at any step of that process that there is no + interruption of connectivity that could lead to removal of + connectivity to remote devices. This includes especially change + provisioning of routing, forwarding, security, and addressing + policies in the network that often occur through mergers and + acquisitions, the introduction of IPv6, or other major overhauls of + the infrastructure design. Examples include change of an IGP or + area, change from Provider Aggregatable (PA) to Provider Independent + (PI) addressing, or systematic topology changes (such as Layer 2 to + Layer 3 changes). + + All these circular dependencies make OAM complex and potentially + fragile. When automation is being used (for example, through + provisioning systems), this complexity extends into that automation + software. + +1.2. Data Communication Networks (DCNs) + + In the late 1990s and early 2000, IP networks became the method of + choice to build separate OAM networks for the communications + infrastructure within Network Providers. This concept was + standardized in ITU-T G.7712/Y.1703 [ITUT_G7712] and called "Data + Communications Networks" (DCNs). These were (and still are) + + + +Eckert & Behringer Informational [Page 3] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + physically separate IP or IP/MPLS networks that provide access to OAM + interfaces of all equipment that had to be managed, from Public + Switched Telephone Network (PSTN) switches over optical equipment to + nowadays Ethernet and IP/MPLS production network equipment. + + Such DCNs provide stable connectivity not subject to the + aforementioned problems because they are a separate network entirely, + so change configuration of the production IP network is done via the + DCN but never affects the DCN configuration. Of course, this + approach comes at a cost of buying and operating a separate network, + and this cost is not feasible for many providers -- most notably, + smaller providers, most enterprises, and typical Internet of Things + (IoT) networks. + +1.3. Leveraging a Generalized Autonomic Control Plane + + One of the goals of the IETF ANIMA (Autonomic Networking Integrated + Model and Approach) Working Group is the specification of a secure + and automatically built in-band management plane that provides stable + connectivity similar to a DCN, but without having to build a separate + DCN. It is clear that such an "in-band" approach can never fully + achieve the same level of separation, but the goal is to get as close + to it as possible. + + This document discusses how such an in-band management plane can be + used to support the DCN-like OAM use case, how to leverage its stable + connectivity, and what the options are for deploying it incrementally + in the short and long term. + + The ANIMA Working Group's evolving specification [ACP] calls this in- + band management plane the "Autonomic Control Plane" (ACP). The + discussions in this document are not dependent on the specification + of that ACP, but only on a set of high-level constraints listed + below, which were decided upon early during the work on the ACP. + Except when being specific about details of the ACP, this document + uses the term "Generalized ACP" (GACP) and is applicable to any + designs that meet the high-level constraints -- for example, the + variations of the ACP protocol choices. + + + + + + + + + + + + + +Eckert & Behringer Informational [Page 4] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +2. GACP Requirements + + The high-level constraints of a GACP assumed and discussed in this + document are as follows: + + VRF isolation: The GACP is a virtual network (Virtual Routing and + Forwarding (VRF)) across network devices; its routing and + forwarding are separate from other routing and forwarding in the + network devices. Non-GACP routing/forwarding is called the "data + plane". + + IPv6-only addressing: The GACP provides only IPv6 reachability. It + uses Unique Local Addresses (ULAs) [RFC4193] that are routed in a + location-independent fashion, for example, through a subnet prefix + for each network device. Therefore, automatic addressing in the + GACP is simple and stable: it does not require allocation by + address registries, addresses are identifiers, they do not change + when devices move, and no engineering of the address space to the + network topology is necessary. + + NOC connectivity: NOC equipment (controlling OAM operations) either + has access to the GACP directly or has an IP subnet connection to + a GACP edge device. + + Closed Group Security: GACP devices have cryptographic credentials + to mutually authenticate each other as members of a GACP. Traffic + across the GACP is authenticated with these credentials and then + encrypted. + + GACP connect (interface): The only traffic permitted in and out of + the GACP that is not authenticated by GACP cryptographic + credentials is through explicit configuration for the traffic + from/to the aforementioned non-GACP NOC equipment with subnet + connections to a GACP edge device (as a transition method). + + The GACP must be built to be autonomic and its function must not be + able to be disrupted by operator or automated configuration/ + provisioning actions (i.e., Network Management System (NMS) or + Software-Defined Networking (SDN)). Those actions are allowed to + impact only the data plane. This document does not cover those + aspects; instead, it focuses on the impact of the above constraints: + IPv6 only, dual connectivity, and security. + + + + + + + + + +Eckert & Behringer Informational [Page 5] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +3. Solutions + +3.1. Stable Connectivity for Centralized OAM + + The ANI is the Autonomic Networking Infrastructure consisting of + secure zero-touch bootstrap (BRSKI [BRSKI]), the GeneRic Autonomic + Signaling Protocol (GRASP [GRASP]), and Autonomic Control Plane (ACP + [ACP]). Refer to the reference model [REF_MODEL] for an overview of + the ANI and how its components interact and [RFC7575] for concepts + and terminology of ANI and autonomic networks. + + This section describes stable connectivity for centralized OAM via + the GACP, for example, via the ACP with or without a complete ANI, + starting with the option that we expect to be the most easy to deploy + in the short term. It then describes limitations and challenges of + that approach and the corresponding solutions and workarounds; it + finishes with the preferred target option of autonomic NOC devices in + Section 3.1.6. + + This order was chosen because it helps to explain how simple initial + use of a GACP can be and how difficult workarounds can become (and + therefore what to avoid). Also, one very promising long-term + solution is exactly like the most easy short-term solution, only + virtualized and automated. + + In the most common case, OAM will be performed by one or more + applications running on a variety of centralized NOC systems that + communicate with network devices. This document describes approaches + to leverage a GACP for stable connectivity, from simple to complex, + depending on the capabilities and limitations of the equipment used. + + Three stages can be considered: + + o There are simple options described in Sections 3.1.1 through 3.1.3 + that we consider to be good starting points to operationalize the + use of a GACP for stable connectivity today. These options + require only network and OAM/NOC device configuration. + + o The are workarounds to connect a GACP to non-IPv6-capable NOC + devices through the use of IPv4/IPv6 NAT (Network Address + Translation) as described in Section 3.1.4. These workarounds are + not recommended; however, if non-IPv6-capable NOC devices need to + be used longer term, then the workarounds are the only way to + connect them to a GACP. + + + + + + + +Eckert & Behringer Informational [Page 6] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + o Options for the near to long term can provide all the desired + operational, zero-touch, and security benefits of an autonomic + network, but a range of details for this still have to be worked + out, and development work on NOC/OAM equipment is necessary. + These options are discussed in Sections 3.1.5 through 3.1.8. + +3.1.1. Simple Connectivity for Non-GACP-Capable NMS Hosts + + In the most simple candidate deployment case, the GACP extends all + the way into the NOC via one or more GACP edge devices. See also + Section 6.1 of [ACP]. These devices "leak" the (otherwise encrypted) + GACP natively to NMS hosts. They act as the default routers to those + NMS hosts and provide them with IPv6 connectivity into the GACP. NMS + hosts with this setup need to support IPv6 (e.g., see [RFC6434]) but + require no other modifications to leverage the GACP. + + Note that even though the GACP only uses IPv6, it can of course + support OAM for any type of network deployment as long as the network + devices support the GACP: The data plane can be IPv4 only, dual + stack, or IPv6 only. It is always separate from the GACP; therefore, + there is no dependency between the GACP and the IP version(s) used in + the data plane. + + This setup is sufficient for troubleshooting mechanisms such as SSH + into network devices, NMS that performs SNMP read operations for + status checking, software downloads onto autonomic devices, + provisioning of devices via NETCONF, and so on. In conjunction with + otherwise unmodified OAM via separate NMS hosts, this setup can + provide a good subset of the stable connectivity goals. The + limitations of this approach are discussed in the next section. + + Because the GACP provides "only" for IPv6 connectivity, and because + addressing provided by the GACP does not include any topological + addressing structure that a NOC often relies on to recognize where + devices are on the network, it is likely highly desirable to set up + the Domain Name System (DNS; see [RFC1034]) so that the GACP IPv6 + addresses of autonomic devices are known via domain names that + include the desired structure. For example, if DNS in the network + were set up with names for network devices as + devicename.noc.example.com, and if the well-known structure of the + data-plane IPv4 address space were used by operators to infer the + region where a device is located, then the GACP address of that + device could be set up as devicename_.acp.noc.example.com, + and devicename.acp.noc.example.com could be a CNAME to + devicename_.acp.noc.example.com. Note that many networks + already use names for network equipment where topological information + is included, even without a GACP. + + + + +Eckert & Behringer Informational [Page 7] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +3.1.2. Challenges and Limitations of Simple Connectivity + + This simple connectivity of non-autonomic NMS hosts suffers from a + range of challenges (that is, operators may not be able to do it this + way) and limitations (that is, operators cannot achieve desired goals + with this setup). The following list summarizes these challenges and + limitations, and the following sections describe additional + mechanisms to overcome them. + + Note that these challenges and limitations exist because GACP is + primarily designed to support distributed Autonomic Service Agent + (ASA), a piece of autonomic software, in the most lightweight + fashion. GACP is not required to support the additional mechanisms + needed for centralized NOC systems. It is this document that + describes additional (short-term) workarounds and (long-term) + extensions. + + 1. (Limitation) NMS hosts cannot directly probe whether the desired + so-called "data-plane" network connectivity works because they do + not directly have access to it. This problem is similar to + probing connectivity for other services (such as VPN services) + that they do not have direct access to, so the NOC may already + employ appropriate mechanisms to deal with this issue (probing + proxies). See Section 3.1.3 for candidate solutions. + + 2. (Challenge) NMS hosts need to support IPv6, and this often is + still not possible in enterprise networks. See Section 3.1.4 for + some workarounds. + + 3. (Limitation) Performance of the GACP may be limited versus normal + "data-plane" connectivity. The setup of the GACP will often + support only forwarding that is not hardware accelerated. + Running a large amount of traffic through the GACP, especially + for tasks where it is not necessary, will reduce its performance + and effectiveness for those operations where it is necessary or + highly desirable. See Section 3.1.5 for candidate solutions. + + 4. (Limitation) Security of the GACP is reduced by exposing the GACP + natively (and unencrypted) in a subnet in the NOC where the NOC + devices are attached to it. See Section 3.1.7 for candidate + solutions. + + These four problems can be tackled independently of each other by + solution improvements. Combining some of these improvements together + can lead towards a candidate long-term solution. + + + + + + +Eckert & Behringer Informational [Page 8] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +3.1.3. Simultaneous GACP and Data-Plane Connectivity + + Simultaneous connectivity to both the GACP and data plane can be + achieved in a variety of ways. If the data plane is IPv4 only, then + any method for dual-stack attachment of the NOC device/application + will suffice: IPv6 connectivity from the NOC provides access via the + GACP; IPv4 provides access via the data plane. If, as explained + above in the simple case, an autonomic device supports native + attachment to the GACP, and the existing NOC setup is IPv4 only, then + it could be sufficient to attach the GACP device(s) as the IPv6 + default router to the NOC subnet and keep the existing IPv4 default + router setup unchanged. + + If the data plane of the network is also supporting IPv6, then the + most compatible setup for NOC devices is to have two IPv6 interfaces + -- one virtual (e.g., via IEEE 802.1Q [IEEE.802.1Q]) or physical + interface connecting to a data-plane subnet, and another connecting + into a GACP connect subnet. See Section 8.1 of [ACP] for more + details. That document also specifies how a NOC device can receive + autoconfigured addressing and routes towards the ACP connect subnet + if it supports default address selection as specified in [RFC6724] + and default router preferences as specified in [RFC4191]. + + Configuring a second interface on a NOC host may be impossible or + seen as undesired complexity. In that case, the GACP edge device + needs to provide support for a "combined ACP and data-plane + interface" as described in Section 8.1 of [ACP]. This setup may not + work with autoconfiguration and all NOC host network stacks due to + limitations in those network stacks. They need to be able to perform + Rule 5.5 of [RFC6724] regarding source address selection, including + caching of next-hop information. + + For security reasons, it is not considered appropriate to connect a + non-GACP router to a GACP connect interface. The reason is that the + GACP is a secured network domain, and all NOC devices connecting via + GACP connect interfaces are also part of that secure domain. The + main difference is that the physical links between the GACP edge + device and the NOC devices are not authenticated or encrypted and, + therefore, need to be physically secured. If the secure GACP was + extendable via untrusted routers, then it would be a lot more + difficult to verify the secure domain assertion. Therefore, the GACP + edge devices are not supposed to redistribute routes from non-GACP + routers into the GACP. + + + + + + + + +Eckert & Behringer Informational [Page 9] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +3.1.4. IPv4-Only NMS Hosts + + One architectural expectation for the GACP as described in + Section 1.3 is that all devices that want to use the GACP (including + NMS hosts) support IPv6. Note that this expectation does not imply + any requirements for the data plane, especially it does not imply + that IPv6 must be supported in it. The data plane could be IPv4 + only, IPv6 only, dual stack, or it may not need to have any IP host + stack on the network devices. + + The implication of this architectural decision is the potential need + for short-term workarounds when the operational practices in a + network do not yet meet these target expectations. This section + explains when and why these workarounds may be operationally + necessary and describes them. However, the long-term goal is to + upgrade all NMS hosts to native IPv6, so the workarounds described in + this section should not be considered permanent. + + Most network equipment today supports IPv6, but it is very far from + being ubiquitously supported in NOC backend solutions (hardware or + software) or in the product space for enterprises. Even when it is + supported, there are often additional limitations or issues using it + in a dual-stack setup, or the operator mandates (for simplicity) + single stack for all operations. For these reasons, an IPv4-only + management plane is still required and common practice in many + enterprises. Without the desire to leverage the GACP, this required + and common practice is not a problem for those enterprises even when + they run dual stack in the network. We discuss these workarounds + here because it is a short-term deployment challenge specific to the + operations of a GACP. + + To connect IPv4-only management-plane devices/applications with a + GACP, some form of IP/ICMP translation of packets between IPv4 and + IPv6 is necessary. The basic mechanisms for this are in [RFC7915], + which describes the Stateless IP/ICMP Translation Algorithm (SIIT). + There are multiple solutions using this mechanism. To understand the + possible solutions, we consider the requirements: + + 1. NMS hosts need to be able to initiate connections to any GACP + device for management purposes. Examples include provisioning + via NETCONF, SNMP poll operations, or just diagnostics via SSH + connections from operators. Every GACP device/function that + needs to be reachable from NMS hosts needs to have a separate + IPv4 address. + + + + + + + +Eckert & Behringer Informational [Page 10] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + 2. GACP devices need to be able to initiate connections to NMS + hosts, for example, to initiate NTP or RADIUS/Diameter + connections, send syslog or SNMP trap, or initiate NETCONF Call + Home connections after bootstrap. Every NMS host needs to have a + separate IPv6 address reachable from the GACP. When a connection + from a GACP device is made to an NMS host, the IPv4 source + address of the connection (as seen by the NMS host) must be + unique per GACP device and must be the same address as in (1) to + maintain addressing simplicity similar to a native IPv4 + deployment. For example in syslog, the source IP address of a + logging device is used to identify it, and if the device shows + problems, an operator might want to SSH into the device to + diagnose it. + + Because of these requirements, the necessary and sufficient set of + solutions are those that provide 1:1 mapping of IPv6 GACP addresses + into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for + use in the GACP). This means that SIIT-based solutions are + sufficient and preferred. + + Note that GACP devices may use multiple IPv6 addresses in the GACP. + For example, Section 6.10 of [ACP] defines multiple useful addressing + sub-schemes supporting this option. All those addresses may then + need to be reachable through IPv6/IPv4 address translation. + + The need to allocate for every GACP device one or multiple IPv4 + addresses should not be a problem if -- as we assume -- the NMS hosts + can use private IPv4 address space ([RFC1918]). Nevertheless, even + with private IPv4 address space, it is important that the GACP IPv6 + addresses can be mapped efficiently into IPv4 address space without + too much waste. + + Currently, the most flexible mapping scheme to achieve this is + [RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping. + Assume the GACP uses the ACP Zone Addressing Sub-Scheme and there are + 3 registrars. In the ACP Zone Addressing Sub-Scheme, for each + registrar, there is a constant /112 prefix for which an Explicit + Address Mapping (EAM), as defined in RFC 7757, to a /16 prefix can be + configured (e.g., in the private IPv4 address space described in + [RFC1918]). Within the registrar's /112 prefix, Device-Numbers for + devices are sequentially assigned: with the V bit (Virtualization + bit) effectively two numbers are assigned per GACP device. This also + means that if IPv4 address space is even more constrained, and it is + known that a registrar will never need the full /15 extent of Device- + Numbers, then a prefix longer than a /112 can be configured into the + EAM in order to use less IPv4 space. + + + + + +Eckert & Behringer Informational [Page 11] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + When using the ACP Vlong Addressing Sub-Scheme, it is unlikely that + one wants or needs to translate the full /8 or /16 of addressing + space per GACP device into IPv4. In this case, the EAM rules of + dropping trailing bits can be used to map only N bits of the V bits + into IPv4. However, this does imply that only addresses that differ + in those high-order N V bits can be distinguished on the IPv4 side. + + Likewise, the IPv4 address space used for NMS hosts can easily be + mapped into an address prefix assigned to a GACP connect interface. + + A full specification of a solution to perform SIIT in conjunction + with GACP connect following the considerations below is outside the + scope of this document. + + To be in compliance with security expectations, SIIT has to happen on + the GACP edge device itself so that GACP security considerations can + be taken into account. For example, IPv4-only NMS hosts can be dealt + with exactly like IPv6 hosts connected to a GACP connect interface. + + Note that prior solutions such as NAT64 ([RFC6146]) may equally be + useable to translate between GACP IPv6 address space and NMS hosts' + IPv4 address space. As a workaround, this can also be done on non- + GACP Edge Devices connected to a GACP connect interface. The details + vary depending on implementation because the options to configure + address mappings vary widely. Outside of EAM, there are no + standardized solutions that allow for mapping of prefixes, so it will + most likely be necessary to explicitly map every individual (/128) + GACP device address to an IPv4 address. Such an approach should use + automation/scripting where these address translation entries are + created dynamically whenever a GACP device is enrolled or first + connected to the GACP network. + + The NAT methods described here are not specific to a GACP. Instead, + they are similar to what would be necessary when some parts of a + network only support IPv6, but the NOC equipment does not support + IPv6. Whether it is more appropriate to wait until the NOC equipment + supports IPv6 or to use NAT beforehand depends in large part on how + long the former will take and how easy the latter will be when using + products that support the NAT options described to operationalize the + above recommendations. + +3.1.5. Path Selection Policies + + As mentioned above, a GACP is not expected to have high performance + because its primary goal is connectivity and security. For existing + network device platforms, this often means that it is a lot more + effort to implement that additional connectivity with hardware + + + + +Eckert & Behringer Informational [Page 12] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + acceleration than without -- especially because of the desire to + support full encryption across the GACP to achieve the desired + security. + + Some of these issues may go away in the future with further adoption + of a GACP and network device designs that better tend to the needs of + a separate OAM plane, but it is wise to plan for long-term designs of + the solution that do NOT depend on high performance of the GACP. + This is the opposite of the expectations that future NMS hosts will + have IPv6 and that any considerations for IPv4/NAT in this solution + are temporary. + + To solve the expected performance limitations of the GACP, we do + expect to have the above-described dual connectivity via both GACP + and data plane between NOC application devices and devices with GACP. + The GACP connectivity is expected to always be there (as soon as a + device is enrolled), but the data-plane connectivity is only present + under normal operations and will not be present during, e.g., early + stages of device bootstrap, failures, provisioning mistakes, or + network configuration changes. + + The desired policy is therefore as follows: In the absence of further + security considerations (see below), traffic between NMS hosts and + GACP devices should prefer data-plane connectivity and resort only to + using the GACP when necessary. The exception is an operation known + to be covered by the use cases where the GACP is necessary, so that + it makes no sense to try using the data plane. An example is an SSH + connection from the NOC to a network device to troubleshoot network + connectivity. This could easily always rely on the GACP. Likewise, + if an NMS host is known to transmit large amounts of data, and it + uses the GACP, then its data rate needs to be controlled so that it + will not overload the GACP path. Typical examples of this are + software downloads. + + There is a wide range of methods to build up these policies. We + describe a few below. + + Ideally, a NOC system would learn and keep track of all addresses of + a device (GACP and the various data-plane addresses). Every action + of the NOC system would indicate via a "path-policy" what type of + connection it needs (e.g., only data-plane, GACP only, default to + data plane, fallback to GACP, etc.). A connection policy manager + would then build connection to the target using the right + address(es). Shorter term, a common practice is to identify + different paths to a device via different names (e.g., loopback vs. + interface addresses). This approach can be expanded to GACP uses, + whether it uses the DNS or names local to the NOC system. Below, we + describe example schemes using DNS. + + + +Eckert & Behringer Informational [Page 13] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + DNS can be used to set up names for the same network devices but with + different addresses assigned: + + o One name (name.noc.example.com) with only the data-plane + address(es) (IPv4 and/or IPv6) to be used for probing connectivity + or performing routine software downloads that may stall/fail when + there are connectivity issues. + + o One name (name-acp.noc.example.com) with only the GACP reachable + address of the device for troubleshooting and probing/discovery + that is desired to always only use the GACP. + + o One name (name-both.noc.example.com) with data-plane and GACP + addresses. + + Traffic policing and/or shaping at the GACP edge in the NOC can be + used to throttle applications such as software download into the + GACP. + + Using different names that map to different addresses (or subsets of + addresses) can be difficult to set up and maintain, especially + because data-plane addresses may change due to reconfiguration or + relocation of devices. The name-based approach alone cannot strongly + support policies for existing applications and long-lived flows to + automatically switch between the ACP and data plane in the face of + data-plane failure and recovery. A solution would be host transport + stacks on GACP nodes that support the following requirements: + + 1. Only the GACP addresses of the responder must be required by the + initiator for the initial setup of a connection/flow across the + GACP. + + 2. Responder and Initiator must be able to exchange their data-plane + addresses through the GACP, and then -- if needed by policy -- + build an additional flow across the data plane. + + 3. For unmodified application, the following policies should be + configurable on at least a per-application basis for its TCP + connections with GACP peers: + + Fallback (to GACP): An additional data-plane flow is built and + used exclusively to send data whenever the data plane is + operational. When the additional flow cannot be built during + connection setup or when it fails later, traffic is sent + across the GACP flow. This could be a default policy for most + OAM applications using the GACP. + + + + + +Eckert & Behringer Informational [Page 14] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + Suspend/Fail: Like the Fallback policy, except that traffic will + not use the GACP flow; instead, it will be suspended until a + data-plane flow is operational or until a policy-configurable + timeout indicates a connection failure to the application. + This policy would be appropriate for large-volume background + or scavenger-class OAM applications such as firmware downloads + or telemetry/diagnostic uploads -- applications that would + otherwise easily overrun performance-limited GACP + implementations. + + GACP (only): No additional data-plane flow is built, traffic is + only sent via the GACP flow. This can just be a TCP + connection. This policy would be most appropriate for OAM + operations known to change the data plane in a way that could + impact connectivity through it (at least temporarily). + + 4. In the presence of responders or initiators not supporting these + host stack functions, the Fallback and GACP policies must result + in a TCP connection across the GACP. For Suspend/Fail, presence + of TCP-only peers should result in failure during connection + setup. + + 5. In case of Fallback and Suspend/Fail, a failed data-plane + connection should automatically be rebuilt when the data plane + recovers, including when the data-plane address of one side or + both sides may have changed -- for example, because of + reconfiguration or device repositioning. + + 6. Additional data-plane flows created by these host transport stack + functions must be end-to-end authenticated by these host + transport stack functions with the GACP domain credentials and + encrypted. This maintains the expectation that connections from + GACP addresses to GACP addresses are authenticated and encrypted. + This may be skipped if the application already provides for end- + to-end encryption. + + 7. For enhanced applications, the host stack may support application + control to select the policy on a per-connection basis, or even + more explicit control for building of the flows and which flow + should pass traffic. + + Protocols like Multipath TCP (MPTCP; see [RFC6824]) and the Stream + Control Transmission Protocol (SCTP; see [RFC4960]) can already + support part of these requirements. MPTCP, for example, supports + signaling of addresses in a TCP backward-compatible fashion, + establishing additional flows (called subflows in MPTCP), and having + primary and fallback subflows via MP_PRIO signaling. The details of + how MPTCP, SCTP, and/or other approaches (potentially with extensions + + + +Eckert & Behringer Informational [Page 15] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + and/or (shim) layers on top of them) can best provide a complete + solution for the above requirements need further work and are outside + the scope of this document. + +3.1.6. Autonomic NOC Device/Applications + + Setting up connectivity between the NOC and autonomic devices when + the NOC device itself is non-autonomic is a security issue, as + mentioned at the beginning of this document. It also results in a + range of connectivity considerations (discussed in Section 3.1.5), + some of which may be quite undesirable or complex to operationalize. + + Making NMS hosts autonomic and having them participate in the GACP is + therefore not only a highly desirable solution to the security + issues, but can also provide a likely easier operationalization of + the GACP because it minimizes special edge considerations for the + NOC. The GACP is simply built all the way automatically, even inside + the NOC, and it is only authorizes and authenticates NOC devices/ + applications that will have access to it. + + According to [ACP], supporting the ACP all the way into an + application device requires implementing the following aspects in it: + AN bootstrap/enrollment mechanisms, the secure channel for the ACP + and at least the host side of IPv6 routing setup for the ACP. + Minimally, this could all be implemented as an application and be + made available to the host OS via, e.g., a TAP driver to make the ACP + show up as another IPv6-enabled interface. + + Having said this: If the structure of NMS hosts is transformed + through virtualization anyhow, then it may be considered equally + secure and appropriate to construct a (physical) NMS host system by + combining a virtual GACP-enabled router with non-GACP-enabled Virtual + Machines (VMs) for NOC applications via a hypervisor. This would + leverage the configuration options described in the previous sections + but just virtualize them. + +3.1.7. Encryption of Data-Plane Connections + + When combining GACP and data-plane connectivity for availability and + performance reasons, this too has an impact on security: When using + the GACP, most traffic will be encryption protected, especially when + considering the above-described use of application devices with GACP. + If, instead, the data plane is used, then this is not the case + anymore unless it is done by the application. + + The simplest solution for this problem exists when using GACP-capable + NMS hosts, because in that case the communicating GACP-capable NMS + host and the GACP network device have credentials they can mutually + + + +Eckert & Behringer Informational [Page 16] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + trust (same GACP domain). As a result, data-plane connectivity that + does support this can simply leverage TLS [RFC5246] or DTLS [RFC6347] + with those GACP credentials for mutual authentication -- and this + does not incur new key management. + + If this automatic security benefit is seen as most important, but a + "full" GACP stack into the NMS host is unfeasible, then it would + still be possible to design a stripped-down version of GACP + functionality for such NOC hosts that only provides enrollment of the + NOC host with the GACP cryptographic credentials and does not + directly participate in the GACP encryption method. Instead, the + host would just leverage TLS/DTLS using its GACP credentials via the + data plane with GACP network devices as well as indirectly via the + GACP connect interface with the above-mentioned GACP connect + interface into the GACP. + + When using the GACP itself, TLS/DTLS for the transport layer between + NMS hosts and network device is somewhat of a double price to pay + (GACP also encrypts) and could potentially be optimized away; + however, given the assumed lower performance of the GACP, it seems + that this is an unnecessary optimization. + +3.1.8. Long-Term Direction of the Solution + + If we consider what potentially could be the most lightweight and + autonomic long-term solution based on the technologies described + above, we see the following direction: + + 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the + network to enable use of a GACP is undesirable in the long term. + Having IPv4-only applications automatically leverage IPv6 + connectivity via host-stack translation may be an option, but + this has not been investigated yet. + + 2. Build the GACP as a lightweight application for NMS hosts so GACP + extends all the way into the actual NMS hosts. + + 3. Leverage and (as necessary) enhance host transport stacks with + automatic GACP with multipath connectivity and data plane as + outlined in Section 3.1.5. + + 4. Consider how to best map NMS host desires to underlying transport + mechanisms: The three points above do not cover all options. + Depending on the OAM, one may still want only GACP, want only + data plane, automatically prefer one over the other, and/or want + to use the GACP with low performance or high performance (for + emergency OAM such as countering DDoS). As of today, it is not + clear what the simplest set of tools is to explicitly enable the + + + +Eckert & Behringer Informational [Page 17] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + choice of desired behavior of each OAM. The use of the above- + mentioned DNS and multipath mechanisms is a start, but this will + require additional work. This is likely a specific case of the + more generic scope of TAPS. + +3.2. Stable Connectivity for Distributed Network/OAM + + Today, many distributed protocols implement their own unique security + mechanisms. + + Keying and Authentication for Routing Protocols (KARP; see [RFC6518]) + has tried to start to provide common directions and therefore reduce + the reinvention of at least some of the security aspects, but it only + covers routing protocols and it is unclear how applicable it is to a + wider range of network distributed agents such as those performing + distributed OAM. The common security of a GACP can help in those + cases. + + Furthermore, a GRASP instance ([GRASP]) can run on top of a GACP as a + security and transport substrate and provide common local and remote + neighbor discovery and peer negotiation mechanisms; this would allow + unifying and reusing future protocol designs. + +4. Architectural Considerations + +4.1. No IPv4 for GACP + + The GACP is intended to be IPv6 only, and the prior explanations in + this document show that this can lead to some complexity when having + to connect IPv4-only NOC solutions, and that it will be impossible to + leverage the GACP when the OAM agents on a GACP network device do not + support IPv6. Therefore, the question was raised whether the GACP + should optionally also support IPv4. + + The decision not to include IPv4 for GACP in the use cases in this + document was made for the following reasons: + + In service provider networks that have started to support IPv6, often + the next planned step is to consider moving IPv4 from a native + transport to just a service on the edge. There is no benefit or need + for multiple parallel transport families within the network, and + standardizing on one reduces operating expenses and improves + reliability. This evolution in the data plane makes it highly + unlikely that investing development cycles into IPv4 support for GACP + will have a longer term benefit or enough critical short-term use + cases. Support for IPv6-only for GACP is purely a strategic choice + to focus on the known important long-term goals. + + + + +Eckert & Behringer Informational [Page 18] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + In other types of networks as well, we think that efforts to support + autonomic networking are better spent in ensuring that one address + family will be supported so all use cases will work with it in the + long term, instead of duplicating effort with IPv4. Also, auto- + addressing for the GACP with IPv4 would be more complex than in IPv6 + due to the IPv4 addressing space. + +5. Security Considerations + + In this section, we discuss only security considerations not covered + in the appropriate subsections of the solutions described. + + Even though GACPs are meant to be isolated, explicit operator + misconfiguration to connect to insecure OAM equipment and/or bugs in + GACP devices may cause leakage into places where it is not expected. + Mergers and acquisitions and other complex network reconfigurations + affecting the NOC are typical examples. + + GACP addresses are ULAs. Using these addresses also for NOC devices, + as proposed in this document, is not only necessary for the simple + routing functionality explained above, but it is also more secure + than global IPv6 addresses. ULAs are not routed in the global + Internet and will therefore be subject to more filtering even in + places where specific ULAs are being used. Packets are therefore + less likely to leak and less likely to be successfully injected into + the isolated GACP environment. + + The random nature of a ULA prefix provides strong protection against + address collision even though there is no central assignment + authority. This is helped by the expectation that GACPs will never + connect all together, and that only a few GACPs may ever need to + connect together, e.g., when mergers and acquisitions occur. + + Note that the GACP constraints demand that only packets from + connected subnet prefixes are permitted from GACP connect interfaces, + limiting the scope of non-cryptographically secured transport to a + subnet within a NOC that instead has to rely on physical security + (i.e., only connect trusted NOC devices to it). + + To help diagnose packets that unexpectedly leaked, for example, from + another GACP (that was meant to be deployed separately), it can be + useful to voluntarily list your own ULA GACP prefixes on some sites + on the Internet and hope that other users of GACPs do the same so + that you can look up unknown ULA prefix packets seen in your network. + Note that this does not constitute registration. + was a site to list ULA + + + + + +Eckert & Behringer Informational [Page 19] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + prefixes, but it has not been open for new listings since mid-2017. + The authors are not aware of other active Internet sites to list ULA + use. + + Note that there is a provision in [RFC4193] for address space that is + not locally assigned (L bit = 0), but there is no existing + standardization for this, so these ULA prefixes must not be used. + + According to Section 4.4 of [RFC4193], PTR records for ULA addresses + should not be installed into the global DNS (no guaranteed + ownership). Hence, there is also the need to rely on voluntary lists + (as mentioned above) to make the use of an ULA prefix globally known. + + Nevertheless, some legacy OAM applications running across the GACP + may rely on reverse DNS lookup for authentication of requests (e.g., + TFTP for download of network firmware, configuration, or software). + Therefore, operators may need to use a private DNS setup for the GACP + ULAs. This is the same setup that would be necessary for using RFC + 1918 addresses in DNS. For example, see the last paragraph of + Section 5 of [RFC1918]. In Section 4 of [RFC6950], these setups are + discussed in more detail. + + Any current and future protocols must rely on secure end-to-end + communications (TLS/DTLS) and identification and authentication via + the certificates assigned to both ends. This is enabled by the + cryptographic credential mechanisms of the GACP. + + If DNS and especially reverse DNS are set up, then they should be set + up in an automated fashion when the GACP address for devices are + assigned. In the case of the ACP, DNS resource record creation can + be linked to the autonomic registrar backend so that the DNS and + reverse DNS records are actually derived from the subject name + elements of the ACP device certificates in the same way as the + autonomic devices themselves will derive their ULAs from their + certificates to ensure correct and consistent DNS entries. + + If an operator feels that reverse DNS records are beneficial to its + own operations, but that they should not be made available publicly + for "security" by concealment reasons, then GACP DNS entries are + probably one of the least problematic use cases for split DNS: The + GACP DNS names are only needed for the NMS hosts intending to use the + GACP -- but not network wide across the enterprise. + +6. IANA Considerations + + This document has no IANA actions. + + + + + +Eckert & Behringer Informational [Page 20] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +7. References + +7.1. Normative References + + [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, + . + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, + November 2005, . + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, + . + + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, + "Default Address Selection for Internet Protocol Version 6 + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + . + + [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, + "TCP Extensions for Multipath Operation with Multiple + Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, + . + + [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., + Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic + Networking: Definitions and Design Goals", RFC 7575, + DOI 10.17487/RFC7575, June 2015, + . + + [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address + Mappings for Stateless IP/ICMP Translation", RFC 7757, + DOI 10.17487/RFC7757, February 2016, + . + + [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, + "IP/ICMP Translation Algorithm", RFC 7915, + DOI 10.17487/RFC7915, June 2016, + . + + + + + + + + + +Eckert & Behringer Informational [Page 21] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +7.2. Informative References + + [ACP] Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic + Control Plane (ACP)", Work in Progress, + draft-ietf-anima-autonomic-control-plane-13, + December 2017. + + [BRSKI] Pritikin, M., Richardson, M., Behringer, M., Bjarnason, + S., and K. Watsen, "Bootstrapping Remote Secure Key + Infrastructures (BRSKI)", Work in Progress, + draft-ietf-anima-bootstrapping-keyinfra-15, April 2018. + + [GRASP] Bormann, C., Carpenter, B., and B. Liu, "A Generic + Autonomic Signaling Protocol (GRASP)", Work in Progress, + draft-ietf-anima-grasp-15, July 2017. + + [IEEE.802.1Q] + IEEE, "IEEE Standard for Local and metropolitan area + networks -- Bridges and Bridged Networks", + IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, + December 2014, . + + [ITUT_G7712] + ITU, "Architecture and specification of data communication + network", ITU-T Recommendation G.7712/Y.1703, November + 2001, . + + [REF_MODEL] + Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., + and J. Nobre, "A Reference Model for Autonomic + Networking", Work in Progress, + draft-ietf-anima-reference-model-06, February 2018. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, DOI 10.17487/RFC4960, September 2007, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + + + + +Eckert & Behringer Informational [Page 22] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + + [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from IPv6 + Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, + April 2011, . + + [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, + D., and S. Mansfield, "Guidelines for the Use of the "OAM" + Acronym in the IETF", BCP 161, RFC 6291, + DOI 10.17487/RFC6291, June 2011, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, + January 2012, . + + [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node + Requirements", RFC 6434, DOI 10.17487/RFC6434, December + 2011, . + + [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for + Routing Protocols (KARP) Design Guidelines", RFC 6518, + DOI 10.17487/RFC6518, February 2012, + . + + [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, + "Architectural Considerations on Application Features in + the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, + . + +Acknowledgements + + This work originated from an Autonomic Networking project at Cisco + Systems, which started in early 2010, with customers involved in the + design and early testing. Many people contributed to the aspects + described in this document, including in alphabetical order: BL + Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, and + Ravi Kumar Vadapalli. The authors would also like to thank Michael + Richardson, James Woodyatt, and Brian Carpenter for their review and + comments. Special thanks to Sheng Jiang and Mohamed Boucadair for + their thorough reviews. + + + + + + + + + + + +Eckert & Behringer Informational [Page 23] + +RFC 8368 AN Stable Connectivity OAM May 2018 + + +Authors' Addresses + + Toerless Eckert (editor) + Huawei USA + 2330 Central Expy + Santa Clara 95050 + United States of America + + Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com + + + Michael H. Behringer + + Email: michael.h.behringer@gmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Eckert & Behringer Informational [Page 24] + -- cgit v1.2.3