idnits 2.17.1 draft-irtf-nmrg-snmp-tcp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 149 has weird spacing: '... octets cont...' -- 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 (November 24, 2000) is 8547 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2571 (ref. '2') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '13') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '15') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '16') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '17') (Obsoleted by RFC 3410) ** Downref: Normative reference to an Informational RFC: RFC 1270 (ref. '18') ** Obsolete normative reference: RFC 793 (ref. '19') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' -- Possible downref: Non-RFC (?) normative reference: ref. '23' Summary: 19 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Schoenwaelder 2 Internet-Draft TU Braunschweig 3 Expires: May 25, 2001 November 24, 2000 5 SNMP over TCP Transport Mapping 6 draft-irtf-nmrg-snmp-tcp-05.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the entire list of Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/iid-abstracts.txt 29 This Internet-Draft will expire on May 25, 2001. 31 Copyright Notice 33 Copyright (C) The Internet Society (2000). All Rights Reserved. 35 Abstract 37 This memo defines a transport mapping for using the Simple Network 38 Management Protocol (SNMP) over TCP. The transport mapping can be 39 used with any version of SNMP. This document extends the transport 40 mappings defined in RFC 1906. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 3. SNMP over TCP . . . . . . . . . . . . . . . . . . . . . . . . 5 47 3.1 Serialization . . . . . . . . . . . . . . . . . . . . . . . . 5 48 3.2 Well-Known Values . . . . . . . . . . . . . . . . . . . . . . 6 49 3.3 Connection Management . . . . . . . . . . . . . . . . . . . . 6 50 3.4 Reliable Transport versus Confirmed Operations . . . . . . . . 6 51 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 52 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 53 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 55 A. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . 10 56 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 58 1. Introduction 60 The SNMP Management Framework presently consists of five major 61 components: 63 o An overall architecture, described in RFC 2571 [2]. 64 o Mechanisms for describing and naming objects and events for the 65 purpose of management. The first version of this Structure of 66 Management Information (SMI) is called SMIv1 and described in STD 67 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 68 second version, called SMIv2, is described in STD 58, RFC 2578 69 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 70 o Message protocols for transferring management information. The 71 first version of the SNMP message protocol is called SNMPv1 and 72 described in STD 15, RFC 1157 [9]. A second version of the SNMP 73 message protocol, which is not an Internet standards track 74 protocol, is called SNMPv2c and described in RFC 1901 [10] and 75 RFC 1906 [11]. The third version of the message protocol is 76 called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and 77 RFC 2574 [13]. 78 o Protocol operations for accessing management information. The 79 first set of protocol operations and associated PDU formats is 80 described in STD 15, RFC 1157 [9]. A second set of protocol 81 operations and associated PDU formats is described in RFC 1905 82 [14]. 83 o A set of fundamental applications described in RFC 2573 [15] and 84 the view-based access control mechanism described in RFC 2575 85 [16]. 87 A more detailed introduction to the current SNMP Management 88 Framework can be found in RFC 2570 [17]. 90 Managed objects are accessed via a virtual information store, termed 91 the Management Information Base or MIB. Objects in the MIB are 92 defined using the mechanisms defined in the SMI. 94 This memo defines a transport mapping for using the Simple Network 95 Management Protocol (SNMP) over TCP. The transport mapping can be 96 used with any version of SNMP. This document extends the transport 97 mappings defined in RFC 1906 [11]. 99 The SNMP over TCP transport mapping is an optional transport 100 mapping. SNMP protocol engines that implement the SNMP over TCP 101 transport mapping MUST also implement the SNMP over UDP transport 102 mapping as defined in RFC 1906 [11]. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [1]. 108 2. Definitions 110 IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN 112 IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, experimental FROM SNMPv2-SMI 113 TEXTUAL-CONVENTION FROM SNMPv2-TC; 115 nmrgSnmpDomains MODULE-IDENTITY 116 LAST-UPDATED "200004031800Z" 117 ORGANIZATION "IRTF Network Management Research Group" 118 CONTACT-INFO 119 "Juergen Schoenwaelder 120 TU Braunschweig 121 Bueltenweg 74/75 122 38106 Braunschweig 123 Germany 125 Phone: +49 531 391-3283 126 Email: schoenw@ibr.cs.tu-bs.de" 127 DESCRIPTION 128 "This MIB module defines the SNMP over TCP transport mapping." 129 REVISION "200004031800Z" 130 DESCRIPTION 131 "Initial version, published as RFC XXXX." 132 ::= { experimental nmrg(91) 1 } 134 -- SNMP over TCP over IPv4 136 snmpTCPDomain OBJECT-IDENTITY 137 STATUS current 138 DESCRIPTION 139 "The SNMP over TCP over IPv4 transport domain. The 140 corresponding transport address is of type SnmpTCPAddress." 141 ::= { nmrgSnmpDomains 1 } 143 SnmpTCPAddress ::= TEXTUAL-CONVENTION 144 DISPLAY-HINT "1d.1d.1d.1d/2d" 145 STATUS current 146 DESCRIPTION 147 "Represents a TCP/IPv4 address: 149 octets contents encoding 150 1-4 IP-address network-byte order 151 5-6 TCP-port network-byte order 152 " 153 SYNTAX OCTET STRING (SIZE (6)) 155 END 157 3. SNMP over TCP 159 SNMP over TCP is an experimental optional transport mapping. It is 160 primarily defined to support more efficient bulk transfer mechanisms 161 within the SNMP framework [20]. 163 The originator of a request/response transaction chooses the 164 transport protocol for the entire transaction. The transport 165 protocol MUST NOT change during a transaction. 167 In general, originators of request/response transactions are free to 168 use the transport they assume is the best in a given situation. 169 However, since TCP has a larger footprint on resource usage than 170 UDP, engines using SNMP over TCP may choose to switch back to UDP by 171 refusing new TCP connections whenever necessary (e.g. too many open 172 TCP connections). 174 When selecting the transport, it is useful to consider how SNMP 175 interacts with TCP acknowledgements and timers. In particular, 176 infrequent SNMP interactions over TCP may lead to additional IP 177 packets carrying acknowledgements for SNMP responses if there is no 178 chance to piggyback them. Furthermore, it is recommended to 179 configure SNMP timers to fire later when using SNMP over TCP to 180 avoid application specific timeouts before the TCP timers have 181 expired. 183 3.1 Serialization 185 Each instance of a message is serialized into a single BER-encoded 186 message, using the algorithm specified in Section 8 of RFC 1906 187 [11]. The BER-encoded message is then sent over a TCP connection. An 188 SNMP engine MUST NOT interleave SNMP messages within the TCP byte 189 stream. All the bytes of one SNMP message must be sent before any 190 bytes of a different SNMP message. 192 It is possible to exchange multiple SNMP request/response pairs over 193 a single (persistent) TCP connection. TCP connections are per 194 default full-duplex and data can travel in both directions at 195 different speeds. It is therefore possible to send multiple SNMP 196 messages to a remote SNMP engine before receiving responses from the 197 same SNMP engine. Note that an SNMP engine is not required to return 198 responses in the same order as it received the requests. 200 It is possible that the underlying TCP implementation delivers byte 201 sequences that do not coincide with SNMP message boundaries. A 202 receiving SNMP engine MUST therefore use the length field in the 203 BER-encoded SNMP message to separate multiple requests sent over a 204 single TCP connection. 206 3.2 Well-Known Values 208 It is RECOMMENDED that administrators configure their SNMP entities 209 containing command responders to listen on TCP port 161 for incoming 210 connections. It is also RECOMMENDED that SNMP entities containing 211 notification receivers be configured to listen on TCP port 162 for 212 connection requests. 214 When an SNMP entity uses the TCP transport mapping, it MUST be 215 capable of accepting messages that are at least 8192 octets in size. 216 Implementation of larger values is encouraged whenever possible. 218 3.3 Connection Management 220 The use of TCP connections introduces costs [18]. Connection 221 establishment and teardown cause additional network traffic. 222 Furthermore, maintaining open connections binds resources in the 223 network layer of the underlying operating system. 225 SNMP over TCP is intended to be used when the size of the 226 transferred data is large since TCP offers flow control and 227 efficient segmentation. The transport of large amounts of management 228 data via SNMP over UDP requires many request/response interactions 229 with small-sized SNMP over UDP messages, which causes latency to 230 increase excessively. 232 All SNMP entities (whether in an agent role or manager role) can 233 close TCP connections at any point in time. This ensures that SNMP 234 entities can control their resource usage and shut down TCP 235 connections that are not used. Note that SNMP engines MUST process 236 SNMP messages even if the incoming half of the TCP connection is 237 closed while the outgoing half remains open. 239 The processing of any outstanding SNMP requests when both halves of 240 the TCP connection have been closed is implementation dependent. The 241 sending SNMP entity SHOULD therefore not make assumptions about the 242 processing of outstanding SNMP requests once a TCP connection is 243 closed. A timeout error condition SHOULD be signalled for confirmed 244 requests if the TCP connection is closed before a response has been 245 received. 247 3.4 Reliable Transport versus Confirmed Operations 249 The transport of SNMP messages over TCP results in a reliable 250 exchange of SNMP messages between SNMP engines. In particular, TCP 251 guarantees (in the absence of security attacks) that the delivered 252 data is not damaged, lost, duplicated, or delivered out of order 253 [19]. 255 The SNMP protocol has been designed to support confirmed as well as 256 unconfirmed operations [2]. The inform-request protocol operation is 257 an example for a confirmed operation while the snmpV2-trap operation 258 is an example for an unconfirmed operation. 260 There is an important difference between an unconfirmed protocol 261 operation sent over a reliable transport and a confirmed protocol 262 operation. A reliable transport such as TCP only guarantees that 263 delivered data is not damaged, lost, duplicated, or delivered out of 264 order. It does not guarantee that the delivered data was actually 265 processed in any way by the application process. Furthermore, even a 266 reliable transport such as TCP can not guarantee that data sent to a 267 remote system is eventually delivered on the remote system. Even a 268 graceful close of the TCP connection does not guarantee that the 269 receiving TCP engine has actually delivered all the data to an 270 application process. 272 With a confirmed SNMP operation, the receiving SNMP engine 273 acknowledges that the data was actually received. Depending on the 274 SNMP protocol operation, a confirmation may indicate that further 275 processing was done. For example, the response to an inform-request 276 protocol operation also indicates to the notification originator 277 that the notification passed the security model and that it was 278 delivered to the notification receiver application. Similarily, the 279 response to a set-request indicates that the data passed the 280 transport, the authentication mechanism and that the write request 281 was actually processed by the command responder. 283 A reliable transport is thus only a poor approximation for confirmed 284 operations. Applications that need confirmation of delivery or 285 processing are encouraged to use the confirmed operations, such as 286 the inform-request, rather than using unconfirmed operations, such 287 as snmpV2-trap, over a reliable transport. 289 4. Security Considerations 291 It is recommended that implementors consider the security features 292 as provided by the SNMPv3 framework in order to provide SNMP 293 security. Specifically, the use of the User-based Security Model 294 RFC 2574 [13] and the View-based Access Control Model RFC 2575 [16] 295 is recommended. 297 It is then a customer/user responsibility to ensure that the SNMP 298 entity giving access to a MIB is properly configured to give access 299 to the objects only to those principals (users) that have legitimate 300 rights to indeed GET or SET (change) them. 302 The SNMP over TCP transport mapping does not have any impact on the 303 security mechanisms provided by SNMPv3. However, SNMP over TCP may 304 introduce new vulnerabilities to denial of service attacks (such as 305 TCP syn flooding) that do not exist in this form in other transport 306 mappings. 308 5. Acknowledgments 310 This document is the result of discussions within the Network 311 Management Research Group (NMRG) of the Internet Research Task 312 Force[21] (IRTF). Special thanks to Luca Deri, Jean-Philippe 313 Martin-Flatin, Aiko Pras, Ron Sprenkels, and Bert Wijnen for their 314 comments and suggestions. 316 Additional useful comments have been made by Mike Ayers, Jeff Case, 317 Mike Daniele, David Harrington, Lauren Heintz, Keith McCloghrie, and 318 Dave Shield. 320 Luca Deri, Wes Hardaker, Bert Helthuis, and Erik Schoenfelder helped 321 to create prototype implementations. The SNMP over TCP transport 322 mapping is currently supported by the NET-SNMP package[22] and the 323 Linux CMU SNMP package[23]. 325 References 327 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 328 Levels", BCP 14, RFC 2119, March 1997. 330 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 331 Describing SNMP Management Frameworks", RFC 2571, April 1999. 333 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 334 Management Information for TCP/IP-based Internets", STD 16, RFC 335 1155, May 1990. 337 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 338 RFC 1212, March 1991. 340 [5] Rose, M., "A Convention for Defining Traps for use with the 341 SNMP", RFC 1215, March 1991. 343 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 344 M. and S. Waldbusser, "Structure of Management Information 345 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 347 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 348 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 349 RFC 2579, April 1999. 351 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 352 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 353 58, RFC 2580, April 1999. 355 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 356 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. 358 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 359 "Introduction to Community-based SNMPv2", RFC 1901, January 360 1996. 362 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 363 "Transport Mappings for Version 2 of the Simple Network 364 Management Protocol (SNMPv2)", RFC 1906, January 1996. 366 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 367 Processing and Dispatching for the Simple Network Management 368 Protocol (SNMP)", RFC 2572, April 1999. 370 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 371 for version 3 of the Simple Network Management Protocol 372 (SNMPv3)", RFC 2574, April 1999. 374 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 375 "Protocol Operations for Version 2 of the Simple Network 376 Management Protocol (SNMPv2)", RFC 1905, January 1996. 378 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 379 2573, April 1999. 381 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 382 Control Model (VACM) for the Simple Network Management 383 Protocol (SNMP)", RFC 2575, April 1999. 385 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 386 to Version 3 of the Internet-standard Network Management 387 Framework", RFC 2570, April 1999. 389 [18] Kastenholz, F., "SNMP Communications Services", RFC 1270, 390 October 1991. 392 [19] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 393 September 1981. 395 [20] Sprenkels, R. and J.P. Martin-Flatin, "Bulk Transfers of MIB 396 Data", Simple Times 7(1), March 1999. 398 [21] http://www.irtf.org/ 400 [22] http://net-snmp.sourceforge.net/ 402 [23] http://www.gaertner.de/snmp/ 404 Author's Address 406 Juergen Schoenwaelder 407 TU Braunschweig 408 Bueltenweg 74/75 409 38106 Braunschweig 410 Germany 412 Phone: +49 531 391-3289 413 EMail: schoenw@ibr.cs.tu-bs.de 415 Appendix A. OPEN ISSUES 417 1. The requirement to handle half-closed TCP connections causes 418 additional implementation complexity in event-driven 419 applications since a half-closed socket would need to be 420 excluded from Randy> poll/select lists input checking (since the 421 descriptor would Randy> always come up ready for read) but be 422 left in the write list Randy> until the application decides to 423 close the socket after writing Randy> the response. This may 424 turn out hard to implement consistently across platforms. 425 Perhaps it would be simpler to just disallow half-closed TCP 426 connections in order to enhance interoperability. 427 2. The text does not explicitely say when TCP connections are 428 opened and by whom. However, some people believe that only one 429 sensible interpretation is actually possible. The question is 430 how precise we have to be without interacting too deeply with 431 RFC 2573. 433 Full Copyright Statement 435 Copyright (C) The Internet Society (2000). All Rights Reserved. 437 This document and translations of it may be copied and furnished to 438 others, and derivative works that comment on or otherwise explain it 439 or assist in its implementation may be prepared, copied, published 440 and distributed, in whole or in part, without restriction of any 441 kind, provided that the above copyright notice and this paragraph 442 are included on all such copies and derivative works. However, this 443 document itself may not be modified in any way, such as by removing 444 the copyright notice or references to the Internet Society or other 445 Internet organizations, except as needed for the purpose of 446 developing Internet standards in which case the procedures for 447 copyrights defined in the Internet Standards process must be 448 followed, or as required to translate it into languages other than 449 English. 451 The limited permissions granted above are perpetual and will not be 452 revoked by the Internet Society or its successors or assigns. 454 This document and the information contained herein is provided on an 455 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 456 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 457 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 458 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 459 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Acknowledgement 463 Funding for the RFC Editor function is currently provided by the 464 Internet Society.