This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
Freelance translator and/or interpreter, Verified site user
Data security
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Source text - English SNMPv3 Applications
The services between modules in an SNMP entity are defined in the RFCs in terms of primitives and parameters. A primitive specifies the function to be performed, and the parameters are used to pass data and control information. We can think of these primitives and parameters as a formalized way of defining SNMP services. The actual form of a primitive is implementation dependent; an example is a procedure call. In the discussion that follows, it may be useful to refer to Fig. 4, based on a figure in RFC 2271, to see how all of these primitives fit together. Figure 4a shows the sequence of events in which a Command Generator or Notification Originator application requests that a PDU be sent, and subsequently how the matching response is returned to that application; these events occur at a manager. Figure 4b shows the corresponding events at an agent. The figure shows how an incoming message results in the dispatch of the enclosed PDU to an application, and how that application's response results in an outgoing message. Note that some of the arrows in the diagram are labeled with a primitive name, representing a call. Unlabeled arrows represents the return from a call, and the shading indicates the matching between call and return.
RFC 2273 defines, in general terms, the procedures followed by each type of application when generating PDUs for transmission or processing incoming PDUs. In all cases, the procedures are defined in terms of interaction with the Dispatcher by means of the Dispatcher primitives.
Command Generator Applications -- A command generator application makes use of the sendPdu and processResponsePdu Dispatcher primitives. The sendPdu provides the Dispatcher with information about the intended destination, security parameters, and the actual PDU to be sent. The Dispatcher then invokes the Message Processing Model, which in turn invokes the Security Model, to prepare the message. The Dispatcher hands the prepared message over to the transport layer (e.g., UDP) for transmission. If message preparation fails, the return primitive value of the sendPdu, set by the Dispatcher, is an error indication. If message preparation succeeds, the Dispatcher assigns a sendPduHandle identifier to this PDU and returns that value to the command generator. The command generator stores the sendPduHandle so that it can match the subsequent response PDU to the original request.
The Dispatcher delivers each incoming response PDU to the correct command generator application, using the processResponsePdu primitive.
Command Responder Applications -- A command responder application makes use of four Dispatcher primitives (registerContextEngineID, unregisterContextEngineID, processPdu, returnResponsePdu), and one Access Control Subsystem primitive (isAccessAllowed).
The registerContextEngineID primitive enables a command responder application to associate itself with an SNMP engine for the purpose of processing certain PDU types for a context engine. Once a command responder has registered, all asynchronously received messages containing the registered combination of contextEngineID and pduType supported are sent to the command responder that registered to support that combination. A command responder can disassociate from an SNMP engine using the unregisterContextEngineID primitive.
The Dispatcher delivers each incoming request PDU to the correct command responder application, using the processPdu primitive. The command responder then performs the following steps:
1. The command responder examines the contents of the request PDU. The operation type must match one of the types previously registered by this application.
2. The command responder determines if access is allowed for performing the management operation requested in this PDU. For this purpose, the isAccessAllowed primitive is called. The securityModel parameter indicates which security model the Access Control Subsystem is to use in responding to this call. The Access Control Subsystem determines if the requesting principal (securityName) at this security level (securityLevel) has permission to request the management operation (viewType) on the management object (variableName) in this context (contextName).
3. If access is permitted, the command responder performs the management operation and prepares a response PDU. If access fails, the command responder prepares the appropriate response PDU to signal that failure.
4. The command responder calls the Dispatcher with a returnResponsePdu primitive to send the response PDU.
Notification Generator Applications -- A notification generator application follows the same general procedures used for a command generator application. If an Inform Request PDU is to be sent, both the sendPdu and processResponsePdu primitives are used, in the same fashion as for command generator applications. If a trap PDU is to be sent, only the sendPdu primitive is used.
Notification Receiver Applications -- A notification receiver application follows a subset of the general procedures as for a command responder application. The notification receiver must first register to receive Inform and/or trap PDUs. Both types of PDUs are received by means of a processPdu primitive. For an Inform PDU, a returnResponsePdu primitive is used to respond.
Proxy Forwarder Applications -- A proxy forwarder application makes use of Dispatcher primitives to forward SNMP messages. The proxy forwarder handles four basic types of messages:
• Messages containing PDU types from a command generator application. The proxy forwarder determines either the target SNMP engine or an SNMP engine that is closer, or downstream, to the target, and sends the appropriate request PDU.
• Messages containing PDU types from a notification originator application. The proxy forwarder determines which SNMP engines should receive the notification and sends the appropriate notification PDU or PDUs.
• Messages containing a Response PDU type. The proxy forwarder determines which previously forwarded request or notification, if any, is matched by this response, and sends the appropriate response PDU.
• Messages containing a report indication. Report PDUs are SNMPv3 engine-to-engine communications. The proxy forwarder determines which previously forwarded request or notification, if any, is matched by this report indication, and forwards the report indication back to the initiator of the request or notification.
Message Processing and the User Security Model
Message processing involves a general-purpose message processing model and a specific security model; this relationship is shown in Fig. 4.
Message Processing Model
RFC 2272 defines a general-purpose message processing model. This model is responsible for accepting PDUs from the Dispatcher, encapsulating them in messages, and invoking the USM to insert security-related parameters in the message header. The message processing model also accepts incoming messages, invokes the USM to process the security-related parameters in the message header, and delivers the encapsulated PDU to the Dispatcher.
Figure 5 illustrates the message structure. The first five fields are generated by the message processing model on outgoing messages and processed by the message processing model on incoming messages. The next six fields show security parameters used by USM. Finally, the PDU, together with the contextEngineID and contextName constitute a scoped PDU, used for PDU processing.
The first five fields are:
msgVersion: Set to snmpv3(3).
msgID: A unique identifier used between two SNMP entities to coordinate request and response messages, and by the message processor to coordinate the processing of the message by different subsystem models within the architecture. The range of this ID is 0 through 231¬1.
msgMaxSize: Conveys the maximum size of a message in octets supported by the sender of the message, with a range of 484 through 231¬1. This is the maximum segment size that the sender can accept from another SNMP engine (whether a response or some other message type).
msgFlags: An octet string containing three flags in the least significant three bits: reportableFlag, privFlag, authFlag. If reportableFlag = 1, then a Report PDU must be returned to the sender under those conditions that can cause the generation of a Report PDU; when the flag is zero, a Report PDU may not be sent. The reportableFlag is set to 1 by the sender in all messages containing a request (Get, Set) or an Inform, and set to 0 for messages containing a Response, a Trap, or a Report PDU. The reportableFlag is a secondary aid in determining when to send a Report. It is only used in cases in which the PDU portion of the message cannot be decoded (e.g., when decryption fails due to incorrect key). The privFlag and authFlag are set by the sender to indicate the security level that was applied to the message. For privFlag = 1, encryption was applied and for privFlag = 0, authentication was applied. All combinations are allowed except (privFlag = 1 AND authFlag = 0); that is, encryption without authentication is not allowed.
msgSecurityModel: An identifier in the range of 0 through 231¬1 that indicates which security model was used by the sender to prepare this message and therefore which security model must be used by the receiver to process this message. Reserved values include 1 for SNMPv1, 2 for SNMPv2c, and 3 for SNMPv3.
Translation - Spanish APLICACIONES DEL SNMPv3
Según las RFC, los servicios intermodulares de las entidades SNMP se definen como primitivas y parámetros. Las pri-mitivas especifican la función que se debe efectuar y los parámetros se emplean para remitir datos e información de con-trol. Las primitivas y los parámetros mencionados se podrían considerar formas de definir servicios de SNMP. La forma real de las primitivas depende de la implementación; un ejemplo son las llamadas de procedimiento. Para lo que vamos a explicar a continuación, será de utilidad consultar la Ilustración 4, basada en otra de la RFC 2271, de forma que se aprecie el modo en que estas primitivas se articulan. En (a) se muestra la secuencia de eventos, a nivel de administradores, que motivan la solicitud del envío de una PDU por el Generador de comandos o el Creador de notificaciones; después se mues-tra la forma en que se devuelve a esa aplicación la respuesta correspondiente. En (b) se aprecian los eventos correspon-dientes a nivel de agentes. Se muestra la manera en que los mensajes entrantes dan lugar a la distribución de la PDU adjun-ta hacia las aplicaciones y cómo la respuesta de estas origina mensajes salientes. Observe que algunas de las flechas del diagrama, que representan llamadas, están etiquetadas con un nombre primitivo. Las flechas que carecen de etiqueta re-presentan devoluciones de llamada y el sombreado indica la coincidencia entre llamada y devolución.
La RFC 2273 define a grandes rasgos los procedimientos seguidos por cada tipo de aplicación al generar PDU para la transmisión o al procesar PDU entrantes. En cualquiera de los casos, los procedimientos se definen atendiendo a la interac-ción con el Distribuidor por medio de las primitivas de este.
APLICACIONES DE GENERADOR DE COMANDOS. Estas aplicaciones utilizan primitivas del Dis-tribuidor de sendPdu y de processResponsePdu. Este recibe de sendPdu información relativa al destino y parámetros de seguridad deseados y a la PDU que se debe enviar. El Distribuidor invoca al Modelo de procesamiento de mensajes, que a su vez invoca al Modelo de seguridad, para preparar el mensaje. El Distribuidor cede el mensaje preparado a la capa de transporte (por ejemplo, UDP) para que sea transmitido. Si la preparación del mensaje falla, el valor primitivo de devolu-ción de sendPDU, configurado por el Distribuidor, indica la comisión de un error. Si la preparación del mensaje es satis-factoria, el Distribuidor asigna un identificador sendPduHandle a esta PDU y devuelve ese valor al generador de comandos. Este almacena el sendPduHandle de modo que haga coincidir la PDU de respuesta posterior con la solicitud original.
El Distribuidor entrega cada PDU Response entrante a la aplicación adecuada de Generador de comandos mediante la primitiva processResponsePdu.
APLICACIONES DE CONTESTADOR DE COMANDOS. Estas aplicaciones utilizan cuatro primiti-vas del Distribuidor (registerContextEngineID, unregisterContentxtEngineID, processPdu, returnResponsePdu) y una primitiva del Subsistema de control de acceso (isAccessAllowed).
La primitiva registerContextEngineID permite que las aplicaciones de Contestador de comandos se asocien con un motor SNMP con el objetivo de procesar determinados tipos de PDU para un motor de contexto. Una vez registrado el Con-testador de comandos, se envían todos los mensajes asíncronos recibidos que incluyan la combinación registrada de con-textEngineID y pduType admitidas al Contestador de comandos que se registro para admitir dicha combinación. Es posi-ble que los contestadores de comandos se desvinculen de un motor SNMP por medio de la primitiva unregisterContextEn-gineID.
El Distribuidor entrega cada PDU Request entrante a la aplicación apropiada del Contestador de comandos mediante la primitiva processPdu. El Contestador de comandos sigue entonces los pasos siguientes:
1. Examina el contenido de la PDU Request. El tipo de operación debe coincidir con alguno de los tipos que esta aplicación registró antes.
2. Decide si se concede el acceso para realizar la operación de administración requerida en esta PDU. Con este fin, se invoca a la primitiva isAccessAllowed. El parámetro securityModel indica qué modelo de seguridad debe uti-lizar el Subsistema de control de acceso para responder a esta llamada. Este subsistema determina si el principal solicitante (securityName) dispone de autorización en este nivel de seguridad (securityLevel) para requerir la operación de administración (viewType) sobre el objeto de administración (variableName) en este contexto (contextName).
3. Si se concede el acceso, efectúa la operación de administración y prepara una PDU Response. En caso contrario, el contestador prepara la PDU Response pertinente para señalar el fallo.
4. Llama al Distribuidor por medio de la primitiva returnResponsePdu para enviar la PDU de respuesta.
APLICACIONES DE CREADOR DE NOTIFICACIONES. Estas aplicaciones siguen el mismo proce-dimiento empleado para las aplicaciones de Generador de comandos. Si se envía una PDU Inform de respuesta, se utilizan las primitivas sendPdu y processResponsePdu de la misma forma que con las aplicaciones de Generador de comandos. Si se envían PDU Trap, solo se emplea la primitiva sendPdu.
APLICACIONES DE RECEPTOR DE NOTIFICACIONES. Estas aplicaciones siguen un subconjunto de los procedimientos generales de igual forma que las aplicaciones de Contestador de comandos. El Receptor de notifica-ciones debe en primer lugar registrarse para recibir PDU Inform, PDU Trap o ambas. Ambos tipos de PDU se reciben por medio de las primitivas processPdu. En el caso de PDU Inform, se emplean primitivas returnResponsePdu para responder.
APLICACIONES DE REENVIADOR DE PROXYS. Estas aplicaciones utilizan primitivas del Distribui-dor para reenviar mensajes SNMP. El reenviador de proxys controla cuatro tipos de mensaje básicos:
• Mensajes que contengan tipos de PDU provenientes de aplicaciones de Generador de comandos. El reenviador determina el motor SNMP de destino o un motor SNMP que sea próximo, o indirecto, al destino y envía la perti-nente PDU de solicitud.
• Mensajes que contengan tipos de PDU provenientes de aplicaciones de Creador de notificaciones. El reenvia-dor determina qué motores SNMP deben recibir la notificación y envía las pertinentes PDU de notificación.
• Mensajes que contengan el tipo PDU Response. El reenviador determina qué notificación o solicitud reenvia-das antes, si las hubiera, coinciden con esta respuesta y envía la pertinente PDU Response.
• Mensajes que contengan indicaciones de informe. Las PDU Report constituyen las comunicaciones entre mo-tores del SNMPv3. El reenviador determina qué notificación o solicitud reenviadas antes, si las hubiera, coin-ciden con esta indicación de informe y reenvía esta última al iniciador de la notificación o de la solicitud.
MODELOS DE PROCESAMIENTO DE MENSAJES Y DE SEGURIDAD DE USUARIO
El procesamiento de mensajes requiere un modelo de procesamiento de mensajes genérico y un modelo de seguridad específico. Esta relación se muestra en la Ilustración 4.
MODELO DE PROCESAMIENTO DE MENSAJES
La RFC 2272 establece un modelo de procesamiento de mensajes genérico. La función de este es aceptar PDU prove-nientes del Distribuidor, encapsularlas en mensajes e invocar al USM para introducir parámetros relativos a la seguridad en la cabecera del mensaje. Asimismo, este modelo acepta mensajes entrantes, invoca al USM para procesar los parámetros relativos a la seguridad en la cabecera del mensaje y entrega la PDU encapsulada al Distribuidor.
En la Ilustración 5 se explica la estructura de mensaje. Los cinco primeros campos los genera el modelo de procesa-miento de mensajes sobre mensajes salientes y los procesa el modelo de procesamiento de mensajes sobre mensajes en-trantes. Los seis campos siguientes muestran los parámetros que emplea el USM. Por último, la PDU, junto con el contex-tEngineID y contextName, conforman scopedPDU para procesar PDU. Los cinco campos son estos:
msgVersion. Establecido en SNMPv3 (3).
msgID. Identificador único utilizado tanto por dos entidades SNMP en la coordinación de mensajes de solicitud y de respuesta como por el procesador de mensajes en la coordinación del procesamiento de los mensajes efectuado por diferentes modelos de subsistema dentro de la arquitectura. El rango de este identificador es de 0 a 231 ¬ 1, am-bos inclusive.
msgMaxSize. Señala en octetos el tamaño máximo de mensajes admitido por el remitente del mensaje; su rango es de 484 a 231 ¬ 1, ambos inclusive. Este es el tamaño de segmento máximo que el remitente acepta de otro motor SNMP (ya sea un mensaje de respuesta o de cualquier otro tipo).
msgFlags. Cadena de octetos que incluye tres indicadores en los tres bits menos significativos: reportable-Flag, privFlag y authFlag. Si el valor de reportableFlag es 1, una PDU Report debe ser devuelta al remitente según las condiciones que motivan la generación de PDU Report; cuando el valor del indicador (flag) es cero, es posible que la PDU Report no se envíe. El remitente establece el valor del indicador reportableFlag en 1 en todos los mensajes que incluyan una petición (Get, Set) o un Inform, y en 0 para los mensajes que contengan PDU Response, PDU Trap o PDU Report. El indicador reportableFlag constituye una ayuda secundaria para determinar cuándo enviar un Re-port. Solo se utiliza en aquellos casos en que la parte PDU del mensaje no se puede descodificar (por ejemplo, cuando fracasa el cifrado debido a una clave incorrecta). El remitente establece los valores de privFlag y authFlag para indicar el nivel de seguridad aplicado al mensaje. Si el valor de privFlag es 1, se aplicó cifrado; si el valor es 0 se aplicó autenticación. Se permiten todas las combinaciones, excepto (privFlag = 1 y authFlag = 0); es decir, no se permite cifrado sin autenticación.
msgSecurityModel. Identificador, cuyo rango está entre 0 y 231 ¬ 1, ambos inclusive, que especifica el modelo de seguridad que empleó el remitente en la preparación de este mensaje y, por tanto, especifica también qué modelo de seguridad debe emplear el receptor en el procesamiento de este mensaje. Los valores reservados incluyen 1 (pa-ra SNMPv1), 2 (para SNMPv2c) y 3 (para SNMPv3).
More
Less
Translation education
Master's degree - Universidad de Granada - Facultad de Traducción e Interpretación
Experience
Years of experience: 19. Registered at ProZ.com: May 2005.
Associate of the Institute of Translation and Interpreting, ASETRAD
Software
Adobe Acrobat, Catalyst, DejaVu, FrameMaker, Microsoft Excel, Microsoft Word, Passolo, Powerpoint, SDLX, Trados Studio, Translation Workspace, Wordfast
Bio
Banking, Finance, Taxation and Duty
Business and Commerce
Legal documents and contracts
Localisation/Computers and IT
Proofreading
Software Manuals
Sworn translation
Software testing
Technical Documentation
Expertise