SNMP over TCP Transport Mapping

- + SNMP over TCP Transport Mapping TU Braunschweig

Bueltenweg 74/75 38106 Braunschweig Germany - +49 531 391-3289 + +49 531 391-3283 schoenw@ibr.cs.tu-bs.de

- + Operations and Management NMRG Network Management Simple Network Management Protocol SNMP Transmission Control Protocol TCP @@ -133,34 +133,34 @@

IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-IDENTITY, experimental FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC; nmrgSnmpDomains MODULE-IDENTITY - LAST-UPDATED "200004031800Z" + LAST-UPDATED "200103010000Z" ORGANIZATION "IRTF Network Management Research Group" CONTACT-INFO "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531 391-3283 Email: schoenw@ibr.cs.tu-bs.de" DESCRIPTION "This MIB module defines the SNMP over TCP transport mapping." - REVISION "200004031800Z" + REVISION "200103010000Z" DESCRIPTION "Initial version, published as RFC &rfc.number;." ::= { experimental nmrg(91) 1 } -- SNMP over TCP over IPv4 snmpTCPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "The SNMP over TCP over IPv4 transport domain. The @@ -269,29 +269,43 @@ SNMP over TCP is intended to be used when the size of the transferred data is large since TCP offers flow control and efficient segmentation. The transport of large amounts of management data via SNMP over UDP requires many request/response interactions with small-sized SNMP over UDP messages, which causes latency to increase excessively. + TCP connections are established on behalf of the SNMP + applications which initiate a transaction. In particular, + command generator applications are responsible for opening TCP + connections to command responder applications and notification + originator applications are responsible to initiate TCP + connections to notification receiver applications, which are + selected as described in Section 3 of RFC 2573 . If the TCP connection cannot be + established, then transaction is aborted reported to the + application as a timeout error condition. Alternative connection + establishment procedures are discussed in + but are not part of this specification. + + All SNMP entities (whether in an agent role or manager role) can close TCP connections at any point in time. This ensures that SNMP entities can control their resource usage and shut down TCP - connections that are not used. Note that SNMP engines MUST - process SNMP messages even if the incoming half of the TCP - connection is closed while the outgoing half remains open. + connections that are not used. Note that SNMP engines are not + required to process SNMP messages if the incoming half of the + TCP connection is closed while the outgoing half remains open. - The processing of any outstanding SNMP requests when both halves + The processing of any outstanding SNMP requests when both sides of the TCP connection have been closed is implementation dependent. The sending SNMP entity SHOULD therefore not make assumptions about the processing of outstanding SNMP requests once a TCP connection is closed. A timeout error condition SHOULD be signalled for confirmed requests if the TCP connection is closed before a response has been received.

@@ -310,21 +324,21 @@ unconfirmed operation. There is an important difference between an unconfirmed protocol operation sent over a reliable transport and a confirmed protocol operation. A reliable transport such as TCP only guarantees that delivered data is not damaged, lost, duplicated, or delivered out of order. It does not guarantee that the delivered data was actually processed in any way by the application process. Furthermore, even a reliable transport such - as TCP can not guarantee that data sent to a remote system is + as TCP cannot guarantee that data sent to a remote system is eventually delivered on the remote system. Even a graceful close of the TCP connection does not guarantee that the receiving TCP engine has actually delivered all the data to an application process. With a confirmed SNMP operation, the receiving SNMP engine acknowledges that the data was actually received. Depending on the SNMP protocol operation, a confirmation may indicate that further processing was done. For example, the response to an @@ -395,34 +409,20 @@ package.

- - - - Key words for use in RFCs to Indicate Requirement Levels - - - Harvard University - - - - - - - An Architecture for Describing SNMP Management Frameworks Cabletron Systems, Inc. BMC Software, Inc. @@ -760,20 +760,34 @@ Ericsson Cisco Systems + + + + Key words for use in RFCs to Indicate Requirement Levels + + + Harvard University + + + + + + + SNMP Communications Services Clearpoint Research Corporation @@ -805,43 +819,101 @@ EPFL -

- - - The requirement to handle half-closed TCP connections causes - additional implementation complexity in event-driven - applications since a half-closed socket would need to be - excluded from Randy> poll/select lists input checking (since - the descriptor would Randy> always come up ready for read) but - be left in the write list Randy> until the application decides - to close the socket after writing Randy> the response. This - may turn out hard to implement consistently across platforms. - Perhaps it would be simpler to just disallow half-closed TCP - connections in order to enhance interoperability. - - - The text does not explicitely say when TCP connections are - opened and by whom. However, some people believe that only one - sensible interpretation is actually possible. The question is - how precise we have to be without interacting too deeply with - RFC 2573. - - + This memo defines a simple connection establishment scheme where + the notification originator or command generator application is + responsible to establish TCP connections to notification receiver + or command responder applications. The purpose of this section is + to document variations or alternatives of this scheme which have + been discussed during the development of this specification. The + discussion below focuses on notification originator applications + since this is case where people seem to have diverging viewpoints. + The discussion below also assumes that the reader is familiar with + the SNMPv3 notification forwarding model as defined in RFC 2573 + . + + + The variations that have been discussed are basically driven by + the idea to provide fallback mechanisms in cases where TCP + connection establishment from the notification originator to the + notification receiver fails. The approach specified in this memo + simply drops notifications if the TCP connection cannot be + established. This implies that notification originators which need + reliable notification delivery must implement a local notification + log in order to keep a history of notifications that could not be + delivered. + + + Another option is to deliver notifications via UDP in case TCP + connection establishment fails. This might require to augment the + snmpTargetTable with columns that provide information about the + alternate UDP transport domain and address. In general, this + approach only helps to deliver notifications in cases where the + notification receiver is unable to accept more TCP connections. In + other fault scenarios (e.g. routing problems in the network), the + UDP packet would have no or only marginally better chances to + reach the notification receiver. This implies that notification + originators which need reliable notification delivery still need + to implement a local notification log in order to keep a history + of notifications in cases the UDP packets do not reach the + destination. + + + A generalization of this approach leads to the idea of a sparse + augmentation of the snmpTargetTable which lists alternate fallback + transports endpoints of arbitrary transport domains. Multiple + fallbacks may be possible by using a tag list approach. This + provides a generic transport independent fallback mechanism + which is independent of the TCP transport mapping defined in + this memo. + + + Another alternative is to make the notification originator + responsible to retry connection establishment. This could be + accomplished by augmenting the snmpTargetTable with additional + columns that specify retry counts and timeouts or by adapting the + existing snmpTargetAddrTimeout and snmpTargetAddrRetryCount + columns in the snmpTargetTable. But even this approach requires a + local notification log in order to handle situations where all + retries have failed. + + + A fundamentally different approach is to make the notification + receiver responsible to establish the TCP connection to the + notification originator. This approach has the advantage that the + notification originator does not necessarily need a list of + pre-configured notification receiver transport addresses. The + current notification forwarding model however relies on the + snmpTargetTable to identify notification targets. So the question + comes up whether (a) new entries are added to the snmpTargetTable + when a connection is established or whether (b) connections are + only accepted if they match pre-configured snmpTargetTable + entries. Note that the target selection logic relies on a tag list + which can not reasonably populated when a connection is accepted. + So only option (b) seems to be compliant with the current + notification forwarding logic. Another issue to consider is the + volunerability to denial of service attacks. A notification + originator can be easily attacked by syn-flooding attacks if it + listens for incoming TCP connections. Finally, in order to let + notification originator and notification receiver appplications + coexist easily on a single system, it would be necessary to assign + new default port numbers on which notification originators listen + for incoming TCP connections.

Return-Path: Received: by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) id RAA01884 for nmrg-outgoing; Fri, 2 Mar 2001 17:28:48 +0100 (MET) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id RAA01804; Fri, 2 Mar 2001 17:28:45 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA17182; Fri, 2 Mar 2001 17:28:45 +0100 Date: Fri, 2 Mar 2001 17:28:45 +0100 Message-Id: <200103021628.RAA17182@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: internet-drafts@ietf.org CC: Network Management Research Group Subject: [nmrg] please post draft-irtf-nmrg-snmp-tcp-06.txt Sender: owner-nmrg@ibr.cs.tu-bs.de Precedence: bulk Please post the following document as an Internet Draft. It has been produced by the network management IRTF research group. http://www.ibr.cs.tu-bs.de/~schoenw/draft-irtf-nmrg-snmp-tcp-06.txt Thank you. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936