SNMP

1
SNMP

• Redes de Datos 2002
• etapia_at_eie.fceia.unr.edu.ar

2
SNMP

• Simple Network Management Protocol
• Use for Monitoring
• printer queues
• set up addresses for devices
• assign priorities for communication
• install software on the network
• manage databases
• manage power on the network

3
How (I) ?

• SNMP interacts with
• Management Information bases (MIBs)
• MIBs reside on network devices
• SNMP issues commands
• Network manager
• Monitor and control the network
• Retrieving information from network devices

4
How (II) ?

• SNMP handles traps
• Network management station
• Important events
• Alert Messages (UPS goes on battery...)

5
SNMP product devices

• Any device or application that
• Communicates management information
• Through SNMP
• Devices that talk SNMP can be
• Monitored and managed
• With SNMP network management software

6
Network Managers

• Use SNMP products to perform
• Network management tasks
• SNMPs is relatively easy to implement
• Widely spread
• Hardware and Software platforms across numerous
  vendor product lines

7
SNMP agents

• A proxy agent
• Acts on behalf of non SNMP devices
• Exchange information with network manager
• Translates data device-network
• Cache for network information
• Minimize processing on a managed node
• Report extraordinary events.

8
What is a MIB?

• Management Information Base
• Standard for storing data critical
• To network operation
• MIB-I stores data on
• TCP/IP traffic
• Routing, configuration and errors
• MIB-II has improved support for
• Multi-protocol devices
• Allows the NMS to control SNMP operation.

9
Gestión Internet
10
Example PowerMIB UPS standard MIB

• Controls - SNMP set commands
• remote control the UPS (for performing tasks such
  as shutdown, startup, battery test, etc)
• Alarms and Traps
• Inform the SNMP network management station about
  significant UPS events (utility power failure,
  battery low, output overload, etc.)

11
Example PowerMIB ...(contd)

• Status Variables
• Identify the manufacturer
• Model and software version of the UPS
• Dynamic information (input voltage, output
  voltage, output load, etc.)

12
SNMP at the Beginning

• Network components
• Heterogeneous
• Unification Requirement
• Management information
• Administration protocol

13
Two main protocols

• Everything must converge
• One protocol
• Access and share the same data
• SNMP CSMIE/CMP
• Barely compatible
• SNMP developed faster

14
Why SNMP?

• IETF RFCs
• SNMP established in few months
• By OSI rules at least a few years

15
Who?

• Keith McCLOGHRIE
• Marshall ROSE
• Jeffrey D.CASE
• Mark FEDOR
• Martin LEE SCHOFFSTALL
• James R.DAVIN

16
Why ?

• Internet users demand
• TCP/IP widely spread
• Need to avoid
• Long network outages
• Long host downtimes
• Security and the confidentiality

17
When ?

• IAB - RFC 1052 (April 1988)
• "IAB Recommendations for the Development of
  Internet Network Management Standards
• Administration tool for TCP/IP network, Internet
• Ideas from
• SGMP - Simple Gateway Monitoring Protocol

18
When? contd

• RFC 1065
• Structure and Identification of Management
  Information for TCP/IP-based internets
• RFC 1066
• Management Information Base for Network
  Management of TCP/IP-based internets
• RFC 1067
• A Simple Network Management Protocol

19
SNMP design rules

• Network management must
• Be as large as possible.
• Have the wider diversity of implementation as
  possible.
• Have the wider diversity of administration/managem
  ent as possible.
• Cover as much protocol layer as possible

20
The RFC factor

• RFC is proposed as a status of standard
• Draft Standard
• After a six month period
• At least two implementation of the protocol
• IESG recommend it as a standard
• After a four month period
• IAB take the final decision

21
Divergence

• ISO ITU-T influence
• SNMP convergence with CMOT
• IAB also wanted
• TCP/IP management with CMIS/CMIP
• Idea was dropped off
• SNMP moves forward

22
SNMP information sources

• Devices contain information about
• Themselves
• Current status that indicates if the running
  conditions are healthy
• Many interesting knowing about its neighbourhood
  (active stations, statistics, problems)
• Information is the heart of SNMP

23
Accessing SNMP information

• SNMP is the nick become the nick for
• Simple Network Management framework
• SNMP protocol
• Part of the framework that gets information from
  device and changes the values (of the
  configuration parameters)

24
Management Information

• What kind of configuration, status and
  statistical information are associated with a
  device ?
• Any network node has one or more interface to
  media
• Network interface has a defined configuration
  type (e.g. Ethernet, X25, Frame Relay ...)

25
Management Information (contd)

• What kind of configuration, status and
  statistical information are associated with a
  device ?
• Interface have an operational status of Up, Down
  and Testing
• A system normally counts interface statistics
  (Number of send and receive frames...)

26
Where is SNMP information?

• SNMP
• First manage TCP/IP networks
• Later other protocols (such as DC Net, AppleTalk,
  IPX/SPX) and every function of the multi-protocol
  Routers

27
MIBs

• The information may be stored at device as
• Combination of switchs, settings, hardware
  counters, memory variables and tables or files
• Management Information is organized in a logical
  database
• SNMP called them a MIB (Management Information
  Base

28
For Network Managers

• MIB internal structure is not important
• But the way and the accessibility of the data
  base is very important

29
Internet-Standard Management Model

• Enable network manager to examine
• Device data
• Update configuration and status information

30
Internet-Standard Management Model

• Enable network manager to examine
• Device data, Update configuration and Status Ix
• AGENT SOFTWARE is installed in each device
• Receive incoming message from the manager
• Message request read or write of devices data
• Send a response back

31
Internet-Standard Management ...(contd)

• Agent does not have to wait
• Problem arises or a significant event occurs, it
  send a TRAP (notification message) to the manager

32
Manager and Agent Interactions

• MANAGER SOFTWARE is in a management station
• Send message to AGENT
• Receive Trap and Responses
• Use UDP protocol to carries its messages

33
Interactions NM-Agent
34
Network Management Application

• Application
• Enable end user to control the manager software
  and view network information
• These application are not standardized
• Management station vendors compete
• Graphical, intuitive information display,
  application, the best toolkit for adding
  specialized application...)

35
Network Management App. (contd)

• They can map tested LANs
• What and which type of device are there, other
  station
• Render graphs of the traffic report
• Managers can select its own parameters
• Significant event
• Spontaneous problems report
• Message from other applications

36
Network Management App. (contd)

• LAN MONITORS add special capabilities to network
  management
• Examine all of the traffic on a LAN based on any
  criteria
• Traffic for a given protocol
• Traffic between a selected pair of station
• Traffic containing a selected bit pattern

37
MIB variables

• What information have to be kept ?
• The SNMP community
• Define groups of useful parameters
• Fine-tune of the fields after several month of
  experience (remove parameters and add new one)
• Committees of experts to define MIB variables for
  special technologies (Bridges, Token-Ring
  interfaces)
• Add vendor-specific extension

38
MIB I

• Concentrated on information specific to TCP/IP
• System description
• The number of networking interfaces that has a
  system (Ethernet adapters, serial ports ..)
• IP address associated with each network interface
• Counts the numbers of incoming and outgoing
  datagrams
• Table of information about active TCP connections

39
MIB extensions

• Technology Extensions
• The IAB encouraged groups of vendors to define
  MIBs needed to manage their products
• RFC 1286 describe a MIB for bridges
• It expresses the philosophy of MIB construction

40
Keep MIBs simple !

• A small set of essential objects at starting
• Add only the objects that are needed
• Required objects are essential for either fault
  or configuration management
• Evidence of current use and/or utility
• Limit total number of objects
• Exclude object derived from others
• Avoid causing critical sections to be heavily
  instrumented

41
Private Enterprise Extensions

• Any vendor can request a a subtree
• In the tree of management information
• Define its own variable necessary for its devices

42
SNMP

• How to get the information stored in the MIB
• SNM Protocol identifies
• Type of messages that can be sent between Manager
  and Agent
• Message format
• Communication protocol used

43
SNM Protocol

44
Messages Manager-Agent

• Structure and Identification of Management
  Information
• Each device contains a database of information
  that it would be useful to know about. This
  database is called MIB
• SNMP define a simple set of messages
• Read and write database variables
• Receive trap reports of problem events

45
Remaining questions ...

• How to define and describe MIB variables?
• How are different variables related to one
  another ?
• How to identify a variable that we want to read
  or write ?
• How should the variables be represented ?

46
RFC 1155

• Structure and Identification of Management
  Information for TCP/IP-based Internets
• Follows the ISO /CCITT
• MIB variables are defined and described using the
  ASN.1 (Abstract Syntax Notation 1)
• Datatype definition language
• It allows to create data structures
• Few additional capabilities to go beyond the
  possibilities of other languages

47
RFC 1155 (contd)

• Network management information has been
  incorporated into a large tree
• Administered by ISO and CCITT
• The tree structure helps us to visualize the
  relationship between variables
• The Identifiers for the Network Management are
  issued from the tree
• The name of a parameter is a sequence of number
  along the path from the root of the tree

48
Structure of Management Information

• Structure of the Managed Objects
• Object instead of variable
• Object
• Name, attributes, set of operations
• SMI RFC 1155

49
SMI - Objetivos

• Definir la estructura de una MIB particular
• Definir objetos individuales, incluyendo la
  sintaxis y el valor de cada objeto
• Codificar los valores de los objetos

50
OID ASN.1
internet OBJECT IDENTIFIER iso (1) org (3)
dod (6) 1
51
OIDs

• El nodo internet(1) es OID 1.3.6.1.
• Este valor sirve como prefijo para los nodos del
  siguiente nivel inferior del árbol.
• SMI define cuatro nodos bajo el nodo internet

52
SMI- Cuatro nodos bajo el nodo internet

• directory(1)
• reservado para uso futuro con el OSI directory
  (X.500)
• mgmt(2)
• usado para objetos definidos en documentos
  aprobados por el IAB
• experimental(3)
• usado para identificar objetos utilizados en
  experimentos de Internet
• private(4)
• usados para identificar objetos definidos
  unilateralmente por los fabricantes

53
Subárbol mgmt

• El contiene las definiciones de las MIBs que han
  sido aprobadas por el IAB
• Actualmente, dos versiones de la MIB han sido
  desarrolladas, mib-1 y mib-2
• La segunda es una extensión de la primera
• Ambas fueron provistas con el mismo OID en el
  subárbol de modo que sólo puede haber una de las
  MIBs presentes en cualquier configuración.

54
Expansiones

• Se puede expandir el subárbol mib-2
• reemplazarlo por una nueva revisión
  (presumiblemente mib-3)
• Para expandir mib-2 se define un nuevo subárbol
• Por ejemplo, la remote networking monitoring MIB
  se define como el decimosexto subárbol bajo mib-2
  (mib-2 (16))

55
Expansiones (contd)

• Puede construirse una MIB experimental para una
  aplicación particular
• Los objetos definidos en ella pueden luego ser
  movidos hacia el subárbol mgmt
• Ejemplos de este caso incluyen varias media
  transmission MIBs, una de las cuales es IEEE
  802.5 token ring LAN (RFC 1231)
• Pueden agregarse extensiones privadas al subárbol
  private. Una que esta documentada como RFC es la
  MUX MIB (RFC 1227)

56
Expansiones (contd)

• El subárbol private tiene actualmente definido
  sólo un nodo hijo, el nodo enterprises(1)
• Esta porción del subárbol se usa para permitirle
  a los fabricantes mejorar la gestión de sus
  dispositivos y compartir esta información con
  otros usuarios y fabricantes quienes pueden
  necesitar interoperar con sus sistemas
• Se asigna una rama dentro del subárbol
  enterprises a cada fabricante que se registre por
  un OID enterprises

57
ISO AND CCITT STRUCTURE OF INFORMATION

58
The MIB node

59
Definición de Objetos

• Cada objeto está definido por un tipo y un valor
• La definición de un tipo de objeto es entonces
  una descripción sintáctica
• Una instancia de un objeto es una instancia
  particular de un tipo de objeto que ha sido
  ligada a un valor.

60
Macros para definición de objetos

• Definición de Macro
• especifica la sintaxis de un conjunto de tipos de
  objetos relacionados
• Instancia de Macro
• una instancia generada a partir de una definición
  de macro específica suministrando los argumentos
  para los parámetros en la definición de macro
  especifica un tipo particular
• Valor de una Instancia de Macro
• representa una entidad específica con un valor
  específico

61
Macros para definición...(contd)

• Inicialmente en la RFC 1155 (Structure of
  Management Information)
• La versión en la RFC 1155 se usa para definir
  objetos en la MIB-I.
• Extendida en la RFC 1212 (Concise MIB
  Definitions).
• La versión en la RFC 1212, que incluye más
  información, se usa para definir objetos en la
  MIB-II y otras adiciones recientes a la MIB

62
Macro para objetos gestionados (RFC 1212)
63
Elementos de Macros

• SYNTAX
• la sintaxis abstracta para el tipo de objeto.
  Ésta debe determinar una instancia del tipo
  ObjectSyntax definido en la RFC 1155
• La sintaxis debe construirse usando los tipos
  universal y application-wide permitidos en la SMI
• ACCESS
• Define la forma en la que puede accederse una
  instancia de un objeto, mediante SNMP u otro
  protocolo.
• La cláusula access especifica el mínimo nivel de
  protección requerido por este tipo de objeto.
• Las opciones son read-only, read-write,
  write-only y not-accessible

64
Elementos de Macros

• STATUS
• Indica el soporte de implementación requerido por
  el objeto. Puede ser mandatory u optional
• Alternativamente, un objeto puede especificarse
  como deprecated. Esto significa que debe ser
  soportado, pero que debería ser removido de la
  próxima versión de la MIB
• Finalmente, el status puede ser obsolete, que
  significa que los sistemas gestionados no
  necesitan implementar más ese objeto

65
Sintaxis de Objetos

• Cada objeto dentro de la SNMP MIB se define de
  modo formal
• La definición especifica el tipo de dato del
  objeto, sus estados permitidos y rangos de
  valores, y su relación con otros objetos dentro
  de la MIB
• La notación ASN.1 se usa para definir cada objeto
  individual y también para definir la estructura
  completa de la MIB.
• Para mantener la simplicidad sólo se usa un
  subconjunto de elementos y características de
  ASN.1

66
Tipos - Universal

• integer (UNIVERSAL 2)
• octetstring (UNIVERSAL 4)
• null (UNIVERSAL 5)
• object identifier (UNIVERSAL 6)
• sequence, sequence-of (UNIVERSAL 16)

67
Tipos Application-Wide

• La RFC 1155 lista un conjunto de tipos de datos
  application-wide para SNMP otros tipos podrán
  definirse en futuras RFCs
• Networkaddress
• este tipo se define usando el constructor CHOICE,
  permitiendo la selección de un formato de
  dirección dentro de un número de familias de
  protocolos. Actualmente, la única dirección
  definida es IpAddress
• ipaddress
• es una dirección de 32 bits usando el formato
  especificado en IP   

68
Tipos Application-Wide

• Counter
• es un entero no negativo que se puede incrementar
  pero no decrementar. Se especifica un valor
  máximo de 232 1 cuando el counter alcanza su
  máximo, comienza a incrementarse nuevamente desde
  cero
• Gauge
• es un entero no negativo que puede incrementarse
  o decrementarse, con un valor máximo de 232 1.
  Si se alcanza el valor máximo, mantiene el mismo
  hasta ser reseteado
• Timeticks
• es un entero no negativo que cuenta el tiempo en
  centésimas de segundos desde el momento
  referenciado en la definición de un objeto que
  utilice este tipo     

69
Tipos Application-Wide

• Opaque
• este tipo soporta la capacidad de pasar datos
  arbitrarios. El dato es codificado como OCTET
  STRING para la transmisión.
• El dato en sí mismo puede estar en cualquier
  formato definido por ASN.1 u otra sintaxis

70
SNMP on UDP

• As the creator of SNMP wanted it to be really
  simple
• uncomplicated transport protocol
• need to keep the number of protocol messages type
  small
• simple types like string and integer

71
SNMP on UDP (contd)

• UDP is easy to build and run
• Into devices (repeaters and modems) vendors have
  built simple version of IP and UDP
• Total software needed is small and can be stored
  in a ROM
• UDP is well suited to the brief
  request /response  message used in network
  management communication.

72
SNMP UDP ports
73
Recall that UDP port numbers

• Identify the origin and the destination endpoints
  of a message
• Most standard service operate out of well-known
  ports
• Many client application take a port number out of
  a pool of available port numbers, and they let it
  free when they are done with it

74
Five SNMP v1 PDUs

• Get-request
• Get-next-request
• Set-request
• Get-response
• Trap

75
SNMP exchange of PDUs
76
SNMP v1

• Servicio de Autenticación
• La estación gestionada puede querer limitar el
  acceso a la MIB por parte de estaciones de
  gestión autorizadas
• Política de Acceso
• La estación gestionada puede querer otorgar
  diferentes privilegios de acceso a distintas
  estaciones de gestión

77
SNMP v1 (contd)

• Servicio Proxy
• Una estación gestionada puede actuar como proxy
  de otras estaciones gestionadas. Esto puede
  involucrar la implementación de un servicio de
  autenticación y/o una política de acceso para los
  otros sistemas gestionados en el sistema proxy
• Seguridad
• SNMP, tal como está definido en la RFC 1157,
  proporciona un método de seguridad primitivo y de
  capacidad limitada conocido como comunidad

78
Comunidades SNMP v1

• Concepto local
• Definido en la estación gestionada
• El sistema gestionado establece una comunidad
  para cada combinación deseada de las
  características de autenticación, control de
  acceso y proxy
• Cada comunidad tiene un nombre de comunidad
  (dentro del agente)
• Las estaciones de gestión dentro de esa comunidad
  están provistas con el nombre de comunidad y
  deben utilizarlo en todas las operaciones Get y
  Set

79
Servicio de Autenticación

• Una comunicación es auténtica
• En el caso de un mensaje SNMP, dicho servicio
  debería asegurarle al receptor que el mensaje
  proviene de donde dice ser
• SNMP proporciona un esquema de autenticación
  trivial
• Cada mensaje desde una estación de gestión hacia
  un agente contiene el nombre de comunidad. Este
  nombre funciona como contraseña, y el mensaje se
  asume auténtico si el que lo envía conoce la
  contraseña.

80
Servicio de Autenticación (contd)

• No confiable
• No se permite el control de la red mediante
  operaciones Set
• Se limita a una tarea de monitorización
• El nombre de comunidad podría usarse como
  disparador de un procedimiento de autenticación
  más seguro, pero esto escapa al alcance de la RFC
  1157

81
Política de Acceso

• Definiendo una comunidad, un agente limita el
  acceso a su MIB a un grupo seleccionado de
  estaciones de gestión
• Usando más de una comunidad, el agente puede
  proporcionar diferentes categorías de acceso a la
  MIB para las distintas estaciones de gestión
• Hay dos aspectos para este control de acceso

82
Política de Acceso (contd)

• SNMP MIB view
• Un subconjunto de objetos dentro de la MIB. Para
  cada comunidad pueden definirse diferentes vistas
  de la MIB.
• El conjunto de objetos en una vista no necesita
  pertenecer a un único subárbol de la MIB.
• SNMP access mode
• Un elemento del conjunto (read-only, read-write)
• Para cada comunidad se define un modo de acceso

83
Política de Acceso (contd)

• Un perfil de comunidad SNMP (community profile)
• La combinación de una MIB view y un modo de
  acceso
• El modo de acceso se aplica uniformemente a toda
  la MIB view

84
Política de Acceso (contd)

• Dentro de un perfil de comunidad, dos
  restricciones de acceso separadas deben conciliar
• Una restricción es el modo de acceso adoptado, la
  otra está dada por la cláusula ACCESS incluida en
  la definición de cada objeto de MIB
• A cada comunidad definida en el agente se le
  asocia un perfil de comunidad
• A esta combinación se la conoce como política de
  acceso SNMP (access policy)

85
Clausula Access Acceso SNMP
86
Servicio Proxy

• Un proxy es un agente SNMP que actúa en nombre de
  otros dispositivos
• El concepto de comunidad es útil en el soporte
  del servicio proxy
• Típicamente los dispositivos representados por el
  proxy no soportan TCP/IP y SNMP, aunque en
  algunos casos se utiliza el proxy para minimizar
  la interacción del dispositivo (que soporta SNMP)
  con el sistema de gestión de red

87
Servicio Proxy (contd)

• Por cada dispositivo que el sistema proxy
  representa, se mantiene una política de acceso
  SNMP
• El proxy conoce cuales objetos de la MIB puede
  usar para gestionar el dispositivo representado
• la MIB view y su modo de acceso

88
OIDs - Objetos Columnas

• El OID no es suficiente para identificar la
  instancia
• Hay una instancia de cada objeto por cada fila de
  la tabla
• Técnicas para la identificación de una instancia
  específica de objeto de tabla
• Una técnica de acceso serial
• Orden Lexicográfico
• Una técnica de acceso aleatorio

89
SNMP PDUs Format

• The get-request and the get-response contain the
  same fields
• Easy for an agent to build an answer to a request
  just by filling the holes in the get-request
• Thus, get-request contains fields set a 0 or NULL
  values
• A get-request can be sent for multiple variables
• It contains the list of the variables we want to
  be retrieved
• The get-response fills each value from each
  variable of the list

90
SNMP PDUs Format

• Get-request and Get-response
• Version version of SNMP (0 for v1)
• Community password used to control access to
  node information
• Command one of the five message type.

91
SNMP PDUs Format (contd)

• Get-request and Get-response
• Request ID used to correlate the request and
  its answer.
• Error status in response, it is used to
  indicate if the request was successful or not.
• Error index in case of error indicates which
  variable in the request caused problem
• A list of pairing OBJECT IDENTIFIER (string of
  integer) plus the variable value

92
Transmisión mensaje SNMP

• Construye la PDU usando la estructura ASN.1
  definida en la RFC 1157
• Envía la PDU a un servicio de autenticación
• Junto con las direcciones de transporte fuente y
  destino, y el nombre de comunidad. Este servicio
  realiza una transformación, como ser encriptación
  o inclusión de algún código de autenticación, y
  retorna el resultado.
• Construye el mensaje, consistente en el campo de
  versión, el nombre de comunidad, y el resultado
  devuelto por el paso anterior
• Codifica el nuevo objeto ASN.1 utilizando BER y
  lo pasa al servicio de transporte

93
Recepción de un mensaje SNMP

• Hace un chequeo de la sintaxis del mensaje, y lo
  descarta si falla el chequeo.
• Verifica el número de versión y descarta el
  mensaje si no hay concordancia.
• Pasa a un servicio de autenticación la PDU del
  mensaje, el nombre de la comunidad, y las
  direcciones de transporte de fuente y destino.
• Si falla la autenticación
• se le da aviso a la entidad SNMP, la cual genera
  un trap y descarta el mensaje.

94
Recepción de un mensaje SNMP

• Si la autenticación es exitosa
• se devuelve a la entidad SNMP una PDU en forma de
  un objeto ASN.1 conforme la estructura definida
  en la RFC 1157.
• Hace un chequeo de la sintaxis de la PDU
• Descarta la PDU si el chequeo falla
• Si pasa el chequeo, se selecciona la política de
  acceso usando el nombre de comunidad, y se
  procesa la PDU

95
Variable Bindings

• Es posible agrupar varias operaciones del mismo
  tipo (Set, Get, Trap) en un único mensaje
• Entonces, si una estación quiere pedir todos los
  valores de los objetos escalares en un grupo
  determinado en un agente, puede enviar un único
  mensaje pidiendo todos los valores, recibiendo
  una única respuesta con una lista de todos los
  valores
• Esta técnica reduce notoriamente la carga de
  comunicaciones de gestión

96
Variable Bindings (cont)

• Para implementar el intercambio de múltiples
  objetos, todas las PDUs incluyen el campo
  variablebindings
• Este campo consiste en una secuencia de
  referencias a una instancia de un objeto, junto
  con el valor de los mismos
• En las PDUs donde sólo importa el nombre del
  objeto (por ejemplo, en operaciones Get), la
  entidad receptora del mensaje ignora la parte de
  los valores en el campo variablebindings. La RFC
  1157 recomienda en estos casos que la entidad que
  envía el mensaje complete con el valor NULL de
  ASN.1 la parte de valores mencionada

97
GetRequest PDU

• PDU type
• Indica que es una PDU GetRequest.
• request-id
• El request-id le permite a la aplicación SNMP
  correlacionar las respuestas recibidas con los
  pedidos pendientes.
• También le permite distinguir PDUs duplicadas
  debidas a un servicio de transporte no confiable
• Variable bindings
• Lista de instancias de los objetos cuyos valores
  son requeridos

98
GetRequest PDU (contd)

• PDU GetRequest - PDU GetResponse
• Request-id
• GetRequest es atómica
• Todos los valores o ninguno
• PDU GetResponse incluye el campo variablebindings
  con el valor de cada variable
• Si al menos uno de los valores no se puede
  devolver, no se retorna ningún valor.

99
GetRequest PDU (contd)

• Un objeto en variable bindings no concuerda con
  ningún OID en la MIB view
• Dicho objeto puede ser de un tipo que no tenga
  ningún valor de instancia asociado (por ejemplo,
  objetos tablas o filas)
• Se devuelve PDU GetResponse
• con un error-status de noSuchName
• un valor en el campo error-index que indica la
  posición del objeto que causó el problema en el
  campo variablebindings enviado

100
GetRequest PDU

• La entidad de respuesta podría devolver todos los
  valores solicitados, pero el tamaño de la PDU
  GetResponse excede una limitación local
• En este caso, se retorna una PDU GetResponse con
  un error-status de tooBig.
• La entidad de respuesta no puede devolver al
  menos un valor de los solicitados por alguna otra
  razón
• En este caso, se devuelve una PDU GetResponse con
  un error-status de genErr y un valor en el campo
  error-index indicando la posición del objeto que
  causó el problema

101
GetRequest PDU

• Con SNMP se pueden recuperar sólo objetos hojas
  del árbol MIB
• No es posible recuperar la tabla IP routing
  referenciando el objeto entry (ipRouteEntry), o
  una tabla completa (ipTable)
• Puede recibirse una fila completa o la tabla
  completa
• incluyendo cada una de las instancias de los
  objetos en la lista de variablebindings

102
GetRequest PDU

• GetRequest (ipRouteDest.9.1.2.3,
  ipRouteMetricl.9.1.2.3, ipRouteNextHop.9.1.2.3)

103
GetNextRequest PDU

• La PDU GetNextRequest tiene el mismo patrón de
  intercambio y el mismo formato que la PDU
  GetRequest
• La diferencia está en que, el que responde el
  pedido, observa en el campo variablebindings el
  nombre del objeto y retorna la instancia del
  objeto que sigue en orden lexicográfico al objeto
  nombrado

104
GetNextRequest PDU

• GetNextRequest significa la próxima instancia de
  un objeto en orden lexicográfico, y no el próximo
  objeto
• Al igual que GetRequest, GetNextRequest es
  atómica.
• Importantes implicancias
• Le permite a una estación de gestión descubrir
  dinámicamente la estructura de una MIB view, como
  así también proporciona un mecanismo para la
  búsqueda de tablas cuyas entradas son
  desconocidas.

105
The Trap messages

• Report a serious condition
• To a management station
• The message is send once
• Trap message has fields
• Identifying the version and the community
  password
• Other fields

106
The Trap messages (contd)

• Enterprise field contain
• OBJECT IDENTIFIER which name the device that
  sends the trap
• Generic-trap field contains 7 values
• coldStart , warmStart, linkDown, linkUp
• authenticationFailure
• egpNeighborLoss - an Exterior Gateway Protocol
  neighbour is down
• enterpriseSpecific - The trap is identified as
  not being one of the basic one

107
The Trap messages (contd)

• Specific-trap field
• When the generic-trap value is enterpriseSpecific
  
• Time ticks
• Time since the initialization

108
Managing Traps
109
Use of Enterprise specific traps

• Define hundreds or thousands trap types
• Defined by
• MIB standards group
• standard groups add technology-specific traps,
• Vendors
• add product-specific traps
• Corporate network management organisations
• add traps that meet their special management needs

110
Trap Definition Macro (I)

• RFC 1215 - TRAP-TYPE macro template
• Fields
• Enterprise for the trap definition
• This will point to a MIB subtree , or identify
  the entity the trap has been designed for.
• specific-trap
• is the number of the traps as they are defined

111
Trap Definition Macro (II)

• The macro give the following fields
• List of MIB variables
• that will be carried in the trap message
• Description of the trap
• Optionally
• a reference part that relates to another trap,
  alarm , event ... anything appropriate for a MIB
  module

112
Managing Interfaces

• SNMP V.1
• Ethernet Interface , Token Ring
• FDDI
• RS-232-Like Hardware Interface
• PPP Interface
• DS1/ES1 (T1 or E1) - DS3/ES3 (T3 or E3)
• X.25, Frame Relay...

113
Ethernet Interface

• RFC 1398 MIB
• Definitions of Managed Objects for the
  Ethernet-like Interface Types
• The Ethernet MIB (1.3.6.1.2.1.10.)
• counts of incoming and outgoing traffic
• Statistics table
• Counts of Ethernet errors
• Histogram of collision frequencies.
• Information for TDR test
• OBJECT IDENTIFIERs for popular chipsets

114
SNMP v1 problems

• If for one of the requested variable, the agent
  is unable to provide a value, the whole
  get-request will fail
• The maximal number of value to retrieve is
  limited by the maximum message size handle by the
  manager and the agent
• Expected to be over 484 bytes in SNMP standards

115
SNMP v2

• The main problems of the SNMP v1
• Authentication of the message source
• Protecting these message from disclosure
• Placing access controls on MIB database
• Those problems are solved in SNMP v2
• Significant changes to the format of SNMP PDUs
• Two new protocol operations have been added
• One supports efficient transfer of large amount
  of MIB data
• The other enables a manager to inform another
  manager of significant events

116
SNMP v2

• A multiple requested value
• Get-request, one is not valid or does not exist,
  there will be answers for the other request that
  have been well dealt. Whereas for version 1, no
  response at all was given, only the error message
• Traps same format other PDUs

117
SNMP v2 operation

• The inform-request
• It enables a manager to send some information to
  another manager
• Helps organisation that needs a hierarchy of
  network management stations
• A manager that sends an inform-request will
  receive the echo of its message as proof of
  delivery

118
SNMP v2 operation

• Get-bulk-request
• As message sizes are limited by the local
  capabilities of each agent
• If too much data are asked in an ordinary
  get-request you receive a message "too big" error
  message without data
• The get bulk request allows you to retrieve a lot
  of information
• then you will receive as much data as it is
  possible in your response message
• This request can retrieve stand alone scalar
  variables and / or columns from a table

119
AUTHENTICATION, SECURITY and CONTROL

• SNMP and Agent communicate
• By means of messages
• Transmitted usually in UDP datagrams
• The good state of all the network stands on this
  messages so security is very important
• We need to be sure of the message source and
  about its contents

120
AUTHENTICATION, SECURITY and CONTROL

• We need to be protected against eavesdroppers
• Restrict MIB databases to some applications
• Those are all security, authentication and
  control problems

121
AUTHENTICATION, SECURITY and CONTROL

• SNMP V2 security framework deals with
• the authentication of the message sender
• its contents
• eavesdropper problems
• Supports the use of
• authentication protocol to identify the sources
  reliability
• prevent message modification
• encryption to keep messages privacy

122
AUTHENTICATION, SECURITY and CONTROL

• Digest Authentication Protocol
• The recommended authentication procedure
• Based on the message-digest
• Message-digest
• It is a message treated like a string of 32-bit
  numbers
• It is just a mathematical calculation performed
  on these numbers and included with the message
• The message-digest protocol chops messages into
  bits, mixes it up with a secret ingredient and
  selects a few bits here and there to assemble
  into its result
• The result is sent to the partner with the
  original message

123
AUTHENTICATION, SECURITY and CONTROL

• SNMPv2 is structured so that any privacy protocol
  can be dropped in and used
• The current protocol is a symetric encryption
  using the Data Encryption Standard
• The same key is used to encrypt message and to
  decrypt it.

124
AUTHENTICATION, SECURITY and CONTROL

• SNMP v1
• Easy to implement and maintain
• SNMP v2
• The introduction of authentication and privacy
  helps to keep the network safe
• Implementation is much larger and more complex
• The important information have to be protected
  and kept in the device if a crash comes, those
  information are kept in a non volatile memory
• The SNMPv2 gives many solutions against piracy
  but an attacker can still do many annoying things

125
SNMPv3

• RFCs 2271 to 2275 in January 1998
• This version is build upon the two first versions
  of SNMP
• it reuse the SNMPv2 standards documents (RFC 1902
  to RFC 1908)
• augments the original SNMP and the SNMPv2
• specifications with additional security and
  administration

126
SNMPv3 new features

• Security
• Authentication
• Privacy authorization
• Access Control
• Administrative Framework
• naming of entities, people and policies
• user names
• key management notification destinations
• proxy relationships remotely configurable via
  SNMP operations

127
SNMPv3 Security and Administration

• The SNMPv3 document series
• RFC 2271 to RFC 2275
• SNMPv3 Architecture document
• RFC 2271, to define an architecture for defining
  SNMP Management Frameworks
• It defines a number of terms and clarifies and
  extends the naming of engines and applications
• entities (service providers such as the engines
  in agents and managers)
• identities (service users)
• management information, including support for
  multiple logical contexts.

128
SNMPv3 Architecture document

• Contains a small MIB module
• Implemented by all authoritative SNMPv3 protocol
  engines
• An authoritative engine is the receiver of a
  message such as a get or set
• The sender if the message does not require a
  response

129
Message Processing and Dispatching

• RFC 2272 - defines
• Procedures for dispatching multiple versions of
  SNMP messages to the proper SNMP Message
  Processing Models
• It also provides the way to dispatch PDUs to SNMP
  applications
• Describes one Message Processing Model - the
  SNMPv3 Message Processing Model.

130
SNMPv3 protocol engine

• Must Support at least one Message Processing
  Model
• May support more than one
• For example, in a multilingual system which
  provides simultaneous support of SNMPv3 and
  SNMPv1 and/or SNMPv2

131
SNMPv3 Applications

• Five types of application (SNMP engine)
• RFC 2273
• Command Generators
• Command Responders
• Notification Originators
• Notification Receivers
• Proxy Forwarders
• The document also defines MIB modules for
  specifying targets of management operations, for
  notification filtering, and for proxy forwarding

132
User-based Security Model (USM)

• RFC 2274
• Elements of Procedure for providing SNMP
  message-level security
• The USM protects the user against four threats,
  which are
• modification of information
• masquerade
• message stream modification
• disclosure (optionally)

133
USM uses

• Message Digest Algorithm (MD5)
• Secure Hash Algorithm
• Provide data integrity
• Protect against data modification attacks
• Provide data origin authentication
• Defend against masquerade attacks
• Data Encryption Standard (DES)
• Protect against disclosure

134
USM includes

• MIB
• remotely monitoring and managing the
  configuration parameters for the USM

135
View-based Access Control Model (VACM)

• RFC 2275
• Elements of Procedure for controlling access to
  management information
• The VACM can be associated
• In a single engine implementation with multiple
  Message Processing Models and multiple Security
  Models
• The document also includes a MIB for remotely
  managing the configuration parameters for the
  View-based Access Control Model

136
Monitoring

• The simple part of the SNMP only concern the
  agent with its ressources limitations
• The management station does not have those
  restrictions
• A monitor is a smart, streetwise partner

137
What can be done by monitors ?

• Watch a LAN as a whole.
• Gather information without polling and adding
  traffic.
• Track the traffic flows that contribute the most
  to the network activity.
• Detect failures hard to find by polling.

138
What can be done by monitors ?

• Find duplicate IP address assignments.
• it can be configured to watch for signs of
  troubles
• because it is "intelligent" made of a CPU,
  memory and hard-drive resources
• it could be asked to send trap message when an
  error counter passes over danger threshold

139
What can be done by monitors ?

• gather and tabulate many statistics
• Monitor operator can configure the monitor to
  show the data in the most significant way for the
  user.
• Usually, monitors are attached to LANs, but
• it can watch WAN interfaces, track traffic and
  check whether errors stay within acceptable
  bounds. They are bought because it is invaluable
  for problem diagnosis
• The variable of RMON are contained in the RMOB MIB

140
Remote Network Monitoring

• RMON MIB RFC 1271 (1991)
• tools needed by a network management station to
  configure and control a monitor
• read out data and reports
• receive alarms
• There are rules to RMON (operator rights)
• rights to one operator
• share them between different users
• Users have to select their own administrative
  model