48
“Arquitectura(s)” de gestão IETF As “arquitecturas” definidas pelo IETF para a gestão de redes assentes no protocolo IP, possuem a seguinte característica geral: simplicidade Motivações para a gestão na Internet O crescimento da Internet em número e diversidade Alguma da evolução histórica 1960-70: ICMP- Internet Control Message Protocol Protocolo mais de monitorização que propriamente gestão 1987: SGMP (Simple Gateway Monitoring Protocol) Monitorização de Gateways HMP (Host Monitoring Protocol) Monitorização de estações terminais (hosts) HEMS (High-level Entity Management System) Generalização do HMP SNMPv2 Simple Network Management Protocol Version 2 SNMPv3 Simple Network Management Protocol Version 3 – 1990: CMOT- CMIP Over TCP/IP Adaptação do CMIP para a pilha protocolar TCP/IP 1990: SNMP- Simple Network Management Protocol • Versão melhorada do SGMP

“Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

  • Upload
    others

  • View
    0

  • Download
    0

Embed Size (px)

Citation preview

Page 1: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

“Arquitectura(s)” de gestão IETF• As “arquitecturas” definidas pelo IETF para a gestão de redes assentes

no protocolo IP, possuem a seguinte característica geral: simplicidade• Motivações para a gestão na Internet

– O crescimento da Internet em número e diversidade

• Alguma da evolução histórica– 1960-70: ICMP- Internet Control Message Protocol

• Protocolo mais de monitorização que propriamente gestão– 1987: SGMP (Simple Gateway Monitoring Protocol)

• Monitorização de Gateways– HMP (Host Monitoring Protocol)

• Monitorização de estações terminais (hosts)– HEMS (High-level Entity Management System)

• Generalização do HMP

– SNMPv2 Simple Network Management Protocol Version 2– SNMPv3 Simple Network Management Protocol Version 3

– 1990: CMOT- CMIP Over TCP/IP• Adaptação do CMIP para a pilhaprotocolar TCP/IP

– 1990: SNMP- Simple NetworkManagement Protocol• Versão melhorada do SGMP

Page 2: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP e CMOT: Evolução ou revolução?• Opção entre SNMP e CMOT

– Características SNMP• Simplicidade!• Solução de curto prazo

– Características CMOT• Evolução para OSI• Solução de longo prazo

• O IAB (Internet Architecture Board decretou que: “SNMP e CMOT usassem amesma base de dados de objectos de gestão”, i.e.– ambos os protocolos usam o mesmo conjunto de variáveis de Monitorização e de

Controlo, com os mesmos formatos em qualquer Host, router, bridge ou qualqueroutro objecto gerido

– Uma única SMI (Structure of Management Information), i.e. a convenção de base parao formato dos objecto

– Uma única MIB (Management Information Base), i.e. a estrutura da base de dados

Constatação prática:Objectos OSI são sofisticados e os Objectos SNMP são simples (variáveis)O IAB abdicou da sua recomendação e o OSI e SNMP desenvolveram-seindependentemente

Page 3: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de Organização IETF para gestão

Gestor

Ex: Router

Agente

MIB

SNMP

SNMP

Ex: Servidor

Agente

MIB

Ex: PC

Agente

MIB

Gestor

SNMP

SNMP

Características:– Arquitectura Cliente-Servidor.– Gestor contém as aplicações de gestão e

faz a interface com o utilizador.– Agente é responsável por um conjunto

de recursos geridos.– O Gestor pode monitorizar ou controlar

os recursos através de Agentes,mantendo uma base de dados com ainformação relevante sobre a rede

– O Agente estrutura a informação degestão numa MIB.(MIB - Modelo de Informação)

• RFC 1157 Simple Network ManagementProtocol – SNMP• define o protocolo usado para gerir os

objectos.(SNMP - Modelo de Comunicação)

Page 4: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de Informação IETF para gestãoCaracterísticas:

– Os objectos da MIB são in de acordo com a SIB– Cada objecto da MIB é um objecto escalar, pelo que não há os conceitos de classes,

herança, encapsulamento, …– As MIBs Internet definem a estrutura, o significado e a identificação dos recursos que

podem fazer parte da MIB dum Agente.– A MIB dum Agente contém apenas os tipos dos objectos geridos que podem ser

instanciados nos equipamentos que gere.– A Identificação de objectos é efectuada através da Árvore de Registo Internet (ARI)

• RFC 1155 Structure and Identification of Management Information for TCP/IP-based networks• SMI: descreve como os objectos contidos na MIB são definidos

• RFC 1213 Management Information Base for Network Management of TCP-IPbased Internets– MIB-II: descreve os objectos de gestão contidos na MIB– possibilidade adição de sub-árvores:

• RFC 1212 Concise MIB Definition– definição do formato para a produção de módulos MIB

• Exemplos:– RFC 1643 Definition of managed Objects for Ethernet-like Interface Types– RFC 1757 - Remote Network Monitoring Management Information Base

Page 5: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de Informação IETF para gestãoDefinição e utilização de MIBs proprietárias:• Possibilitam gerir aspectos específicos dos produtos• Possibilidade de registar os objectos proprietários na ARI de forma não

ambígua• Problemas: Um gestor não é capaz de gerir o que não conhece

– Procedimento:1. O Agente desenvolve uma descrição textual e uma descrição formal da MIB

proprietária2. O Gestor carrega e compila a descrição forma a incluí-la na sua biblioteca

– Diferentes Modelos de Informação nas diferentes versões do SNMPdificultam esta operação.

Page 6: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de Informação:Árvore de Registo na Internet

root

itu-t (0) iso (1) join iso/itu-t (2)

org (3)

dod (6)

internet (1)

mib -2 (1) ATM (41) X.25 (44)

recursos nós (36)

IBM (2) HP (11)

dir- (1) mgmt (2) exper. (3) priv.(4)

empresas (1)

1.3.6.1.2.1iso.org.dod.internet,mgmt.mib-2

(tipo OBJECT-IDENTIFIER do ASN.1)

Árvore apenas de Registo• Não existe o conceito de

herança

MIBs privadas/proprietárias

Page 7: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação: Sintaxe dos ObjectosSintaxe dos objectos no SMI (RFC 1155): tipos de dados pré-definidos

• Dependentes da aplicação:Network Address

IpAddress

Time tick

Gauge

Counter

Opaque

• Independentes da aplicação:– Tipos primitivos

INTEGER

OCTECT STRING

OBJECT IDENTIFIER

NULL

– ConstrutoresSEQUENCE

SEQUENCE OF

• Time tick tempo em centésimos de segundo

• Gauge contador up-down de 32 bits, números positivos, que bloqueia quando atinge o valor máximo, até que seja feito o reset.

• Counter contador circular de 32 bits, números positivos

• Opaque transferência de qualquer tipo de dados

Page 8: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação: exemplo de ramo da ARI

mib- 21.3.6.1.2.1

ip 1.3.6.1.2.1.4

iplnReceives1.3.6.1.2.1.4.3

ipRouteTable1.3.6.1.2.1.4.21

ipRouteEntry1.3.6.1.2.1.4.21.1

ipRouteNextHop1.3.6.1.2.1.4.21.1.7

ipRouteDest1.3.6.1.2.1.4.21.1.1

ObjectoEscalar

Tabela

Page 9: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação: exemplo de objecto MIB

SNMP

GestorAcessos internos

iplnReceives 25

Counter Value

Agente

ipRouteDest … ipRouteNextHop …

9.1.2.3 … 99.0.0.3 …

10.0.0.51 … 89.1.1.42 …

10.0.0.77 … 89.1.1.42 ...

MIB do Agente

mib- 2

ip

iplnReceives ipRouteTable

ipRouteEntry

ipRouteNextHopipRouteDest

MIB

Grupo

Tabela

Linha

Variável

Instância = tipo de objecto + valor

Page 10: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

ipInReceives OBJECT TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION ´The total number of input datagrams received from

interfaces… .´::= {ip 3}

Modelo de informação:definição de objectos escalares (SMIv1)

MACRO OBJECT-TYPE: • Nome e Identificador• Sintaxe • Tipo de acesso• Estado• Descrição informal

•Localização do ramo na ARI

Page 11: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação:definição de tabelas (SMIv1)

• Modelo de Informação SMI suporta apenas tabelas bidimensionais.• As entradas da tabela são objectos escalares.• A definição de tabelas envolve :

– a utilização dos construtores SEQUENCE e SEQUENCE-OF– a utilização dum novo campo na macro OBJECT-TYPE: o campo INDEX-PART

Page 12: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação:exemplo de definição de tabelas (ipRoute)

ipRouteTable OBJECT-TYPESYNTAX SEQUENCE OF IpRouteEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION<<Tabela de encaminhamento IP>>

::= { ip 21}

IpRouteEntry OBJECT-TYPESYNTAX IpRouteEntryACCESS not-accessibleSTATUS mandatoryDESCRIPTION<<Rota para um dado destino>>INDEX {ipRouteDest }

::= { ipRouteTable 1}

IpRouteEntry ::= SEQUENCE {ipRouteDest IpAddress, ...ipRouteNextHop IpAddres, ..

}

ipRouteDest OBJECT-TYPESYNTAX IpAddressACCESS read-writeSTATUS mandatoryDESCRIPTION<<Endereço de destino da rota>>

::= {ipRouteEntry 1}

ipRouteNextHop OBJECT-TYPESYNTAX IpAddressACCESS read-writeSTATUS mandatoryDESCRIPTION<<Endereço seguinte da rota>>

::= {ipRouteEntry 7}

Page 13: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação:codificação da informação

Componentede AplicaçãoMIB

Componentede Aplicação MIB

Componente de

transferência de dados

Componente de

transferência de dados

MapeamentoLocal

MapeamentoLocal

Sintaxe

Abstracta(ASN.1)

Sintaxe de

Transferência(SNMP)

Regras de Codificação Regras de Codificação

Page 14: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de informação: conclusões• Simplicidade de conceitos

– Modelo de Informação orientado a tipos de dados.• - Objectos Geridos são folhas da ARI.• - Acesso a OGs através do Identificador do Objecto na ARI.

• Desenvolvimento rápido de produtos• Modelo não orientado-a-objectos:

– - não há reutilização– - não há herança.

• Estrutura da ARI:– - não há inclusão– - elevado nº de MIBs– - informação relacionada em várias sub-árvores

Page 15: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de comunicação: SNMP• RFC 1157 Simple Network Management Protocol – SNMP (Versão 1)

Get

Nex

tReq

ues

t

Set

Req

ues

t

Get

Nex

tReq

ues

t

Set

Req

ues

t

Get

Req

ues

t

Get

Req

ues

t

Get

Res

po

nse

Get

Res

po

nse

Tra

p

Tra

p

GESTOR

Aplicação de Gestão

Gestor SNMP

UDP

IP

Protocolos dependentes da rede

AGENTE

Gestor SNMP

UDP

IP

Protocolos dependentes da rede

Objectos SNMP

Recursos geridos

REDE

Aplicação gere os objectos

Mensagens(PDU) SNMP

Page 16: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de comunicação: SNMPv1• Formato das mensagens

VersionNumber

CommunityString

PDU-SNMP ou Trap-PDU

Variable bindingsErrorIndex

PDUs: GetRequest, GetNextRequest, GetReponse

PDU: Trap

name1:value1 name2:value2 nameN:valueN

Variable binding

PDUType

RequestID

ErrorStatus

Variable bindingsTimeStamp

AgentAddress

GenericTrap

SpecificTrap

Trap Entreprise

...

Page 17: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de comunicação:manipulação de objectos escalares

GetRequest (ipInReceives.0)

GetResponse(ipInReceives.0=25)iplnReceives 25

Counter Value

Leitura

SetRequest (ifAdminStatus.0= ´Testing´)

GetResponse(ifAdminStatus.0= ´Testing´)ifAdminStatus Testing

OctectString Value

EscritaQuando se obtêm sucesso o valor de GetResponse é omesmo que o colocado em SetRequest

Page 18: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de comunicação:monitorização (leitura) de tabelas

Leitura

tabela

GetNextRequest (ipRouteDest, ipRouteNextHop)

GetResponse ((ipRouteDest.9.1.2.3=9.1.2.3),

(ipRouteNextHop.9.1.2.3=99.0.0.3))

GetNextRequest (ipRouteDest.9.1.2.3, ipRouteNextHop.9.1.2.3)

GetResponse ((ipRouteDest.10.0.0.51=10.0.0.51),

(ipRouteNextHop. 10.0.0.51 =89.11.4.2))

GetNextRequest (ipRouteDest.10.0.0.77, ipRouteNextHop.10.0.0.77)

GetResponse ((ipRouteNextHop.9.1.2.3=99.0.0.3),

(ipNetToMediaIfIndex. 1.3 =1))

ipRouteDest … ipRouteNextHop …

9.1.2.3 … 99.0.0.3 …

10.0.0.51 … 89.1.1.42 …

10.0.0.77 … 89.1.1.42 ...

Page 19: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de comunicação:controlo (escrita) de tabelas

ipRouteDest … ipRouteNextHop …

9.1.2.3 … 99.0.0.3 …

10.0.0.51 … 89.1.1.42 …

10.0.0.77 … 89.1.1.42 ...

SetRequest (ipRouteType.10.0.0.77 =invalid)SetResponse(ipRouteDest.11.3.3.12=invalid)

Remoçãode linha

SetRequest ((ipRouteDest.10.0.0.77=10.0.0.77), (ipRouteNextHop.10.0.0.77 = 89.1.1.42))SetResponse((ipRouteDest. 10.0.0.77=10.0.0.77), (ipRouteNextHop. 10.0.0.77 = 89.1.1.42))

Inserçãode linha

Page 20: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMPv1: Mecanismos de segurança

Definida no Agente• Identificação através de nome• Engloba:

• Autenticação• Controlo de acesso• Característica do proxy

Gestor

Gestor

Agente Comunidade

Agente

Agente

Autenticação: garantir a proveniência correcta⇒ nome da comunidadeControlo de acesso: diferenciar o acesso à MIB⇒ Perfil da comunidade - visão da MIB (objectos visíveis) - modo de acesso a cada elementoCaracterísticas do proxy de cada dispositivo⇒ visão da MIB e modo de acesso

Page 21: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Modelo de comunicação: conclusões• Operações simples

• Desenvolvimento produtos:rápido, realizável em recursos simples

• Divulgação generalizada

• Autenticação trivial

• Ineficiência na transmissão de grandes volumes de informação

• Informação tem de ser sempre requisitada pelo Gestor

• Eventos assíncronos pré-definidos e em nº limitado

• Suporte em UDP

Page 22: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Avaliação e necessidade de evolução do SNMPCaracterísticas (resumo):• Modelo Organização:

– Arquitectura Gestor-Agente– Transferencia de Informação por “polling”

• Modelo Informação:– Informação de Gestão organizada em MIBs– A MIB contém variáveis simples (mesmo as tabelas) e não objectos

• Modelo Comunicação:– Protocolo de gestão SNMP a correr sobre UDP

+ :SimplicidadeAceitação pelos fabricantesPossibilidade de MIBs proprietárias

- (i.e., problemas):Dimensão da redeVolume da informaçãoSegurança

Melhorar o SNMP Evoluir para o CMOTou

Page 23: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Possibilidades de evolução do SNMP• Características “evoluir para CMOT” (ao tempo da decisão):

– Normas OSI ainda em desenvolvimento– Falta de produtos de gestão OSI no mercado– Modelo de informação SNMP é incompatível com a Gestão OSI

• Características “melhorar SNMP”:– SNMP Seguro: resolve os problemas de segurança– SMP: Facilitar a transferência de informação entre recursos

arbitrários• Transferência de Informação em bloco• Compatibilidade (backward) com SMNP• Mecanismos de segurança de SNMP seguro

Page 24: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

Melhoria do SNMP (Versões 2 e 3)

• Características SNMPv2– 1993: SNMPv2

• A elevada aceitação do SNMPv1 condicionou o SNMPv2• Os mecanismos de segurança propostos eram demasiado complexos

– 1994/95: o SNMPv2 é revisto:• As tentativas de simplificação dos mecanismos de segurança são abandonados por

falta de consenso.• Surgem duas versões:

– SNMPv2p: com segurança– SNMPv2c: sem segurança

• Características SNMPv3– Compatibilização com as versões anteriores– Novos mecanismos de segurança

Page 25: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Modificações• Modificações ao Modelo de Informação:

– Novos Grupos na Árvore de Registo Internet– Inserção de novos objectos em grupos da MIB-II– Conceitos fundamentais:

• Definição de objectos,• Tabelas conceptuais,• Definição de notificações,• Módulos de Informação

• Alterações ao Modelo de Comunicação:– Comunicação Gestor Agente– Comunicação Agente Gestor– Comunicação Gestor Gestor

• Modificações ao nível da segurança, embora não tenham sidototalmente normalizados devido à falta de consenso

Page 26: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Novos grupos na ARI

root

itu-t (0) iso (1) join iso/itu-t (2)

org (3)

dod (6)

internet (1)

mib -2 (1) ATM (41) X.25 (44)

recursos nós (36)

IBM (2) HP (11)

dir- (1) mgmt (2) exper. (3) priv.(4)

empresas (1)

1.3.6.1.2..1

security.(5) mail (7)

domínios(1) proxys (2) módulos (3)

snmpv2 (6)

snmpMIB(1)

snmp M2M (2)

Party MIB (3)

Page 27: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Definição de novos objectos• Novos tipos ASN.1

• Unsigned32, Counter64, endereços OSI (NSAP), tipos enumerados• Estes novos tipos aparecem no campo SYNTAX

• Novos campos na definição de objectos• Unit Parts: unidades (ex: segundos)• MAX_ACCESS: not-accessible, accessible-for-notify,

read-only, read-write e read-create• STATUS: current, deprecated, obsolete• ReferPart: referências textuais a outros módulos• IndexPart: manipulação flexível de tabelas• DefValPart: valor por omissão

Page 28: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Manipulação de tabelas• Inserção de colunas

– Index definição da tabela conceptual de base– Augment definição da extensão à tabela

• A extensão pode existir noutro grupo da MIB• Funcionalmente a extensão não se distingue da tabela de base.

• Inserção/Remoção de linhas– Utilização conjunta com os valores por defeito (DEFVAL)– RowStatus

• Uma linha pode estar num estado “ainda não disponível” (not ready)

– Read-create• Possibilidade de criar de forma “automática” este elemento

– CreateAndWait e CreateAndGo• Dois métodos diferentes para lidar com os objectos para os quais não há

valores por defeito na sua definição

Page 29: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Exemplo inserção de colunas

ipForwardDest ... ipForwardNextHop

ipDelayMetric ipQueueLenMetric

private

Empresa X

internet

ip

Mib-2

Mgmt

IpForwardTable OBJECT-TYPE SYNTAX SEQUENCE OF IpForwardEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION << Tabela de encaminhamento IP >>

::= { ip 21} IpForwardEntry OBJECT-TYPE

SYNTAX IpForwardEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION << Rota para um dado destino >> INDEX {ipForwardDest, ipForwardNextHop }

::= { ipForwardTable 1} IpForwardEntry ::=

SEQUENCE { ipForwardDest IpAddress, ... ipForwardNextHop IpAddres, ..

} ipForwardDest OBJECT-TYPE

SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION << Endereço de destino da rota >>

::= {ipForwardEntry 1} … ipForwardNextHop OBJECT-TYPE

SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION << Endereço seguinte da rota >>

::={ipForwardEntry7}

moreIpForwardTable OBJECT-TYPESYNTAX SEQUENCE OF moreEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION << Extensão a ipForwardTable >>

::= {B}

moreEntry OBJECT-TYPESYNTAX moreEntryMAX-ACCESS not-accessibleSTATUS currentDESCRIPTION << Adição de novas colunas a

ipForwardTable >>AUGMENTS {ipForwardEntry}

::= {moreIpForwardTable 1}

moreEntry :==SEQUENCE {ipDelayMetric, ipQueueLenMetric}

ipDelayMetric OBJECT-TYPESYNTAX INTEGERMAX-ACCESS read-writeSTATUS currentDESCRIPTION << Metrica de atraso >>

::= {moreEntry 1}

ipQueueLenMetric OBJECT-TYPESYNTAX INTEGERMAX-ACCESS read-writeSTATUS currentDESCRIPTION << Metrica de tamanho da fila de saída >>

::= {moreEntry 2}

Page 30: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Definição de notificações

• Em SNMPv2 passou a existir uma MACRO para definir a informaçãoenviada por uma entidade quando uma situação de excepção existe -notificação

• Exemplo:

linkUp NOTIFICATION-TYPE OBJECTS (ifIndex,ifAdminStatus, ifOperStatus) STATUS current DESCRIPTION ´A link~Up trap signifies that the SNMPv2 entity, acting in the agent role, has detected that the ifOperStatus object for one of its communication links has transitioned

out of the down state´::= { snmpTraps 4}

Page 31: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Módulos de informação

• O SNMPv2 introduz o conceito de módulo de informação que servepara especificar um grupo de definições relacionadas

• Existem três tipos de módulos:– Módulos das MIBs, que contêm MACROS de definição de objectos e de

notificações– Especificação de compatibilidade para módulos da MIB, que utilizam as

MACROS MODULE-COMPLIANCE, OBJECT-GROUP e NOTIFICATION-GROUP.– Especificação de capacidades de implementação de um Agente que

utilizam a AGENT-CAPABILITIES MACRO

Page 32: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Modelo de comunicaçãoFormato das mensagens

VersionNumber

CommunityString

PDU SNMPv2

Variable bindingsErrorIndexMax-rep

PDUs: GetRequest, GetNextRequest, SetRequest,GetReponse,SNMPv2Trap, GetBulkRequest, InformRequest

name1:value1 name2:value2 nameN:valueN

Variable binding

PDUType

RequestID

ErrorStatus

Non-repeaters

...

Page 33: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Modelo de comunicaçãoMensagens do tipo GetBulkRequest

getBulkRequast permite a transferência de grandes volumes de informação,o gestor pode indicar quantos objectos do mesmo tipo pretende receber.

GetBulkRequest (non-repeaters=1, max-repeaters=3 ipInReceive, ipRouteDest, ipRouteNextHop)

GetResponse (ipInReceive=25,

(ipRouteDest.9.1.2.3=…),ipRouteNextHop.9.1.2.3=… ),

(ipRouteDest.10.0.0.51=…),(ipRouteNextHop.10.0.0.51=…),

(ipRouteDest.10.0.0.77=…),(ipRouteNextHop.10.0.0.77=…))

Leitura

dados ipInReceives 25

ipRouteDest … ipRouteNextHop …

9.1.2.3 … 99.0.0.3 …

10.0.0.51 … 89.1.1.42 …

10.0.0.77 … 89.1.1.42 ...

Page 34: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 2: Segurança

• Autenticidade da origem e do conteúdo, assinar a mensagem usandoo MD5, a mensagem é enviada entre o destino e a origem a chave éconhecida por ambos.

• Confidencialidade: cifrar a mensagem usando DES (Data EncriptionStandard) e o CBC (Cipher Block Chaning)

• Não duplicação (validade) da Informação: adição de uma Marcatemporal - Time Stamp que permite detectar sequências for de ordemdelimitar o intervalo de vida da mensagem.

Page 35: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Princípios gerais

• Usar como base o trabalho existente (SNMPv2)• Colmatar a deficiência de segurança das versões anteriores, que

impossibilita a utilização de configuração SetRequest.• Conceber uma arquitectura modular, adaptável quer a sistemas

simples quer a complexos capazes de gerir redes de grandesdimensões.

• Permitir que essa arquitectura fosse utilizada sem interferência doprocesso de normalização.

• Permitir a utilização de modelos alternativos de segurança.• Manter o SNMP o mais simples possível.• Permitir que fosse progressivamente normalizada, podendo as partes

normalizadas serem usadas.

Page 36: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Princípios gerais

• Usar como base o trabalho existente (SNMPv2)• Colmatar a deficiência de segurança das versões anteriores, que

impossibilita a utilização de configuração SetRequest.• Conceber uma arquitectura modular, adaptável quer a sistemas

simples quer a complexos capazes de gerir redes de grandesdimensões.

• Permitir que essa arquitectura fosse utilizada sem interferência doprocesso de normalização.

• Permitir a utilização de modelos alternativos de segurança.• Manter o SNMP o mais simples possível.• Permitir que fosse progressivamente normalizada, podendo as partes

normalizadas serem usadas.

Page 37: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Opções gerais

• Arquitectura, definida com base em limites conceptuais, que se traduzemdirectamente nos documentos de especificação.– Sub-sistemas que descrevem os serviços por partes especificas da arquitectura– Interfaces entre os serviços definidas através de primitivas de serviços

• Documentos auto-suficientes, cada parte deve ser contida num documentoúnico, que inclui as funções as variáveis, etc..

• Configuração remota, chaves secretas configuradas remotamente.

• Complexidade controlada,– equipamentos simples => recursos SNMP reduzidos– configurações complexas => recursos SNMP mais alargados

• Ataques à segurança, o sub-sistema de segurança deve ser capaz deproteger o sistema de gestão contra os principais ataques.

Page 38: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Ataques à segurançacontenplados• Modificação de informação:

– Alteração de uma mensagens em trânsito• EX: Alteração de informação de configuração ou de contabilização de recursos

• Ataque à privacidade (Disclosure)– Observação de trocas de informação Gestor - Agente

• Ex: Observação de um comando de alteração de password

• Alteração de sequência– Duplicação, atraso ou reordenação de mensagens

• EX: Duplicação uma mensagem de reboot

• Ataque à autenticação (Masquerade)– Realização de operações não permitidas a uma entidade através da

adopção de uma entidade falsa, que tenha privilégios para as executar.

Page 39: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Ataques à segurançanão-contemplados• Negação de serviço

– Evitar a comunicação Gestor - Agente• Situação análoga à que se verifica quando há falha de comunicação• Quando ocorre afecta todas as comunicações pelo que deverá ser

resolvido no âmbito geral das comunicações, e não específico dagestão.

• Análise de tráfego– Observação do padrão de tráfego gerado Gestor - Agente

• Padrão de tráfego previsível, pelo que não há vantagem em proteger asua observação

Page 40: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Pricípios fundamentais• Conceito de entidade

– A arquitectura de Gestão SNMP é constituída por um conjunto deentidades SNMP distribuídas, que cooperam entre si.

– Cada entidade implementa uma parte da arquitectura SNMP,podendo funcionar como Agente, Gestor ou ambos em simultâneo.

• Conceito de módulo– Cada entidade é constituída por um conjunto de módulos que

interagem entre si para providenciar serviços.– As interacções são modeladas através dum conjunto de primitivas

abstractas e parâmetros.

Page 41: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: EntidadeEntidade SNMP

Gerador deComandos

Gerador deRespostas

Gerador deNotificações

Receptor deNotifcações

ProxyForwarder

Outros

Aplicações

DespachoSubsistema deProcessamentode Mensagens

Subsistema deSegurança

Subsistema deControlo de

Acessos

Máquina SNMP

Page 42: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Aplicações

• Gerador de Comandos– Envia mensagens Get, GetNext, GetBulk e SetRequest– Processa mensagens Response recebidas como resposta a pedidos enviados

• Gerador de Respostas– Recebe e Processa as mensagens Get, GetNext, GetBulk e SetRequest– Utiliza o Controlo de Acessos e executa a acção adequada– Envia mensagem Response

• Gerador de Notificações– Monitoriza um sistema e gera Traps ou InformRequest com base em

eventos ou condições– Selecciona o destino das Notificações, versão do SNMP e parâmetros de

segurança.• Receptor de Notificações

– Espera e recebe Traps ou InformRequest– Gera uma resposta quando recebe InformRequest

• Proxy Forwarder– Envia mensagens SNMP– Opcional

Page 43: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Máquina

• Despacho– Coordena a transferência de PDUs entre a rede e as aplicações

• Sub-sistema de Processamento de Mensagens– Conversão PDUs <-> mensagens SNMP

• Sub-sistema de Segurança– Serviços de segurança– Ex: autenticação e confidencialidade

• Sub-Sistema de Controlo de Acesso– Serviços de autorização que uma aplicação necessita para a

verificação de privilégios

Page 44: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Estrutura geral de um gestor

Gerador deComandos

Gerador deNotificações

Receptor deNotifcações

Despachode PDU

Despachode Msg.

Mapeamentode Transporte

Des

pac

ho

Outro

Segurança

Baseado em

Utilizador

v1MP

v2cMP

v3MP

Outro

Processamentode Mensagens

UDP IPX Outros

Rede

Page 45: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Estrutura geral de um agente

Despachode PDU

Despachode Msg.

Mapeamentode Transporte

Des

pac

ho

Outro

Segurança

Baseado em

Utilizador

Gerador deRespostas

Gerador deNotificações

ProxyForwarder

UDP IPX Outros

Rede

Outro

Controlo de Acessos

Baseadoem

Views

Manipulação da MIB

v1MP

v2cMP

v3MP

Outro

Processamentode Mensagens

Page 46: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Ex. Polling Gestor-Agente

Receptor deComandos

Despacho Sub-sistema deProcessamentode Mensagens

Sub-sistema deSegurança

registerContextEngineIDRecebe SNMP RequestMsg da rede

prepareDataElements

processingIncomingMsg

processPDU

prepareResponseMsggenerateResponseMsg

returnResponsePDU

Envia SNMP ResponseMsg para a rede

Page 47: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Ex. Polling Gestor-Agente

Gerador deComandos

Despacho Sub-sistema deProcessamentode Mensagens

Sub-sistema deSegurança

sendPDUprepareOutgoingMsg

generateRequestMsg

Envia SNMP RequestMsg para a rede...

prepareDataElementsprocessingIncomingMsg

responsePDU

Recebe SNMP ResponseMsg da rede

Page 48: “Arquitectura(s)” de gestão IETFhome.iscte-iul.pt/~rhcl/material/IGRS_OLD/2007/gestao/07...“Arquitectura(s)” de gestão IETF •As “arquitecturas” definidas pelo IETF

SNMP versão 3: Segurança• Os mecanismos de segurança e controlo de acessos podem ser

utilizados de forma flexível adaptando-se a cada sistema.

• Autenticidade da origem e do conteúdo, assinar a mensagem usandoo MD5, a mensagem é enviada entre o destino e a origem a chave éconhecida por ambos.

• Confidencialidade: cifrar a mensagem usando DES (Data EncriptionStandard) e o CBC (Cipher Block Chaning)

• Validade da Informação: adição de uma Marca temporal - Time Stampque permite detectar sequências for de ordem delimitar o intervalode vida da mensagem.