idnits 2.17.1 draft-ietf-netconf-beep-10.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 432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 422. ** 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 6, 2006) is 6620 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 359, 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 7, 2006 K. Crozier 5 March 6, 2006 7 Using the NETCONF Protocol over Blocks Extensible Exchange Protocol 8 (BEEP) 9 draft-ietf-netconf-beep-10 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 7, 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 . . . . . . . . . . . . . . . . . . . . . 10 57 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 58 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 59 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 60 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 61 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 63 Intellectual Property and Copyright Statements . . . . . . . . . . 15 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 and validate a server 270 certificate, and SHOULD by default reject invalid certificates. 272 In order to validate a certificate the client must be able to access 273 a trust anchor. While such validation methods are beyond the scope 274 of this document, they will depend on the type of device and 275 circumstance. Both the implementor and the administrator are 276 cautioned to be aware of any circular dependencies various methods 277 may introduce. For instance, OCSP servers may not be available in a 278 network cold start scenario, and would be ill advised for core 279 routers to depend on to receive configuration at boot. 281 For client-side authentication there are several options. The client 282 MAY provide a certificate during the initiation phase of TLS, in 283 which case the subject of that certificate shall be considered 284 principle for authentication purposes. Once again, server 285 implementors should be aware of any interdependencies that could be 286 created through protocols used to validate trust anchors. 288 TLS endpoints may be authorized based on subject name or certificate 289 authority (CA), depending on circumstances. For instance, it would 290 be unwise for a core internet router to allow a netconf agent 291 connection simply based on a valid certificate signed by a common CA, 292 but not unreasonable to allow a connection from an agent with a 293 particular distinguished name. On the other hand, it might be 294 desirable for enterprises to trust certificates signed by CAs of 295 their network operations team. 297 In the case where the client has not authenticated through TLS, the 298 server SHOULD advertise one or more SASL profiles, from which the 299 client will choose. In the singular case where TLS is established 300 the minimum profile MAY be PLAIN. Otherwise, implementations MUST 301 support the DIGEST-MD5 profile as described in [6], and they MAY 302 support other profiles such as OTP.[10] 304 Different environments may well allow different rights prior to and 305 then after authentication. An authorization model is not specified 306 in this document. When an operation is not properly authorized then 307 a simple rpc-error containing "permission denied" is sufficient. 308 Note that authorization information may be exchanged in the form of 309 configuration information, which is all the more reason to ensure the 310 security of the connection. 312 4. IANA Considerations 314 The IANA is requested to assign a TCP port for NETCONF, and to 315 register the BEEP profile contained here-in. 317 5. Acknowledgments 319 This work is the product of the NETCONF IETF working group, and many 320 people have contributed to the NETCONF discussion. Most notably, Rob 321 Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and 322 Margaret Wasserman all contributed in some fashion to this work, 323 which was originally to be found in the NETCONF base protocol 324 specification. Thanks also to Weijing Chen, Keith Allen, Juergen 325 Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very 326 constructive participation. The authors would also like to thank 327 Elwyn Davies for his constructive review. 329 6. References 331 6.1. Normative References 333 [1] Enns, R., "NETCONF Configuration Protocol", 334 draft-ietf-netconf-prot-08 (work in progress), September 2005. 336 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 337 Levels", BCP 14, RFC 2119, March 1997. 339 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", 340 RFC 2222, October 1997. 342 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 343 RFC 2246, January 1999. 345 [5] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 346 June 1999. 348 [6] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 349 Mechanism", RFC 2831, May 2000. 351 [7] Rose, M., "The Blocks Extensible Exchange Protocol Core", 352 RFC 3080, March 2001. 354 [8] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, 355 March 2001. 357 6.2. Informative References 359 [9] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, 360 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 361 REC REC-xml-20001006, October 2000. 363 [10] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, 364 October 1998. 366 Appendix A. Change Log 368 08: Editing errors found by Bruce Moon. Changes to URNs. 370 07: Match URN changes to core draft (one change). 372 06: Changes (fix references, IANA section) from AD comments. 374 05: improved advice on use of tls and SASL profiles. 376 04: complete revamp of the profile. Added as well as 377 examples. 379 03: minor gnits relating to 381 02: added comments about locking 383 01: Removed management channel, rpc-status, rpc-abort, and associated 384 profile changes. 386 Authors' Addresses 388 Eliot Lear 389 Cisco Systems 390 Glatt-com 391 Glattzentrum, Zurich 8301 392 CH 394 Email: lear@cisco.com 396 Ken Crozier 398 Email: ken.crozier@gmail.com 400 Intellectual Property Statement 402 The IETF takes no position regarding the validity or scope of any 403 Intellectual Property Rights or other rights that might be claimed to 404 pertain to the implementation or use of the technology described in 405 this document or the extent to which any license under such rights 406 might or might not be available; nor does it represent that it has 407 made any independent effort to identify any such rights. Information 408 on the procedures with respect to rights in RFC documents can be 409 found in BCP 78 and BCP 79. 411 Copies of IPR disclosures made to the IETF Secretariat and any 412 assurances of licenses to be made available, or the result of an 413 attempt made to obtain a general license or permission for the use of 414 such proprietary rights by implementers or users of this 415 specification can be obtained from the IETF on-line IPR repository at 416 http://www.ietf.org/ipr. 418 The IETF invites any interested party to bring to its attention any 419 copyrights, patents or patent applications, or other proprietary 420 rights that may cover technology that may be required to implement 421 this standard. Please address the information to the IETF at 422 ietf-ipr@ietf.org. 424 Disclaimer of Validity 426 This document and the information contained herein are provided on an 427 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 428 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 429 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 430 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 431 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 432 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 434 Copyright Statement 436 Copyright (C) The Internet Society (2006). This document is subject 437 to the rights, licenses and restrictions contained in BCP 78, and 438 except as set forth therein, the authors retain all their rights. 440 Acknowledgment 442 Funding for the RFC Editor function is currently provided by the 443 Internet Society.