Delay-Tolerant Networking E.J. Birrane Internet-Draft B. Sipos Intended status: Standards Track JHU/APL Expires: 10 May 2025 6 November 2024 DTNMA Asynchronous Management Protocol (AMP) draft-ietf-dtn-amp-00 Abstract This document defines a messaging protocol for the Delay-Tolerant Networking (DTN) Management Architecture (DTNMA) Asynchronous Management Model (AMM) and a transport mapping for exchanging those messages over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management of resource constrained devices and over challenged networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 10 May 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Birrane & Sipos Expires 10 May 2025 [Page 1] Internet-Draft DTNMA AMP November 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Constraints and Assumptions . . . . . . . . . . . . . . . . . 4 3. Message Structure and Sequencing . . . . . . . . . . . . . . 5 3.1. Execution-Set Values . . . . . . . . . . . . . . . . . . 6 3.2. Reporting-Set Values . . . . . . . . . . . . . . . . . . 6 4. Bundle Protocol Transport . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Example Messages . . . . . . . . . . . . . . . . . . 10 Implementation Notes . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Network management in challenged and resource constrained networks must be accomplished differently than the network management methods in low-delay, high-rate, high-availability networks. The Delay- Tolerant Networking (DTN) Management Architecture (DTNMA), as defined in [I-D.ietf-dtn-dtnma], provides an overview and justification of an alternative to "synchronous" management services such as those provided by SNMP [RFC3411] or NETCONF [RFC6241] (and its derivatives RESTCONF [RFC8040] and CORECONF [I-D.ietf-core-comi]). In particular, the DTNMA defines the need for a flexible, robust, and efficient autonomy engine to handle decisions when operators cannot be active in the network. The logical description of that DTNMA Application Management Model (AMM), and its realization in static Application Data Models (ADMs) and dynamic Operational Data Models (ODMs), is in [I-D.ietf-dtn-amm]. Birrane & Sipos Expires 10 May 2025 [Page 2] Internet-Draft DTNMA AMP November 2024 The AMM presents an efficient and expressive model for the asynchronous management of a network node, but does not specify any particular message structure or encoding. This document, the DTNMA Asynchronous Management Protocol (AMP), specifies an encoding of messages related to AMM objects using ARI values [I-D.ietf-dtn-ari] as protocol data units (PDUs) in Section 3 and a transport of these PDUs within Bundle Protocol version 7 (BPv7) [RFC9171] payloads in Section 4. This AMP specification provides an enveloping of ARIs necessary to support the AMM as described in Section 2.3 of [I-D.ietf-dtn-amm]. As such, AMP defines very few structures of its own. 1.1. Scope The AMP provides data monitoring, administration, and configuration for applications operating above the data link layer of the OSI networking model. While the AMP may be configured to support the management of network layer protocols, it also uses these protocol stacks to encapsulate and communicate its own messages. It is assumed that the transport(s) used to carry AMP messages provide addressing, confidentiality, integrity, security, fragmentation/reassembly, and other network functions. Therefore, these items are outside of the scope of this document. This document describes the format of messages used to exchange data models between managing and managed devices in a network. The rationale for this type of exchange is outside of the scope of this document and is covered in [I-D.ietf-dtn-dtnma]. The description and explanation of the data models exchanged is also outside of the scope of this document and is covered in [I-D.ietf-dtn-amm]. This document does not address specific configurations of AMP-enabled devices or any ADMs or ODMs available on such devices. This also does not discuss the interface, if any, between AMP and other management protocols. 1.2. Use of CDDL This document defines Concise Binary Object Representation (CBOR) structure using the Concise Data Definition Language (CDDL) of [RFC8610]. The entire CDDL structure can be extracted from the XML version of this document using the XPath expression: '//sourcecode[@type="cddl"]' Birrane & Sipos Expires 10 May 2025 [Page 3] Internet-Draft DTNMA AMP November 2024 The following initial fragment defines the top-level symbols of this document's CDDL, which includes the example CBOR content. start = amp-adu From the document [I-D.ietf-dtn-ari] the definitions are taken for ari>, lit-execset, and lit-rptset. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The terms "Agent", "Application Data Model", "Externally Defined Data", "Variable", "Control", "Literal", "Macro", "Manager", "Report Template", "Report", "Table", "Constant", "Operator", "Time-Based Rule" and "State-Based Rule" are used without modification from the definitions provided in [I-D.ietf-dtn-amm]. 2. Constraints and Assumptions The desirable properties of an asynchronous management protocol, as specified in the DTNMA, are summarized here to represent design constraints on the AMP specification. Intelligent Push of Information: Nodes in a challenged network cannot guarantee concurrent, bi-directional communications. Some links between nodes may be strictly unidirectional. In the DTNMA, Agents "push" data to Managers rather than Managers "pulling" data from Agents. Small Message Sizes: Smaller messages require smaller periods of viable transmission for communication, incur less retransmission cost, and consume fewer resources when persistently stored en route in the network. The AMP minimizes message size wherever practical, to include binary data representations and predefined data definitions and templates. Static and Dynamic Identification: All data in the system must be uniquely addressable, to include operator-specified information. AMP provides a compact encoding for identifiers based on the Application Resource Identifier (ARI) of [I-D.ietf-dtn-ari]. Stateless Operation: There is no reliable concept of session Birrane & Sipos Expires 10 May 2025 [Page 4] Internet-Draft DTNMA AMP November 2024 establishment or round-trip data exchange in challenged networks. AMP is designed to be stateless and ADM controls are specified to be idempotent when executed. Where helpful, AMP provides mechanisms for ordering of execution within a single AMP protocol data unit, but otherwise degrades gracefully when nodes in the network diverge in their configuration. Independence from ADMs: Although some portions of the AMP structure share concepts and capabilities of AMM semantic types, the AMP operates independently from any specific ADMs or ODMs which would use the AMP for messaging between entities. This avoids the need for an AMP processor to have information about those specific ADMs or ODMs, similarly to how the ARI syntax processing is independent from specific ADMs or ODMs. The interpreting of ARIs, however, does require the use of specific referenced ADMs and ODMs. All AMP encodings are self-terminating, based on Concise Binary Object Representation (CBOR). This means that, given an indefinite- length octet stream, each encoding can be unambiguously decoded from the stream without requiring additional information such as a length field separate from the data type definition. CBOR also provides a layer of well-formed data coding separate from valid AMP structure coding. 3. Message Structure and Sequencing The function of the AMP is to deliver Execution-Set (EXECSET) and Reporting-Set (RPTSET) values to a DTNMA Agent and a Manager respectively. Together these support the needs described in Section 2.3 of [I-D.ietf-dtn-amm]. Each AMP message consists of a version number followed by any number of binary form ARI values, as defined in Section 5 of [I-D.ietf-dtn-ari]. All AMP messages conforming to this specification SHALL contain version number 1. Any AMP messages received with an unknown version number SHALL be ignored. Each of the contained ARIs SHALL be either an EXECSET or a RPTSET. The EXECSET is used to communicate from Manager to Agent and cause execution activities within the Agent as defined in Section 3.1. The RPTSET is used to communicate from Agent to Manager, which includes reports and (specific) execution results from the Agent, as defined in Section 3.2. Each AMP message has the following CDDL definition. Birrane & Sipos Expires 10 May 2025 [Page 5] Internet-Draft DTNMA AMP November 2024 amp-msg = [ version: 1, *amp-ari ] amp-ari = (lit-execset / lit-rptset) .within ari 3.1. Execution-Set Values When received by an Agent, an EXECSET value SHALL result in immediate execution activities based on the message contents. Each item in the target list SHALL be executed independently (_i.e._, failures on one item do not affect other items). Each item in the target list MAY be executed in any order or concurrently. This is not the same behavior as execution of a macro (see Section 6.6.3 of [I-D.ietf-dtn-amm]), where execution of items is ordered and a failure of any execution causes subsequent items to not be executed. When possible, Managers SHOULD coalesce multiple execution targets into a single EXECSET value. This avoids the overhead of processing multiple messages on an Agent to cause multiple executions, but it does require that all or none of the executions are associated with a nonce value. | Because execution targets are supposed to be idempotent (see | Section 3.4.5 of [I-D.ietf-dtn-amm]) there is no need to | differentiate multiple targets with the same object-identity- | and-parameters when using the same nonce. 3.2. Reporting-Set Values When received by a Manager, each report within a RPTSET value SHALL be correlated to its ADM or ODM object used to interpret its source- specific data. Each report in the Report List SHALL be processed independently (_i.e._, failures on one report do not affect other items). Each report in the Report List MAY be processed in any order or concurrently. When associated to the same nonce value, Agents SHOULD coalesce multiple reports into a single RPTSET value. The coalescing MAY be based on a time interval or an event (e.g. power-saving wake-up). This avoids the overhead of processing multiple RPTSET values on a Manager and improves timestamp compression in the items, but it does require that all or none of the items are associated with the same nonce value. Birrane & Sipos Expires 10 May 2025 [Page 6] Internet-Draft DTNMA AMP November 2024 4. Bundle Protocol Transport When embedded as block type-specific data (BTSD) within a BPv7 payload block in accordance with [RFC9171], the application data unit (ADU) SHALL consist of an AMP message (see Section 3) as a CBOR sequence. The payload BTSD has the following CDDL definition. amp-adu = bstr .cborseq amp-msg When Agents and Managers register endpoints on a BPA, they SHOULD use the well-known service numbers defined in Section 5.1. Using well- known identifiers simplifies configuration and troubleshooting but is not necessary for correct AMP operation. When BPv7 is used as transport for AMP, the primary and payload blocks SHALL be authenticated by a BPSec [RFC9172] mechanism traceable to the message source. This can be either block integrity block (BIB) or block confidentiality block (BCB) using an authenticated encryption algorithm, either using an authenticated public key of the source directly or via some security association derived from an authenticated public key or from a security gateway and delegated for the bundle source. It is an network policy and configuration issue to determine the correct use of BPSec for any particular Manager and Agent. When processing an AMP ADU, the processing context SHALL include the following: * The bundle Source Node ID * An indication of the authenticity of the primary and payload blocks, along with the Security Source Node ID used to authenticate them 5. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of schema and namespaces related to the Application Resource Identifier (ARI), in accordance with BCP 26 [RFC1155]. 5.1. URI Schemes This document defines entries in the registry "'ipn' Scheme URI Well- known Service Numbers for BPv7" within the "URI Schemes" registry group [IANA-URI] containing the following. Birrane & Sipos Expires 10 May 2025 [Page 7] Internet-Draft DTNMA AMP November 2024 // RFC Editor: The values for TBA1 and TBA2 below should be assigned // from the range 128-255. +=========+==============+===========+ | Value | Description | Reference | +=========+==============+===========+ | | DTNMA Agent | [This | | // TBA1 | role | document] | +---------+--------------+-----------+ | | DTNMA | [This | | // TBA2 | Manager role | document] | +---------+--------------+-----------+ Table 1: 'ipn' Scheme URI Well- known Service Numbers for BPv7 6. Security Considerations Security within the AMP exists in two distinct layers as follows: Transport Security: Transport security addresses the questions of authentication, integrity, and confidentiality associated with the transport of messages between Managers and Agents. This security is applied before any particular entity in the system receives data and, therefore, its specifics are outside of the scope of this document. The BP transport specified in Section 4 does require some authentication which covers the AMP payload, but details are network- and implementation-specific. Access Control: Fine grained object-level security is provided and enforced by Agents via access control lists (ACLs) which are part of an Agent's configuration. An Agent's ACLs could be managed via an ADM using AMP itself, but such details are also outside the scope of this document. 7. References 7.1. Normative References [IANA-URI] IANA, "Uniform Resource Identifier (URI) Schemes", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Birrane & Sipos Expires 10 May 2025 [Page 8] Internet-Draft DTNMA AMP November 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, . [I-D.ietf-dtn-amm] Birrane, E. J., Sipos, B., and J. Ethier, "DTNMA Application Management Model (AMM) and Data Models", Work in Progress, Internet-Draft, draft-ietf-dtn-amm-01, 21 July 2024, . [I-D.ietf-dtn-ari] Birrane, E. J., Annis, E., and B. Sipos, "DTNMA Application Resource Identifier (ARI)", Work in Progress, Internet-Draft, draft-ietf-dtn-ari-02, 21 July 2024, . 7.2. Informative References [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, DOI 10.17487/RFC1155, May 1990, . [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . Birrane & Sipos Expires 10 May 2025 [Page 9] Internet-Draft DTNMA AMP November 2024 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, . [I-D.ietf-core-comi] Veillette, M., Van der Stok, P., Pelov, A., Bierman, A., and C. Bormann, "CoAP Management Interface (CORECONF)", Work in Progress, Internet-Draft, draft-ietf-core-comi-19, 3 November 2024, . [I-D.ietf-dtn-dtnma] Birrane, E. J., Heiner, S., and E. Annis, "DTN Management Architecture", Work in Progress, Internet-Draft, draft- ietf-dtn-dtnma-14, 28 April 2024, . Appendix A. Example Messages An example of an Execution-Set being sent to an Agent has the following ARI text representation. ari:/EXECSET/n=1234;(//example-adm-a/CTRL/dothing,//example-adm-a/CONST/amacro) Assuming some enumeration values for the ADM and objects results in the following transformed ARI. ari:/EXECSET/n=1234;(//65536/-3/18,//65536/-2/43) This is embedded into an AMP message with the following CBOR sequence. 1, [20, [1234, [65536, -3, 18], [65536, -2, 43]]] Which is encoded to the following binary string. 0x018214831904D2831A000100002212831A0001000021182B An example of a corresponding Reporting-Set being sent to a Manager has the following ARI text representation. ari:/RPTSET/n=1234;r=/TP/20230102T030405Z;(t=/TD/PT0S;s=//example-adm-a/CTRL/dothing;(null))(t=/TD/PT5S;s=//example-adm-a/CTRL/other;(567)) Which results in the following transformed ARI. Birrane & Sipos Expires 10 May 2025 [Page 10] Internet-Draft DTNMA AMP November 2024 ari:/RPTSET/n=1234;r=/TP/725943845;(t=/TD/0;s=//65536/-3/18;(null))(t=/TD/5;s=//65536/-3/6;(567))) This is embedded into an AMP message with the following CBOR sequence. 1, [21, 1234, 725943845, [0, [65536, -3, 18], null], [5, [65536, -3, 6], 567]] Which is encoded to the following binary string. 0x0185151904D21A2B4506258300831A000100002212F68305831A000100002206190237 Implementation Notes This section is to be removed before publishing as an RFC. A reference implementation of an earlier revision of the AMP is available in the 3.6.2 release of the ION open source code base available from the ION-DTN (https://sourceforge.net/projects/ion- dtn/) Sourceforge project. An extraction of the same AMP Agent and Manager from ION into a stand-alone project is available in the DTNMA Tools (https://github.com/JHUAPL/dtnma-tools) GitHub project. This project also contains an updated Wireshark AMP dissector (https://github.com/JHUAPL/dtnma-tools/tree/main/wireshark) for the corresponding earlier revision of this draft. Acknowledgments The following participants contributed technical material, use cases, and useful thoughts on the overall approach to this protocol specification: Jeremy Pierce-Mayer of INSYEN AG contributed the concept of the typed data collection and early type checking in the protocol. David Linko and Evana DiPietro of the Johns Hopkins University Applied Physics Laboratory contributed appreciated review and type checking of various elements of this specification. Authors' Addresses Edward J. Birrane, III The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Rd. Laurel, MD 20723 United States of America Phone: +1 443 778 7423 Email: Edward.Birrane@jhuapl.edu Birrane & Sipos Expires 10 May 2025 [Page 11] Internet-Draft DTNMA AMP November 2024 Brian Sipos The Johns Hopkins University Applied Physics Laboratory Email: brian.sipos+ietf@gmail.com Birrane & Sipos Expires 10 May 2025 [Page 12]