idnits 2.17.1 draft-ietf-netconf-soap-03.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 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 744. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (September 7, 2004) is 7164 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 578, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 582, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 599, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 611, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 623, 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: 11 errors (**), 0 flaws (~~), 8 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: March 8, 2005 September 7, 2004 5 Using the Network Configuration Protocol (NETCONF) Over the Simple 6 Object Access Protocol (SOAP) 7 draft-ietf-netconf-soap-03 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 March 8, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 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 that yield application protocols sufficient for 50 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 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 4.1 Integrity, Privacy, and Authentication . . . . . . . . . . 13 75 4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 13 76 4.3 Environmental Specifics . . . . . . . . . . . . . . . . . 14 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 79 5.2 Informative References . . . . . . . . . . . . . . . . . . . 16 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 81 A. WSDL Definitions . . . . . . . . . . . . . . . . . . . . . . . 17 82 A.1 NETCONF SOAP Binding . . . . . . . . . . . . . . . . . . . 17 83 A.2 Sample Service Definition . . . . . . . . . . . . . . . . 18 84 Intellectual Property and Copyright Statements . . . . . . . . 19 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 application protocol 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 [15] 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 the Appendix. 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 2. SOAP Background for NETCONF 110 Why introduce SOAP as yet another wrapper around what is already a 111 remote procedure call message? There are, in fact, both technical 112 and practical reasons. The technical reasons are perhaps less 113 compelling, but let's examine them first. 115 The use of SOAP does offer a few technical advantages. SOAP is 116 fundamentally an XML messaging scheme (which is capable of supporting 117 remote procedure call) and it defines a simple message format 118 composed of a "header" and a "body" contained within an "envelope". 119 The "header" contains meta-information relating to the message, and 120 can be used to indicate such things as store-and-forward behaviour or 121 transactional characteristics. In addition, SOAP specifies an 122 optional encoding for the "body" of the message. However, this 123 encoding is not applicable to NETCONF as one of the goals is to have 124 highly readable XML, and SOAP-encoding is optimized instead for ease 125 of automated deserialization. These benefits of the SOAP message 126 structure are simple, but worthwhile due to the fact that they are 127 already standardized. 129 It is the practical reasons that truly make SOAP an interesting 130 choice for device management. It is not difficult to invent a 131 mechanism for exchanging XML messages over TCP, but what is difficult 132 is getting that mechanism supported in a wide variety of tools and 133 operating systems and having that mechanism understood by a great 134 many developers. SOAP over HTTP (with WSDL) is seeing good success 135 at this, and this means that a device management protocol making use 136 of these technologies has advantages in being implemented and 137 adopted. Admittedly, there are interoperability problems with SOAP 138 and WSDL, but such problems have wide attention and can be expected 139 to be resolved. 141 2.1 Use and Storage of WSDL and XSD 143 One of the advantages of using machine readable formats such as Web 144 Services Description Language (WSDL) [4] and XML Schemas [5] is that 145 they can be used automatically in the software development process. 146 With appropriate tools, WSDL and XSD can be used to generate classes 147 that act as remote interfaces or application specific data 148 structures. Other uses, such as document generation and service 149 location, are also common. A great innovation found with many 150 XML-based definition languages is the use of hyperlinks for referring 151 to documents containing supporting definitions. For instance, in 152 WSDL, the import statement 154 157 imports the definitions of XML types and elements from the base 158 NETCONF schema. Ideally, the file containing that schema is hosted 159 on a web server under the authority of the standards body that 160 defined the schema. In this way, dependent standards can be built up 161 over time and all are accessible to automated software tools that 162 ensure adherence to the standards. Thus, it will gradually become as 163 important for iana.org to host documents like 165 http://iana.org/ietf/netconf/base_1.0.xsd 167 as the IETF now hosts documents such as 169 http://www.ietf.org/rfc/rfc2616.txt 171 Note that WSDL declarations for SOAP over BEEP bindings are not yet 172 standardized. 174 2.2 SOAP over HTTP 176 While it is true that SOAP focuses on messages and can be bound to 177 different underlying protocols such as HTTP, SMTP, or BEEP, most 178 existing SOAP implementations support only HTTP or HTTP/TLS. 180 There are a number of advantages to considering SOAP over protocols 181 other than HTTP, as HTTP assigns the very distinct client and server 182 roles by connection initiation. This causes difficulties in 183 supporting asynchronous notification and can be relieved in many ways 184 by replacing HTTP with BEEP. 186 2.3 HTTP Drawbacks 188 HTTP is not the ideal transport for messaging, but it is adequate for 189 the most basic interpretation of "remote procedure call". HTTP is 190 based on a communication pattern whereby the client (which initiates 191 the TCP connection) makes a "request" to the server. The server 192 returns a "response" and this process is continued (possibly over a 193 persistent connection, as described below). This matches the basic 194 idea of a remote procedure call where the caller invokes a procedure 195 on a remote server and waits for the return value. 197 Potential criticisms of HTTP could include the following: 198 o server-initiated data flow is awkward to provide 199 o headers are verbose and text-based 200 o idle connections may be closed by intermediate proxies 201 o data encapsulation must adhere to MIME 202 o bulk transfer relies on stream-based ordering 204 In many ways these criticisms are directed at particular compromises 205 in the design of HTTP. As such, they are important to consider, but 206 it is not clear that they result in fatal drawbacks for a device 207 management protocol. 209 2.4 BCP56: On the Use of HTTP as a Substrate 211 Best Current Practice 56 [9] presents a number of important 212 considerations on the use of HTTP in application protocols. In 213 particular, it raises the following concerns: 214 o HTTP may be more complex than is necessary for the application 215 o The use of HTTP may mask the application from some firewalls 216 o A substantially new service should not re-use port 80 as assigned 217 to HTTP 218 o HTTP caching may mask connection state 220 Fundamentally, these concerns lie directly with SOAP over HTTP, 221 rather than the application of SOAP over HTTP to NETCONF. As BCP 56 222 indicates, it is debatable whether HTTP is an appropriate protocol 223 for SOAP at all, and it is likely that BEEP would be a superior 224 protocol for most SOAP applications. Unfortunately, SOAP over HTTP 225 is in common use and must be supported if the practical benefits of 226 SOAP are to be realized. Note that the verbose nature of SOAP 227 actually makes it more readily processed by firewalls, albeit 228 firewalls designed to process SOAP messages. 230 It is very important that HTTP caches are not inserted between 231 NETCONF managers and agents as NETCONF session state is tied to the 232 state of the underlying transport connection. Three defensive 233 actions can be taken: 234 o Prohibit caching through the use of HTTP headers Cache-Control and 235 Pragma: no-cache 236 o Ensure that HTTP proxies are not deployed within the management 237 network 238 o Use HTTPS 240 It is also possible to respond to the concern on the re-use of port 241 80. A NETCONF SOAP service can be offered on any desired port, and 242 it is recommended that a new standard port for SOAP over HTTP, or a 243 new standard port for NETCONF over SOAP (over HTTP) be defined. 245 2.5 Important HTTP 1.1 Features 247 HTTP 1.1 [8] includes two important features that provide for 248 relatively efficient transport of SOAP messages. These features are 249 "persistent connections" and "chunked transfer-coding". 251 Persistent connections allow a single TCP connection to be used 252 across multiple HTTP requests. This permits multiple SOAP request/ 253 response message pairs to be exchanged without the overhead of 254 creating a new TCP connection for each request. Given that a single 255 stream is used for both requests and responses, it is clear that some 256 form of framing is necessary. For messages whose length is known in 257 advance, this is handled by the HTTP header "Content-length". For 258 messages of dynamic length, "Chunking" is required. 260 HTTP "Chunking" or "chunked transfer-coding" allows the sender to 261 send an indefinite amount of binary data. This is accomplished by 262 informing the receiver of the size of each "chunk" (substring of the 263 data) before the chunk is transmitted. The last chunk is indicated 264 by a chunk of zero length. Chunking can be effectively used to 265 transfer a large XML document where the document is generated on-line 266 from a non-XML form in memory. 268 In terms of application to SOAP message exchanges, persistent 269 connections are clearly important for performance reasons, and are 270 particularly important when it is the persistence of authenticated 271 connections that is at stake. When one considers that messages of 272 dynamic length are the rule rather than the exception for SOAP 273 messages, it is also clear that Chunking is very useful. In some 274 cases it is possible to buffer a SOAP response and determine its 275 length before sending, but the storage requirements for this are 276 prohibitive for many devices. Together, these two features provide a 277 good foundation for device management using SOAP over HTTP. 279 2.6 SOAP Over BEEP 281 Although not widely adopted by the Web Services community, BEEP is an 282 excellent substrate for SOAP [16]. 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 faultcode is "Client" in the SOAP envelope namespace, the SOAP 327 Fault faultstring is the contents of the NETCONF "tag", 328 and the SOAP Fault detail is the original structure. 330 For instance, given the following , 332 334 EXAMPLE_MTU_RANGE 335 128 336 error 337 mtu 21050; 338 MTU 21050 on Ethernet/1 is 339 outside range 256..9192 340 342 the associated SOAP Fault message is 343 345 346 347 soapenv:Client 348 EXAMPLE_MTU_RANGE 349 350 352 EXAMPLE_MTU_RANGE 353 128 354 error 355 mtu 21050; 356 MTU 21050 on Ethernet/1 is 357 outside range 256..9192 358 359 360 361 362 364 3. A SOAP Service for NETCONF 366 3.1 Fundamental Use Case 368 The fundamental use case for NETCONF over SOAP is that of a 369 management console ("manager" role) managing one or more devices 370 running NETCONF agents ("agent" role). The manager initiates an HTTP 371 or BEEP connection to an agent and drives the NETCONF session via a 372 sequence of SOAP messages. When the manager closes the connection, 373 the NETCONF session is also closed. 375 3.2 NETCONF Session Establishment 377 A NETCONF over SOAP session is established by the initial message 378 exchange on the underlying substrate. For HTTP, a NETCONF session is 379 established once a SOAP message is POSTed to the NETCONF web 380 application URI. For BEEP, a NETCONF session is established once the 381 BEEP profile for SOAP handshake establishes the SOAP channel. 383 3.3 NETCONF Capabilities Exchange 385 Capabilities exchange, if defined through a NETCONF RPC operation, 386 can easily be accommodated in the SOAP binding. 388 3.4 NETCONF Session Usage 390 NETCONF sessions are persistent for both performance and semantic 391 reasons. NETCONF session state contains the following: 392 1. Authentication Information 393 2. Capability Information 394 3. Locks 395 4. Pending Operations 396 5. Operation Sequence Numbers 398 Authentication must be maintained throughout a session due to the 399 fact that it is expensive to establish. Capability Information is 400 maintained so that appropriate operations can be applied during a 401 session. Locks are released upon termination of a session as this 402 makes the protocol more robust. Pending operations come and go from 403 existence during the normal course of RPC operations. Operation 404 sequence numbers provide the small but necessary state information to 405 refer to operations during the session. 407 In the case of SOAP over HTTP, a NETCONF session is supported by an 408 HTTP connection with an authenticated user. For SOAP over BEEP, a 409 NETCONF session is supported by a BEEP channel operating according to 410 the BEEP profile for SOAP [16]. 412 3.5 NETCONF Session Teardown 414 To allow automated cleanup, NETCONF over SOAP session teardown takes 415 place when the underlying connection (in the case of HTTP) or channel 416 (in the case of BEEP) is closed. Note that the root cause of such 417 teardown may be the closure of the TCP connection under either HTTP 418 or BEEP as the case may be. NETCONF managers and agents must be 419 capable of programatically closing the transport connections 420 associated with NETCONF sessions; thus, the HTTP or BEEP substrate 421 implementation must expose this appropriately. 423 3.6 A NETCONF Over SOAP example 425 Since the proposed WSDL (in Appendix A.1) uses document/literal 426 encoding, the use of a SOAP header and body has little impact on the 427 representation of a NETCONF operation. This example shows HTTP/1.0 428 for simplicity. Examples for HTTP/1.1 and BEEP would be similar. 430 POST /netconf HTTP/1.0 431 Content-Type: text/xml; charset=utf-8 432 Accept: application/soap+xml, text/* 433 Cache-Control: no-cache 434 Pragma: no-cache 435 Content-Length: 470 437 438 440 441 443 444 445 446 447 448 449 450 xml 451 452 453 454 456 The HTTP/1.0 response is also straightforward: 458 HTTP/1.0 200 OK 459 Content-Type: text/xml; charset=utf-8 461 462 464 465 467 468 469 470 root 471 superuser 472 473 474 fred 475 admin 476 477 478 barney 479 admin 480 481 482 483 484 485 487 4. Security Considerations 489 NETCONF is used to access and modify configuration information, so 490 the ability to access this protocol should be limited to users and 491 systems that are authorized to view or modify the agent's 492 configuration data. 494 Because configuration information is sent in both directions, it is 495 not sufficient for just the client or user to be authenticated with 496 the server. The identity of the server should also be authenticated 497 with the client. 499 Configuration data may include sensitive information, such as user 500 names or security keys. So, NETCONF should only be used over 501 communications channels that provide strong encryption for data 502 privacy. 504 If the NETCONF server provides remote access through insecure 505 protocols, such as HTTP, care should be taken to prevent execution of 506 the NETCONF program when strong user authentication or data privacy 507 is not available. 509 4.1 Integrity, Privacy, and Authentication 511 The NETCONF SOAP binding relies on an underlying secure transport for 512 integrity and privacy. Such transports are expected to include TLS 513 [12] and IPSec. There are a number of options for authentication 514 (some of which are deployment-specific): 515 o within the transport (such as with TLS client certificates) 516 o within HTTP (such as Digest Access Authentication [10]) 517 o within SOAP (such as a digital signature in the header [18]) 519 HTTP, BEEP, and SOAP level authentication can be integrated with 520 RADIUS [13] to support remote authentication databases. 522 4.2 Vulnerabilities 524 The above protocols may have various vulnerabilities, and these may 525 be inherited by NETCONF over SOAP. 527 NETCONF itself may have vulnerabilities due to the fact that an 528 authorization model is not currently specified. 530 It is important that device capabilities and authorization remain 531 constant for the duration of any outstanding NETCONF session. In the 532 case of NETCONF, it is important to consider that device management 533 may be taking place over multiple substrates (in addition to SOAP) 534 and it is important that the different substrates have a common 535 authentication model. 537 4.3 Environmental Specifics 539 Some deployments of NETCONF over SOAP may choose to use transports 540 without encryption. This presents vulnerabilities but may be 541 selected for deployments involving closed networks or debugging 542 scenarios. 544 A device managed by NETCONF may interact (over protocols other than 545 NETCONF) with devices managed by other protocols, all of differing 546 security. Each point of entry brings with it a potential 547 vulnerability. 549 5. References 551 5.1 Normative References 553 [1] Enns, R., "NETCONF Configuration Protocol", 554 draft-ietf-netconf-prot-03 (work in progress), June 2004, 555 . 558 [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 559 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 560 REC REC-xml-20001006, October 2000, 561 . 563 [3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, 564 N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access 565 Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, 566 . 568 [4] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana, 569 "Web Services Description Language (WSDL) 1.1", W3C Note 570 NOTE-wsdl-20010315, March 2001, 571 . 573 [5] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 574 Schema Part 1: Structures", W3C Recommendation 575 REC-xmlschema-1-20010502, May 2001, 576 . 578 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 579 Extensions (MIME) Part One: Format of Internet Message Bodies", 580 RFC 2045, November 1996, . 582 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 583 Extensions (MIME) Part Two: Media Types", RFC 2046, November 584 1996, . 586 [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 587 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 588 HTTP/1.1", RFC 2616, June 1999, 589 . 591 [9] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, 592 February 2002, . 594 [10] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 595 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: 596 Digest Access Authentication", RFC 2069, January 1997, 597 . 599 [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement 600 Levels", RFC 2119, March 1997, 601 . 603 [12] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 604 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 605 1999, . 607 [13] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 608 Authentication Dial In User Service (RADIUS)", RFC 2865, June 609 2000, . 611 [14] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, 612 November 2001, . 614 [15] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 615 3080, March 2001, . 617 [16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access 618 Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", 619 RFC 3288, June 2002, . 621 5.2 Informative References 623 [17] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with 624 Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec 625 2000, 626 . 628 [18] Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama, 629 "SOAP Security Extensions: Digital Signature", W3C Note 630 NOTE-SOAP-dsig-20010206, Feb 2001, 631 . 633 Author's Address 635 Ted Goddard 636 ICEsoft Technologies Inc. 637 Suite 300, 1717 10th St. NW 638 Calgary, AB T2M 4S2 639 Canada 641 Phone: (403) 663-3322 642 EMail: ted.goddard@icesoft.com 643 URI: http://www.icesoft.com 645 Appendix A. WSDL Definitions 647 A.1 NETCONF SOAP Binding 649 The following WSDL document assumes a hypothetical location for the 650 NETCONF schema. 652 653 661 664 665 666 667 668 669 671 672 673 674 675 676 678 679 681 682 683 684 686 687 688 690 691 692 694 696 A.2 Sample Service Definition 698 The following WSDL document assumes a hypothetical location for the 699 NETCONF over SOAP WSDL definitions. A typical deployment of a device 700 manageable via NETCONF over SOAP would provide a service definition 701 similar to the following to identify the address of the device. 703 704 711 714 715 716 717 718 720 722 Intellectual Property Statement 724 The IETF takes no position regarding the validity or scope of any 725 Intellectual Property Rights or other rights that might be claimed to 726 pertain to the implementation or use of the technology described in 727 this document or the extent to which any license under such rights 728 might or might not be available; nor does it represent that it has 729 made any independent effort to identify any such rights. Information 730 on the procedures with respect to rights in RFC documents can be 731 found in BCP 78 and BCP 79. 733 Copies of IPR disclosures made to the IETF Secretariat and any 734 assurances of licenses to be made available, or the result of an 735 attempt made to obtain a general license or permission for the use of 736 such proprietary rights by implementers or users of this 737 specification can be obtained from the IETF on-line IPR repository at 738 http://www.ietf.org/ipr. 740 The IETF invites any interested party to bring to its attention any 741 copyrights, patents or patent applications, or other proprietary 742 rights that may cover technology that may be required to implement 743 this standard. Please address the information to the IETF at 744 ietf-ipr@ietf.org. 746 Disclaimer of Validity 748 This document and the information contained herein are provided on an 749 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 750 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 751 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 752 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 753 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 754 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 756 Copyright Statement 758 Copyright (C) The Internet Society (2004). This document is subject 759 to the rights, licenses and restrictions contained in BCP 78, and 760 except as set forth therein, the authors retain all their rights. 762 Acknowledgment 764 Funding for the RFC Editor function is currently provided by the 765 Internet Society.