idnits 2.17.1 draft-lear-netconfbeep-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 28 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2003) is 7560 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) == Unused Reference: '7' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-00 ** Obsolete normative reference: RFC 2222 (ref. '4') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '5') (Obsoleted by RFC 4346) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft K. Crozier 4 Expires: January 30, 2004 Cisco Systems 5 R. Enns 6 Juniper Networks 7 August 2003 9 NETCONF Transport over BEEP 10 draft-lear-netconfbeep-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 30, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document specifies a transport mapping for the NETCONF protocol 42 over the Blocks Extensible Exchange Protocol (BEEP). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . 4 48 2.1 NETCONF Session Initiation . . . . . . . . . . . . . . . . . 4 49 2.2 NETCONF RPC Execution . . . . . . . . . . . . . . . . . . . 4 50 2.3 NETCONF and . . . . . . . . . . . 5 51 2.4 NETCONF Session Teardown . . . . . . . . . . . . . . . . . . 5 52 2.5 BEEP Profiles for NETCONF Channels . . . . . . . . . . . . . 5 53 2.5.1 Management Channel Profile . . . . . . . . . . . . . . . . . 5 54 2.5.2 Operations Channel Profile . . . . . . . . . . . . . . . . . 7 55 2.5.3 Notification Channel Profile . . . . . . . . . . . . . . . . 9 56 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 57 Normative References . . . . . . . . . . . . . . . . . . . . 11 58 Informative References . . . . . . . . . . . . . . . . . . . 12 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 60 Intellectual Property and Copyright Statements . . . . . . . 13 62 1. Introduction 64 The NETCONF protocol [1] defines a simple mechanism through which a 65 network device can be managed. NETCONF is designed to be usable over 66 a variety of transport protocols. This document specifies a 67 transport mapping over the Blocks Extensible Exchange Protocol (BEEP) 68 [2] . 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119 [3]. 74 2. BEEP Transport Mapping 76 All NETCONF over BEEP implementations MUST implement the profile and 77 functional mapping between NETCONF and BEEP as described below. 79 2.1 NETCONF Session Initiation 81 Managers may be either BEEP listeners or initiators. Similarly, 82 agents may be either listeners or initiators. Thus the initial 83 exchange takes place without regard to whether a manager or the agent 84 is the initiator. After the transport connection is established, as 85 greetings are exchanged, they should each announce their support for 86 TLS [5] and optionally SASL [4] (see below), as well as for the 87 SYSLOG profile [6]. Once greetings are exchanged, if TLS is to be 88 used and available by both parties, the listener STARTs a channel 89 with the TLS profile. 91 Once TLS has been started, a new greeting is sent by both initiator 92 and listener, as required by the BEEP RFC. 94 At this point, if SASL is desired, the initiator starts BEEP channel 95 1 to perform a SASL exchange to authenticate itself. When SASL is 96 completed, the channel MUST be closed. 98 Once authentication has occurred, there is no need to distinguish 99 between initiator and listener. We now distinguish between manager 100 and agent. 102 The manager now establishes an NETCONF management channel for the 103 purpose of exchanging capabilities, monitoring progress, and aborting 104 remote procedure calls. As initiators assign odd channels and 105 listeners assign even channels, the management channel is BEEP 106 channel 1 or 2, depending on whether the manager is the initiator or 107 the listener. 109 The manager next establishes the NETCONF operational channel for the 110 purpose of issuing RPC requests. This channel is BEEP channel 3 or 111 4. 113 Finally, if either manager or agent wishes to send or receive 114 notifications, it may issue a start on the next available channel if 115 the other side has sent the send or receive NETCONF capability. 117 At this point, the NETCONF session is established. 119 2.2 NETCONF RPC Execution 121 To issue an RPC, the manager transmits on the operational channel a 122 BEEP MSG containing the RPC and its arguments. In accordance with 123 the BEEP standard, RPC requests may be split across multiple BEEP 124 frames. 126 Once received and processed, the agent responds with BEEP RPYs on the 127 same channel with the response to the RPC. In accordance with the 128 BEEP standard, responses may be split across multiple BEEP frames. 130 2.3 NETCONF and 132 and requests are issued by the manager on 133 the NETCONF management channel, and the agent responds with BEEP RPYs 134 on that same channel. 136 2.4 NETCONF Session Teardown 138 Either side may initiate the termination of an NETCONF session. In 139 This is done by issuing a BEEP close on the operational channel after 140 the current RPC has completed. The same is done with any 141 notification channels by the end that transmits notifications. 142 Finally, BEEP channel 0 is closed. 144 2.5 BEEP Profiles for NETCONF Channels 146 There are two profiles, the management channel profile and the 147 operations channel profile. These are not to be confused with the 148 BEEP control channel. 150 The operations channel will have two commands, and . 151 The management channel will have one additional operation with 152 . 154 2.5.1 Management Channel Profile 156 164 178 180 182 184 %BEEP; 186 198 213 214 215 216 --> 218 222 223 226 230 231 235 239 240 243 245 2.5.2 Operations Channel Profile 247 255 269 271 273 275 %BEEP; 277 288 301 302 304 --> 306 310 311 314 318 319 323 325 2.5.3 Notification Channel Profile 327 The NETCONF notification channel profile is defined in RFC 3195 [6]. 329 3. Security Considerations 331 Configuration information is by its very nature sensitive. Its 332 transmission in the clear and without integrity checking leaves 333 devices open to classic so-called "person in the middle" attacks. 334 Configuration information often times contains passwords, user names, 335 service descriptions, and topological information, all of which are 336 sensitive. A NETCONF transport protocol, therefore, must minimally 337 support options for both confidentiality and authentication. 339 BEEP makes use of both transport layer security and SASL. We require 340 that TLS be used in BEEP as described by the BEEP standard. 341 Client-side certificates are strongly desirable, but an SASL 342 authentication is the bare minimum. SASL allows for the use of 343 protocols such as RADIUS [9], so that authentication can occur off 344 the box. 346 SASL authentication will occur on the first channel creation. No 347 further authentication may occur during the same session. This 348 avoids a situation where rights are different between different 349 channels. If an implementation wishes to support multiple accesses 350 by different individuals with different rights, then multiple 351 sessions are required. 353 Different environments may well allow different rights prior to and 354 then after authentication. Thus, an authorization model is not 355 specified in this document. When an operation is not properly 356 authorized then a simple "permission denied" is sufficient. Note 357 that authorization information may be exchanged in the form of 358 configuration information, which is all the more reason to ensure the 359 security of the connection. 361 Normative References 363 [1] Enns, R., "NETCONF Configuration Protocol", 364 draft-ietf-netconf-prot-00 (work in progress), August 2003. 366 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 367 3080, March 2001. 369 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 370 Levels", BCP 14, RFC 2119, March 1997. 372 [4] Myers, J., "Simple Authentication and Security Layer (SASL)", 373 RFC 2222, October 1997. 375 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 376 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 377 1999. 379 [6] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 380 November 2001. 382 Informative References 384 [7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 385 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 386 REC-xml-20001006, October 2000. 388 [8] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 389 Use of Extensible Markup Language (XML) within IETF Protocols", 390 BCP 70, RFC 3470, January 2003. 392 [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 393 Authentication Dial In User Service (RADIUS)", RFC 2865, June 394 2000. 396 Authors' Addresses 398 Eliot Lear 399 Cisco Systems 400 170 W. Tasman Dr. 401 San Jose, CA 95134-1706 402 US 404 EMail: lear@cisco.com 406 Ken Crozier 407 Cisco Systems 408 170 W. Tasman Dr. 409 San Jose, CA 95134-1706 410 US 412 EMail: kcrozier@cisco.com 414 Rob Enns 415 Juniper Networks 416 1194 North Mathilda Ave 417 Sunnyvale, CA 94089 418 US 420 EMail: rpe@juniper.net 422 Intellectual Property Statement 424 The IETF takes no position regarding the validity or scope of any 425 intellectual property or other rights that might be claimed to 426 pertain to the implementation or use of the technology described in 427 this document or the extent to which any license under such rights 428 might or might not be available; neither does it represent that it 429 has made any effort to identify any such rights. Information on the 430 IETF's procedures with respect to rights in standards-track and 431 standards-related documentation can be found in BCP-11. Copies of 432 claims of rights made available for publication and any assurances of 433 licenses to be made available, or the result of an attempt made to 434 obtain a general license or permission for the use of such 435 proprietary rights by implementors or users of this specification can 436 be obtained from the IETF Secretariat. 438 The IETF invites any interested party to bring to its attention any 439 copyrights, patents or patent applications, or other proprietary 440 rights which may cover technology that may be required to practice 441 this standard. Please address the information to the IETF Executive 442 Director. 444 Full Copyright Statement 446 Copyright (C) The Internet Society (2003). All Rights Reserved. 448 This document and translations of it may be copied and furnished to 449 others, and derivative works that comment on or otherwise explain it 450 or assist in its implementation may be prepared, copied, published 451 and distributed, in whole or in part, without restriction of any 452 kind, provided that the above copyright notice and this paragraph are 453 included on all such copies and derivative works. However, this 454 document itself may not be modified in any way, such as by removing 455 the copyright notice or references to the Internet Society or other 456 Internet organizations, except as needed for the purpose of 457 developing Internet standards in which case the procedures for 458 copyrights defined in the Internet Standards process must be 459 followed, or as required to translate it into languages other than 460 English. 462 The limited permissions granted above are perpetual and will not be 463 revoked by the Internet Society or its successors or assignees. 465 This document and the information contained herein is provided on an 466 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 467 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 468 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 469 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 470 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Acknowledgement 474 Funding for the RFC Editor function is currently provided by the 475 Internet Society.