Internet Engineering Task Force J. Haas, Ed.
Internet-Draft Juniper Networks
Intended status: Informational March 8, 2015
Expires: September 9, 2015
I2RS requirements for netmod/netconf
draft-haas-i2rs-netmod-netconf-requirements-01
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 September 9, 2015.
Copyright Notice
Copyright (c) 2015 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 September 9, 2015 [Page 1]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. I2RS Requirements . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Data Store Requirements . . . . . . . . . . . . . . . . . 3
2.1.1. A Separate Ephemeral Datastore . . . . . . . . . . . 3
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.7. Transaction Requirements . . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
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.
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.
Haas Expires September 9, 2015 [Page 2]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
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
<hello> message if it supports the specified YANG module
persistently and/or ephemerally.
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
Haas Expires September 9, 2015 [Page 3]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
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.
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.
Haas Expires September 9, 2015 [Page 4]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
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 NETCONF service over SSH is believed to provide the necessary
mutual authentication services required by I2RS. Per [RFC6242]: "The
identity of the SSH server MUST be verified and authenticated by the
SSH client according to local policy before password-based
authentication data or any configuration or state data is sent to or
received from the SSH server. The identity of the SSH client MUST
also be verified and authenticated by the SSH server according to
local policy to ensure that the incoming SSH client request is
legitimate before any configuration or state data is sent to or
received from the SSH client. Neither side should establish a
NETCONF over SSH connection with an unknown, unexpected, or incorrect
identity on the opposite side."
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. This secondary identity is an opaque
value. [I-D.ietf-i2rs-traceability] provides an example of how the
secondary identity can be used for traceability.
Haas Expires September 9, 2015 [Page 5]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
If in support of the I2RS prioririty requirements if it is determined
to be necessary to annotate state with the client that added it, the
secondary identity SHOULD be included for troubleshooting.
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.
Haas Expires September 9, 2015 [Page 6]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
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
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
[I-D.ietf-i2rs-pub-sub-requirements] has been published and contains
the requirements for I2RS for publication and subscription services.
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 mis-formatted,
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
is accepted, but notification will be sent that BGP peering can't be
established.
3. IANA Considerations
This document introduces no new considerations to IANA.
4. Security Considerations
TBD
Haas Expires September 9, 2015 [Page 7]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
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
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-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-00 (work in progress), March 2015.
Haas Expires September 9, 2015 [Page 8]
Internet-Draft I2RS requirements on NETMOD/NETCONF March 2015
[I-D.ietf-i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and
Information Model", draft-ietf-i2rs-traceability-02 (work
in progress), March 2015.
[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.
[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.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, 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
Email: jhaas@juniper.net
Haas Expires September 9, 2015 [Page 9]
