SMUX questions

Anil Kumar <akumar@indetech.com> Thu, 24 June 1993 05:40 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa24196; 24 Jun 93 1:40 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa24192; 24 Jun 93 1:40 EDT
Received: from SLEEPY.TIS.COM by CNRI.Reston.VA.US id aa09519; 24 Jun 93 1:40 EDT
Received: from sleepy.tis.com by sleepy.TIS.COM id aa10042; 24 Jun 93 5:26 GMT
Received: from tis.com by sleepy.TIS.COM id aa10040; 24 Jun 93 1:16 EDT
Received: from relay2.UU.NET by TIS.COM (4.1/SUN-5.64) id AA03873; Thu, 24 Jun 93 01:16:40 EDT
Received: from spool.uu.net (via LOCALHOST) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14698; Thu, 24 Jun 93 01:15:07 -0400
Received: from indetech.UUCP by spool.uu.net with UUCP/RMAIL (queueing-rmail) id 011456.20821; Thu, 24 Jun 1993 01:14:56 EDT
Received: by indetech.com (/\=-/\ Smail3.1.18.1 #18.22) id <m0o8jOP-000Fz0C@indetech.com>; Wed, 23 Jun 93 21:58 PDT
Received: by kavita.indetech.com (/\=-/\ Smail3.1.18.1 #18.22) id <m0o8jLY-0000owC@kavita.indetech.com>; Wed, 23 Jun 93 21:55 PDT
Message-Id: <m0o8jLY-0000owC@kavita.indetech.com>
Date: Wed, 23 Jun 1993 21:55:00 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Anil Kumar <akumar@indetech.com>
To: snmp-sec-dev@tis.com
Subject: SMUX questions
Cc: akumar@indetech.com

1) One of the element of Simple open PDU (RFC1227) is identity. This has
been described as "authoritative designation for a SMUX peer".
What this OID represent? If I have 4 SMUX peer running on my machine,
how do I assign these OID's to different SMUX peers. What purpose 
this OID serves. I mean how does the master agent makes use of this information.

2) I am getting the impression that format of get-next message recived by
SNMP agent ( SMUX master) is not same as get-next message it sends to its peers.
Becasue , the get-next received by Agent from NMS contains SNMP version and
community which are not part of SMUX-PDUs defined in RFC1227. SMUX-PDUs
has PDUs (SNMP) as part of choice as in RFC1227 (reproduced below) -
The SMUX protocol data units are defined using Abstract Syntax
  
-- start included portion --
 
   SMUX DEFINITIONS ::= BEGIN

   IMPORTS
           DisplayString, ObjectName
                   FROM RFC1155-SMI

           PDUs
                   FROM RFC1157-SNMP;
 

   -- tags for SMUX-specific PDUs are application-wide to
   -- avoid conflict with tags for current (and future) 
   -- SNMP-generic PDUs
 
   SMUX-PDUs ::=
       CHOICE {
           open            -- SMUX peer uses
               OpenPDU,    -- immediately after TCP open
 
           close           -- either uses immediately before TCP close
               ClosePDU,
 
           registerRequest -- SMUX peer uses
               RReqPDU,
 
           registerResponse -- SNMP agent uses
               RRspPDU,
           registerResponse -- SNMP agent uses
               RRspPDU,
 
               PDUs,       -- note that roles are reversed:
                           --   SNMP agent does get/get-next/set
                           --   SMUX peer does get-response/trap
 
           commitOrRollback -- SNMP agent uses
               SOutPDU
      }
 
 
   -- open PDU
   -- currently only simple authentication
 
   OpenPDU ::=
       CHOICE {
          simple
              SimpleOpen
       }
 
   SimpleOpen ::=
       [APPLICATION 0] IMPLICIT
           SEQUENCE {
               version     -- of SMUX protocol
                   INTEGER {
                       version-1(0)
                   },
 
               identity    -- of SMUX peer, authoritative
                   OBJECT IDENTIFIER,
 
               description -- of SMUX peer, implementation-specific
                   DisplayString,
 
               password    -- zero length indicates no authentication
                   OCTET STRING
           }
 
 .... etc
-- end  included portion --


( Same is true with other SNMP PDU's. i.e., the format of SNMP messages 
floating betwwen Agent and NMS are not same as the same message floating 
between agent and peers).

If I encode the SNMP message get-response ( version 1, community public,
req-id 17, err-status -0, err-index-0. one variable with OID .1.3.6.1.2.1.1.1.1.0
and value "unix"), its encoding looks like -
30 2b			/* sequence - lemgth 43*/
	02 01 00	/* integer - length - 1 value 0 for version */
	04 06 70 75 62 6c 69 63 /* community - public */
a2 1e			/* context-speicfic tag for get-response */
	02 01 11	/* reqid = 17*/
	02 01 00	/* err-status = 0*/
	02 01 00	/*  err-index = 0*/
	30 13		/* sequnece of */
		30 11	/* sequence */
			06 09 2b 06 01 02 01 01 01 01 00 /* oid */
			04 04 75 6e 69 78	/* value = unix*/

If I encode the same SNMP get response message but is being generated by 
SMUX peer (  instead of SNMP agent ), its coding will look like -
a2 1e
	02 01 11
	02 01 00
	02 01 00
	30 13
		30 11
			06 09 2b 06 01 02 01 01 01 01 00
			04 04 75 6e 69 78
(This is mostly the same message as to be used from SMUX master to NMS
except for head chopped.)

Is my understnading right?
If so, SMUX peer does not recive community name as part of get, get-next or
set request from SMUX master ( SNMP agent). How than, SMUX peer does the
authentication?

3) I encode SMUX close PDU  ( type - goingDown) -

61 01 00
(61 means tag is application tag - constructed - type 1)
(01 is the length)
(00 is value. goingDown is zero in the enumeration.)

Is it OK?


Anil Kumar
akumar@indetech.com
voice - (510)438-8711
Fax   - (510)438-2034