SNMP

Baseado em slides gentilmente cedidos pelo Prof.

João Henrique Kleinschmidt da UFABC.
 Gerência Internet: Introdução
2

 À exemplo do que ocorre com a abordagem da

ISO, a arquitetura SNMP define também um
modelo de comunicação e um modelo de
informação.
 Essa arquitetura tem incorporado várias inovações
ao longo de sua existência, de forma que existem
atualmente três versões:
 SNMPv1
 SNMPv2
 SNMPv3
3 SNMPv1
 SNMPv1: Especificações
4

 Principais especificações relativas à primeira

versão do protocolo SNMP (SNMPv1):
RFC Título
1155 Structure and identification of management information for
TCP/IP-based internets
1157 Simple Network Management Protocol (SNMP)
1212 Concise MIB definitions
1213 Management Information Base for Network Management of
TCP/IP-based internets: MIB-II
(Updated by RFC 2011, RFC 2012, RFC 2013)
 Mensagens SNMPv1
5

 Do gerente para o agente:

 get

 getnext

 set

 Do agente para o gerente:

 getresponse

 trap
 Formato da mensagem e das PDUs
6
SNMPv1
 SNMPv1: Comunidades
7

 Um nome de comunidade representa um

relacionamento entre um agente e um (ou vários)
gerentes, definindo características de autenticação
e controle de acesso.

 O nome de comunidade não é encriptado, o que

restringe muitas vezes a gerência à simples
monitoração.
 SNMPv1: Operações de Leitura
8

 As operações de leitura dos valores de um ou mais objetos

gerenciados são iniciadas pelos gerentes com o envio de PDUs
GetRequest ou GetNextRequest.

 Essas PDUs são endereçadas à porta UDP 161 do agente

SNMPv1 remoto.
 SNMPv1: Respostas da Leitura
9

 As PDUs GetRequest e GetNextRequest são replicadas

atomicamente com o envio de PDUs GetResponse.
 SNMPv1: Operações de Escrita
10

 As operações de escrita dos valores de um ou mais objetos

gerenciados são iniciadas pelos gerentes com o envio de PDUs
SetRequest.

 Essas PDUs também são endereçadas à porta UDP 161 do

agente SNMPv1 remoto.
 SNMPv1: Respostas da Escrita
11

 As PDUs SetRequest também é replicada atomicamente com o

envio de uma PDU GetResponse.
 SNMPv1: Mensagem Trap
12

 A PDU Trap é uma notificação assíncrona utilizada pelo

agente SNMP para informar um ou mais gerentes sobre algum
evento significativo.

 Essa PDU é endereçada à porta UDP 162 do(s) gerente(s).

 SNMPv1: Regras de Codificação
13

 PDUs e objetos gerenciados são codificados para transmissão

usando-se BER (Basic Encoding Rules).

 Em BER, cada elemento é estruturado como uma lista TLV

(Type, Length, Value).
 SNMPv1: Deficiências
14

 Deficiências observadas no SNMPv1:

 Inabilidade em coletar um grande volume de dados
 Não é possível obter visões consistentes de tabelas de
objetos gerenciados.
 Escalabilidade limitada
 Modelo é fortemente centralizado em torno de uma única
estação de gerência.
 Ausência de mecanismos eficazes de segurança
 Nome de comunidade não sofre encriptação, inibindo a
realização de operações mais sensíveis.
15 SNMPv2
 Gerência Internet: SNMPv2
16

 Um conjunto de RFCs referenciadas como SNMP-

seguro foram emitidas com o status de Proposed
Standard em julho de 1992.
 O SNMP-seguro endereçava exclusivamente
aspectos de segurança ausentes no SNMPv1.
 Outra abordagem denominada SMP (Simple
Management Protocol) foi emitida também em julho
de 1992 sob a forma de oito documentos (não
RFCs) submetidos à IETF.
 Gerência Internet: SNMPv2
17

 Além de endereçar aspectos de desempenho e

funcionalidade, o SMP incorporava também as
melhorias de segurança propostas pelo SNMP-seguro.
 Após a publicação do SNMP-seguro e do SMP, surgiu
um consenso na comunidade Internet de que era hora
de se criar uma segunda versão para o SNMP.
 Dois grupos de trabalho foram formados: um deles
endereçava aspectos de segurança, enquanto o outro
endereçava os demais aspectos. O esforço combinado
foi publicado como Internet Standards em Março de
1993.
 Gerência Internet: SNMPv2
18

 Após anos de experiência como SNMPv2, um Grupo de

Trabalho da IETF revisou as especificações.
 O resultado dessa revisão foi um novo conjunto de
RFCs, emitidas em 1996.
 Os sofisticados mecanismos de segurança do SNMPv2
foram substituídos por outro baseado em nomes de
comunidade, como é utilizado no SNMPv1.
 Por essa razão, o SNMPv2 atualmente vigente também
é conhecido como SNMPv2c (Community-based).
 SNMPv2: Especificações
19

RFC Título
1901 Introduction to Community-Based SNMPv2
2578 Structure of Management Information Version 2 (SMIv2)
2579 Textual Conventions for SMIv2
2580 Conformance Statements for SMIv2
3416 Protocol Operations for SNMPv2
3417 Transport Mappings for SNMPv2
3418 Management Information Base for SNMPv2
3584 Coexistence Between Version 1, Version 2, and Version 3 of
the Internet-standard Network Management Framework
 SNMPv2: SMIv2
20

 A SMI definida para o SNMPv2 é um superconjunto

daquela definida para o SNMPv1.
 Ela estabelece mecanismos mais elaborados para a
definição de objetos gerenciados e MIBs.
 As melhorias providas concentraram-se nas
seguintes áreas:
 Definição de objetos
 Tabelas conceituais
 Definição de notificações
 Módulos de informação
 SMIv2
21
 Mensagens SNMPv2 e 3
22

 Do gerente para o agente:

 get
 getnext
 Set
 getbulk
 inform
 report
 Do agente para o gerente:
 getresponse
 trap
 getbulkresponse
 inform
 report
 Formato da mensagem e das PDUs
23
SNMPv2
 SNMPv2: Respostas de Leitura
24

 As PDUs GetRequest e GetNextRequest são replicadas com o

envio de PDUs Response – neste caso, porém, respostas
parciais são permitidas.
 SNMPv2: GetBulkRequest
25

 As PDUs GetBulkRequest foi criada especificamente para a

tarefa de coleta volumosa de dados.
 Essa PDU tem dois campos não encontrados em quaisquer
outras PDUs: non-repeaters e max-repetitions.
 SNMPv2: GetBulkRequest
26

 non-repeaters: Qtde. de variáveis presentes em

variablebindings para as quais uma única instância é
retornada.
 max-repetitions: Qtde. de instâncias a serem
retornadas para as variáveis restantes de
variablebindings.
 SNMPv2: GetBulkRequest
27

 Exemplo de utilização da PDU GetBulkRequest:

 SNMPv2: SetRequest
28

 PDUs SetRequest são replicadas com PDUs Response.

 O processamento que ocorre na troca dessas PDUs difere um
pouco daquele que ocorre no SNMPv1.
 SNMPv2: InformRequest
29

 PDUs InformRequest são trocadas entre gerentes SNMPv2,

sendo replicadas por PDUs Response.
 Elas introduzem descentralização à arquitetura SNMP.
 SNMPv2: InformRequest
30

 Exemplo de utilização da PDU InformRequest:

 SNMPv2: Trap
31

 As PDU TRAP SNMPv2 difere em formato daquela definida

para o SNMPv1. Porém, assim como acontece no SNMPv1,
nenhuma réplica é emitida.
 SNMPv2: Avaliação
32

 Vantagens introduzidas pelo SNMPv2:

 SMI mais elaborada, com maior número de tipos e
facilidades de manipulação de tabelas.
 Facilidade de coleta volumosa de dados, mediante
criação de uma PDU especializada em tal tarefa.
 Modelo mais descentralizado, também viabilizado
através de uma PDU especialmente criada para tal.
 Deficiência ainda observada:
 Ausência de mecanismos eficazes de segurança na
troca de PDUs entre gerentes e agentes.
33 SNMPv3
 SNMPv3
34

 Vários grupos independentes começaram a trabalhar

em melhorias de segurança para o SNMPv2.
 Duas abordagens sobressaíram-se: SNMPv2u e
SNMPv2*. Elas serviram como insumo para o Grupo de
Trabalho SNMPv3 da IETF, em Março de 1997.
 Em Janeiro de 1998, esse grupo produziu uma série de
documentos com o status de Proposed Standard.
 Em Dezembro de 2002, estes documentos foram
atualizados e receberam o status de Internet Standard.
 O SNMPv3 incorpora as funcionalidades definidas nas
versões anteriores e adiciona mecanismos de segurança
à arquitetura.
 Evolução da Arquitetura SNMP
35
 Especificações SNMPv3
36

RFC Título Data

3410 Introduction and Applicability Statements for Internet-Standard Dez. 2002
Management Framework
3411 An Architecture for Describing Simple Network Management Dez. 2002
Protocol (SNMP) Management Frameworks
(Updated by RFC 5343, RFC 5590)
3412 Message Processing and Dispatching for the Simple Network Dez. 2002
Management Protocol (SNMP)
(Updated by RFC 5590)
3413 Simple Network Management Protocol (SNMP) Applications Dez. 2002
3414 User-based Security Model (USM) for version 3 of the Simple Dez. 2002
Network Management Protocol (SNMPv3)
(Updated by RFC 5590)
3415 View-based Access Control Model (VACM) for the Simple Dez. 2002
Network Management Protocol (SNMP)
 Arquitetura SNMP atual
37
 +------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-------------------------------------------------------------------+
| +--------------------------------------------------+ |
| | Transport Subsystem | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| | | UDP | | TCP | | SSH | | TLS | . . . | other | | |
| | +-----+ +-----+ +-----+ +-----+ +-------+ | |
| +--------------------------------------------------+ |
| ^ |
| | |
| Dispatcher v |
| +-------------------+ +---------------------+ +----------------+ |
| | Transport | | Message Processing | | Security | |
| | Dispatch | | Subsystem | | Subsystem | |
| | | | +------------+ | | +------------+ | |
| | | | +->| v1MP |<--->| | USM | | |
| | | | | +------------+ | | +------------+ | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v2cMP |<--->| | Transport | | |
| | Message | | | +------------+ | | | Security | | |
| | Dispatch <--------->| +------------+ | | | Model | | |
| | | | +->| v3MP |<--->| +------------+ | |
| | | | | +------------+ | | +------------+ | |
| | PDU Dispatch | | | +------------+ | | | Other | | |
| +-------------------+ | +->| otherMP |<--->| | Model(s) | | |
| ^ | +------------+ | | +------------+ | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | Application | | | | Applications | | Application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
38
 Gerente SNMPv3
39
 Gerente SNMPv3
40

 O Dispatcher pode ser compreendido como um simples gerente de tráfego.

 Gerente SNMPv3
41

 O Subsistema de Processamento de Mensagens prepara mensagens para

transmissão e processa mensagens recebidas.
 Gerente SNMPv3
42

 O Subsistema de Segurança realiza funções de autenticação e privacidade.

 Agente SNMPv3
43
 Agente SNMPv3
44

 O Subsistema de Controle de Acesso provê serviços de autorização para

controlar o acesso às MIBs para leitura e escrita de valores de objetos gerenciados.
 Fluxo de Mensagens
45

 Fluxo originado por um Gerador de Comandos ou um Gerador de Notificações.

 Fluxo de Mensagens
46

 Fluxo originado por um Respondedor de Comandos.

 Formato da Mensagem SNMPv3
47
 Formato da Mensagem SNMPv3
48

 msgVersion: setado para snmpv3 (3).

 Formato da Mensagem SNMPv3
49

 msgID: identificador único usado por duas entidades SNMP para coordenação de
mensagens de solicitação e resposta. Vai de 0 até 231-1.
 Formato da Mensagem SNMPv3
50

 msgMaxSize: tamanho máximo da mensagem enviada ou recebida por uma

entidade SNMP. Vai de 484 até 231-1 octetos.
 Formato da Mensagem SNMPv3
51

 msgFlags: um octeto contendo três flags nos seus três dígitos menos significativos:
reportableFlag, provFlag e authFlag.
 Formato da Mensagem SNMPv3
52

 Comentários sobre o msgFlags:

 Se reportFlag for setado em 1, uma PDU Report deve ser enviada (caso das PDUs
Get/SetRequest e Inform). O contrário ocorre quando ela é setada em 0 (caso para PDUs
Response, Trap e Report).
 Para os bits privFlag e authFlag, o comportamento é o seguinte:
 Formato da Mensagem SNMPv3
53

 msgSecurityModel: indica qual modelo de segurança foi utilizado para o

preparo da mensagem. Vai de 0 até 231-1. Valores reservados são 1 (SNMPv1),
2 (SNMPv2) e 3 (SNMPv3).
 Formato da Mensagem SNMPv3
54

 msgGlobalData: contém parâmetros necessários pelo Subsistema de

Processamento de Mensagens para coordenação das mensagens.
 Formato da Mensagem SNMPv3
55

 msgSecurityParameters: contém parâmetros relacionados ao Subsistema de

Segurança, não sendo portanto interpretados pelo Subsistema de Processamento
de Mensagens ou o Dispatcher.
 Formato da Mensagem SNMPv3
56

 contextEngineID: identifica inequivocamente uma entidade SNMP.

 Formato da Mensagem SNMPv3
57

 contextName: identifica inequivocamente um contexto particular dentro do

escopo de um contextEngineID associado.
 Formato da Mensagem SNMPv3
58

 scopePDU: informação necessária pelas aplicações de processamento das PDUs.

Contém uma PDU num contexto que é inequivocamente identificado pelos campos
contextNAME e contextEngineID.
 Conceitos de Segurança
59

 Confidencialidade (Sigilo): apenas o remetente e o

destinatário pretendido devem “entender” o conteúdo da
mensagem
 remetente cifra (codifica) msg
 destinatário decifra (decodifica) msg
 Autenticação: remetente e destinatário querem confirmar a
identidade um do outro
 Integridade e não-repudiação de Mensagem: remetente e
destinatário querem garantir que a mensagem não seja
alterada (em trânsito ou após) sem que isto seja detectado
 Disponibilidade e Controle de Acesso: os serviços devem
estar acessíveis e disponíveis para os usuários
 Melhorias de Segurança
60

 USM – User-based Security Model

 VACM – View Access Control Model
 USM – User-based Security Model
61

 O USM (User-based Security Model) do SNMPv3

oferece proteção contra os seguintes ataques:
 Modificação da informação
 Mascaramento
 Modificação do fluxo de mensagens
 Observação do conteúdo de mensagens

 Porém, o USM não protege contra os seguintes

ataques:
 Negação de serviço
 Análise de tráfego
 Núcleo com Autoridade
62

 Conceito de Núcleo com Autoridade (authoritative

engine):
 Se uma mensagem contiver uma PDU que requer uma
resposta (Get, GetNext, GetBulk, Set ou
Inform), então seu receptor será o núcleo com
autoridade.
 Se uma mensagem contiver uma PDU que não requer uma
resposta (Trap, Response ou Report), então seu
emissor será o núcleo com autoridade.
 Conclusão:
 Considerando um modelo simples gerente-agente, é o
agente quem possui o núcleo autorizado.
 Núcleo com Autoridade
63

 Qual a importância desta definição?

A pontualidade da mensagem é determinada em
relação ao relógio mantido pelo núcleo com
autoridade
 As mensagens enviadas contêm o valor de relógio deste
núcleo e o receptor (sem autoridade) pode sincronizar com
este relógio
 Processo de localização de chave, permite que uma
entidade principal possua chaves armazenadas em
múltiplos núcleos (engines)
 Objetos
64

Objetos snmpEngineBoots e snmpEngineTime:

 São mantidos por núcleos autorizados, sendo
inicialmente setados em 0.
 snmpEngineTime é incrementado a cada segundo,
até chegar a 231− 1.
 Nesse valor, snmpEngineBoots é incrementado e
snmpEngineTime é setado em 0 e recomeça a ser
incrementado.
 se o sistema for reinicializado, snmpEngineBoots será
incrementado e snmpEngineTime será setado em 0 e
recomeçará a ser incrementado.
 Objetos
65

 Interpretação dada para esses objetos:

 snmpEngineBoots representa a quantidade de
vezes em que o núcleo autorizado foi (re)inicializado
desde a sua configuração original.
 snmpEngineTime representa a quantidade de
segundos decorridos desde a última (re)inicialização do
núcleo autorizado.
 Propósito desses objetos:
 permitir a sincronização entre núcleos SNMP.
 Formato da Mensagem SNMPv3
66

 msgAuthoritativeEngineID: identificador do núcleo com autoridade

envolvido na troca dessa mensagem.
 Formato da Mensagem SNMPv3
67

 msgAuthoritativeEngineBoots: valor do snmpEngineBoots no núcleo

com autoridade envolvido na troca dessa mensagem.
 Formato da Mensagem SNMPv3
68

 msgAuthoritativeEngineTime: valor do snmpEngineTime no núcleo

com autoridade envolvido na troca dessa mensagem.
 Formato da Mensagem SNMPv3
69

 msgUserName: o usuário (principal) em cujo interesse a mensagem está sendo

trocada.
 Formato da Mensagem SNMPv3
70

 msgAuthenticationParameters: Null se a autenticação não estiver

sendo utilizada nessa troca. Caso contrário, esse é um parâmetro de autenticação
(para o USM, um código de autenticação de mensagem HMAC – Hash-based
Message Authentication Code).
 Formato da Mensagem SNMPv3
71

 msgPrivacyParameters: Null se a privacidade não estiver sendo utilizada

nessa troca. Caso contrário, esse é um parâmetro de privacidade (para o USM, um
valor usado para formar o IV (Initial Vector) do modo CBC (Cipher Block Chaining )
do algoritmo DES (Data Encryption Standard). A RFC3826 apresenta o uso do AES
(Advanced Encryption Standard)
 Sincronização
72
 Sincronização
73
 Estabelecimento de janelas de tempo
74

 As mensagens devem ser recebidas dentro de uma

janela de tempo razoável para evitar atrasos e
ataques de reprodução (replay)
 Fatores determinantes para o projeto:
 precisão dos relógios envolvidos
 atrasos fim-a-fim
 frequência de sincronização

 Implicação dos erros cometidos no projeto:

 janelas muito pequenas rejeitarão mensagens autênticas.
 janelas muito grandes aumentarão a vulnerabilidade aos
ataques por réplica ou atraso.
 Estabelecimento de janelas de tempo
75
 Estabelecimento de janelas de tempo
76
 Sincronização e Janelas de Tempo
77

Observação:
 Os mecanismos de sincronização e janelas de tempo só
podem ser aplicados se:
1. Autenticação for empregada.
2. A mensagem for considerada autêntica via HMAC.
 Essa restrição é essencial porque o escopo da
autenticação inclui os campos
 msgAuthoritativeEngineID,
 msgAuthoritativeEngineBoots e
 msgAuthoritativeEngineTime.
 Descoberta
78

 O USM requer o uso de um processo de descoberta

para obter informação suficiente sobre núcleos com
autoridade antes de qualquer comunicação.
 Através da descoberta, um núcleo SNMP sem
autoridade aprende o valor do ID do núcleo com
autoridade e entra em sincronismo com esse núcleo.
 O processo de descoberta é composto por dois passos,
sendo o primeiro deles obrigatório. O segundo é dado
apenas quando a autenticação for necessária.
 A ser descritos a seguir.
 Descoberta
79

 Passo 1: núcleo sem autoridade aprende a ID do núcleo com autoridade.

 Descoberta
80

 Passo 2: núcleo sem autoridade estabelece sincronismo com núcleo com

autoridade.
 USM: Funções Criptográficas
81

 No USM, são utilizadas duas funções criptográficas:

autenticação e privacidade.
 Para suportá-las, cada núcleo SNMP mantém um
par de chaves authKey e privKey para cada
um dos núcleos com os quais se comunica.
 Os valores de authKey e privKey servem de
subsídio para a geração e verificação dos campos
msgAuthenticationParameters e
msgPrivacyParameters.
 Porém, eles não são acessíveis através do SNMPv3.
 Geração de Parâmetros de
82
Autenticação e Privacidade
 MIB usmUser
83
 Criação da Mensagem junto ao USM
84
 Recepção da Mensagem junto ao USM
85
 Gerência de Chaves
86

 Os pares authKey e privKey usados na

comunicação entre um núcleo SNMP e vários outros
núcleos são, na verdade, derivados de um único par
de chaves.
 As chaves authKey e privKey são chamadas de
chaves locais.
 A gerência de chaves lida com a criação do par de
chaves originais e com a geração e atualização
das chaves locais.
 Gerência de Chaves:
87
geração do par de chaves original
 As chaves de autenticação e privacidade originais
(string de bits) são geradas a partir de senhas.
 O processo de geração dessas chaves não utiliza
nenhum repositório externo especializado no
armazenamento de chaves.
 Além disso, ele aumenta a lentidão na execução de
ataques do estilo força bruta.
 É composto por dois passos.
 Gerência de Chaves:
88
geração do par de chaves original
 Gerência de Chaves:
89
geração de chaves locais
 Consiste no processo, composto por dois passos,
para a geração de subchaves (chaves locais).
 Objetiva evitar as seguintes medidas:
 Um usuário tenha que relembrar pares de chaves cuja
quantidade aumenta com a adição de novos sistemas
gerenciados.
 Um adversário aprenda uma chave para um agente e
esteja apto a personificar qualquer outro agente para
qualquer usuário, ou vice-versa.
 Geração de chaves originais e chaves
90
locais
 VACM – View-based Access Control
91
Model
 Determina se o acesso a objetos gerenciados numa
MIB local por entidades remotas deve ser
permitida.
 Utiliza uma MIB que define a política de controle
de acesso para este agente, tornando possível
configurações remotas.
 Define cinco elementos: Grupos, Nível de Segurança,
Contextos, Visões de MIB e Política de Acesso.
 Grupos
92

 Grupo: é definido como um conjunto de tuplas

<securityName,securityModel>, ao qual
associa-se um groupName.
 securityName e securityModel são equivalentes
aos campos msgUserName e msgSecurityModel da
mensagem SNMPv3.
 Nível de Segurança
93

 Nível de Segurança: obtido a partir do campo

msgFlags da mensagem SNMPv3. Apenas
relembrando...
 noAuthNoPriv
 authNoPriv
 authPriv
 Contextos
94

 Contexto: trata-se de um subconjunto de objetos

gerenciados numa MIB local.
 Uma determinada entidade SNMP é identificada
por um contextEngineID.
 Esta entidade pode manter vários contextos
diferentes.
 Cada um destes contextos é identificado por um
contextName diferente.
 Visões de MIB
95

 Visão de MIB: é definida em termos de uma

coleção, ou família, de subárvores de MIBs.
 Uma tabela que faz uso de subárvores para definir
subconjuntos de objetos gerenciados possui os
seguintes parâmetros:
 Subtree: OID que identifica a subárvore.
 Mask: permite refinar a identificação da subárvore no
nível de objetos gerenciados individuais.
 Type: informa se a subárvore está incluída ou excluída
da Visão.
 Política de Acesso
96

 Política de Acesso: baseia-se nos seguintes

parâmetros:
A entidade solicitando o acesso (principal).
 O nível de segurança empregado na solicitação.
 O modelo de segurança utilizado para processamento
da mensagem de solicitação.
 O contexto da MIB para a solicitação.
 O objeto gerenciado solicitado.
 O tipo de acesso solicitado (leitura, escrita ou
notificação).
 MIB VACM
97
(View-based Access Control Model)
 Lógica do VACM
98
 Parâmetros da MIB VACM
99

 Parâmetros da MIB VACM para configuração inicial “Semi-Security”.

100 SNMP: Limitações do Modelo
 SNMP: Limitações do Modelo
101

 Escalabilidade e eficiência
 Aumento do overhead da rede
 Aumento de atrasos (latência)

 Capacidade de processamento do gerente

 Limite de segmento do gerente

 SNMP: Limitações do Modelo
102

 Escalabilidade e eficiência
 Transferência ineficiente de grande quantidade de
dados
 Limitaçãodo get-next
 Get-bulk overshoot effect
 Tamanho máximo de mensagem SNMP – datagrama UDP

 Ausência de mecanismos de compressão

 Baixa eficiência do BER

 Protocolo de transporte não confiável (UDP)

 SNMP: Limitações do Modelo
103

 Segurança
 Mecanismo de comunidades limitado (v1/v2)
 Não pode ser considerado como autenticação
 Texto da comunidade trafega em claro

 Configurações complexas no SNMPv3

 Mecanismo de Chaves Compartilhadas inseguro (v3)

 Dificuldade de atravessar Firewalls

 SNMP: Limitações do Modelo
104

 Gerenciamento Integrado e Configurações de

redes
 Modelo de informações limitado
 Não orientado a objetos

 Não hierárquico

 Difícil programação de Interfaces de Gerenciamento

mais aprimoradas devidos às limitações