Edgard Jamhour Mauro Fonseca Carlos Maziero Gerência de Redes (SNMP) Serviços de Diretório (LDAP) Policy Based Networking (PBNM) Edgard Jamhour Mauro Fonseca Carlos Maziero

Definições básicas Gerência de redes: Gerência integrada: conjunto de ferramentas, procedimentos e políticas usadas para manter o funcionamento e eficiência de uma rede, independente de seu tamanho ou finalidade. Gerência integrada: ferramentas e procedimentos que podem cooperar entre si, possibilitando a definição de políticas homogêneas em um ambiente heterogêneo.

Áreas funcionais de gerência Configuração Falha Desempenho Segurança Contabilidade

Gerência de configuração Inventory: conjunto de dispositivos na rede, do software e hardware presente nesses dispositivos e sua informação estática. Configuration: mapa indicando as conexões entre componentes do inventário. Provisioning: parâmetros operacionais modificáveis que especificam o comportamento de cada dispositivo.

Gerência de falha Detectar e resolver rapidamente situações que degradam o funcionamento da rede: Determinar a origem da falha Isolar a falha do restante da rede reconfigurar a rede para diminuir impacto da falha reparar ou trocar componentes com falha

Gerência de desempenho Assegurar uma capacidade de tráfego mínima na rede. Assegurar que os dispositivos podem tratar o tráfego presente na rede. Baseia-se em dados colhidos da rede: erros de CRC, time-outs, retransmissões Dados históricos podem ser importantes

Gerência de segurança Proteção das informações Controle de acesso ao sistema Monitorar uso dos recursos Criar, manter e examinar “log-files” Muito importante em sistemas abertos Essencial em hosts conectados à Internet

Gerência de contabilização Ter uma idéia clara do uso dos recursos cobrar pelos serviços utilizados planejar crescimento da rede detectar abusos no uso dos recursos Informação de contabilização deve ter acesso restrito.

Modelo de gerência Baseado em uma estrutura cliente/servidor agente: age como servidor de informações de gerência gerente: consulta os agentes para obter informações

Servidor: Agente Agente: Network Management Entity executa um processo agente interage com os dispositivos físicos coleta, mantém e oferece informações de gerência responde a pedidos de informação e comandos

Cliente: Gerente Gerente: Network Management Application consultas e ações sobre os agentes executa um software de gerência interage com o operador do sistema

O ciclo de gerência As atividades de gerência compõe um ciclo: Coleta de dados: monitoração (automática) dos recursos gerenciados. Diagnóstico: tratamento e análise dos dados coletados para delinear o problema. Ação: controle sobre os recursos gerenciados para corrigir o problema.

Transferência da informação Dados fluem dos agentes ao gerentes Pooling: interações tipo “pedido/resposta” iniciadas pelo gerente, solicitando dados podem ser específicas ou genéricas Event reporting: indicações de ocorrência de eventos importantes iniciadas pelo agente podem ser periódicas ou ocasionais

Uma arquitetura de gerência Management entity requests Managed objects responses notifications events operations Management application Management protocol Management agent MIB Management database

Ferramentas de gerência Arquitetura de gerência OSI Gerência usando SNMP Gerência via Web Gerência com objetos CORBA

Protocolos de gerência SNMP Simple Network Management Protocol Criado pela IETF em 1988 Projetado para monitorar redes simples Dominante em redes TCP/IP CMIP Common Management Information Protocol Proposto pela ISO no início dos anos 90 Controle (complexo) de redes complexas Muito presente em redes de telefonia

Informações de gerência MIB Management Information Base Dados mantidos pelos elementos gerenciados Informação com estrutura hierárquica SMI Structure of Management Information Define notações, formatos, tipos, nomes, ... Usa como base a notação formal ASN.1

MIB-II - Estrutura geral iso(1) org(3) dod(6) Object ID is 1.3.6.1.2.1.7 internet(1) directory(1) mgmt(2) mib-2(1) udpInDatagrams udpNoPorts udpInErrors udpOutDatagrams system(1) interfaces(1) tcp(6) udp(7)

SNMP Voltado à monitoração de redes simples Pode ser embutido em hardware simples Muito usado em redes TCP/IP Comandos e tipos de dados fixos Poucos tipos de mensagens estrutura bastante simples Usa UDP/IP baixo nível de tráfego de gerência protocolo de transporte sem conexão não confiável (perda de pacotes) Comandos e respostas assíncronas

Extensões de SNMP RMON - Remote Network Monitoring RMON-2 SNMP-V2 extensão da MIB-II para gerência Facilidades para monitoração e coleta “Remendo” sobre SNMP e MIB RMON-2 Coleta de informações mais abrangente SNMP-V2 estrutura de segurança melhorada comunicação entre gerentes (método inform) MIB e SMI aumentadas: novos tipos de dados

Estrutura de gerência OSI Arquitetura em camadas de serviços: SMFA System Management Functional Areas: faltas, contabilidade, configuração, desempenho, segurança SMF System Management Functions CMISE CMIS: Common Management Information Services CMIP: Common Management Information Protocol

Specific Management Functional Areas System Management Functions Arquitetura OSI security configuration fault performance accounting Specific Management Functional Areas relationship Event-report state alarm object System Management Functions log security access accounting workload test summarization action event-report set create get CMISE Services delete CMIP Managed node

O que é SNMP ? Padrão para gerência na Internet Composto de: simples de implementar amplamente difundido Composto de: protocolo para trocas de mensagens padrões para estruturar a informação Evolutivo: SNMPv2, SNMPv3, RMON, ...

Estrutura geral do sistema Protocol Request SNMP manager MIB SNMP agent MIB Response Management information

Informações de gerência Definidas através da SMI Structure of Management Information Define como criar a MIB Endereçada através de MIBs Management Information Bases Uma MIB é uma coleção de objetos Cada objeto representa uma parâmetro de gerência Transportadas através do SNMP Single Network Management Protocol

Árvore MIB Object IDentifier (OID) - Exemple .1.3.6.1.2.1.1 Notas: - iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) system(1) Notas: - .1.3.6.1 ~100% present. - os ramos mgmt e private são os mais usados. - MIB-2 é uma estrutura padrão que deve ser suportada por nós TCP/IP. iso(1) 1 org(3) 3 dod(6) 6 internet(1) 1 private(4) directory(1) 4 1 mgmt(2) experimental(3) 2 3 mib-2(1) 1 tcp(6) system(1) 6 1 interfaces(2) ip(4) 2 4

A MIB versão 2 1.3.6.1. iso.org.dod.internet objeto 1.3.6.1.2.1.1 1. system 2. interfaces 3. address translation 4. ip 5. icmp 6. tcp 7. udp 8. egp 9. oim 10. transmission 11. snmp 1. directory 2. mgmt 3. experimental 4. private 5. security 6. snmpV2 7. mail 1. mib-2 1. enterprises

Objeto MIB Definido em ANS.1 Standard MIB Object: OBJECT-TYPE Descreve o objeto MIB. Object IDentifier (OID). SYNTAX Define o tipo de informação representada pelo objeto MIB. ACCESS READ-ONLY, READ-WRITE. STATUS Estado do objeto em relação a comunidade SNMP. DESCRIPTION Significado da informação representada pelo objeto MIB. Standard MIB Object: sysUpTime OBJECT-TYPE SYNTAX Time-Ticks ACCESS read-only STATUS mandatory DESCRIPTION “Time since the network management portion of the system was last re-initialised. ::= {system 3}

ASN.1 Abstract Syntax Notation One Linguagem de descrição de dados da ISO Definição em formato texto não ambíguo Permite definir modelos de dados Formato independente de máquina Implementação dos dados não é considerada

Campo SYNTAX Define o conteúdo do objeto INTEGER: inteiros de 32 bits INTEGER (1..100): sub-tipo inteiro OCTET STRING: string de bytes OBJECT IDENTIFIER: localização de outro objeto na MIB Aceita alguns tipos específicos de aplicação: IpAddress: OCTET STRING com 4 bytes Counter: inteiro 32 bits monotônico crescente Gauge: inteiro 32 bits limitado no mínimo e no máximo TimeTicks: inteiro 32 bits (1/100 de segundo)

Sub-tipagem INTEGER INTEGER (-127..128) INTEGER (1..10)

Enumeração usando inteiros Boolean ::= INTEGER { true (1), false (2)} Alarm-level ::= INTEGER { critical (1), major (2), minor (3), warning (4), informational (10) }

Campo ACCESS Define a acessibilidade do objeto Valores possíveis em SNMPv1: read-only read-write write-only not-accessible

Campo STATUS Situação do objeto na MIB Mandatory Devem ser implementados por todos os agentes Valores contidos devem ser válidos Optional Pode ou não ser implementado Deprecated Foi substituido por novo objeto, mas ainda é valido Se tornará obsoleto mais tarde Obsolete Não deve ser considerado

Valores escalares e vetoriais uma só instância por variável OID deve ser completado por “.0” Exemplo: ....mib-2.ip.ipForwarding: 1.3.6.1.2.1.4.1.0 Valores vetoriais: para construir listas e tabelas usam os construtores SEQUENCE e SEQUENCE OF Convenção de tabela: xxxTable Convenção de linha na tabela: xxxEntry

Tabela de conexões TCP tcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “A table containing TCP connection-specific information.” ::= {tcp 13}

Uma conexão TCP na tabela tcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION “Information about a particular current TCP connection. ...” INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= {tcpConnTable 1}

Uma conexão TCP na tabela (2) TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort INTEGER (0..65535), tcpConnRemAddress IpAddress, tcpConnRemPort INTEGER (0..65535), }

BER Basic Encoding Rules Codificação dos dados para transferência Usa formato TLV: Type-Length-Value Type: tipo ASN.1 e infos complementares Length: tamanho da representação dos dados Value: string de octetos contendo o valor do dado A estrutura de codificação é recursiva

management application A arquitetura SNMP Managed system Management system resources management application management actions MIB objects SNMP messages SNMP manager SNMP agent UDP UDP IP IP link link

O protocolo SNMP Veicula informações de gerência transporte de valores das MIBs Interações sem conexão Mensagens em UDP/IP portas 161 e 162 pacotes de tamanho variável Mensagens auto-contidas formato Type - Length - Value

Histórico do SNMP 1989: SNMP v1 1992: Remote Monitoring - RMON 1996: SNMP v2c (Community Security) 1996: MIB RMON v2 1998: SNMP v3 (User Security Model)

Operações básicas SNMP GET GET-NEXT gerente busca informações dos agentes acessos em leitura às MIBs SET gerente modifica informações dos agentes acessos em escrita às MIBs TRAP agentes enviam informações não solicitadas aos gerentes, informado eventos importantes

Exemplo de uso manager SNMP Agent MIB Get (Nome) Response (‘João’) pessoa.nome = João pessoa.idade = 35 pessoa.sexo = masc Response (‘João’) GetNext (Nome) Response (35) Set (sexo, fem) Response (Erro)

Restrições das operações Permitem somente inspeção e/ou alteração de variáveis A estrutura da MIB não pode ser alterada pelas operações Somente podem ser acessados valores escalares em cada operação

Limitações de SNMP Falta de segurança Ineficiência esquema de autenticação trivial limitações no uso do método SET Ineficiência esquema de eventos limitado e fixo operação baseada em pooling comandos transportam poucos dados Falta de funções específicas MIB com estrutura fixa Falta de comandos de controle Falta de comunicação entre gerenciadores Não confiável baseado em UDP/IP traps sem reconhecimento

Modelo de segurança SNMP Modelo mais comum: SNMP V2c Baseado no conceito de comunidade Uma comunidade define: método para autenticar acesso (senha) visibilidade da MIB privilégios de acesso à MIB Cada dispositivo implementa uma ou mais comunidades Comunidade default: “public”

Exemplo de comunidades admin public ensino network

Uma mensagem SNMP Conteúdo codificado via BER Geralmente limitada a < 484 bytes msg length 2 bytes preâmbulo protocol version 1 byte community string até 128 bytes PDU header PDU SNMP PDU body

Estrutura das PDUs SNMP Get & Set Trap msg length protocol version community string PDU type PDU length Request ID Error Status Error Index Variable bindings msg length protocol version community string PDU type PDU length Enterprises OID Agent IP address Standard trap type Variable bindings Specific trap type Time stamp preamble SNMP header SNMP body

Preâmbulo e cabeçalho Versão Tipo de PDU Request ID 0: SNMPv1, 1: SNMPv2, ... Tipo de PDU 0: getRequest 1: getNextRequest 2: getResponse 3: setRequest 4: trap Request ID valor numérico usado para casar pedidos e respostas

Códigos de erro Error Status: Error index: 0: noError: sucesso na operação 1: tooBig: resposta muito grande para enviar 2: noSuchName: OID não suportado pelo agente 3: badValue: valor incorreto para operação set 4: readOnly: tentativa de escrita inválida 5: genErr: erro não relacionado ao protocolo Error index: indica qual variável listada na PDU causou o erro.

Conteúdo das mensagens varbind length variable OID variable type variable value ... var list size 41 23 1.3.6.1.2.1.1.2.0 2 1.3.6.1.4.1.311.1.1.3.2 14 1.3.6.1.2.1.7.4.0 65 250

A operação GetNext Busca próximo elemento na MIB Serve para: Usa ordem lexicográfica 1.3.6.1.2.1.1.4 1.3.6.1.2.1.1.4.0 1.3.6.1.2.1.1.5.0 ... Serve para: passear na MIB (descoberta da estrutura) buscar dados em tabelas

Exemplo de passeio na MIB snmpgetnext -v1 localhost -c public system SNMPv2-MIB::sysDescr.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64 snmpget -v1 localhost -c public -O n system.sysDescr.0 .1.3.6.1.2.1.1.1.0 = STRING: Linux espec.ppgia.pucpr.br 2.6.17-1.2142_FC4smp #1 SMP Tue Jul 11 22:59:20 EDT 2006 x86_64 snmpgetnext -v1 localhost -c public -O n .1.3.6.1.2.1.1.1.0 .1.3.6.1.2.1.1.2.0 = OID: .1.3.6.1.4.1.8072.3.2.10 snmpgetnext -v1 localhost -c public -O n .1.3.6.1.2.1.1.2.0 .1.3.6.1.2.1.1.3.0 = Timeticks: (523160) 1:27:11.60 snmpget -v1 localhost -c public .1.3.6.1.2.1.1.3.0 SNMPv2-MIB::sysUpTime.0 = Timeticks: (527855) 1:27:58.55

Percurso seqüencial myVar1.1 myVar2.1 myVar3.1 myVar1.2 myVar2.2 coluna 1 coluna 2 coluna 3 1 5 9 linha 1 myVar1.1 myVar2.1 myVar3.1 2 6 10 linha 2 myVar1.2 myVar2.2 myVar3.2 3 7 11 linha 3 myVar1.3 myVar2.3 myVar3.3 4 8 12 linha 4 myVar1.4 myVar2.4 myVar3.4 13

Traps em SNMP Mensagens enviadas pelo agente Não são respostas a pedidos Representam eventos anormais Classificam-se em: genéricos: presentes na MIB padrão específicos: definidos na MIB “enterprises”

Traps genéricos coldStart: warmStart: linkDown: o dispositivo foi ligado configuração local pode ter sido alterada informa ao gerente sobre sua existência warmStart: o dispositivo foi reinicializado configuração local não foi alterada linkDown: link ou porta de comunicação ligada ao nó falhou

Traps genéricos (2) linkUp: authenticationFailure: egpNeighborLoss: link ou porta local foi (re)ativada. authenticationFailure: o dispositivo recebeu msg SNMP não autorizada comunidade não reconhecida número IP de gerente inválido egpNeighborLoss: Exterior Gateway Protocol falhou no nó normalmente usado em roteadores

Serviço de Diretório Defini-se um serviço de diretório como sendo um "banco de dados" especializado para informações de gerenciamento. Exemplos bem conhecidos de serviços de diretório são: Especificação LDAP Especificação X500 Especificação DNS (Nomes de Domínio) Serviços de diretório são utilizados para oferecer um repositório "logicamente" centralizado com as informações de gerenciamento.

Modelos de Serviço de Diretório Um serviço de diretório deve ser capaz de: Armazenar qualquer tipo de objeto DNS, por exemplo, só armazena registros que relacionam nomes com endereços. Oferecer mecanismos flexíveis de consulta por exemplo, localizar o email de uma pessoa pela departamento onde trabalha e cargo que ocupa. Armazenar as informações numa arquitetura decentralizada Serviço de Diretório = Banco de Dados Distribuído. Utilizar um mecanismo para nomear os objetos independente do seu tipo.

Serviço de Diretório X500 X500 é um protocolo CCITT projetado para construir um serviço de diretório distribuído de alcance global. Ele oferece as seguintes características: Escalabilidade Sistema de Banco de Dados Distribuído Mecanismos de Procura Flexíveis Linguagem de consulta orientada a objetos Espaço de Nomes Homogêneo Mesma notação para qualquer objeto. Serviço padronizado e aberto. Definido por normas CCITT

Modelo Funcional X500 (Banco de Dados Distribuído)

Modelo Funcional X500 DSP (Directory Service Protocol). Protocolo que padroniza a comunicação entre servidores. Essa comunicação ocorre quando uma consulta não pode ser satisfeita pelo servidor local. DAP (Directory Access Protocol). Protocolo de acesso, que padroniza a comunicação entre o cliente e o servidor de diretório. DUA (Directory User Agent) é o nome dado a parte do software do cliente que interage diretamente com o servidor de diretório. O desenvolvimento de aplicações que interagem com o diretório é feita através de um conjunto de API's padronizadas pelo protocolo de acesso. DSA (Directory System Agent) é a denominação dada a porção do software do servidor responsável por atender as requisições dos clientes.

Políticas IPsec para o IP de destino 200.10.0.1? Serviço de Diretório X500 prenome=edgard?email? email=jamhour@ppgia.pucpr.br SERVIÇO DE DIRETÓRIO Login Bypass. Login+senha Políticas IPsec para o IP de destino 200.10.0.1? senha OK

Estrutura do X500 As informações de diretório do X500 estão armazenadas no DIB - Directory Information Base cada entrada do diretório aponta para um objeto Objeto: Usuário nome: Edgard sobrenome: Jamhour email: jamhour@ccet.pucpr.br Atributos Objeto Atributo 1 (tipo, valores) Atributo 2 (tipo, valores) .... Atributo n (tipo,valores) Entrada

Objetos do X500

X500: Esquema de Classes Algumas classes LDAP são derivados do X500 e definidas na RFC 2256. objectclass: person (derivada de top) atributos obrigatórios: sn, cn atributos opcionais: description, seeAlso, telephoneNumber, userPassword objectclass: organizationalperson (derivada de person) atributos opcionais: facsimileTelephoneNumber, postOfficeBox, postalAddress , postalCode, preferredDeliveryMethod , etc. objectclass: inetOrgPerson atributos opcionais: businessCategory, departmentNumber, employeeType, employeeNumber, homePhone, homePostalAddress, initials, manager, mobile, pager, preferredLanguage, mail, o, roomNumber, secretary, uid

Estrutura em Árvore Os objetos podem conter outros objetos constituindo uma estrutura hierárquica em forma de árvore. Objetos que contém outros objetos são ditos containers. Uma rede de computadores ou domínio pode ser representado como uma sub-árvore no diretório. Objetos que não contém outros objetos são ditos leaf.

DN: NC=aeinstein, UO=ppgia, O=pucpr, P=br Esquema de Nomes X500 DN: Distiguished Name DN: NC=aeinstein, UO=ppgia, O=pucpr, P=br

Nomes Um nome é utilizado para identificar cada objeto no diretório. Existem dois tipos de nomes: Relative Distinguished Name (RDN): Nome Característico Relativo identifica o objeto através de um atributo cn=ejamhour Distinguished Name (DN): Nome Característico identifica o objeto pelo seu caminho completo a partir da raiz. cn=ejamhour,ou=Funcionarios,ou=ppgia,o=pucpr.br

LDAP (Lightweight Directory Access Protocol) Criado como uma alternativa mais simples ao protocolo padrão do X500. DAP: Directory Access Protocol Desenvolvido pela Universidade de Michigan em conjunto com o Internet Engineerig Task Force (ETF) O LDAP está atualmente na versão 3: LDAP v3 Diversas normas descrevem o funcionamento do LDAP: RFC 1777 - Protocolo RFC 1779 - Modelo de Nomes RFC 1823 - API RFC 1959 - formato URL RFC 2044 - conjunto de caracteres internacionais UTF-8

LDAP Trabalha numa arquitetura cliente-servidor: clientes LDAP se conectam a um ou mais servidores LDAP para atualizarem e obterem informações sobre o diretório. Define um conjunto de primitivas para manipular objetos de diretório: Bind, search, modify, delete, etc. LDAP inclui suporte para autenticação Simples (clear text), Kerberos e SSL são utilizados.

A arquitetura LDAP segue o padrão cliente-servidor. Servidor LDAP: A arquitetura LDAP segue o padrão cliente-servidor. O servidor LDAP pode ser de dois tipos: Fazer uma ponte com outro servidor de diretório (e.g. X500) Ser um servidor stand-alone.

Servidor LDAP como Ponte para X500

Stand-alone LDAP

Sintaxe de uma Consulta LDAP ldap[s]://<host>:<porta>/<base_dn>?<atributos>?<escopo>?<filtro> ldap://ppgia.pucpr.br/o=pucpr,c=br?email?sub?(sn=Joa*) c=br c=br c=br o=pucpr o=pucpr o=pucpr o=ufpr o=ufpr o=ufpr escopo sub escopo one escopo base

Directory Enable Networks Criação: Criado pelo DMTF(Distribute Engineering Task Force) www.dmtf.org DMTF: Reuni os principais fabricantes de produtos de hardware e software pare rede: Cisco, 3Com, Microsoft, Sun, Novel, IBM, etc. Objetivo: Criar um formato padrão para armazenar informações de rede em um diretório LDAP, de maneira que este possa ser compartilhado por várias aplicações.

CIM - Common Information Model Os esquemas de diretório propostos pelo DMTF já estão implementados nas versões atuais de Solaris e Windows 2000 sob a denominação CIM: Common Information Model Recentemente, o DMTF juntou esforços com o IETF e criou o PCIM: PCIM: Police Core Information Model (RFC3060)

CIM: Common Information Model

CIM: Common Information Model

Directory Enable Networks ESQUEMA e INTERFACES Futuras Aplicações que usam Diretório Aplicações de Gerenciamento Existentes Futuras Aplicações de Gerenciamento Protocolos de Gerenciamento Existentes DIRETÓRIO hubs switches roteadores computadores

Gerência de Redes Baseada em Políticas A configuração e gerência de redes possui características que podem ser melhor descritas através de políticas. Exemplo: Políticas de operação normal, grande volume ou emergenciais. Para atender essas políticas a rede precisa ser configurada, e não cada equipamento individualmente. Políticas devem permitir mapear processos de negócio para as aplicações que utilizam a rede.

PCIM Policy Core Information Model Resultado entre um trabalho conjunto entre o DMTP e o IETF. As seguintes RFC´s são atualmente publicadas pelo IETF: Policy Core Information Model - Version 1 Specification (RFC 3060) Terminology for Policy-Based Management (RFC 3198) Os seguintes trabalhos estão no formato de Draft: Policy Core LDAP Schema Policy Framework QoS Information Model Information Model for Describing Network Device QoS Datapath Mechanisms Policy Core Information Model Extensions

O que é o PCIM? PCIM é um modelo genérico: Princípios: Define um conjunto de classes e relacionamentos de maneira extensível. Políticas para o controle de objetos gerenciáveis são definidas pela extensão desse modelo. Princípios: PCIM representa a estrutura e não o conteúdo de uma política. O conteúdo deve ser definido para herança das classes genéricas do PCIM de maneira a criar estrutura de políticas especializadas para áreas de aplicação e produtos específicos.

Máquina de Estados O gerenciamento baseado em políticas presume que a rede é modelada como uma máquina de estados. As classes e relacionamentos do PCIM são usadas para modelar: O estado de uma entidade As ações para manter a entidade num dado estado ou movê-la para outro estado. A configuração a ser aplicada numa entidade para mantê-la ou movê-la para outro estado.

Políticas = Conjunto de Regras Uma política PCIM é formada por um conjunto de regras. Cada regra é definida por um conjunto de condições e um conjunto de ações. As regras podem ser priorizadas e agrupadas para modelar uma hierarquia administrativa. Condição 1 … Condição N Política Regra 1 Ação … Açaõ N Regra 2 … Regra N

Principais Classes do PCIM

PCIMe

Condições

Mapeamento de Políticas no Dispositivo

QPIM: Policy Quality of Service Information Model

Policy Based Networking PDP: Policy Decision Point PEP: Policy Enforcement Point Policy Management Tool request PDP aplicativo PEP COPS decision LDAP Policy request Repository dispositivo PEP COPS decision Base de Estados

COPS Common Open Policy Services Protocol RFC 2748: The COPS (Common Open Policy Service) Protocol (Janeiro 2000) RFC 2749: COPS usage for RSVP (Janeiro 2000) RFC 2753: A Framework for Policy-based Admission Control (Janeiro 2000) RFC 3084: COPS Usage for Policy Provisioning (COPS-PR) (Março 2001)

COPS Protocolo simples, extensível, baseado em TCP. A conexão TCP é permanente As mensagens COPS são transmitidas como objetos independentes e flexíveis novos objetos podem ser criados A segurança pode ser implementada por IPsec ou TLS. PEP PDP PEP PDP Request Open Client Type Connection Decision Client Connection Accept Report

Princípio O PDP é stateful. As requisições feitas pelos PEPs são “lembradas” pelo PDP até que sejam explicitamente apagadas pelo PEP. As mensagens COPS são enviadas através de conexões TCP iniciadas sempre pelo PEP. Na inicialização o PEP solicita a carga de uma configuração inicial. Mas o PDP pode enviar mensagens não solicitadas ao PEP através dessas conexões. As decisões tomadas pelo PDP são assíncronas. O PDP pode carregar novas configurações no PEP. O PDP pode remover certas configurações no PEP quando elas não forem mais necessárias.

Modelo Básico LPDP: Local Policy Decision Point Permite ao PEP tomar decisões na ausência do PDP. O LDPD não é um substituto do PDP. O PDP central é autoritário sobre o LPDP. Todas as decisões importantes devem ser enviadas ao PDP central. Nó de Rede PEP PDP COPS LPDP

Funcionamento 1) O PEP faz uma conexão TCP no PDP. 2) O PEP envia uma mensagem de “Request” identificando o tipo de política desejada . 3) O PDP envia para o PEP as configurações através de mensagens “Decision”. 4) O PEP instala as configurações e quando estiver pronto envia a mensagem “Report”. 5) O PDP pode enviar uma mensagem “Decision” não solicitada para o PEP para anular uma requisição já concedida. 6) O PEP deve responder a essa mensagem com “Report”.

Mensagens COPS version flags op code Client Type 1 byte 2 bytes As mensagens COPS são formadas por um cabeçalho fixo, seguido por um número variável de objetos. Version: atualmente 1 Flags: Apenas o flag “Solicited Message Flag” está definido Op Code: Mensagem COPS Client Type: Identifica o tipo de cliente (para receber a política) Message Length Tamanha da mensagem em bytes (inclui o cabeçalho) version flags op code Client Type 1 byte 2 bytes Message Length

Op Code 1 = Request (REQ) 2 = Decision (DEC) 3 = Report State (RPT) 4 = Delete Request State (DRQ) 5 = Synchronize State Req (SSQ) 6 = Client-Open (OPN) 7 = Client-Accept (CAT) 8 = Client-Close (CC) 9 = Keep-Alive (KA) 10= Synchronize Complete (SSC)

Objetos COPS 2 byte 1 byte 1 byte Length C-Num C-Type Object Contents 1 = Handle 2 = Context 3 = In Interface 4 = Out Interface 5 = Reason code 6 = Decision 7 = LPDP Decision 8 = Error 9 = Client Specific Info 10 = Keep-Alive Timer 11 = PEP Identification 12 = Report Type 13 = PDP Redirect Address 14 = Last PDP Address 15 = Accounting Timer 16 = Message Integrity C-Type Depende de C-Num Indica o subtipo ou versão da informação transportada pelo objeto. 2 byte 1 byte 1 byte Length C-Num C-Type Object Contents

Escalabilidade Repositório de Políticas PDP COPS PEP COPS is an emerging IETF protocol. Quick background, COPS does Policy Control of IP. Today, one of the most pressing issues with the traffic convergence at the IP layer is providing adequate QoS. IP is best effort delivery, but certain applications such as VoIP require QoS to solve the voice clipping that occurs in a congested IP best effort environment. The IETF Policy Framework is a client service model, where the Policy Decision Point, PDP controls the policy and the Policy Enforcement Point PEP, which is generally a router or switching element enforces the policy. Our sister organization, vBNS did early research in the area of providing QoS for IP traffic. They have a Reserved Bandwidth Service which uses COPS - for controlling RSVP signals. vBNS decided that the ENSD MSCP and our work with policy control of ATM SVC’s was a good fit for their Reserved Bandwidth Service and they had us develop a COPS-RSVP PDP which is called the RBS.

Modelos de PDP/PEP O COPs pode ser utilizado em duas estratégias diferentes: Outsourcing: Poucas informações são armazenadas no dispositivo gerenciado (PEP). O PEP consulta ao PDP para tomar decisões relativas aos eventos do dispotivo. Provisioning: A maioria das informações de configuração é armazenada no PEP na inicialização do dispositivo. O PEP toma a maioria das decisões localmente.

Modelo Outsourcing Cada evento no PEP dispara uma consulta ao PDP.

Modelo Provisioning O PEP tem autonomia para tomar decisões localmente.

PIB - Policy Information Base Similar a MIB, utilizada pelo SNMP, uma PIB é uma árvore lógica que permite representar políticas na forma de variáveis unicamente identificadas. PRC - Provisioning Classes PRI - Provisioning Instances

Tipos de Classes PIB 1) Notify: PEP  PDP 2) Install: PDP  PEP os valores dos atributos destas classes são definidos pelo próprio dispositivo (PEP). 2) Install: PDP  PEP os valores dos atributos destas classes são preenchidos de acordo com a decisão do PDP. 3) Notify / Install : PDP  PEP as classes deste tipo combinam as características dos dois ítens acima,

Exemplo: Diffserv PIB O IETF definiu algumas PIBs padronizadas, como para os casos do IPsec e do Diffserv.

Exemplo: Diffserv PIB B B 1

Representação OID

Exemplo: CIM X QPIM X PIB

Princípios do Modelo Provisioning

Feedback do uso de políticas O feedback do uso de políticas pode ser: Periódico ou solicitado As políticas solicitadas definem as características a serem monitoradas e o intervalo para envio de relatórios. O feedback é enviado pelo PEP pela mensagem de Report O feedback pode ser utilizado para implementar políticas dinâmicas e mecanismos de contabilização.

Failover Se a conexão TCP com o PDP cair o PEP usa as políticas guardadas em cache. No restabelecimento da conexão, o PDP envia uma mensagem de re-sincronização para as políticas guardadas em cache.

Conclusão Policy Based Networking é uma nova abordagem amplamente adotada pelo DMTF e o IETF. A arquitetura de Policy Based Networking é baseada no framework: PDP, PEP e COPS. Sua aplicabilidade inicial é para gerenciar políticas de QoS e Segurança em dispositivos de rede. Todavia, o modelo PCIM pode ser adaptado para qualquer outra área de configuração e contabilização de dados.

ANEXOS A RMON

Monitoração de redes SNMP e MIBs em agentes só permitem analisar valores isolados (nos agentes) Como medir o tráfego na rede ? tráfego = 137 kbps tráfego = 55 kbps tráfego = ?

Monitores de rede Ouvem a rede continuamente Podem ouvir várias redes Não interferem nas redes monitoradas monitor

Informações monitoradas Todos os pacotes são ouvidos Podem ser aplicadas filtragens tipo de pacote, protocolo, origem, destino, ... Produção de dados estatísticos distribuição por tipo de pacote percentual de colisões taxas de transferência Armazenagem de pacotes para análise

Monitorando múltiplas redes Um monitor para cada sub-rede Monitores devem ser acessíveis pelo gerente monitores gerente router

Definindo um monitor Definir a informação a armazenar significado dos dados tipos dos dados estrutura geral da informação Definir formas de acesso leitura/escrita configuração relatar eventos Implementar como um dispositivo dedicado serviço adicionado a um elemento da rede

RMON RMON: Remote Monitoring Norma para monitores de redes Define uma (imensa) MIB Dados são acessados via SNMP Efetua a monitoração contínua de redes Versões: RMON v1: monitoração MAC (ethernet, token ring, ...) RMON v2: monitora camadas mais elevadas Monitor: agente RMON ou sonda RMON

Objetivos de RMON Operação off-line Monitoração pró-ativa autônoma (independe do gerente) diminui o tráfego de rede Monitoração pró-ativa diagnósticos contínuos monitoração de desempenho pode gerar alarmes enviados ao gerente

Objetivos de RMON (2) Informações de valor agregado dados estatísticos informações históricas Acesso por múltiplos gerentes diferentes objetivos de gerência tolerância a falhas Compatibilidade com padrões informação na forma de MIBs acesso via protocolo SNMP

Controle da sonda RMON Monitor é acessado remotamente para: configuração geral invocação de ações Configuração: indicar tipo e forma dos dados a coletar manipulação de tabelas de controle Ações: leitura e escrita de valores invocação de “value triggered commands”

Organização da MIB RMON Cada grupo consiste de: uma ou mais tabelas de dados (read-only) uma ou mais tabelas de controle (read-write) Tabelas de dados: valores coletados da rede e processados Tabelas de controle indicam que dados devem ser coletados cada linha representa uma função de coleta Podem ser fundidas em uma só tabela

Múltiplos gerentes Vários gerentes podem acessar uma sonda acessos concorrentes podem saturar a sonda um gerente pode monopolizar a sonda Para o controle de múltiplos gerentes: cada linha da tabela de controle possui um owner propriedade: IP do gerente, localização, telefone, ... informação de propriedade não limita o acesso o monitor pode ser proprietário de algumas linhas

Gerência de tabelas Complexo e pouco claro (Stallings 96 !) Inserção e remoção de linhas nas tabelas de controle Cada linha de tabela de controle possui: OwnerString: o proprietário da linha de controle EntryStatus: situação daquela linha: valid create request under creation invalid Demais informações

Indexação de tabelas xyzControlTable xyzDataTable

Inserção de linhas Através do método SNMP set: set [index, (tipo, valor), (tipo, valor), ...] erro badValue em caso de dado inválido ou impossibilidade de criação tratamento de conflitos em acessos simultâneos torna-se necessário

Passos para a criação de linhas Seqüência de passos para criar linhas: 1. se a linha solicitada não existe (índice inexistente), ela é criada e seu status recebe o valor “createRequest”; 2. imediatamente após a criação o monitor muda o status da linha para “underCreation”; 3. as novas linhas permanecem nesse estado até o gerente terminar de criar todas a linhas desejadas; 4. ao final o gerente seta o campo de status das linhas criadas por ele para o valor “valid”; 5. tentativas de criar linhas cujos índices já existem resultam em erro.

A MIB RMON rmon (16) mib-2 statistics (1) history (2) alarm (3) host (4) hostTopN (5) matrix (6) filter (7) capture (8) event (9) tokenRing (10)

Grupo statistics Uma tabela para cada sub-rede monitorada sub-rede referenciada por sua interface Informações mais importantes: carga da sub-rede saúde da sub-rede (erros, colisões) pacotes fora de tamanho (undersize, oversize) Mais detalhado que mib-2.interfaces

Grupo history Amostragens do tráfego nas interfaces ao longo do tempo de operação Cada linha da tabela de controle define um conjunto de amostras Cada linha da tabela de dados corresponde a uma amostra Defaults: cada amostra dura 1800 segundos as 50 últimas amostras são mantidas

Outros grupos hosts hostTopN matrix tokenRing estatísticas sobre hosts na sub-rede hostTopN estatísticas sobre hosts segundo algum critério armazena dados sobre os N primeiros hosts em termos de tráfego, erros, tipos de pacotes, etc. matrix armazenar dados sobre tráfego entre pares de hosts tokenRing suporte a informações de redes token-ring

Alarmes Alarmes são registrados na MIB Cada entrada da tabela contém: gerados pelo grupo alarm tratados pelo grupo event podem ser enviados ao gerente via traps Cada entrada da tabela contém: OID da variável a ser monitorada intervalo de amostragem parâmetros de limiar (threshold) Um exemplo: + de 500 erros CRC nos últimos 5 minutos

O ciclo de histerese Pequenas flutuações no valor monitorado poderiam gerar alarmes excesso de alarmes sem utilidade Usa dois limiares de disparo do alarme: inferior: valor mínimo em condições normais superior: valor máximo em condições normais Gerar alarmes somente quando: valor ultrapassar o limite superior valor descer abaixo do limite inferior de forma alternada !

O ciclo de histerese disparo do alarme inferior disparo do alarme superior estado do alarme alarme superior alarme inferior valor monitorado

Geração de alarmes Alarme é gerado quando: valor maior que o limiar superior (risingThreshold) valor menor que o limiar inferior (fallingThreshold) valor lim sup lim inf tempo disparos

O grupo filter Permite regras de filtragem dos pacotes dois tipos de filtros: data filter: padrões de bits nos pacotes status filter: status dos pacotes (válido, erro de CRC, ...) filtros podem ser combinados operações lógicas AND, OR, seqüências Os pacotes filtrados: constituem um fluxo chamado canal (channel) podem disparar eventos podem ser armazenados no grupo capture

Considerações práticas Uso correto da sonda e do gerente evitar uso abusivo de alarmes e eventos uso inteligente de filtros e captura risco de saturar a sonda e a rede poder de processamento da sonda é limitada Problemas de interoperabilidade discrepância entre MIBs de fabricantes distintos muitas funções são parcialmente implementadas

RMON v2 RMON v1: RMON v2: Outras inovações limitado à camada MAC ethernet e token-ring poucos recursos de configuração RMON v2: suporte às demais camadas (3 a 7) monitoração de protocolos de aplicação visibilidade de tráfego vindo de fora (IP) tabelas replicadas para cada protocolo Outras inovações grupo MIB de configuração da sonda

ANEXOS B SNMPv2

SNMPv2 Definido em 1993 (RFC) Suporte flexível: gerência centralizada gerência distribuída Modificações mais significativas: estrutura de informação (SMI) interações “gerente a gerente” operações do protocolo

SMI em SNMPv2 Super-conjunto da SMI em SNMPv1 Especificação e documentação mais elaboradas dos objetos da MIB Novos conceitos: definições de novos objetos tabelas conceituais novas definições de notificações módulos de informação

Definições de objetos Melhor definição de OBJECT-TYPE Novos tipos de dados: Counter32 Unsigned64 Remoção de ambigüidades de SNMPv1 Novas interpretações de alguns tipos: Gauge32 Counter64

Cláusula MAX ACCESS Similar a ACCESS, enfatizando que o acesso não pode ser modificado por configuração do agente Níveis de acesso: not accessible accessible for notify read only read-write read-create (tabelas conceituais)

Cláusula STATUS Novos status: Desaparecem: current deprecated obsolete mandatory optional

Tabelas Duas categorias de tabelas: Criação/deleção de linhas estrutura fixa estrutura alterável Criação/deleção de linhas operações pelo gerente, via SNMP extremamente complexo e controverso segue o modelo adotado em RMON

O protocolo SNMPv2 Três formas de interação manager to agent, request/response agent to manager, unconfirmed manager to manager, request/response o último é definido em SNMPv2

PDUs SNMPv2 GetRequest, GetNextRequest SetRequest GetBulkRequest similar à de SNMPv1 resposta não é mais atômica SetRequest idem GetBulkRequest busca de grandes blocos de dados equivale a um GetNextRequest múltiplo

PDUs SNMPv2 InformRequest ReportPDU comunicação entre gerentes enviado pelo gerente que deseja enviar a informação resposta ResponsePDU sem conteúdo. ReportPDU não utilizada (abandonada nas RFCs)

ANEXOS C LDAP

Raizes de Árvore no Servidor Raiz do diretório ou=Groups o=ppgia.pucpr.br Servidor LDAP ou=People 389 o=NetscapeRoot

Exemplo o=ppgia.pucpr.br Objectclass = organization ou=Exemplo Objectclass=organizationalUnit ou=Funcionarios ou=Grupos Objectclass =organizationalUnit cn=ejamhour ou=analistas Objectclass =groupOfNames cn=acalsavara Objectclass =inetOrgPerson

Parâmetros do LDAP <host> <porta> <base_dn> Nome (ou endereço IP) do servidor LDAP (por exemplo, ldap.ppgia.pucpr.br ou 200.17.98.174). <porta> Porta do servidor LDAP. Se nenhuma porta for especificada, assume-se a porta padrão 389. <base_dn> dn do ponto de início da procura. <atributos> indica quais atributos do objeto serão retornados. <escopo> define como efetuar a procura. <filtro> define os critérios da procura.

Exemplos de Consulta LDAP em URL ldap://servidorLDAP/ou=RSD,o=ppgia.pucpr.br Solicita o todos os campos do objeto RSD ldap://servidorLDAP /ou=RSD,o=ppgia.pucpr.br? endereço Solicita apenas o campo endereço do objeto PUCPR. ldap://servidorLDAP / ou=RSD,o=ppgia.pucpr.br? email?sub?(cn=Alc*) Solicita todos os emails da PUCPR pertencentes a usuários que tem o nome começando por Alc.

Comandos para localizar o usuário Procura todas as pessoas em ppgia.pucpr.br: Servidor: ldap://icaro.ppgia.pucpr.br/ Search Root: o=ppgia.pucpr.br Escopo: sub Filtro: (objectclass=Person) Procura as pessoas em sua_Unidade Search Root: ou=sua_Unidade,o=ppgia.pucpr.br Procura as pessoas em Curitiba Search Root: ou=Curitiba,ou=sua_Unidade,o=ppgia.pucpr.br

Procura por Atributos Atributos disponíveis para Person: telephoneNumber, seeAlso, userPassword, description Atributos para organizationalperson: title, street, ou, postalAddress, postalCode Exemplo de Consulta: Filtro: title=Professor) Filtro: (title=Prof*)

Filtros LDAP a) Especifica objetos do tipo carro (objectClass=carro) b) especifica carros da marca Golf ou Vectra ( &(objectClass=carro) ( |(marca=Golf)(marca=Audi))) c) especifica carros da marca Golf ou Vectra mas não importados. ( &(objectClass=carro) (|(marca=Golf)(marca=Audi)) (!(origem=importado)))

Servidores LDAP Stand Alone e Referral Quando um servidor LDAP não conhece a resposta a uma pergunta do cliente, e pelo indicar um outro servidor LDAP (chamado referral) ou uma lista de servidores LDAP para o cliente consultar. LDAP LDAP Servidor LDAP CLIENTE LDAP Servidor LDAP LDAP Servidor LDAP

Diretório Distribuído: Smart Referral icaro.ppgia.pucpr.br o=ppgia.pucpr.br hal2002.ppgia.pucpr.br ou=Exemplo o=ppgia.pucpr.br ou=São Paulo ou=Curitiba ou=Exemplo ou=Persons ref=xxxx ou=Curitiba cn=George Bush Objectclass = referral ou=Persons cn=Bill Gates

Sintaxe O objeto referral deve ter um link para o servidor para o qual se deseja redirecionar as consultas: No exemplo anterior: No servidor icaro deve ser criado A) Um objeto vazio do tipo unidade organizacional: ou=Curitiba Este objeto deve ser derivado de: organizatinalunit refferal B) O atributo refferal permite redirecionar as consultas: ref = ldap://hal2002.pucpr.br/ou=Curitiba,ou=Exemplo, o=ppgia.pucpr.br

Exemplo O arquivo LDIF que cria um entrada de referral é ilustrado abaixo: dn: uid=ACalsavara, ou=people, dc=pucpr,dc=br objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetOrgPerson objectclass: referral cn: Alcides Calsavara sn: Calsavara uid: ACalsavara ref: ldap://10.32.1.253/cn=Alcides%20Calsavara,ou=people, l=europe,dc=pucpr,dc=br

Diretório Distribuído: Smart Referral hal2002.ppgia.pucpr.br o=ppgia.pucpr.br ou=Exemplo icaro.ppgia.pucpr.br o=ppgia.pucpr.br ou=Curitiba ou=São Paulo ou=Exemplo ou=Persons ref=xxxx ou=São Paulo ou=Curitiba cn=George Bush Objectclass = referral ou=Persons ref=yyyy cn=Bill Gates