idnits 2.17.1 draft-wangzheng-netconf-proxy-01.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 (July 3, 2017) is 2489 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 97, but not defined == Unused Reference: 'RFC793' is defined on line 641, 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: 2 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: January 4, 2018 July 3, 2017 7 Network Configuration Protocol (NETCONF) Proxy 8 draft-wangzheng-netconf-proxy-01 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 January 4, 2018. 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. Netconf Proxy Use Case . . . . . . . . . . . . . . . . . 4 54 1.2.1. Using Netconf Proxy to manage VNF Elements . . . . . 4 55 1.2.2. Using NetConf Proxy to manage the Non-Gateway 56 Elements of OSN (Optical Switch Network) . . . . . . 5 57 1.3. Requirements Terminology . . . . . . . . . . . . . . . . 6 58 2. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 3. The NETCONF Client . . . . . . . . . . . . . . . . . . . . . 8 60 4. The Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5. The Target . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 6. New attribute: target-id . . . . . . . . . . . . . . . . . . 11 63 7. YANG DATA MODEL . . . . . . . . . . . . . . . . . . . . . . . 12 64 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 65 7.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 70 10.2. Informative References . . . . . . . . . . . . . . . . . 15 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 This document proposes a NETCONF Proxy mechanism. The mechanism 76 extends the NETCONF protocol [RFC6241] which provides a standard way 77 to set up NETCONF session. At its core, the mechanism defined here 78 introduces a set of new operations which allow a client to forward 79 NETCONF requests to a target host through an intermediary NETCONF 80 proxy server, especially in case where client would otherwise not 81 have direct network access to a target host. The document also 82 includes YANG data model which extend the model and RPCs defined 83 within [RFC6241]. 85 1.1. Motivation 87 NETCONF provide a RPC-based mechanism to facilitate communication 88 between a client and a server. The client can be a script or 89 application typically running as part of a network manager. The 90 server is typically a network device [RFC6241]. However, the network 91 manager may not have direct network access to the target network 92 devices. For example, some target network devices may locate in a 93 network with private addresses behind a NAT device or a firewall. 94 Thus, network manager cannot direct communicate with these target 95 devices. 97 NETCONF Call Home [RFC8071] provides a mechanism that allows NETCONF 98 Servers to initiate a connection with a NETCONF client, reversing the 99 normal direction of NETCONF session setup. This allows a NETCONF 100 Server, e.g. a networking device that needs to be managed, to reach 101 out to a NETCONF Client, e.g. an Operations Support System of an SDN 102 controller, in order to be managed. By reversing the direction in 103 which NETCONF sessions are normally set up, problems such as 104 establishing connectivity with devices behind a firewall can be 105 alleviated. However, NETCONF Call Home requires that the server 106 knows its client by way of configuration or discovery. It does not 107 address the scenarios as presented below: 109 1. In some NFV scenarios, VNF instances are running in a private 110 network. To reduce the management resources (like IP resources, 111 bandwidth, etc) of large-scale management activities, these VNF 112 instances may not be assigned IP addresses. Then the element 113 management system (EMS), which located in public network, cannot 114 be aware of the addresses of VNF instances. Therefore, the 115 element management system (EMS) is difficult to manage these VNF 116 instances via NETCONF protocol. More details please see section 117 1.2.1. 119 2. And in some cloud network scenarios, the gateway network element 120 (GNE) and non-gateway network elements (N-GNEs) communicate with 121 each other using some private protocol. And these non-gateway 122 network elements (N-GNEs) may not IP devices. Therefore, the 123 cloud centre EMS (element management system) cannot be aware of 124 the addresses of N-GENs. Thus, the element management system 125 (EMS) is difficult to manage these N-GNE devices via NETCONF 126 protocol. More details please see section 1.2.2. 128 To solve that problem, this document proposes a NETCONF Proxy 129 mechanism. The proxy can acts as an intermediary between manager and 130 target device, therefore the client can set up a NETCONF session to a 131 target through a NETCONF Proxy. 133 The mechanism allows the client to subsequently direct NETCONF 134 requests to the server, to receive responses, and to subscribe to 135 notifications from the server. While the NETCONF Proxy can be used 136 to traverse NAT boundaries, it should be noted that it does not apply 137 NAT mappings for contents carried as part of the NETCONF payload; 138 specifically, it does not substitute IP address information that is 139 carried as part of data nodes. 141 1.2. Netconf Proxy Use Case 143 1.2.1. Using Netconf Proxy to manage VNF Elements 145 Figure 1 illustrates EMS manage the VNF instances. 147 +--------------+ 148 | EMS | 149 +-------+------+ 150 | 151 | NetConf Over SSH/TLS 152 | 153 +...................|.........................+ 154 . +------+--------+ . 155 . | VNFM | . 156 . +-------+-------+ . 157 . / | \ . 158 . / | \ Neconf Over ITPC. 159 . / | \ . 160 . / | \ . 161 . / | \ . 162 . +-------+ +-------+ +-------+ . 163 . | VNFI_1| | VNFI_2| | VNFI_3| . 164 . +-------+ +-------+ +-------+ . 165 . VNF Network . 166 +.............................................+ 168 Using Netconf Proxy to manage VNF Elements 170 EMS is connected to VNFM through public network. To reduce the cost 171 of management resources (like IP resources, bandwidth, etc) for 172 large-scale management activities, the VNFIs(VNF instances) are 173 running a TIPC(Transparent Inter-process Communication) protocol, and 174 these VNIs are not assigned IP address. The management data of VNFIs 175 will be transported to VNFM via TIPC. Within the VNF Network, the 176 TIPC protocol will provide the data to the respective application 177 i.e. NETCONF. 179 To manage the VNFIs, EMS will access the VNFIs via the Netconf Proxy 180 which located in the VNFM. EMS is access to Netconf Proxy through 181 Netconf over SSH. Within the VNF network, the NETCONF data will be 182 transported from VNFM to VNFIs over Transparent Inter-process 183 Communication (TIPC) protocol. And the VNFIs will report their IDs 184 and other information to netconf proxy. The netconf proxy will store 185 these information in the "target-list". According to these 186 information, the EMS can manage the VNFIs via Netconf Proxy, more 187 details see section 2. 189 1.2.2. Using NetConf Proxy to manage the Non-Gateway Elements of OSN 190 (Optical Switch Network) 192 Figure 2 illustrates EMS manage the Non-Gateway Elements of Optical 193 Switch Network (OSN) via Netconf Proxy. 195 ---------------- 196 //// +-------+\ 197 /// | | \\\ 198 // +-------+ |IP Device \\ 199 || | | +-------+ | 200 | | IP Device | 201 | +-------+ | 202 | | 203 | +-------+ | 204 || | | | 205 \\ |IP Device // 206 \\\ / +-------+ /// 207 X\\\ //// 208 // ---------------- 209 / 210 +-------+ 211 | | 212 | EMS | 213 +- /---+ 214 / 215 +---------+ 216 |Netconf Proxy ------------ 217 | +-- -\\\\ 218 //| Gateway NE ----- +-------+-\\\ 219 // -+-----+---+ ---- |Non-Gateway \ 220 // | --+ NE | \\ 221 | | +----+--+ | 222 || | | | 223 | | | | 224 | | | | 225 || +---+---+ +----+---+ | 226 | |Non-Gateway | Non-Gateway | 227 \\ |NE |-------------- NE | // 228 \\ +-------+ +--------+ // 229 \\\\ OSN ///// 230 \\\\-- --//// 231 ----------------- 233 Using Netconf Proxy to manage VNF Elements 235 The network between EMS and GNE is IP Accessible whereas the network 236 between GNE and N-GNE is not IP Accessible. Therefore, the EMS 237 cannot be aware of the address of N-GENs. Note that the Non-Gateway 238 Elements are not IP devices, thus the N-GNE cannot support NAT. The 239 management data of N-GNE will be transported to GNE on OSN's private 240 transmission layer. Within the OSN Network Elements, the OSN private 241 transmission protocol (i.e. via QX interface [G.773]) will provide 242 the data to the respective application i.e. NETCONF. 244 To manage the non-gateway network elements, NMS will access the non- 245 gateway NE via the Netconf Proxy which located in the gateway network 246 element (GNE). EMS is access to Netconf Proxy through Netconf over 247 SSH. Within the OSN, the NETCONF data will be transported from GNE 248 to Non-GNEs over OSN private transport protocol. And the Non-GNEs 249 will report their IDs and other information to netconf proxy. The 250 netconf proxy will store these information in the "target-list". 251 According to these information, the EMS can manage the Non-Gateway 252 Elements of OSN via Netconf Proxy, more details see section 2. 254 1.3. Requirements Terminology 256 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 257 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 258 document are to be interpreted as described in RFC 2119 [RFC2119]. 260 2. Solution Overview 262 The diagram below illustrates how the client can set up a NETCONF 263 session to a target through the NETCONF proxy. 265 client proxy target ID:A1 266 | | | 267 | | | 268 | | | 269 |<--------------------------->| | 270 | | | 271 | | | 272 | | | 273 |---------------------------->| | 274 | | | 275 |<----------------------------| | 276 | | | 280 | | | 281 | | | 282 | | | 284 | target="A1" | | 285 | xmlns="urn:xxxx"> | | 286 | | | 287 | | case 1: target_id can be | 288 | |------------------------->| 289 | | found | 290 | | Forward message | 291 | | | 292 | |<-------------------------| 293 | | | 294 |<----------------------------| | 295 | | | 296 | | case 2: target_id cannot | 297 | | be found | 298 | | | 299 |<----------------------------| | 300 | | | 301 | | | 302 | invalid-target | | 303 | | | 304 | ... | | 305 | | | 306 | | | 308 This diagram makes the following points: 310 1. The client initiates the connection using the SSH/TLS transport 311 protocol. When the NETCONF session is established, the client 312 and proxy MUST send a element containing a list of that 313 peer's capabilities. The proxy SHOULD send at least the 314 "netconf" and "proxy" capabilities. And other rules of 315 capabilities exchange described in section 8 of [RFC6241]. 317 2. The client sends a RPC to proxy to retrieve the "target- 318 list" of the proxy. 320 3. The proxy responds with a RPC which containing 321 "target-list" attributes. The "target-list" attributes includes 322 the target's information such as target-id, protocol, 323 authentication, etc. 325 4. The client receives a the RPC from the proxy, and 326 retrieves the target information according to the received 327 "target-list". Subsequently, the client can direct NETCONF 328 requests to the target according to the received "target-list", 329 to receive responses, and to subscribe to notifications from the 330 target. For example, the client wants to retrieve the 331 configuration information of a target. The client should 332 construct a message according to the received 333 "target-list". This message SHOULD contain at least 334 a "target-id" attribute. And then client sends this 335 message to proxy and waits for a reply. 337 5. The proxy receives the RPC message and checks the value of 338 "target-id" attribute: 340 If the target is not found, then an "invalid-target" error 341 will be returned. 343 If the target can be found, then proxy forwards the RPC 344 message, which received from client, to corresponding target. 346 6. The target receives the RPC message. And then sends an message in response to the received RPC message. 349 3. The NETCONF Client 351 The term "client" is defined in [RFC6241], Section 1.1 "client". In 352 the context of network management, the NETCONF client might be a 353 network management system for example a EMS (element management 354 system). 356 The client operation describes as follows: 358 1. The client initiates a connection to proxy using the SSH/TLS 359 transport protocol [RFC6242]. How to establish an SSH/TLS transport 360 connection is described in [RFC6242] 362 2. When the NETCONF session is established, the client sends a 363 message to proxy, then waits for a reply. This 364 message contains a list of client's capabilities. 366 3. After capabilities exchange, the client sends a RPC to 367 proxy to retrieve the "target-list" of the proxy, then waits for a 368 reply. 370 4. The client receives the RPC from the proxy, looks up 371 the value of "target-list", and then constructs a RPC message 372 according to the received "target-list". 374 For example, the client wants to retrieve the configuration 375 information of a target A1. The client should construct a message. This message SHOULD contain at least a 377 "target-id" attribute: 379 382 383 384 385 386 387 388 389 390 391 392 394 And then client sends this message to proxy and waits for a 395 reply. 397 5. If the reply containing a element which satisfied with 398 "Positive Response" condition of corresponding RPC (Section 7 of 399 [RFC6241]), it means that the client has successfully managed the 400 target device. 402 6. If the reply contains the "invalid-target" error, the process 403 turn to step (4) or aborts. 405 7. Otherwise, the client interprets the error and aborts. 407 4. The Proxy 409 The Proxy should ensure that requests given by client for a 410 particular target device should reach the target device and the 411 operations should be executed on that target device and the response 412 should be given back to the client. 414 The proxy operation describes as follows: 416 1. When the NETCONF session is established, the proxy sends a 417 element containing a list of proxy's capabilities. The proxy 418 SHOULD send at least the "netconf" and "proxy" capabilities. And 419 other rules of capabilities exchange described in section 8 of 420 [RFC6242]. 422 2. The proxy receives the RPC and then responds with a RPC which containing "target-list" attributes. The "target- 424 list" attributes SHOULD includes the target's information such as 425 target-id, protocol, etc. The following example shows a "target- 426 list": 428 429 A1 430 protocol-foo 431 433 3. The proxy receives the RPC message and checks the value of 434 "target-id" attribute: 436 If the target is not found in target-list, then an "invalid- 437 target" error will be returned. 439 If the target can be found, then proxy forwards the RPC message, 440 which received from client, to corresponding target. 442 4. In this Netconf-Proxy model, the proxy reads data from both the 443 client and the target, and writes any data received to the other end, 444 without interpreting the data. If any side of the connection is 445 closed, the proxy closes the other side. 447 5. The Target 449 The term "target" is equivalent to the term "server" which is defined 450 in [RFC6242], Section 1.1 "server". In the context of network 451 management, the target is typically a network device. 453 The target operations describes as follows: 455 If the connection between the proxy and the target established. And 456 target receives the RPC message from the proxy, and then responds a 457 message. 459 If the target can satisfy the RPC request, the target sends an 460 element containing a element which satisfied 461 with "Positive Response" condition of corresponding RPC (Section 7 462 of [RFC6241]). 464 If an error occurs during the processing of an request, the 465 target sends an element which includes a corresponding 466 element (Section 7 of [RFC6241]). 468 6. New attribute: target-id 470 A proxy can be used by a client to connect to several servers and to 471 maintain multiple NETCONF sessions. A client may use the proxy even 472 to maintain multiple NETCONF sessions with the same NETCONF server. 473 When issuing a NETCONF request, a client must therefore differentiate 474 between NETCONF sessions. To solve this problem, a new attribute 475 "target-id" is defined. This attribute allow the proxy to forward 476 RPC to corresponding target. 478 For example: 480 The following element invokes the NETCONF method and 481 includes the "target-id" attribute: 483 486 487 489 492 493 494 495 497 7. YANG DATA MODEL 499 7.1. Overview 501 The YANG data model for NETCONF Proxy is depicted in the following 502 figure. Following Yang tree convention in the depiction, brackets 503 enclose list keys, "rw" means configuration, "ro" operational state 504 data, "?" designates optional nodes, "*" designates nodes that can 505 have multiple instances. A "+" at the end of a line indicates that 506 the line is to be concatenated with the subsequent line. 508 module: ietf-netconf-proxy 509 +--rw proxy {proxy}? 510 +--rw proxy-name? string 511 +--rw target-list* [target-id] 512 +--rw target-id string 513 +--rw protocol? string 514 +--rw authentication? string 516 7.2. YANG Module 518 file "ietf-netconf-proxy@2017-03-09.yang" 519 module ietf-netconf-proxy { 521 namespace "urn:ietf:params:xml:ns:yang:ietf-netconf-proxy"; 523 prefix np; 525 organization 526 "IETF NETCONF (Network Configuration) Working Group"; 528 contact 529 "WG Web: http://tools.ietf.org/wg/netconf 530 WG List: netconf@ietf.org 532 WG Chair: Mehmet Ersue 533 mehmet.ersue@nsn.com 535 Editor: zitao wang 536 wangzitao@huawei.com"; 538 description 539 "NETCONF Protocol Data Types and Protocol Operations. 541 Copyright (c) 2011 IETF Trust and the persons identified as 542 the document authors. All rights reserved. 544 Redistribution and use in source and binary forms, with or 545 without modification, is permitted pursuant to, and subject 546 to the license terms contained in, the Simplified BSD License 547 set forth in Section 4.c of the IETF Trust's Legal Provisions 548 Relating to IETF Documents 549 (http://trustee.ietf.org/license-info). 551 This YANG module describe how to define a netconf proxy"; 553 revision 2017-03-09 { 554 description 555 "Initial revision"; 556 reference 557 "draft-wang-netconf-proxy"; 558 } 560 feature proxy { 561 description 562 "Netconf proxy"; 563 } 565 container proxy { 566 if-feature proxy; 567 leaf proxy-name{ 568 type string; 569 description 570 "Proxy name"; 571 } 572 list target-list { 573 key "target-id"; 574 leaf target-id{ 575 type string; 576 description 577 "Target ID"; 578 } 579 leaf protocol { 580 type string; 581 description 582 "Support protocols"; 583 } 584 leaf authentication { 585 type string; 586 description 587 "Authentication"; 588 } 589 description 590 "List for target information"; 591 } 592 description 593 "Container for NETCONF Proxy"; 594 } 596 } 597 599 8. Security Considerations 601 The security considerations described in [RFC6242] and [RFC7589], and 602 by extension [RFC4253], [RFC5246] apply here as well. 604 9. IANA Considerations 606 TBD 608 10. References 610 10.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, 614 DOI 10.17487/RFC2119, March 1997, 615 . 617 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 618 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 619 January 2006, . 621 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 622 (TLS) Protocol Version 1.2", RFC 5246, 623 DOI 10.17487/RFC5246, August 2008, 624 . 626 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 627 and A. Bierman, Ed., "Network Configuration Protocol 628 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 629 . 631 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 632 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 633 . 635 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 636 NETCONF Protocol over Transport Layer Security (TLS) with 637 Mutual X.509 Authentication", RFC 7589, 638 DOI 10.17487/RFC7589, June 2015, 639 . 641 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 642 September 1981, . 644 10.2. Informative References 646 [G.773] "Protocol suites for Q-interfaces for management of 647 transmission systems", ITU-T Recommendation G.773, 1993. 649 Authors' Addresses 651 Zitao Wang 652 Huawei Technologies 653 101 Software Avenue, Yuhua District 654 Nanjing 655 China 657 EMail: wangzitao@huawei.com 659 Guangying Zheng 660 Huawei Technologies 661 101 Software Avenue, Yuhua District 662 Nanjing 663 China 665 EMail: zhengguangying@huawei.com