]> U.S. Army CERDEC

328 Hopkins Road Aberdeen Proving Ground MD 21005 USA +1.410.278.6779 robert.g.cole@us.army.mil http://www.cs.jhu/~rgcole/

Avaya

Atidim Technology Park, Bldg. #3 Tel Aviv 61131 Israel dromasca@avaya.com

InterWorking Labs

303 Potrero Street, Suite 52 Santa Cruz, CA 95060-2760 USA andyb@iwl.com

General Internet Engineering Task Force configuration management, verification, manets, dtns This document extends the capabilities of the NETCONF configuration management protocol in order to standardize mechanisms to perform sets of active tests (i.e., verification) against servers' running configuration to afford the client and server a more robust and resilient configuration management capability. Specifically, this document defines a transaction test module based upon the defined set of Uniform Resource Locators. The transaction tests in this module are executed by the NETCONF verify operation.

This document identifies enhancements to NETCONF capabilities to achieve a more robust model of configuration management for future IETF systems. Most network management systems which are required to provide a highly robust network service rely upon some form of out-of-band access for configuration management. This provides an alternative management entry into devices in the event that in-band access is unavailable due to, e.g., mis-configuration. However, not all network deployments can afford the luxury of alternative networks for management access to all networking devices, nor should this be necessary. Examples include Mobile Ad-Hoc Wireless Networks (MANETs) and other forms of Disruption Tolerant Networks (DTNs). All managed networks, as well, would benefit from a more robust and extensive configuration management capability from the IETF, e.g., to provide equivalent network reliability at reduced infrastructure costs. Towards this objective, we propose that the NETCONF protocol RFC 4741 requires extension of capabilities to define and manage active tests and assess success, i.e., Verification, (from both the client and the servers) involving server-side running configuration. This document augments the verify capability within NETCONF by defining a transaction test module. This allows the network management application to exercise the transaction tests through a standard mechanism. In this test module, the transactions are defined within the context of defined Uniform Resource Locators (URLs). This allows the network management application to exercise the transaction tests through an extensible mechanism. As an example, we envision a NETCONF client-server interaction model shown in the below figure. Here, the client issues a <commit> with the confirming option. As part of testing prior to issuing the confirming <commit> the client wishes to execute a set of verification transaction tests from the server. It issues the <verify> operation to manage this aspect of verification transaction testing. The client passes a reference to the server indicating instances of specific pre-configured transaction tests within this module that define the specific test suite. The server executes these as part of the NETCONF <verify> testing process. Simultaneously, the client may also run a set of tests to gain confidence in the proposed configuration changes to the server. Once the server completes its test execution, it indicates success through notification messages. Once the client is comfortable with its own tests and those of the server, it issues the confirming <commit> to the server which forces the server to commit to the proposed configuration change; else the server backs out of the proposed configuration changes.

Sets up config +------------------------------> Sets up test control --- +------------------------------> | Sends (set - timeout timeout) - confirm option | | | +------------------------------> | Sends | - timeout | - test-template:instanceIDs | (running (running client-side server-side tests) tests) +--------+ | | | | | <--------+ | (server-side tests | complete) | <-----------------------------+ | notification | | | +-----------------------------> | Sends | | --- ]]>

This, and other Use Cases, are discussed further in the document defining the verify operation VERIFY of NETCONF. NETCONF defines the term 'validation' as the set of checks performed on proposed configuration code up to the point that the server places it into its running-configuration. We use the term 'verification' as the act of performing active tests against configuration code in the running-configuration on the server. Verification tests can be executed from either the NETCONF client or the NETCONF server, or from a NETCONF server(a) against running configuration code on a NETCONF server(b), or all combinations. In this document, we define the transaction.yang module as a first example of a test module supporting the NETCONF verify operation. This allows for extensible verification testing of configuration across the base of IETF compliant devices. This leads to more resilient configuration management for operators manging multi-vendor networks of devices. This will promote future integrated network management capabilities as opposed to device management capabilities.

Our objective is to promote the development of a robust and resilient network configuration capability, building upon the improvements afforded by the NETCONF protocol and it's associated modeling language, YANG. The envisioned benefits of a standardized set of mechanisms and capabilities for verification testing include: Minimize faulty configuration and network disconnects, Provide for uniform methods for control, execution and reporting of verification testing in multi-vendor networks, Improve automation of extensive verification testing, Provide opportunity for device modelers to associate/recommend tests tied to specific configuration items, and Improve efficiency of coordinated network upgrades.

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 RFC 2119.

In the remainder of this document we present a description of the transaction.yang test module. This is followed with 'Acknowledgments' and 'IANA Considerations' sections. A section on 'Security Considerations' is provided concluding the main body of the document. In the appendix, i.e., 'Appendix A: transaction.yang', we define the transaction.yang module.

The transaction.yang module defines a set of transaction tests that can be instrumented via NETCONF and executed through the verify operation. We briefly discuss the verify operation in the context of executing the transaction tests. We then discuss the construction of the transaction.yang module. The definitive definition of the transaction.yang module is found in Appendix A of this document.

The verify operation, defined in VERIFY, allows for the execution of verification tests within the NETCONF protocol. The construction of the verify operation is illustrated in the following diagram. Here a verify command is given with associated timeout and test-template parameters. The multiple test-template parameters each indicate a specific set of tests defined within the transaction.yang module resident on the server. The specific tests are pre-configured through standard NETCONF commands prior to issuing the verify operation. The definition of the verify operation allows various levels of reporting of the test results back to the NETCONF client.

3600 /tt:transaction/tt:controlTableEntry[tt:controlTableIndex=21] /tt:transaction/tt:controlTableEntry[tt:controlTableIndex=42] /tt:transaction/tt:controlTableEntry[tt:controlTableIndex=48] true false ]]>

The transaction.yang module is designed to support an extensible set of transaction test for the purpose of verification testing of proposed configuration changes. As such, we have modeled the module after the Uniform Resource Locator (URL) definition. The module is defined in six basic functions: Protocol - defines the set of protocol transactions supported by the server and referenced through the URL 'scheme'. Location Profile - defines a set of URLs which are predefined for later execution. Network Profile - defines a set of reuse-able network layer parameters. Metric Profile - defines the performance aspects of the tests, e.g., frequency, metric, etc. Control Table - defines the specific verification test sets. Results table - contains the results of the verification test sets. Refer to Appendix A for the definitive statement of the transaction.yang module.

This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see the update of RFC 2434 for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

This section presents the required security considerations for all IETF protocols and capabilities. This section was developed following guidelines within RFC 3552. This section addresses the security concerns and objectives for the for the use of the transaction.yang module within the context of the :verify capability in NETCONF. (NOTE: This section is currently TBD.) Security issues related to the use of the transaction.yang module should address issues specific to the remote execution of verification tests. Here is an initial list of potential considerations: Verification requires server-side tests that require that packets to be injected into the network for the purpose of measuring some performance characteristics. As such, associated test modules will contain sensitive network and application data; e.g., user IDs and passwords. Further, if security is compromised, this capability could provide a source for denial-of-service, and potential other, attacks. The configuration of verification tests may require passing sensitive network information. For this reason, this configuration information should be encrypted prior to transport over the network. Some test attributes configure username and password information for some application-level protocols as indicated above. Access to these attributes may provide unauthorized use of resources. Some test attributes configure the size and rate of traffic flows for the purpose of performance measurements. Access to these attributes may exacerbate the use of this capability in denial-of-service attacks. It is recommended that test modules define a maximum packet rate on the device and to indicate this rate. Other objects that control aspects of the test packets related to packet size and rate are will exist in test modules and bounds on these should be set. Test module objects will exist which set the source and destination addresses on the packet headers. The server should not allow the setting of source addresses on the test packets other than those that are administratively configured onto the server.

&RFC2119; &RFC4741; &RFC3552; &I-D.narten-iana-considerations-rfc2434bis;

In this appendix we define the transaction.yang model for use in conjunction with the robust-netconf capabilities.