idnits 2.17.1 draft-ietf-netconf-beep-04.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 3978, Section 5.1.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 376. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- ** There are 45 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 (March 19, 2005) is 6978 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 312, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 316, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-04 ** Obsolete normative reference: RFC 2222 (ref. '3') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '4') (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: September 17, 2005 Cisco Systems 4 March 19, 2005 6 Using the NETCONF Protocol over Blocks Extensible Exchange Protocol 7 (BEEP) 8 draft-ietf-netconf-beep-04 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 17, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document specifies an application protocol mapping for the 44 NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1 Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4 51 2.1 NETCONF Session Establishment . . . . . . . . . . . . . . 4 52 2.2 Starting a Channel for NETCONF . . . . . . . . . . . . . . 4 53 2.3 NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6 54 2.4 NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6 55 2.5 BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 6 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 58 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 59 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 61 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 63 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 Intellectual Property and Copyright Statements . . . . . . . . 14 66 1. Introduction 68 The NETCONF protocol [1] defines a simple mechanism through which a 69 network device can be managed. NETCONF is designed to be usable over 70 a variety of application protocols. This document specifies an 71 application protocol mapping for NETCONF over the Blocks Extensible 72 Exchange Protocol (BEEP) [6] . 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 76 document are to be interpreted as described in RFC 2119 [2]. 78 1.1 Why BEEP? 80 Use of BEEP is natural as an application protocol for transport of 81 XML. As a peer to peer protocol, BEEP provides an easy way to 82 implement NETCONF, no matter which side of the connection was the 83 initiator. This "bidirectionality" allows for either manager or 84 agent to initiate a connection. This is particularly important to 85 support large number of intermittantly connected devices, as well as 86 those devices that must reverse the management connection in the face 87 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 [4] and optionally SASL [3]. Once greetings are exchanged, if 107 TLS is to be used and available by both parties, the listener STARTs 108 a channel with the TLS profile. 110 Once TLS has been started, a new greeting is sent by both initiator 111 and listener, as required by the BEEP RFC. 113 At this point, if SASL is desired, the initiator starts a BEEP 114 channel to perform a SASL exchange to authenticate itself. Upon 115 completion of authentication the channel is closed. That is, the 116 channel is exclusively used to authenticate. 118 Examples of both TLS and SASL profiles can be found in [6]. 120 It is anticipated that the SASL PLAIN mechanism will be heavily used 121 in conjunction with TLS.[5] In such cases, in accordance with RFC 122 2595 the PLAIN mechanism MUST NOT be advertised in the first BEEP 123 , but only in the one following a successful TLS 124 negotiation. This applies only if TLS and SASL PLAIN mechanisms are 125 both to be used. The SASL PLAIN mechanism SHOULD NOT be used 126 unencrypted channels to avoid risk of eavesdropping. 128 Once authentication has occurred, there is no need to distinguish 129 between initiator and listener. We now distinguish between manager 130 and agent, and it is assumed that each knows its role in the 131 conversation. 133 2.2 Starting a Channel for NETCONF 135 The manager now establishes new channel and specifies the single 136 NETCONF profile. For example: 138 (M = Manager ; A = Agent ) 140 M: MSG 0 1 . 10 48 101 141 M: Content-type: application/beep+xml 142 M: 143 M: 144 M: 145 M: END 146 A: RPY 0 1 . 38 87 147 A: Content-Type: application/beep+xml 148 A: 149 A: 150 A: END 152 At this point we are ready to proceed on BEEP channel 1 with NETCONF 153 operations. 155 Next the manager and the agent exchange NETCONF elements on 156 the new channel so that each side learns the other's capabilities. 157 This occurs through a MSG. Each side will then respond with 158 positively. The following example is adapted from [1] Section 8.1: 160 A: MSG 1 0 . 0 436 161 A: Content-type: application/beep+xml 162 A: 163 A: 164 A: 165 A: 166 A: urn:ietf:params:xml:ns:netconf:base:1.0 167 A: 168 A: 169 A: urn:ietf:params:xml:ns:netconf:base:1.0#startup 170 A: 171 A: 172 A: http:/example.net/router/2.3/core#myfeature 173 A: 174 A: 175 A: 4 176 A: 177 A: END 179 M: RPY 1 0 . 0 0 180 M: END 182 Certain NETCONF capabilities may require additional BEEP channels. 183 When such capabilities are defined, a BEEP mapping must be defined as 184 well. 186 At this point, the NETCONF session is established, and capabilities 187 have been exchanged. 189 2.3 NETCONF Session Usage 191 Nearly all NETCONF operations are executed through the tag. To 192 issue an RPC, the manager transmits on the operational channel a BEEP 193 MSG containing the RPC and its arguments. In accordance with the 194 BEEP standard, RPC requests may be split across multiple BEEP frames. 196 Once received and processed, the agent responds with BEEP RPYs on the 197 same channel with the response to the RPC. In accordance with the 198 BEEP standard, responses may be split across multiple BEEP frames. 200 2.4 NETCONF Session Teardown 202 Upon receipt of from the manager, once the agent has 203 completed all RPCs, it will close BEEP channel 0. When an agent 204 needs to initiate a close it will do so by closing BEEP channel 0. 205 Although not required to do so, the agent should allow for a 206 reasonable period for a manager to release an existing lock prior to 207 initiating a close. Once the agent has closed channel 0, all locks 208 are released, and each side follows tear down procedures as specified 209 in [7]. Having received a BEEP close or having sent , 210 a manager MUST NOT send further requests. If there are additional 211 activities due to expanded capabilities, these MUST cease in an 212 orderly manner, and should be properly described in the capability 213 mapping. 215 2.5 BEEP Profile for NETCONF 217 Profile Identification: http://iana.org/beep/netconf 219 messages exchanged during Channel Creation: not applicable 221 Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply" 223 Messages in positive replies: "rpc-reply" 225 Messages in negative replies: "rpc-reply" 227 Messages in one-to-many exchanges: none 229 Message syntax: [1] 231 message semantics: [1] 232 Contact Information: c.f., the "Author's Address" section of this 233 memo. 235 3. Security Considerations 237 Configuration information is by its very nature sensitive. Its 238 transmission in the clear and without integrity checking leaves 239 devices open to classic so-called "person in the middle" attacks. 240 Configuration information often times contains passwords, user names, 241 service descriptions, and topological information, all of which are 242 sensitive. A NETCONF application protocol, therefore, must minimally 243 support options for both confidentiality and authentication. 245 BEEP makes use of both transport layer security and SASL. We require 246 that TLS be used in BEEP as described by the BEEP standard. 247 Client-side certificates are strongly desirable, but an SASL 248 authentication is the bare minimum. SASL allows for the use of 249 protocols such as RADIUS [10], so that authentication can occur off 250 the box. 252 In keeping with the BEEP standard, SASL authentication will occur on 253 the first channel creation, and prior to issuance of any protocol 254 operations. No further authentication may occur during the same 255 session. This avoids a situation where rights are different between 256 different channels. If an implementation wishes to support multiple 257 accesses by different individuals with different rights, then 258 multiple sessions are required. 260 Different environments may well allow different rights prior to and 261 then after authentication. An authorization model is not specified 262 in this document. When an operation is not properly authorized then 263 a simple rpc-error containing "permission denied" is sufficient. 264 Note that authorization information may be exchanged in the form of 265 configuration information, which is all the more reason to ensure the 266 security of the connection. 268 4. IANA Considerations 270 The IANA will assign a TCP port for NETCONF, and register the BEEP 271 profile contained here-in. 273 5. Acknowledgments 275 This work is the product of the NETCONF IETF working group, and many 276 people have contributed to the NETCONF discussion. Most notably, Rob 277 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 278 Margaret Wasserman all contributed in some fashion to this work, 279 which was originally to be found in the NETCONF base protocol 280 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 281 Schoenwaelder, and Eamon O'Tuathail for their very constructive 282 participation. 284 6. References 286 6.1 Normative References 288 [1] Enns, R., "NETCONF Configuration Protocol", 289 draft-ietf-netconf-prot-04 (work in progress), October 2004. 291 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 292 Levels", BCP 14, RFC 2119, March 1997. 294 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", 295 RFC 2222, October 1997. 297 [4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 298 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 299 1999. 301 [5] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 302 1999. 304 [6] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 305 3080, March 2001. 307 [7] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 308 2001. 310 6.2 Informative References 312 [8] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 313 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 314 REC REC-xml-20001006, October 2000. 316 [9] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the 317 Use of Extensible Markup Language (XML) within IETF Protocols", 318 BCP 70, RFC 3470, January 2003. 320 [10] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 321 Authentication Dial In User Service (RADIUS)", RFC 2865, June 322 2000. 324 Authors' Addresses 326 Eliot Lear 327 Cisco Systems 328 Glatt-com 329 Glattzentrum, Zurich 8301 330 CH 332 EMail: lear@cisco.com 334 Ken Crozier 335 Cisco Systems 336 170 W. Tasman Dr. 337 San Jose, CA 95134-1706 338 US 340 EMail: kcrozier@cisco.com 342 Appendix A. Change Log 344 04: complete revamp of the profile. Added as well as 345 examples. 347 03: minor gnits relating to 349 02: added comments about locking 351 01: Removed management channel, rpc-status, rpc-abort, and associated 352 profile changes. 354 Intellectual Property Statement 356 The IETF takes no position regarding the validity or scope of any 357 Intellectual Property Rights or other rights that might be claimed to 358 pertain to the implementation or use of the technology described in 359 this document or the extent to which any license under such rights 360 might or might not be available; nor does it represent that it has 361 made any independent effort to identify any such rights. Information 362 on the procedures with respect to rights in RFC documents can be 363 found in BCP 78 and BCP 79. 365 Copies of IPR disclosures made to the IETF Secretariat and any 366 assurances of licenses to be made available, or the result of an 367 attempt made to obtain a general license or permission for the use of 368 such proprietary rights by implementers or users of this 369 specification can be obtained from the IETF on-line IPR repository at 370 http://www.ietf.org/ipr. 372 The IETF invites any interested party to bring to its attention any 373 copyrights, patents or patent applications, or other proprietary 374 rights that may cover technology that may be required to implement 375 this standard. Please address the information to the IETF at 376 ietf-ipr@ietf.org. 378 Disclaimer of Validity 380 This document and the information contained herein are provided on an 381 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 382 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 383 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 384 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 385 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 386 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 388 Copyright Statement 390 Copyright (C) The Internet Society (2005). This document is subject 391 to the rights, licenses and restrictions contained in BCP 78, and 392 except as set forth therein, the authors retain all their rights. 394 Acknowledgment 396 Funding for the RFC Editor function is currently provided by the 397 Internet Society.