idnits 2.17.1 draft-ietf-netconf-beep-09.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 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 401. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 407. ** 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. 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 : ---------------------------------------------------------------------------- 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 (March 3, 2006) is 6628 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: '9' is defined on line 344, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-08 ** Obsolete normative reference: RFC 2222 (ref. '3') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. '4') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2831 (ref. '6') (Obsoleted by RFC 6331) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft Cisco Systems 4 Expires: September 4, 2006 K. Crozier 5 March 3, 2006 7 Using the NETCONF Protocol over Blocks Extensible Exchange Protocol 8 (BEEP) 9 draft-ietf-netconf-beep-09 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 4, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies an application protocol mapping for the 43 NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Why BEEP? . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. BEEP Transport Mapping . . . . . . . . . . . . . . . . . . . . 4 50 2.1. NETCONF Session Establishment . . . . . . . . . . . . . . 4 51 2.2. Starting a Channel for NETCONF . . . . . . . . . . . . . . 5 52 2.3. NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6 53 2.4. NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6 54 2.5. BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 7 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 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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) [7] . 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 [2]. 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 manager or 83 agent to initiate a connection. This is particularly important to 84 support large number of intermittently connected devices, as well as 85 those devices that must reverse the management connection in the face 86 of firewalls and network address translators (NATs). 88 BEEP makes use of the Simple Authentication and Security Layer (SASL) 89 [3]. The SASL profile used by BEEP allows for a simple and direct 90 mapping to the existing security model for CLI, while transport layer 91 security (TLS) [4] provides a strong well tested encryption mechanism 92 with either server or server and 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 For purposes of this document a manager is a NETCONF client, and an 100 agent is a NETCONF server. Use of client/server language in BEEP is 101 avoided because of the common notion that in networking clients 102 connect to servers. 104 2.1. NETCONF Session Establishment 106 Managers may be either BEEP listeners or initiators. Similarly, 107 agents may be either listeners or initiators. Thus the initial 108 exchange takes place without regard to whether a manager or the agent 109 is the initiator. After the transport connection is established, as 110 greetings are exchanged, they SHOULD each announce their support for 111 TLS and optionally SASL. Once BEEP greeting messages are exchanged, 112 if TLS is to be used and available by both parties, the listener 113 STARTs a channel with the TLS profile. 115 Once TLS has been started, a new BEEP greeting message is sent by 116 both initiator and listener, as required by the BEEP RFC. 118 After all BEEP greeting messages are exchanged in order for roles to 119 be clear, the agent MUST advertise the NETCONF profile. The manager 120 MUST NOT advertise the NETCONF profile. If the agent side of the 121 communication (either initiator or listener) receives a BEEP 122 element that contains the NETCONF profile, it MUST close 123 the connection. Similarly, if neither side issues a NETCONF profile 124 it is equally an error, and the listener MUST close the connection. 126 At this point, if SASL is desired, the initiator starts a BEEP 127 channel to perform a SASL exchange to authenticate itself. Upon 128 completion of authentication the channel is closed. That is, the 129 channel is exclusively used to authenticate. 131 Examples of both TLS and SASL profiles can be found in [7]. 133 It is anticipated that the SASL PLAIN mechanism will be heavily used 134 in conjunction with TLS.[5] In such cases, in accordance with RFC 135 2595 the PLAIN mechanism MUST NOT be advertised in the first BEEP 136 , but only in the one following a successful TLS 137 negotiation. This applies only if TLS and SASL PLAIN mechanisms are 138 both to be used. To avoid risk of eavesdropping, the SASL PLAIN 139 mechanism MUST NOT be used over unencrypted channels. More specifics 140 about the use of SASL and TLS are mentioned in Security 141 Considerations below. 143 Once authentication has occurred, there is no need to distinguish 144 between initiator and listener. We now distinguish between manager 145 and agent, and it is assumed that each knows its role in the 146 conversation. 148 2.2. Starting a Channel for NETCONF 150 The manager now establishes a new channel and specifies the single 151 NETCONF profile. For example: 153 (M = Manager ; A = Agent ) 155 M: MSG 0 1 . 10 48 116 156 M: Content-type: application/beep+xml 157 M: 158 M: 159 M: 160 M: END 161 A: RPY 0 1 . 38 87 162 A: Content-Type: application/beep+xml 163 A: 164 A: 165 A: END 167 At this point we are ready to proceed on BEEP channel 1 with NETCONF 168 operations. 170 Next the manager and the agent exchange NETCONF elements on 171 the new channel so that each side learns the other's capabilities. 172 This occurs through a MSG. Each side will then respond positively. 173 The following example is adapted from [1] Section 8.1: 175 A: MSG 1 0 . 0 429 176 A: Content-type: application/beep+xml 177 A: 178 A: 179 A: 180 A: 181 A: urn:ietf:params:netconf:base:1.0 182 A: 183 A: 184 A: urn:ietf:params:netconf:capability:startup:1.0 185 A: 186 A: 187 A: http://example.net/router/2.3/core#myfeature 188 A: 189 A: 190 A: 4 191 A: 192 A: END 194 M: RPY 1 0 . 0 0 195 M: END 197 Future NETCONF capabilities may require additional BEEP channels. 198 When such capabilities are defined, a BEEP mapping must be defined as 199 well. 201 At this point, the NETCONF session is established, and capabilities 202 have been exchanged. 204 2.3. NETCONF Session Usage 206 Nearly all NETCONF operations are executed through the element. 207 To issue an RPC, the manager transmits on the operational channel a 208 BEEP MSG containing the RPC and its arguments. In accordance with 209 the BEEP standard, RPC requests may be split across multiple BEEP 210 frames. 212 Once received and processed, the agent responds with BEEP RPY 213 messages on the same channel with the response to the RPC. In 214 accordance with the BEEP standard, responses may be split across 215 multiple BEEP frames. 217 2.4. NETCONF Session Teardown 219 Upon receipt of from the manager, once the agent has 220 completed all RPCs, it will close BEEP channel 0. When an agent 221 needs to initiate a close it will do so by closing BEEP channel 0. 223 Although not required to do so, the agent should allow for a 224 reasonable period for a manager to release an existing lock prior to 225 initiating a close. Once the agent has closed channel 0, all locks 226 are released, and each side follows tear down procedures as specified 227 in [8]. Having received a BEEP close or having sent , 228 a manager MUST NOT send further requests. If there are additional 229 activities due to expanded capabilities, these MUST cease in an 230 orderly manner, and should be properly described in the capability 231 mapping. 233 2.5. BEEP Profile for NETCONF 235 Profile Identification: http://iana.org/beep/netconf 237 messages exchanged during Channel Creation: not applicable 239 Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply" 241 Messages in positive replies: "rpc-reply" 243 Messages in negative replies: "rpc-reply" 245 Messages in one-to-many exchanges: none 247 Message syntax: [1] 249 message semantics: [1] 251 Contact Information: c.f., the "Author's Address" section of this 252 memo. 254 3. Security Considerations 256 Configuration information is by its very nature sensitive. Its 257 transmission in the clear and without integrity checking leaves 258 devices open to classic so-called "person in the middle" attacks. 259 Configuration information often times contains passwords, user names, 260 service descriptions, and topological information, all of which are 261 sensitive. A NETCONF application protocol, therefore, must minimally 262 support options for both confidentiality and authentication. 264 The BEEP mapping described in this document addresses both 265 confidentiality and authentication in a flexible manner through the 266 use of TLS and SASL profiles. Confidentiality is provided via the 267 TLS profile, and is used as discussed above. In addition, the server 268 certificate shall serve as the server's authentication to the client. 269 The client MUST be prepared to recognize a valid server certificate. 270 While distribution of such certificates is beyond the scope of this 271 document, the implementor is cautioned to be aware of any 272 interdependencies that may be placed on the network infrastructure 273 through the use of protocols that validate trust anchors. 275 For client-side authentication there are several options. The client 276 MAY provide a certificate during the initiation phase of TLS, in 277 which case the subject of that certificate shall be considered 278 principle for authentication purposes. Once again, server 279 implementors should be aware of any interdependencies that could be 280 created through protocols used to validate trust anchors. 282 In the case where the client has not authenticated through TLS, the 283 server SHOULD advertise one or more SASL profiles, from which the 284 client will choose. In the singular case where TLS is established 285 the minimum profile MAY be PLAIN. Otherwise, implementations MUST 286 support the DIGEST-MD5 profile as described in [6], and they MAY 287 support other profiles such as OTP.[10] 289 Different environments may well allow different rights prior to and 290 then after authentication. An authorization model is not specified 291 in this document. When an operation is not properly authorized then 292 a simple rpc-error containing "permission denied" is sufficient. 293 Note that authorization information may be exchanged in the form of 294 configuration information, which is all the more reason to ensure the 295 security of the connection. 297 4. IANA Considerations 299 The IANA is requested to assign a TCP port for NETCONF, and to 300 register the BEEP profile contained here-in. 302 5. Acknowledgments 304 This work is the product of the NETCONF IETF working group, and many 305 people have contributed to the NETCONF discussion. Most notably, Rob 306 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 307 Margaret Wasserman all contributed in some fashion to this work, 308 which was originally to be found in the NETCONF base protocol 309 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 310 Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very 311 constructive participation. The authors would also like to thank 312 Elwyn Davies for his constructive review. 314 6. References 316 6.1. Normative References 318 [1] Enns, R., "NETCONF Configuration Protocol", 319 draft-ietf-netconf-prot-08 (work in progress), September 2005. 321 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 322 Levels", BCP 14, RFC 2119, March 1997. 324 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", 325 RFC 2222, October 1997. 327 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 328 RFC 2246, January 1999. 330 [5] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 331 June 1999. 333 [6] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 334 Mechanism", RFC 2831, May 2000. 336 [7] Rose, M., "The Blocks Extensible Exchange Protocol Core", 337 RFC 3080, March 2001. 339 [8] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, 340 March 2001. 342 6.2. Informative References 344 [9] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 345 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 346 REC REC-xml-20001006, October 2000. 348 [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, 349 October 1998. 351 Appendix A. Change Log 353 08: Editing errors found by Bruce Moon. Changes to URNs. 355 07: Match URN changes to core draft (one change). 357 06: Changes (fix references, IANA section) from AD comments. 359 05: improved advice on use of tls and SASL profiles. 361 04: complete revamp of the profile. Added as well as 362 examples. 364 03: minor gnits relating to 366 02: added comments about locking 368 01: Removed management channel, rpc-status, rpc-abort, and associated 369 profile changes. 371 Authors' Addresses 373 Eliot Lear 374 Cisco Systems 375 Glatt-com 376 Glattzentrum, Zurich 8301 377 CH 379 Email: lear@cisco.com 381 Ken Crozier 383 Email: ken.crozier@gmail.com 385 Intellectual Property Statement 387 The IETF takes no position regarding the validity or scope of any 388 Intellectual Property Rights or other rights that might be claimed to 389 pertain to the implementation or use of the technology described in 390 this document or the extent to which any license under such rights 391 might or might not be available; nor does it represent that it has 392 made any independent effort to identify any such rights. Information 393 on the procedures with respect to rights in RFC documents can be 394 found in BCP 78 and BCP 79. 396 Copies of IPR disclosures made to the IETF Secretariat and any 397 assurances of licenses to be made available, or the result of an 398 attempt made to obtain a general license or permission for the use of 399 such proprietary rights by implementers or users of this 400 specification can be obtained from the IETF on-line IPR repository at 401 http://www.ietf.org/ipr. 403 The IETF invites any interested party to bring to its attention any 404 copyrights, patents or patent applications, or other proprietary 405 rights that may cover technology that may be required to implement 406 this standard. Please address the information to the IETF at 407 ietf-ipr@ietf.org. 409 Disclaimer of Validity 411 This document and the information contained herein are provided on an 412 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 413 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 414 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 415 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 416 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 417 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 419 Copyright Statement 421 Copyright (C) The Internet Society (2006). This document is subject 422 to the rights, licenses and restrictions contained in BCP 78, and 423 except as set forth therein, the authors retain all their rights. 425 Acknowledgment 427 Funding for the RFC Editor function is currently provided by the 428 Internet Society.