idnits 2.17.1 draft-ietf-netconf-beep-03.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 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 382. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 398), 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 == 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 (November 15, 2004) is 7099 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 320, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 324, 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 (~~), 6 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: May 16, 2005 Cisco Systems 4 November 15, 2004 6 Using the NETCONF Protocol over Blocks Extensible Exchange Protocol 7 (BEEP) 8 draft-ietf-netconf-beep-03 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 May 16, 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 146 split across multiple BEEP frames. 148 2.4 NETCONF Session Teardown 150 Upon receipt of from the manager, once the agent has 151 completed all RPCs, it will close BEEP channel 0. When an agent 152 needs to initiate a close it will do so by closing BEEP channel 0. 153 Although not required to do so, the agent should allow for a 154 reasonable period for a manager to release an existing lock prior to 155 initiating a close. Once the agent has closed channel 0, all locks 156 are released, and each side follows tear down procedures as specified 157 in [3]. Having received a BEEP close or having sent , 158 a manager MUST NOT send further requests. If there are additional 159 activities due to expanded capabilities, these MUST cease in an 160 orderly manner, and should be properly described in the capability 161 mapping. 163 2.5 BEEP Profile for NETCONF 165 There are two commands in the BEEP profile. and . 167 2.5.1 BEEP Profile 169 177 190 191 193 195 %BEEP; 197 208 220 221 223 --> 225 229 230 233 237 238 242 244 3. Security Considerations 246 Configuration information is by its very nature sensitive. Its 247 transmission in the clear and without integrity checking leaves 248 devices open to classic so-called "person in the middle" attacks. 249 Configuration information often times contains passwords, user names, 250 service descriptions, and topological information, all of which are 251 sensitive. A NETCONF application protocol, therefore, must minimally 252 support options for both confidentiality and authentication. 254 BEEP makes use of both transport layer security and SASL. We require 255 that TLS be used in BEEP as described by the BEEP standard. 256 Client-side certificates are strongly desirable, but an SASL 257 authentication is the bare minimum. SASL allows for the use of 258 protocols such as RADIUS [10], so that authentication can occur off 259 the box. 261 SASL authentication will occur on the first channel creation, and 262 prior to issuance of any protocol operations. No further 263 authentication may occur during the same session. This avoids a 264 situation where rights are different between different channels. If 265 an implementation wishes to support multiple accesses by different 266 individuals with different rights, then multiple sessions are 267 required. 269 Different environments may well allow different rights prior to and 270 then after authentication. An authorization model is not specified 271 in this document. When an operation is not properly authorized then 272 a simple "permission denied" is sufficient. Note that authorization 273 information may be exchanged in the form of configuration 274 information, which is all the more reason to ensure the security of 275 the connection. 277 4. IANA Considerations 279 The IANA will assign a TCP port for NETCONF. 281 5. Acknowledgments 283 This work is the product of the NETCONF IETF working group, and many 284 people have contributed to the NETCONF discussion. Most notably, Rob 285 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 286 Margaret Wasserman all contributed in some fashion to this work, 287 which was originally to be found in the NETCONF base protocol 288 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 289 Schoenwaelder, and Eamon O'Tuathail for their very constructive 290 participation. 292 6. References 294 6.1 Normative References 296 [1] Enns, R., "NETCONF Configuration Protocol", 297 draft-ietf-netconf-prot-03 (work in progress), June 2004. 299 [2] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 300 3080, March 2001. 302 [3] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 303 2001. 305 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 306 Levels", BCP 14, RFC 2119, March 1997. 308 [5] Myers, J., "Simple Authentication and Security Layer (SASL)", 309 RFC 2222, October 1997. 311 [6] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 312 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 313 1999. 315 [7] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, 316 November 2001. 318 6.2 Informative References 320 [8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 321 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 322 REC REC-xml-20001006, October 2000. 324 [9] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 325 Use of Extensible Markup Language (XML) within IETF Protocols", 326 BCP 70, RFC 3470, January 2003. 328 [10] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 329 Authentication Dial In User Service (RADIUS)", RFC 2865, June 330 2000. 332 Authors' Addresses 334 Eliot Lear 335 Cisco Systems 336 Glatt-com 337 Glattzentr 338 um, Zurich 8301 339 CH 341 EMail: lear@cisco.com 343 Ken Crozier 344 Cisco Systems 345 170 W. Tasman Dr. 346 San Jose, CA 95134-1706 347 US 349 EMail: kcrozier@cisco.com 351 Appendix A. Change Log 353 03, 04: minor gnits relating to 355 02: added comments about locking 357 01: Removed management channel, rpc-status, rpc-abort, and associated 358 profile changes. 360 Intellectual Property Statement 362 The IETF takes no position regarding the validity or scope of any 363 Intellectual Property Rights or other rights that might be claimed to 364 pertain to the implementation or use of the technology described in 365 this document or the extent to which any license under such rights 366 might or might not be available; nor does it represent that it has 367 made any independent effort to identify any such rights. Information 368 on the procedures with respect to rights in RFC documents can be 369 found in BCP 78 and BCP 79. 371 Copies of IPR disclosures made to the IETF Secretariat and any 372 assurances of licenses to be made available, or the result of an 373 attempt made to obtain a general license or permission for the use of 374 such proprietary rights by implementers or users of this 375 specification can be obtained from the IETF on-line IPR repository at 376 http://www.ietf.org/ipr. 378 The IETF invites any interested party to bring to its attention any 379 copyrights, patents or patent applications, or other proprietary 380 rights that may cover technology that may be required to implement 381 this standard. Please address the information to the IETF at 382 ietf-ipr@ietf.org. 384 Disclaimer of Validity 386 This document and the information contained herein are provided on an 387 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 388 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 389 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 390 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 391 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 392 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 394 Copyright Statement 396 Copyright (C) The Internet Society (2004). This document is subject 397 to the rights, licenses and restrictions contained in BCP 78, and 398 except as set forth therein, the authors retain all their rights. 400 Acknowledgment 402 Funding for the RFC Editor function is currently provided by the 403 Internet Society.