Subject: [nmrg] new snmp over tcp document
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Date: Fri, 2 Mar 2001 17:44:41 +0100

I have posted a new version of the snmp over tcp document. Below is a
diff of the xml sources relative to the last internet draft. As you
will see, I tried to capture some of the rather lengthy discussions we
had a few months ago about connections establishment schemes and the
various implications wrt. to "reliable notification delivery". I hope
I did a fair summary, but I would also not be surprised that my text
in the appendix leads to another big discussion.

Anyway, unless someone here on the list has any major issues with this
document, I would like to get it published as an RFC. So please speak
up in the next two weeks if you have any major concerns. If there are
no major issues, I will check in Minneapolis whether the EOS WG
(Evolution of SNMP) is interested to take over this document to put it
on the standards track. If they are not interested, then I will submit
it to the RFC editor asking for publication as an experiemental RFC.

/js

Index: snmptcp.xml
===================================================================
RCS file: /usr/home/schoenw/CVS/irtf/nmrg/snmp-tcp/snmptcp.xml,v
retrieving revision 1.3
retrieving revision 1.4
diff -U10 -r1.3 -r1.4
--- snmptcp.xml	2000/11/24 11:27:19	1.3
+++ snmptcp.xml	2001/03/02 16:24:53	1.4
@@ -1,40 +1,40 @@
 <?xml version="1.0"?>
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
 <?rfc toc="yes"?>
 <?rfc compact="yes"?>
 <rfc ipr="full2026"
-     docName="draft-irtf-nmrg-snmp-tcp-05.txt"
+     docName="draft-irtf-nmrg-snmp-tcp-06.txt"
      category="exp">
 
-<!-- $Id: snmptcp.xml,v 1.3 2000/11/24 11:27:19 schoenw Exp $ -->
+<!-- $Id: snmptcp.xml,v 1.4 2001/03/02 16:24:53 schoenw Exp $ -->
 
 <front>
 
 <title abbrev="SNMP over TCP Transport Mapping">
   SNMP over TCP Transport Mapping
 </title>
 
 <author initials="J." surname="Schoenwaelder" fullname="Juergen Schoenwaelder">
   <organization>TU Braunschweig</organization>
   <address>
     <postal>
       <street>Bueltenweg 74/75</street>
       <city>38106 Braunschweig</city>
       <country>Germany</country>
     </postal>
-    <phone>+49 531 391-3289</phone>
+    <phone>+49 531 391-3283</phone>
     <email>[email-masked]</email>
   </address>
 </author>
 
-<date month="November" year="2000"/>
+<date month="March" year="2001"/>
 
 <area>Operations and Management</area>
 
 <workgroup>NMRG</workgroup>
 
 <keyword>Network Management</keyword>
 <keyword>Simple Network Management Protocol</keyword>
 <keyword>SNMP</keyword>
 <keyword>Transmission Control Protocol</keyword>
 <keyword>TCP</keyword>
@@ -133,34 +133,34 @@
 <section title="Definitions">
 
   <figure>
     <artwork>
 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: [email-masked]"
     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 @@
     </t>
     <t>
       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.
     </t>
     <t>
+      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 <xref
+      target="refs.RFC2573"/>. 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 <xref target="alt"/>
+      but are not part of this specification.
+    </t>
+    <t>
       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.
     </t>
     <t>
-      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.
     </t>
   </section>
 
   <section title="Reliable Transport versus Confirmed Operations">
@@ -310,21 +324,21 @@
       unconfirmed operation.
     </t>
     <t>
       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.
     </t>
     <t>
       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</eref>.
   </t>
 </section>
 
 </middle>
 
 <back>
 
 <references>
 
-  <reference anchor="refs.RFC2119">
-    <front>
-      <title>
-        Key words for use in RFCs to Indicate Requirement Levels
-      </title>
-      <author initials="S." surname="Bradner" fullname="S. Bradner">
-        <organization>Harvard University</organization>
-      </author>
-      <date month="March" year="1997"/>
-    </front>
-    <seriesInfo name="BCP" value="14"/>
-    <seriesInfo name="RFC" value="2119"/>
-  </reference>
-
   <reference anchor="refs.RFC2571">
     <front>
       <title>
         An Architecture for Describing SNMP Management Frameworks
       </title>
       <author initials="D." surname="Harrington" fullname="David Harrington">
         <organization>Cabletron Systems, Inc.</organization>
       </author>
       <author initials="R." surname="Presuhn" fullname="Randy Presuhn">
         <organization>BMC Software, Inc.</organization>
@@ -760,20 +760,34 @@
         <organization>Ericsson</organization>
       </author>
       <author initials="B." surname="Stewart" fullname="Bob Stewart">
         <organization>Cisco Systems</organization>
       </author>
       <date month="April" year="1999"/>
     </front>
     <seriesInfo name="RFC" value="2570"/>
   </reference>
 
+  <reference anchor="refs.RFC2119">
+    <front>
+      <title>
+        Key words for use in RFCs to Indicate Requirement Levels
+      </title>
+      <author initials="S." surname="Bradner" fullname="S. Bradner">
+        <organization>Harvard University</organization>
+      </author>
+      <date month="March" year="1997"/>
+    </front>
+    <seriesInfo name="BCP" value="14"/>
+    <seriesInfo name="RFC" value="2119"/>
+  </reference>
+
   <reference anchor="refs.RFC1270">
     <front>
       <title>
         SNMP Communications Services
       </title>
       <author initials="F." surname="Kastenholz" fullname="Frank Kastenholz">
         <organization>Clearpoint Research Corporation</organization>
       </author>
       <date month="October" year="1991"/>
     </front>
@@ -805,43 +819,101 @@
       <author initials="J.P." surname="Martin-Flatin" fullname="J.P. Martin-Flatin">
         <organization>EPFL</organization>
       </author>
       <date month="March" year="1999"/>
     </front>
     <seriesInfo name="Simple Times" value="7(1)"/>
   </reference>
 
 </references>
 
-<section title="OPEN ISSUES">
+<section anchor="alt" title="Connection Establishment Alternatives">
   <t>
-    <list style="numbers">
-      <t>
-        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.
-      </t>
-      <t>
-        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.
-      </t>
-    </list>
+    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
+    <xref target="refs.RFC2573"/>.
+  </t>
+  <t>
+    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.
+  </t>
+  <t>
+    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.
+  </t>
+  <t>
+    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.
+  </t>
+  <t>
+    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.
+  </t>
+  <t>
+    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.
   </t>
 </section>
 
 </back>
 
 </rfc>
 
 <!-- Local Variables:                                           -->
 <!-- compile-command: "xml2rfc snmptcp"                         -->
 <!-- ispell-local-dictionary: "american"                        -->

Date: Fri, 2 Mar 2001 17:28:45 +0100
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: Network Management Research Group <[email-masked]>
Subject: [nmrg] please post draft-irtf-nmrg-snmp-tcp-06.txt
Sender: [email-masked]

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
<[email-masked]>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>