idnits 2.17.1 draft-schoenw-lmap-netconf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 15, 2013) is 4087 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-netconf-rfc5539bis-01 -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 6536 (Obsoleted by RFC 8341) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft Jacobs University Bremen 4 Intended status: Standards Track February 15, 2013 5 Expires: August 19, 2013 7 Considerations on using NETCONF with LMAP Measurement Agents 8 draft-schoenw-lmap-netconf-00.txt 10 Abstract 12 This document discusses how the NETCONF protocol can be used to 13 configure LMAP measurement agents. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 19, 2013. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Properties of Measurement Agents . . . . . . . . . . . . . . . 3 51 3. Properties of the NETCONF Protocol . . . . . . . . . . . . . . 3 52 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1. Connection Initiation . . . . . . . . . . . . . . . . . . . 4 54 4.2. Client and Server Role . . . . . . . . . . . . . . . . . . 5 55 4.3. Identification of Configuration Versions . . . . . . . . . 5 56 4.4. Pushing of Measurement Results . . . . . . . . . . . . . . 5 57 4.5. NETCONF versus YANG-API . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. Informative References . . . . . . . . . . . . . . . . . . . . 7 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 This document discusses how the NETCONF protocol [RFC6241] can be 67 used to configure Large-Scale Measurement of Broadband Performance 68 (LMAP) measurement agents (MAs), sometimes also called measurement 69 clients [I-D.schulzrinne-lmap-requirements]. 71 MAs may be deployed as separate hardware devices or as functions 72 embedded in consumer electronic devices and home routers or as pure 73 software solutions that can be installed on off-the-shelf computing 74 equipment. Measurement agents receive instructions from a controller 75 when and how to conduct what measurements (the measurement schedule) 76 and how and when to report measurement results to a data collector 77 (the report schedule). Further information about the interaction 78 between MAs and controllers and collectors can be found in 79 [I-D.schulzrinne-lmap-requirements]. 81 2. Properties of Measurement Agents 83 Measurement Agents (MAs) have a number of important properties: 85 1. MAs are often deployed behind Network Address Translators (NATs). 86 This might even be true if MAs are part of a device on the 87 demarcation line between a service provider and a home network 88 due to the usage of Carried Grade NATs in the service provider 89 network. 91 2. MAs may run on devices that are not always powered up and online. 93 3. A single controller may be responsible for a large number of MAs. 95 4. A large fraction of the MAs may be inactive (i.e., they do not 96 perform any measurements) at any given point in time. Inactive 97 MAs may need to be enabled on demand for example to troubleshoot 98 specific problems (e.g., as part of customer helpdesk services) 99 or to balance measurement traffic load. 101 3. Properties of the NETCONF Protocol 103 The Network Configuration Protocol (NETCONF) [RFC6241] provides 104 mechanisms to install, manipulate, and delete the configuration of 105 network devices. It uses an Extensible Markup Language (XML)-based 106 data encoding for the configuration data as well as the protocol 107 messages. The NETCONF protocol operations are realized as remote 108 procedure calls (RPCs). 110 The NETCONF protocol runs by default over the Secure Shell protocol 111 (SSH) [RFC6242] but it can also be used over Transport Layer Security 112 (TLS) [RFC5539] with pairwise authentication using X.509 113 certificates. 115 NETCONF has been originally designed to be used on network devices 116 such as backbone routers. A device supporting NETCONF has an 117 embedded NETCONF server. Configuration management applications use 118 embedded NETCONF clients to connect to NETCONF servers and then issue 119 RPC calls to manipulate the configuration state of the devices. 121 4. Discussion 123 This section discusses certain technical challenges related to the 124 usage of NETCONF to configure MAs. 126 4.1. Connection Initiation 128 Due to the nature of LMAP MAs (likely located behind NATs), it is 129 crucial that MAs initiate connections to a controller. This is 130 currently not supported in NETCONF. There were previous attempts to 131 provide a so called call-home mechanism for NETCONF, see for example 132 [I-D.kwatsen-reverse-ssh]. The current state of the art, however, is 133 that there is no standardized call home mechanism for NETCONF over 134 SSH. 136 For the NETCONF over TLS transport [RFC5539], which relies on mutual 137 authentication using X.509 certificates, it seems easier to support 138 call home. In fact, the NETCONF over TLS transport specification is 139 currently being updated and hence there is an opportunity to get call 140 home support into this update on relative short notice. The work 141 essentially requires to detail aspects such as port numbers used to 142 connect form a NETCONF server (acting as a TCP client) to a NETCONF 143 client (acting as a TCP server). In addition, a YANG data model 144 would be desirable that can be used to configure the call home policy 145 (when to call home) and the addresses to connect to and perhaps the 146 certificate to use. 148 Decoupling the NETCONF server / client role from the TCP server / 149 client role turns out to be straight-forward since every NETCONF 150 session starts with an exchange of messages. The 151 message sent by the NETCONF server includes a session-id while the 152 NETCONF client does not send a session-id. As such, both endpoints 153 can easily identify and verify who is acting as NETCONF client and 154 NETCONF server. [RFC6241] already handles the possible error cases 155 (i.e., a NETCONF server connecting to a NETCONF server or a NETCONF 156 client connecting to a NETCONF client). 158 4.2. Client and Server Role 160 Some large scale measurement deployments use proprietary protocols 161 where the server role is on the controller. In a nutshell, the MA 162 connects to the controller running a server and checks if there is a 163 configuration update to load. If so, the MA fetches the necessary 164 new configuration information and then applies it locally. 166 The NETCONF protocol, however, assumes that the NETCONF server role 167 is taken by the device that is configured. This would be in the LMAP 168 use case the MA while the NETCONF client would be running on the 169 controller. 171 Even though this may seem like a major difference in the way the 172 interaction works, it appears that NETCONF can provide the 173 functionality needed. A MA initiating a transport connection and 174 subsequently taking the NETCONF server role enables the controller 175 (acting as a NETCONF client) after the exchange to take the 176 initiative to determine whether any configuration changes need to be 177 applied to the device. If so, standard operations can 178 be used to modify the device's configuration. 180 4.3. Identification of Configuration Versions 182 As mentioned above, the controller (running a NETCONF client) must 183 determine whether a device's configuration needs updates. While this 184 could be achieved by retrieving the configuration using 185 and comparing the result with the expected configuration, this 186 approach is not very efficient. It will be much more effective if 187 the NETCONF server would indicate the version of the configuration it 188 is currently using. The version can either be identified by a 189 version number or a time-stamp of the last configuration change or 190 simply an opaque tag that is handed out and interpreted only by the 191 controller. While the configuration version might simply be modeled 192 as a regular data object that the NETCONF client retrieves in the 193 usual way, it might be useful to consider optimizations, e.g., 194 carrying the configuration version as part of a new capability in the 195 exchange. 197 4.4. Pushing of Measurement Results 199 NETCONF has not been designed as a data push protocol. While a 200 NETCONF extension [RFC5277] provides support for event notifications, 201 this mechanism requires in its simplest form that a NETCONF client 202 first subscribes to an event stream and that the session used to 203 carry event notification stays open. This is not scalable in the 204 LMAP scenario. 206 One possible way to work around this limitation within the framework 207 of the current NETCONF protocol is to make use of the event 208 notification replay feature: A MA is locally collecting measurement 209 results. After connecting to a collector (acting as a NETCONF 210 client), the collector subscribes to an event stream with a request 211 to replay the measurement results collected since the last time data 212 has been fetched from the MA. An alternative, of course, would be to 213 model test results as part of an LMAP data model and to use NETCONF 214 operations to retrieve the data. 216 That said, if close to soft real-time pushing of measurement results 217 form the MA to the collector is required, then NETCONF likely is not 218 the right choice. 220 4.5. NETCONF versus YANG-API 222 NETCONF provides a feature rich solution for network configuration 223 management, including support for concurrent access to a NETCONF 224 server by multiple NETCONF clients, different configuration 225 datastores, explicit validation of configurations, and a confirmed- 226 commit procedure to support configuration change transactions 227 spanning multiple devices. A recent proposal called YANG-API 228 [I-D.bierman-netconf-yang-api] aims at providing a simplified 229 interface that follows RESTful principles and is compatible with a 230 resource-oriented device abstraction. 232 While implementations of YANG-API are in progress, it seems too early 233 to decide whether the benefits of RESTful YANG-API are significant 234 enough to consider it as a possible alternative for LMAP. In 235 particular, it might take a few years for YANG-API to become a stable 236 specification. 238 5. Security Considerations 240 The NETCONF protocol [RFC6241] can run over several different 241 transports. Since the protocol manipulates sensitive configuration 242 information, NETCONF requires that all transports provide 243 authentication, data integrity, confidentiality, and replay 244 protection. 246 There are currently two transport for NETCONF on the standards track. 247 The NETCONF over SSH transport [RFC6242] provides authentication and 248 data encryption services. The NETCONF over SSH specification further 249 requires that the identity of the SSH server must be verified and 250 authenticated by the SSH client according to local policy before 251 password-based authentication data or any configuration or state data 252 is sent to or received from the SSH server. Similarily, the identity 253 of the SSH client must also be verified and authenticated by the SSH 254 server according to local policy to ensure that the incoming SSH 255 client request is legitimate before any configuration or state data 256 is sent to or received from the SSH client. Neither side should 257 establish a NETCONF over SSH connection with an unknown, unexpected, 258 or incorrect identity on the opposite side. 260 The NETCONF over TLS transport [RFC5539], currently being revised in 261 [I-D.ietf-netconf-rfc5539bis], provides authentication and data 262 encryption services. In particular, [RFC5539] assumes that both 263 peers authenticate each other using X.509 certificates while 264 [I-D.ietf-netconf-rfc5539bis] adds the possibility to use pre-shared 265 keys. 267 The NETCONF access control model [RFC6536] provides an authorization 268 model for NETCONF. It allows to configure access control rules that 269 can be used to restrict NETCONF protocol access for particular users 270 to a pre-configured subset of all available NETCONF protocol 271 operations and content. The NETCONF access control model should be 272 required for LMAP implementations that potentially allow access from 273 multiple controllers. 275 6. IANA Considerations 277 TBD 279 7. Acknowledgements 281 TBD 283 8. Informative References 285 [I-D.bierman-netconf-yang-api] 286 Bierman, A. and M. Bjorklund, "YANG-API Protocol", 287 draft-bierman-netconf-yang-api-01 (work in progress), 288 November 2012. 290 [I-D.ietf-netconf-rfc5539bis] 291 Badra, M., Luchuk, A., and J. Schoenwaelder, "NETCONF Over 292 Transport Layer Security (TLS)", 293 draft-ietf-netconf-rfc5539bis-01 (work in progress), 294 October 2012. 296 [I-D.kwatsen-reverse-ssh] 297 Watsen, K., "Reverse Secure Shell (Reverse SSH)", 298 draft-kwatsen-reverse-ssh-01 (work in progress), 299 June 2011. 301 [I-D.schulzrinne-lmap-requirements] 302 Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale 303 Measurement of Broadband Performance: Use Cases, 304 Architecture and Protocol Requirements", 305 draft-schulzrinne-lmap-requirements-00 (work in progress), 306 September 2012. 308 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 309 Notifications", RFC 5277, July 2008. 311 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 312 RFC 5539, May 2009. 314 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 315 Bierman, "Network Configuration Protocol (NETCONF)", 316 RFC 6241, June 2011. 318 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 319 Shell (SSH)", RFC 6242, June 2011. 321 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 322 Protocol (NETCONF) Access Control Model", RFC 6536, 323 March 2012. 325 Author's Address 327 Juergen Schoenwaelder 328 Jacobs University Bremen 330 Email: j.schoenwaelder@jacobs-university.de