home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1000s / rfc1022.txt < prev    next >
Text File  |  1987-10-27  |  25KB  |  671 lines
  1.  
  2. Network Working Group                                      C. Partridge
  3. Request For Comment: 1022                                      BBN/NNSC
  4.                                                              G. Trewitt
  5.                                                                Stanford
  6.                                                            October 1987
  7.  
  8.           THE HIGH-LEVEL ENTITY MANAGEMENT PROTOCOL (HEMP)
  9.  
  10. STATUS OF THIS MEMO
  11.  
  12.    An application protocol for managing network entities such as hosts,
  13.    gateways and front-end machines, is presented.  This protocol is a
  14.    component of the High-Level Entity Management System (HEMS) described
  15.    in RFC-1021.  Readers may want to consult RFC-1021 when reading this
  16.    memo.  This memo also assumes a knowledge of the ISO data encoding
  17.    standard, ASN.1.  Distribution of this memo is unlimited.
  18.  
  19. PROTOCOL OVERVIEW
  20.  
  21.    The High-Level Entity Management Protocol (HEMP) provides an
  22.    encapsulation system and set of services for communications between
  23.    applications and managed entities.  HEMP is an application protocol
  24.    which relies on existing transport protocols to deliver HEMP messages
  25.    to their destination(s).
  26.  
  27.    The protocol is targeted for management interactions between
  28.    applications and entities.  The protocol is believed to be suitable
  29.    for both monitoring and control interactions.
  30.  
  31.    HEMP provides what the authors believe are the three essential
  32.    features of a management protocol:  (1) a standard encapsulation
  33.    scheme for all interactions, (2) an authentication facility which can
  34.    be used both to verify messages and limit access to managed systems,
  35.    and (3) the ability to encrypt messages to protect sensitive
  36.    information.  These features are discussed in detail in the following
  37.    sections.
  38.  
  39. PROTOCOL OPERATION
  40.  
  41.    HEMP is designed to support messages; where a message is an
  42.    arbitrarily long sequence of octets.
  43.  
  44.    Five types of messages are currently defined: request, event, reply,
  45.    and protocol error, and application error messages.  Reply, protocol
  46.    error and application error messages are only sent in reaction to a
  47.    request message, and are referred to collectively as responses.
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Partridge & Trewitt                                             [Page 1]
  54.  
  55. RFC 1022                     HEMS Protocol                  October 1987
  56.  
  57.  
  58.    Two types of interaction are envisioned: a message exchange between
  59.    an application and an entity managed by the application, and
  60.    unsolicited messages from an entity to the management centers
  61.    responsible for managing it.
  62.  
  63.    When an application wants to retrieve information from an entity or
  64.    gives instructions to an entity, it sends a request message to the
  65.    entity.  The entity replies with a response, either a reply message
  66.    if the request was valid, or an error message if the request was
  67.    invalid (e.g., failed authentication).  It is expected that there
  68.    will only be one response to a request message, although the protocol
  69.    does not preclude multiple responses to a single request.
  70.  
  71.    Protocol error messages are generated if errors are found when
  72.    processing the HEMP encapsulation of the message.  The possible
  73.    protocol error messages are described later in this document.  Non-
  74.    HEMP errors (e.g., errors that occur during the processing of the
  75.    contents of the message) are application errors.  The existence of
  76.    application error messages does not preclude the possibility that a
  77.    reply will have an error message in it.  It is expected that the
  78.    processing agent on the entity may have already started sending a
  79.    reply message before an error in a request message is discovered.  As
  80.    a result, application errors found during processing may show up in
  81.    the reply message instead of a separate application error message.
  82.  
  83.    Note that in certain situations, such as on secure networks,
  84.    returning error messages may be considered undesirable.  As a result,
  85.    entities are not required to send error messages, although on
  86.    "friendly" networks the use of error messages is encouraged.
  87.  
  88.    Event messages are unsolicited notices sent by an entity to an
  89.    address, which is expected to correspond to one or more management
  90.    centers.  (Note that a single address may correspond to a multicast
  91.    address, and thus reach multiple hosts.)  Event messages are
  92.    typically used to allow entities to alert management centers of
  93.    important changes in their state (for example, when an interface goes
  94.    down or the entity runs out of network buffers).
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109. Partridge & Trewitt                                             [Page 2]
  110.  
  111. RFC 1022                     HEMS Protocol                  October 1987
  112.  
  113.  
  114. STANDARD MESSAGE FORMAT
  115.  
  116.    Every HEMP message is put in the general form shown in Figure 1.
  117.  
  118.                      +-------------------------------+
  119.                      :           leader              :
  120.                      +-------------------------------+
  121.                      :       encryption section      :
  122.                      +-------------------------------+
  123.                      :    reply encryption section   :
  124.                      +-------------------------------+
  125.                      :     authentication section    :
  126.                      +-------------------------------+
  127.                      :          common header        :
  128.                      +-------------------------------+
  129.                      :              data             :
  130.                      +-------------------------------+
  131.  
  132.                   Figure 1: General Form of HEMP Messages
  133.  
  134.    Each message has five components: (1) the leader, which is simply the
  135.    ASN.1 tag and message length; (2) the encryption section, which
  136.    provides whatever information the receiver may require to decrypt the
  137.    message; (3) the reply encryption section, in which the requesting
  138.    application may specify the type of encryption to use in the reply;
  139.    (4) the authentication section, which allows the receiver to
  140.    authenticate the message; (5) the common header, which identifies the
  141.    message type, the HEMP version, and the message id; and (6) the data
  142.    section.  All four sections following the leader are also ASN.1
  143.    encoded.  The ASN.1 format of the message is shown in Figure 2.
  144.  
  145.           HempMessage ::= [0] IMPLICIT SEQUENCE {
  146.               [0] IMPLICIT EncryptSection OPTIONAL,
  147.               [1] IMPLICIT ReplyEncryptSection OPTIONAL,
  148.               [2] IMPLICIT AuthenticateSection OPTIONAL,
  149.               [3] IMPLICIT CommonHeader,
  150.               [4] IMPLICIT Data }
  151.  
  152.                   Figure 2: ASN.1 Format of HEMP Messages
  153.  
  154.    The ordering of the sections is significant.  The encryption section
  155.    comes first so that all succeeding sections (which may contain
  156.    sensitive information) may be encrypted.  The authentication section
  157.    precedes the header so that messages which fail authentication can be
  158.    discarded without header processing.
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165. Partridge & Trewitt                                             [Page 3]
  166.  
  167. RFC 1022                     HEMS Protocol                  October 1987
  168.  
  169.  
  170. THE ENCRYPTION SECTION
  171.  
  172. Need For Encryption
  173.  
  174.    Encryption must be supported in any management scheme.  In
  175.    particular, a certain amount of monitoring information is potentially
  176.    sensitive.  For example, imagine that an entity maintains a traffic
  177.    matrix, which shows the number of packets it sent to other entities.
  178.    Such a traffic matrix can reveal communications patterns in an
  179.    organization (e.g., a corporation or a government agency).
  180.    Organizations concerned with privacy may wish to employ encryption to
  181.    protect such information.  Access control ensures that only people
  182.    entitled to request the data are able to retrieve it, but does not
  183.    protect from eavesdroppers reading the messages.  Encryption protects
  184.    against eavesdropping.
  185.  
  186.    Note that encryption in HEMP does not protect against traffic
  187.    analysis.  It is expected that HEMP interactions will have distinct
  188.    signatures such that a party which can observe traffic patterns may
  189.    guess at the sort of interactions being performed, even if the data
  190.    being sent is encrypted.  Organizations concerned with security at
  191.    this level should additionally consider link-level encryption.
  192.  
  193. Format of the Encryption Section
  194.  
  195.    The encryption section contains any data required to decrypt the
  196.    message.  The ASN.1 format of this section is shown in Figure 3.
  197.  
  198.           EncryptSection :: = IMPLICIT SEQUENCE {
  199.                 encryptType INTEGER,
  200.                 encryptData ANY
  201.           }
  202.  
  203.                 Figure 3: ASN.1 Format of Encryption Section
  204.  
  205.    If the section is omitted, then no decryption is required.  If the
  206.    section is present, then the encryptType field contains a number
  207.    defining the encryption method in use and encryptData contains
  208.    whatever data, for example a key, which the receiver must have to
  209.    decrypt the remainder of the message using the type of encryption
  210.    specified.
  211.  
  212.    Currently no encryption types are assigned.
  213.  
  214.    If the message has been encrypted, data is encrypted starting with
  215.    the first octet after the encryption section.
  216.  
  217.  
  218.  
  219.  
  220.  
  221. Partridge & Trewitt                                             [Page 4]
  222.  
  223. RFC 1022                     HEMS Protocol                  October 1987
  224.  
  225.  
  226. THE REPLY ENCRYPTION SECTION
  227.  
  228. Need for Reply Encryption
  229.  
  230.    The reasons for encrypting messages have already been discussed.
  231.  
  232.    The reply encryption section provides the ability for management
  233.    agents to request that responses be encrypted even though the
  234.    requests are not encrypted, or that responses be encrypted using a
  235.    different key or even a different scheme from that used to encrypt
  236.    the request.  A good example is a public key encryption system, where
  237.    the requesting application needs to pass its public key to the
  238.    processing agent.
  239.  
  240. Format of the Reply Encryption Section
  241.  
  242.    The reply encryption section contains any data required to encrypt
  243.    the reply message.  The ASN.1 format of this section is shown in
  244.    Figure 4.
  245.  
  246.           ReplyEncryptSection :: = IMPLICIT SEQUENCE {
  247.                 replyEncryptType INTEGER,
  248.                 replyEncryptData ANY
  249.           }
  250.  
  251.           Figure 4: ASN.1 Format of Reply Encryption Section
  252.  
  253.    If the section is omitted, then the reply should be encrypted in the
  254.    manner specified by the encryption section.  If the section is
  255.    present, then the replyEncryptType field contains a number defining
  256.    the encryption method to use and replyEncryptData contains whatever
  257.    data, for example a key, which the receiver must have to encrypt the
  258.    reply message.
  259.  
  260.    If the reply encryption section is present, then the reply message
  261.    must contain an appropriate encryption section, which indicates the
  262.    encryption method requested in the reply encryption section is in
  263.    use.  The reply message should be encrypted starting with the first
  264.    octet after the encryption section.
  265.  
  266.    If the reply encryption method requested is not supported by the
  267.    entity, the entity may not send a reply.  It may, at the discretion
  268.    of the implementor, send a protocol error message.  (See below for
  269.    descriptions of protocol error messages.)
  270.  
  271.    Currently no encryption types are assigned.
  272.  
  273.  
  274.  
  275.  
  276.  
  277. Partridge & Trewitt                                             [Page 5]
  278.  
  279. RFC 1022                     HEMS Protocol                  October 1987
  280.  
  281.  
  282. THE AUTHENTICATION SECTION
  283.  
  284. Need for Authentication
  285.  
  286.    It is often useful for an application to be able to confirm either
  287.    that a message is indeed from the entity it claims to have originated
  288.    at, or that the sender of the message is accredited to make a
  289.    monitoring request, or both.  An example may be useful here.
  290.    Consider the situation in which an entity sends a event message to a
  291.    monitoring center which indicates that a trunk link is unstable.
  292.    Before the monitoring center personnel take actions to re-route
  293.    traffic around the bad link (or makes a service call to get the link
  294.    fixed), it would be nice to confirm that the event was indeed sent by
  295.    the entity, and not by a prankster.  Authentication provides this
  296.    facility by allowing entities to authenticate their event messages.
  297.  
  298.    Another use of the authentication section is to provide access
  299.    control.  Requests demand processing time from the entity.  In cases
  300.    where the entity is a critical node, such as a gateway, we would like
  301.    to be able to limit requests to authorized applications.  We can use
  302.    the authentication section to provide access control, by only
  303.    allowing specially authenticated applications to request processing
  304.    time.
  305.  
  306.    It should also be noted that, in certain cases, the encryption method
  307.    may also implicitly authenticate a message.  In such situations, the
  308.    authentication section should still be present, but uses a type code
  309.    which indicates that authentication was provided by the encryption
  310.    method.
  311.  
  312. Format of the Authentication Section
  313.  
  314.    The authentication section contains any data required to allow the
  315.    receiver to authenticate the message.  The ASN.1 format of this
  316.    section is shown in Figure 5.
  317.  
  318.          AuthenticateSection :: = IMPLICIT SEQUENCE {
  319.                 authenticateType INTEGER,
  320.                 authenticateData ANY
  321.                }
  322.  
  323.  
  324.              Figure 5: ASN.1 Format of Authentication Section
  325.  
  326.    If the section is omitted, then the message is not authenticated.  If
  327.    the section is present, then the authenticateType defines the type of
  328.    authentication used and the authenticateData contains the
  329.    authenticating data.
  330.  
  331.  
  332.  
  333. Partridge & Trewitt                                             [Page 6]
  334.  
  335. RFC 1022                     HEMS Protocol                  October 1987
  336.  
  337.  
  338.    This memo defines two types of authentication, a password scheme and
  339.    authentication by encryption method.  For the password scheme, the
  340.    AuthenticateSection has the form shown in Figure 6.
  341.  
  342.          AuthenticateSection :: = IMPLICIT SEQUENCE {
  343.                 authenticateType INTEGER { password(1) },
  344.                 authenticateData OCTETSTRING
  345.           }
  346.  
  347.           Figure 6: ASN.1 Format of Password Authentication Section
  348.  
  349.    The authenticateType is 1, and the password is an octet string of any
  350.    length.  The system is used to validate requests to an entity.  Upon
  351.    receiving a request, an entity checks the password against an entity
  352.    specific password which has been assigned to the entity.  If the
  353.    passwords match, the request is accepted for processing.  The scheme
  354.    is a slightly more powerful password scheme than that currently used
  355.    for monitoring on the Internet.
  356.  
  357.    For authentication by encryption, the AuthenticateSection has the
  358.    format shown in Figure 7.
  359.  
  360.          AuthenticateSection :: = IMPLICIT SEQUENCE {
  361.                 authenticateType INTEGER { encryption(2) },
  362.                 authenticateData NULL
  363.           }
  364.  
  365.           Figure 7: ASN.1 Format of Encryption Authentication Section
  366.  
  367.    This section simply indicates that authentication was implicit in the
  368.    encryption method.  Recipients of such messages should confirm that
  369.    the encryption method does indeed provide authentication.
  370.  
  371.    No other authentication types are currently defined.
  372.  
  373.    If a message fails authentication, it should be discarded.  If the
  374.    type of authentication used on the message is unknown or the section
  375.    is omitted, the message may be discarded or processed at the
  376.    discretion of the implementation.  It is recommended that requests
  377.    with unknown authentication types be logged as potential intrusions,
  378.    but not processed.
  379.  
  380. THE COMMON HEADER
  381.  
  382.    The common header contains generic information about the message such
  383.    as the protocol version number and the type of request.  The ASN.1
  384.    format of the common header is shown in Figure 8.
  385.  
  386.  
  387.  
  388.  
  389. Partridge & Trewitt                                             [Page 7]
  390.  
  391. RFC 1022                     HEMS Protocol                  October 1987
  392.  
  393.  
  394.            CommonHeader ::= IMPLICIT SEQUENCE {
  395.                link IMPLICIT INTEGER,
  396.                messageType IMPLICIT INTEGER,
  397.                messageId IMPLICIT INTEGER,
  398.                resourceId ANY
  399.            }
  400.  
  401.  
  402.                   Figure 8: ASN.1 Format of Common Header
  403.  
  404.    The link indicates which version of HEMS is in use.
  405.  
  406.    The messageType is a value indicating whether the message is a
  407.    request (0), reply (1), event (2), protocol error (3) or application
  408.    error (4) message.
  409.  
  410.    The messageId is a unique bit identifier, which is set in the request
  411.    message, and echoed in the response.  It allows applications to match
  412.    responses to their corresponding request.  Applications should choose
  413.    messageIds such that a substantial period of time elapses before a
  414.    messageId is re-used by a particular application (even across machine
  415.    crashes).
  416.  
  417.    Event messages also use the messageId field to indicate the number of
  418.    the current event message.  By comparing messageId fields from events
  419.    lost, event values may be detected.  The event messageId should be
  420.    reset to 0 on every reboot, and by convention, the event message with
  421.    messageId of 0 should always be a "reboot" event.  (Facilities should
  422.    be provided in the event message definition to allow entities which
  423.    are capable of storing messageIds across reboots to send the highest
  424.    messageId reached before the reboot.)
  425.  
  426.    The resourceId is defined for ISO compatibility and corresponds to
  427.    the resource ID used by the Common Management Information Protocol to
  428.    identify the relevant ISO resource.
  429.  
  430. DATA SECTION
  431.  
  432.    The data section contains the message specific data.  The format of
  433.    the data section is shown in Figure 9.
  434.  
  435.                    Data ::= ANY
  436.  
  437.                   Figure 9: ASN.1 Format of Data Section
  438.  
  439.    The contents of the data section is application specific and, with
  440.    the exception of protocol error messages, is outside the scope of
  441.    this memo.
  442.  
  443.  
  444.  
  445. Partridge & Trewitt                                             [Page 8]
  446.  
  447. RFC 1022                     HEMS Protocol                  October 1987
  448.  
  449.  
  450. TRANSPORT PROTOCOL
  451.  
  452.    There has been considerable debate about the proper transport
  453.    protocol to use under HEMP.  Part of the problem is that HEMP is
  454.    being used for two different types of interactions:  request-response
  455.    exchanges and event messages.  Request-response interactions may
  456.    involve arbitrary amounts of data being sent in both directions, and
  457.    is believed to require a reliable transport mechanism.  Event
  458.    messages are typically small and need not be reliably delivered.
  459.  
  460.    Public opinion seems to lean towards running HEMP over a transaction
  461.    protocol (see RFC-955 for a general discussion).  Unfortunately, the
  462.    community is still experimenting with transaction protocols, and many
  463.    groups would like to be able to implement HEMP now.  Accordingly,
  464.    this memo defines two transport protocols for use with HEMP.
  465.  
  466.    Groups interested in using an implementation of HEMP and the HEMS in
  467.    the near future should use a combination of the Transmission Control
  468.    Protocol (TCP) and the User Datagram Protocol (UDP) under HEMP.  TCP
  469.    should be used for all request-response interactions and UDP should
  470.    be used to send event messages.  Using UDP to support the request-
  471.    response interactions is strongly discouraged.
  472.  
  473.    More forward looking groups are encouraged to implement HEMP over a
  474.    transaction protocol, in particular, experiments are planned with the
  475.    Versatile Message Transaction Protocol (VMTP).
  476.  
  477. PROTOCOL ERROR MESSAGES
  478.  
  479.    Protocol error messages are so closely tied to the definition of HEMP
  480.    that it made sense to define the contents of the data section for
  481.    protocol error messages in this memo, even though the data section is
  482.    generally considered application specific.
  483.  
  484.    The data section of all protocol error messages has the same format,
  485.    which is shown in Figure 10.  This format has been chosen to agree
  486.    with the error message format and ASN.1 type used for language
  487.    processing errors in RFC-1024, and the error codes have been chosen
  488.    such that they do not overlap.
  489.  
  490.            ProtocolError ::= [APPLICATION 0] implicit sequence {
  491.                protoErrorCode INTEGER,
  492.                protoErrorOffset INTEGER,
  493.                protoErrorDescribed IA5String,
  494.            }
  495.  
  496.             Figure 10: Data Section For Protocol Error Messages
  497.  
  498.  
  499.  
  500.  
  501. Partridge & Trewitt                                             [Page 9]
  502.  
  503. RFC 1022                     HEMS Protocol                  October 1987
  504.  
  505.  
  506.    The protoErrorCode is a number which specifies the particular type of
  507.    error encountered.  The defined codes are:
  508.  
  509.            0 - reserved <not used>
  510.  
  511.            1 - ASN.1 format error.  Some error has been encountered
  512.            in parsing the message.  Examples of such an error are an
  513.            unknown type or a violation of the ASN.1 syntax.
  514.  
  515.            2 - Wrong HEMP version number.  The version number in
  516.            the common header is invalid.  Note that this may
  517.            be an indication of possible network intrusion and
  518.            should be logged at sites concerned with security.
  519.  
  520.            3 - Authentication error.  Authentication has failed.
  521.            This error code is defined for completeness, but
  522.            implementations are *strongly* discouraged from using
  523.            it.  Returning authentication failure information may
  524.            aid intruders in cracking the authentication system.
  525.            It is recommended taht authentication errors be logged
  526.            as possible security problems.
  527.  
  528.            4 - ReplyEncryption type not supported.  The entity
  529.            does not support the encryption method requested in the
  530.            ReplyEncryption section.
  531.  
  532.            5 - Decryption failed.  The entity could not decrypt the
  533.            encrypted message.  Note that this means that the
  534.            entity could not read the CommonHeader to find the
  535.            messageId for the reply.  In this case, the messageId
  536.            field should be set to 0.
  537.  
  538.            6 - Application Failed.  Some application failure made it
  539.            impossible to process the message.
  540.  
  541.    The protoErrorOffset is the number of the octet in which the error
  542.    was discovered.  The first octet in the message is octet number 0.
  543.  
  544.    The protoErrorDescribed field is a string which describes the
  545.    particular error.  This description is expected to give a more
  546.    detailed description of the particular error encountered.
  547.  
  548. APPENDIX OF TYPES
  549.  
  550.    This section lists all ASN.1 types defined in this document.
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557. Partridge & Trewitt                                            [Page 10]
  558.  
  559. RFC 1022                     HEMS Protocol                  October 1987
  560.  
  561.  
  562.    HEMP Types
  563.  
  564.           HempMessage ::= [0] IMPLICIT SEQUENCE {
  565.               [0] IMPLICIT EncryptSection OPTIONAL,
  566.               [1] IMPLICIT ReplyEncryptSection OPTIONAL,
  567.               [2] IMPLICIT AuthenticateSection OPTIONAL,
  568.               [3] IMPLICIT CommonHeader,
  569.               [4] IMPLICIT Data }
  570.  
  571.        EncryptSection :: = IMPLICIT SEQUENCE {
  572.            encryptType INTEGER,
  573.            encryptData ANY
  574.        }
  575.  
  576.        ReplyEncryptSection :: = IMPLICIT SEQUENCE {
  577.            replyEncryptType INTEGER,
  578.            replyEncryptData ANY
  579.        }
  580.  
  581.  
  582.        AuthenticateSection :: = IMPLICIT SEQUENCE {
  583.            authenticateType INTEGER,
  584.            authenticateData ANY
  585.        }
  586.  
  587.  
  588.        CommonHeader ::= IMPLICIT SEQUENCE {
  589.            link IMPLICIT INTEGER,
  590.            messageType IMPLICIT INTEGER {
  591.                request(0), reply(1), event(2),
  592.                protocol error (3), application error(4)
  593.            }
  594.            messageId IMPLICIT INTEGER,
  595.            resourceId ANY
  596.        }
  597.  
  598.        Data ::= ANY
  599.  
  600. Protocol Error Types
  601.  
  602.        ProtocolError ::= [APPLICATION 0] implicit sequence {
  603.            protoErrorCode INTEGER,
  604.            protoErrorOffset INTEGER,
  605.            protoErrorDescribed OCTETSTRING
  606.        }
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613. Partridge & Trewitt                                            [Page 11]
  614.  
  615. RFC 1022                     HEMS Protocol                  October 1987
  616.  
  617.  
  618. REFERENCES
  619.  
  620.    ISO Standard ASN.1 (Abstract Syntax Notation 1).  It comes in two
  621.    parts:
  622.       International Standard 8824 -- Specification (meaning, notation)
  623.       International Standard 8825 -- Encoding Rules (representation)
  624.  
  625.    The current VMTP specification is available from David Cheriton of
  626.    Stanford University.
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669. Partridge & Trewitt                                            [Page 12]
  670.  
  671.