idnits 2.17.1 draft-ietf-netconf-soap-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. ** 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 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 2005) is 7034 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '6' is defined on line 716, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 720, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 749, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 764, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 774, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-03 -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2616 (ref. '8') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3205 (ref. '9') (Obsoleted by RFC 9205) ** Obsolete normative reference: RFC 2069 (ref. '10') (Obsoleted by RFC 2617) ** Obsolete normative reference: RFC 2246 (ref. '12') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3288 (ref. '16') (Obsoleted by RFC 4227) Summary: 10 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Goddard 2 Internet-Draft ICEsoft Technologies Inc. 3 Expires: July 2, 2005 January 2005 5 Using the Network Configuration Protocol (NETCONF) Over the Simple 6 Object Access Protocol (SOAP) 7 draft-ietf-netconf-soap-04 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 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 21 Internet-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 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The Network Configuration Protocol (NETCONF) is applicable to a wide 43 range of devices in a variety of environments. The emergence of Web 44 Services gives one such environment, and is presently characterized 45 by the use of the Simple Object Access Protocol (SOAP). NETCONF 46 finds many benefits in this environment: from the re-use of existing 47 standards, to ease of software development, to integration with 48 deployed systems. Herein, we describe SOAP over HTTP and SOAP over 49 BEEP bindings for NETCONF. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. SOAP Background for NETCONF . . . . . . . . . . . . . . . . . 4 55 2.1 Use and Storage of WSDL and XSD . . . . . . . . . . . . . 4 56 2.2 SOAP over HTTP . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3 HTTP Drawbacks . . . . . . . . . . . . . . . . . . . . . . 5 58 2.4 BCP56: On the Use of HTTP as a Substrate . . . . . . . . . 6 59 2.5 Important HTTP 1.1 Features . . . . . . . . . . . . . . . 6 60 2.6 SOAP Over BEEP . . . . . . . . . . . . . . . . . . . . . . 7 61 2.7 SOAP Implementation Considerations . . . . . . . . . . . . 7 62 2.7.1 SOAP Feature Exploitation . . . . . . . . . . . . . . 7 63 2.7.2 SOAP Headers . . . . . . . . . . . . . . . . . . . . . 8 64 2.7.3 SOAP Faults . . . . . . . . . . . . . . . . . . . . . 8 65 3. A SOAP Service for NETCONF . . . . . . . . . . . . . . . . . . 10 66 3.1 Fundamental Use Case . . . . . . . . . . . . . . . . . . . 10 67 3.2 NETCONF Session Establishment . . . . . . . . . . . . . . 10 68 3.3 NETCONF Capabilities Exchange . . . . . . . . . . . . . . 10 69 3.4 NETCONF Session Usage . . . . . . . . . . . . . . . . . . 10 70 3.5 NETCONF Session Teardown . . . . . . . . . . . . . . . . . 11 71 3.6 A NETCONF Over SOAP example . . . . . . . . . . . . . . . 11 72 3.7 NETCONF SOAP WSDL . . . . . . . . . . . . . . . . . . . . 12 73 3.8 Sample Service Definition WSDL . . . . . . . . . . . . . . 14 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 4.1 Integrity, Privacy, and Authentication . . . . . . . . . . 16 76 4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 16 77 4.3 Environmental Specifics . . . . . . . . . . . . . . . . . 17 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 81 6.2 Informative References . . . . . . . . . . . . . . . . . . . 20 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 83 Intellectual Property and Copyright Statements . . . . . . . . 22 85 1. Introduction 87 Given the use of XML [2] and the remote procedure call 88 characteristics, it is natural to consider a binding of the NETCONF 89 [1] operations to a SOAP [3] application protocol. This document 90 proposes a binding of this form. 92 In general, SOAP is a natural messaging scheme for NETCONF, 93 essentially because of the remote procedure call character of both. 94 However, care must be taken with SOAP over HTTP as it is inherently 95 synchronous and client-driven. SOAP over BEEP [15] is technically 96 superior, but is not as widely adopted. 98 Four basic topics are presented: SOAP specifics of interest to 99 NETCONF, specifics on implementing NETCONF as a SOAP-based web 100 service, security considerations, and an appendix with functional 101 WSDL. In some sense, the most important part of the document is the 102 brief WSDL document presented in Section 3.7. With the right tools, 103 the WSDL combined with the base NETCONF XML Schemas provide machine 104 readable descriptions sufficient for the development of software 105 applications using NETCONF. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [11] 111 2. SOAP Background for NETCONF 113 Why introduce SOAP as yet another wrapper around what is already a 114 remote procedure call message? There are, in fact, both technical 115 and practical reasons. The technical reasons are perhaps less 116 compelling, but let's examine them first. 118 The use of SOAP does offer a few technical advantages. SOAP is 119 fundamentally an XML messaging scheme (which is capable of supporting 120 remote procedure call) and it defines a simple message format 121 composed of a "header" and a "body" contained within an "envelope". 122 The "header" contains meta-information relating to the message, and 123 can be used to indicate such things as store-and-forward behaviour or 124 transactional characteristics. In addition, SOAP specifies an 125 optional encoding for the "body" of the message. However, this 126 encoding is not applicable to NETCONF as one of the goals is to have 127 highly readable XML, and SOAP-encoding is optimized instead for ease 128 of automated deserialization. These benefits of the SOAP message 129 structure are simple, but worthwhile due to the fact that they are 130 already standardized. 132 It is the practical reasons that truly make SOAP an interesting 133 choice for device management. It is not difficult to invent a 134 mechanism for exchanging XML messages over TCP, but what is difficult 135 is getting that mechanism supported in a wide variety of tools and 136 operating systems and having that mechanism understood by a great 137 many developers. SOAP over HTTP (with WSDL) is seeing good success 138 at this, and this means that a device management protocol making use 139 of these technologies has advantages in being implemented and 140 adopted. Admittedly, there are interoperability problems with SOAP 141 and WSDL, but such problems have wide attention and can be expected 142 to be resolved. 144 2.1 Use and Storage of WSDL and XSD 146 One of the advantages of using machine readable formats such as Web 147 Services Description Language (WSDL) [4] and XML Schemas [5] is that 148 they can be used automatically in the software development process. 149 With appropriate tools, WSDL and XSD can be used to generate classes 150 that act as remote interfaces or application specific data 151 structures. Other uses, such as document generation and service 152 location, are also common. A great innovation found with many 153 XML-based definition languages is the use of hyperlinks for referring 154 to documents containing supporting definitions. 156 160 For instance, in WSDL, the above import statement imports the 161 definitions of XML types and elements from the base NETCONF schema. 162 Ideally, the file containing that schema is hosted on a web server 163 under the authority of the standards body that defined the schema. 164 In this way, dependent standards can be built up over time and all 165 are accessible to automated software tools that ensure adherence to 166 the standards. The IANA maintained registry for this purpose is 167 described in The IETF XML Registry [17]. 169 Note that WSDL declarations for SOAP over BEEP bindings are not yet 170 standardized. 172 2.2 SOAP over HTTP 174 While it is true that SOAP focuses on messages and can be bound to 175 different underlying protocols such as HTTP, SMTP, or BEEP, most 176 existing SOAP implementations support only HTTP or HTTP/TLS. 178 There are a number of advantages to considering SOAP over protocols 179 other than HTTP, as HTTP assigns the very distinct client and server 180 roles by connection initiation. This causes difficulties in 181 supporting asynchronous notification and can be relieved in many ways 182 by replacing HTTP with BEEP. 184 2.3 HTTP Drawbacks 186 HTTP is not the ideal transport for messaging, but it is adequate for 187 the most basic interpretation of "remote procedure call". HTTP is 188 based on a communication pattern whereby the client (which initiates 189 the TCP connection) makes a "request" to the server. The server 190 returns a "response" and this process is continued (possibly over a 191 persistent connection, as described below). This matches the basic 192 idea of a remote procedure call where the caller invokes a procedure 193 on a remote server and waits for the return value. 195 Potential criticisms of HTTP could include the following: 196 o server-initiated data flow is awkward to provide 197 o headers are verbose and text-based 198 o idle connections may be closed by intermediate proxies 199 o data encapsulation must adhere to MIME 200 o bulk transfer relies on stream-based ordering 202 In many ways these criticisms are directed at particular compromises 203 in the design of HTTP. As such, they are important to consider, but 204 it is not clear that they result in fatal drawbacks for a device 205 management protocol. 207 2.4 BCP56: On the Use of HTTP as a Substrate 209 Best Current Practice 56 [9] presents a number of important 210 considerations on the use of HTTP in application protocols. In 211 particular, it raises the following concerns: 212 o HTTP may be more complex than is necessary for the application 213 o The use of HTTP may mask the application from some firewalls 214 o A substantially new service should not re-use port 80 as assigned 215 to HTTP 216 o HTTP caching may mask connection state 218 Fundamentally, these concerns lie directly with SOAP over HTTP, 219 rather than the application of SOAP over HTTP to NETCONF. As BCP 56 220 indicates, it is debatable whether HTTP is an appropriate protocol 221 for SOAP at all, and it is likely that BEEP would be a superior 222 protocol for most SOAP applications. Unfortunately, SOAP over HTTP 223 is in common use and must be supported if the practical benefits of 224 SOAP are to be realized. Note that the verbose nature of SOAP 225 actually makes it more readily processed by firewalls, albeit 226 firewalls designed to process SOAP messages. 228 HTTP caches SHOULD NOT be inserted between NETCONF managers and 229 agents as NETCONF session state is tied to the state of the 230 underlying transport connection. Three defensive actions can be 231 taken: 232 o Caching MUST be prohibited through the use of HTTP headers 233 Cache-Control and Pragma: no-cache 234 o HTTP proxies SHOULD NOT be deployed within the management network 235 o Use HTTPS 237 It is also possible to respond to the concern on the re-use of port 238 80. A NETCONF SOAP service can be offered on any desired port, and 239 it is recommended that a new standard port for SOAP over HTTP, or a 240 new standard port for NETCONF over SOAP (over HTTP) be defined, as 241 requested in the IANA considerations of this document. 243 2.5 Important HTTP 1.1 Features 245 HTTP 1.1 [8] includes two important features that provide for 246 relatively efficient transport of SOAP messages. These features are 247 "persistent connections" and "chunked transfer-coding". 249 Persistent connections allow a single TCP connection to be used 250 across multiple HTTP requests. This permits multiple SOAP request/ 251 response message pairs to be exchanged without the overhead of 252 creating a new TCP connection for each request. Given that a single 253 stream is used for both requests and responses, it is clear that some 254 form of framing is necessary. For messages whose length is known in 255 advance, this is handled by the HTTP header "Content-length". For 256 messages of dynamic length, "Chunking" is required. 258 HTTP "Chunking" or "chunked transfer-coding" allows the sender to 259 send an indefinite amount of binary data. This is accomplished by 260 informing the receiver of the size of each "chunk" (substring of the 261 data) before the chunk is transmitted. The last chunk is indicated 262 by a chunk of zero length. Chunking can be effectively used to 263 transfer a large XML document where the document is generated on-line 264 from a non-XML form in memory. 266 In terms of application to SOAP message exchanges, persistent 267 connections are clearly important for performance reasons, and are 268 particularly important when it is the persistence of authenticated 269 connections that is at stake. When one considers that messages of 270 dynamic length are the rule rather than the exception for SOAP 271 messages, it is also clear that Chunking is very useful. In some 272 cases it is possible to buffer a SOAP response and determine its 273 length before sending, but the storage requirements for this are 274 prohibitive for many devices. Together, these two features provide a 275 good foundation for device management using SOAP over HTTP. HTTP 276 chunking and persistent connections SHOULD be used. 278 2.6 SOAP Over BEEP 280 Although not widely adopted by the Web Services community, BEEP is an 281 excellent substrate for SOAP [16]. In particular, it provides for 282 request/response message exchanges initiated by either BEEP peer and 283 allows the number of response messages to be arbitrary (including 284 zero). The BEEP profile for SOAP simply makes use of a single BEEP 285 channel for exchanging SOAP messages and benefits from BEEP's 286 inherent strengths for message exchange over a single transport 287 connection. 289 2.7 SOAP Implementation Considerations 291 It is not the goal of this document to cover the SOAP [3] 292 specification in detail. Instead, we provide a few comments that may 293 be of interest to an implementor of NETCONF over SOAP. 295 2.7.1 SOAP Feature Exploitation 297 NETCONF over SOAP does not make extensive use of SOAP features. For 298 instance, NETCONF operations are not broken into SOAP message parts, 299 and the SOAP header is not used to convey metadata. This is a 300 deliberate design decision as it allows the implementor to easily 301 provide NETCONF over multiple substrates while handling the messages 302 over those different substrates in a common way. 304 2.7.2 SOAP Headers 306 Implementors of NETCONF over SOAP should be aware of the following 307 characteristic of SOAP headers: a SOAP header may have the attribute 308 "mustUnderstand" and, if so, the recipient must either process the 309 header block or not process the SOAP message at all, and instead 310 generate a fault. A "mustUnderstand" header must not be silently 311 discarded. 313 In general, however, SOAP headers are intended for 314 application-specific uses. The NETCONF SOAP binding does not make 315 use of SOAP headers. 317 2.7.3 SOAP Faults 319 A SOAP Fault is returned in the event of a NETCONF . It 320 is constructed essentially as a wrapper for the , but 321 allow SOAP processors to propagate the to application 322 code using a language-appropriate exception mechanism. 324 A SOAP Fault is constructed from an as follows: the SOAP 325 Fault faultcode is "Client" in the SOAP envelope namespace, the SOAP 326 Fault faultstring is the contents of the NETCONF 327 "error-tag", and the SOAP Fault detail is the original 328 structure. 330 For instance, given the following , 332 333 rpc 334 MISSING_ATTRIBUTE 335 error 336 337 message-id 338 rpc 339 340 342 the associated SOAP Fault message is 343 346 347 348 soapenv:Client 349 MISSING_ATTRIBUTE 350 351 353 rpc 354 MISSING_ATTRIBUTE 355 error 356 357 message-id 358 rpc 359 360 361 362 363 364 366 3. A SOAP Service for NETCONF 368 3.1 Fundamental Use Case 370 The fundamental use case for NETCONF over SOAP is that of a 371 management console ("manager" role) managing one or more devices 372 running NETCONF agents ("agent" role). The manager initiates an HTTP 373 or BEEP connection to an agent and drives the NETCONF session via a 374 sequence of SOAP messages. When the manager closes the connection, 375 the NETCONF session is also closed. 377 3.2 NETCONF Session Establishment 379 A NETCONF over SOAP session is established by the initial message 380 exchange on the underlying substrate. For HTTP, a NETCONF session is 381 established once a SOAP message is POSTed to the NETCONF web 382 application URI. For BEEP, a NETCONF session is established once the 383 BEEP profile for SOAP handshake establishes the SOAP channel. 385 3.3 NETCONF Capabilities Exchange 387 Capabilities exchange is performed through the exchange of 388 messages. In the case of SOAP over HTTP, the HTTP client MUST send 389 the first message. The case of SOAP over BEEP imposes no 390 ordering constraints. 392 3.4 NETCONF Session Usage 394 NETCONF sessions are persistent for both performance and semantic 395 reasons. NETCONF session state contains the following: 396 1. Authentication Information 397 2. Capability Information 398 3. Locks 399 4. Pending Operations 400 5. Operation Sequence Numbers 402 Authentication must be maintained throughout a session due to the 403 fact that it is expensive to establish. Capability Information is 404 maintained so that appropriate operations can be applied during a 405 session. Locks are released upon termination of a session as this 406 makes the protocol more robust. Pending operations come and go from 407 existence during the normal course of RPC operations. Operation 408 sequence numbers provide the small but necessary state information to 409 refer to operations during the session. 411 In the case of SOAP over HTTP, a NETCONF session is supported by an 412 HTTP connection with an authenticated user. For SOAP over BEEP, a 413 NETCONF session is supported by a BEEP channel operating according to 414 the BEEP profile for SOAP [16]. 416 3.5 NETCONF Session Teardown 418 To allow automated cleanup, NETCONF over SOAP session teardown takes 419 place when the underlying connection (in the case of HTTP) or channel 420 (in the case of BEEP) is closed. Note that the root cause of such 421 teardown may be the closure of the TCP connection under either HTTP 422 or BEEP as the case may be. NETCONF managers and agents must be 423 capable of programatically closing the transport connections 424 associated with NETCONF sessions, such as in response to a 425 operation; thus, the HTTP or BEEP substrate 426 implementation must expose this appropriately. 428 3.6 A NETCONF Over SOAP example 430 Since the proposed WSDL (in Section 3.7) uses document/literal 431 encoding, the use of a SOAP header and body has little impact on the 432 representation of a NETCONF operation. This example shows HTTP/1.0 433 for simplicity. Examples for HTTP/1.1 and BEEP would be similar. 435 C: POST /netconf HTTP/1.0 436 C: Content-Type: text/xml; charset=utf-8 437 C: Accept: application/soap+xml, text/* 438 C: Cache-Control: no-cache 439 C: Pragma: no-cache 440 C: Content-Length: 467 441 C: 442 C: 443 C: 445 C: 446 C: 448 C: 449 C: 450 C: 451 C: 452 C: 453 C: 454 C: 455 C: 456 C: 457 C: 459 The HTTP/1.0 response is also straightforward: 461 S: HTTP/1.0 200 OK 462 S: Content-Type: text/xml; charset=utf-8 463 S: 464 S: 465 S: 467 S: 468 S: 470 S: 471 S: 472 S: 473 S: 474 S: root 475 S: superuser 476 S: Charlie Root 477 S: 1 478 S: 1 479 S: 480 S: 481 S: 482 S: fred 483 S: admin 484 S: Fred Flintstone 485 S: 2 486 S: 2 487 S: 488 S: 489 S: 490 S: 491 S: 492 S: 493 S: 494 S: 496 3.7 NETCONF SOAP WSDL 498 The following WSDL document assumes a hypothetical location for the 499 NETCONF schema. 501 502 510 514 515 517 518 519 520 521 523 524 525 526 527 528 529 531 532 533 534 535 537 538 539 540 541 542 544 545 546 547 548 549 551 552 553 554 555 556 557 558 559 560 562 563 565 566 567 568 570 571 572 574 575 576 577 578 579 581 582 583 585 586 587 589 591 3.8 Sample Service Definition WSDL 593 The following WSDL document assumes a hypothetical location for the 594 NETCONF over SOAP WSDL definitions. A typical deployment of a device 595 manageable via NETCONF over SOAP would provide a service definition 596 similar to the following to identify the address of the device. 598 599 606 610 611 612 613 614 616 618 4. Security Considerations 620 NETCONF is used to access and modify configuration information, so 621 the ability to access this protocol should be limited to users and 622 systems that are authorized to view or modify the agent's 623 configuration data. 625 Because configuration information is sent in both directions, it is 626 not sufficient for just the client or user to be authenticated with 627 the server. The identity of the server should also be authenticated 628 with the client. 630 Configuration data may include sensitive information, such as user 631 names or security keys. So, NETCONF should only be used over 632 communications channels that provide strong encryption for data 633 privacy. 635 If the NETCONF server provides remote access through insecure 636 protocols, such as HTTP, care should be taken to prevent execution of 637 the NETCONF program when strong user authentication or data privacy 638 is not available. 640 4.1 Integrity, Privacy, and Authentication 642 The NETCONF SOAP binding relies on an underlying secure transport for 643 integrity and privacy. Such transports are expected to include TLS 644 [12] and IPSec. There are a number of options for authentication 645 (some of which are deployment-specific): 646 o within the transport (such as with TLS client certificates) 647 o within HTTP (such as Digest Access Authentication [10]) 648 o within SOAP (such as a digital signature in the header [19]) 650 HTTP, BEEP, and SOAP level authentication can be integrated with 651 RADIUS [13] to support remote authentication databases. 653 4.2 Vulnerabilities 655 The above protocols may have various vulnerabilities, and these may 656 be inherited by NETCONF over SOAP. 658 NETCONF itself may have vulnerabilities due to the fact that an 659 authorization model is not currently specified. 661 It is important that device capabilities and authorization remain 662 constant for the duration of any outstanding NETCONF session. In the 663 case of NETCONF, it is important to consider that device management 664 may be taking place over multiple substrates (in addition to SOAP) 665 and it is important that the different substrates have a common 666 authentication model. 668 4.3 Environmental Specifics 670 Some deployments of NETCONF over SOAP may choose to use transports 671 without encryption. This presents vulnerabilities but may be 672 selected for deployments involving closed networks or debugging 673 scenarios. 675 A device managed by NETCONF may interact (over protocols other than 676 NETCONF) with devices managed by other protocols, all of differing 677 security. Each point of entry brings with it a potential 678 vulnerability. 680 5. IANA Considerations 682 The IANA will assign TCP ports for NETCONF for SOAP over HTTP and 683 SOAP over BEEP. 685 The IANA will place netconf-soap_1.0.wsdl in the IANA XML registry. 687 6. References 689 6.1 Normative References 691 [1] Enns, R., "NETCONF Configuration Protocol", 692 draft-ietf-netconf-prot-03 (work in progress), June 2004, 693 . 696 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 697 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 698 REC REC-xml-20001006, October 2000, 699 . 701 [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, 702 N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access 703 Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, 704 . 706 [4] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana, 707 "Web Services Description Language (WSDL) 1.1", W3C Note 708 NOTE-wsdl-20010315, March 2001, 709 . 711 [5] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 712 Schema Part 1: Structures", W3C Recommendation 713 REC-xmlschema-1-20010502, May 2001, 714 . 716 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 717 Extensions (MIME) Part One: Format of Internet Message Bodies", 718 RFC 2045, November 1996, . 720 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 721 Extensions (MIME) Part Two: Media Types", RFC 2046, November 722 1996, . 724 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 725 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 726 HTTP/1.1", RFC 2616, June 1999, 727 . 729 [9] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, 730 February 2002, . 732 [10] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 733 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: 734 Digest Access Authentication", RFC 2069, January 1997, 735 . 737 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 738 Levels", RFC 2119, March 1997, 739 . 741 [12] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 742 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 743 1999, . 745 [13] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 746 Authentication Dial In User Service (RADIUS)", RFC 2865, June 747 2000, . 749 [14] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, 750 November 2001, . 752 [15] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 753 3080, March 2001, . 755 [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access 756 Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", 757 RFC 3288, June 2002, . 759 [17] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004, 760 . 762 6.2 Informative References 764 [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with 765 Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec 766 2000, 767 . 769 [19] Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama, 770 "SOAP Security Extensions: Digital Signature", W3C Note 771 NOTE-SOAP-dsig-20010206, Feb 2001, 772 . 774 [20] Nadalin, A., Kaler, C., Hallam-Baker, P. and R. Monzillo, "Web 775 Services Security: SOAP Message Security V1.0", OASIS Standard 776 wss-soap-message-security-1.0, Mar 2004, 777 . 780 Author's Address 782 Ted Goddard 783 ICEsoft Technologies Inc. 784 Suite 300, 1717 10th St. NW 785 Calgary, AB T2M 4S2 786 Canada 788 Phone: (403) 663-3322 789 EMail: ted.goddard@icesoft.com 790 URI: http://www.icesoft.com 792 Intellectual Property Statement 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed to 796 pertain to the implementation or use of the technology described in 797 this document or the extent to which any license under such rights 798 might or might not be available; nor does it represent that it has 799 made any independent effort to identify any such rights. Information 800 on the procedures with respect to rights in RFC documents can be 801 found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use of 806 such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository at 808 http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Disclaimer of Validity 818 This document and the information contained herein are provided on an 819 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 820 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 821 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 822 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 823 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 824 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Copyright Statement 828 Copyright (C) The Internet Society (2005). This document is subject 829 to the rights, licenses and restrictions contained in BCP 78, and 830 except as set forth therein, the authors retain all their rights. 832 Acknowledgment 834 Funding for the RFC Editor function is currently provided by the 835 Internet Society.