idnits 2.17.1 draft-ietf-netconf-beep-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 378. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 394), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 6) being 74 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (October 18, 2004) is 7101 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: '8' is defined on line 319, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 323, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-03 ** Obsolete normative reference: RFC 2222 (ref. '5') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '6') (Obsoleted by RFC 4346) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Lear 2 Internet-Draft K. Crozier 3 Expires: April 18, 2005 Cisco Systems 4 October 18, 2004 6 Using the NETCONF Protocol over Blocks Extensible Exchange Protocol 7 (BEEP) 8 draft-ietf-netconf-beep-02 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3668. 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 28 http://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 April 18, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document specifies an application protocol mapping for the 42 NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1 Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4 49 2.1 NETCONF Session Establishment . . . . . . . . . . . . . . 4 50 2.2 Capabilities Exchange . . . . . . . . . . . . . . . . . . 4 51 2.3 NETCONF Session Usage . . . . . . . . . . . . . . . . . . 4 52 2.4 NETCONF Session Teardown . . . . . . . . . . . . . . . . . 5 53 2.5 BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 5 54 2.5.1 BEEP Profile . . . . . . . . . . . . . . . . . . . . 5 55 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 57 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 60 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 62 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . 14 65 1. Introduction 67 The NETCONF protocol [1] defines a simple mechanism through which a 68 network device can be managed. NETCONF is designed to be usable over 69 a variety of application protocols. This document specifies an 70 application protocol mapping for NETCONF over the Blocks Extensible 71 Exchange Protocol (BEEP) [2] . 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [4]. 77 1.1 Why BEEP? 79 Use of BEEP is natural as an application protocol for transport of 80 XML. As a peer to peer protocol, BEEP provides an easy way to 81 implement NETCONF, no matter which side of the connection was the 82 initiator. This "bidirectionality" allows for either side to play 83 the role of the manager with no protocol changes. Either side can 84 open a channel. Either side could initiate an RPC. This is 85 particularly important to support operational models that involve 86 small devices connecting to a manager, and those devices that must 87 reverse the management connection in the face of firewalls and NATs. 89 The SASL profile used by BEEP allows for a simple and direct mapping 90 to the existing security model for CLI, while TLS provides a strong 91 well tested encryption mechanism with either server or server and 92 client-side authentication. 94 2. BEEP Transport Mapping 96 All NETCONF over BEEP implementations MUST implement the profile and 97 functional mapping between NETCONF and BEEP as described below. 99 2.1 NETCONF Session Establishment 101 Managers may be either BEEP listeners or initiators. Similarly, 102 agents may be either listeners or initiators. Thus the initial 103 exchange takes place without regard to whether a manager or the agent 104 is the initiator. After the transport connection is established, as 105 greetings are exchanged, they should each announce their support for 106 TLS [6] and optionally SASL [5] (see below), as well as for the 107 SYSLOG profile [7]. Once greetings are exchanged, if TLS is to be 108 used and available by both parties, the listener STARTs a channel 109 with the TLS profile. 111 Once TLS has been started, a new greeting is sent by both initiator 112 and listener, as required by the BEEP RFC. 114 At this point, if SASL is desired, the initiator starts BEEP channel 115 1 to perform a SASL exchange to authenticate itself. When SASL is 116 completed, the channel MUST be closed. 118 Once authentication has occurred, there is no need to distinguish 119 between initiator and listener. We now distinguish between manager 120 and agent. 122 2.2 Capabilities Exchange 124 The manager now establishes an NETCONF a new channel. As initiators 125 assign odd channels and listeners assign even channels, this next 126 channel is BEEP channel 1 or 2, depending on whether the manager is 127 the initiator or the listener. 129 Certain NETCONF capabilities may require additional BEEP channels. 130 When such capabilities are defined, a BEEP mapping must be defined as 131 well. 133 At this point, the NETCONF session is established, and capabilities 134 have been exchanged. 136 2.3 NETCONF Session Usage 138 Nearly all NETCONF operations are executed through the tag. To 139 issue an RPC, the manager transmits on the operational channel a BEEP 140 MSG containing the RPC and its arguments. In accordance with the 141 BEEP standard, RPC requests may be split across multiple BEEP frames. 143 Once received and processed, the agent responds with BEEP RPYs on the 144 same channel with the response to the RPC. In accordance with the 145 BEEP standard, responses may be split across multiple BEEP frames. 147 2.4 NETCONF Session Teardown 149 Upon receipt of from the manager, once the agent has 150 completed all RPCs, it will close BEEP channel 0. When an agent 151 needs to initiate a close it will do so by closing BEEP channel 0. 152 Although not required to do so, the agent should allow for a 153 reasonable period for a manager to release an existing lock prior to 154 initiating a close. Once the agent has closed channel 0, all locks 155 are released, and each side follows tear down procedures as specified 156 in [3]. Having received a BEEP close or having sent , 157 a manager MUST NOT send further requests. If there are additional 158 activities due to expanded capabilities, these MUST cease in an 159 orderly manner, and should be properly described in the capability 160 mapping. 162 2.5 BEEP Profile for NETCONF 164 There are three commands in the BEEP profile. and . 166 2.5.1 BEEP Profile 168 176 189 190 192 194 %BEEP; 196 207 219 220 222 --> 224 228 229 232 236 237 241 243 3. Security Considerations 245 Configuration information is by its very nature sensitive. Its 246 transmission in the clear and without integrity checking leaves 247 devices open to classic so-called "person in the middle" attacks. 248 Configuration information often times contains passwords, user names, 249 service descriptions, and topological information, all of which are 250 sensitive. A NETCONF application protocol, therefore, must minimally 251 support options for both confidentiality and authentication. 253 BEEP makes use of both transport layer security and SASL. We require 254 that TLS be used in BEEP as described by the BEEP standard. 255 Client-side certificates are strongly desirable, but an SASL 256 authentication is the bare minimum. SASL allows for the use of 257 protocols such as RADIUS [10], so that authentication can occur off 258 the box. 260 SASL authentication will occur on the first channel creation, and 261 prior to issuance of any protocol operations. No further 262 authentication may occur during the same session. This avoids a 263 situation where rights are different between different channels. If 264 an implementation wishes to support multiple accesses by different 265 individuals with different rights, then multiple sessions are 266 required. 268 Different environments may well allow different rights prior to and 269 then after authentication. An authorization model is not specified 270 in this document. When an operation is not properly authorized then 271 a simple "permission denied" is sufficient. Note that authorization 272 information may be exchanged in the form of configuration 273 information, which is all the more reason to ensure the security of 274 the connection. 276 4. IANA Considerations 278 The IANA will assign a TCP port for NETCONF. 280 5. Acknowledgments 282 This work is the product of the NETCONF IETF working group, and many 283 people have contributed to the NETCONF discussion. Most notably, Rob 284 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 285 Margaret Wasserman all contributed in some fashion to this work, 286 which was originally to be found in the NETCONF base protocol 287 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 288 Schoenwaelder, and Eamon O'Tuathail for their very constructive 289 participation. 291 6. References 293 6.1 Normative References 295 [1] Enns, R., "NETCONF Configuration Protocol", 296 draft-ietf-netconf-prot-03 (work in progress), June 2004. 298 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 299 3080, March 2001. 301 [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 302 2001. 304 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 305 Levels", BCP 14, RFC 2119, March 1997. 307 [5] Myers, J., "Simple Authentication and Security Layer (SASL)", 308 RFC 2222, October 1997. 310 [6] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 311 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 312 1999. 314 [7] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 315 November 2001. 317 6.2 Informative References 319 [8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 320 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 321 REC REC-xml-20001006, October 2000. 323 [9] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 324 Use of Extensible Markup Language (XML) within IETF Protocols", 325 BCP 70, RFC 3470, January 2003. 327 [10] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 328 Authentication Dial In User Service (RADIUS)", RFC 2865, June 329 2000. 331 Authors' Addresses 333 Eliot Lear 334 Cisco Systems 335 Glatt-com 336 Glattzentrum, Zurich 8301 337 CH 339 EMail: lear@cisco.com 341 Ken Crozier 342 Cisco Systems 343 170 W. Tasman Dr. 344 San Jose, CA 95134-1706 345 US 347 EMail: kcrozier@cisco.com 349 Appendix A. Change Log 351 02: added comments about locking 353 01: Removed management channel, rpc-status, rpc-abort, and associated 354 profile changes. 356 Intellectual Property Statement 358 The IETF takes no position regarding the validity or scope of any 359 Intellectual Property Rights or other rights that might be claimed to 360 pertain to the implementation or use of the technology described in 361 this document or the extent to which any license under such rights 362 might or might not be available; nor does it represent that it has 363 made any independent effort to identify any such rights. Information 364 on the procedures with respect to rights in RFC documents can be 365 found in BCP 78 and BCP 79. 367 Copies of IPR disclosures made to the IETF Secretariat and any 368 assurances of licenses to be made available, or the result of an 369 attempt made to obtain a general license or permission for the use of 370 such proprietary rights by implementers or users of this 371 specification can be obtained from the IETF on-line IPR repository at 372 http://www.ietf.org/ipr. 374 The IETF invites any interested party to bring to its attention any 375 copyrights, patents or patent applications, or other proprietary 376 rights that may cover technology that may be required to implement 377 this standard. Please address the information to the IETF at 378 ietf-ipr@ietf.org. 380 Disclaimer of Validity 382 This document and the information contained herein are provided on an 383 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 384 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 385 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 386 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 387 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 388 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 390 Copyright Statement 392 Copyright (C) The Internet Society (2004). This document is subject 393 to the rights, licenses and restrictions contained in BCP 78, and 394 except as set forth therein, the authors retain all their rights. 396 Acknowledgment 398 Funding for the RFC Editor function is currently provided by the 399 Internet Society.