Internet DRAFT - draft-schoenw-lmap-netconf
draft-schoenw-lmap-netconf
Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Bremen
Intended status: Standards Track February 15, 2013
Expires: August 19, 2013
Considerations on using NETCONF with LMAP Measurement Agents
draft-schoenw-lmap-netconf-00.txt
Abstract
This document discusses how the NETCONF protocol can be used to
configure LMAP measurement agents.
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 August 19, 2013.
Copyright Notice
Copyright (c) 2013 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.
Schoenwaelder Expires August 19, 2013 [Page 1]
Internet-Draft LMAP Data Model February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Properties of Measurement Agents . . . . . . . . . . . . . . . 3
3. Properties of the NETCONF Protocol . . . . . . . . . . . . . . 3
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Connection Initiation . . . . . . . . . . . . . . . . . . . 4
4.2. Client and Server Role . . . . . . . . . . . . . . . . . . 5
4.3. Identification of Configuration Versions . . . . . . . . . 5
4.4. Pushing of Measurement Results . . . . . . . . . . . . . . 5
4.5. NETCONF versus YANG-API . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Schoenwaelder Expires August 19, 2013 [Page 2]
Internet-Draft LMAP Data Model February 2013
1. Introduction
This document discusses how the NETCONF protocol [RFC6241] can be
used to configure Large-Scale Measurement of Broadband Performance
(LMAP) measurement agents (MAs), sometimes also called measurement
clients [I-D.schulzrinne-lmap-requirements].
MAs may be deployed as separate hardware devices or as functions
embedded in consumer electronic devices and home routers or as pure
software solutions that can be installed on off-the-shelf computing
equipment. Measurement agents receive instructions from a controller
when and how to conduct what measurements (the measurement schedule)
and how and when to report measurement results to a data collector
(the report schedule). Further information about the interaction
between MAs and controllers and collectors can be found in
[I-D.schulzrinne-lmap-requirements].
2. Properties of Measurement Agents
Measurement Agents (MAs) have a number of important properties:
1. MAs are often deployed behind Network Address Translators (NATs).
This might even be true if MAs are part of a device on the
demarcation line between a service provider and a home network
due to the usage of Carried Grade NATs in the service provider
network.
2. MAs may run on devices that are not always powered up and online.
3. A single controller may be responsible for a large number of MAs.
4. A large fraction of the MAs may be inactive (i.e., they do not
perform any measurements) at any given point in time. Inactive
MAs may need to be enabled on demand for example to troubleshoot
specific problems (e.g., as part of customer helpdesk services)
or to balance measurement traffic load.
3. Properties of the NETCONF Protocol
The Network Configuration Protocol (NETCONF) [RFC6241] provides
mechanisms to install, manipulate, and delete the configuration of
network devices. It uses an Extensible Markup Language (XML)-based
data encoding for the configuration data as well as the protocol
messages. The NETCONF protocol operations are realized as remote
procedure calls (RPCs).
Schoenwaelder Expires August 19, 2013 [Page 3]
Internet-Draft LMAP Data Model February 2013
The NETCONF protocol runs by default over the Secure Shell protocol
(SSH) [RFC6242] but it can also be used over Transport Layer Security
(TLS) [RFC5539] with pairwise authentication using X.509
certificates.
NETCONF has been originally designed to be used on network devices
such as backbone routers. A device supporting NETCONF has an
embedded NETCONF server. Configuration management applications use
embedded NETCONF clients to connect to NETCONF servers and then issue
RPC calls to manipulate the configuration state of the devices.
4. Discussion
This section discusses certain technical challenges related to the
usage of NETCONF to configure MAs.
4.1. Connection Initiation
Due to the nature of LMAP MAs (likely located behind NATs), it is
crucial that MAs initiate connections to a controller. This is
currently not supported in NETCONF. There were previous attempts to
provide a so called call-home mechanism for NETCONF, see for example
[I-D.kwatsen-reverse-ssh]. The current state of the art, however, is
that there is no standardized call home mechanism for NETCONF over
SSH.
For the NETCONF over TLS transport [RFC5539], which relies on mutual
authentication using X.509 certificates, it seems easier to support
call home. In fact, the NETCONF over TLS transport specification is
currently being updated and hence there is an opportunity to get call
home support into this update on relative short notice. The work
essentially requires to detail aspects such as port numbers used to
connect form a NETCONF server (acting as a TCP client) to a NETCONF
client (acting as a TCP server). In addition, a YANG data model
would be desirable that can be used to configure the call home policy
(when to call home) and the addresses to connect to and perhaps the
certificate to use.
Decoupling the NETCONF server / client role from the TCP server /
client role turns out to be straight-forward since every NETCONF
session starts with an exchange of <hello> messages. The <hello>
message sent by the NETCONF server includes a session-id while the
NETCONF client does not send a session-id. As such, both endpoints
can easily identify and verify who is acting as NETCONF client and
NETCONF server. [RFC6241] already handles the possible error cases
(i.e., a NETCONF server connecting to a NETCONF server or a NETCONF
client connecting to a NETCONF client).
Schoenwaelder Expires August 19, 2013 [Page 4]
Internet-Draft LMAP Data Model February 2013
4.2. Client and Server Role
Some large scale measurement deployments use proprietary protocols
where the server role is on the controller. In a nutshell, the MA
connects to the controller running a server and checks if there is a
configuration update to load. If so, the MA fetches the necessary
new configuration information and then applies it locally.
The NETCONF protocol, however, assumes that the NETCONF server role
is taken by the device that is configured. This would be in the LMAP
use case the MA while the NETCONF client would be running on the
controller.
Even though this may seem like a major difference in the way the
interaction works, it appears that NETCONF can provide the
functionality needed. A MA initiating a transport connection and
subsequently taking the NETCONF server role enables the controller
(acting as a NETCONF client) after the <hello> exchange to take the
initiative to determine whether any configuration changes need to be
applied to the device. If so, standard <edit-config> operations can
be used to modify the device's configuration.
4.3. Identification of Configuration Versions
As mentioned above, the controller (running a NETCONF client) must
determine whether a device's configuration needs updates. While this
could be achieved by retrieving the configuration using <get-config>
and comparing the result with the expected configuration, this
approach is not very efficient. It will be much more effective if
the NETCONF server would indicate the version of the configuration it
is currently using. The version can either be identified by a
version number or a time-stamp of the last configuration change or
simply an opaque tag that is handed out and interpreted only by the
controller. While the configuration version might simply be modeled
as a regular data object that the NETCONF client retrieves in the
usual way, it might be useful to consider optimizations, e.g.,
carrying the configuration version as part of a new capability in the
<hello> exchange.
4.4. Pushing of Measurement Results
NETCONF has not been designed as a data push protocol. While a
NETCONF extension [RFC5277] provides support for event notifications,
this mechanism requires in its simplest form that a NETCONF client
first subscribes to an event stream and that the session used to
carry event notification stays open. This is not scalable in the
LMAP scenario.
Schoenwaelder Expires August 19, 2013 [Page 5]
Internet-Draft LMAP Data Model February 2013
One possible way to work around this limitation within the framework
of the current NETCONF protocol is to make use of the event
notification replay feature: A MA is locally collecting measurement
results. After connecting to a collector (acting as a NETCONF
client), the collector subscribes to an event stream with a request
to replay the measurement results collected since the last time data
has been fetched from the MA. An alternative, of course, would be to
model test results as part of an LMAP data model and to use NETCONF
<get> operations to retrieve the data.
That said, if close to soft real-time pushing of measurement results
form the MA to the collector is required, then NETCONF likely is not
the right choice.
4.5. NETCONF versus YANG-API
NETCONF provides a feature rich solution for network configuration
management, including support for concurrent access to a NETCONF
server by multiple NETCONF clients, different configuration
datastores, explicit validation of configurations, and a confirmed-
commit procedure to support configuration change transactions
spanning multiple devices. A recent proposal called YANG-API
[I-D.bierman-netconf-yang-api] aims at providing a simplified
interface that follows RESTful principles and is compatible with a
resource-oriented device abstraction.
While implementations of YANG-API are in progress, it seems too early
to decide whether the benefits of RESTful YANG-API are significant
enough to consider it as a possible alternative for LMAP. In
particular, it might take a few years for YANG-API to become a stable
specification.
5. Security Considerations
The NETCONF protocol [RFC6241] can run over several different
transports. Since the protocol manipulates sensitive configuration
information, NETCONF requires that all transports provide
authentication, data integrity, confidentiality, and replay
protection.
There are currently two transport for NETCONF on the standards track.
The NETCONF over SSH transport [RFC6242] provides authentication and
data encryption services. The NETCONF over SSH specification further
requires that 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. Similarily, the identity
Schoenwaelder Expires August 19, 2013 [Page 6]
Internet-Draft LMAP Data Model February 2013
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.
The NETCONF over TLS transport [RFC5539], currently being revised in
[I-D.ietf-netconf-rfc5539bis], provides authentication and data
encryption services. In particular, [RFC5539] assumes that both
peers authenticate each other using X.509 certificates while
[I-D.ietf-netconf-rfc5539bis] adds the possibility to use pre-shared
keys.
The NETCONF access control model [RFC6536] provides an authorization
model for NETCONF. It allows to configure access control rules that
can be used to restrict NETCONF protocol access for particular users
to a pre-configured subset of all available NETCONF protocol
operations and content. The NETCONF access control model should be
required for LMAP implementations that potentially allow access from
multiple controllers.
6. IANA Considerations
TBD
7. Acknowledgements
TBD
8. Informative References
[I-D.bierman-netconf-yang-api]
Bierman, A. and M. Bjorklund, "YANG-API Protocol",
draft-bierman-netconf-yang-api-01 (work in progress),
November 2012.
[I-D.ietf-netconf-rfc5539bis]
Badra, M., Luchuk, A., and J. Schoenwaelder, "NETCONF Over
Transport Layer Security (TLS)",
draft-ietf-netconf-rfc5539bis-01 (work in progress),
October 2012.
[I-D.kwatsen-reverse-ssh]
Watsen, K., "Reverse Secure Shell (Reverse SSH)",
Schoenwaelder Expires August 19, 2013 [Page 7]
Internet-Draft LMAP Data Model February 2013
draft-kwatsen-reverse-ssh-01 (work in progress),
June 2011.
[I-D.schulzrinne-lmap-requirements]
Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale
Measurement of Broadband Performance: Use Cases,
Architecture and Protocol Requirements",
draft-schulzrinne-lmap-requirements-00 (work in progress),
September 2012.
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", RFC 5277, July 2008.
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)",
RFC 5539, May 2009.
[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
Juergen Schoenwaelder
Jacobs University Bremen
Email: j.schoenwaelder@jacobs-university.de
Schoenwaelder Expires August 19, 2013 [Page 8]
