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