rfc2593.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,236 行 · 第 1/4 页

   The `status' command is generated either periodically or on demand by
   the SNMP agent in order to retrieve status information from running
   scripts. The SNMP agent sends the `status' command as defined in 5.2.
   The SNMP agent then expects a reply from the runtime system within a
   reasonable timeout interval.

   1.   If the timeout expires before the SNMP agent received a reply,
        then the SNMP agent sends an `abort' command to abort the
        running script and sets the `smRunState' of the running script
        to `terminated', the `smRunExitCode' to `genericError' and
        `smRunError' is modified to describe the timeout situation.

   2.   If the received message can not be analyzed because it does not
        have the required format, then the message is ignored. The SNMP
        agent continues to wait for a valid reply message until the
        timeout expires.

   3.   If the received message is a `4yz' reply and the `Id' matches
        the `Id' of the `status' command, then the SNMP agent assumes
        that the script status can not be read, which is a fatal error
        condition. The SNMP agent sends an `abort' command to abort the
        running script. The `smRunState' of the running script is set to



Schoenwaelder & Quittek       Experimental                     [Page 17]

RFC 2593                    SMX Protocol 1.0                    May 1999


        `terminated', the `smRunExitCode' to `genericError' and the
        `smRunError' is modified to describe the error situation.

   4.   If the received message is a `231' reply and the `Id' matches
        the `Id' of the `status' command, then the `smRunState' variable
        of the running script is updated.

   5.   Received messages are discarded if none of the previous rules
        applies.

6.2.8.  Processing Asynchronous Notifications

   The runtime system can send asynchronous status change notifications.
   These `5yz' replies are processed as described below.

   1.   If the received message is a `511' reply, then the message is
        displayed or logged appropriately and processing stops.

   2.   If the received message is a `531' reply, then the SNMP agent
        checks whether a running script with the given `RunId' exists in
        the runtime system. Processing of the notification stops if
        there is no running script with the `RunId'. Otherwise, the
        `smRunState' is updated.

   3.   If the received message is a `532' reply, then the SNMP agent
        checks whether a running script with the given `RunId' exists in
        the runtime system. Processing of the notification stops if
        there is no running script with the `RunId'. Otherwise,
        `smRunState' and `smRunResult' are updated.

   4.   If the received message is a `533' reply, then the SNMP agent
        checks whether a running script with the given `RunId' exists in
        the runtime system. Processing of the notification stops if
        there is no running script with the `RunId'. Otherwise,
        `smRunState' and `smRunResult' are updated and the
        `smScriptResult' notification is generated.

   5.   If the received message is a `534' reply, then the SNMP agent
        checks whether a running script with the given `RunId' exists in
        the runtime system. Processing stops if there is no running
        script with the `RunId'. Otherwise, `smExitCode' is set to
        `noError', `smRunState' is set to `terminated' and `smRunResult'
        is updated.

   6.   If the received message is a `535' reply, then the SNMP agent
        checks whether a running script with the given `RunId' exists in
        the runtime system. Processing stops if there is no running
        script with the `RunId'. Otherwise, `smRunState' is set to



Schoenwaelder & Quittek       Experimental                     [Page 18]

RFC 2593                    SMX Protocol 1.0                    May 1999


        `terminated' and `smExitCode' and `smRunError' are updated.

7.  An Example SMX Message Flow

   Below is an example SMX message exchange. Messages send from the SNMP
   agent are marked with `>' while replies send from the runtime system
   are marked with `<'. Line terminators (`CRLF') are not shown in order
   to make the example more readable.

     > hello 1
     < 211 1 SMX/1.0 0AF0BAED6F877FBC
     > start 2 42 "/var/snmp/scripts/foo.jar" untrusted ""
     > start 5 44 "/var/snmp/scripts/bar.jar" trusted "www.ietf.org"
     < 231 2 2
     > start 12 48 "/var/snmp/scripts/foo.jar" funny ""
     < 231 5 2
     < 532 0 44 2 "waiting for response"
     > status 18 42
     > status 19 44
     < 432 12
     < 231 19 2
     < 231 18 2
     > hello 578
     < 211 578 SMX/1.0 0AF0BAED6F877FBC
     > suspend 581 42
     < 231 581 4
     < 534 0 44 "test completed"
     > abort 611 42
     < 232 611

8.  Security Considerations

   The SMX protocol runs on top of a local TCP connection. Protocol
   messages never leave the local system. It is therefore not possible
   to attack the message exchanges if the underlying operating system
   protects local TCP connections from other users on the same machine.

   The only critical situation is the connection establishment phase.
   The rules defined in section 4 ensure that only local connections are
   accepted and that a runtime system has to identify itself with a
   security cookie generated by the SNMP agent and passed to the runtime
   system process as part of its environment. This rule ensures that
   scripts will only be executed on authorized runtime systems. This
   scheme relies on the protection of process environments by the
   operating system. Well maintained UNIX operating systems have this
   property.





Schoenwaelder & Quittek       Experimental                     [Page 19]

RFC 2593                    SMX Protocol 1.0                    May 1999


   The SMX protocol allows to execute script under different operating
   system and runtime system security profiles. The memo suggests to map
   the smLaunchOwner value to an operating system and a runtime system
   security profile. The operating system security profile is enforced
   by the operating system by setting up a proper process environment.
   The runtime security profile is enforced by a secure runtime system
   (e.g. the Java virtual machine or a safe Tcl interpreter) [7].

9.  Acknowledgments

   The protocol described in this memo is the result of a joint project
   between the Technical University of Braunschweig and C&C Research
   Laboratories of NEC Europe Ltd. in Berlin. We would like to thank the
   following project members for their contributions to the initial
   design and the implementation of the protocol described in this memo:

           M. Bolz         (TU Braunschweig)
           C. Kappler      (NEC Europe Ltd.)
           A. Kind         (NEC Europe Ltd.)
           S. Mertens      (TU Braunschweig)
           J. Nicklisch    (NEC Europe Ltd.)

10.  References

   [1]  Levi, D. and J. Schoenwaelder, "Definitions of Managed Objects
        for the Delegation of Management Scripts", RFC 2592, May 1999.

   [2]  Lindholm, T., and F. Yellin, "The Java Virtual Machine
        Specification", Addison Wesley, 1997.

   [3]  J.K. Ousterhout, "Tcl and the Tk Toolkit", Addison Wesley, 1994.

   [4]  Fritzinger, J.S., and M. Mueller, "Java Security", White Paper,
        Sun Microsystems, Inc., 1996.

   [5]  Levy, J.Y., Demailly, L., Ousterhout, J.K., and B. Welch, "The
        Safe-Tcl Security Model", Proc. USENIX Annual Technical
        Conference, June 1998.

   [6]  Crocker, D., and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon
        Internet Ltd., November 1997.

   [7]  Schoenwaelder, J., and J. Quittek, "Secure Management by
        Delegation within the Internet Management", Proc. IFIP/IEEE
        International Symposium on Integrated Network Management '99,
        May 1999.




Schoenwaelder & Quittek       Experimental                     [Page 20]

RFC 2593                    SMX Protocol 1.0                    May 1999


11.  Authors' Addresses

   Juergen Schoenwaelder
   TU Braunschweig
   Bueltenweg 74/75
   38106 Braunschweig
   Germany

   Phone: [phone]
   EMail: [e-mail]


   Juergen Quittek
   NEC Europe Ltd.
   C&C Research Laboratories
   Hardenbergplatz 2
   10623 Berlin
   Germany

   Phone: [phone]
   EMail: [e-mail]






























Schoenwaelder & Quittek       Experimental                     [Page 21]

RFC 2593                    SMX Protocol 1.0                    May 1999


12.  Full Copyright Statement

   Copyright (C) The Internet Society (1999). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Schoenwaelder & Quittek       Experimental                     [Page 22]