Internet Engineering Task Force J. Haas, Ed. Internet-Draft Juniper Networks Intended status: Informational September 12, 2014 Expires: March 16, 2015 I2RS requirements for netmod/netconf draft-haas-i2rs-netmod-netconf-requirements-00 Abstract This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. 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 http://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 March 16, 2015. Copyright Notice Copyright (c) 2014 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 (http://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. Haas Expires March 16, 2015 [Page 1] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. I2RS Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Data Store Requirements . . . . . . . . . . . . . . . . . 3 2.1.1. A Separate Ephemeral Datastore . . . . . . . . . . . 4 2.1.2. Tagged Ephemeral Modules in the Running Datastore . . 4 2.1.3. Permitting Existing Configuration State to be Made Optionally Ephemeral . . . . . . . . . . . . . . . . 4 2.2. Mutual Authentication Requirements . . . . . . . . . . . 5 2.2.1. NETCONF over SSH . . . . . . . . . . . . . . . . . . 5 2.2.2. NETCONF/RESTCONF over TLS . . . . . . . . . . . . . . 5 2.3. Identity, Secondary-Identity Requirements; Priority Requirements; Implications . . . . . . . . . . . . . . . 5 2.3.1. Identity Requirements . . . . . . . . . . . . . . . . 5 2.3.2. Priority Requirements . . . . . . . . . . . . . . . . 6 2.3.3. Implications of Idenities and Priorities on Internal State . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Access Control Model Requirements . . . . . . . . . . . . 6 2.4.1. Data Store Implications . . . . . . . . . . . . . . . 6 2.4.2. I2RS Priority . . . . . . . . . . . . . . . . . . . . 6 2.5. Connectivity Requirements . . . . . . . . . . . . . . . . 6 2.6. Notification and Subscription Requirements . . . . . . . 7 2.6.1. Persistence of Subscriptions . . . . . . . . . . . . 7 2.6.2. Filtering Considerations . . . . . . . . . . . . . . 7 2.6.2.1. Expressivity of Existing Filtering Mechanisms . . 7 2.6.2.2. Filtering Workload . . . . . . . . . . . . . . . 8 2.7. Transaction Requirements . . . . . . . . . . . . . . . . 8 2.8. Object Relationship Requirements . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction The Interface to the Routing System (I2RS) Working Group is chartered with providing architecture and mechanisms to inject into and retrieve information from the routing system. The I2RS Architecture document [I-D.ietf-i2rs-architecture] abstractly documents a number of requirements for implementing the I2RS requirements. The I2RS Working Group has chosen to use the YANG data modeling language [RFC6020] as the basis to implement its mechanisms. Haas Expires March 16, 2015 [Page 2] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 Additionally, the I2RS Working group has chosen to use the NETCONF [RFC6241] and its similar but lighter-weight relative RESTCONF [I-D.bierman-netconf-restconf] as the protocols for carrying I2RS. While YANG, NETCONF and RESTCONF are a good starting basis for I2RS, there are some things needed from each of them in order for I2RS to be implemented. Note that this draft does not attempt to address specific implementation of I2RS requirements that the existing YANG, RESTCONF and NETCONF mechanisms are expected to cover. A separate draft will be issued for the consumption of the I2RS Working Group for such cases. 2. I2RS Requirements 2.1. Data Store Requirements One of the key mechanisms in I2RS is the ability to inject configuration state into a network element on an ephemeral basis. While at first glance this may seem equivalent to the writable- running datastore in NETCONF, running-config can be copied to a persistant data store, like startup config. The author wishes to prevent any action that would lead to preserving any configuration state entered via the I2RS agent across reboots. If state has to be restored, it should be solely by replay actions from I2RS client via I2RS agent. A few options for implementing such ephemeral configuration suggest themselves, as do some possible problems with such an implementation: 1. A separate ephemeral datastore. The semantics of this datastore is that all configuration state is known ahead of time to not survive reboot and is not to be copied into persistent storage. Such a datastore could be referenced by NETCONF and RESTCONF using existing semantics, such as "target" and "source". 2. Configuration state in the existing running datastore where the module is "tagged ephemeral". 3. Permitting existing configuration to be optionally configured as ephemeral. As an example, the NETCONF server advertises in its message if it supports the specified YANG module persistently and/or ephemerally. Haas Expires March 16, 2015 [Page 3] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 2.1.1. A Separate Ephemeral Datastore The primary advantage of a fully separate datastore is that the semantics of its contents are always clearly ephemeral. It also provides strong segregation of I2RS configuration and operational state from the rest of the system within the network element. The most obvious disadvantage of such a fully separate datastore is that interaction with the network element's operational or configuration state becomes significantly more difficult. As an example, a BGP I2RS use case would be the dynamic instantiation of a BGP peer. While it is readily possible to re-use any defined groupings from an IETF-standardized BGP module in such an I2RS ephemeral datastore's modules, one cannot currently reference state from one datastore to another. For example, XPath queries are done in the context document of the datastore in question and thus it is impossible for an I2RS model to fulfil a "must" or "when" requirement in the BGP module in the standard data stores. To implement such a mechanism would require appropriate semantics for XPath. 2.1.2. Tagged Ephemeral Modules in the Running Datastore Presume a YANG keyword that flagged an entire module as being ephemeral. In such a case, entire modules could be crafted for I2RS (and other) purposes wherein the configuration state in the module had ephemeral properties. The primary property is that copy operations would not be able to cause the I2RS state to persist. An obvious issue with this is the muddying of the semantics of existing NETCONF/RESTCONF operations. For example, get-config is expected to return the configuration state for the network element, but the knowledge that the configuration state may not persist is important. This may require alterations to get-config (and similar commands) along with the ambiguity of copy-config not picking up the ephemeral modules. Providing additional parameters to the various configuration related operations in NETCONF/RESTCONF would likely be required. 2.1.3. Permitting Existing Configuration State to be Made Optionally Ephemeral In YANG, configuration state is distinguished from operational state using "config true" vs. "config false". One way to implement I2RS state would be to introduce a third option, "config ephemeral", to configuration. Haas Expires March 16, 2015 [Page 4] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 A form of this option was previously discussed in [I-D.rfernando-i2rs-yang-mods]. The suggestion of "config ephemeral" is made instead due to potential non-I2RS interest in this feature at the microphone during the IETF-90 session of netmod in Toronto, Canada. 2.2. Mutual Authentication Requirements "Mutual authentication between the I2RS Client and I2RS Agent is required. An I2RS Client must be able to trust that the I2RS Agent is attached to the relevant Routing Element so that write/ modify operations are correctly applied and so that information received from the I2RS Agent can be trusted by the I2RS Client." Implementing the mutual authentication requirements for I2RS in each of the underlying protocols and their transports have some implications to be discussed. 2.2.1. NETCONF over SSH The SSH transport does not mandate authentication be done; it is an optional feature. In an I2RS context, authentication is mandatory. Authentication of the client to the agent is carried out using any method besides "none". Authentication of the agent to the client requires that the server's public key be recognized. 2.2.2. NETCONF/RESTCONF over TLS Agent validation of the I2RS client is mandated over TLS in an I2RS context. The client shall also validate the Agent using its server certificate. 2.3. Identity, Secondary-Identity Requirements; Priority Requirements; Implications 2.3.1. Identity Requirements I2RS requires clients to have an identity. This identity will be used by the Agent authentication mechanism over the appropriate protocol. I2RS also permits clients to have a secondary identity which may be used for troubleshooting. Haas Expires March 16, 2015 [Page 5] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 2.3.2. Priority Requirements To support Multi-Headed Control, I2RS requires that there be a decidable means of arbitrating the correct state of data when multiple clients attempt to manipulate the same piece of data. This is done via a priority mechanism with the highest priority winning. This priority may vary on a per-node or subtree basis based for a given identity. 2.3.3. Implications of Idenities and Priorities on Internal State Given the requirements for I2RS identities and priority arbitration, I2RS configured state must have "meta-data" that includes the identity that caused it to come into being. Agents must also be able to map priority on a particular piece of configuration state vs. the identity provisioning it for arbitration purposes. Such mapping might be represented as part of the "meta-data" or potentially a distinct mapping database of identity vs. priority vs. configuration state. Such a mapping may be implemented using an extension to the NETCONF Access Control Model [RFC6536]. 2.4. Access Control Model Requirements 2.4.1. Data Store Implications As noted above, one of the possible options for implementing the I2RS ephemeral behavior is a separate data store. However, this clashes with Section 3.2 of [RFC6536] which limits itself to the well- known data stores. 2.4.2. I2RS Priority A likely implementation of priority arbitration would be to extend the NACM model to also contain criteria for I2RS priority. 2.5. Connectivity Requirements I2RS does not require clients to maintain active communication channels with their agents. Agents thus require the ability to open communication channels back to clients to satisfy previously requested information. [I-D.ietf-netconf-call-home] describes a mechanism by which NETCONF may "phone home" using SSH and TLS. While NETCONF notifications currently permit a different client to establish a session to an agent specifically for notification purposes, the I2RS use case typically expects that provisioning of Haas Expires March 16, 2015 [Page 6] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 notifications is centrally managed and that systems receiving the notifications should not need to be individually to be provisioned. 2.6. Notification and Subscription Requirements 2.6.1. Persistence of Subscriptions NETCONF Event Notifications [RFC5277] provides a mechanism by which subscriptions may be created. In that RFC, subscriptions are terminated when the underlying transport session ends. As noted in the prior section, I2RS does not require its clients to maintain a connection to its agents. Thus, a mechanism by which subscriptions may be created and persist through the termination of the transport session is required. Management of these subscriptions implies the ability to: o Create a "headless" subscription and determine what its endpoint is. o Specify the type and various parameters for the endpoint session. For example, the need for confidentiality may not be required for some notifications or a highly efficient transport may be required. Experience over the years has shown that very light- weight transports, for example UDP for SNMP NOTIFICATIONs/TRAPs, enables low-end components to participate in notification in a distributed fashion. A long-term implication may be that additional lighter-weight transports may be needed for I2RS notification channels. o Delete such "headless" subscriptions. o Enumerate the set of those subscriptions on the network element. o Apply Access Control to the above abilities. 2.6.2. Filtering Considerations 2.6.2.1. Expressivity of Existing Filtering Mechanisms XPath is provided as the mechanism in [RFC6241] for extended filtering. While XPath is a highly expressive language, it tends to be best suited for string and simple math-based filtering. I2RS, being an interface to network elements, will typically have as common types IPv4 and IPv6 addresses, prefixes for the same and may require network mask interactions for firewalling. These and other Haas Expires March 16, 2015 [Page 7] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 examples suggest that long term extensions appropriate for efficient filtering of I2RS types may be required. As an example, a regular expression filter that can match addresses covered by "192.0.2.128/25" would need to match on the string "192.0.2." as a prefix and all final octets with the string representations of the values greater than or equal to 128. While methodologies for building such regular expressions are well known within the networking world, it typically results in poor performance. 2.6.2.2. Filtering Workload Filtering, additionally, is implied to be a mechanism of the "central event processor". I2RS subscriptions may be implemented on data objects wherein a small, filtered portion of a subtree is being monitored, but the magnitude of events being generated is substantial. Given this filtering workload, implementations are suggested to "push" the filtering to relevant system components to "pre-filter" events when possible. 2.7. Transaction Requirements Each transaction should be treated as atomic and providing full functionality. If the configuration change is not functionally complete, then the transaction should fail and be rolled back ( rollback 0). Example, I2RS agents wants to configure BGP: routing-options { autonomous-system autonomous-system; } protocols { bgp { group group-name { peer-as autonomous-system; type type; neighbor address; } } } If a statement like neighbor address is missing or is missformated, like 300.127.5.23, configuration is not functional, transaction should fail and rollback 0 should be performed by the I2RS agent on the ephemeral config store. If the neighbor address is in the transaction, but the address is not reachable or similar, transaction Haas Expires March 16, 2015 [Page 8] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 is accepted, but notification will be sent that BGP peering can't be established. 2.8. Object Relationship Requirements XXX JMH - I've largely convinced myself that the "instance- identifier" and "require-instance" YANG keywords satisfy the properties required by I2RS. If you don't, please supply an example. 3. IANA Considerations This document introduces no new considerations to IANA. 4. Security Considerations TBD 5. Acknowledgements This document is an attempt to distill length conversations on the I2RS mailing list for an architecture that was for a long period of time a moving target. Some individuals in particular warrant speicfic mention for their extensive help in providing the basis for this document: o Alia Atlas o Andy Bierman o Martin Bjorklund o Dean Bogdanavich o Rex Fernando o Joel Halpern o Susan Hares o Thomas Nadeau o Juergen Schoenwaelder o Kent Watsen Haas Expires March 16, 2015 [Page 9] Internet-Draft I2RS requirements on NETMOD/NETCONF September 2014 6. Normative References [I-D.bierman-netconf-restconf] Bierman, A., Bjorklund, M., Watsen, K., and R. Fernando, "RESTCONF Protocol", draft-bierman-netconf-restconf-04 (work in progress), February 2014. [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-05 (work in progress), July 2014. [I-D.ietf-netconf-call-home] Watsen, K., "NETCONF Call Home", draft-ietf-netconf-call- home-00 (work in progress), September 2014. [I-D.rfernando-i2rs-yang-mods] Fernando, R., pals, p., Madhayyan, M., and A. Clemm, "YANG modifications for I2RS", draft-rfernando-i2rs-yang-mods-00 (work in progress), February 2013. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, October 2010. [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, "Network Configuration Protocol (NETCONF)", RFC 6241, June 2011. [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration Protocol (NETCONF) Access Control Model", RFC 6536, March 2012. Author's Address Jeffrey Haas (editor) Juniper Networks 1194 N. Mathida Ave. Sunnyvale, CA 94089 US Email: jhaas@juniper.net Haas Expires March 16, 2015 [Page 10]