Curso de TCPIP Avançado v.2

Curso de

TCP-IP Avançado

V.2.0

abril de 2004

Curso de TCP-IP Avançado 2 de 126

AVISO IMPORTANTE Esta apostila é parte integrante do Curso de TCP-IP Avançado,

desenvolvido pela TopMaster para a Embratel. O objetivo deste documento é apresentar uma versão textual do conteúdo do curso online para a conveniência do aluno.

Sua leitura não substitui o estudo online, pois este oferece interações e animações que não podem ser representadas no formato impresso.


1. Roteamento IP Avançado

1.1. O Conceito de AS A definição clássica de um Autonomous System é um conjunto de roteadores sob uma única administração técnica que usam um mesmo IGP (Interior Gateway Protocol) e métricas comuns para efetuar o roteamento dos pacotes dentro do AS, além de utilizarem um EGP (Exterior Gateway Protocol) para rotear os pacotes aos outros ASs. No entanto, desde que esta definição clássica foi desenvolvida, tornou-se comum um único AS usar vários IGP's e até diversas métricas para a troca de informações de roteamento internas ao AS.

Com isso, uma definição mais apropriada para o termo Autonomous System deve considerar que, mesmo quando existem múltiplos IGPs e métricas, um AS aparece para outros ASs como um conjunto coerente de redes que possui uma única e clara política de roteamento totalmente 'invisível' para os outros ASs, e que permite que estes alcancem as redes internas do AS através do uso dos EGPs, que são executados nos roteadores que fazem a interface entre os Autonomous Systems.


Os ASs são identificados por um número globalmente unívoco, freqüentemente referido como ASN (Autonomous System Number). Este número é usado tanto na troca da informação entre ASs quanto como um identificador interno do AS.

Os valores de AS variam de 0 a 65535 para o BGP (Border Gateway Protocol), que vem a ser o EGP usado para roteamento entre ASs na Internet, sendo que os valores de 64512 a 65535 são destinados a ASs privativos usados em redes internas e não propagados externamente.

Como regra geral, recomenda-se colocar o maior número de blocos de endereçamento IP dentro de um mesmo AS, respeitando a premissa de que todos devem estar em conformidade com a mesma política de roteamento.

Considera-se fundamentalmente que a obtenção de um AS para um conjunto de blocos de endereçamento IP somente é necessária quando temos uma política de roteamento diferente à dos roteadores de borda que nos conectam com o resto da Internet. Definimos como política de roteamento o modo pelo qual os outros ASs tomam decisões de roteamento para alcançar os blocos de endereço IP do meu Autonomous System baseadas nas informações fornecidas por ele.

Tipos de AS

AS Trânsito São ASs usados como passagem de tráfego entre ASs.

Stub AS São ASs como um único ponto de entrada/saída. Não há tráfego de outros ASs passando por um Stub AS.


1.2. Protocolo EGP O protocolo EGP (Exterior Gateway Protocol) é um protocolo de roteamento do tipo externo, ou seja, é utilizado pelos roteadores que conectam diferentes ASs (Autonomous Systems), os chamados 'exterior routers', para anunciar as informações que permitem a comunicação entre diferentes ASs.

O EGP foi o protocolo de roteamento externo mais utilizado para interligação dos diversos ASs da Internet até o início dos anos 90, quando o principal backbone da grande rede pertencia à National Science Foundation, instituição de pesquisa vinculada ao governo dos EUA.

O EGP está fundamentado em três tipos de processo de comunicação:

• Estabelecimento de vizinhança: para que a troca de informação entre exterior routers seja possível, é preciso que os mesmos estabeleçam uma relação de vizinhança (neighboring). A partir daí, as informações de controle e roteamento poderão ser trocadas entre os, agora, exterior neighbors routers.

• Verificação do estado do roteador neighbor: Os exterior neighbors checam periodicamente se o seu parceiro está UP por meio de mensagens de controle trocadas entre eles.

• Troca de informação de roteamento: Após o estabelecimento da vizinhança e depois da verificação do estado do EGP neighbor, os exterior neighbor routers estão prontos para trocarem as informações de roteamento que permitirão que os hosts localizados em seus respectivos ASs consigam comunicar-se entre si.


Tipos de mensagem do protocolo EGP O funcionamento do EGP baseia-se em três tipos de comunicação entre os roteadores que executam o protocolo: estabelecimento de vizinhança (Neighbor Acquisition), verificação do estado do roteador neighbor (Neighbor Reachability) e troca de informação de roteamento.

Essas três categorias ou tipos de mensagens podem ser divididas em nove subtipos definidos pelo protocolo EGP para sua execução.

Independentemente do tipo de mensagem EGP que está sendo enviada, encontraremos os seguintes campos comuns a todos os pacotes de mensagens:

Version Identifica a versão do EGP usada pelo remetente. O roteador que recebe a mensagem verifica se a versão do EGP que se está usando é compatível.

Type Identifica o tipo de mensagem.

Code Identifica o subtipo para cada tipo de mensagem.

Status Informa o status. Os valores diferem dependendo do tipo de mensagem.

Checksum Verifica a integridade da mensagem.

Autonomous System Number (ASN) Identifica o AS ao qual pertence o roteador remetente.

Sequence Number Número usado para identificar mensagens enviadas e suas respostas. Quando dois roteadores tornam-se neighbors, cada um determina um número seqüencial inicial para suas mensagens. Cada mensagem é enviada com o seqüencial e as respostas a essas mensagens contêm o mesmo número de seqüência.

Descrição das mensagens EGP A tabela, a seguir, resume os tipos de mensagens do protocolo EGP, bem como os subtipos de mensagens. Clique em cada um deles para saber mais sobre o tipo ou subtipo referido.


Neighbor Acquisition

Acquisition Request: Solicitação para torna-se um neighbor Acquisition Confirm: Resposta positiva ao Acquisition Request Acquisition Refuse: Resposta negativa ao Acquisition Request Cease Request: Solicita o fim de uma relação de neighbor Cease Confirm: Resposta de confirmação ao Cease Request

Neighbor Reachability

Hello: Solicita ao neighbor que responda se estiver 'vivo' I Heard You: Resposta ao Hello

Informação de roteamento

Poll Request: Solicita a atualização das informações de roteamento Routing Update: Informações de roteamento

Mensagens de Estabelecimento de Vizinhança (Neighbor Acquisition Messages) A fim de iniciar o processo de comunicação EGP, um roteador envia uma mensagem de Neighbor Aquisition ao seu par pertencente a outro AS para, com isso, criar a relação de vizinhança entre ambos.

Além dos campos comuns a todas as mensagens EGP, dois campos são específicos das mensagens de Neighbor Acquisition: Hello Interval e Poll Interval.

As mensagens de Neighbor Acquisition são do tipo 3 e possuem 5 subtipos identificados pelos códigos de 0 a 4.

O cabeçalho completo deste tipo de mensagem fica, portanto, como se segue:

Code (0 a 4)

Subtipos das Mensagens de Neighbor Acquisition (Type 3)

Code 0: Acquisition Request

Code 1: Acquisition Confirm

Code 2: Acquisition Refuse

Code 3: Cease Request

Code 4: Cease Confirm

Hello Interval - Especifica o intervalo de tempo que deverá ser usado entre os neighbors para a verificação de estado de seus pares (se Up ou Down).


Mensagens de Verificação do Estado do Roteador Neighbor (Neighbor Reachability Messages) O mecanismo pelo qual o EGP verifica se o roteador neighbor está UP, ou seja, apto a receber as mensagens de atualização de rotas, é o envio de mensagens de Hello. A cada n segundos, definidos no estabelecimento dos neighbors, um dos pares envia uma mensagem de Hello para o seu neighbor que responde com a mensagem I Heard You, confirmando, dessa forma, seu estado de 'vivo' e operante.

Considerando a hipótese de perda de mensagens por motivos como congestionamento na rede ou aumento na taxa de erros do meio físico, o EGP tem como padrão aguardar 2 pacotes de mensagem de Hello não respondidas para considerar o estado do neighbor como DOWN. Da mesma forma, é preciso que haja 2 respostas consecutivas a mensagens de Hello para que um neighbor que encontrava-se em estado DOWN seja considerado novamente operante.

O formato das mensagens de Hello e sua resposta I Heard You consiste no cabeçalho padrão do EGP com campo de tipo igual a 5 e dois subtipos (códigos) iguais a 0 e 1, significando Hello e I Heard You, respectivamente.

Code (0 a 1)

Subtipos das Mensagens de Neighbor Reachability (Type 5)

Code 0: Hello

Code 1: I Heard You


Mensagens de troca de informação de roteamento As informações de atualização de rotas são passadas via mensagens de Routing Update em resposta a mensagens de solicitação de informações de roteamento do tipo Poll Request.

Mensagem Poll Request

Depois de transcorrido o tempo acordado durante o processo de estabelecimento de vizinhança para solicitação de informação de rotas (Poll Interval), um dos pares envia um Poll Request contendo o cabeçalho padrão EGP e o campo IP Source Network. Esse campo identifica a rede comum aos ASs de ambos os EGP neighbors, que muitas das vezes consiste na própria rede que conecta os EGP neighbors.

Mensagem de Routing Update

A mensagem de Routing Update, enviada em resposta ao Poll Request, contém uma lista de gateways localizados na rede comum (IP Source Network) e a lista de redes que podem ser acessadas através desses gateways.

Dois tipos de listas de gateways podem ser enviadas:

Lista Interna (Interior Gateways) Contém somente os gateways pertencentes ao mesmo AS do EGP neighbor que envia a mensagem de Routing Update.


Lista Externa (Exterior Gateways) Contém gateways de outros ASs que são também caminho para as redes em questão.

É importante observar que as listas internas e externas NÃO são incluídas na mesma mensagem; elas são sempre anunciadas em mensagens distintas.

As distâncias são medidas em hop counts, isto é, pela quantidade de roteadores que são transpassados entre a Source Network e as redes contidas no bloco de mesma distância (Distance 1, Distance 2,..., Distance n).


Entretanto, essas distâncias não são levadas em conta como indicadores de melhor rota na comunicação entre os exterior routers de diferentes ASs. O fato de existir uma métrica de distância somente indica que a rede anunciada pode ser alcançada através do gateway associado. Na verdade, a arquitetura do EGP considera que somente deve haver 1 caminho para qualquer rede participante, não considerando, portanto, rotas alternativas.

A mensagem de Routing Update tem a seguinte estrutura:

# Interior Gateways: Número de Interior Gateways que aparecem na mensagem.

# Exterior Gateways: Número de Exterior Gateways que aparecem na mensagem.

IP Source Network: Rede a partir da qual as distâncias são medidas.


Gateway n IP Address: Endereço IP do gateway n da lista.

# Distances: Número de distâncias existentes para um mesmo gateway.

Distance n: Identifica a quantidade de hop counts para se alcançar as redes contidas neste bloco.

# Networks: Número de redes existentes alcançáveis através da mesma distância.

Network n: Endereço IP da rede.

Limitações do Protocolo EGP O EGP foi inicialmente projetado para uma Internet de dimensões reduzidas onde o backbone NFSNet era formado por uma quantidade muito pequena de roteadores. Com o estouro da Internet comercial, este protocolo mostrou muitas deficiências que fizeram com que o BGP fosse a solução escolhida a partir do início dos anos 90.

Algumas das limitações do EGP que lhe conferem um baixo grau de escalabilidade, são:

- Toda a conectividade é perdida em caso de falha dos roteadores conectados diretamente ao backbone principal (core system routers);

- O EGP somente permite o anúncio de 1 caminho para cada rede;

- Não permite balanceamento de carga entre ASs mesmo que existam múltiplos roteadores fazendo a conexão entre eles;

- O EGP não se adequa à arquitetura de redes com múltiplos backbones.

A seção sobre o protocolo BGP mostra, entre outros assuntos, como o BGP trata estas limitações.

1.3. Protocolo BGP O Border Gateway Protocol (BGP) é um protocolo de roteamento tipicamente usado para viabilizar a comunicação entre ASs. Foi construído baseado na experiência obtida com o EGP no backbone da NSFNET como descrito nas RFCs 1092 e 1093.

O BGP é um protocolo bastante robusto e escalável, evidenciado pelo fato de que o BGP é amplamente empregado no backbone da Internet nos dias de hoje.

O BGP necessita estabelecer uma sessão TCP para que a troca de informações possa acontecer. O TCP atende às exigências de transporte do BGP e é suportado por praticamente todos os roteadores e hosts comerciais. O BGP usa a porta TCP/179 em suas conexões.

Estima-se que as tabelas de rotas BGP da Internet somam atualmente mais de 90.000 entradas. Para conseguir uma escalabilidade nesse patamar, o BGP usa atributos para definir políticas de distribuição de rotas e manter um ambiente de roteamento estável.


Além dos atributos que definem as políticas de roteamento, o suporte ao CIDR (Classless Inter-Domain Routing) é outra feature importante do BGP, que permite reduzir o tamanho das tabelas de rotas da Internet.

Exemplo:

CIDR - Classes Inter-Domain Routing

Suponha que um ISP tenha recebido o bloco 195.10.x.x do espaço de endereçamento da classe C. Este bloco consiste em 256 redes classe C: de 195.10.0.x até 195.10.255.x. Consideremos então que o ISP ceda um bloco de rede classe C a cada um de seus clientes. Sem CIDR, o ISP anunciaria 256 entradas de rede classe C a seus pares BGP. Com CIDR, é possível fazer o supernetting desse bloco, anunciando somente uma rota para os outros roteadores, o que significa somente uma entrada na tabela de roteamento: 195.10.x.x. Ou seja, o BGP desconsidera as distinções tradicionais de classes de endereçamento (A, B e C) graças ao suporte ao CIDR, permitindo uma redução significativa em suas tabelas de rotas.

Outra característica importante do BGP consiste no fato de que os roteadores somente trocam as tabelas de rotas completas quando a conexão TCP entre os pares (peers) ou neighbors BGP é estabelecida inicialmente. A partir daí, apenas as alterações são enviadas. Além disso, os roteadores BGP não emitem updates periódicos de suas tabelas de roteamento e sim utilizam o método de Triggered Updates onde as atualizações de rotas são enviadas somente quando algum evento pré-definido dispara o processo de emissão de informações. Dessa forma, o uso da banda dos circuitos de longa distância que comumente conectam os pares BGP (BGP peers) é otimizado.

iBGP e eBGP iBGP ou Internal BGP é usado para troca de informações de roteamento entre roteadores dentro do mesmo AS. Para que as mensagens iBGP possam ser trocadas, é preciso que exista a conexão entre todos os roteadores do AS constituindo uma topologia lógica de Full-Mesh. eBGP ou External BGP é usado para troca de informações de roteamento entre diferentes ASs. É preciso que seja apenas estabelecida a sessão entre os Neighbors BGP diretamente conectados entre si.

Quando usar ou não o BGP O BGP é um protocolo de roteamento bastante complexo e, portanto, a primeira análise a ser feita é a que define a necessidade de usá-lo em detrimento a rotas estáticas ou rotas default.

Devemos usar o BGP quando:

- For necessária a comunicação entre ASs;

- Precisa-se manipular o tráfego de saída de nosso ASs. Por exemplo, quando desejamos definir que o tráfego X sairá pelo roteador RX e o tráfego Y sairá pelo roteador RY;

- Deseja-se conectar dois ou mais ISPs entre si;

- Deseja-se conectar uma empresa a mais de um ISP.


Não devemos usar o BGP quando:

- O hardware do roteador não suporta a carga de processamento e de memória exigida. Lembre-se de que a tabela BGP da Internet hoje contém em torno de 90.000 entradas;

- A empresa possui apenas 1 ligação com a Internet. Nesse caso, recomenda-se o uso de rota default;

- Quando a conexão não possui banda suficiente para atender à carga de tráfego requerida pelo BGP.

Mensagens BGP

Cabeçalho comum Antes de entrarmos na análise dos detalhes de cada tipo de mensagem, apresentaremos os campos do cabeçalho BGP comuns a todos os tipos de mensagem.

Marker Serve para verificar a autenticidade da mensagem recebida e se houve perda de sincronização entre os roteadores vizinhos BGP. Pode ter dois formatos: caso a mensagem seja do tipo OPEN (abrir), ou se a mensagem tipo OPEN não possuir informação de autenticação, o campo deve estar todo preenchido com números um (1); caso contrário, o campo terá o seu conteúdo baseado em parte do mecanismo de autenticação usado.

Length Indica o tamanho total da mensagem BGP, incluindo o cabeçalho.

Type Tipo da mensagem que está sendo enviada. São 4 os tipos de mensagens utilizadas pelo BGP em seus processos de roteamento:

Valor do campo Type 1: Mensagem OPEN

Valor do campo Type 2: Mensagem UPDATE

Valor do campo Type 3: Mensagem NOTIFICATION

Valor do campo Type 4: Mensagem KEEPALIVE

BGP OPEN Message Esta é a primeira mensagem emitida logo após a sessão TCP ter sido estabelecida entre os BGP peers. Nesta mensagem, é identificado o AS ao qual pertence o roteador. São acertados os parâmetros do protocolo e temporizadores que serão usados ao longo da sessão.


Mensagem BGP OPEN

Version Indica a versão do BGP. Este campo permite que os BGP peers negociem a maior versão comum a ambas as partes. Quando, por exemplo, um peer recebe uma mensagem indicando que a outra parte executa a versão 4 e ele suporta uma versão inferior. O recipiente envia uma mensagem de erro e o remetente solicita uma nova sessão com os parâmetros usados pela versão inferior.

My Autonomous System ASN do roteador que envia a mensagem de OPEN.

Hold Time Tempo máximo que os peers esperam antes de considerar a conexão terminada. O valor mínimo permitido para este parâmetro é de 3 segundos.

BGP Identifier Pela especificação do BGP, o identificador é um valor randômico e único escolhido pelo roteador no momento do envio da mensagem OPEN. As implementações práticas usam o endereço IP da interface em saída da mensagem ou, se definido, o endereço de loopback.

Optional Parameters Length Indica o tamanho do campo de parâmetros opcionais (Optional Parameters).

Optional Parameters Parâmetros opcionais incluídos na mensagem BGP OPEN.

BGP UPDATE Message Esta mensagem carrega as mudanças de topologia. A mensagem de UPDATE pode conter uma nova rota, rotas a serem removidas ou ambas.

Mensagem BGP UPDATE

Withdrawn Routes Lengh Tamanho do campo Withdrawn Routes em octetos.


Withdrawn Routes Lista de rotas a serem excluídas, seja pelo fato de o caminho não mais existir ou pela inclusão de políticas que limitem o acesso à rede destino.

Total Path Attributes Length Tamanho do campo Total Path Attributes.

Path Attributes São um conjunto de parâmetros associados a uma determinada rota que influenciam no processo de decisão do BGP em relação à escolha da melhor rota. Mais adiante, estes atributos serão vistos com mais detalhes.

Network Layer Reachability Information (NLRI) São prefixos de endereços IP de informações no formato <comprimento, prefixo>. Um exemplo de entrada seria: <24,200.210.10.0>, que indica uma rota para 200.210.10.0 255.255.255.0 (ou 200.210.10.0 /24, na notação CIDR).

Atributos BGP

Conforme visto, as mensagens UPDATE incluem o campo PATH Attributes que carrega as informações dos atributos BGP para as rotas anunciadas no campo NLRI. Os Path Attributes podem ser considerados como métricas usadas pelo BGP que passam pelos routers para seus peers.

Categorias de atributos

Existem as seguintes categorias de atributos:

• Well-Known Mandatory Trata-se de um atributo definido na especificação original do protocolo BGP. Deve estar obrigatoriamente presente em todas as mensagens do tipo UPDATE e deve ser reconhecido em todas as implementações do protocolo. Caso não esteja presente na mensagem UPDATE, será enviada uma mensagem do tipo NOTIFICATION informando o erro.

• Well-Known Discretionary É o tipo do atributo reconhecido por todas as implementações do protocolo BGP mas que não precisa estar obrigatoriamente presente em todas as mensagens UPDATE enviadas.

Além dos atributos Well-Known, existem os opcionais, que podem ser transitivos ou não e que não são obrigatoriamente suportados por todas as implementações do BGP. Atributos transitivos são repassados nas mensagem de UPDATE para os peers seguintes.

• Optional Transitive Se determinada implementação do BGP não reconhecer um atributo opcional ao receber uma mensagem UPDATE, ela verificará se a flag Transitive está ativada ou não para aquele atributo. Caso esteja, esse atributo é repassado nas mensagens UPDATE seguintes, enviadas pelo roteador para seus pares.

• Optional Non-Transitive Inverso do opcional transitivo. Se a implementação do BGP não reconhecer o atributo opcional e não encontrar a flag transitive ativada, o atributo é ignorado e NÃO é repassado para os vizinhos BGP nas mensagens UPDATE subseqüentes.


Vale observar que TODOS os atributos Well-Known são transitivos.

Tipos de atributos

Vistas as quatro categorias de atributos, vamos descrever agora os tipos de atributos encontrados nas mensagens de UPDATE do BGP.

ORIGIN Well-Known Mandatory Indica a origem do anúncio de rota ou NLRI (que indica o prefixo e a máscara de bits) em relação ao AS que o originou. Pode conter um dos seguintes valores:

Valor Descrição

0 IGP A origem é interna ao AS originário da mensagem (indicado por um "i" na tabela de rotas), seja ela recebida através da redistribuição das rotas do IGP para o BGP (do mesmo AS) ou pela simples configuração do BGP naquele roteador.

1 EGP A origem é de um AS externo e foi recebida por um anúncio de um EGP. É identificada por um "e" na tabela de rotas. Este tipo de entrada dificilmente será visto nas tabelas de rotas atualmente.

2 INCOMPLETE A NLRI é desconhecida ou aprendida por outros meios (além dos acima). Geralmente acontece quando uma rota estática (configurada manualmente por um operador) é redistribuída no BGP e a origem da rota fica incompleta. É indicada por um "?" na tabela de rotas.

AS PATH Well-Known Mandatory É uma seqüência de ASNs que uma rota cruza para alcançar uma determinada rede de destino. O AS que origina uma rota acrescenta seu ASN ao anunciar uma rota sua para seus peers BGP externos. Daí em diante, cada AS que receber a rota acrescenta seu próprio ASN no início da seqüência de ASNs e repassa a rota para outros peers seus que irão fazer o mesmo. A lista final vai representar todos os ASNs que uma rota atravessou com o ASN do AS de origem da rota no final da seqüência, também conhecida como AS_Sequence.

Caso um AS receba um anúncio de rota que contenha seu próprio ASN na seqüência inclusa no AS_PATH, este anúncio será rejeitado e descartado, garantindo assim que não haverá loop de roteamento na tabela BGP desse AS.


Caso o AS_PATH seja anunciado para um vizinho do mesmo AS, a informação contida no AS_PATH não é alterada.

A informação contida no AS_PATH é uma das usadas no processo de seleção da melhor rota para determinado destino. Ao comparar duas rotas para um mesmo destino (considerando que os outros atributos sejam idênticos), o BGP vai preferir a que possuir o AS_PATH menor. Caso o caminho (path) seja do mesmo tamanho, o BGP vai usar outros atributos para fazer a sua escolha da melhor rota.

NEXT HOP Well-Known Mandatory Este atributo contém o endereço IP da interface do próximo roteador - próximo salto (next hop) a ser dado - para se chegar a determinado destino, ou seja, às redes de destino incluídas na mensagem UPDATE.

Um roteador BGP nunca deve anunciar como NEXT_HOP o IP do roteador de onde foi originada a mensagem de UPDATE recebida, a fim de evitar loops de roteamento.

MED - MULTI_EXIT_DISCRIMINATOR Optional Non-Transitive Este atributo tem como finalidade informar para os vizinhos BGP externos (peers) qual o melhor caminho (path) para uma determinada rota do próprio AS, influenciando-os, assim, em relação ao caminho a ser seguido no caso de o AS possuir diversos pontos de entrada.

O MED é anunciado somente entre ASs. No entanto, só o AS de origem pode fazer anúncios com valores neste atributo. Um AS vizinho que receba o atributo via mensagem UPDATE não pode repassar o valor desse atributo a outros ASs fazendo uso dos mesmos apenas para tomadas de decisão internas do AS. Um exemplo seria quando o anúncio da rota é repassado a um terceiro AS e o atributo MED recebe o valor 0 (zero). O BGP seleciona a rota que possuir o atributo MED com menor valor. Havendo contato com mais de um vizinho BGP pertecentes a um mesmo AS que façam anúncios com métrica, o roteador (do AS vizinho) que receber os UPDATEs vai comparar as métricas para os caminhos oferecidos por estes roteadores, se ele não for configurado para o contrário.

LOCAL_PREF (Local Preference) Well-Known Discretionary Este atributo anuncia qual é o caminho preferencial de saída (de pacotes) para uma determinada rota, destinada a uma rede externa ao AS. Como o próprio nome do atributo sugere, o LOCAL_PREF somente é anunciado (repassado) entre os roteadores vizinhos BGP (iBGP) do mesmo AS e não é repassado aos roteadores vizinhos externos (eBGP). Caminhos (paths) que possuem o LOCAL_PREF com maior valor são preferidos pelo BGP. O valor padrão do LOCAL_PREF é 100.

ATOMIC_AGGREGATE Well-Known Discretionary Este atributo é usado por um roteador que, ao ter que selecionar uma rota dentre


outras recebidas de seu peer que se sobrepõem, escolhe uma, ignorando a mais específica. Então, ele deve incluir o atributo ATOMIC_AGGREGATE à rota quando for propagá-la a seus vizinhos (caso o atributo ainda não esteja presente na rota menos específica recebida).

Um roteador que receba uma rota com o atributo ATOMIC_AGGREGATE não deve removê-lo e não deve fazer nenhum NLRI da rota mais específica quando for propagar a rota aos vizinhos BGP. Ele precisa também reconhecer que o caminho atual para os destinos (como especificado no campo NLRI da rota), respeitando a ausência de loops de roteamento, pode cruzar ASs que não estejam listados no AS_PATH.

Outra observação importante: não é possível agregar um endereço sem ter uma rota mais específica daquele endereço na tabela de roteamento. Por exemplo: um roteador não pode gerar uma rota agregada para 196.0.0.0 sem possuir previamente uma rota de 196.10.0.0 em sua tabela de roteamento.

AGGREGATOR Optional Transitive Este atributo pode ser incluído em mensagens UPDATE que sejam formadas por agregação. O atributo AGGREGATOR contém o ASN do último roteador que formou uma rota agregada, seguido de seu próprio ASN e endereço IP.

COMMUNITY Optional Transitive Este atributo é usado para representar um agrupamento de destinos que compartilhem uma ou mais características que não estão restritas a um mesmo AS, rede ou conjunto de redes. As delimitações do agrupamento são em termos de Routing Policies (políticas de roteamento), podendo envolver mais de um AS, inclusive. As comunidades (Communities) podem ser compostas de diversas redes pertencentes a qualquer AS, usadas para simplificar políticas de roteamento através da identificação de rotas por algum parâmetro lógico ao invés de prefixos CIDR ou ASNs. Usando esses atributos, um roteador pode combiná-los com outros para determinar para cada comunidade as rotas a serem aceitas, descartadas, preferidas ou repassadas para outros vizinhos.

WEIGHT Definido pela Cisco Systems, o WEIGHT não é propriamente um atributo BGP. Ele influencia no processo de seleção da melhor rota do roteador onde for definido e, como é um atributo local ao roteador, não é repassado e nem propagado aos seus vizinhos nas mensagens UPDATE. O WEIGHT é um valor decimal entre 0 e 65535, sendo o valor padrão igual a 32768, assumido para rotas originadas pelo roteador. Outras rotas possuem o WEIGHT igual a 0 (zero), por padrão. Havendo mais de uma possível rota para um mesmo destino, o BGP-4 seleciona a que possuir o atributo WEIGHT com maior valor.

Este atributo é comumente usado pelos operadores de redes para influenciar o processo de escolha de rotas do BGP.


BGP NOTIFICATION Message Este tipo de mensagem é enviada no caso de detecção de erros durante ou após o estabelecimento de uma sessão BGP.

Cód. Descrição Sub-códigos de erro

1 Erro no cabeçalho da mensagem Sub-código Descrição

1 Conexão não sincronizada

2 Comprimento da mensagem inválido

3 Tipo de mensagem inválido

2 Erro na mensagem OPEN Sub-código Descrição

1 Número de versão não suportado

2 Número de AS vizinho inválido

3 Identificador BGP inválido

4 Parâmetro opcional não suportado

5 Falha na autenticação

6 Tempo de espera inaceitável

3 Erro na mensagem UPDATE Sub-código Descrição

1 Lista de atributos mal formada

2 Atributo Well-Known desconhecido


3 Atributo Well-Known faltando

4 Erro nas flags de atributos

5 Erro no comprimento do atributo

6 Atributo origem inválido

7 Loop de roteamento em AS

8 Atributo NEXT_HOP inválido

9 Erro no atributo Opcional

10 Campo de rede inválido

11 AS_path mal formado

KEEPALIVE Message São mensagens trocadas periodicamente com o propósito de verificar se a comunicação entre os vizinhos está ativa. A mensagem do tipo KEEPALIVE é composta apenas do cabeçalho padrão das mensagens BGP, sem dados transmitidos após o cabeçalho. O tempo máximo permitido para o recebimento de mensagens KEEPALIVE ou UPDATE é definido pelo hold time, como foi visto na descrição do tipo de mensagem OPEN.

BGP Light A Embratel oferece uma modalidade de BGP a seus clientes chamada de BGP Light.

Conforme especificado na RFC 1930, o bloco de ASNs entre 64512 e 65535 é reservado para uso privado e estes não devem ser anunciados para o restante da Internet. Dessa forma, é possível criar uma AS para um cliente, com os benefícios de administração, redundância dos links e distribuição de tráfego, sem a necessidade de arcar com altos custos de roteadores de grande porte capazes de manter a tabela inteira de BGP em sua memória.

Duas formas de roteamento são oferecidas:

• Full route: mantém todas as tabelas de rotas, o que exige muita memória do roteador. Logo, este terá que ser de maior porte


• Partial route: mantém as rotas nacionais, as rotas conectadas ao AS e as rotas default com redundância, permitindo o roteamento em caso de queda de um link pelo roteador remanescente.

Note que o cliente fica conectado a dois centros de roteamento diferentes, efetivamente garantindo a redundância do link.

Lógica para seleção de rotas BGP Com os conceitos básicos do BGP e, principalmente, com a compreensão dos atributos incluídos nas mensagens de atualização (UPDATE), mostraremos como o BGP escolhe a melhor rota entre dois pontos baseado nos PATH Attributes.


1.4. Protocolo EIGRP O protocolo Enhanced Interior Gateway Routing Protocol (EIGRP) é um protocolo de roteamento interno (IGP) desenvolvido pela Cisco Systems. Conceitualmente, o EIGRP é um protocolo do tipo Distance-Vector que possui algumas características comumente encontradas em protocolos do tipo Link-State, o que o torna um protocolo de roteamento bastante versátil.


O algoritmo de cálculo de melhor rota, DUAL (Diffusing Update Algorithm), permite uma rápida convergência quando ocorrem mudanças na topologia. Uma rede converge quando, após uma alteração de estado em um circuito, as tabelas de todos os roteadores que “conhecem” o circuito são atualizadas.

O EIGRP somente envia Updates (atualizações) quando há alterações na topologia da rede e apenas para os roteadores que precisam saber destas alterações (neighbors). Quando não existem alterações, somente mensagens de Hello são trocadas entre vizinhos . Por não enviar Updates periódicos para todos os roteadores, o uso da banda da rede é bastante otimizado.

O EIGRP suporta os principais protocolos rateáveis em uso atualmente – IP, IPX e Appletalk – tornando-o uma opção apropriada para redes heterogêneas.

Relações de Vizinhança Usando mensagens de Hello, o EIGRP estabelece e mantém relações de vizinhança (Neighboring Relationship), sendo elas responsáveis por determinar o estado da conexão entre os neighbors. Ao ser estabelecida a relação de vizinhança, as informações de roteamento podem ser trocadas entre os neighbors.

As mensagens de Hello são trocadas por default a cada 5 segundos em circuitos ponto a ponto como PPP, HDLC e Frame-Relay point-to-point. Este período é chamado de Hello Interval. O período de tempo que um roteador aguarda antes de considerar o neighbor fora de operação é chamado Hold-Time interval e o seu valor padrão é três vezes o Hello Interval, portanto, 15 segundos.


Cada instância EIGRP sendo executada cria e mantém uma tabela de neighbors, contendo informações como endereço IP e Hold-Time Interval referente a cada Neighbor.

O único momento em que o EIGRP anuncia as informações completas de roteamento é quando os neighbors iniciam a comunicação. A partir daí, somente as alterações são divulgadas.

O EIGRP baseia-se em três tabelas para seu processo de descoberta, cálculo e anúncio de rotas. São elas:

• Tabela de neighbors: Contém as informações de todos os vizinhos, tais como endereço IP e Hold-Time Interval.

• Tabela de topologia: Contém as informações conseguidas pelo próprio roteador, assim como as recebidas dos neighbors sobre todos os caminhos possíveis para um determinado destino.

• Tabela de rotas: Contém os caminhos de menor custo para os destinos aprendidos pelo próprio roteador ou via neighbors.

Cálculo da melhor rota O algoritmo DUAL usado para o cálculo de melhor rota tem como importantes características a possibilidade de uso de rotas secundárias ou stand-by, suporte a VLSM (Variable Length Subnet Mask) e envio de querie para os neighbors em busca de rotas para destinos que não possuem entradas na tabela de rotas do roteador local.

Sempre que uma mensagem de Update é recebida tratando de uma alteração na rota para um destino ou destinos existentes na tabela de rotas local ou anunciando uma nova rota para um novo destino, o processo de recálculo de rotas é iniciado.


Quando a nova informação chega, é criada uma nova entrada na tabela de topologia. Essa tabela pode armazenar até seis caminhos para o mesmo destino, o que significa que o EIGRP pode selecionar a melhor rota dentre até seis caminhos redundantes.

A seleção é feita com base no custo de cada caminho que, por sua vez, é o resultado de métricas que consideram fatores como banda passante (bandwidth), atraso (delay), confiabilidade (reliability) e taxa de uso do circuito (load).

• Bandwidth: A vazão ou banda passante de um circuito. O valor default é dado baseado no tipo de interface do roteador onde o circuito conecta-se, mas deve ser alterado manualmente pelo administrador da rede visando refletir corretamente a banda real contratada.

• Delay: O atraso na propagação do sinal dado fundamentalmente pelo tipo de meio de transmissão. Uma transmissão via satélite, por exemplo, terá um atraso maior do que uma transmissão via fibra ótica se tivermos como premissa que a distância percorrida seja a mesma.

• Reliability: A confiabilidade do circuito dada pela média de erros ou indisponibilidade do mesmo em um período de tempo (default é de 5 minutos nos roteadores Cisco).

• Load: A taxa média de utilização do circuito em um período de tempo (default é de 5 minutos).

A composição de alta banda, baixo atraso, alta confiabilidade e baixa carga é o que o EIGRP busca para escolher a rota com custo inferior. A rota de menor custo dentre as existentes na tabela de topologia é transferida para a tabela de rotas e designada como Ativa (Active Route). As rotas com custos superiores a ela são marcadas como Possíveis sucessoras (feasible sucessors) em caso de falha da rota Ativa.

Obs: Na prática, os roteadores Cisco somente consideram por default Bandwith e Delay para composição do custo, podendo-se configurar Reliability e Load manualmente caso haja interesse do administrador.

O processo de seleção de rotas A figura, a seguir, ilustra o processo de seleção de rotas.


Balanceamento de carga O EIGRP é capaz de balancear a carga entre circuitos de mesmo custo para um mesmo destino, distribuindo o tráfego igualitariamente entre os mesmos. Até aqui não há nenhuma grande vantagem em relação a outros protocolos de roteamento como OSPF, que podem também efetuar este tipo de balanceamento.

A grande diferença é a capacidade do EIGRP em balancear circuitos com custos diferentes. Isto é possível quando usamos o comando variance , que faz com que sejam incluídas como rotas ativas as feasible sucessors que tenham custo menor ou igual a menor custo computado * variance.

Exemplo: Temos 3 rotas para um mesmo destino. O menor custo é 20. Caso definamos uma variância de 2, teríamos as rotas com custo <= 40 incluídas no rol de rotas ativas. Com isso, a rota 2 também seria considerada ativa e colocada na tabela de rotas.

A inteligência do EIGRP faria a distribuição do tráfego na proporção de 2/1, ou seja, para cada pacote que passasse pela Rota 2, dois passariam pela rota 1.


1.5. Protocolo Is-Is O protocolo de roteamento Intermediate System-Intermediate System foi desenvolvido pela ISO (International Standards Organization) para prover roteamento em ambientes baseados nos protocolos especificados pelo OSI, órgão da ISO responsável pela definição dos protocolos de interconexão de sistemas abertos, isto é, não proprietários.

Intermediate System é o termo usado pela ISO para definir roteador. O IS-IS é, portanto, um protocolo usado para comunicação entre IS’s ou, usando o termo mais familiar para nós, entre roteadores. Utilizaremos os nomes IS e roteador para nos referirmos ao mesmo objeto de rede em nosso curso.


O IS-IS é um protocolo de roteamento que fornece as facilidades de roteamento dentro de um mesmo domínio. Podemos entender como domínio no mundo OSI/ISO o que chamamos de AS em nosso conhecido mundo TCP/IP. Portanto, o IS-IS é o equivalente a um IGP (Interior Gateway Protocol), que é o protocolo de roteamento executado dentro de um mesmo AS. Como exemplos, teríamos o OSPF e o EIGRP.

Similar a outros protocolos já vistos neste curso, tais como BGP e EIGRP, o IS-IS precisa estabelecer uma relação de vizinhança para que as informações de roteamento possam ser trocadas.

Tipos de IS O IS-IS usa uma estrutura hierárquica de 2 níveis em seu processo de roteamento: domínio e área, sendo que áreas são subdivisões lógicas dos domínios.

Com base nessa estrutura hierárquica, temos dois tipos de roteadores no ambiente IS-IS:

• Nível 1: Conhecem e trocam informações sobre a topologia interna de uma área com todos os outros IS’s da mesma área. Por outro lado, não têm qualquer conhecimento sobre os IS’s ou redes destino de outras áreas.

• Nível 2: Conhecem todas as outras áreas de um mesmo domínio mas não têm a visibilidade do que existe em termos de roteadores e redes dentro das áreas. Para que um roteador de nível 1 possa comunicar-se com outra área, ele deve enviar o pacote para um roteador de nível 2 localizado em sua área, que encaminhará o pacote para outra através de outro roteador de nível 2 localizado na área destino.


Tipos de pacotes São 3 os tipos de pacotes usados pelo IS-IS em seu processo de roteamento: Hello, Link State e Sequence Number.

• Hello Packets: São usados para iniciar e manter adjacências ou relações de vizinhança entre neighbors IS-IS. Temos 3 tipos de Hello: Nível 1, trocados entre IS’s de nível 1; nível 2 LAN, trocados entre IS’s de nível 2 em redes locais; e nível 2 ponto-a-ponto, que são usados em redes ponto-a-ponto não orientadas a broadcast.

• Link State Packets: Usados para troca de informação sobre o estado dos circuitos (Links). São 2 os tipos de LSPs: LSP nível 1, trocados entre os IS’s de nível 1 e LSP nível 2 trocados entre os IS’s de nível 2. Vale observar que os IS’s de nível 2 normalmente também consistem em IS’s de nível 1, já que conhecem seus pares e a topologia de dentro da sua própria área. Com isso, os IS’s de nível 2 também trocam LSPs de nível 1.

• Sequence Number Packets: Têm como função controlar o tráfego de LSPs, servindo como um pacote de ACK no sentido de controlar o recebimento de pacotes de LSP baseados no número de seqüência. Interação.

Processo de roteamento O processo de roteamento pode ser decomposto em 4 funções:

• Decision Process: Calcula as rotas para cada destino. Se o IS for de nível 2, há um processo separado para cada nível. Baseia-se na tabela de Link-State para o calculo da melhor rota.

• Update Process: Este processo monta, propaga e recebe as informações de Link-State. Este processo também é responsável pela manutenção da tabela de link-state.

• Forward Process: É responsável pelo processo de roteamento propriamente dito. Faz a busca na tabela de roteamento bem como aloca buffers de recepção e envio.

• Receive Process: Responsável pelo recebimento dos pacotes. Interage com outros processos como FP, caso o pacote recebido deva ser roteado.


2. Protocolo IP Avançado

2.1. Conceitos de Aplicações

QoS – Qualidade de Serviço A qualidade do serviço (Quality of Service - QoS) é a capacidade de uma rede em fornecer serviços com qualidade garantida baseando-se em métricas claramente definidas para tipos de tráfego específicos, ou seja, uma rede com suporte a QoS é capaz de reconhecer classes de tráfego e tratá-las diferentemente.

As redes de hoje necessitam suportar múltiplos tipos de tráfego sobre os mesmos circuitos. Os tipos diferentes do tráfego exigem tratamentos diferentes da rede. Assim como um passageiro da primeira classe está disposto a pagar mais pelo melhor serviço, as empresas hoje estão dispostas a pagar um adicional pelo tratamento preferencial de seu tráfego de rede. E da mesma forma que não podemos ter um avião separado para cada passageiro da primeira classe, nós não podemos ter conexões de redes separadas para cada uma das empresas. Conseqüentemente, o tráfego de "primeira classe" e o de outras classes têm que compartilhar a mesma largura de banda disponível (como passageiros da classe econômica compartilham o avião com os passageiros da primeira classe).


A diferenciação do tráfego somente pode ser feita nos elementos ativos da rede. Exemplos de tais elementos são roteadores e switches.

Para definir a qualidade de serviço é preciso conhecer as métricas que, em última instância, são os parâmetros que definem o QoS de uma determinada rede. As principais métricas são:

• Service Availability (Disponibilidade do serviço) Confiabilidade das conexões fim-a-fim.

• Delay (Atraso) Tempo que um pacote leva para percorrer a rede do ponto de origem ao ponto de destino.

• Delay Jitter (Atraso irregular) Variação no atraso encontrado pelos pacotes similares que seguem a mesma rota através da rede. Há casos como o de tráfego de voz sobre IP, onde um atraso constante não ocasiona problemas na conversação, porém, caso tenhamos um atraso irregular, as sílabas soarão "emboladas" no destino. Nesse caso, o controle dessa característica da rede é fundamental em termos de QoS para o tráfego de voz.

• Throughput (vazão) Taxa de transmissão dos pacotes através da rede.

• Packet Loss Rate (Taxa de perda de pacotes) Taxa que representa o número de pacotes recusados, perdidos ou corrompidos em relação ao total de pacotes enviados na rede.

Componentes de QoS Diversos componentes são necessários de forma a se atingir uma QoS efetiva. Observe a imagem a seguir:


Da mesma forma que protocolos de rede e equipamentos especificamente projetados são necessários para garantir uma determinada QoS no backbone da Embratel, o mesmo deve acontecer com a rede do cliente.

Um conjunto específico de equipamentos e protocolos (CPE - Customer Premise Equipment, ou equipamento nas instalações do cliente) é exigido para garantir o QoS:

• Roteador com FRF-12 Permite fragmentação em interleaving, colocando os pacotes de dados entre os de áudio e vídeo. O FRF-12 foi desenvolvido de modo a permitir que frames de dados muito longos sejam fragmentados em pedaços menores e intercalados (interleaving) com frames pertencentes a transmissões em tempo real. Desta forma, frames de voz e vídeo, sensíveis ao tempo, e de dados, não sensíveis ao tempo, podem ser transmitidos simultaneamente em links de menor velocidade sem causar atrasos excessivos ao tráfego em tempo real. Veja mais em http://www.frforum.com.

• Filas CBWFQ e LLQ, proprietárias da Cisco CBWFQ (Class-based weighted fair queueing) é uma extensão da funcionalidade WFQ (weighted fair queueing) padrão que permite a definição de classes de tráfego pelo usuário. É possível utilizar diversos critérios na definição dessas classes, incluindo protocolos, listas de controle de acesso (ACLs) e interfaces de entrada. LLQ (Low latency queueing) permite que o CBWFQ seja realizado com base em prioridades estrita

• Marcação de pacotes com IP Precedence ou DSPC

• Utilização de CRTP O CRTP (Compressed RTP), proprietário da Cisco, comprime o cabeçalho IP/UDP/RTP de 40 bytes para entre 2 e 4 bytes, na maioria das vezes. Isso é conseguido aproveitando o fato que metade das informações de um cabeçalho normalmente não muda ao longo da transmissão e que, mesmo a parte que muda, o faz de maneira determinística e não precisa ser transmitida. CRTP deve ser utilizado em qualquer interface WAN onde exista uma preocupação com largura de banda e alto tráfego de RTP.


Atenção: A fragmentação em interleaving e o uso de CRTP são primordiais para a implantação de QoS em links de baixa velocidade.

CoS – Classe de Serviço A classe de serviço (Class of Service - CoS) é uma maneira de controlar o tráfego em uma rede agrupando os tipos de tráfego similares, como email, streaming de vídeo, tráfego de voz e transferência de arquivo, e tratando cada tipo como uma classe com seu próprio nível da prioridade do serviço. Ao contrário da qualidade de serviço (QoS), a CoS não garante um nível de qualidade em termos das métricas analisadas no item QoS; somente oferecem um nível de serviço na base do "melhor-esforço" (best-effort), onde o tráfego concorrente será tratado de acordo com níveis de prioridade.

As garantias dadas por mecanismos de CoS são bastante limitadas. O CoS somente garante que os pacotes com prioridade mais elevada tenham um melhor serviço do que pacotes com prioridade mais baixa. Não há controle da admissão do pacote de entrada, portanto não há nenhum mecanismo para impedir que as classes fiquem sobrecarregadas. Conseqüentemente, a qualidade do serviço não é previsível, mas depende da quantidade de tráfego competindo pelos mesmos recursos. É possível haver congestionamento dentro das classes, o que pode levar a delay jitter e perda do pacote.

As classes de QoS são completamente isoladas. Tráfego de dados e tráfego real-time, por exemplo, podem ser totalmente separados. Com isso, o tráfego de dados não causaria delay jitter às aplicações real-time e, da mesma forma, ele não é prejudicado por uma quantidade excessiva de tráfego real-time.

Por outro lado, com o CoS, recursos de processamento e memória não são gastos em tarefas como gerenciamento do fluxo, scheduling do tráfego e ordenação como é feito no QoS. Assim, os recursos exigidos aos roteadores para oferecer o CoS são inferiores aos requeridos pelo QoS.


DiffServ X IntServ Há dois mecanismos principais de QoS em redes IP: Integrated Services (IntServ) e Differenciated Services (DiffServ).

• IntServ É um mecanismo baseado em reserva antecipada de recursos. Isto significa que o IntServ reserva recursos para cada fluxo usando um protocolo dinâmico para este fim e emprega o controle de admissão, a classificação dos pacotes e scheduling para conseguir o QoS desejado.

• DiffServ É um mecanismo que não trabalha com a reserva de recursos antecipada. Isto significa que o DiffServ classifica os pacotes em um número reduzido de tipos de serviço e usa prioridades para fornecer QoS ao tráfego. Nenhuma reserva de recursos ou controle de admissão explícitos são utilizados, embora tenhamos que, de alguma forma, implementar um método para diferenciar o tráfego.

Integrated Services IntServ é um mecanismo de QoS orientado a fluxo. Um fluxo é definido como uma seqüência de pacotes originados a partir de uma atividade específica do usuário, como, por exemplo, uma sessão transferência de arquivo. Um fluxo pode ser identificado por uma variedade de informações encontradas nos pacotes, como os endereços IP origem, IP de destino e o número da porta TCP destino.

O IntServ requer que os recursos sejam reservados para cada fluxo, a fim de prover o QoS solicitado. Isto pode ser feito através de um protocolo dinâmico de reserva de recursos (Dynamic Reservation Protocol) ou de configuração manual. Ainda que o IntServ não esteja amarrado a


nenhum método específico, o RSVP (Resource reSerVation Protocol) é o protocolo dinâmico de reserva de recursos comumente empregado.

Existem quatro funcionalidades básicas na implementação do IntServ, conforme descrito abaixo:

• Packet Scheduler O scheduler de pacotes, como o nome sugere, programa a transmissão dos pacotes colocando-os nas filas de trasmissão adequadas para transmiti-los no momento apropriado.

• Admission Control O controle da admissão decide se um roteador ou host concedem a um novo fluxo o QoS solicitado, sem causar impacto nas garantias fornecidas a fluxos anteriores. A decisão de aceitar ou rejeitar um pedido de reserva é feita com base no QoS pedido e no QoS disponível no link de saída.

• Classifier O classifier relaciona cada pacote de entrada a uma classe de serviço específica, a fim de ser apropriadamente transmitido pelo scheduler. Os pacotes são classificados baseando-se em determinadas informações contidas no cabeçalho do pacote. Todos os pacotes que pertencem à mesma classe são tratados similarmente. Há diversos critérios para classificação, como, por exemplo, considerar todos os fluxos de vídeo como pertencendo à mesma classe de serviço.

• Resource reSerVation Protocol O Resource reSerVation Protocol (RSVP) é responsável pela distribuição das informações específicas de cada fluxo por todos os roteadores ao longo do caminho entre origem e destino, além dos hosts localizados nas duas extremidades da comunicação. A aplicação especifica o QoS requerido e o RSVP utiliza esta informação para reservar os recursos ao longo de todo o caminho. O protocolo RSVP é abordado com mais detalhes na porta Protocolos associados deste andar.


Funcionamento do IntServ

Limitações do IntServ O maior problema com relação ao uso do IntServ é quanto à sua escalabilidade. Em uma rede de grande porte, a quantidade de mensagens de controle necessárias à solicitação de reserva para um grande número de fluxos certamente exigirá um alto volume de processamento por parte dos dispositivos de rede.

Da mesma forma, a manutenção de tabelas de estado dos fluxos em cada nó da rede demandaria uma grande necessidade de memória. Além disso, a classificação e programação (scheduling) do tráfego tornaria o processo de roteamento em cada dispositivo bastante complexo. A questão da segurança também é uma preocupação, já que o IntServ carece de um mecanismo que evite o pedido de alocação de recursos por fontes não autorizadas.

Os Differenciated Services, em função de suas características e funcionamento, conseguem solucionar algumas das deficiências do IntServ, tornando-o mais apropriado a redes de maior porte.

Differenciated Services Os Differenciated Services (DiffServ - DS) utilizam o conceito de domínios para modelar sua estrutura de QoS. Um domínio de DiffServ é um conjunto contínuo de nós de rede que suportam um mesmo método de provisionamento de recursos e políticas de QoS. O domínio tem uma fronteira bem definida e há dois tipos de nós associados com um domínio do DS: border nodes (nós de borda) e interior nodes (nós internos).


Os border nodes conectam um domínio DS a outros domínios. Eles classificam o tráfego de modo que os pacotes de entrada sejam marcados apropriadamente para que recebam o tratamento adequado dentro do domínio. Os interior nodes são conectados a outros interior nodes ou a border nodes dentro do mesmo domínio.

Algumas definições merecem serem apresentadas, visando a melhor compreensão do mecanismo de QoS do DiffServ:

• DiffServ CodePoint (DSCP) O Diffserv utiliza um campo que sempre existiu no cabeçalho IP mas que até o advento das tecnologias de QoS, na prática, não era utilizado. Estamos falando do campo ToS (Type of Service), que é composto por 8 bits, sendo que somente 6 são usados para definir o DSCP. Na terminologia do DiffServ, ele é chamado de DS-Field e o código especificado neste campo (DSCP) indica qual o tipo de tratamento que o pacote receberá dos roteadores de um domínio DS.

• DS Behavior Aggregate (DSBA) Um conjunto de pacotes com o mesmo DS Codepoint e que, portanto, devem receber o mesmo tratamento de QoS pelos DS-Routers.

• Per Hop Behavior (PHB) Consiste no tratamento que é dado em cada DS-Router a cada DS Behavior Aggregate com relação a como serão repassados os pacotes, a fim de manter a QoS requerida.

• PHB group Um conjunto de PHBs com características comuns que recebem o mesmo tratamento no DS-Router.


Funcionamento do DiffServ O pacote entra no domínio DS através de um border node, responsável pela classificação e condicionamento do mesmo. Classificar consiste em identificar o tráfego que irá receber um serviço diferenciado baseando-se no DS Codepoint e associá-lo a um DS Behavior Aggregate. Condicionar significa aplicar ao tráfego regras pré-acordadas e pré-definidas, como limites máximos de vazão e condições que levam ao descarte de pacotes.

Com base no DS Codepoint, em cada interior node um determinado DS Behavior Aggregate é mapeado para um PHB que define o tipo de serviço que será fornecido ao DS Behavior Aggregate.

Os PHBs podem ser definidos em função da prioridade de uso de recursos (como buffers e largura de banda) em relação a outros PHBs ou nos termos das características de tráfego requeridas, como atraso máximo e perda de pacotes suportada para um determinado DSBA. Em síntese, os PHBs são as bases para alocação de recursos no mecanismo de DiffServ.


Comparativo das duas soluções Terminamos o módulo que trata do IntServ mostrando as limitações deste mecanismo de QoS e apresentaremos agora algumas das características do DiffServ que superam tais limitações.

O DiffServ não diferencia o tráfego por fluxo como é o caso do IntServ. Ao invés disso, há um número pequeno de classes para as quais são oferecidos serviços diferenciados e essas classes, na verdade, são agregações de diversos fluxos que solicitam o mesmo tipo de QoS.

No DiffServ não há classificação de pacotes nos interior nodes da rede. Já no IntServ/RSVP, cada router interno executa a classificação do pacote, a fim fornecer diferentes níveis de serviço. No DiffServ, a classificação do pacote é movida para a borda da rede, isto é, os border nodes classificam e marcam pacotes apropriadamente e os interior nodes processam os pacotes baseados nessas marcas.

Outra diferença importante entre as duas soluções é o fato de que o IntServ/RSVP explicitamente reserva, de forma antecipada, os recursos ao longo do trajeto, enquanto o DiffServ não fornece garantias prévias. O objetivo em DiffServ é monitorar o tráfego que entra na rede pelo border node e verificar sua adequação a perfis de serviços pré-definidos com base em acordos de nível de serviço (SLAs). Baseado nos SLAs, os pacotes podem ser marcados como estando dentro (IN) ou fora (OUT) de seus perfis. Dentro da rede, os interior nodes descartam preferencialmente os pacotes que são marcados como OUT.

Como o DiffServ move a classificação dos pacotes para a borda da rede, não trata fluxos individuais e não possui controles para reserva antecipada de recursos, esta solução é mais escalável que a IntServ, pois reduz o custo para o controle do QoS como banda passante no interior da rede, memória e processamento nos interior nodes.


Unicast x Multicast A transmissão de áudio e vídeo através do método convencional de comunicação direta ponto-a-ponto, ou Unicast, sobrecarrega tanto os servidores transmissores quanto as redes por onde passam estas aplicações. Para solucionar este tipo de problema, veremos que a trasmissão multiponto, ou Multicast, é a opção mais apropriada.

Unicast

O IP Unicast é o método comumente usado nas típicas comunicações cliente/servidor. Neste contexto, cada conexão usa uma parte exclusiva da banda total disponível. Isto significa que se um servidor de streaming de áudio/vídeo como o Windows Media Server, por exemplo, transmitisse em Unicast para 100 clientes, 100 cópias dos mesmos dados seriam enviadas na rede.

Devido à relação linear entre o número de conexões e a quantidade de banda consumida e de consumo de CPU e memória dos hosts e roteadores envolvidos, o Unicast não é a melhor opção para transmissões para vários hosts simultâneos tendo em vista a falta de escalabilidade.

O IP Unicast, portanto, é uma tecnologia que trabalha muito bem em comunicação ponto-a-ponto, mas não em comunicação ponto-a-multiponto. Para esse tipo de comunicação, a transmissão em Multicast é a forma que melhor se adequa às características deste tráfego, como veremos a seguir.

MultiCast

O princípio fundamental que permite o IP Multicast é o tratamento eficiente de comunicações entre grupos de hosts em uma rede IP. Esta tecnologia permite o envio de uma única mensagem (data stream) na rede e que vários hosts recebam a mesma mensagem.

Neste método, uma banda adicional não precisa ser alocada para cada nova conexão. Ao invés disso, cada novo usuário conecta-se ao único fluxo de dados transmitido. Conseqüentemente, há


um uso muito mais eficiente da largura de banda da rede quando se trata de comunicação entre grupos de host. Com isso, um grupo de usuários assistindo a uma transmissão de vídeo via Internet, por exemplo, consumiria somente a banda equivalente à alocada a um único usuário em um ambiente Unicast.

Quando falamos em IP Multicast, estamos falando de um conjunto estável e já maduro de protocolos que, contudo, não tinham sido usados em todo seu potencial até a recente popularização das tecnologias de banda larga para acesso à Internet. A utilização do Multicast exige um novo conjunto de protocolos nas redes unicast existentes, como teremos a oportunidade de apresentar ao longo deste módulo.

Quando IP Multicast necessita transpassar diferentes segmentos de rede via roteadores, três requisitos precisam ser atendidos:

• Grupo de destinatários: A camada de rede deve conter um endereço que represente um grupo de destinatários, ao invés de apenas um receptor. Isto é realizado usando a faixa de endereçamento IP de classe D, e não endereços da classe A, B ou C.

• Método de adesão: Deve haver um método para que os computadores dos clientes associem-se ao grupo que recebe os pacotes de IP Multicast. Isto é realizado usando-se protocolos como o IGMP, que gerenciam os grupos Multicast.

• Infra-estrutura de rede: A infra-estrutura da rede deve ter uma maneira de comunicar as decisões de roteamento multicast. Alguns exemplos de protocolo de roteamento multicast são o Distance Vector Multicast Routing Protocol e PIM (Protocol Independent Multicast).

Endereçamento IP Multicast Diferentemente da comunicação Unicast, onde cada endereço IP identifica um único host, no Multicast um endereço IP representa um grupo ao qual os hosts podem associar-se para receber pacotes referentes a uma mesma transmissão.


A faixa de endereços IP de classe D utilizada no Multicast compreende os valores iniciados em 224.0.0.0 até 239.255.255.255. Da mesma forma que os endereços Unicast, há endereços que podem ser atribuídos às aplicações Multicast e os que são reservados. Vejamos alguns exemplos de endereços Multicast e seu uso:

Os endereços da faixa de 224.0.0.0 até 224.0.0.255 são do tipo locais, isto é, não são roteados pelos roteadores Multicast e, portanto, restritos ao uso dentro de uma mesma subrede IP. Os endereços da faixa 224.0.1.0 à 224.0.1.255 são roteáveis e portanto podem passar através dos roteadores.

A faixa de endereços dita como endereços privativos (239.0.0.0 a 239.255.255.255) tem a função semelhante à dos endereços privativos das classes A, B e C (10.0.0.0, 172.16.0.0 a 172.31.0.0 e 192.168.0.0), ou seja, são endereços inválidos e controlados pelo IANA, mas que podem ser utilizados dentro da empresa para aplicações restritas.

Gerenciamento de Grupos de IP Multicast O controle da comunicação através dos grupos Multicast funciona de forma similar a um clube. Quando uma estação quer receber os pacotes Multicast de uma determinada aplicação, é preciso associar-se ao grupo para que a informação seja passada pelos roteadores Multicast para a estação de trabalho. Da mesma forma, quando não se quer mais receber as informações originadas a partir de uma aplicação Multicast, é preciso informar o desejo de retirar-se do grupo.

O principal protocolo responsável pelo gerenciamento dos grupos Multicast é o IGMP (Internet Group Management Protocol), atualmente em sua versão 2. Com a mesma funcionalidade, temos também o protocolo proprietário da Cisco CGMP (Cisco Group Management Protocol).

Vejamos como são os principais processos envolvidos no gerenciamento dos grupos Multicast:

• Query Process - Os roteadores Multicast passam o tráfego Multicast destinado a grupos somente para os segmentos de rede diretamente conectados a ele e que tenham, pelo menos, um host nesses grupos. Para saber que hosts estão associados a que grupos em um determinado segmento, os roteadores enviam uma query (pergunta) para todos os hosts do segmento por meio do endereço 224.0.0.1. Os hosts que pertençam a grupos Multicast reportam ao roteador suas informações. Desde que haja, pelo menos, um host em um determinado grupo, o roteador enviará o tráfego referente a esse grupo para o segmento em questão.


• Joining Process - Quando um host deseja associar-se a um grupo Multicast para

receber o tráfego da aplicação que transmite para este grupo, ele envia uma solicitação ao roteador pedindo para que o tráfego seja passado para o segmento de rede IP onde se encontra.

• Leaving Process - Para solicitar a sua remoção de um grupo Multicast, um host

envia uma mensagem a todos os roteadores de seu segmento (endereço 224.0.0.2) pedindo o desligamento do grupo. Neste momento, os roteadores enviam uma query para o grupo do host que quer se desligar para saber se ainda há algum host remanescente do mesmo grupo. Em caso afirmativo, o tráfego para este grupo continua sendo repassado para o segmento, caso contrário, não serão enviados pacotes, para o segmento de rede, referentes ao grupo em questão.


Virtual Private Network (VPN) A maneira pela qual as empresas fazem seus negócios tem mudado muito nos últimos anos. Em vez de simplesmente tratarem dos interesses locais ou regionais, as empresas agora têm que pensar nos mercados e logística globais. As empresas globalizadas têm com freqüência suas linhas de produção em unidades de negócios espalhadas por todo o mundo, além da mobilidade cada vez maior de suas equipes de vendas e suporte técnico. Existe, portanto, uma necessidade comum a este tipo de organização: uma maneira de viabilizar as comunicações da forma mais segura e de menor custo possível entre suas unidades distribuídas geograficamente pelo mundo.

Até recentemente, as possibilidades existentes para efetuar este tipo de conexão eram o uso de linhas dedicadas ou contratação de serviços de redes comutadas, como Frame-Relay e X.25, de operadoras internacionais. Hoje, podemos utilizar com segurança uma rede pública que oferece maior capilaridade e menor custo entre todas as outras soluções. Esta rede é a Internet e a tecnologia que viabiliza esta solução com segurança é a rede privativa virtual (Virtual Private Network - VPN).

Certamente, as soluções tradicionais ainda oferecem vantagens sobre uma rede pública, como a Internet, quanto à confiabilidade e ao desempenho; porém, essas vantagens tendem a diminuir com as novas tecnologias de QoS. Por outro lado, manter uma estrutura baseada em circuitos dedicados de longa distância é muito caro, e os custos aumentam em função da distância entre os pontos conectados.

Conceitualmente, uma VPN é uma rede privativa que utiliza uma rede pública (geralmente a Internet) para conectar localidades e usuários remotos a redes privadas. Em vez de usar um circuito dedicado, uma VPN utiliza conexões virtuais através da Internet, ligando a rede privada da empresa à uma localidade remota.


Típicas ligações que usam VPN

Tipos de VPN

Acesso Remoto

Também chamada de client-to-LAN, este tipo de conexão VPN é utilizada para ligar as estações de trabalho, tipicamente laptops ou PDAs de funcionários que necessitam se conectar à rede da empresa quando estão em localidades remotas, como hotéis e clientes.

Neste caso, é comum a empresa terceirizar o acesso à Internet junto à uma provedora de acesso que ofereça números locais em diversas das principais cidades do país ou do mundo, além de números 0800 para as cidades onde números de acesso locais não estejam disponíveis.

Após a conexão discada ter sido estabelecida, o funcionário usa um cliente VPN instalado em sua estação para estabelecer a conexão com o servidor VPN localizado na sua empresa e passa então a ter acesso seguro aos recursos da rede corporativa.

Consultores, equipes de venda e equipes de suporte são usuários típicos deste tipo de VPN.

Site-to-Site

Também conhecida como LAN-to-LAN, este tipo de VPN é feita por meio da conexão dedicada de escritórios remotos à Internet. São comumente utilizados dispositivos especializados na manutenção do circuito dedicado (roteadores), além dos dispositivos com o fim específico de tratar os processos inerentes à conexão VPN (firewalls), como autenticação e criptografia.

Neste mecanismo, após autenticação, os firewalls de ambos os lados combinam o método de criptografia a utilizar, trocam as chaves criptográficas necessárias e estabelecem a comunicação


segura. Além disso, é também normalmente responsabilidade dos firewalls iniciar e encerrar o encapsulamento dos dados.

Ligações entre matriz e filiais e entre a empresa com seus fornecedores são os usos mais comuns deste modo de conexão VPN.

VPN e Criptografia Este mecanismo envolve normalmente dois métodos de criptografia:

• Criptografia de chaves simétricas Envolve o conhecimento de uma única chave, por ambos os lados, capaz de criptografar e descriptografar a informação transmitida. É o método escolhido quando a performance é o requisito fundamental.

• Criptografia de chaves públicas Método onde as duas partes possuem duas chaves: uma privada de conhecimento exclusivo do '"dono" da chave e uma pública que, como o nome sugere, é de conhecimento de todos. Estas duas chaves têm a seguinte propriedade: o que é criptografado com uma delas somente será descriptografado pela outra, isto é, o que é criptografado com a chave privada somente pode ser descriptografado com a chave pública e vice-versa.

Os dois métodos de criptografia são utilizados no processo de estabelecimento e troca de informações da conexão VPN segura ,da forma descrita a seguir:

- O lado transmissor usa a chave pública do receptor para enviar a chave simétrica que servirá para criptografar os dados a serem enviados;

- Como somente a chave privada do receptor consegue "abrir" a mensagem criptografada com sua chave pública, a troca de chaves é feita com segurança e o receptor fica ciente da chave para criptografar os dados;

- O transmissor passa a enviar os dados criptografados com a chave simétrica acordada;

- O receptor decodifica as mensagens recebidas com a chave simétrica recebida.

Note que em virtude de sua melhor performance, graças ao menor consumo de recursos em relação aos algoritmos de chave pública, os algoritmos de chave simétricas são preferenciais para o processo de criptografia dos dados.

VPN e encapsulamento As VPNs baseiam-se em encapsulamento de pacotes (tunneling) para criar uma rede privada através da Internet. Essencialmente, tunneling é o processo de colocar um pacote inteiro (headers e dados) dentro de um outro pacote e transmiti-lo na rede pública que liga as duas redes privadas. O protocolo do pacote "externo" é compreendido pela rede pública e por ambos os pontos que abrem e fecham a VPN, também designados de interfaces de tunelamento, onde o pacote é inserido e retirado da rede pública. Existem três tipos de protocolos que compõem o mecanismo de encapsulamento:


• Protocolo externo: O protocolo usado pela rede pública que conecta as interfaces de tunelamento. No caso da Internet seria o próprio IP.

• Protocolo de encapsulamento: O protocolo utilizado para encapsular o pacote original. Alguns exemplos são o GRE, IPSec, L2F, PPTP, L2TP, que serão vistos com mais detalhes mais à frente, neste curso.

• Protocolo original dos dados: Os protocolos utilizados dentro da empresa que podem ser o próprio IP, IPX ou mesmo protocolos não roteáveis como NetBEUI.

Pelo encapsulamento, é possível, por exemplo, colocar um pacote que use um protocolo não suportado na Internet (como NetBEUI) dentro de um pacote IP e enviá-lo pela Internet. Poderíamos também usar a faixa de endereços privativos (10.x.x.x, por exemplo) nas redes privadas conectadas via Internet e colocar este pacote dentro de outro pacote cujos endereços IP sejam válidos para transmissão via Internet.

2.2. Protocolos associados

Protocolo ICMP Em uma rede de pacotes não orientada à conexão, como a Internet, diversos problemas podem ocorrer durante a transmissão de uma mensagem. Um exemplo bastante comum ocorre quando o host destino não está disponível (unreachable) para receber a mensagem. Outro exemplo seria quando um roteador está com algum tipo de problema e não tem como reencaminhar o tráfego. Em ambos os casos, uma mensagem de erro deve ser retornada ao host origem para que alguma ação seja tomada.


No modelo Internet, o protocolo ICMP (Internet Control Message Protocol) tem como principal função reportar à origem problemas na transmissão de uma mensagem envolvendo os roteadores que reencaminham o datagrama e o host destino. O ICMP reside na camada de rede, juntamente com o protocolo IP. Mensagens ICMP são encapsuladas em datagramas IP e enviadas da mesma forma que os demais pacotes. Em função disso, mensagens ICMP podem ter os mesmos problemas em alcançar o seu destino.

Formato de mensagem ICMP O protocolo ICMP reporta diferentes tipos de problemas, implementando diversos tipos de mensagens. No entanto, todas apresentam três campos:

Type Especifica o tipo da mensagem ICMP.

Checksum Utilizado para garantir a integridade da mensagem IGMP.

Code Permite especificar informações adicionais sobre a mensagem ICMP.

A seguir são listados os principais tipos e uma breve explicação de algumas funcionalidades e problemas que podem se reportados:


Tipo Descrição

0 Echo Reply

3 Destination Unreachable

4 Source Quench

5 Redirect

8 Echo Request

11 Time Exceeded on a Datagram

12 Parameter Problem on a Datagram

13 Timestamp Request

14 Timestamp Reply

17 Address Mask Request

18 Address Mask Reply

Mensagens ICPM As mensagens do tipo echo request e echo reply permitem testar uma conexão de rede, e são utilizadas, por exemplo, no comando ping. O comando ping envia uma ou mais mensagens do tipo echo request para um determinado host. O destino, por sua vez, responde utilizando uma mensagem do tipo echo reply. Desta forma, é possível identificar problemas na rede.

C:\>ping www.embratel.com.br

Pinging www.embratel.net.br [200.255.125.213] with 32 bytes of data:

Reply from 200.255.125.213: bytes=32 time=130ms TTL=243 Reply from 200.255.125.213: bytes=32 time=50ms TTL=243 Reply from 200.255.125.213: bytes=32 time=91ms TTL=243 Reply from 200.255.125.213: bytes=32 time=40ms TTL=243

Ping statistics for 200.255.125.213: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 40ms, Maximum = 130ms, Average = 77ms


A mensagem destination unreachable indica que o roteador não pôde reencaminhar o datagrama ou não pôde entregá-lo ao destino. Existem diversas razões para que um host esteja indisponível.

Código Descrição

0 Network unreachable

1 Host unreachable

2 Protocol unreachable

3 Port unreachable

4 Fragmentation needed and DF set

5 Source route failed

6 Destination network unknown

7 Destination host unknown

8 Source host isolated

9 Communication with destination network prohibited

10 Communication with destination host prohibited

11 Network unreachable for type of service

12 Host unreachable for type of service

A mensagem time exceeded indica que o tempo de vida (Time-To-Live) do datagrama está esgotado e deve ser descartado da rede pelo roteador.

A mensagem source quench permite implementar uma forma simples de controle de fluxo, onde o destino pode solicitar à origem que reduza a sua taxa de transmissão, conseqüentemente evitando ou reduzindo problemas de congestionamento e buffer overflow.

As mensagens timestamp request e timestamp reply permitem que um host solicite a hora do dia a uma determinada máquina na rede. A partir destas mensagens é possível avaliar o atraso no envio/recebimento de datagramas na rede.


IGMP No endereçamento ponto-a-ponto, também conhecido como unicast, uma mensagem é endereçada para um único host destino. Se for necessário enviar uma mesma mensagem para diversos hosts, serão enviadas tantas mensagens quanto for o número de hosts. Nesse caso, o host origem deverá enviar várias mensagens idênticas, consumindo seus recursos computacionais. Além disso, a rede de interconexão deverá transportar as mesmas mensagens para os diversos hosts destino, consumindo banda da rede.

O endereçamento multicast ou IP multicast permite que uma mesma mensagem seja enviada uma única vez e diversos hosts possam recebê-la. Um bom exemplo de aplicação que se beneficia com o endereçamento multicast pode ser observado em uma vídeo-conferência, onde vários participantes devem receber as mesmas imagens. Em um ambiente unicast, para cada participante da vídeo-conferência deve ser enviada a mesma mensagem.

A comunicação multicast é implementada através de grupos multicast. Um grupo multicast é formado por hosts que possuem o mesmo endereço multicast. Os endereços multicast são formados pelos endereços classe D, que estão no intervalo de 224.0.0.0 a 239.255.255.255. Cada grupo possui um único endereço multicast.

Para receber as mensagens de um determinado grupo multicast, um host deve solicitar sua inclusão no grupo. Da mesma forma, quando um host não deseja mais receber tais mensagens, ele deve solicitar sua saída do grupo. Para que um host envie mensagens multicast não é necessário que ele faça parte de nenhum grupo multicast.

Formato da mensagem IGMP O protocolo IGMP (Internet Group Management Protocol) faz parte da camada de rede do modelo Internet, juntamente com o protocolo IP. Mensagens IGMP são encapsuladas em datagramas IP e enviadas da mesma forma que os demais pacotes. Em função disso, mensagens


IGMP podem não alcançar seu destino. Na nova versão do protocolo IP (IPv6), o IGMP foi incorporado ao ICMP, ou seja, o ICMPv6 inclui as funções dos protocolos ICMPv4 e IGMPv4.

A função do protocolo IGMP é permitir a troca de informações multicast entre hosts e roteadores multicast, responsáveis por implementar a comunicação multicasting. Por exemplo, sempre que um host deseja tornar-se membro de um grupo multicast, ele deverá enviar uma mensagem IGMP especificando o endereço multicast do grupo desejado. O protocolo permite que os roteadores multicast identifiquem quais grupos continuam ativos, enviando periodicamente uma mensagem IGMP para todos os hosts de um determinado grupo. Os hosts que desejarem permanecer no grupo devem responder, utilizando uma mensagem IGMP.

Uma mensagem IGMP possui os seguintes campos:

Version: versão do produto.

Type: Especifica o tipo da mensagem IGMP.

Tipo 0: Identifica uma resposta enviada por um host.

Tipo 1: Identifica uma solicitação enviada por um roterador multicast.

Checksum: Utilizado para garantir a integridade da mensagem IGMP.

Group Address: Identifica o endereço de um grupo multicast (classe D).

Protocolo RSVP O protocolo RSVP (Resource reSerVation Protocol) tem a função de garantir a QoS (Quality of Service) em redes do tipo Integrated Services (IntServ), como a Internet, implementando o esquema de pré-alocação de recursos para um determinado fluxo de dados (data flow) unicast ou multicast.

Antes de estabelecer uma conexão, a aplicação especifica os parâmetros necessários para garantir a QoS desejada. Os roteadores responsáveis pelo encaminhamento das mensagens verificam a possibilidade de oferecer essa QoS. Se for possível, os recursos necessários são reservados e a conexão pode ser estabelecida. Caso contrário, informa-se à aplicação que a QoS desejada não pode ser atendida. Nesse caso, a aplicação pode baixar seu nível de exigência ou decidir tentar uma nova conexão posteriormente.


O RSVP não é um protocolo de roteamento, apesar de estar na camada de rede do modelo Internet. O RSVP trabalha juntamente com os protocolos de roteamento, como OSPF, de forma a permitir que os requisitos de QoS sejam mantidos dinamicamente, embora haja possíveis mudanças de tráfego e rotas. Isto é possível devido ao conceito de soft state, que é o conjunto de informações de estado mantido nos roteadores e atualizado periodicamente pelo RSVP para garantir a QoS. Esta é uma grande diferença em relação aos protocolos ATM e Frame Relay, que oferecem serviços orientados à conexão com base no conceito de hard state.

De forma simplificada, o RSVP estabelece o caminho dos dados entre origem/destino (data path) e a pré-alocação de recursos em duas etapas. Inicialmente, o transmissor informa, através de uma mensagem (PATH), o tipo de dado que será enviado (data flow). Essa mensagem percorrerá todo o caminho até o host destino (downstream), passando a ser conhecida por todos os dispositivos que fazem parte do data path. O host destino, depois de receber a mensagem PATH, solicita a reserva dos recursos necessários através de uma outra mensagem (RESV). A mensagem RESV irá percorrer o mesmo caminho que a mensagem PATH, mas no sentido contrário (upstream). Após esse processo, o soft state criado em cada dispositivo no data path deve ser mantido por mensagens periódicas PATH e RESV.

A seguir, são apresentadas as principais características do protocolo RSVP:

- Pode ser utilizado tanto para conexões unicast, quanto multicast;

- A reserva é feita em uma única direção, ou seja, uma transmissão bidirecional necessita de duas reservas individuais;

- O host origem define as características do data flow e inicia o data path;

- O host destino inicializa e mantém a reserva dos recursos, permitindo que em transmissões multicast cada host possa especificar níveis de QoS diferentes;

- Utiliza o esquema de agregação de mensagens para reduzir o tráfego na rede;


- É possível conviver na mesma rede roteadores que implementam RSVP e outros que utilizem apenas o esquema de best-effort;

- Suporta tanto IPv4, quanto IPv6.

Formato da mensagem RSVP O RSVP é um protocolo de sinalização, ou seja, não transporta dados, apenas mensagens de controle. As mensagens RSVP são encapsuladas diretamente em datagramas IP e consistem em um header comum de tamanho fixo, seguido por um ou mais objetos de tamanho variável.

Version: Especifica a versão do protocolo (1).

Flags: Reservado.

Msg Type: Especifica o tipo da mensagem RSVP, que pode ser:

Tipo 1 – Path: Mensagem enviada da origem para destino para criar o caminho de dados.

Tipo 2 – Resv: Mensagem enviada do destino para a origem para a reserva de recursos.

Tipo 3 – PathErr: Reporta erros na criação do caminho de dados.

Tipo 4 – ResvErr: Reporta erros na reserva de recursos.

Tipo 5 – PathTear: Solicita explicitamente a desalocação do caminho.

Tipo 6 – ResvTear: Solicita explicitamente a desalocação dos recursos.

Tipo 7 – ResvConf: Indica êxito na reserva dos recursos.

RSVP Checksum: Utilizado para garantir a integridade da mensagem.

Send_TTL: Time-to-live do pacote IP em que a mensagem RSVP foi enviada.

RSVP Length: Tamanho da mensagem, incluindo o header e os objetos.

Cada objeto é formado por um header de 32 bits e uma seqüência variável que define as características do objeto.

Length: Tamanho, em bytes, do objeto.

Class-Num: Identifica a classe do objeto.

C-Type: Identifica o tipo de objeto dentro de sua classe.


2.3. Comutação IP

MPLS MPLS significa Multiprotocol Label Switching. O termo multiprotocol é proveniente do fato de que este protocolo foi projetado para funcionar em conjunto com os diversos protocolos das camadas 2 e 3 do modelo OSI. Na prática, o que vemos hoje em relação à implementação do MPLS é seu uso em redes onde a camada 3 é ocupada pelo protocolo IP. Quanto ao termo label switching ou comutação baseada em rótulos, vamos utilizar uma analogia bastante específica para explicar o controle de tráfego baseado em labels: o sistema de correios.

Imagine que sua empresa tenha contratado três tipos de serviço junto à ECT: serviço regular, Sedex e Sedex 10. O primeiro não possui qualquer garantia quanto ao prazo de entrega, sendo tratado pelos correios na base do melhor prazo possível. O segundo serviço tem a entrega garantida no prazo de 24 horas e, por fim, o terceiro serviço contratado tem a garantia de ser entregue até as 10 hs da manhã do dia seguinte.

Certamente o custo das soluções com garantia de entrega é maior em relação ao serviço regular e, entre esses, maior custo para o que oferece rapidez superior. No exemplo, o Sedex 10 é o mais caro entre todos. Com isso, uma empresa não vai enviar toda a sua correspondência pela via mais cara, apenas aquela sensível ao prazo de entrega.

Como os postos de triagem da ECT identificam as correspondências que deverão tomar o caminho expresso ou o caminho regular? Com base em rótulos nos envelopes no momento da postagem, ou seja, no momento em que entraram na rede dos correios. O MPLS funciona de forma bastante similar. Vejamos como.

Quando um pacote de dados entra na rede MPLS, ele recebe um rótulo indicando o tratamento em relação à qualidade de serviço que será dado ao mesmo. Com base neste rótulo, o pacote tomará o caminho já previamente estabelecido que atende aos requisitos exigidos para os pacotes daquele tipo. Portanto, em cada switch MPLS (similar aos postos de distribuição da ECT), será analisado o rótulo do pacote e decidido em qual circuito de saída será colocado o pacote.

Componentes da Arquitetura MPLS Visto o MPLS em linhas gerais, vamos agora ao detalhamento técnico do seu funcionamento.


Label Edge Router (LER) São os roteadores localizados de forma lógica na borda da rede MPLS, responsáveis pela inserção e retirada dos labels, mapeamento dos protocolos de camada 2 e 3 para o MPLS, classificação do tráfego e decisão de quais pacotes farão parte da rede MPLS e de quais serão roteados dentro da estrutura tradicional.

Label Switch Router (LSR) Responsáveis pela comutação dos pacotes dentro do perímetro da rede MPLS. Baseiam-se nos labels inseridos pelos LERs para efetuar esta função.

Label Information Base (LIB) Tabela usada pelos LSRs que contém as instruções que relacionam o circuito de saída de um pacote com o label encontrado no mesmo. Informa, ainda, qual o novo label que o pacote receberá antes de ser colocado no próximo trecho do caminho.

Label Switch Path (LSP) O caminho estabelecido desde a entrada até a saída da rede MPLS para cada tipo de tráfego considerando os requisitos de qualidade de serviço.

Forwarding Equivalence Class (FEC) É o fluxo de dados classificado pelo LER ao qual um label será associado. Podem ser usados como subsídios para a classificação do tráfego de informações em pacotes associados a um mesmo AS, originados em um mesmo prefixo CIDR ou mesmo com campo TOS similar definido pelo DiffServ.

Label Distribution Protocol (LDP) Protocolo usado com a finalidade de distribuir os labels entre os LSRs e com isso garantir que todos os LSRs possam tomar as decisões de comutação baseadas nos labels, traçando o caminho fim-a-fim (LSPs).

Funcionamento do MPLS O MPLS trabalha com a idéia de fluxo de dados. Um fluxo de dados consiste no tráfego fim-a-fim identificado e classificado, eventualmente requerendo uma mesma qualidade de serviço


(QoS). No mundo do MPLS, esse fluxo é denominado Forwarding Equivalence Class ou simplesmente FEC.

Ao entrar na rede MPLS, o LER classifica o pacote como membro de um determinado FEC. Caso este seja o primeiro pacote do fluxo, protocolos de roteamento modificados com extensões que permitem atender às especificidades do MPLS, como BGP com Traffic Engineering (BGP-TE) ou OSPF-TE, determinam a rota que todos os pacotes subseqüentes do mesmo fluxo deverão seguir.

Após determinar a rota do FEC, o LER insere o mesmo label em cada pacote do fluxo. Ele consiste em um segmento de 32 bits, sendo que 20 bits destinados ao identificador do label propriamente dito e 12 bits contendo informações de controle. O label é inserido entre o cabeçalho da camada de enlace e o da camada de rede, como mostra a figura a seguir. O label tem significância local, ou seja, ele somente faz sentido para os LSRs adjacentes, que são aqueles que compartilham o mesmo link.

A fim de garantir que o fluxo (FEC) tenha as mesmas características fim a fim, o MPLS usa um protocolo de distribuição de labels (Label Distribution Protocol ou LDP) para fazer a distribuição dos labels nos quais os LSRs baseiam-se para direcionar o tráfego para o caminho especificado para cada FEC. É também através deste mecanismo que se torna possível garantir a qualidade de serviço (QoS) desde o início até o fim de um dado percurso de rede.

Após o LDP ter sido executado em cada LSR do caminho e, portanto, os labels terem sido devidamente distribuídos, um caminho fim-a-fim é criado desde o LER de entrada até o LER de saída. Tal caminho é definido como Label Switch Path ou simplesmente LSP e é por onde todos os pacotes do mesmo FEC devem passar. Da mesma forma que na entrada da rede MPLS o LER insere o label no pacote de entrada (procedimento denominado PUSH), o LER de saída retira o label do pacote retornando o mesmo à sua forma original (procedimento chamado POP).

Graças ao uso dos labels, o MPLS calcula a rota apenas uma vez para cada fluxo na entrada da rede. Todas as decisões de roteamento feitas dentro da rede pelos LSRs são baseadas nos labels, não sendo necessário o cálculo de rotas em cada nó. Desta forma, o tempo necessário à análise do caminho por onde deve seguir cada pacote de um mesmo fluxo é reduzido.


Exemplo prático passo-a-passo

2.4. Segurança IP

IPSec O IP Security (IPSec) é parte integrante do novo protocolo IP, conhecido como IPv6, que irá substituir a atual versão IPv4. O IPSec é um conjunto de padrões abertos desenvolvidos pelo IETF (Internet Engineering Task Force) que envolve diversos protocolos e algoritmos. Ao contrário dos protocolos de segurança que atuam nas camadas de enlace e aplicação, o IPSec trabalha na camada de rede, oferecendo autenticidade, integridade e confidencialidade em redes públicas, como a Internet.

O IPSec pode ser utilizado em diversas soluções para a conexão segura de redes, como a ligação de filiais à matriz, conexão de usuários remotos às aplicações internas da empresa e criação de extranets e intranets. A utilização da rede pública para trafegar dados de forma segura gera uma grande economia, pois não há necessidade de ligações privadas.


O IPSec é implementado como uma extensão do header IPv6, por meio de dois headers adicionais: Authentication Header (AH) e Encapsulation Security Payload Header (ESP), que serão apresentados nos próximos itens. Ele também pode ser utilizado em redes.

Os headers AH e ESP permitem dois tipos de utilização: modo de transporte e modo de tunelamento. O modo de transporte oferece segurança apenas para as camadas acima da camada de rede, ou seja, transporte e aplicação, sendo utilizado tipicamente para comunicação fim-a-fim entre dois hosts.

O modo de tunelamento oferece proteção integral para o pacote IP, incluindo o seu header. Nesse caso, o pacote IP original pode ser totalmente criptografado e encapsulado dentro de outro pacote


IP, criando a idéia de túnel. Geralmente, este modo é implementado ligando duas redes através de roteadores e/ou firewalls. Os hosts pertencentes a redes diferentes podem comunicar-se de forma segura sem implementarem IPSec.

Um conceito muito importante no IPSec é o de Security Association (SA), pois é utilizado pelos headers AH e ESP. Um SA é uma relação entre origem e destino que permite identificar unicamente uma conexão e implementar a sua segurança. Um SA é formado por três campos:

• Security Parameters Index (SPI) - Funciona como um identificador da SA e aparece em ambos os headers;

• IP Destination Address - Endereço IP do destinatário;

• Security Protocol Identifier - Indica se o SA está associado ao header do tipo AH ou ESP.

A criação e gerência dos SAs é função do protocolo IKE (Internet Key Exchange). O IKE também tem a função de gerenciamento e troca de chaves criptográficas.

Protocolo AHIP

Authentication Header O Authentication Header (AH) oferece os serviços de autenticidade e integridade de pacotes IPv4 e IPv6, mas não oferece confidencialidade (criptografia). Desta forma, é possível autenticar o sistema que está enviando a mensagem e evitar, assim, ataques do tipo spoofing. Além disso, também permite evitar ataques do tipo replay.

O AH utiliza, atualmente, quatro algoritmos para a implementação da autenticação do pacote: Message Digest 5 (MD-5), Secure Hashing Algorithm (SHA), Hashed Message Authentication Code MD-5 (HMAC-MD5) e HMAC-SHA

A seguir, são apresentados os campos do header do protocolo AH:


Next Header: Identifica o header seguinte ao AH.

Payload Length: Tamanho do AH.

Security Parameters Index (SPI): Identifica um security association (SA).

Sequence Number: Utilizado no mecanismo para evitar ataques do tipo replay.

Authentication Data: Utilizado no mecanismo de autenticação do pacote.

O esquema de autenticação implementado pelo AH pode ser empregado nos modos de transporte ou tunelamento. A seguir, são apresentados os formatos dos pacotes IPv4 e IPv6 nos dois modos:


Protocolo ESP IP

Encapsulating Security Payload O Encapsulating Security Payload (ESP) permite implementar a confidencialidade (criptografia) de pacotes IPv4 e IPv6, não oferecida pelo protocolo Authentication Header (AH). Além disso, é possível também implementar a autenticidade do pacote.

O ESP pode utilizar diversos algoritmos para a implementação da criptografia, no entanto, o DES-CBC (Data Encryption Standard-Cipher Block Chaining) e o 3DES-CBC são os algoritmos mais comuns.

O formato do header ESP não é igual ao AH, pois o payload fica dentro do header, criando a idéia de trailer. A seguir, são apresentados os campos do header/trailer do protocolo ESP.

Security Parameters Index (SPI): Identifica um security association (SA).

Sequence Number: Utilizado no mecanismo para evitar ataques do tipo replay.

Payload: Dado sendo efetivamente criptografado.

Padding: O campo possui diversas funções, como, por exemplo, garantir o alinhamento do campo Next Header dentro do trailer.

Pad Length: Tamanho do campo Padding.

Next Header: Identifica o header seguinte ao ESP.

Authentication Data: Utilizado, opcionalmente, no mecanismo de autenticação do pacote, podendo ser implementado utilizando os mesmos algoritmos do protocolo AH.

O esquema de ciframento e/ou autenticação implementado pelo ESP pode ser empregado nos modos de transporte ou tunelamento. A seguir, são apresentados os fomatos dos pacotes IPv4 e IPv6 nos dois modos:


2.5. Tunelamento

GRE O protocolo GRE (Generic Routing Encapsulating) é uma solução genérica para encapsulamento e roteamento de pacotes, também chamados payloads. O payload é encapsulado em um pacote GRE, que pode ser encapsulado em algum outro protocolo e reencaminhado, formando o túnel.


GRP O payload pode ser IPX, AppleTalk, DECnet Phase IV, XNS, VINES ou o próprio IP. Na Internet, o pacote GRE é encapsulado em um datagrama IP. Por exemplo, suponha a conexão de duas redes SPX/IPX através de uma rede IP. Primeiramente, o pacote IPX é encapsulado em um pacote GRE que, por sua vez, é encapsulado em um pacote IP. O pacote IP é roteado até o seu destino, desencapsulado para obter-se o pacote GRE e novamente desencapsulado para obter-se o payload a ser entregue à rede IPX.

O GRE é normalmente implementado nos roteadores, sendo uma solução de fácil implementação, baixo custo e bom desempenho. Túneis GRE são compulsórios, ou seja, são estabelecidos manualmente ligando dois pontos pré-definidos, geralmente LANs. O GRE não implementa criptografia, porém pode-se utilizar o protocolo IPSec para oferecer um túnel criptografado.

O header do pacote GRE possui alguns campos. Os mais importantes estão detalhados a seguir:


Checksum (C) Present (bit 0): Indica se o campo de Checksum está presente e contém uma informação válida.

Routing (R) Present (bit 1): Indica se o campo de Routing está presente e contém informação válida.

Key Present (K) (bit 2): Indica se o campo Key está presente.

Sequence (S) Number Present (bit 3): Indica se o campo Sequence Number está presente.

Recursion Control (bits 5-7): Define o número máximo de encapsulamentos permitidos.

Version Number (bits 13-15): Normalmente igual a zero.

Protocol Type (2 octets): Define o tipo de payload que está sendo encapsulado.

Checksum (2 octets): Contém o Checksum do header GRE e do payload.

Offset (2 octets): Permite identificar o tamanho da parte variável do header.

Key (4 octets): Utilizado como forma de autenticação do transmissor.

Sequence Number (4 octets): Permite ao receptor seqüenciar os pacotes recebidos.

Routing (variable): Lista de SREs (Source Route Entries) que permite definir questões sobre o roteamento do pacote.

L2F O protocolo L2F (Layer 2 Forwarding) foi desenvolvido pela Cisco Systems e implementa o conceito de tunelamento na camada de enlace (nível 2). O L2F está em desuso, pois está sendo substituído pelo protocolo Internet L2TP.

O L2F pode trafegar em diversos tipos de redes, como IP, X.25, Frame Relay e ATM (Asynchronous Transfer Mode). Além disso, permite encapsular diferentes tipos de protocolos, como SNA, IPX/SPX, NetBEUI e o próprio TCP/IP. A autenticação de usuários L2F pode ser feita pelos mesmos protocolos disponíveis no protocolo PPP, além de suporte para TACACS+ e RADIUS.


O formato do pacote L2F é semelhante ao do protocolo GRE. A seguir, é apresentado o formato do L2F e com descrição de seus principais campos:

Packet (P) priority: Se o bit P estiver definido, indica que o pacote é prioritário e deve ser processado antes daqueles sem bit definido.

Ver: O campo indica a versão do protocolo (001).

Sequence: Este campo está presente se o bit S estiver definido e permite ao receptor seqüenciar os pacotes recebidos.

Multiplex ID (MID): Permite identificar uma conexão dentro do túnel.

Cliente ID (CLID): Permite auxiliar na demultiplexação de túneis.

Length: Indica o tamanho total do pacote, incluindo o header, todos os campos e o payload.

Payload Offset: Este campo está presente se o bit F estiver definido e indica onde o payload se inicia dentro do pacote.

Key: Este campo está presente se o bit K estiver definido e é utilizado como mecanismo de autenticação, funcionando como chave para evitar ataques do tipo spoofing.

Checksum: Checksum do pacote, incluindo header e payload.

PPTP O protocolo PPTP (Point-to-Point Tunneling Protocol) foi proposto por um grupo de empresas, incluindo a Microsoft, que adotou este protocolo como solução para VPNs nos seus sistemas operacionais Windows. Apesar disso, o PPTP não é um protocolo proprietário, sendo uma extensão do protocolo PPP (Point-to-Point Protocol) utilizado amplamente em conexões discadas na Internet.

Um pacote PPTP utiliza o conceito de tunneling, encapsulando o frame PPP dentro de um datagrama IP, utilizado para ligar as duas pontas de uma conexão PPTP. Por esse motivo, o PPTP não pode ser utilizado em redes X.25, Frame Relay ou ATM. Ele não possui um header próprio, pois utiliza uma versão modificada do protocolo GRE (Generic Routing Encapsulation), permitindo a conexão de outros tipos de redes (como SNA, IPX/SPX e NetBEUI) além do próprio TCP/IP. O header PPP implementa a segurança do túnel PPTP, oferecendo autenticação, criptografia e compressão. A área de dados do PPP (payload) encapsula os protocolos originais e os dados da aplicação.


O PPTP pode ser utilizado para criar VPNs (1) interligando LANs e (2) interligando usuários remotos à LAN. No segundo caso, as conexões discadas podem ser de dois tipos: com suporte do provedor e sem o seu suporte. Quando o provedor oferece suporte ao PPTP no servidor de acesso remoto (NAS - Network Access Server), o usuário é autenticado no próprio provedor. Nesse caso, o usuário precisa apenas do protocolo PPP, pois o NAS cria o túnel com o servidor PPTP. No entanto, a conexão entre o usuário e provedor não é criptografada (2a). Caso o provedor não ofereça suporte ao PPTP, o próprio cliente deverá criar o túnel com o servidor PPTP (2b).

PPTP interligando LANs

PPTP interligando usuários remotos e uma LAN

A autenticação de usuários remotos PPTP pode ser implementada utilizando os protocolos CHAP (Challenge Handshake Authentication Protocol), MS-CHAP (Microsoft Challenge Handshake Authentication Protocol), PAP (Password Authentication Protocol) e EAP (Extensible Authentication Protocol). A criptografia é implementada utilizando o protocolo MPPE (Microsoft Point-to-Point Encryption), que é baseado no algoritmo simétrico RSA RC4 e pode trabalhar com chaves criptográficas de 40, 56 e 128 bits.


L2TP O protocolo L2TP (Layer 2 Tunneling Protocol) é uma combinação dos protocolos PPTP e L2F (Layer 2 Forwarding), este último desenvolvido pela Cisco Systems. O L2TP deverá tornar-se o padrão Internet para tunelamento na camada de enlace (nível 2) e o IPSec, padrão para camada de rede.

Um pacote L2TP também utiliza o conceito de tunneling, encapsulando o frame PPP dentro de um datagrama UDP/IP. Apesar disso, o L2TP pode trafegar também em outros tipos de redes, como X.25, Frame Relay e ATM. O L2TP possui um header próprio, herdado do protocolo L2F. O header PPP permite implementar a segurança da conexão L2TP, porém, existem formas alternativas de implementar autenticação e criptografia. A área de dados do PPP (payload) encapsula os protocolos originais e os dados da aplicação.

A autenticação de usuários L2TP pode ser feita pelos mesmos protocolos disponíveis no protocolo PPP, como CHAP, MS-CHAP, PAP e EAP, além de outros mecanismos de autenticação (como RADIUS). Também é possível implementar a autenticação de computadores utilizando o IPSec. Em geral, a criptografia é implementada utilizando o protocolo IPSec a partir


do algoritmo DES e 3DES. A figura abaixo mostra um pacote L2TP encapsulado em uma estrutura IPSec.

O L2TP utiliza o mesmo formato de header para mensagens de dados e controle. A seguir, é apresentado o formato do protocolo e seus principais campos. Os campos marcados com um x estão reservados para uso futuro.

Type (T) bit: Indica o tipo da mensagem, ou seja, dado (0) ou controle (1).

Length (L) bit: Indica se o campo Length está presente.

Sequence (S) bit: Indica que os campos Ns e Nr estão presentes.

Offset (O) bit: Indica que os campos de Offset estão presentes.

Priority (P) bit: Indica que o pacote é prioritário e deve receber um tratamento especial.

Ver: Indica a versão do protocolo L2TP (2).

Length: Indica o tamanho total do frame.

Tunnel ID: Permite identificar o túnel para o controle da conexão.

Session ID: Permite identificar uma conexão dentro do túnel.

Ns e Nr: Permitem ao receptor seqüenciar os pacotes recebidos.

Offset Size: Permite identificar onde inicia o payload dentro do pacote.


3. O transporte e a sessão

3.1. Protocolo TCP O protocolo TCP (Transmission Control Protocol), juntamente com o IP (Internet Protocol), são considerados os dois protocolos mais importantes da arquitetura Internet. O protocolo IP encontra-se na camada de rede e está preocupado com o endereçamento do pacote e seu reencaminhamento entre os roteadores.

O IP não tem uma preocupação com a entrega dos pacotes no destino, além de não garantir a seqüência na qual os pacotes são entregues. Por isso, ele é definido como sendo um serviço não orientado à conexão, também conhecido como datagrama não-confiável.

O protocolo TCP fica na camada de transporte e se preocupa em oferecer um serviço orientado à conexão, também conhecido como circuito virtual. Neste caso, a camada de transporte garante a entrega e a seqüência dos pacotes enviados ao destino. Sua principal função é criar uma conexão lógica confiável, livre de erros, entre o host transmissor e o receptor. Para aplicação no host transmissor, é como se existisse uma ligação física com a aplicação no host destino, que desconhece a rede de interconexão e seus problemas. Esse conceito é conhecido como comunicação fim-a-fim.

Todas as conexões TCP são full-duplex, ou seja, a comunicação pode acontecer nos dois sentidos simultaneamente. As conexões são ponto-a-ponto, o que significa que o TCP não suporta endereçamento broadcast ou multicast. Por oferecer um serviço orientado à conexão, o TCP é um protocolo complexo que implementa diversos mecanismos de controle. A seguir, veremos os mais importantes.


Início e término de conexão lógica Para que duas aplicações comuniquem-se utilizando a rede, é necessário que seja estabelecida primeiramente uma conexão lógica entre a aplicação origem e destino. O TCP utiliza para iniciar uma conexão o mecanismo chamado three-way handshake. Quando um host deseja estabelecer uma conexão com outra estação, a origem envia um segmento com o bit SYN ligado. Ao receber a mensagem, o destino responde com um segmento com os bits SYN e ACK ligados. Por fim, a origem confirma para o destino que a conexão foi estabelecida.

Início e término de conexão lógica

Como o TCP implementa comunicação full-duplex para encerrar uma conexão, tanto a origem quanto o destino devem solicitar o seu término. O pedido de fim de conexão é implementado através do bit FIN no segmento TCP, que indica que não há mais dados a serem transmitidos. Depois do reconhecimento do pedido de término de conexão, a comunicação pode ser encerrada.

Endereçamento de transporte Além do endereçamento IP, implementado pela camada de rede, a camada de transporte também utiliza um esquema de endereçamento, conhecido como portas TCP. Para compreendermos a necessidade de endereços de transporte, vejamos dois exemplos práticos.

Suponha um servidor que ofereça diferentes tipos de serviços, como Web, mail e transferência de arquivos. Como o servidor tem apenas um único IP, como seria possível diferenciar os vários serviços de rede oferecidos? No lado do cliente, o usuário abre diversas conexões Web diferentes utilizando o browser. Como o cliente tem apenas um IP, como seria possível para o servidor diferenciar para qual dos browsers a resposta deveria ser enviada?

Em ambos os casos, as portas TCP são utilizadas como mecanismo para a criação de conexões lógicas únicas que diferenciam as aplicações dentro de um mesmo endereço IP. A combinação de um endereço IP e uma porta forma o que é chamado de socket. Uma conexão lógica é formada por um par de sockets: um na origem e outro no destino.


Endereçamento de transporte

A grande maioria dos sistemas operacionais oferece suporte à criação e utilização de sockets, através de system calls e APIs (Application Program Interfaces), o que torna o desenvolvimento de aplicações em rede bastante simplificado.

As portas TCP são números de 16 bits que variam entre 0 e 65.535. Por questões de padronização, as portas abaixo de 1.024 são reservadas para serviços pré-definidos (well-known ports), como apresentado na tabela a seguir. No primeiro exemplo, o servidor utilizaria uma porta pré-definida para cada serviço oferecido. Nesse caso, utilizaria as portas 80 (Web), 25 (correio eletrônico) e 20/21 (transferência de arquivos).

Serviço Porta

Transferência de arquivos (FTP) 20 e 21

Telnet 23

Correio eletrônico (SMTP) 25

Serviços de nomes (DNS) 53

Web (HTTP) 80

Correio eletrônico (POP) 110

As portas acima de 1.023 são portas que podem ser utilizadas dinamicamente, conforme a necessidade das aplicações. No segundo exemplo, a cada conexão aberta pelo browser seria associado um socket diferente, contendo o mesmo IP, porém com portas diferentes.


É possível que os clientes tenham acesso a uma aplicação sem ter o conhecimento da porta na qual o serviço está sendo oferecido. Nesse caso, o cliente deve conhecer, pelo menos, o nome da aplicação e solicitar o número da porta correspondente ao nome do serviço.

Controle de erro fim-a-fim Como já sabemos, a camada de rede oferece um serviço não orientado à conexão através do protocolo IP. É responsabilidade da camada de transporte, mais especificamente do protocolo TCP, garantir a entrega e a seqüência correta dos datagramas. Para implementar esse serviço, o TCP utiliza a técnica de reconhecimento com retransmissão.

De forma simplificada, sempre que o host origem envia uma mensagem, o host destino deve informar através de um reconhecimento (ACK) que recebeu a mensagem.

Como não existe a garantia de que a mensagem alcançará o destino, o host origem ao enviar a mensagem, também inicializa um temporizador. Caso um ACK não chegue no tempo previsto, a origem retransmite a mensagem.


Na situação anterior, pode ocorrer a duplicação de uma mensagem no destino, caso a mensagem tenha sido corretamente recebida pelo destinatário. No entanto, o ACK enviado pode não alcançar a origem por algum problema. Nesse caso, o receptor deve reconhecer o problema e descartar as mensagens repetidas. Para isso, cada mensagem deve ser numerada de forma a permitir sua identificação.

Se o esquema adotado pelo TCP fosse exatamente como descrito, haveria um grande desperdício da capacidade de transmissão da rede, pois, para cada mensagem enviada, um ACK deveria ser retornado. Na verdade, o TCP utiliza a técnica de reconhecimento cumulativo para implementar o controle de erro de forma eficiente. Nessa técnica, o transmissor pode enviar várias mensagens sem aguardar um ACK individual para cada mensagem. O host destino pode receber um certo número de mensagens e reconhecer apenas a última recebida. Dessa forma, é possível reconhecer um conjunto de mensagens, evitando o ACK individual para cada mensagem.

Para implementar a técnica de reconhecimento cumulativo, o TCP utiliza o mecanismo de sliding window. O sliding window implementa o conceito de janelas deslizantes, sendo que a origem possui uma janela de envio e o destino uma janela de recepção. A janela de envio desliza conforme os ACKs do destino são recebidos, sendo que o número máximo de mensagens que podem ser enviadas sem reconhecimento dependerá do tamanho da janela de recepção. A janela de recepção permite receber várias mensagens, armazená-las e reconhecer apenas a última


mensagem recebida. Por exemplo, se o tamanho da janela de recepção for igual a quatro, o host origem poderá transmitir até quatro mensagens sem receber ACKs.

A animação ao lado apresenta uma seqüência de mensagens, uma janela de transmissão de quatro posições e três ponteiros que permitem o controle da envio e reconhecimento das mensagens. O intervalo em amarelo indica as mensagens que já foram transmitidas e reconhecidas. O intervalo em azul indica as mensagens transmitidas, mas ainda não reconhecidas. O intervalo em verde indica as mensagens que podem ainda ser transmitidas, sem a necessidade de recebimento de qualquer ACK do destino. As demais mensagens no intervalo vermelho apenas poderão ser transmitidas quando houver o deslocamento da janela.

Para cada conexão TCP existem quatro janelas. Como a conexão é full-duplex, existe uma janela de transmissão e uma janela de recepção para cada sentido da comunicação.

Controle de fluxo fim-a-fim O controle de fluxo é a capacidade do host receptor avisar ao host transmissor sobre sua capacidade de recebimento de mensagens, a fim de evitar o problema de overflow. O problema de overflow ocorre quando o buffer do host destino fica cheio e novas mensagens continuam chegando. Nesse caso, o host destino deve descartar todas as mensagens recebidas enquanto o seu buffer não tiver espaço disponível. Conseqüentemente, o host origem deverá retransmitir todas as mensagens descartadas pelo destino.

Esse problema também é resolvido utilizando o esquema de sliding window, sendo que o tamanho da janela varia em função do tempo. Nesse caso, o receptor, quando reconhece uma ou mais


mensagens, também informa ao transmissor o tamanho de sua janela disponível para recepção de novos dados. A partir dessa informação, disponível no campo window size, o transmissor pode aumentar ou diminuir sua janela de transmissão. Por exemplo, se o receptor avisa que sua janela de recepção é zero, o transmissor deve parar de enviar novas mensagens imediatamente, pois o buffer do receptor está cheio. Posteriormente, quando o buffer tiver espaço disponível, o transmissor pode ser avisado que pode novamente enviar dados.

Segmento TCP Um segmento TCP é formado por um cabeçalho de 20 bytes, seguido de um número variável de opções e finalizado por uma área de dados também opcional. Em geral, o tamanho máximo de um segmento é limitado pelo campo de dados do datagrama IP, ou seja, 65.515 bytes (64 Kb menos 20 bytes do cabeçalho IP). O formato do segmento TCP pode ser observado na figura abaixo.


Source port: Identifica a porta de origem. Juntamente com o IP de origem formam o socket de origem.

Destination port: Identifica a porta de destino. Juntamente com o IP de destino formam o socket de destino.

Sequence number: Identifica a mensagem que está sendo enviada. Na verdade, o TCP numera os bytes dentro do segmento e o sequence number identifica a posição do byte dentro do segmento.

Acknowledgement number: Identifica o número do próximo byte que o transmissor espera receber.

TCP header length: Identifica o tamanho do cabeçalho TCP, incluindo as opções, quando utilizadas.

URG (Urgent): Flag que indica que o campo urgent pointer é válido e deve ser utilizado.

ACK: Flag que indica que o campo acknowledgement number é válido e deve ser utilizado para reconhecimento.

PSH (Push): Flag utilizado para forçar o envio do segmento imediatamente, independentemente do seu tamanho.

RST (Reset): Flag utilizado para a reinicialização da conexão.

SYN (Synchronize): Flag utilizado para a abertura de uma conexão lógica.

FIN: Flag utilizado para a finalização de uma conexão lógica.

Window size: Utilizado para informar ao transmissor o tamanho da janela ainda disponível para o recebimento de dados no receptor, a fim de implementar o controle de fluxo fim-a-fim e evitar overflow.

Checksum: Utilizado para garantir a integridade do segmento, ou seja, cabeçalho e dados.

Urgent pointer: Permite implementar um mecanismo de sinalização, pelo qual a origem informa ao destino que o processamento do segmento deve ser interrompido.

Options: Permitem definir opções adicionais não disponíveis no cabeçalho padrão, como o tamanho máximo do segmento, ampliar a capacidade da janela de recebimento e utilização da retransmissão seletiva com o uso de NAKs.

Data: Área onde são encapsulados os dados vindos da camada de aplicação. O tamanho máximo do campo de dados está limitado ao campo de dados do datagrama IP, ou seja, 65.495 bytes (64 Kb menos 20 bytes do cabeçalho IP menos 20 bytes do cabeçalho TCP). O campo de dados pode não estar presente em segmentos que, por exemplo, apenas realizam a função de reconhecimento ou que iniciam ou finalizam uma conexão.

3.2. Protocolo UDP O protocolo UDP (User Data Protocol) está na mesma camada que o TCP, no entanto, eles são bastante diferentes. Enquanto o protocolo TCP está preocupado em oferecer um serviço orientado à conexão, o UDP oferece um serviço não orientado. Quando se utiliza o UDP na camada de transporte significa que não há garantias de entrega e seqüência de pacotes a serem entregues à camada de aplicação. Nesse caso, a implementação do serviço é delegada para a camada de aplicação.


A grande maioria dos protocolos de aplicação, como HTTP, FTP e SMTP, utiliza o TCP na camada de transporte. Por outro lado, existem alguns protocolos que utilizam o UDP, como o DNS, TFTP e BOOTP. Os protocolos de aplicação que utilizam o UDP levam em conta que o meio de transmissão oferece baixas taxas de erros, como no caso de redes locais.

A principal função do UDP é implementar o endereçamento no transporte e oferecer integridade dos dados transmitidos. Sua maior vantagem é o desempenho, pois dispensa a necessidade de estabelecer uma conexão lógica e depois desfazê-la. Um segmento UDP é formado por um cabeçalho de 8 bytes e uma área de dados opcional. O formato do segmento UDP pode ser observado na figura abaixo.

Source Port: Identifica a porta de origem. Juntamente com o IP de origem formam o socket de origem.

Destination port: Identifica a porta de destino. Juntamente com o IP de destino formam o socket de destino.

Length: Identifica o tamanho do segmento UDP, incluindo o cabeçalho e a área de dados.

Checksum: Utilizado para garantir a integridade do segmento. A utilização deste campo é opcional.


3.3. Protocolo LDAP O protocolo LDAP (Lightweight Directory Access Protocol) é um padrão para a utilização de serviços de diretório em uma rede de computadores. Um diretório é uma base de dados com informações sobre os diversos objetos da rede, como impressoras, usuários e servidores. O serviço de diretório permite que um cliente obtenha informações sobre os objetos disponíveis da rede a partir dessa base de dados.

Um serviço de diretório é semelhante a um serviço de páginas amarelas, onde várias empresas estão organizadas por áreas de atuação com seus nomes, endereços e telefones. No caso de um serviço de diretório, um usuário pode pesquisar, por exemplo, por uma impressora colorida de alta resolução que aceite um determinado tipo de arquivo e que esteja próxima de seu local de trabalho. O usuário poderia também pesquisar por um usuário em especial e localizar seu email e telefone para contato.

O LDAP está na camada de aplicação, utiliza o protocolo TCP como transporte e funciona no modelo cliente/servidor. Nesse modelo, o cliente solicita uma informação ao servidor responsável por manter o serviço de diretório, o servidor recebe a solicitação, processa o pedido e envia a resposta para o cliente.

Existem vários produtos que oferecem serviços de diretórios, como o Novell Directory Services (NDS) e o Active Directory da Microsoft. É importante verificar o grau de compatibilidade com o padrão LDAP nos produtos que oferecem esse tipo de serviço.


3.4. Serviço DNS

Protocolo DNS Em uma rede TCP/IP, os hosts comunicam-se utilizando o endereço IP; no entanto, os usuários da rede preferem utilizar nomes em vez de endereços. Para facilitar o acesso aos hosts da rede, cada endereço IP deve estar associado a um nome de host. Sempre que o usuário refere-se a um nome de host, esse nome deve ser convertido antes para o endereço IP correspondente.

Uma forma bastante simples de implementar esse esquema de endereçamento é utilizar um arquivo em cada estação contendo uma lista com o nome de cada host existente na Internet e seu respectivo IP. Quando o usuário refere-se a um host, o nome é pesquisado no arquivo e o endereço IP retornado. Em função do número de hosts da Internet e suas constantes mudanças, manter tal arquivo seria, na prática, impossível. Logo, esse método é indicado apenas para pequenas redes.


# 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host

127.0.0.1 localhost 200.255.253.239 pop-gw.embratel.com.br 200.255.125.213 www.embratel.com.br 200.162.224.82 edu.topmaster.com.br 200.225.79.48 www.topmaster.com.br

O exemplo acima refere-se ao arquivo host utilizado na maioria dos sistemas operacionais para criar o mapeamento estático de endereços.

O protocolo DNS (Domain Name System) foi desenvolvido com a finalidade de servir como tradutor de nomes em grandes redes, como a Internet. Por exemplo, quando o usuário digita o endereço da Embratel, o nome www.embratel.com.br deve ser traduzido antes para o IP correspondente ao servidor Web (200.255.125.213). Depois de obtido o endereço IP, o acesso ao servidor poderá ser realizado.

O serviço de nomes é implementado por servidores DNS que possuem tabelas relacionando os nomes de hosts e seus respectivos IPs. Quando um usuário utiliza o nome www.embratel.com.br, um servidor DNS é consultado e o IP correspondente retornado. Se o usuário souber o IP do servidor da Embratel, o servidor DNS não será consultado.

; Hosts para: embratel.net.br

@ IN SOA ns.embratel.net.br. admin.embratel.net.br. (

1999052101; Serial (aaaammddvv)

3600 ; Refresh (1 hour)


900 ; Retry (1/4 hour)

604800 ; Expire (1 week)

86400) ; Minimum (1 day)

IN NS ns.embratel.net.br.

IN NS ns2.embratel.net.br.

IN MX 100 mailhost.embratel.net.br.

ns2 IN A 200.245.255.33

ns IN A 200.255.253.241

mailhost IN A 200.255.253.239

rjo01 IN A 200.208.155.102

;

;

rjo02 IN A 200.208.155.150

www 60 IN CNAME rjo02

home IN CNAME rjo02

infoserv 60 IN CNAME rjo02

;

news IN A 200.208.155.103

;


rjo04 IN A 200

Espaço de endereçamento O espaço de endereçamento (namespace) utilizado pelo DNS é hierárquico, semelhante ao modelo de árvore de diretórios e subdiretórios utilizado na maioria dos sistemas operacionais. O DNS é formado por domínios e subdomínios, sendo que o domínio raiz é conhecido como root. Abaixo do root existem os domínios de primeiro nível (top-level) que podem representar domínios genéricos ou países. Abaixo dos domínios de primeiro nível, estão os subdomínios que, por sua vez, podem ser formados por outros subdomínios. Os hosts ficam nas folhas.

Para se ter acesso a um host que faça parte do esquema de domínios, basta fazer referência ao caminho a partir da raiz. Por exemplo, o servidor Web da Embratel pode ser referenciado como www.embratel.com.br e o servidor correio poderia ser referenciado como smtp.embratel.com.br.


Genérico Descrição

gov Governo

com Comercial

mil Militar

org Organização sem fins lucrativos

edu Educacional

net Provedores

Domínio de país Descrição

br Brasil

us Estados Unidos

de Alemanha

jp Japão

nl Holanda

O esquema de nomes hierárquico torna o DNS bastante flexível. Quando um novo subdomínio precisa ser criado, basta apenas solicitar sua criação abaixo do domínio desejado, sem interferir nos demais domínios. No caso do domínio de uma empresa, é possível a criação de subdomínios apenas com a alteração do servidor DNS da própria empresa. Por exemplo, se for preciso criar o subdomínio ead abaixo do domínio Embratel, basta que o administrador da rede registre no servidor DNS do domínio embratel.com.br o novo domínio ead.embratel.com.br.

Busca de nomes O DNS, além de hierárquico, também é um esquema distribuído. Devido ao grande número de hosts na Internet, seria complicado que todos os servidores DNS fossem capazes de traduzir qualquer nome para seu respectivo IP. No modelo distribuído, os servidores DNS mapeiam apenas um pequeno número de hosts, formando uma zona de autoridade.

Uma zona de autoridade pode responder por um ou mais domínios, sendo esta uma decisão do gerente da rede. Cada zona possui um servidor DNS primário, que possui o arquivo com a configuração utilizada pelo servidor e um ou mais servidores secundários. Esses sevidores secundários possuem uma cópia da configuração e funcionam como backup do servidor primário.

O esquema de busca de um nome dentro da estrutura de domínios é conhecido como lookup, sendo iniciado pelo cliente chamando a rotina resolver. Para exemplificar o seu funcionamento, vejamos o exemplo de um usuário localizado no domínio www.mci.com acessando o site de treinamento à distância da Embratel ead.embratel.com.br.


Registros de DNS Um servidor DNS é responsável por várias outras informações além do mapeamento host-IP, sendo que cada uma delas é representada por um tipo de registro. Observe, a seguir, os principais tipos de registro do DNS:


Tipos de registro do DNS Descrição

SOA (Start Of Authority) Define uma zona de autoridade e fornece algumas informações gerais sobre o domínio.

Informações contidas no registro SOA

Serial Indica a versão da informação. O servidor secundário compara de tempos em tempos (refresh) o serial da zona que ele possui com o serial no servidor primário.

Refresh Indica a freqüência com que o secundário checará com o primário se uma zona deve ser atualizada.

Retry Informa quanto tempo um secundário deve aguardar antes de tentar novamente uma transferência de zona que tenha falhado.

Expire Tempo máximo que um secundário pode usar uma informação sobre uma zona antes que ela expire por falta de refresh.

Minimum TTL

Especifica o valor default para uma zona que especifica o tempo em que uma informação ficará cacheada antes de ser descartada.

NS (Name server) Indica os servidores autoritativos para uma zona. Cada zona deve possuir pelo menos dois servidores autoritativos.

A (Address) Permite mapear o nome do host e seu respectivo IP. Uma determinada máquina deve ter um registro A para cada endereço IP que possuir.

MX (Mail eXchange) Define o servidor configurado para o recebimento de e-mails para o domínio.

PTR (Pointer) Permite mapear o IP ao nome do host, sendo utilizado para buscas reversas.


CNAME (Canonical Name) Permite criar alias (apelidos) para os nomes de hosts.

Tabela de DNS Interativa Conheça melhor os registros da tabela de DNS clicando no nome do registro abaixo:


|


3.5. Protocolo RTP/RTCP O protocolo RTP (Real-time Transport Protocol) é direcionado à transmissão de dados em tempo real, como áudio e vídeo interativos, tendo sido projetado principalmente para a transmissão multicast. O RTP é muito utilizado em aplicações para vídeo-conferência, ferramentas de apresentação multimídia e tráfego de voz (VoIP).

O RTP localiza-se na camada de aplicação e utiliza o protocolo UDP na camada de transporte, basicamente para oferecer endereçamento e verificação de integridade da mensagem. A figura, a seguir, apresenta o encapsulamento da mensagem RTP dentro de um segmento UDP, que por sua vez está encapsulado em um pacote IP.

É importante ressaltar que o protocolo RTP não garante a qualidade do serviço, pois não tem qualquer influência na pré-alocação de recursos na rede de interconexão. Para isso, devem ser utilizados outros protocolos, como o RSVP (Resource reSerVation Protocol) e MPLS (MultiProtocol Label Switching), apresentados anteriormente.


Principais funções do protocolo RTP

Timestamping

As mensagens RTP enviadas possuem o momento exato no qual foram geradas. Com esta informação, o destinatário pode implementar a temporização da mensagem, ou seja, reproduzi-la da mesma forma que a original.

Controle de erro e seqüenciamento As mensagens RTP enviadas possuem o momento exato no qual foram geradas. Com esta informação, o destinatário pode implementar a temporização da mensagem, ou seja, reproduzi-la da mesma forma que a original.

Identificação do tipo da mensagem O protocolo RTP permite definir diferentes formatos de dados que podem ser enviados, como PCM, MPEG, JPEG e H.261. Essa característica torna o protocolo bastante flexível para o tráfego de áudio e vídeo, além de simplificar a inclusão de novos formatos.

O protocolo RTCP (Real-time Transport Control Protocol) foi projetado para trabalhar em conjunto com o protocolo RTP. As suas principais funções são a monitoração da qualidade do serviço e a identificação dos participantes da transmissão. Durante uma sessão RTP, os participantes periodicamente trocam mensagens RTCP com o objetivo de informar aos demais a qualidade dos dados recebidos. Com isso, é possível que o emissor ajuste a sua transmissão em função das informações recebidas.


4. Os Serviços e Aplicações

4.1. Servidores Web

Protocolo HTTP O serviço World Wide Web (WWW) ou, simplesmente, Web é basicamente um conjunto de documentos (páginas) contendo texto, imagens, áudio e/ou vídeo. As páginas são interconectadas através de hiperlinks, permitindo ao usuário navegar entre os diversos documentos de forma bastante intuitiva. O esquema de hiperlinks que liga os documentos forma o que é conhecido como hipertexto.

Os documentos disponibilizados na Internet são desenvolvidos em HTML (HyperText Markup Language), que é uma linguagem de marcação de texto responsável apenas pela forma na qual as informações são apresentadas na tela. Depois de desenvolver as páginas HTML, os arquivos devem ser copiados para um servidor Web, como o Apache e Microsoft Internet Information Server (IIS).

Um cliente que deseja acessar uma determinada página deve utilizar sua respectiva URL (Uniform Resource Locator), como, por exemplo, http://www.embratel.com.br/ index.html, sendo que:

• http especifica o protocolo responsável pela comunicação entre o browser e o servidor;

• www.embratel.com.br representa o domínio DNS;

• index.html é a página HTML.

Depois que a página é localizada e copiada do servidor Web para o cliente, o browser interpreta as marcações (tags) da página e a exibe na tela.


O protocolo HTTP (HyperText Transfer Protocol) faz parte da camada de aplicação do modelo Internet, utiliza o protocolo TCP como transporte e funciona no modelo cliente-servidor. Nesse modelo, quando um cliente deseja um serviço, abre-se uma conexão TCP e o pedido é enviado. O servidor processa e devolve a solicitação pela mesma conexão TCP, que é desfeita em seguida. Esse esquema de comunicação é conhecido como conexão sem estado (stateless connection). Foram introduzidos alguns artifícios para manter o controle das conexões, tais como cookies.

Endereçamento de transporte

O HTTP é formado por dois tipos de mensagens: solicitações do cliente para o servidor e respostas do servidor para o cliente. As mensagens utilizadas no HTTP são do formato texto. Nas versões iniciais do protocolo, as mensagens de solicitações e respostas eram bastante simples (simple-request e simple-response). O HTTP/1.1 implementa mensagens mais complexas (full-request e full-response).

Uma mensagem de solicitação completa é formada por um método, a URL que deseja-se acessar e a versão do protocolo HTTP que está sendo utilizada pelo cliente.

Solicitação completa: <Método> <URL> <Versão do HTTP>

O método, na verdade, indica o comando que está sendo solicitado ao servidor. A tabela, a seguir, apresenta os principais métodos disponíveis:


Método Descrição

GET Permite solicitar uma página em uma URL.

HEAD Permite solicitar apenas o cabeçalho da página.

PUT Permite transferir uma página para uma URL.

POST Permite acrescentar uma página.

DELETE Permite eliminar uma página.

Apesar da simplicidade, uma solicitação HTTP pode conter informações adicionais a serem enviadas ao servidor. Essas informações são descritas como uma seqüência de cabeçalhos (request headers) que são enviados juntamente com uma solicitação.

O exemplo abaixo ilustra o que o servidor Web irá receber do browser. A primeira linha indica o método utilizado (GET), a URL contendo o nome do arquivo desejado e a versão do HTTP, no caso a 1.0. A segunda linha identifica o browser que está sendo usado pelo usuário, no caso o Navigator (também conhecido como Mozilla), componente do Netscape Communicator. Essa linha, assim como as demais, contém informações complementares ao pedido HTTP. As quatro linhas seguintes trazem diversas informações úteis. A terceira linha, por exemplo, indica que o browser está preparado para receber documentos texto (text/plain), documentos HTML (text/html) e diversos tipos de imagens, como GIF (image/gif) e JPEG (image/jpeg). Essa lista é codificada de acordo com regras MIME (Multipurpose Internet Mail Extensions), que identificam o tipo de documento. Na terceira linha, o */* indica que o browser aceita qualquer tipo de arquivo.

GET /internet/index.html HTTP/1.0 User-agent: Mozilla/4.5b1 [en] (WinNT; I) Accept: text/plain, text/html, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */* Accept-Charset: iso-8859-1,*,utf-8 Accept-Encoding: gzip Accept-Language: en

Uma mensagem de resposta completa é formada pela versão do protocolo HTTP que está sendo utilizada pelo cliente, por um código de status e uma pequena frase explicando o código de status.

Resposta completa <Versão do HTTP> <Status> <Frase>


Existem inúmeros códigos de status que podem indicar sucesso na solicitação, falha no cliente ou no servidor. Alguns exemplos de códigos bastante comuns são apresentados a seguir:

Código Frase Descrição

200 Document follows Solicitação bem sucedida e o documento será enviado.

403 Unauthorized Acesso não autorizado.

404 Not found Documento não localizado.

O exemplo, a seguir, seria a resposta enviada a partir da solicitação apresentada anteriormente. A primeira linha indica a versão 1.0 do HTTP, o código de status 200 e que a informação requisitada será retornada. Nas linhas seguintes são identificados o servidor Web, o tamanho do documento (5807 bytes, de acordo com o exemplo) e outras informações. A mais importante, entretanto, é a Content-type, que informa ao browser o tipo de informação que está sendo retornada, de modo que ele possa exibi-la da forma adequada. Essa informação é codificada pelo tipo MIME no pedido do browser, do mesmo modo que a lista de tipos na linha Accept.

Em outras palavras, o servidor Web, ao receber o pedido, procura o arquivo e verifica a sua extensão (.html) através de uma consulta a uma grande tabela de tipos MIME que indica o código que deverá ser usado para cada extensão existente. No caso, o tipo usado foi o text/html, indicando que o arquivo que está sendo enviado é do tipo HTML. Após as linhas iniciais e uma linha intermediária em branco, vem o documento propriamente dito ou alguma resposta acusando erro ou arquivo não encontrado. Essa informação será, então, exibida pelo browser segundo o tipo MIME informado na linha Content-type. Nesse momento, a página requisitada aparece na tela do browser do usuário.

HTTP/1.0 200 Document follows Date: Thu, 20 Aug 1998 18:47:27 GMT Server: NCSA/1.4.2 Content-type: text/html Last-modified: Fri, 14 Aug 1998 20:14:23 GMT Content-length: 5807 ... conteúdo do arquivo index.html ...


4.2. Servidores FTP

Protocolo FTP O protocolo FTP (File Transfer Protocol) permite a transferência de arquivos entre hosts utilizando a rede de comunicação. O usuário remoto pode, além de copiar arquivos, visualizar o conteúdo de arquivos e diretórios, definir o formato dos arquivos (texto e executável) além de criar e eliminar arquivos e diretórios.

O FTP está na camada de aplicação e utiliza o protocolo TCP no transporte. O FTP utiliza o modelo cliente/servidor, sendo necessário um cliente FTP e um servidor FTP. O servidor FTP utiliza duas portas pré-definidas: 20 (dados) e 21 (controle). A porta 20 é reservada para a transferência de dados entre cliente e servidor, enquanto a porta 21 é utilizada para a troca de comandos.

O usuário tem acesso aos serviços de transferência de arquivo a partir do utilitário FTP, que geralmente acompanha a maioria dos sistemas operacionais. A tabela, a seguir, descreve os principais comandos disponíveis no utilitário:

Comando Descrição

open Abre uma conexão.

close Encerra uma conexão.

get Copia um arquivo do host remoto para o host local.

put Copia um arquivo do host local para o host remoto.

dir Lista o conteúdo do diretório remoto.


ascii/binary Permite definir o formato do arquivo.

Após o comando open, o usuário é solicitado a identificar-se através de um login e senha. Apesar dessa facilidade, o protocolo FTP não oferece qualquer confidencialidade no envio das informações, inclusive em relação à senha, que é enviada abertamente. Alguns servidores FTP permitem o login anônimo, utilizando a conta anonymous.

No exemplo a seguir, estamos conectando o servidor FTP da Embratel ftp.embratel.net.br utilizando a conta anonymous e verificando o conteúdo do diretório default de login.

Exemplo:

ftp> open ftp.embratel.net.br Connected to ftp.embratel.net.br. 220 wks01.rjo.embratel.net.br FTP server (Version wu-2.6.2(1) Tue Dec 4 17:42:05 EDT 2001) ready. User (ftp.embratel.net.br:(none)): anonymous 331 Guest login ok, send your complete e-mail address as password. Password: 230-+-----------------------------------------------------------------------+ 230-Servicos Internet Via EMBRATEL 230-Bem-vindo ao Servidor de FTP da Embratel ! (ftp://ftp.embratel.net.br) 230- Horario Local : Mon Jul 22 23:34:32 2002 230- Sua maquina : dial237.ism.com.br 230- Voce e' o usuario numero 2. 230- Numero maximo de usuarios anonimos : 400 ftp> dir 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. total 16 -rw-r--r-- 1 1 1242 Oct 26 1999 .welcome lrwxrwxrwx 1 1 7 Aug 31 2000 bin -> usr/bin dr-xr-xr-x 2 1 512 Oct 26 1999 dev dr-xr-xr-x 3 1 512 Oct 26 1999 etc drwxr-xr-x 2 70 512 Oct 26 1999 incoming drwxr-xr-x 23 70 512 May 16 14:06 pub drwxr-xr-x 5 1 512 Oct 26 1999 usr 226 Transfer complete. ftp: 381 bytes received in 0,09Seconds 4,19Kbytes/sec.

Protocolo TFTP O protocolo TFTP (Trivial File Transfer Protocol), assim como o FTP, também permite a transferência de arquivos, porém de forma mais simples. Um exemplo de utilização do TFTP acontece na implementação de boot remoto em estações diskless (sem disco).

O TFTP está na camada de aplicação e utiliza o protocolo UDP no transporte, o que obriga o TFTP a implementar seus próprios mecanismos de controle de erro. O TFTP também utiliza o modelo cliente/servidor, sendo necessário um cliente e um servidor TFTP. O servidor TFTP utiliza apenas a porta 69 para dados e controle.


4.3. Servidores de correio eletrônico

Protocolo SMTP O serviço de email (electronic mail) ou correio eletrônico é um dos mais antigos e importantes serviços da Internet. O serviço é formado por clientes (user agents) e servidores (Message Transfer Agents - MTAs). Os clientes, como Eudora e Microsoft Outlook, são responsáveis por enviar e receber as mensagens. Os servidores, como Sendmail, Lotus Notes e Microsoft Exchange, são responsáveis por reencaminhar a mensagem até seu destino.

Um email é muito semelhante a uma carta convencional, sendo formado por um envelope com informações do destinatário, um cabeçalho com informações do remetente e o texto propriamente dito. Inicialmente, a área de texto permitia apenas mensagens simples utilizando caracteres ASCII, no entanto, o protocolo MIME (Multipurpose Internet Mail Extensions) foi concebido para ser uma extensão, oferecendo suporte a outros alfabetos e mídias, como imagens, som e vídeo.

O protocolo SMTP (Simple Mail Transfer Protocol) está na camada de aplicação e utiliza o protocolo TCP no transporte. O servidor de email recebe conexões na porta pré-definida 25. Após estabelecida a conexão, a mensagem é armazenada na caixa postal (mailbox) do destinatário. Por exemplo, quando enviamos um email para [email protected], a mensagem é armazenada na mailbox referente ao usuário rbmaia.


Protocolo POP3 e IMAP O protocolo POP3 (Post Office Protocol versão 3) permite que um cliente acesse um servidor de email, onde está sua caixa postal, e transfira suas mensagens do servidor para a máquina local. Em geral, as mensagens são apagadas do servidor depois de copiadas para o cliente.

O protocolo IMAP (Interactive Mail Access Protocol) permite que um cliente acesse um servidor de email, onde está sua caixa postal, e apenas consulte suas mensagens no servidor, sem copiá-las para a máquina local. A grande vantagem do IMAP é permitir que o usuário possa ter acesso à sua caixa postal em qualquer máquina, ou seja, ele poderá consultar seus emails em um desktop no trabalho ou em um laptop em casa.

4.4. Aplicações de Segurança

Firewall Um firewall permite implementar um esquema de segurança centralizado, onde todo o tráfego que sai ou entra de/para a empresa pode ser monitorado. Com esse monitoramento, é possível restringir o acesso da rede interna de/para a rede externa, normalmente a Internet.

Em geral, o firewall é um software que é executado em um servidor Unix, Microsoft Windows NT ou Windows 2000, dedicado exclusivamente para essa função. Também existem soluções que englobam hardware e software proprietários. Independentemente da plataforma, as soluções de firewall podem ser divididas em dois tipos: firewall de rede e firewall de aplicação.


Firewall de rede O tipo mais simples de firewall atua apenas na camada de rede, basicamente monitorando informações do datagrama IP, como endereço de origem e destino e o tipo de protocolo. Opcionalmente, também monitora portas de origem e destino pertencentes à camada de transporte, por isso esse tipo de firewall também é chamado de filtro de pacotes.

Aplicação

Transporte

Rede

Enlace/Físico

Firewalls deste tipo são utilizados nas bordas da rede, funcionando como um primeiro nível de defesa, podendo ser implementado no próprio roteador que conecta a rede interna e externa.

A partir de regras previamente definidas, o firewall pode permitir ou não certos tipos de tráfego entre a rede interna e a Internet. Por exemplo, a tabela abaixo apresenta algumas das regras que podem ser implementadas em um firewall para a rede 192.168.1.0.

IP origem

Porta origem

IP destino

Porta destino

Ação Descrição

* * 192.168.1.0 > 1023 Permite Permite que as conexões solicitadas internamente possam ser estabelecidas

* * 192.168.1.2 25 (SMTP)

Permite Permite que qualquer usuário acesse o serviço de mail

* * 192.168.1.3 80 (HTTP)

Permite Permite que qualquer usuário acesse o serviço de Web

* * * * Nega Qualquer acesso que não tenha sido permitido é negado

Apesar da simplicidade, a definição e a manutenção das regras do firewall podem tornar-se difíceis, em função do grande número de regras especificadas. Um dos principais problemas com firewalls de rede é a possibilidade de não se identificar ataques que falsifiquem o endereço IP de


origem, conhecidos como IP spoofing. Devido à fragilidade do protocolo, não se recomenda a autenticação baseada em endereços IP.

Os firewalls de rede evoluíram e passaram a utilizar também informações da camada de transporte para identificar e monitorar uma conexão lógica.

Esse tipo de firewall é conhecido como stateful inspection e atua, basicamente, no controle das portas de origem e destino. Quando um cliente solicita uma conexão TCP, a porta origem deve estar entre 1024 e 16384, enquanto a porta destino deverá ter um número entre 0 e 1023.

Aplicação

Transporte

Rede

Enlace/Físico

Por exemplo, uma conexão a um servidor Web utilizará, por default, a porta destino 80 e como porta origem alguma porta disponível acima de 1023. O firewall stateful controla cada porta origem utilizada na abertura de uma conexão externa, permitindo respostas apenas para as portas de onde partiram as solicitações. Esta solução é mais segura que a oferecida por firewalls de rede, que permitem a entrada de qualquer porta acima de 1023.

Além disso, o firewall stateful reconstrói os pacotes fragmentados e analisa o conteúdo por completo, impedindo que um conjunto de pacotes aparentemente inócuos se transforme em um ataque.

Firewall de aplicação (Proxy) O firewall de aplicação ou proxy, além de poder executar as funções de filtro de pacotes, pode examinar os protocolos da camada de aplicação, como HTTP e SMTP. Ao monitorar os protocolos de aplicação, o controle é maior em relação a apenas realizar a verificação de endereços IP e portas.

Aplicação

Transporte

Rede

Enlace/Físico


O proxy funciona como um intermediador entre o cliente e o servidor. O cliente solicita um serviço ao servidor e o proxy intermedia a conexão, criando uma conexão com cliente e uma outra com o servidor. Todas as mensagens enviadas ou recebidas podem ser analisadas pelo proxy, que pode permitir ou não o envio/recebimento de uma determinada mensagem.

Proxy

Como proxy, atua na camada de aplicação e pode desempenhar diversas funções. O proxy pode ser utilizado como um filtro de protocolos de alto nível, como SMTP e HTTP, pode verificar o conteúdo de emails e páginas Web, além de decidir se o acesso será permitido ou não. Por exemplo, se um email contém palavras que não estejam de acordo com as regras de segurança da empresa, o proxy pode barrar a entrada ou saída de emails que contenham tais palavras. Além disso, pode impedir a entrada de arquivos anexados e verificar a existência de vírus. Um processo semelhante pode ser implementado também no tratamento do conteúdo de páginas Web, impedindo a entrada de páginas que contenham certas palavras, componentes Active X, Applets Java e código JavaScript.

Enquanto os firewalls de rede podem autenticar as conexões utilizando apenas IPs e portas, que podem ser facilmente forjadas (IP spoofing), os proxies permitem implementar diversos mecanismos de autenticação, como login e senha, token e biométrica. Por exemplo, para que os usuários da rede interna possam ter acesso à Internet, eles devem ser autenticados primeiro no proxy.

Por questões de desempenho, o proxy geralmente não implementa o controle em todas as camadas que lhe são permitidas. Na prática, as funções de filtro de pacotes são implementadas


por um firewall preocupado apenas com as camadas de rede e transporte, enquanto o proxy implementa apenas o controle na camada de aplicação.

O proxy também pode funcionar como cache de páginas Web. Quando um usuário realiza um acesso a uma determinada página na Internet, o conteúdo da página é copiado para o proxy e repassado ao usuário. Quando um outro usuário acessar a mesma página, não será preciso buscá-la novamente, pois a página estará localizada no cache do proxy e poderá ser entregue ao cliente sem a necessidade de acesso à Internet. Dependendo da política de atualização de cache do proxy, é possível que os usuários acessem páginas com conteúdo desatualizado.

NAT O NAT (Network Address Translation) geralmente é implementado no roteador que liga a rede interna à Internet e tem duas funções principais: endereçamento e segurança.

Com o crescimento da Internet, a distribuição de endereços IP tornou-se um problema. Como os endereços IP classes A e B estão esgotados, restam apenas endereços classe C, que permitem no máximo 254 hosts por endereço. Para contornar o problema, as empresas passaram a utilizar um endereço inválido na rede interna e um endereço válido para acessar a rede externa.

Quando se implementa o esquema de NAT, os usuários da rede externa desconhecem os endereços da rede interna, não tendo acesso direto às estações. Nesse caso, o dispositivo que implementa o NAT intermedia o acesso da rede externa para a rede interna, escondendo os


endereços internos e aumentando o nível de segurança. O mecanismo de NAT só é possível devido ao esquema de portas que permite mapear vários clientes internos em apenas um endereço de saída.

Criptografia A criptografia permite implementar uma série de atributos indispensáveis para uma comunicação segura em uma rede de computadores, como a Internet. Seguem as implementações permitidas:

• Confidencialidade: é a garantia de que a comunicação entre o transmissor e receptor seja implementada de forma sigilosa, sem o conhecimento de terceiros. Por exemplo, quando utilizamos o Internet Banking, a comunicação entre o cliente e o servidor do banco deve ser feita de forma confidencial;

• Integridade: é a garantia de que a informação trocada entre o transmissor e receptor não será alterada. Por exemplo, quando enviamos um email, nada impede que alguém intercepte a mensagem e altere seu conteúdo;

• Autenticidade: é a garantia de que a pessoa que realizou a operação é de fato aquela que diz ser. Por exemplo, quando recebemos um email de alguém, não temos qualquer garantia de que a mensagem foi enviada pela pessoa que consta no cabeçalho do email, pois essa informação é facilmente forjada;

• Não repúdio: é a possibilidade de provar a terceiros a autoria de uma operação após a mesma ter ocorrido. Por exemplo, quando enviamos um email, a pessoa que recebe a mensagem não tem como provar quem foi a pessoa que o enviou.

A criptografia moderna está baseada no conceito de chaves criptográficas, que consistem em uma seqüência de bits. Existem duas técnicas atualmente utilizadas: chaves simétricas e assimétricas.

Chaves simétricas No esquema de chaves simétricas, também conhecidas como chaves secretas, o transmissor e o receptor devem possuir a mesma chave criptográfica. O transmissor utiliza sua chave para criptografar a mensagem, que pode então ser enviada. O receptor utiliza a mesma chave para descriptografar a mensagem recebida. Caso a mensagem seja interceptada, não será possível ler o seu conteúdo, a não ser que se descubra a chave secreta utilizada.


A criptografia de chave simétrica é muito rápida, mas apresenta dois problemas: a troca e gerência das chaves.

Chaves assimétricas No esquema de chaves assimétricas, também conhecidas como chaves públicas, o transmissor possui um par de chaves e o receptor outro. O par de chaves é formado por uma chave privada e uma pública. A chave privada é de conhecimento apenas do dono do par, enquanto a chave pública é amplamente divulgada e pode ser consultada por qualquer usuário.

Quando o transmissor deseja enviar uma mensagem confidencial, ele utiliza a chave pública do receptor que está disponível na rede. O receptor, ao receber a mensagem, utiliza sua chave privada para abrir a mensagem. Caso alguém intercepte a mensagem, não será possível a sua leitura, pois apenas a chave privada do receptor pode ler uma mensagem criptografada com sua chave pública.

Chaves assimétricas - Criptografia

Além de garantir a confidencialidade e integridade da mensagem, o esquema de chave pública permite também implementar a assinatura digital, garantindo autenticidade da operação. Nesse caso, o transmissor utiliza a sua chave privada para assinar (criptografar) a mensagem e o receptor, por sua vez, utiliza a chave pública do transmissor para abri-la. Caso o receptor consiga abrir a mensagem, está garantida a autenticidade da operação.


Chaves assimétricas - Assinatura digital

É importante perceber que é possível utilizar os dois serviços de forma isolada ou combinada, ou seja, apenas confidencialidade, apenas autenticidade ou os dois serviços simultaneamente.

Autoridades certificadoras As autoridades certificadoras ou CAs (Certification Authorities) são cartórios virtuais onde as chaves públicas ficam armazenadas de forma segura, ou seja, podem ser consultadas mas não alteradas. Verisign, Certisign, Entrust, Serasa, Serpro são apenas alguns exemplos de CA's que atuam no Brasil.

A chave pública fica armazenada em um certificado digital que, além da chave, possui informações da certificadora e do dono da chave pública. Existem diferentes tipos de certificados que podem ser emitidos, como certificados para servidores, email, autoria de software e delegação de autoridade. O padrão X.509v3 é, atualmente, o padrão para certificados digitais e define diversas informações que devem compor um certificado.

Informações sobre a CA

Informações sobre o possuidor da chave pública

Chave pública

Assinatura da CA

Um certificado passa por diversas fases, que se iniciam na sua criação. Os certificados devem ser periodicamente renovados, caso contrário, são revogados.


HTTPS O protocolo HTTP não foi concebido para oferecer segurança, porém, a maioria das operacões em sites de comércio eletrônico utilizam esse protocolo. Para garantir segurança para operações na Web, utiliza-se o HTTP seguro ou HTTPS. O HTTPS é o protocolo HTTP combinado ao protocolo Secure Sockets Layer (SSL).

O SSL trabalha entre os protocolos da camada de aplicação e a camada de transporte (TCP), oferecendo diversos serviços, como criptografia simétrica, assimétrica, certificação digital e hashing. O SSL faz parte do browser e do servidor Web, que utiliza a porta 443 para conexões Web seguras, ao contrário da porta default 80.

Aplicação

SSL

Transporte

Rede

Enlace/Físico


O SSL foi inicialmente desenvolvido pela Netscape e hoje é um padrão para a implementação de segurança na Internet, sendo utilizado por diversas aplicações de comércio eletrônico, como no exemplo de Internet Banking a seguir:

IDS (Intrusion Detection Systems) A função de um sistema de detecção de intrusão (IDS - intrusion-detection system) é automatizar a identificação de ataques e intrusões por hackers. Ainda que o uso de IDS seja cada vez mais comum, também os ataques contra este tipo de sistema também se tornam mais comuns.

Modelos de IDS Um IDS pode ser implantado de duas formas, individualmente ou combinadas:

• baseados no host: são sistemas que se prestam principalmente a monitorar os ataques no nível do próprio computador. Em outras palavras, IDS baseados no host detectam alterações no sistema de arquivos, nos arquivos de log e em aplicativos em cada computador. Normalmente, um servidor de administração central do IDS recebe atualizações de cada host conforme essas mudanças são detectadas.


• baseados na rede: são sistemas que normalmente inspecionam a rede no nível dos pacotes, de forma similar a um sniffer. Isto permite que o IDS monitore todos os dados que trafegam em uma rede e que detecte a atividade de hackers ao comparar esses dados com um conjunto de regras. Desta forma, o IDS não precisa interagir com cada um dos computadores na rede - apenas com aqueles que estão interferindo nos pacotes de dados. Além disso, um IDS baseado na rede pode ter diversos sistemas de log espalhados por toda a rede, monitorando todos os segmentos de forma abrangente

Tipos de IDS Os IDS podem variar desde sistemas corporativos complexos a até aplicativos comuns para o desktop. Independentemente do nível de complexidade, todos os IDS compartilham características de operação comuns. Os tipos de IDSs disponíveis e seus métodos de operação são:

Monitor de arquivos de Log

A forma mais simples de um IDS é o monitor de arquivos de log, que procura detectar intrusões ao analisar os logs de eventos do sistema. Por exemplo, um monitor de arquivo de log básico poderia varrer o log de acesso de um servidor web procurando por requisições /cgi-bin/ específicas. A limitação desta tecnologia reside no fato de só detectar eventos que tenham sido registrados no log - algo que os invasores podem facilmente alterar. Além disso, um sistema desse tipo perderia eventos de baixo nível no sistema, posto que o registro de eventos é uma operação de alto nível na hierarquia dos sistemas operacionais.


Amostra de um log gerado por um script de ataque em cgi-scan

127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/test-cgi HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/nph-test-cgi HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/phf HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/phf.pp HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/phf.cgi HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/websendmail HTTP/1.0" 404 0

Monitor de integridade

Um monitor de integridade acompanha mudanças em estruturas chave do sistema. Por exemplo, um monitor de integridade básico utiliza arquivos do sistema ou chaves no registro como "iscas" para rastrear mudanças efetuadas por um invasor. Ainda que sua funcionalidade seja limitada, monitores de integridade adicionam uma camada extra de proteção a outras formas de detecção de intrusão.

Entre os atributos que podem ser rastreados por um monitor de integridade temos:

- Adição, exclusão e modificação de arquivos

- Mudança nos atributos dos arquivos (ocultos, somente para leitura, arquivo etc.)

- Último acesso ao arquivo

- Última escrita ao arquivo

- Data de criação

- Tamanho do arquivo

- Verificação por Hash

Scanner de assinatura

Da mesma forma que os scanners de vírus tradicionais, a maioria dos IDS tenta detectar os ataques com base em um banco de dados de assinaturas de ataques conhecidas. Quando um hacker tenta um ataque conhecido, o IDS procura por um padrão coincidente em seu banco de dados.

Um exemplo clássico de assinatura detectada por um IDS são os scripts CGI. As ferramentas de um hacker normalmente incluem um scanner CGI que sonda o servidor Web alvo por bugs conhecidos no CGI. Por exemplo, um ataque phf conhecido permite que o atacante recupere qualquer arquivo ao invés do arquivo HTML adequado. Para detectar um ataque phf, o IDS deve vasculhar os pacotes por um pedaço da string:


GET /cgi-bin/phf?

Quando esta string é detectada, o IDS reage de acordo com as instruções pré-programadas. Como se trata de um comando CGI básico, o nível de periculosidade deste ataque é médio, quando muito. Entretanto, se o IDS encontrasse a string:

cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

...e criasse um registro em seu log como:

GET /cgi-bin/phf?Qalias x%0a/bin/cat%20/etc/passwd HTTP/1.0" 200 267

...então o problema seria mais sério e o servidor está vulnerável. Verificando o arquivo de log, é possível observar que a requisição phf foi bem sucedida (código 200), o que significa que o hacker foi capaz de visualizar o conteúdo do arquivo passwd, que contém as senhas do sistema.

Detetores de anomalias

A detecção de anomalias normalmente compreende o estabelecimento de uma curva padrão de atividade da rede ou do sistema e de um aviso quando houver um desvio dessa curva. Posto que o tráfego de rede está constantemente mudando, este tipo de IDS é mais adequado para implementação baseada em host. A detecção de anomalias fornece alta sensibilidade porém baixa especificidade, sendo mais útil em máquinas da rede que sejam absolutamente críticas porém razoavelmente estáticas. Nesta situação, quando um detetor de anomalias indica alguma mudança com relação à curva padrão de atividade, será necessária a intervenção humana para investigar as razões. Assim sendo, esta alta sensibilidade apresenta um alto custo em termos de necessidade de recursos humanos.

Ataques ao IDS

Entender as vulnerabilidades de um IDS e a forma como estas são exploradas é um meio de garantir uma melhor implementação da segurança na rede do cliente.

Fragmentação

Fragmentação é a forma mais comum de ataque contra IDS. Os pacotes são divididos em pedaços menores, o que pode enganar um IDS. Um IDS stateful pode recompor os pacotes fragmentados para a análise porém, conforme aumenta o tráfego, esta operação consome mais recursos e se torna menos precisa. Quando a técnica de fragmentação é utilizada, firewalls e IDS normalmente vêem apenas o pacote parcial, o que não ativa nenhum dos tipos de alarme

Spoofing (fingimento)

É possível forjar (spoof) o número de seqüência do protocolo TCP visto pelo IDS. Por exemplo, enviando um pacote SYN com um número de seqüência forjado após o início da conexão, o IDS pode sair de sincronia com o host. Isto acontece porque o host é capaz


de ignorar o pacote SYN inesperado e incorreto, ao passo que o IDS pode se reconfigurar para seguir o novo número de seqüência. Desta forma, o IDS ignora o fluxo de dados real e fica esperando pacotes com um novo número de seqüência que não existe. Ao enviar um pacote RST com um endereço forjado que corresponde ao SYN forjado pode inclusive fechar esta nova conexão com o IDS.

Tipos de IDS

Mutação do HTTP

Requisições HTTP complexas podem freqüentemente enganar IDS que simplesmente verificam o tráfego Web. Se um IDS está procurando pela vulnerabilidade phf conforme abaixo:

GET /cgi-bin/phf

é possível enganá-lo simplesmente adicionando dados extras à requisição:

GET /cgi-bin/subdirectory/../phf HTTP/1.0

Neste caso, foi solicitado um diretório qualquer e então utilizado o comando /../ para subir para o diretório pai e então executar o script desejado. Esta técnica é chamada de "directory traversal", e é atualmente uma das formas de ataque mais comuns.

O futuro dos IDS A tecnologia para sobrepujar os IDS continua a evoluir. Os fornecedores de IDS devem manter a evolução, preferencialmente estando sempre um passo a frente. Alguns dos avanços futuros são:

IDS incorporado

O protocolo IPSec em breve se tornará o padrão para a segurança da transmissão de dados em rede. A implementação deste padrão permite que pacotes de uma determinada empresa trafeguem por uma infra-estrutura não confiável como a Internet, ao mesmo tempo que previne o roubo, a alteração ou mesmo a falsificação de dados por hackers.

Como o IPSec garante a conexão segura fim-a-fim e realiza a criptografia na camada de rede, este processo se torna transparente para as aplicações que geram o tráfego IP.

Infelizmente para os IDS, o IPSec se torna uma faca de dois gumes: ainda que permita o acesso seguro a redes corporativas através de VPNs, a criptografia dos pacotes impede a ação de IDS que vasculham os dados por ataques maliciosos. Dessa forma, se um hacker conseguir acesso a um cliente remoto, terá um túnel seguro através do qual poderá acessar a rede corporativa.

A forma de prevenir quanto a esta possível brecha de segurança é introduzir IDS em todos as camadas do TCP/IP. Dessa forma, o pacote será analisado conforme é desencapsulado e processado, inclusive nas camadas mais altas.


Detecção estrita de anomalias

Conforme a velocidade e a complexidade dos ataques aumentar, logo será atingida a capacidade dos IDS atuais de lidar com a carga de análise necessária. Uma forma de resolver este dilema consiste na adoção mais ampla de detecção estrita de anomalias. Isso significa que qualquer comportamento fora do normal, não importando quão pequeno, será considerado um alarme positivo e verdadeiro.

Obviamente, para que seja exeqüível, esse método requer que o IDS atue em cada um dos hosts ao invés de na rede como um todo. Dessa forma, é possível traçar uma curva de utilização normal para cada host, que certamente será mais previsível do que a da rede como um todo. Regras específicas de exceção aceitável são configuradas para cada um dos hosts e o IDS monitora o comportamento da mesma forma que o firewall monitora a rede.

Quando uma anomalia for detectada, quer no nível da rede, quer no nível da aplicação, um alerta é enviado para o console central. Este método apresenta uma alta sensibilidade a ataques porém gera uma quantidade significativa de dados.

IDS baseado em host vs. IDS baseado na rede

O uso cada vez mais comum de redes comutadas se torna um empecilho para IDS que realizam a análise passiva de protocolos. Desta forma, a monitoração simultânea de diversos hosts fica mais difícil. Além disso, o uso crescente de tráfego criptografado também prejudica a análise passiva. Desta forma, é possível antever uma tendência de cada vez mais mover o IDS da rede para os próprios hosts.

4.5. Aplicações em banda larga

Voz sobre IP Voz sobre IP (Voice over IP - VoIP) é um serviço que permite conversas telefônicas ou áudio-conferências utilizando uma rede TCP/IP, como a Internet, em tempo real. A grande vantagem em utilizar esse tipo serviço é a convergência de voz e dados e, conseqüentemente, a redução de custo com ligações interurbanas e internacionais que podem ser realizadas pelo custo de uma ligação local.

O primeiro passo para enviar voz por uma rede de pacotes, como a Internet, é converter a voz, que é um sinal analógico, em uma informação digital. Esse processo é implementado por um dispositivo chamado codec, que normalmente utiliza uma técnica conhecida como PCM (Pulse Code Modulation).


A técnica de PCM mostra o sinal analógico periodicamente (a cada 125 ms) e gera uma informação de 8 bits. Os vários bytes gerados são agrupados em uma seqüência que é submetida a um algoritmo de compressão, como ADPCM ou CS-ACELP. O processo de compressão é utilizado para reduzir o tamanho da mensagem a ser enviada e, conseqüentemente, a necessidade de banda.

A seqüência compactada é então encapsulada no protocolo RTP (Real-time Transport Protocol), que, por sua vez, é encapsulado no datagrama UDP e, por fim, no pacote IP. O pacote, ao chegar ao destinatário, é desencapsulado e a seqüência de bytes é descompactada e convertida novamente para um sinal analógico, ou seja, para voz.

Em 1996, o ITU (International Telecommunications Union) ratificou o padrão H.323, que define como áudio e vídeo devem ser transmitidos em uma rede IP. Em 1998, o padrão foi atualizado. O H.323 é na verdade uma família de padrões, sendo vários deles especificações de codecs de áudio (G.711, G.722, G.723, G.728 e G729). A recomendação baseia-se nos protocolos RTP e RTCP para o gerenciamento da conexão.


O grande problema com a transmissão de voz e demais informações multimídia em uma rede de pacotes é a qualidade da transmissão. Em uma rede de pacotes, é possível que os pacotes sofram atrasos para chegar ao destino e que esses atrasos sejam variáveis (jitter). Além disso, é possível que alguns pacotes sejam perdidos e nunca cheguem. Algumas aplicações, como o correio eletrônico, são pouco afetadas por esses problemas, mas aplicações de áudio e vídeo podem ser seriamente comprometidas.

Video-conferência Vídeo-conferência é um serviço que permite a transmissão de vídeo e áudio entre dois ou mais pontos em tempo real, utilizando câmeras, monitores, microfones e auto-falantes. Existem inúmeras aplicações para serviços de vídeo-conferência, como reuniões, ensino à distância, telemedicina, home office, aplicações jurídicas, laboratórios virtuais e segurança. A vídeo-conferência reduz principalmente custos, como, por exemplo, o deslocamento e possível estadia dos envolvidos nos encontros.

O número de participantes de uma vídeo-conferência pode variar. Na figura 1, temos um exemplo de uma vídeo-conferência bidirecional entre duas pessoas apenas. Na figura 2, temos uma conferência entre diversos participantes de ambos os lados. É possível termos também apenas uma única pessoa em um dos lados da transmissão. No caso de conferências com vários participantes em diversos pontos, utiliza-se a técnica de MCU (Multi-point Conferencing Unit) ou multi-casting.


A vídeo-conferência com linhas privadas é um serviço bastante difundido. No entanto, o grande desafio é implementá-lo utilizando uma rede de pacotes. Em uma rede de pacotes, como já abordamos em VoIP, existem problemas de latência na entrega, jitter e perda de pacotes.

A especificação H.323 também é utilizada como padrão para a transmissão de vídeo-conferência em redes TCP/IP. O H.323, além de definir diversos codecs para áudio, ofecere várias opções de codificadores para vídeo, que permitem transformar as imagens (sinal analógico) em informação digital. O padrão também define os conceitos de gatekeepers, gateways e MCUs.

Um gatekeeper H.323 controla os dispositivos envolvidos em uma vídeo-conferência e os serviços oferecidos, como endereçamento, controle de admissão, gerência de banda, sinalização etc. Gateways são responsáveis por conectar sistemas de vídeo-conferência que utilizem padrões incompatíveis, como H.320 (ISDN) e H.321 (ATM).

Streaming O áudio e vídeo-conferência são realizados em tempo real. Streaming consiste na possibilidade de armazenar áudio e vídeo em servidores para, posteriormente, serem transmitidos. Por exemplo, uma vídeo-conferência pode ser gravada e armazenada para depois ser reapresentada. O vídeo-streaming pode ser amplamente utilizado para ensino à distância, permitindo que os alunos possam assistir ou rever uma determinada aula sempre que desejarem.

Uma das características mais importantes em aplicações que utilizam streaming é a possibilidade de a apresentação ser iniciada antes mesmo do término da transmissão. Por exemplo, quando um usuário solicita um vídeo, o servidor envia apenas uma pequena seqüência (stream) do vídeo compactado. Recebido o primeiro stream, o vídeo pode ser descompactado, enquando um segundo stream está sendo recebido. Após a descompactação, o primeiro stream pode, então, ser exibido, enquanto o segundo é descompactado e o terceiro recebido. Quando implementado adequadamente, o streaming permite criar um fluxo contínuo de apresentação, mesmo que a transmissão não seja contínua.


Protocolo RTSP O protocolo RTSP (Real-Time Streaming Protocol) permite a apresentação de conteúdo multimídia em redes IP, utilizando o conceito de streaming. O protocolo tem como principal função estabelecer e controlar a exibição de áudio e vídeo streaming entre servidores de multimídia e clientes. O RTSP permite implementar funções semelhantes a de um vídeo cassete ou CD, como iniciar e finalizar a transmissão, gravação, pausa e avanço rápido, funcionando como um "controle remoto". Suas principais funções são:

- Permitir ao cliente obter apresentações multimídia de algum servidor de mídia;

- Permitir a criação e gravação de conferência com vários participantes;

- Permitir a inserção de novas mídias em apresentações em tempo real.

O RTSP é implementado na camada de aplicação e utiliza em geral o protocolo RTP (Real-Time Protocol), que por sua vez pode utilizar como transporte o TCP ou UDP. A sintaxe e operação do RTSP são muito parecidas com as do protocolo HTTP/1.1, como pode ser observado no exemplo abaixo, onde uma URL RTSP é especificada:

rtsp://media.example.com:554/twister/audiotrack

Apesar das inúmeras semelhanças, os protocolos RTSP e HTTP guardam certas diferenças. Por exemplo, enquando o HTTP não guarda o estado da conexão (stateless), o RTSP a mantém. Enquanto no HTTP apenas o cliente realiza solicitações, no RTSP tanto o cliente quanto o servidor podem realizar solicitações.

Uma mensagem de solicitação RTSP é formada por um método, pela URL que se deseja acessar e pela versão do protocolo que está sendo utilizada pelo cliente.


Solicitação = <Método> <URL> <Versão do RTSP>

Os métodos mais importantes são:

Método Descrição

OPTIONS Permite que clientes e servidores troquem informações sobre as opções que podem ser aceitas.

SETUP Permite inicializar uma conexão RTSP.

PLAY Permite começar a transmissão, inicializada pelo SETUP.

PAUSE Permite parar a transmissão, sem liberar os recursos alocados.

TEARDOWN Permite encerrar uma transmissão liberando os recursos alocados.

RECORD Permite gravar uma transmissão.

4.5. Serviços de Gerenciamento

SNMP O protocolo SNMP (Simple Network Management Protocol) permite o gerenciamento remoto de dispositivos em rede, como roteadores, switches, servidores e impressoras. A partir desse protocolo, é possível monitorar e gerenciar remotamente os diversos dispositivos, simplificando o trabalho de administração da rede.

Para que um dispositivo possa ser gerenciado remotamente, é necessário que o dispositivo suporte o protocolo SNMP, ou seja, execute um processo específico para essa função, conhecido como agente. O agente tem a função de receber e processar comandos remotos, além de armazenar localmente as informações relacionadas ao dispositivo.

Os agentes dos dispositivos comunicam-se com uma ou mais estações de gerenciamento, que enviam comandos para os agentes e recebem as respectivas respostas. Uma estação de gerenciamento é, geralmente, uma máquina dedicada para essa tarefa que processa um software de gerência de rede, como o HP OpenView, IBM Tivoli NetView ou CA Unicenter.

O protocolo SNMP faz a ligação entre a estação de gerenciamento e os vários agentes, permitindo que a estação faça uma consulta ao agente, ele processe o pedido e retorne uma resposta. É possível


também que o agente comunique determinados eventos sem a solicitação da estação de gerenciamento.

Cada dispositivo mantém uma base de dados local, onde são armazenadas as variáveis que descrevem o estado atual do dispositivo e histórico previamente armazenado.

A base de dados onde são armazenadas as variáveis correspondentes ao dispositivo se chama MIB (management information base). Como diferentes serviços de gerenciamento de rede são utilizados para diferentes tipos de dispositivos e protocolos, cada serviço terá o seu próprio conjunto de variáveis (também chamadas objetos).

As mensagens de requisição que o agente pode receber da estação de gerenciamento podem ser dos seguintes tipos:

• Get: O comando Get solicita uma determinada informação do agente sobre o dispositivo que representa.

• Set: O comando Set modifica o valor de uma determinada informação no agente

• GetNext: Similar ao comando Get, o comando GetNext traz o próximo valor na ordem léxica da MIB. É útil para os casos onde o tamanho da tabela é desconhecido.

• GetBulkj: Similar ao comando Get, o comando GetBulk traz todos os valores da MIB do agente em particular.

Ao receber qualquer uma dessas requisições, o agente executará a função específica: localizar o valor de um determinado objeto e enviá-lo à estação de gerenciamento ou ajustar o valor do objeto conforme solicitado.

Além disso, o agente pode enviar à estação de gerenciamento uma mensagem de Trap quando um evento significativo ocorrer com o dispositivo que representa.


Uma mensagem de Trap pode ser enviada quando:

- uma porta ou módulo é ativado ou desativado

- limites de temperatura são ultrapassados

- há mudanças na topologia da rede e ocorrem falhas na autenticação

- ocorre um problema com a fonte de alimentação


5. SLA - Service Level Agreement (Acordo de Nível de Serviço)

5.1. O que é SLA? Um acordo de nível de serviço (SLA) é um contrato formal negociado entre o fornecedor de serviços de rede e o cliente, idealizado para definir um entendimento comum sobre a definição de qualidade do serviço, das responsabilidades, prioridades etc. Ele especifica os serviços a serem fornecidos e a qualidade. Na Embratel, este contrato é denominado Garantia de Desempenho.

Um SLA pode cobrir os mais diversos aspectos do relacionamento entre o fornecedor e o cliente, tais como desempenho dos serviços, atendimento ao cliente, cobrança e provisionamento de serviços. Entretanto, é preciso sempre ter em mente que a concordância quanto ao nível de serviços prestados é o propósito primordial de um SLA.


5.2. A cadeia de valor Sempre que falamos em cliente, nos referimos a quem solicita e recebe o serviço. O fornecedor, por sua vez, é quem entrega o serviço. Dessa forma, é possível que uma determinada entidade dentro de uma cadeia de valor do fornecimento de serviço seja tanto fornecedor quanto cliente. Nesse caso, teremos tantos SLAs quantos forem os pares fornecedores-clientes.

Um ponto que deve ser definido no SLA é sobre quem detém a responsabilidade de serviços terceirizados. O nível de serviço de diversos fornecedores pode estar sob a gerência de um único fornecedor de valor agregado, caso assim seja acordado.

5.3. Métricas "Métrica é uma forma de medida do desempenho ou

eficiência de alguma característica de um serviço ou atividade."

Ao estabelecermos o SLA, é preciso definir não apenas quais tipos de serviços serão prestados mas também as métricas que serão utilizadas para mensurar a sua qualidade, bem como o índice mínimo de qualidade que deve ser entregue ao cliente.

Alguns exemplos de métricas que podem ser incluídas em um SLA são:

- Percentual de tempo da disponibilidade da rede

- Percentual de tempo da disponibilidade do serviço

- Latência da rede

- Número de usuários que podem ser atendidos simultaneamente

- Padrões de desempenho com os quais os serviços serão comparados periodicamente

- Antecedência de avisos sobre modificações na rede que possam afetar os usuários


- Tempo de resposta do "help desk" para diversas classes de problemas, tanto de reparo quanto de reação

- Estatísticas de uso que serão fornecidas

5.4. SLA na Embratel

As métricas da Embratel A Embratel oferece, em seu contrato de Garantia de Desempenho, três métricas para a mensuração do nível de serviço:

• Latência média mensal da rede: É o tempo que um pacote IP leva para ir e voltar (round-trip) de um ponto a outro da rede. É normalmente medida em milissegundos. Quanto menor a latência, melhor o tempo de resposta da rede.

• Perda média mensal de pacotes da rede: É o índice que mede a taxa de sucesso na transmissão de pacotes IP entre dois pontos da rede. É normalmente exibida como uma porcentagem, indicando o percentual de pacotes perdidos. Quanto menor a perda de pacotes, maior a eficiência da rede.

• Disponibilidade média do núcleo da rede: É o índice que mede o tempo que uma rede esteve operacional para transmissão e recepção de pacotes IP. É normalmente registrada como uma porcentagem, indicando o percentual de tempo em que a rede esteve no ar. Quanto maior a disponibilidade, maior a confiabilidade da rede.

O cálculo das métricas Como são calculadas cada uma das três métricas utilizadas na mensuração do nível de serviço:

• Latência média mensal da rede: A cada dia do mês, durante todos os dias, são tomadas 1440 medidas de latência entre o Centro de Gerência da Rede Internet e todos os Centros de Roteamento da Rede Internet Via Embratel. Essas medidas comporão uma média horária a cada 60 minutos. A média diária será calculada em função das médias horárias a cada 24 horas e a média mensal será a média aritmética das médias diárias do mês. Links de satélite não entram nessa medição!

• Perda média mensal de pacotes da rede: A cada dia do mês, durante todos os dias, são tomadas 1440 medidas de perda de pacotes entre o Centro de Gerência da Rede Internet e todos os Centros de Roteamento da Rede Internet Via Embratel. Essas medidas comporão uma média horária a cada 60 minutos. A média diária será calculada em função das médias horárias a cada 24 horas e a média mensal será a média aritmética das médias diárias do mês.


• Disponibilidade média do núcleo da rede: Todos os dias, para o Business Link Direct, são tomadas 1440 medidas de disponibilidade do Roteador de Acesso da Rede Internet Via Embratel ao qual a porta do Cliente está especificamente conectada. No caso do Business Link Flex e Business Link On Demand, a referência a ser considerada é a média do conjunto de roteadores do Backbone. Essas medidas comporão uma média horária a cada 60 minutos. A média diária será calculada em função das médias horárias a cada 24 horas e a média mensal será a média aritmética das médias diárias do mês.

Avaliação do desempenho O acordo especificado na Garantia de Desempenho da Embratel define os seguintes índice:

Latência média mensal da rede não pode ultrapassar 75 ms

Perda média mensal de pacotes da rede menor que 1%

Disponibilidade média do núcleo da rede maior ou igual a 99,7%

5.5. SLA, QoS e GoS O acordo de nível do serviço (SLA), a qualidade do serviço (QoS) e o grau do serviço (GoS) estão intimamente relacionados. O SLA pretende alinhar as seguintes expectativas em relação ao serviço:

- Fornecedor: qualidade que espera estar fornecendo

- Cliente: qualidade que espera estar recebendo

O grau do serviço consiste justamente nas expectativas alinhadas, no conjunto de métricas que se pretende alcançar, ao passo que a qualidade do serviço é justamente o desempenho real do serviço oferecido, medido através da utilização do mesmo conjunto de métricas.

Para saber mais sobre acordos de nível de serviço, sugerimos a leitura do SLA Management Handbook, redigido pelo TeleManagement Forum.

Curso de TCPIP Avançado v.2

Documents

Transcript of Curso de TCPIP Avançado v.2