Y APROBADA PO L SIGUIENTE COMITE
benchuchñflDirector del Comiié `
¿If-S
//2
Dr. Alain J eneveau Dr. Franc' co Javier Ocampo Torres
Miembro del Comité Miembro del Comite'
5
\
«í-ÍI ¿I
Dr. Ciro Ap*/_ 4_¿¡_ÍfIÍ1É4z-B);I1ìÍâ>Moreno M.C. Emesto Eduardo Q iroz Morones
Mie bro del Comite' Miembì' Comite'
Q/-//` Í)/Z;
,,, Q 1 /ÓQ'/C / 41
Dr. Enrique Mitrani Abenchuchan (Úra. Ma. Luisa Argote/E/spínoza jefe delDepanfamento de Electrónicay Director de Estudios de Posgrado
Telecomunicaciones
DIVISION DE FISICA APLICADA
DEPARTAMENTO DE
ELECTRONICA Y TELECOMUNICACIONES
PUESTA EN MARCHA DE UN MEDIO AMBIENTE DE
ADMINISTRACION DE RED CON EL PROTOCOLO
ISODE/SNMPV2 Y REALIZACION DE UNA APLICACION
DE GESTION
TESIS
Que para cubrir parcialmente los requisitos necesarios
para obtener el grado de Maestro en Ciencias presenta
ISMAEL ALBERTO ALVARADO ALEMAN
PUESTA EN MARCHA DE UN MEDIO AMBIENTE DE ADMINISTRACION DE
RED CON EL PROTOCOLO 1sODE/sNM1>v2 Y REALIZACION DE UNA
APLICACION DE GESTION.
Resumen aprobado por:
Enrique Milrani A. Director de tesis.
En este trabajo se analiza el desempeño del protocolo SN`MPv2. Este protocolo simple de manejo de red, en su versión 2 (SNMPv2), es un protocolo de aplicación que ofrece los servicios de manejo de red al modelo de protocolos de Intemet (TCP/IP) por medio de una relación cliente/servidor.
El trabajo se realizó en varias etapas: estudio del medio ambiente del protocolo, puesta en marcha de los dispositivos del mismo y resultados.
La primera fase presenta una introducción general de la administración de redes, principalmente las redes del modelo de TCP/IP y su protocolo de gestión SNMP. La segunda fase, presenta una plataforma de gestión de red, ISODE (ISO Development Environment), esta plataforma incluye el protocolo SNMP en sus versiones l y 2, así como todas las herramientas necesarias para la realización de un prototipo de administración de red con el protocolo y todo su medio ambiente de gestión. Esta etapa resulta interesante desde el punto de vista de interconexión de redes abiertas y principalmente, en lo relacionado al desempeño del protocolo en este tipo de redes ya que por los resultados obtenidos, se validan los dispositivos de seguridad del modelo administrativo del protocolo. La última etapa, muestra los resultados y conclusiones del trabajo, es decir, la realización de una aplicación de administración para monitoreo por medio de una interfaz X Window, obteniendo los resultados esperados. Al final, se realizó un estudio del comportamiento del manejador realizando las operaciones del protocolo con y sin mecanismos de seguridad. Los resultados obtenidos muestran un ligero consumo de recursos (CPU) en el manejador usando los mecanismos de seguridad; sin embargo, se considera un factor despreciable tomando en cuenta el nivel de seguridad ofiecido por medio del protocolo.
IMPLEMENTATION OF A NETWORK MANAGEMENT ENVHIONMENT WITH THE ISODE/SNMPV2 PROTOCOL AND DEVELOPMENT OF A MANAGEMENT
APPLICATION.
Aprovved by ZI“iiIi`/B'
Enrique Mitrani A. Director de tesis
On this work the performance of the protocol SNMPv2 is presented. The Simple Network
Management Protocol version 2 is an application protocol which offers network
management services to the suite of Intemet protocols (model TCP/IP) by a Client/Sen/er relationship.
This work was divided on the folowing stages: study of protocol environment, protocol devices initialization (setting up) and the results.
At the beginning is presented an introduction about network management focusing on the networks of the TCP/IP model and its management protocol SNMP. Then a management network ISODE platform is shown. This platfonn includes SNMP version 1 and 2, as well as all the tools needed for the implementation of a network management prototype and its management environment. This stage is interesting from the point of view of the open networks interconections and mainly in the protocol performance in this type of networks. Based on the results obtained, the security devices of protocol administrative model are also evaluated. In the last part of this work there are shown the results and conclusions obtained, between them the implementation of a management application for monitoring via a X Window interface and a behavior analis of the manager employing the protocol with and without security mechanisms. The results show a little increase in the use of resources (CPU) by the driver when the security mechanisms are employed. However, this factor is considered negligible because of the security level offered by the protocol.
The perfonnance of the management prototype implemented is in good agreement with the theory. As the SNl\/[P protocol has a lack of security mainly by its limited resources, it has been developed the Sl\H\/IPv2. We can infer that the SNMPv2 is a quality tool for network
A mis padres:
Ismael Alvarado Durón y Ma. Esthela Alemán de A., les dedico este trabajo por el gran apoyo incondicional que me han brindado...ayer, ahora y siempre, gracias; los quiero
mucho.
A mi novia:
Myrthala González Cepeda, gracias por el apoyo, el amor y la comprensión que me brindaste y que hicieron posible lo realización de este trabajo, TE AMO.
A mis hermanos, familiares y amigos:
Luis, Andrés, Femando y Rolando... Luis Felipe y Carlos.
A lasfamilias González Alemán, González Cepeda, Martínez González y Delgado González...
A los miembros del comité de tesis, por sus comentarios y correcciones al manuscrito, en especial agradezco al Dr. Enrique ll/Iitrani por su colaboración y sus consejos durante el desarrollo de este trabajo.
Á M Alain JENEVEA Upour son acueil en France et sa disponibilité.
Á Mme. Dominique SERET pour m 'oflrir l 'opportunité de realiser cette expérience a l'ENSTÍ
Á M. Bruno .ÍOA CHIM' merci de votre implication, vos idées et de votre générosité.
Ainsi que á toutes les personnes du départament de réseaux pour l'attention qu 'ils m 'ont portée et pour la bienveillance avec laquelle m 'ont re çue
A todos mis profesores, compañeros y amigos, porque gracias a ellos he podido culminar este trabajo.
A “NUESTRA GENERACIÓN” por todos los momentos gratos que viví a su lado... por todo ese tiempo que compartimos a lo largo de todo la Maestría.
A mis amigos: Violaine Bouveresse fla güera), Horacio Martínez (Horazio), Miguel Martínez. (mike), II/figuel Cota (elflaco), Rene Betancourt, Héctor Mejía y Arturo Arvizu.
1. INTRODUCCIÓN
11. ANTECEDENTES
II.l La administración de redes abiertas II. 1 .1 Heterogeneidad en la interconexión II. 1.2 Multiplicidad de las organizaciones II. 1.3 El modelo de Intemet: TCP/IP II.2 El protocolo SNMP y su evolución.
II.2.l Medio ambiente del protocolo SNMP II.2.2 El nuevo modelo: SNMPv2
II.3 Un resumen de SNMPv2 II.3.1 Los contextos II.3.2 La autorización
II.3.3 La autentificación y la privacidad
II.3.3.1 El algoritmo de autentificación (MD5)
II.3.3.2 Algoritmo de encriptación simétrico (DES, Data Encryption Std.) II.3.4 Un control de acceso
II.3.5 Un modelo de seguridad
11.3 .6 Relación por procuración para el manejo de la información (proxy agents) H.4 Componentes del protocolo SNMPv2 en la administración de redes
II.4.1 Entidad SNMPv2
II.4.2 Agente SNMPv2 II.4.3 Manejador SNMPv2
II.4.4 Entidad SNMPv2 en doble papel
114.5 Panes SNMPv2 (party SNMPv2)
II.4.6 La vista de la MIB H.4.7 Contexto SNMPv2
II.4.7.1 Contexto local SNMPv2
II.4.7.2 Contexto SNMPv2 por procuración H.4.8 Operaciones del protocolo SN1\/[Pv2
II.4.8.1 El contenido de un mensaje PDU (Protocol Data Unit) II.4.9 La politica de control de acceso
IV. RESULTADOS
IV.l Análisis de resultados IV.2 Pruebas propuestas
v. CoNCLUs1óN
LITERATURA CITADA
APENDICE
Apéndice A: la platafomia ISODE
Apéndice B: la realización de una aplicación de administración de red Apéndice C: programas y bases de datos del sistema
35 38 39
41
44
Figura
1.
2.
3.
4.
5.
El medio ambiente del protocolo SNMPv2.
El modelo Cliente/Servidor del protocolo SNMPv2. Las operaciones del protocolo SN1\/[Pv2.
La plataforma de gestión de ISODE y sus herramientas.
Configuración Manejador y agentes en la red dorsal de la ENST, Paris.
ll
13
25
30
Tablas
I. Tiempo de respuesta y CPU consumido por operaciones de SNMPv2. II. Relación de carga/máquina contra tiempo (promedios).
III. Resultados finales de tasa de carga, duración y consumo del evento;
37
38
I. INTRODUCCIÓN
Al inicio de la era de las comunicaciones entre computadoras, intercambiar información de manera confiable entre una estación central y una terminal distante era una verdadera aventura. A finales de los años 70s, la tecnología evolucionó y las redes de terminales se convirtieron en redes de computadoras: para comunicarse, las computadoras estaban enlazadas a una misma red por la técnica de comnutación de paquetes. A mediados de los años 80s, diversos factores económicos y tecnológicos pemútieron interconectar redes con características diferentes.
Esta interconexión consiste en enlazar varias redes entre ellas por medio de equipos especializados. Estos, (nomialmente enrutadores o pasarelas) están dotados de protocolos de interconexión utilizados para disfiazar todos los detalles y aspectos fisicos subyacentes y ofrecer un servicio de red uniforme.
metropolitana, que puede ser considerada como una red simple desde el punto de vista de una regional, puede estar formada por varias redes fisicas ' entrelazadas por equipos de interconexión tales como repetidores, puentes u otros enrutadores. Si la utilización de repetidores (a nivel fisico) y de puentes (a nivel de enlace de datos) permite ver a varios se mentos 2 como una sola red fisica,S Puede ser favorable dividir la red metro olitana enP varias sub-redes intemas para separar el tráfico local.
Cada red fisica se apoya sobre diversas tecnologías (Ethemet, Token-ring, X.25, etc.) de acuerdo a sus propias reglas y protocolos de comunicación. Todas las computadoras enlazadas a estas redes tienen una visión común de red. Esto constituye el más poderoso concepto de la interconexión. Gracias a la utilización de protocolos y de algoritmos comunes, la topología de red más compleja, constituida de una multitud de tecnologias diferentes, puede ser percibida como una simple red fisica homogénea.
La tecnología de interconexión por excelencia es aquella relativa a la familia de protocolos de Intemet, comúnmente conocida como <la red Internet>. Los primeros trabajos sobre la familia Intemet fueron llevados a cabo por la Agencia para los Proyectos de Investigación Avanzada del Ministerio de La Defensa de los Estados Unidos, la DARPA
1. En el presente escrito hablaremos de red física para referirnos o detallar aspectos fisicos de las redes, según
lo indica [Rose. 1995].
2. Una red fisica puede tener varios segmentos enlazados entre ellos por repetidores. Para Ethernet 4
(del inglés, Defense Advanced Research Project Agency). El objetivo de la tecnología de interconexión es crear una red virtual única, independiente de toda tecnología.
II. ANTECEDENTES
En este capitulo se describe todo lo referente al entorno del protocolo SNMPv2. Se mencionan los puntos más importantes tales como: el medio ambiente donde se desempeña el protocolo, algunos conceptos de la administración de red, los conceptos del protocolo SNMPv2, los componentes de la platafomia ISODE versión 8, etcétera. El método de estudio consiste en evaluar y validar los dispositivos de seguridad del protocolo SNMPv2 en algunas interconexiones de red. Después, hacer una evaluación en relación a su manera de trabajo y su efectividad en la administración de redes.
lI.l La administración de redes abiertas
La necesidad de una tecnologia de red estandarizada es conocida desde hace mucho tiempo. Las computadoras deben de adoptar un grupo común de reglas para efectuar sus interacciones y estas reglas están consignadas en un protocolo. Los protocolos utilizados en un mismo medio ambiente de trabajo y manejados por una entidad común constituyen una familia de protocolos. Por lo tanto, si esa familia de protocolos es independiente del equipo y de sus respectivos fabricantes, se dice que es una tecnología de red abierta.
H.l.l Heterogeneidad en la interconexión
Interconectar redes implica la participación de diferentes tipos de equipo, de diferentes fabricantes y diferentes tecnologias de red. Aun asi, la mayoria de los equipos son generalmente heterogéneos. Como la red Intemet está formada en base a este concepto, es necesario un manejo óptimo para este tipo de redes heterogéneas.
Como se sabe, una red es una interconexión de sub-redes y una sub-red esta definida por una arquitectura unificada y un plan de direccionamiento: todos los equipos de comunicación y sus dispositivos de programática deben permitir al usuario ver la red de manera transparente, es decir, trabajar de manera óptima sobre la red sin importar la mecamátìca. Por lo tanto, se recomienda seguir una metodología para analizar la arquitectura de cada componente de red a fin de reducir sus diferencias en términos de protocolos, de servicios y de mecanismos. Por otro lado, definir sus funcionalidades y los mecanismos que habrá que incluir en los equipos para poder interconectar las sub-redes. Podemos mencionar las principales etapas de la metodologia de interconexión de red: 0 Estudio de la red de transporte: es necesario definir el tipo de red O sub-redes
dependiendo de la calidad de servicio requerido para las aplicaciones
0 Definición de las unidades de interfuncionalidad: es decir, hasta qué punto, el O los equipos pueden interconectarse. Es necesario definir las fronteras de interconexión [Gagnaire, 1994].
lI.l.2 Multiplicidad de las organizaciones
La interconexión permite a varias redes, cuyo tamaño y vocación es diferente, una cooperación entre sus diferentes medios de comunicación para alcanzar un óptimo rendimiento. Tratar exhaustivamente del manejo y la administración de red necesita cubrir todos los aspectos de la administración e interconexión de redes multiprotocolos, tanto desde el punto de vista técnico como el de la organización. Para cualquier información más detallada respecto a redes y tópicos de comunicación en servicios de Intemet, el lector podrá tener una amplia referencia en Quaterman [1995] que ofrece una excelente presentación a la administración de redes.
Esta tesis no cubre sino algunas técnicas en la administración de red. Sobre todo, se aborda el medio ambiente de un protocolo que es la herramienta principal para la administración de las redes del modelo de TCP/IP. Si el lector requiere de información respecto a otro tipo de problemas en la administración, la siguiente fuente bibliográfica le ofrecerá más información : Leinwand [l994], revista gratuita bimensual de la tecnologia
SNMP.
II.l.3 El modelo de Internet: TCP/IP
Para los propósitos de este estudio, consideramos las cuatro capas del modelo 1 1. La < capa interfaz > que describe las técnicas del nivel fisico y del nivel de enlace de
datos. Estos niveles son utilizados para efectuar las transmisiones sobre los diversos medios de comunicación.
2. La < capa Intemet > que describe la técnica utilizada para realizar el concepto de interconexión de redes.
3. La < capa de transporte > que describe las técnicas utilizadas para asegurar una comunicación confiable de extremo a extremo.
4. La < capa de aplicación > que incluye las técnicas para ofrecer los servicios a los usuarios finales.
La característica principal de la familia de protocolos de Intemet es relativa a la interconexión de redes utilizando técnicas del nivel fisico diferentes. La generación actual de estos protocolos de comunicación se basa esencialmente sobre :
0 Un servicio de transporte en modo conexión (o conectado) asegurado por el protocolo de transmisión (del inglés, Transmission Control Protocol, TCP). 0 Un servicio de interconexión de redes en modo sin conexión (O no conectado)
asegurado por el protocolo Intemet (del inglés, Intemet Protocol, IP).
Existen varios protocolos de aplicación que son utilizados en el medio ambiente del modelo de Intemet :
Para los propósitos de este estudio, consideramos las cuatro capas del modelo : 1. La < capa interfaz > que describe las técnicas del nivel fisico y del nivel de enlace de
datos. Estos niveles son utilizados para efectuar las transmisiones sobre los diversos medios de comunicación.
2. La < capa Internet > que describe la técnica utilizada para realizar el concepto de interconexión de redes.
3. La < capa de transporte > que describe las técnicas utilizadas para asegurar una comunicación confiable de extremo a extremo.
4. La < capa de aplicación > que incluye las técnicas para ofrecer los servicios a los usuarios finales.
La característica principal de la familia de protocolos de Intemet es relativa a la interconexión de redes utilizando técnicas del nivel fisico diferentes. La generación actual de estos protocolos de comunicación se basa esencialmente sobre :
0 Un servicio de transporte en modo conexión (o conectado) asegurado por el protocolo de transmisión (del inglés, Transmission Control Protocol, TCP). 0 Un servicio de interconexión de redes en modo sin conexión (O no conectado)
asegurado por el protocolo Intemet (del inglés, Intemet Protocol, IP).
Existen varios protocolos de aplicación que son utilizados en el medio ambiente del modelo de Intemet :
0 El protocolo TELNET (del inglés, Terminal Network) que asegura los servicios de terminal virtual.
0 El Sistema de Nombre de Dominios (del inglés, Domain Name System, DNS) que asegura, que efectivamente los nombres de las máquinas correspondan con sus direcciones de red.
0 El Protocolo Simple de Manejo de Red (del inglés, Simple Network Management Protocol, SNMP) que es el objeto de estudio de esta tesis.
Una interconexión de redes contiene, como hemos señalado, varios tipos de redes fisicas, de manera que la capa interfaz está compuesta por varias partes y una de ellas tiene como objeto ofrecer un servicio uniforme a la capa Internet.
Debido a esto, la capa Intemet toma el papel principal y posiblemente el más importante, esto desde el punto de vista de la interconexión de red, asi que es necesario estudiarla en detalle, en particular el protocolo de interconexión utilizado: IP.
obra. Por lo tanto, considere simplemente que IP entrega las tramas en las direcciones respectivas.
IP debe apoyarse en los servicios de la capa interfaz para poder enrutar sus tramas. Asi, IP recibe los datos del usuario, los cifra en una que debe contener toda la información necesaria para ser entregado a la entidad IP destino. Esta entidad IP analiza la trama recibida y extrae los datos que entregará a la entidad apropiada de capas superiores.
Por lo tanto, la capa interfaz debe de asegurar dos servicios : 1. Que las direcciones IP correspondan con las direcciones fisicas.
2. Llevar a cabo la encapsulación de las tramas [P a fin de que puedan ser transmitidas sobre un soporte fisico particular.
Existe un documento para cada red fisica, utilizable en la transmisión de tramas IP, que precisa cómo asegurar estos servicios. No se incluye este documento por no ser la parte de estudio del trabajo, sin embargo incluimos la dirección electrónica para el interés general : nic@n¡c.ddn.mil
Dicho documento define unos mecanismos y estos se representan en dos categorías : 0 Si la tecnología de red subyacente es en modo sin conexión, el mecanismo es evidente :
los "datagramas" IP son encapsulados en las tramas fisicas.
II.2 El protocolo SNMP y su evolución.
El protocolo SNMP (del inglés, Simple Network Management Protocol) proporciona los servicios de administración de red al conjunto de protocolos de Internet, y está definido por una relación cliente/servidor. El cliente/manejador (manager, en inglés) envía solicitudes de gestión a un dispositivo o servidor llamado agente (en inglés, agent), este último ejecuta las operaciones indicadas sobre una base de información de manejo (MIB, Management Information Base) que contiene información conceptual en variables llamadas identificadores de objeto de la MIB. Dichos identificadores contienen a su vez instancias o variables de objeto.
SNMP tiene varios factores a su favor, uno de ellos es su gran popularidad, los agentes SNMP se encuentran en dispositivos de red tales como computadoras, puentes, módems, impresoras, enrutadores, etcétera. SNMP es un protocolo inter-operable, flexible y extensible. Sin embargo, el protocolo presenta varias debilidades. En contradicción con su nombre, es un protocolo dificil de implementar debido a las reglas de su funcionamiento, eventualmente desperdicia ancho de banda al transmitir información innecesaria en cada mensaje SNMP. Otro factor importante en el desempeño del protocolo es la inseguridad en la transmisión de la información (ésto en la versión 1). Entre otras cosas, a lo largo de este trabajo será presentada la evolución de SNMPVI a SNMPv2.
lI.2.l Medio ambiente del protocolo SNMP
el protocolo de administración para intercambiar la información entre los agentes y el manejador. Las operaciones del protocolo son transportadas bajo ciertas medidas de autentificación, de autorización, de control de acceso y bajo politicas de confidencialidad.
La estación de manejo (en inglés, manager) ejecuta las aplicaciones de gestión a los elementos manejados (agentes), con la finalidad de supervisarlos y controlarlos mediante la información de administración.
Estacion Agente A0-me x Equipo no
de genren E"“"“'°' sNMP›/2 w=›=~n=|- SNMP
P'°°"" Pf°=II° ¢0 ameno aa ameno- P ae nm" 7
m-“$28” -mu- -wm- 6., u-“um Funcion un cunvlrilon weno DI nn' Proeno de
no
SNMP lplenclon 'wm'
Um' TCP 3"” Q¡.,°,|¡|v°, Dlspolitlvol UDP dot online ¡¡¢| aqumg
IP UDP "'°”'“"*° prapremro
¡P morro: rrnnn W007!! “ll”
tlnlen
llue-lrllffn Ilslul ¡maru "uu
. . .
Figura 1. El medio ambiente del protocolo SNMPv2. ›-M-
posiblellegar a comprender la SMI. El RFC 1157 [Case et al., 1990], que define el protocolo SNMP. Y un RFC [Case et al., 1994] que ofrece más información sobre la coexistencia entre SN1\/IPvl y SNMPv2.
II.2.2 El nuevo modelo: SNMPv2
` Agente > Magfiad
\_/
SNMP”
1 sNMPv2
\`-4
1
¶
Figura 2. El modelo Cliente/Servidor del protocolo SNMPv2.
H.3 Un resumen de SNMPv2
El dominio de la administración de redes contiene nomralmente una gran cantidad de información. Esta información está detallada en instancias que varían según el tipo de objeto manejado. grupo de objetos manejados enlazados unos a otros, se le denomina módulo MIB (Management Information Base). Algunos de estos módulos están ya definidos (por ejemplo, los módulos Ethemet, FDDI, ATM, etc.)
Para cada tipo de objeto manejado, un módulo MIB define no solamente la sintaxis y la semántica del tipo de objeto, sino también un método para identificar una o varias instancias del mismo tipo de objeto. Estas instancias pueden por lo tanto ser distintas.
H.3.1 Los contextos
Cada contexto tiene al menos un identificador único dentro del dominio de la gestión. Esto es debido a que dicho identificador está formado por la cadena de identificadores de ISO y por la dirección IP del dispositivo donde el contexto gestionará por medio del protocolo SNMPv2. También es importante saber que una parte de la información puede existir en varios contextos y, por lo tanto, esta información puede tener varios identificadores.
H.3.2 La autorización
Por razones de seguridad, es necesario restringir los derechos de acceso a ciertas aplicaciones de administración; es decir, subagrupar la información de gestión y controlar, de esta manera, los derechos de acceso a la información confidencial.
Para ofrecer esta capacidad, el acceso a una parte de la MIB (en inglés, view MIB) se hace a través de un contexto. Esa parte o vista de la MIB contiene un grupo especifico de tipos de objetos manejados (opcionalmente, también sus instancias) dentro de este contexto. Por ejemplo, para un contexto dado, hay una vista de la MIB a cuya gestión se tendrá acceso por medio de dicho contexto. 'En efecto, habrá seguramente otras vistas de la MIB por medio de las cuales podremos tener acceso a otras partes de la información.
De esta manera, podemos autorizar el acceso a una aplicación de gestión para que maneje información de una parte de la MIB (podría ser a ciertos subgrupos por ejemplo), es decir, sólo aquella información contenida dentro de ese contexto dado, de esta manera, la aplicación quedará restringida para gestionar sólo bajo un contexto dado.
información mediante un contexto en particular. Por ejemplo, una aplicación sólo tendrá acceso a cierta parte de la información (p.e. al grupo users de la MIB de Unix), o tendrá acceso a lectura o a escritura, o bien pudiese tener acceso a cualquier operación, todo depende de la necesidad del administrador de red.
II.3.3 La autentificación y la privacidad
En ocasiones, no es suficiente con restringir el acceso a ciertas aplicaciones para tener un cierto nivel de seguridad. Por tal motivo son necesarias otras medidas y no solamente identificar la entidad que se desea manejar, sino también encontrar la manera de saber que la identificación sea auténtica. Otra medida de seguridad opcional, es la capacidad de proteger los datos cuando se realiza una operación mediante el protocolo SNMPv2 (cifrar los datos). Esto es utilizado principalmente para los datos confidenciales, a los cuales se tiene acceso mediante SNMPv2.
Existen algunos algoritmos para realizar la autentificación y la privacidad. Sin embargo, están sujetos a cambios. Tales cambios pueden tener lugar cuando nuevos resultados de investigación sean obtenidos. Debido a esto, es posible especificar tales algoritmos como parámetros, de manera que nuevos algoritmos puedan ser tomados en cuenta en el futuro. En particular, un grupo que puede ser útil a futuro es el grupo de algoritmos asociados a una criptografía simétrica.
lI.3.3.l El algoritmo de autentificación (MD5)
información se genera un campo llamado condensado (en inglés conocido como “digest") calculado por el algoritmo a partir de una porción de la trama por emitirse. Para evitar la falsificación de identidad, se utiliza el mismo campo “digest", establecido en función de una clave secreta de manera que sólo el emisor y el receptor tengan conocimiento.
El algoritmo utilizado para generar el campo "digest" es el algoritmo MD5 (Message Digest 5). Una cadena de 128 bits es construida a partir de una porción de la trama SNMPv2 que va a ser emitida. El algoritmo MD5 a sido realizado bajo un concepto de portabilidad, concepto que debe tomarse dentro de la medida que estos algoritmos consumen muchos recursos. Sería interesante estudiarlo en función de la arquitectura utilizada. El algoritmo MD5 está diseñado en lenguaje ASN.1 (Abstractac Syntax Notation.One) con un identificador llamado v2md5AuthProtocol.
Cualquiera que sea la parte SNMPv2 (party-SNMPv2), el protocolo de autentificación es v2md5AuthProtocol, el tamaño de la clave de autentificación es de 16 octetos y el tamaño del identificador authDigest para una comunicación es igualmente de 16
lI.3.3.2 Algoritmo de encriptación simétrico (DES, Data Encryption Std.)
Una confidencialidad total puede ser obtenida cifrando la información emitida sobre la red. El cifrado de los datos es realizado por el algoritmo Data Encryption Standard (DES). Los datos son cifrados y después integrados a la trama SNMPv2 para ser transmitidos. La utilización de este algoritmo es identificado por el objeto identificador en ASN.1 desPrivProtocol. Cualquiera que sea la parte SNMPv2 (party-SNMPv2) que utilice el algoritmo, posee una clave privada de 16 octetos.
Para que una comunicación sea correcta, es necesario que las dos partes hagan la misma operación para utilizar, O no, los algoritmos de autentificación y privacidad; es decir, hay que sincronizar ambas partes si van a usar dicho algoritmo.
Es importante mencionar que no todas la interacciones del protocolo SNMPv2 necesitan tener el mismo nivel de seguridad. De hecho, hay interacciones del protocolo que necesitan trabajar sin seguridad. Por ejemplo, la capacidad de una estación de gestión para trabajar con algunos otros dispositivos fuera de su dominio de gestión, es decir, de manera pública. Otro ejemplo seria la sincronización entre entidades SNMPv2 para poder hacer uso de los algoritmos de seguridad. El acceso sin seguridad, está incluido en las interacciones del protocolo SNl\/IPv2 debido a que hay ocasiones en las que se requiere trabajar sin hacer uso de los algoritmos de autentificación (nivel Auth) y privacidad (nivel Priv), es decir, trabajar con un nivel sin seguridad llamado noAuth/noPriv.
H.3.4 Un control de acceso
acceso a las operaciones de administración autorizadas para manejar información de la MIB (Management Information Base).
II.3.5 Un modelo de seguridad
Un modelo de seguridad define los mecanismos utilizados para ofrecer un nivel de seguridad, definido administrativamente, para poner en marcha la operaciones del protocolo, es decir:
1. Define los parámetros de seguridad asociados a una comunicación; incluyendo, los algoritmos de autentificación y privacidad, asi como sus claves de acceso.
2. Define las interacciones de una entidad SNMPv2, las que son emitidas e identificadas. 3. Define los contextos identificados para las interacciones del protocolo.
4. Define los mecanismos que realizan la política de control de acceso, de manera que se pueda tener acceso a la información correctamente.
lI.3.6 Relación por procuración para el manejo dela información (proxy agents) Es la relación mediante la cual un agente responde a solicitudes generadas por otras entidades para tener acceso a la información de gestión. Tal solicitud está contenida en un mensaje SNMPv2, con lo cual ofi'ece la posibilidad de aplicar una operación a cierta parte de la información de administración. En casos por procuración cada mensaje SNMPv2 debe de estar asociado a un contexto. Asi, un agente por procuración SNMPv2, puede ser capaz de procesar las solicitudes a cualquier parte de la información que esté dentro de los contextos soportados.
aproximada; es decir, se emplea con algunas diferencias. Por tal motivo se describe a continuación la manera de utilizar un agente por procuración:
l. Para remitir peticiones de un agente SNMPv2 a algún agente SNMIPvl, debido a que este último no puede interpretar el medio ambiente de SNMPv2. El objetivo es encontrar un acceso a los objetos manejados. Un ejemplo de esto, es cuando se remite una petición SN1\/IPv2 de un dominio de transporte a otro o convertir peticiones SNMPv2 a SNMP. 2. Para interpretar solicitudes SNMPv2 en operaciones de otro protocolo que no sea
SNMP.
3. Para soportar los objetos recuperados por una interacción, donde el valor de la instancia del objeto, depende sobre todo del valor que tome la instancia en la parte distante.
Cada uno de estos escenarios puede ser ventajoso. Por ejemplo, el soporte que ofrece este tipo de agente para recuperar la información de gestión, puede reducir significativamente las necesidades de ancho de banda cuando desempeña actividades de gestión de gran escala. Sin embargo, utilizar el termino “por procuración” para cubrir todos los escenarios puede causar confiisiones. Para evitar tales conlìrsiones en este témrino, podemos agregar lo siguiente:
Asi, cuando un agente actúa como un agente SNMPv2 por procuración en un contexto particular, este agente no necesita una información detallada concerniente a la parte o la vista de la MIB a donde se desea tener acceso. El agente por procuración remite, solamente, la solicitud cualquiera que sea el tipo de objeto administrado.
En el caso contrario, un agente operando normalmente puede tener una definición detallada de la parte o la vista de la MIB a donde se desea tener acceso.
H.4 Componentes del protocolo SNMPv2 en la administración de redes
En este punto se aborda una descripción más formal de lo que es el protocolo SNMPv2. También se abordan sus principales conceptos para después, llevar a cabo la administración de red mediante el mismo.
[[.4.l Entidad SNlVIPv2
Una entidad SNMPv2 es un mecanismo que realiza operaciones de administración de red; es decir, que genera y/o responde a mensajes del protocolo SNMPv2. Estos mensajes son conocidos como la unidad de datos del protocolo (PDU, Protocol Data Unit) los cuales están detallados en [Case et al., 1995]. Una entidad SNMPv2 siempre está identificada como una entidad administrativa particular cuando procesa un mensaje SN1\/IPv2; es decir, el mensaje siempre contiene la identificación de la entidad que lo ha procesado.
lI.4.2 Agente SNMPv2
Todos los componentes de red necesitan estar controlados jerárquicamente por medio de una instrumentación de red y el agente tiene el acceso a esa instrumentación. Por otra parte, por medio del protocolo se tiene acceso a la información de gestión mediante los objetos manejados soportados por el agente en uno o varios contextos.
II.4.3 Manejador SNMPv2
Un manejador SNMPv2 es el papel que asume una entidad SN1\/IPv2 cuando juega el papel de administrador de red. Asi, es posible realizar las operaciones de administración de red (en inglés get, get-next, get-bulk). Para ser más precisos, un manejador realiza estas operaciones generando mensajes del protocolo SNMPv2 o recibiendo y procesando otras operaciones importantes como alarmas y notificaciones, estas últimas enviadas de un agente SNMPv2.
II.4.4 Entidad SNMPv2 en doble papel
Una entidad SNMPv2 que se comporta, ya sea como manejador o ya sea como agente, es conocida como entidad en doble papel. Cuando actúa como manejador, interroga a los agentes que están dentro de su dominio de gestión; esto lo hace procesando la información que los agentes le envían mediante las operaciones de respuesta (en inglés, reponse). Cuando actúa en el papel de agente, verifica si el acceso a la información es autorizado y realiza la operación solicitada sobre el objeto indicado, después envia la respuesta al manejador.
agente. Por lo tanto es recomendable que todas las entidades SNMPv2 actúen como entidad SNMPv2 en doble papel, sobre todo cuando se tienen nodos manejados por jerarquía de red.
H.4.5 Partes SNMPv2 (en inglés, party SNMPv2)
Es un mecanismo programado que comunica a las entidades con la ayuda de un protocolo de administración de red (SNMPv2) y un protocolo de transporte y utiliza los mecanismos de autentificación y confidencialidad (privacidad). Estas partes SNl\/[Pv2 (en inglés, party°s), se encuentran dentro de una base de datos ubicada en cada entidad SNMPv2, dicha base de datos, contiene los mecanismos más importantes para llevar a cabo la administración de red con el protocolo SNMPv2.
II.4.6 La vista de la MIB
Una vista MIB es un grupo o un sub-grupo de objetos manejados por una entidad. Dicha vista de la MIB es una parte de todas las instancias de los tipos de objeto definidos de acuerdo a la SMI (Structure Management Information) [Case et al., 1995]. Cada vista de la MIB está dentro de un contexto SNMPv2 (o varios si es necesario) para poder tener acceso a manejar la información por medio de las aplicaciones de administración de red; sin embargo, es necesario cumplir con estos requisitos:
1. Es posible especificar una vista de MIB que contenga todas las instancias necesarias dentro de un contexto SNMPv2.
H.4.7 Contexto SNMPv2
Un contexto SNMPv2 es una colección de información de gestión accesible por una entidad SNMPv2. El contexto puede ser local o por procuración. Un contexto local es un contexto realizado por el administrador para una entidad local, es decir, la entidad SNMPv2 utiliza los mecanismos definidos localmente para tener acceso a la infonnación identificada por ese contexto. Para un contexto por procuración, la entidad actúa como una agente por procuración SNMPv2 para tener acceso a la información identificada por ese contexto SNMPv2.
lI.4.7.l Contexto local SNMPv2
lI.4.7.2 Contexto SNMPv2 por procuración
Una relación por procuración existe cuando un agente procesa un mensaje (solicitud o respuesta recibida) remitiéndola a otra entidad definida por el contexto dentro de ese mensaje recibido. Este contexto es conocido como contexto por procuración. Asi, cuando una entidad SNMPv2 procesa tal solicitud o respuesta a través de un contexto por procuración, la entidad actúa como un agente por procuración SNMPv2.
l1.4.8 Operaciones del protocolo SNMPv2
La unidad de datos del protocolo (PDU) es definido en Case et al. [1995]. Cada PDU consiste en una operación especifica particular, los datos son intercambiados o transportados por las entidades utilizando el protocolo y cada operación apropiadamente. Las operaciones son las siguientes:
0 GetBulkRequest: acceso en modo lectura a instancias tabuladas. 0 GetRequest: acceso en modo lectura a una instancia dada.
0 GetNextRequest: acceso en modo lectura a la siguiente instancia. 0 Inform: información de manejador a manejador SNMPv2.
manejador agente
-==--fíget-requestì-H fiígebroponueí-«i-got-noxt-request-¿-U
rt nagobreponaeí- rt udppuïeg ebulk-request?-_› 1%1
-fií-bulk-reponaeíì
end-requeati-›
<-ìget-reponse-í-1 UIP
Figura 3. Las operaciones del protocolo SNMPv2.
II.4.8.l El contenido de un mensaje PDU (Protocol Data Unit)
Una comunicación entre dos entidades SNMPv2 es un mensaje SNMPv2. El formato de este mensaje es de tal manera que contiene a la unidad de datos del protocolo (PDU). Eso significa que esta unidad ha sido encapsulada de acuerdo con el modelo de seguridad utilizado para la transmisión de un mensaje SNMPv2.
han sido ocupados. La entidad reporta en el PDU ( a la entidad origen) los siguientes campos: request-id, que es la dirección a donde se remitirá el mensaje PDU en respuesta a la falta de identidad; error-status y error-index que son puestos a cero debido, como citamos, a que no han sido requeridos, dichos campos son usados para contabilizar errores cuando se llevan a cabo interacciones identificadas. El campo variable-bindings, contiene dos informaciones: la identidad del contador incrementado y su nuevo valor. Es decir retiene ciertas claves del porque la eliminación del mensaje y el numero de ocasiones que el agente ha sido solicitado.
En el caso en el cual la información sea bien identificada, los campos serán llenados dependiendo del tipo de dispositivo en cuestión (p.e. los tipos de instancias, identificadores de objeto, variables, etc.). El mensaje PDU varía dependiendo el mecanismo a manejar, sin embargo no existe gran diferencia.
lI.4.9 La politica de control de acceso
[L5 La plataforma de administración de ISODE y sus componentes
En este punto se presentan los componentes de la plataforma de ISODE versión 8.0, que es utilizada para la puesta en marcha del protocolo SNMPv2. La plataforma está formada por algunos repertorios tales como: TCL (Tool Command Language) versión 7.3, TK (Tool Kit) versión 3.6 y BLT (Base Language Tool) versión 1.0 e ISODE (ISO Development Environment)versión 8.0. En conjunto, estos repertorios ofrecen las herramientas para manejar la información de administración usando el protocolo SNMPv2.
La plataforma de ISODE-8.0 está basada principalmente en los repertorios TCL y TK. En conjunto, estos dos repertorios ofrecen un sistema para desarrollar algunas aplicaciones de gestión por medio de un interfaz gráfico de usuario (GUI Graphic User Interface).
TCL es un lenguaje creado para desarrollar aplicaciones de gestión, el cual ofi'ece la facilidad de trabajar en vanos ambientes de gestión e instrumentación de red. TK es una extensión de TCL, formada por un grupo de herramientas extendidas al sistema gráfico de X Window.
Estos repertorios juntos ofrecen algunas ventajas de interés en el desarrollo de aplicaciones de manejo o gestión de red. Algunas de estas ventajas se presentan a continuación:
0 TCL y TK juntos, ofrecen grandes facilidades para desarrollar aplicaciones con otros medios como compiladores C.
0 TCL ofrece una relativa facilidad a la programación en ambientes de gestión en modo
ventanas.
Una vez instalada la plataforma, quedan instaladas todas las herramientas con las cuales se lleva a cabo la administración de red. Entre las principales herramientas se encuentran las siguientes:
0 Soporte para las bases de datos de manejador y agentes
0 Compilador de módulos MIB (Management Information Base).
0 Escenarios de ejecución para gestionar con la instrumentación en el equipo de gestión.
0 Un iniciador para SNMPv2. (snmpi)
0 Un manejador en lenguaje TCL y TK en ambiente ventana (snmptcl).
III. DESARROLLO
Este trabajo de tesis consistió en la implementación de una tecnología de administración de red con una plataforma experimental que incluye el protocolo SNMPv2. El trabajo se llevó a cabo en las siguientes etapas: introducción general al dominio de la administración de redes, estudio del protocolo SNMPv2, instalación de la plataforma de gestión de ISODE, componentes del protocolo en la plataforma, la realización de una aplicación de monitoreo para manejar el sistema Unix y un estudio del comportamiento del manejador SNMPv2.
El objetivo del trabajo comprendió los siguientes puntos:
1. La validación de los dispositivos de seguridad del protocolo SNMPv2 con la platafonna instalada.
2. El desarrollo de una aplicación de monitoreo de red para estudiar el desempeño de protocolo en la recuperación de información.
3. Un estudio del comportamiento del manejador SNMPv2 (estación de gestión) utilizando dos modos de comunicación (con y sin seguridad).
El desarrollo del trabajo para cumplir con los objetivos fiie el siguiente: en lo referente al punto número uno, se realizó una configuración de prueba, es decir, se instaló manejador y agentes en diferentes estaciones teniendo el manejador en una estación de trabajo SunOS 4.1.3 con dirección IP es 137.l94.206.1(shorter) Esta entidad contiene la plataforma de gestión que incluye:
0 Una base de datos para cada entidad SNMPv2.
0 Las herramientas de ayuda tales como compiladores, módulos y programas. 0 Un agente por procuración SNMPv2 para recuperar la información del agente
SNMPVI.
0 Un agente local SNMPv2 con sus tres modos de comunicación (noAuth/noPriv, Auth/NoPriv y Auth/Priv) y,
I Un sistema de administración de red con una interfaz gráfica para usuario (GUI, Graphic User Interface) con programación en TCL y TK (snmptcl).
Agente V1
manejad q Interfaz gráfico
or para usuario
SNMP\Q X1 1
Agente V2 "
-s
g 2
3 Herramientas
su del sistema:
3;: Bass as datos Snmpi
del
:gt: Manejador mosyv
, módulos,
etc.
oojegñ
oidwus
x±^1o±ans
Plataforma de ISODE
Sistema Operativo SunOS 4.1.3
Figura 4. La plataforma de gestión de ISODE y sus herramientas.
realizar las pruebas e interactuar con el modelo administrativo del protocolo. Las estaciones que soportan a los agentes tienen las siguientes caracteristicas:
* Stheno: dirección IP l37.l94.l60.36 es una estación de trabajo HP (Hewlett Pakard) con sistema operativo HP-UX y soportando una interfaz ATM (Asyncronus Transfer Mode), por lo que el agente toma el nivel de agente extensivo.
* Terry: dirección IP l37.194.l92.4 es una estación de trabajo HP sobre una subred Ethernet. Agente clásico.
* Deedee: dirección IP 137.194.192.22 es una estación de trabajo HP sobre una subred Ethertnet. Agente clásico.
Una vez que la configuración fue realizada, se trabajó con el protocolo con la finalidad de validar su seguridad. La sinopsis de las pruebas fueron de la siguiente manera:
0 Comprobar que el acceso de un manejador privilegiado (manejador local) a la información, cumpla con los dispositivos de seguridad ofrecidos por el protocolo. 0 Comprobar el acceso de un manejador a un agente mediante sus claves secretas
(privacidad).
Internet
' "
137.194.160.36
;
°"° °
"stheno"
:
137.194. red
dorsal de la
A
\
R R
1 2
137.194.206.1
137.194. 192.4
"shorter"
"terry"
137.194.192.22
“deedee” oo
WJ.VZBJ-lalul
Figura 5. Configuración manejador y agentes en la red dorsal de la ENST. Paris
En lo referente al punto número 2, se desarrolló una aplicación de monitoreo para recuperar la información de una MIB. Para esto se utilizó la configuración de la plataforma, es decir, los mecanismos de la platafonna para recuperar y administrar la infonnación de la MIB del sistema Unix.
Las especificaciones que debe cumplir la aplicación son la siguientes:
0 Que la aplicación sea ejecutable sólo con snmptcl, es decir, escrita o compilada en lenguaje TCL.
0 El desempeño debe ser en tiempo real, monitoreando en pantalla el desempeño del protocolo en cada operación.
Para cumplir lo anterior, el programa fiie realizado en lenguaje TCL y contiene un preámbulo de identificación para que snmptcl pueda ejecutarlo. El acceso a las variables del modelo del protocolo, son de tal manera que no se altera la información, es decir, el programa respeta todos los estatutos del protocolo.
El objetivo de la aplicación es la administración de algunos grupos de la MIB para aplicar su fimcionamiento en equipos de acceso al usuario (servidores, impresoras en red, etc.). La aplicación se desarrolló en base a un programa que puede ser leido y compilado por el sistema gráfico de la plataforma (snmptcl) El programa es capaz de leer la información (instancias de objeto) de los grupos users, print y fileSystem, contenida en un módulo MIB. Esta aplicación fise validada comparando su desempeño con el iniciador snmpi obteniendo muy buenos resultados.
Por último, se realizó un estudio del comportamiento en el manejador SNMPv2, utilizando los modos de comunicación con y sin seguridad. Este estudio pemiite conocer el comportamiento del manejador por una parte, y por otra, evaluar el consumo de recursos por el protocolo.
Para esta prueba se utilizó una configuración manejador/agente, el manejador privilegiado es el de la plataforma (shorter 137.194.206.1), el agente está instalado en la estación stheno.
Para cumplir el objetivo, se realizó un programa que hace uso de algunos comandos de Unix. Esto para conocer directamente el porcentaje de CPU utilizado en el menejador y el tiempo utilizado en un ciclo de operaciones. El programa ejecuta 100 peticiones al agente solicitando el valor de una variable del grupo system de la MIB (sysDescr). Desde luego se realizaron pruebas utilizando los mecanismos de seguridad y sin ella.
IV. RESULTADOS
En base al trabajo realizado, los tres puntos citados en el capítulo anterior cumplen lo esperado por el protocolo SNMPv2. Si bien el protocolo es un dispositivo lógico del modelo de TCP/IP que opera en la administración de redes abiertas y su implementación es un tanto complicada, no obstante, es segura. En respuesta a la evolución que busca el protocolo SNMPv2 en relación a SNMPVI, la seguridad es un punto crucial a favor. En este trabajo se pudo comprobar que todos los mecanismos del modelo administrativo (el modelo de la seguridad del protocolo) trabajan de manera óptima.
Por otro lado, por medio de las herramientas de la plataforma (snmptcl), se pudo constatar que el protocolo podría ser incluido en grandes plataformas de administración de red (p.ej. Openview 9000 de H.P.) ya que está excento de problemas de programática y a que puede gestionar en diferentes nodos de interconexión.
Por último, se efectuaron medidas cuyos objetivos fueron: 1) evaluar el consumo de CPU (Central Process Unit) y 2) el tiempo de respuesta por operación (100 peticiones) utilizando los modos de comunicación noA uth/noPriv y SnmpAuthMsg/SnmpPrivMsg.
Las informaciones recolectadas en la máquina que soporta al manejador fueron: 0 La carga de la máquina
0 Fecha y hora de ejecución
0 Duración correspondiente a la ejecución y respuesta de 100 solicitudes en serie y, 0 Recursos utilizados dentro del sistema Unix (consumo de CPU3 ),
Shorter- 9596/memoria/test $ cat cien_veces : #/bin/csh
a=5O ; b=o ; c=2 ; d=0
echo " " ; echo "inicio de prueba"
# HORA DE EJECUCIÓN
date
# CARGA
uptime ~
while test Sd -ne Sc #ciclo 1 do
while test $b -en Sa #ciclo 2 do
/usr/local/bin/gawksnmp 'BEGIN { print sysDescr;}' l>/dev/null
b=“expr $b + 1 2>/dev/null'
done i
b=O
date;uptime
d=“expr $d + 1 2>/dev/null' done
echo “DURACIÓN POR roo PETICIONES”
3Porcentaje de CPU dedicado al manejador SNMPv2. En este caso la estación esta dedicada para
Esta subrutina está incluida en un programa que la ejecuta 500 veces, de la manera siguiente:
Shorter- 9596/memoire/test $ cat 500_veces : c=500 ; d=0
while test $d -en Sc do
time cien_veces
d=“expr $d + l 2>/dev/null' done
El mando SNMPv2 será, por lo tanto, repetido 50000 veces. Toda esta información fue tomada en cuenta para llenar la tabla I.
Tabla I. Tiempo de respuesta y CPU consumido por 100 operaciones SNMPv2.
Tiempo total de respuesta por ejecución de % de recursos utilizado en 100 peticiones
100 peticiones (seg) (CPU)
139 55%
139 53%
125 57%
134 54%
130 57%
112 62%
130 55%
si está entre l.5 y 2.5 y fiierte, si es estrictamente superior a 3.5. Los resultados son los siguientes:
Tabla ll. Resultado de carga contra tiempo de respuesta (promedios).
Primera Segunda Tercera Carga media Tiempo de Consumo
0.9 0.96 l 0.95
medición medición medición , respuesta de CPU
107 64%
1.8 ,2.l 2.1 2.00 61%
03.86
3.71
3.62 3.73 56%0.9 0.91 0.98 0.96 76%
1.9 2.00 1.95 1.95 68%
3.85 3.9 3.6 3.81 , 62%
3.6 3.75
`3.s9
3.74 64%IV.1 Análisis de resultados
La tabla del análisis de resultados muestra algunas tendencias importantes. La primera, y podria ser la más importante, es referente al tiempo de respuesta, tanto en forma noAuth/noPriv como SnmpAuthMsg/SnmpPrivMsg. De tal manera, que los resultados son casi los mismos en lo referente a la respuesta a las peticiones ejecutadas. Eso significa, que la comunicación SnmpAuthMsg/SnmpPrivMsg no está penalizada en tiempo, es decir, son muy aproximadas las respuestas al tiempo en los dos modos de comunicación, al menos en la configuración de esta prueba.
que el cifrado de los datos necesita de un algoritmo, y este consume una parte considerable del CPU.
La tercera tendencia, concieme a la relación de la carga en la máquina y la duración media de ejecución de 100 peticiones. El tiempo de respuesta del agente, depende de la carga de la máquina donde esta el manejador (manager SNMPv2). Los resultados muestran que esta tendencia se presenta de igual manera en ambos modos de comunicación. La disminución del consumo de CPU en fiinción de la carga, se debe al hecho de que un proceso, generalmente, pasa más tiempo en transmisión que en proceso/máquina; así, cuando el agente atiende las peticiones recibidas de manera fluida, ofrece un factor óptimo para descargar y depurar el sistema del manejador (carga en la máquina).
Tabla III. Resultados finales de las pruebas obtenidas.
Pf0I0¢0l0 SNMP*/2 tasa de la carga j carga media duración media consumo CPU 107
n0Auth/n0Priv
débil
0.95
64%
noAuth/noPriv media 2.00 61%
noAuth/noPriv fuerte 3.77 56%
SnmpAuthMsg
/SnrnpPrivMsg débil 0.96 76%
SnmpAuthMsg
/SnmpPrivMsg media 1.95 68%
SnmpAuthMsg
/SnmpPrivMsg fuerte 3.81 64%
IV.2 Pruebas propuestas
v. coNcLUs1óN
La presentación del protocolo SNMPv2 y sus diferentes modos de comunicación, ponen de manifiesto su evolución. El estudio del desempeño del protocolo SNMPv2, en sus modos de comunicación no/luth/noPriv y SnmpAuthMsg/SnmpPrivMsg aportan lo siguiente:
0 La utilización del protocolo SnmpAuthMsg/SnmpPrivMsg no altera el tiempo de respuesta en comparación con noA uth/noPriv, en la configuración propuesta. 0 La diferencia media del consumo de CPU es del 9 % entre los dos modos de
comunicación.
Esto confirma que la evolución del protocolo SNMP en su versión 2, no excede los recursos de un equipo (al menos en la configuración propuesta) y además, cumple con un modelo de seguridad utilizado en la transmisión de información dentro de la gestión de redes. Por otro lado, SNMP es un protocolo enormemente diseminado, si la cohabitación de los manejadores SNMPv2 con el protocolo SNl\/IPvl ha sido bien estudiada [Case et al.,
1995], se puede suponer que este protocolo tendrá la aceptación esperada.
necesario contar con la presencia de esta operación (inform). En respuesta al problema, se recomienda trabajar en paralelo con la plataforma CMU (Camegie Mellon University), que incluye principalmente,
0 Un agente bilingüe que implementa los mismos algoritmos de seguridad, 0 La manera de comunicar un manejador con otro,
0 La implementación de diversas aplicaciones de administración de red, basadas en lenguaje TCL y TK.
Esta plataforma es activamente apoyada y actualizada por la Universidad Camegie Mellon y por la comunidad de Intemet. Sería interesante trabajar con ambas plataformas a manera de profundizar en algunos puntos de la administración de red con el protocolo
SNMPv2.
Después de haber evaluado el desempeño del protocolo con y sin mecanismos de seguridad, los resultados permiten ver que la disminución de los recursos disponibles del equipo que soporta al protocolo (sobre todo actuando bajo los mecanismos de seguridad) son despreciables, si tomamos en cuenta el nivel de seguridad ofrecido cuando se tiene acceso a la información de administración de red.
Si bien, como se mencionó anteriormente, el protocolo no es lo suficientemente simple para ponerlo en marcha y operar con él, es muy importante tener en cuenta que es un protocolo muy completo y que además cumple con las especificaciones de la interconexión de redes heterogéneas.
LITERATURA CITADA
Case J., M. Fedor, M. Schoffstall, J. Davin. 1990. “Simple Network Management Protocol”. STD 15, RFC 1157.
Case J., K. McCloghrie, M. Rose, S. Waldbusser. The SNMPv2 Working Group. 1995 “Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)”. RFC-TC.
Case J., K. McCloghrie, M. Rose, S. Waldbusser. The SNMPv2 Working Group. 1995. “Confomrance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)”. RFC-CONF.
Case J., K. McCloghrie, M. Rose, S. Waldbusser. The SNMPv2 Working Group. 1995. “Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)”. RFC-PROTO.
Case J., K. McCloghrie, M. Rose, S. Waldbusser. The SNMPv2 Working Group. 1995. “Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)”. RFC-TM.
Case J., K. McCloghrie, M. Rose, S. Waldbusser. The SNlvIPv2 Working Group. 1995. “Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)”. RFC-SNMPv2-MIB.
Case J., K. McCloghrie, M. Rose, S. Waldbusser. The SNMPv2 Working Group. 1995 “Structure of Management Information for Version 2d of the Simple Network Management Protocol (SNMPv2)”. RFC-SMI.
Feit S. 1995. "SNMP, A guide to network management”. McGraw Hill. Series Advidsor. Gagniaire M. 1994. " Interconexión de Reseaux Heterogenes". ENST, De'pt. Reseaux. Paris
44 pp.
Joachim B., A. Lellouche. 1995. “Environnement de SNN[Pv2”. Gres 1995. ENST Paris 151-162 p.
Leinwand A. 1994. “Network Management”. Revista Mensual. SNMP. Leinwand A. 1994. “The simple times”. Revista bimensual. SNMP.
McCloghrie K., and F. Kastenhol. 1994. “Evolution of the Interfaces Group of M]B-II”. RFC 1573, Cisco Systems, FTP Soflware.
Quaterman J.S. 1993. “The matrix”. Revista mensual de Internet. USA.
Rose M. T. 1995. “La gestion des réseaux ouverts : SNMPv2”. Inter Editions, primera edición. Paris Francia. 279 pp.
Rose M., K. McCloghrie. 1990. “Structure and Identification of Management Information for TCP/[P-based Internets”. STD 16, RFC 1155.
Rose M., K. McClogl1rie. 1991. “Concise MIB Definitions”. STD 16, RFC 1212, March 1991.
Stevens W.R. 1995. “ TCP/IP, régles et prctocoles”. Addison-Wesley, primera edición 392
PP-APÉNDICE
A continuación se presenta cada uno de los repertorios utilizados para la puesta en marcha de la plataforma de administración, remarcando las medidas necesarias para la instalación, configuración y compilación de cada repertorio. En lo referente a instalación, se incluye la recuperación del repertorio en una cuenta de super-usuario. La configuración, depende del sistema donde se instale el repertorio, en este caso, es en un sistema SunOS. Cabe señalar que la plataforma, puede configurarse en infinidad de arquitecturas (H.P., Xerox, etc.). Por último, la etapa de compilación incluye el ordenamiento de todos los procesos de cada repertorio, tales como: bibliotecas, programas de usuario, programas de administrador, etcétera. Empezaremos por instalar cada uno de los repertorios en el orden que se muestra: tcl7.3, tk3.6, bltl.0 e isode-8.0. Con esto tendremos instalada la plataforma de gestión ISODE-8.0 para administración de red con el protocolo SNMPv2.
Apéndice A: la plataforma ISODE El repertorio tcl7.3
El repertorio tcl7.3 trabaja de dos maneras; primeramente, es un poderoso lenguaje de programación orientado a objetos y secundariamente, actúa como biblioteca para algunos otros programas de TCL.
La versión utilizada en esta plataforma, es la más actual (tcl7.3) y fue instalada, configurada y compilada de la siguiente forma:
La versión del repertorio tcl7.3 está disponible en la siguiente dirección: Lugar: fip.smli.com
La instalación se debe realizar en la trayectoria: /usr/local/src/v2/
y con los mandos siguientes: # cd /usr/local/src/v2/
# uncompress < tcl7.3.tar.Z |
xdf-Este último mando realiza la descompresión del repertorio de tal manera que a partir de este momento se tendrá un directorio llamado tcl7.3, el cual contiene los archivos para realizar la configuración y la compilación.
Para configurar el nuevo directorio de tcl7.3, es necesario una instrucción para ejecutar el archivo llamado configure:
# cd tcl7.3 # _/configure
Este programa verifica la presencia de los archivos necesarios para la compilación principalmente un archivo llamado Makefile. Este archivo indica al compilador el nombre de ciertos archivos particulares que pueden ser modificados. La modificación depende del tipo de arquitectura y sistema operativo de la estación donde será instalada la plataforma. Sin embargo, la plataforma de administración de ISODE-8.0 se instaló en un dispositivo con un sistema de SunOS 4.1.3 (y unos agentes en arquitectura HP).
Después de verificar la anulación de los errores en la compilación, se puede ejecutar el comando make:
El mando make verifica que todos los archivos estén bien ordenados dentro del
directorio antes de ejecutar el ultimo mando, make install, con este último mando, queda instalado el directorio tcl7.3 y después, instala todos los mandos de TCL que se usarán en la programación de aplicaciones.
Por último, para que la instalación se lleva a cabo correctamente, es importante crear la trayectoria /usr/local/lib/tcl ya que ahí se encontraran las bibliotecas de tcl7.3 requeridas al momento de instalar el repertorio isode-8.0.
El repertorio tk3.6
El repertorio tk3.6 es una extensión de TCL que ofrece al programador un sistema de ventanas con una interfaz bajo el sistema Windows X11 y todo su medio ambiente. Esto quiere decir, que es un interfaz gráfico XII instalado bajo TCL.
La versión utilizada en la plataforma es la más actual (tk3.6), y fue instalada, configurada y compilada de la siguiente fomra:
La versión del repertorio tk3.6 está disponible en la siguiente dirección: Lugar: f`tp.smli.com
trayectoria: /pub/tcl/ Archivo: tk3.6.tar.Z
La instalación se debe realizar, igualmente que TCL, en la trayectoria: /usr/local/src/v2/
y con los mandos siguientes: # cd /usr/local/src/v2/
xdf-Con este último mando se realiza la descompresión del repertorio, de tal manera que a partir de este momento se tendrá un directorio llamado tk3.6, con lo cual ahora se tienen los archivos para realizar la configuración y la compilación.
Para configurar el nuevo directorio de tk3.6, es necesario ejecutar la instrucción configure de la siguiente manera:
# cd tk3.6 # ./configure
Este programa verifica la presencia de los archivos necesarios para la compilación principalmente el archivo Makefile del repertorio tk3.6. El archivo Makefile indica al compilador el nombre de los archivos que pueden ser modificados. La modificación depende del tipo de arquitectura y sistema operativo de la estación donde será instalada la plataforma (al igual que para tcl7.3). Sin embargo, la plataforma de administración de ISODE-8.0 se instaló en una estación de trabajo con un sistema SunOS 4.1.3.
Después de verificaraque la compilación se haya llevado a cabo correctamente, se puede ejecutar el comando make:
# make # make install
Por último, para que la instalación se lleve a cabo correctamente, es importante crear la trayectoria /usr/local/lib/tk ya que ahí se encontraran las bibliotecas de tk3.6 requeridas al momento de instalar el repertorio isode-8,0.
El repertorio blt-1.0
Esta es la versión 1.0 del repertorio de BLT, el cual es una extensión de TCL y TK que contiene algunos archivos que no se pueden mezclar con las bibliotecas principales de
TCL y TK.
La versión del repertorio blt-1.0 está disponible en la siguiente dirección: Lugar: ftp.cisco.com
trayectoria: /pub/kzm/snrnptcl/ Archivo: blt-1 .0.tar.Z
La instalación se debe realizar igual que para todos los componentes de la plataforma, es decir, en la trayectoria:
/usr/local/src/v2/
y con los mandos siguientes: # cd /usr/local/src/v2/
# uncompress < blt-1.0.tar.Z |
xdf-Con este último mando se realiza la descompresión del repertorio, de tal manera que a partir de este momento se tendrá un directorio llamado blt-1.0, con lo cual ahora se tienen los archivos para realizar la configuración y la compilación.
Para configurar el nuevo directorio de blt-1.0, es necesario ejecutar la instrucción configure de la siguiente manera:
Este programa verifica la presencia de los archivos necesarios para la compilación principalmente el archivo Makefile del repertorio blt-1.0. El archivo Makefile indica al compilador el nombre de los archivos que pueden ser modificados. La modificación depende del tipo de arquitectura y sistema operativo de la estación donde será instalada la plataforma (igual que para todos los componentes de la plataforma). En este caso, la plataforma de administración de ISODE-8.0 se instaló en una estación de trabajo con un sistema SunOS 4.1.3.
Después de verificar que la compilación se haya llevado a cabo correctamente, se puede ejecutar el comando make:
# make # make install
El mando make verifica que todos los archivos necesarios existan dentro del nuevo directorio llamado blt-1.0. Una vez que no existan errores, se puede ejecutar el último mando make install, con el cual queda instalado el directorio blt-1.0 y todos los mandos y utilerias de BLT que se usarán en la programación de aplicaciones, principalmente al momento de compilar snmptcl.
Este es el repertorio principal de la plataforma. Aquí están contenidos todos los archivos necesarios para llevar a cabo la administración de red por medio del protocolo, ya que el repertorio incluye el protocolo SNMP en la versión 1 y 2.
Al igual que los anteriores repertorios, se sigue la misma secuencia para llevar a cabo la instalación. La configuración y la compilación de isode presentan algunas diferencias en comparación con los primeros repertorios, las cuales se acentúan en la etapa de compilación debido a que este repertorio contiene algunos dispositivos que forman parte de otras aplicaciones.
La versión del repertorio isode-8.0 está disponible en la siguiente dirección: Lugar: fip.lbp.fr
trayectoria: lpub/
Archivo: isode-8.tar.Z
La instalación se debe realizar igual que para todos los componentes de la plataforma, es decir, en la trayectoria:
/usr/local/src/v2/
y con los mandos siguientes: # cd /usr/local/src/v2/
# uncompress < isode-8.tar.Z |
archivo Makefile de isode (en el directorio isode-8.0) que contiene información de las diferentes aplicaciones disponibles en el repertorio de isode.
El siguiente punto describe la manera en que se realizó la compilación de isode-8.0 debido a que a partir de este momento, se trabaja con la fase para la instalación del protocolo SNMPv2 y todos sus mecanismos para llevar a cabo la administración de red.
Hasta esta fase se cuenta con la plataforma de administración instalada; es decir, que a partir de este momento se puede hacer uso de los mecanismos tales como agentes, manejadores, módulos MIB, compiladores de MIB, etcétera. Todo depende de la configuración de isode, nosotros hemos instalado la plataforma completa y la instalación se describe en el siguiente capítulo.
Instalación del medio ambiente de administración de red 4BSD/ISODE SNMPv2. El repertorio 4BSD/ISODE SNMPv2 ha sido actualizado para soportar ambas versiones del protocolo SNMP. El objetivo de este punto es presentar los criterios, componentes y archivos del protocolo SNMPv2 en la administración de red, trabajando sobre la plataforma de isode8.0, sobre un sistema SunOS 4.1.
Restricciones del protocolo SNMPv2 en la plataforma de isode-8.0
El repertorio 4BSD/ISODE SNlV[Pv2 es una implementación casi completa del protocolo SNMPv2 con algunas excepciones:
