idnits 2.17.1 draft-wangzheng-netconf-proxy-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2599 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) == Missing Reference: 'RFC8071' is mentioned on line 91, but not defined == Unused Reference: 'RFC793' is defined on line 500, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group Z. Wang 3 Internet-Draft G. Zheng 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 14, 2017 March 13, 2017 7 Network Configuration Protocol (NETCONF) Proxy 8 draft-wangzheng-netconf-proxy-00 10 Abstract 12 This document presents Network Configuration Protocol (NETCONF) Proxy 13 through which NETCONF requests can be forwarded to a target host. It 14 would be useful when a client does not have direct network access to 15 a target host. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 14, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 3 54 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The NETCONF Client . . . . . . . . . . . . . . . . . . . . . 5 56 4. The Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. The Target . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. New attribute: target-id . . . . . . . . . . . . . . . . . . 8 59 7. YANG DATA MODEL . . . . . . . . . . . . . . . . . . . . . . . 8 60 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 This document proposes a NETCONF Proxy mechanism. The mechanism 70 extends the NETCONF protocol [RFC6241] which provides a standard way 71 to set up NETCONF session. At its core, the mechanism defined here 72 introduces a set of new operations which allow a client to forward 73 NETCONF requests to a target host through an intermediary NETCONF 74 proxy server, especially in case where client would otherwise not 75 have direct network access to a target host. The document also 76 includes YANG data model which extend the model and RPCs defined 77 within [RFC6241]. 79 1.1. Motivation 81 NETCONF provide a RPC-based mechanism to facilitate communication 82 between a client and a server. The client can be a script or 83 application typically running as part of a network manager. The 84 server is typically a network device [RFC6241]. However, the network 85 manager may not have direct network access to the target network 86 devices. For example, some target network devices may locate in a 87 network with private addresses behind a NAT device or a firewall. 88 Thus, network manager cannot direct communicate with these target 89 devices. 91 NETCONF Call Home [RFC8071] provides a mechanism that allows NETCONF 92 Servers to initiate a connection with a NETCONF client, reversing the 93 normal direction of NETCONF session setup. This allows a NETCONF 94 Server, e.g. a networking device that needs to be managed, to reach 95 out to a NETCONF Client, e.g. an Operations Support System of an SDN 96 controller, in order to be managed. By reversing the direction in 97 which NETCONF sessions are normally set up, problems such as 98 establishing connectivity with devices behind a firewall can be 99 alleviated. However, NETCONF Call Home requires that the server 100 knows its client by way of configuration or discovery. It does not 101 address the scenarios as presented below: 103 1. In some NFV scenarios, VNF instances are running in a private 104 network. To reduce the management resources (like IP resources, 105 bandwidth, etc) of large-scale management activities, these VNF 106 instances may not be assigned IP addresses. Then the element 107 management system (EMS), which located in public network, cannot 108 be aware of the addresses of VNF instances. Therefore, the 109 element management system (EMS) is difficult to manage these VNF 110 instances via NETCONF protocol. 112 2. And in some cloud network scenarios, the gateway network element 113 (GNE) and non-gateway network elements (N-GNEs) communicate with 114 each other using some private protocol. And these non-gateway 115 network elements (N-GNEs) may not IP devices. Therefore, the 116 cloud centre EMS (element management system) cannot be aware of 117 the addresses of N-GENs. Thus, the element management system 118 (EMS) is difficult to manage these N-GNE devices via NETCONF 119 protocol. 121 To solve that problem, this document proposes a NETCONF Proxy 122 mechanism. The proxy can acts as an intermediary between manager and 123 target device, therefore the client can set up a NETCONF session to a 124 target through a NETCONF Proxy. 126 The mechanism allows the client to subsequently direct NETCONF 127 requests to the server, to receive responses, and to subscribe to 128 notifications from the server. While the NETCONF Proxy can be used 129 to traverse NAT boundaries, it should be noted that it does not apply 130 NAT mappings for contents carried as part of the NETCONF payload; 131 specifically, it does not substitute IP address information that is 132 carried as part of data nodes. 134 1.2. Requirements Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 2. Solution Overview 142 The diagram below illustrates how the client can set up a NETCONF 143 session to a target through the NETCONF proxy. 145 client proxy target ID:A1 146 | | | 147 | | | 148 | | | 149 |<--------------------------->| | 150 | | | 151 | | | 152 | | | 153 |---------------------------->| | 154 | | | 155 |<----------------------------| | 156 | | | 160 | | | 161 | | | 162 |---------------------------->| | 163 | | authenticate & connect | 164 | |------------------------->| 165 | | | 166 | | | 167 | |------------------------->| 168 | |<-------------------------| 169 |<----------------------------| | 170 | | | 171 | | | 173 | target="A1" | | 174 | xmlns="urn:xxxx"> | | 175 | | | 177 This diagram makes the following points: 179 1. The client initiates the connection using the SSH/TLS transport 180 protocol. When the NETCONF session is established, the client 181 and proxy MUST send a element containing a list of that 182 peer's capabilities. The proxy SHOULD send at least the 183 "netconf" and "proxy" capabilities. And other rules of 184 capabilities exchange described in section 8 of [RFC6241]. 186 2. The client sends a RPC to proxy to retrieve the "target- 187 list" of the proxy. 189 3. The proxy responds with a RPC which containing 190 "target-list" attributes. The "target-list" attributes includes 191 the target's information such as target-id, protocol, 192 authentication, etc. 194 4. The client receive a RPC from the proxy, and looks up 195 the value of "target-list". Then the client constructs a 196 message according to the received "target-list". This 197 massage SHOULD contain at least a "target-id" attribute. And 198 then client sends this message to proxy and waits for a 199 reply. 201 5. The proxy receives the message and checks the value of 202 "target-id" attribute: 204 If the target is not found, then an "invalid-target" error 205 will be returned. 207 If the target can be found, then the proxy initiates a 208 connection to corresponding target. And then proxy forwards 209 the message, which received from client, to 210 corresponding target. 212 6. The target receives the message and then responds a 213 message containing a list of capabilities. The rules of 214 capabilities exchange described in section 8 of [RFC6241]. 216 7. Now, client established a NETCONF session to a target through 217 NETCONF Proxy. Subsequently, the client can direct NETCONF 218 requests to the target, to receive responses, and to subscribe to 219 notifications from the target. 221 3. The NETCONF Client 223 The term "client" is defined in [RFC6241], Section 1.1 "client". In 224 the context of network management, the NETCONF client might be a 225 network management system for example a EMS (element management 226 system). 228 The client operation describes as follows: 230 1. The client initiates a connection to proxy using the SSH/TLS 231 transport protocol [RFC6242]. How to establish an SSH/TLS transport 232 connection is described in [RFC6242] 234 2. When the NETCONF session is established, the client sends a 235 message to proxy, then waits for a reply. This 236 message contains a list of client's capabilities. 238 3. After capabilities exchange, the client sends a RPC to 239 proxy to retrieve the "target-list" of the proxy, then waits for a 240 reply. 242 4. The client receive a RPC from the proxy, looks up the 243 value of "target-list", and then constructs a message 244 according to the received "target-list". This massage SHOULD 245 contain at least a "target-id" attribute. For example, if the client 246 received "target-list" containing "target-id=A1", then the client 247 constructs message: 249 C: 250 C: A1 251 C: foo 252 C: 254 And then client sends this message to proxy and waits for a 255 reply. 257 5. If the reply presents the "capabilities" of target, the proxy 258 connection is established. Subsequently, the client can direct 259 NETCONF requests to the target, to receive responses, and to 260 subscribe to notifications from the target. 262 6. If the reply contains the "invalid-target" error, the process 263 turn to step (4) or aborts. 265 7. Otherwise, the client interprets the error and aborts. 267 4. The Proxy 269 The Proxy should ensure that requests given by client for a 270 particular target device should reach the target device and the 271 operations should be executed on that target device and the response 272 should be given back to the client. 274 The proxy operation describes as follows: 276 1. When the NETCONF session is established, the proxy sends a 277 element containing a list of proxy's capabilities. The proxy 278 SHOULD send at least the "netconf" and "proxy" capabilities. And 279 other rules of capabilities exchange described in section 8 of 280 [RFC6242]. 282 2. The proxy receives the RPC and then responds with a RPC which containing "target-list" attributes. The "target- 284 list" attributes SHOULD includes the target's information such as 285 target-id, protocol, authentication, etc. The following example 286 shows a "target-list": 288 289 A1 290 protocol-foo 291 authentication-foo 292 294 3. The proxy receives the message and checks the value of 295 "target-id" attribute: 297 If the target is not found in target-list, then an "invalid- 298 target" error will be returned. 300 If the target can be found in target-list, the proxy checks the 301 corresponding "protocol" and "authentication" of the "target-id". 302 And then, the proxy uses corresponding protocol to establish a 303 connection to the target. After session established, the proxy 304 forwards the message, which received from client, to 305 corresponding target. 307 4. If the reply presents the "capabilities" of target, the proxy 308 connection is established. Subsequently, the proxy transports the 309 messages received from the client to the target and vice versa. 311 5. The Target 313 The term "target" is equivalent to the term "server" which is defined 314 in [RFC6242], Section 1.1 "server". In the context of network 315 management, the target is typically a network device. 317 The target operations describes as follows: 319 1. If the connection between the proxy and the target established. 320 And target receives the message from the proxy, and then 321 responds a message containing a list of capabilities. The 322 rules of capabilities exchange described in section 8 of [RFC6242]. 324 2. After client established a NETCONF session to a target through 325 NETCONF Proxy. The client sends a series of one or more RPC request 326 messages, which cause the server to respond with a corresponding 327 series of RPC reply messages. 329 6. New attribute: target-id 331 A proxy can be used by a client to connect to several servers and to 332 maintain multiple NETCONF sessions. A client may use the proxy even 333 to maintain multiple NETCONF sessions with the same NETCONF server. 334 When issuing a NETCONF request, a client must therefore differentiate 335 between NETCONF sessions. To solve this problem, a new attribute 336 "target-id" is defined. This attribute allow the proxy to forward 337 RPC to corresponding target. 339 For example: 341 The following element invokes the NETCONF method and 342 includes the "target-id" attribute: 344 347 348 350 353 354 355 356 358 7. YANG DATA MODEL 360 7.1. Overview 362 The YANG data model for NETCONF Proxy is depicted in the following 363 figure. Following Yang tree convention in the depiction, brackets 364 enclose list keys, "rw" means configuration, "ro" operational state 365 data, "?" designates optional nodes, "*" designates nodes that can 366 have multiple instances. A "+" at the end of a line indicates that 367 the line is to be concatenated with the subsequent line. 369 module: ietf-netconf-proxy 370 +--rw proxy {proxy}? 371 +--rw proxy-name? string 372 +--rw target-list* [target-id] 373 +--rw target-id string 374 +--rw protocol? string 375 +--rw authentication? string 377 7.2. YANG Module 379 file "ietf-netconf-proxy@2017-03-09.yang" 380 module ietf-netconf-proxy { 382 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-proxy"; 384 prefix np; 386 organization 387 "IETF NETCONF (Network Configuration) Working Group"; 389 contact 390 "WG Web: http://tools.ietf.org/wg/netconf 391 WG List: netconf@ietf.org 393 WG Chair: Mehmet Ersue 394 mehmet.ersue@nsn.com 396 Editor: zitao wang 397 wangzitao@huawei.com"; 399 description 400 "NETCONF Protocol Data Types and Protocol Operations. 402 Copyright (c) 2011 IETF Trust and the persons identified as 403 the document authors. All rights reserved. 405 Redistribution and use in source and binary forms, with or 406 without modification, is permitted pursuant to, and subject 407 to the license terms contained in, the Simplified BSD License 408 set forth in Section 4.c of the IETF Trust's Legal Provisions 409 Relating to IETF Documents 410 (http://trustee.ietf.org/license-info). 412 This YANG module describe how to define a netconf proxy"; 414 revision 2017-03-09 { 415 description 416 "Initial revision"; 417 reference 418 "draft-wang-netconf-proxy"; 419 } 421 feature proxy { 422 description 423 "Netconf proxy"; 424 } 426 container proxy { 427 if-feature proxy; 428 leaf proxy-name{ 429 type string; 430 description 431 "Proxy name"; 432 } 433 list target-list { 434 key "target-id"; 435 leaf target-id{ 436 type string; 437 description 438 "Target ID"; 439 } 440 leaf protocol { 441 type string; 442 description 443 "Support protocols"; 444 } 445 leaf authentication { 446 type string; 447 description 448 "Authentication"; 449 } 450 description 451 "List for target information"; 452 } 453 description 454 "Container for NETCONF Proxy"; 455 } 457 } 458 460 8. Security Considerations 462 The security considerations described in [RFC6242] and [RFC7589], and 463 by extension [RFC4253], [RFC5246] apply here as well. 465 9. IANA Considerations 467 TBD 469 10. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, 473 DOI 10.17487/RFC2119, March 1997, 474 . 476 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 477 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 478 January 2006, . 480 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 481 (TLS) Protocol Version 1.2", RFC 5246, 482 DOI 10.17487/RFC5246, August 2008, 483 . 485 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 486 and A. Bierman, Ed., "Network Configuration Protocol 487 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 488 . 490 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 491 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 492 . 494 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 495 NETCONF Protocol over Transport Layer Security (TLS) with 496 Mutual X.509 Authentication", RFC 7589, 497 DOI 10.17487/RFC7589, June 2015, 498 . 500 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 501 September 1981, . 503 Authors' Addresses 504 Zitao Wang 505 Huawei Technologies 506 101 Software Avenue, Yuhua District 507 Nanjing 508 China 510 EMail: wangzitao@huawei.com 512 Guangying Zheng 513 Huawei Technologies 514 101 Software Avenue, Yuhua District 515 Nanjing 516 China 518 EMail: zhengguangying@huawei.com