idnits 2.17.1 draft-ietf-netconf-beep-08.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 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 384. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 390. ** 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 (January 5, 2006) is 6684 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 327, 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: July 9, 2006 K. Crozier 5 January 5, 2006 7 Using the NETCONF Protocol over Blocks Extensible Exchange Protocol 8 (BEEP) 9 draft-ietf-netconf-beep-08 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 July 9, 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 . . . . . . . . . . . . . . 4 52 2.3. NETCONF Session Usage . . . . . . . . . . . . . . . . . . 6 53 2.4. NETCONF Session Teardown . . . . . . . . . . . . . . . . . 6 54 2.5. BEEP Profile for NETCONF . . . . . . . . . . . . . . . . . 6 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 transportlayer 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 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 and optionally SASL. Once greetings are exchanged, if TLS is to 107 be used and available by both parties, the listener STARTs a channel 108 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 [7]. 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. To avoid risk of eavesdropping, the SASL PLAIN 126 mechanism MUST NOT be used over unencrypted channels. More specifics 127 about the use of SASL and TLS are mentioned in Security 128 Considerations below. 130 Once authentication has occurred, there is no need to distinguish 131 between initiator and listener. We now distinguish between manager 132 and agent, and it is assumed that each knows its role in the 133 conversation. 135 2.2. Starting a Channel for NETCONF 137 The manager now establishes new channel and specifies the single 138 NETCONF profile. For example: 140 (M = Manager ; A = Agent ) 142 M: MSG 0 1 . 10 48 116 143 M: Content-type: application/beep+xml 144 M: 145 M: 146 M: 147 M: END 148 A: RPY 0 1 . 38 87 149 A: Content-Type: application/beep+xml 150 A: 151 A: 152 A: END 154 At this point we are ready to proceed on BEEP channel 1 with NETCONF 155 operations. 157 Next the manager and the agent exchange NETCONF elements on 158 the new channel so that each side learns the other's capabilities. 159 This occurs through a MSG. Each side will then respond positively. 160 The following example is adapted from [1] Section 8.1: 162 A: MSG 1 0 . 0 429 163 A: Content-type: application/beep+xml 164 A: 165 A: 166 A: 167 A: 168 A: urn:ietf:params:netconf:base:1.0 169 A: 170 A: 171 A: urn:ietf:params:netconf:capability:startup:1.0 172 A: 173 A: 174 A: http://example.net/router/2.3/core#myfeature 175 A: 176 A: 177 A: 4 178 A: 179 A: END 181 M: RPY 1 0 . 0 0 182 M: END 184 Certain NETCONF capabilities may require additional BEEP channels. 185 When such capabilities are defined, a BEEP mapping must be defined as 186 well. 188 At this point, the NETCONF session is established, and capabilities 189 have been exchanged. 191 2.3. NETCONF Session Usage 193 Nearly all NETCONF operations are executed through the tag. To 194 issue an RPC, the manager transmits on the operational channel a BEEP 195 MSG containing the RPC and its arguments. In accordance with the 196 BEEP standard, RPC requests may be split across multiple BEEP frames. 198 Once received and processed, the agent responds with BEEP RPY 199 messages on the same channel with the response to the RPC. In 200 accordance with the BEEP standard, responses may be split across 201 multiple BEEP frames. 203 2.4. NETCONF Session Teardown 205 Upon receipt of from the manager, once the agent has 206 completed all RPCs, it will close BEEP channel 0. When an agent 207 needs to initiate a close it will do so by closing BEEP channel 0. 208 Although not required to do so, the agent should allow for a 209 reasonable period for a manager to release an existing lock prior to 210 initiating a close. Once the agent has closed channel 0, all locks 211 are released, and each side follows tear down procedures as specified 212 in [8]. Having received a BEEP close or having sent , 213 a manager MUST NOT send further requests. If there are additional 214 activities due to expanded capabilities, these MUST cease in an 215 orderly manner, and should be properly described in the capability 216 mapping. 218 2.5. BEEP Profile for NETCONF 220 Profile Identification: http://iana.org/beep/netconf 222 messages exchanged during Channel Creation: not applicable 224 Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply" 226 Messages in positive replies: "rpc-reply" 228 Messages in negative replies: "rpc-reply" 230 Messages in one-to-many exchanges: none 232 Message syntax: [1] 233 message semantics: [1] 235 Contact Information: c.f., the "Author's Address" section of this 236 memo. 238 3. Security Considerations 240 Configuration information is by its very nature sensitive. Its 241 transmission in the clear and without integrity checking leaves 242 devices open to classic so-called "person in the middle" attacks. 243 Configuration information often times contains passwords, user names, 244 service descriptions, and topological information, all of which are 245 sensitive. A NETCONF application protocol, therefore, must minimally 246 support options for both confidentiality and authentication. 248 The BEEP mapping described in this document addresses both 249 confidentiality and authentication in a flexible manner through the 250 use of TLS and SASL profiles. Confidentiality is provided via the 251 TLS profile, and is used as discussed above. In addition, the server 252 certificate shall serve as the server's authentication to the client. 253 The client MUST be prepared to recognize a valid server certificate. 254 While distribution of such certificates is beyond the scope of this 255 document, the implementor is cautioned to be aware of any 256 interdependencies that may be placed on the network infrastructure 257 through the use of protocols that validate trust anchors. 259 For client-side authentication there are several options. The client 260 MAY provide a certificate during the initiation phase of TLS, in 261 which case the subject of that certificate shall be considered 262 principle for authentication purposes. Once again, server 263 implementors should be aware of any interdependencies that could be 264 created through protocols used to validate trust anchors. 266 In the case where the client has not authenticated through TLS, the 267 server SHOULD advertise one or more SASL profiles, from which the 268 client will choose. In the singular case where TLS is established 269 the minimum profile MAY be PLAIN. Otherwise, implementations MUST 270 support the DIGEST-MD5 profile as described in [6], and they MAY 271 support other profiles such as OTP.[10] 273 Different environments may well allow different rights prior to and 274 then after authentication. An authorization model is not specified 275 in this document. When an operation is not properly authorized then 276 a simple rpc-error containing "permission denied" is sufficient. 277 Note that authorization information may be exchanged in the form of 278 configuration information, which is all the more reason to ensure the 279 security of the connection. 281 4. IANA Considerations 283 The IANA is requested to assign a TCP port for NETCONF, and to 284 register the BEEP profile contained here-in. 286 5. Acknowledgments 288 This work is the product of the NETCONF IETF working group, and many 289 people have contributed to the NETCONF discussion. Most notably, Rob 290 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 291 Margaret Wasserman all contributed in some fashion to this work, 292 which was originally to be found in the NETCONF base protocol 293 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 294 Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very 295 constructive participation. 297 6. References 299 6.1. Normative References 301 [1] Enns, R., "NETCONF Configuration Protocol", 302 draft-ietf-netconf-prot-08 (work in progress), September 2005. 304 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 305 Levels", BCP 14, RFC 2119, March 1997. 307 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", 308 RFC 2222, October 1997. 310 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 311 RFC 2246, January 1999. 313 [5] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 314 June 1999. 316 [6] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 317 Mechanism", RFC 2831, May 2000. 319 [7] Rose, M., "The Blocks Extensible Exchange Protocol Core", 320 RFC 3080, March 2001. 322 [8] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, 323 March 2001. 325 6.2. Informative References 327 [9] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 328 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 329 REC REC-xml-20001006, October 2000. 331 [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, 332 October 1998. 334 Appendix A. Change Log 336 08: Editing errors found by Bruce Moon. Changes to URNs. 338 07: Match URN changes to core draft (one change). 340 06: Changes (fix references, IANA section) from AD comments. 342 05: improved advice on use of tls and SASL profiles. 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 Authors' Addresses 356 Eliot Lear 357 Cisco Systems 358 Glatt-com 359 Glattzentrum, Zurich 8301 360 CH 362 Email: lear@cisco.com 364 Ken Crozier 366 Email: ken.crozier@gmail.com 368 Intellectual Property Statement 370 The IETF takes no position regarding the validity or scope of any 371 Intellectual Property Rights or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; nor does it represent that it has 375 made any independent effort to identify any such rights. Information 376 on the procedures with respect to rights in RFC documents can be 377 found in BCP 78 and BCP 79. 379 Copies of IPR disclosures made to the IETF Secretariat and any 380 assurances of licenses to be made available, or the result of an 381 attempt made to obtain a general license or permission for the use of 382 such proprietary rights by implementers or users of this 383 specification can be obtained from the IETF on-line IPR repository at 384 http://www.ietf.org/ipr. 386 The IETF invites any interested party to bring to its attention any 387 copyrights, patents or patent applications, or other proprietary 388 rights that may cover technology that may be required to implement 389 this standard. Please address the information to the IETF at 390 ietf-ipr@ietf.org. 392 Disclaimer of Validity 394 This document and the information contained herein are provided on an 395 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 396 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 397 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 398 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 399 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 402 Copyright Statement 404 Copyright (C) The Internet Society (2006). This document is subject 405 to the rights, licenses and restrictions contained in BCP 78, and 406 except as set forth therein, the authors retain all their rights. 408 Acknowledgment 410 Funding for the RFC Editor function is currently provided by the 411 Internet Society.