idnits 2.17.1 draft-ietf-netconf-beep-01.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 37 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (June 7, 2004) is 7255 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 310, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 314, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-01 ** 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: 4 errors (**), 0 flaws (~~), 6 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: December 6, 2004 Cisco Systems 5 June 7, 2004 7 BEEP Application Protocol Mapping for NETCONF 8 draft-ietf-netconf-beep-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 6, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document specifies an application protocol mapping for the 39 NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1 Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . 4 46 2.1 NETCONF Session Initiation . . . . . . . . . . . . . . . . . 4 47 2.2 NETCONF RPC Execution . . . . . . . . . . . . . . . . . . . 4 48 2.3 NETCONF Session Teardown . . . . . . . . . . . . . . . . . . 5 49 2.4 BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . . 5 50 2.4.1 Operations Channel Profile . . . . . . . . . . . . . . . . . 5 51 2.4.2 Notification Channel Profile . . . . . . . . . . . . . . . . 7 52 3. Security Considerations . . . . . . . . . . . . . . . . . . 8 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 54 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 55 Normative References . . . . . . . . . . . . . . . . . . . . 11 56 Informative References . . . . . . . . . . . . . . . . . . . 12 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 58 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 Intellectual Property and Copyright Statements . . . . . . . 14 61 1. Introduction 63 The NETCONF protocol [1] defines a simple mechanism through which a 64 network device can be managed. NETCONF is designed to be usable over 65 a variety of application protocols. This document specifies an 66 application protocol mapping for NETCONF over the Blocks Extensible 67 Exchange Protocol (BEEP) [2] . 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119 [3]. 73 1.1 Why BEEP? 75 Use of BEEP is natural as an application protocol for transport of 76 XML. As a peer to peer protocol, BEEP provides an easy way to 77 implement NETCONF, no matter which side of the connection was the 78 initiator. This "bidirectionality" allows for either side to play 79 the role of the manager with no protocol changes. Either side can 80 open a channel. Either side could initiate an RPC. This is 81 particularly important to support operational models that involve 82 small devices connecting to a manager, and those devices that must 83 reverse the management connection in the face of firewalls and NATs. 85 The SASL profile used by BEEP allows for a simple and direct mapping 86 to the existing security model for CLI, while TLS provides a strong 87 well tested encryption mechanism with either server or server and 88 client-side authentication. 90 2. BEEP Transport Mapping 92 All NETCONF over BEEP implementations MUST implement the profile and 93 functional mapping between NETCONF and BEEP as described below. 95 2.1 NETCONF Session Initiation 97 Managers may be either BEEP listeners or initiators. Similarly, 98 agents may be either listeners or initiators. Thus the initial 99 exchange takes place without regard to whether a manager or the agent 100 is the initiator. After the transport connection is established, as 101 greetings are exchanged, they should each announce their support for 102 TLS [5] and optionally SASL [4] (see below), as well as for the 103 SYSLOG profile [6]. Once greetings are exchanged, if TLS is to be 104 used and available by both parties, the listener STARTs a channel 105 with the TLS profile. 107 Once TLS has been started, a new greeting is sent by both initiator 108 and listener, as required by the BEEP RFC. 110 At this point, if SASL is desired, the initiator starts BEEP channel 111 1 to perform a SASL exchange to authenticate itself. When SASL is 112 completed, the channel MUST be closed. 114 Once authentication has occurred, there is no need to distinguish 115 between initiator and listener. We now distinguish between manager 116 and agent. 118 The manager now establishes an NETCONF a new 119 &dquot;operational&dquot; channel for capabilitiesexchange and 120 requests and responses. As initiators assign odd channels and 121 listeners assign even channels, this next channel is BEEP channel 1 122 or 2, depending on whether the manager is the initiator or the 123 listener. 125 Certain NETCONF capabilities may require additional BEEP channels. 126 When such capabilities are defined, a BEEP mapping must be defined as 127 well. 129 At this point, the NETCONF session is established. 131 2.2 NETCONF RPC Execution 133 To issue an RPC, the manager transmits on the operational channel a 134 BEEP MSG containing the RPC and its arguments. In accordance with 135 the BEEP standard, RPC requests may be split across multiple BEEP 136 frames. 138 Once received and processed, the agent responds with BEEP RPYs on the 139 same channel with the response to the RPC. In accordance with the 140 BEEP standard, responses may be split across multiple BEEP frames. 142 2.3 NETCONF Session Teardown 144 Either side may initiate the termination of an NETCONF session. In 145 This is done by issuing a BEEP close on channel 0 after the current 146 RPC has completed. Having sent or received a BEEP close, a manager 147 MUST NOT send further requests, and an agent MUST NOT send additional 148 responses. If there are additional activities due to expanded 149 capabilities, these MUST cease in an orderly manner, and should be 150 properly described in the capability mapping. 152 2.4 BEEP Profile for NETCONF 154 The operations channel will have two commands, and . 156 2.4.1 Operations Channel Profile 158 166 179 181 183 185 %BEEP; 187 198 211 212 214 --> 216 220 221 224 228 229 233 235 2.4.2 Notification Channel Profile 237 The NETCONF notification channel profile is defined in RFC 3195 [6]. 239 3. Security Considerations 241 Configuration information is by its very nature sensitive. Its 242 transmission in the clear and without integrity checking leaves 243 devices open to classic so-called "person in the middle" attacks. 244 Configuration information often times contains passwords, user names, 245 service descriptions, and topological information, all of which are 246 sensitive. A NETCONF application protocol, therefore, must minimally 247 support options for both confidentiality and authentication. 249 BEEP makes use of both transport layer security and SASL. We require 250 that TLS be used in BEEP as described by the BEEP standard. 251 Client-side certificates are strongly desirable, but an SASL 252 authentication is the bare minimum. SASL allows for the use of 253 protocols such as RADIUS [9], so that authentication can occur off 254 the box. 256 SASL authentication will occur on the first channel creation, and 257 prior to issuance of any protocol operations. No further 258 authentication may occur during the same session. This avoids a 259 situation where rights are different between different channels. If 260 an implementation wishes to support multiple accesses by different 261 individuals with different rights, then multiple sessions are 262 required. 264 Different environments may well allow different rights prior to and 265 then after authentication. Thus, an authorization model is not 266 specified in this document. When an operation is not properly 267 authorized then a simple "permission denied" is sufficient. Note that 268 authorization information may be exchanged in the form of 269 configuration information, which is all the more reason to ensure the 270 security of the connection. 272 4. IANA Considerations 274 The IANA will assign a TCP port for NETCONF. 276 5. Acknowledgments 278 This work is the product of the NETCONF IETF working group, and many 279 people have contributed to the NETCONF discussion. Most notably, Rob 280 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 281 Margaret Wasserman all contributed in some fashion to this work, 282 which was originally to be found in the NETCONF base protocol 283 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 284 Schoenwaelder, and Eamon O'Tuathail for their very constructive 285 participation. 287 Normative References 289 [1] Enns, R., "NETCONF Configuration Protocol", 290 draft-ietf-netconf-prot-01 (work in progress), October 2003. 292 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 293 3080, March 2001. 295 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 296 Levels", BCP 14, RFC 2119, March 1997. 298 [4] Myers, J., "Simple Authentication and Security Layer (SASL)", 299 RFC 2222, October 1997. 301 [5] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 302 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 303 1999. 305 [6] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 306 November 2001. 308 Informative References 310 [7] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 311 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 312 REC-xml-20001006, October 2000. 314 [8] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 315 Use of Extensible Markup Language (XML) within IETF Protocols", 316 BCP 70, RFC 3470, January 2003. 318 [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 319 Authentication Dial In User Service (RADIUS)", RFC 2865, June 320 2000. 322 Authors' Addresses 324 Eliot Lear 325 Cisco Systems 326 170 W. Tasman Dr. 327 San Jose, CA 95134-1706 328 US 330 EMail: lear@cisco.com 332 Ken Crozier 333 Cisco Systems 334 170 W. Tasman Dr. 335 San Jose, CA 95134-1706 336 US 338 EMail: kcrozier@cisco.com 340 Appendix A. Change Log 342 Removed management channel, rpc-status, rpc-abort, and associated 343 profile changes. 345 Intellectual Property Statement 347 The IETF takes no position regarding the validity or scope of any 348 intellectual property or other rights that might be claimed to 349 pertain to the implementation or use of the technology described in 350 this document or the extent to which any license under such rights 351 might or might not be available; neither does it represent that it 352 has made any effort to identify any such rights. Information on the 353 IETF's procedures with respect to rights in standards-track and 354 standards-related documentation can be found in BCP-11. Copies of 355 claims of rights made available for publication and any assurances of 356 licenses to be made available, or the result of an attempt made to 357 obtain a general license or permission for the use of such 358 proprietary rights by implementors or users of this specification can 359 be obtained from the IETF Secretariat. 361 The IETF invites any interested party to bring to its attention any 362 copyrights, patents or patent applications, or other proprietary 363 rights which may cover technology that may be required to practice 364 this standard. Please address the information to the IETF Executive 365 Director. 367 Full Copyright Statement 369 Copyright (C) The Internet Society (2004). All Rights Reserved. 371 This document and translations of it may be copied and furnished to 372 others, and derivative works that comment on or otherwise explain it 373 or assist in its implementation may be prepared, copied, published 374 and distributed, in whole or in part, without restriction of any 375 kind, provided that the above copyright notice and this paragraph are 376 included on all such copies and derivative works. However, this 377 document itself may not be modified in any way, such as by removing 378 the copyright notice or references to the Internet Society or other 379 Internet organizations, except as needed for the purpose of 380 developing Internet standards in which case the procedures for 381 copyrights defined in the Internet Standards process must be 382 followed, or as required to translate it into languages other than 383 English. 385 The limited permissions granted above are perpetual and will not be 386 revoked by the Internet Society or its successors or assignees. 388 This document and the information contained herein is provided on an 389 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 390 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 391 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 392 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 393 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Acknowledgment 397 Funding for the RFC Editor function is currently provided by the 398 Internet Society.