Iracema Suassuna de Oliveira

 

 

Virtual Private Networks

 

 

 

Trabalho de avaliação apresentado na disciplina de Comunicação de Dados do Curso de Mestrado em Telecomunicações da Universidade Federal do Paraná.

 

Prof. Eduardo Parente

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Curitiba – PR

Outubro 2001

SUMÁRIO

 

INTRODUÇÃO

1.     OS ELEMENTOS ESSENCIAIS DE UMA VPN

1.1      Tunelamento

1.2   Criptografia

1.3   Autenticação

2.     COMO UMA VPN FUNCIONA

3.     OS PROTOCOLOS DE UMA VPN

4.     OS CONTRATOS DE SLA

5.     O PROTOCOLO IPSec

5.1.  ASSOCIAÇÕES DE SEGURANÇA (SA - Security Association)

5.2.  AS TOPOLOGIAS IPSec EM USO

5.3.  ALGORITMOS DE AUTENTICAÇÃO E ENCRIPTAÇÃO PARA O IPSec

5.3.1.           Autenticação

5.3.2.           Encriptação

5.3.3.           Tunelamento

5.4.  AUTENTICATION HEADER (AH)

5.4.1.           O formato de cabeçalho AH

5.4.2.           Modos de uso do AH

5.4.3.           Considerações do AH para o IPv6

5.5.  ENCAPSULATING SECURITY PAYLOAD (ESP)

5.5.1.           Formato do Pacote ESP

5.5.2.           Modos de Uso do ESP

5.5.3.           Considerações do ESP para o IPv6

5.6.  THE INTERNET KEY EXCHANGE PROTOCOL (IKE)

5.6.1.           Identificadores Permanentes

5.6.2.           Inicializando as AS com o IKE

6.     CONSIDERAÇÕES NA ESCOLHA DE UMA VPN

7.     AS RFCs E OS RASCUNHOS DE INTERNET

CONCLUSÃO

REFERÊNCIAS BIBLIOGRÁFICAS

ANEXO 1 – RFCs (Requests for Comments)

ANEXO 2 – I-D (Internet Drafts)

GLOSSÁRIO

 

Introdução

 

A porcentagem de pessoas que dependem de acesso remoto para realizar seus trabalhos está continuamente em crescimento. Esta força de trabalho móvel demanda acesso freqüente a volumes de informações corporativas. Além disso, a explosão do e-commerce significa que as companhias estão implementando aplicações de negócios que compartilham informações entre redes privativas fisicamente distantes, estendendo o alcance de seus negócios a parceiros, contratantes e fornecedores. Uma das soluções em voga neste cenário são as Virtual Private Networks ou simplesmente VPNs.

Em sua definição mais comum, uma VPN permite uma rede privada ser interligada a outra rede privada (ou a um terminal remoto) através de uma rede acessada publicamente. Desta forma, as VPNs são similares às Wide Area Networks (WAN) porém, no lugar de utilizarem linhas privadas alugadas, as VPNs estão capacitadas a dispor das redes públicas (como a Internet, por exemplo) e oferecer as mesmas características de segurança que as redes privadas, além de levar vantagem na economia de escala e a acessibilidade remota abrangente das redes públicas.

As VPNs podem ser estabelecidas por uma variedades de meios, e podem ser construídas sobre tecnologias ATM, Frame Relay, X.25 ou IP. O método mais popular são as VPNs baseadas em IP (ou IP-VPNs) – enfoque principal deste trabalho - as quais oferecem maior flexibilidade e fácil conectividade. Considerando que a maior parte das redes corporativas usam tecnologias IP ou Web, as IP-VPNs podem de forma mais transparente estender suas capacidades sobre a rede mundialmente. Um enlace IP-VPN pode ser estabelecido entre dois pontos em qualquer lugar do mundo, e a rede IP automaticamente manipulará o roteamento do tráfego. Contudo, privacidade e proteção de dados é de supra importância quando emprega-se serviços sobre uma rede pública como a Internet, a qual é vulnerável a ataques ou entradas ilegais. Para isto as VPNs são asseguradas por mecanismos de encriptação e autenticação.

Figura 1 – A arquitetura VPN.

 

Os produtos VPNs estão classificados em três grandes categorias:

 

·        Sistemas baseados em hardware: A maior parte de VPNs baseadas em hardwares são roteadores de encriptação, os quais são considerados seguros em simples de usar uma vez que são a coisa disponível mais próxima de um equipamento "plug-and-play". Entretanto, eles podem não ser flexíveis como um sistema baseados em software.

·        Sistemas baseados em Software (firewall): os quais são ideal em situações onde ambas as extremidades da VPN não são controladas por uma mesma organização, o que é típico entre parceiros de negócios ou quando suporte ao cliente é requerido. VPNs baseadas em firewall são consideradas entre as mais seguras visto que elas tiram vantagens dos mecanismos de segurança dos firewalls existentes.

·        Pacotes de aplicações standalone: para usuários remotos.

 

Hoje, as VPNs estão sendo usadas para ajudar corporações a compartilhar com segurança aplicações da empresas, manter parcerias de negócios e fornecedores, prover aplicações emergentes tais como voice over IP (VoIP) e network-hosted e dar suporte à explosão do e-commerce, especialmente nas aplicações business-to-business (B2B).

 

1.         OS ELEMENTOS ESSENCIAIS DE UMA VPN

 

            Tecnicamente, a VPN é uma combinação avançada de tunelamento, encriptação, autenticação e tecnologias de controle de acessos e serviços usados para carregar tráfego sobre a Internet, uma rede IP gerenciada ou um backbone de provedor. O funcionamento de uma VPN depende basicamente de três elementos:

 

·        Tunelamento (ou encapsulamento de pacote): é o método de englobar um pacote em um novo pela adição de um cabeçalho. O pacote original inteiro torna-se o payload do novo pacote.

·        Criptografia ou Encriptação: é um criptosistema cuja função é misturar seus dados em uma texto cifrado o qual é então decriptado na outra ponta para que possa ser lido.

·        Autenticação: é usada para verificar a validade da identidade dos usuários e restringir o acesso à rede apenas aos usuários autorizados.

 

1.1       Tunelamento

 

O tunelamento ou encapsulamento é uma técnica comum nas redes de comutação de pacotes. Ele consiste em incorporar um pacote em um novo. Isto é, um novo endereçamento (header) é anexado ao pacote original. O pacote original inteiro torna-se o bloco de informação (payload) do novo pacote como mostra a figura abaixo. O tunelamento em geral é usado para carregar o tráfego de um protocolo sobre uma rede que não suporta aquele protocolo diretamente. Por exemplo, o NetBIOS ou o IPX pode ser encapsulado no IP para carregá-lo sobre um enlace WAN TCP/IP.

 

 

Figure 2 - Exemplo de tunelamento

 

 

Figura 3 – Representação dos tunelamentos VPN sobre a rede pública, neste caso, a Internet.

 

1.2       Criptografia

 

A maior parte das VPNs modernas usam algum tipo de criptosistema que mistura os dados a serem transmitidos em um texto cifrado que será decriptado na ponta receptora da rede para que possa ser lido. A encriptação de dados e senhas ajuda a assegurar que clientes não autorizados não tenham acesso aos dados privados transportados sobre a rede pública. Os tipos de encriptação disponíveis são muito variados, entretanto, existem dois tipos básicos de criptografia:

 

·        Simétrica: é mais rápida de se implantar e é comumente usada para a troca de pacotes de dados grandes entre duas partes que se conhecem uma a outra e usam a mesma chave privada de acesso aos dados.

 

·        Assimétrica: são muito mais complexas e exigem um par de chaves relacionadas matematicamente – uma pública e outra privada – para permitir o acesso. O processo de encriptação que codifica dados para a transmissão utiliza um algoritmo especial junto com a chave e então os dados não podem ser lidos por qualquer um que não tenha a chave apropriada para decifrá-lo. Este método é freqüentemente usado para pacotes de dados menores e sigilosos ou durante um processo de autenticação.

 

Como uma regra geral, quanto maior é uma chave de encriptação mais forte ela é (mais resistente). O comprimento em bytes de um algoritmo determina o montante de esforço necessário para quebrar um sistema usando um ataque de "força bruta" no qual computadores são combinados para calcular todas as possibilidades de chave.

A maior parte dos dispositivos VPNs, sejam baseados em hardware ou software, usam algum tipo de esquema de encriptação e, naturalmente, variam no custo de acordo com a “resistência” do algoritmo a ataques de hackers. Também, é importante ressaltar que a resistência de um algoritmo de encriptação é inversamente proporcional à taxa de transmissão dos dados na rede, ou seja, uma forte encriptação implica numa queda nas velocidades de transmissão.

Alguns produtos também têm características de encriptação seletiva permitindo ao administrador decidir pela encriptação de apenas parte do tráfego de dados baseados em sua importância e sigilo. A combinação seletiva de encriptação e controle de acesso permite ao usuário criar uma sessão encriptada específica para a aplicação VPN, garantindo a segurança dos dados tão bem quanto a segurança da rede.

 

Abaixo, estão listados alguns algoritmos de encriptação presentes no mercado:

 

 

1.3       Autenticação

 

A autenticação é usada para verificar a validade da identidade dos usuários e restringir o acesso à rede apenas aos usuários autorizados. Para autenticação de usuário, diferentes implementações oferecem uma variedade de métodos de autenticação, incluindo segredo compartilhado, token cards e certificados digitais. Segredo compartilhado é mais fácil para usar para um pequeno número de pontas (clientes e/ou gateways). Token card funciona muito bem para implementações de Intranet, mas, para uma implementação de extranet o método mais fácil é usar um certificado digital (infraestrutura de chave pública).

Todas as VPNs requerem que um dispositivo de acesso seja configurado para reconhecer e autenticar usuários remotos. Um grande número de técnicas e produtos, ambos baseados em hardware e software estão disponíveis.

 

2.         COMO UMA VPN FUNCIONA

 

A conexão física de um equipamento (ou subrede) à rede pública que transportará o tráfego de informação via VPN pode ser qualquer combinação de tecnologias de acesso incluindo T1 (1,5Mbps)/E1 (2Mbps), Frame Relay, ADSL, ISDN, ATM ou um simples acesso discado (Dial-up).

A explicação que segue é extremamente simplificada mas demostra os passos principais de uma comunicação VPN (maiores detalhes serão vistos em tópicos à frente). A seqüência para o funcionamento de uma VPN é:

 

1 - No modelo VPN, os pacotes originados no Host A de uma subrede alcançarão um dispositivo inicial do túnel denominado de gateway habilitado para VPN (um roteador, um firewal, um switch, etc).

2 – Há a criação do túnel entre os gateways das redes a serem interligadas, isto é, o protocolo de rede (IPX, NetBEUI, AppleTalk, IP e outros) é encapsulado dentro de um protocolo de tunelamento, tipicamente o IP, mas poderia ser também ATM ou Frame Relay.

3 - O túnel iniciador (gateway pertencente à rede do Host A) comunica-se com o Host B da outra subrede (Host terminador que irá receptar os dados) para concordar com um esquema de encriptação e de autenticação.

4 - O túnel iniciador então encripta os pacotes de acordo com os protocolos de encriptação e autenticação combinados.

5 – Os dados são enviados pela rede pública.

6 – Na outra ponta, o gateway (túnel terminador) desencripta os pacotes recebidos e entrega-os para a destinação apropriada na rede, neste caso o Host B.

 

3.         OS PROTOCOLOS DE UMA VPN

 

Segundo a VPNC (Virtual Private Network Consortium) [4], existem três protocolos para VPNs mais usados, a saber:

 

·        PPTP (Point-to-Point Tunneling Protocol): protocolo proprietário implementado por muitas companhias, mais notadamente a Microsoft.

·        L2TP (Layer 2 Tunneling Protocol): o qual qual combina PPTP da Microsof com o Layer-2 Forwarding (L2F) da Cisco Systems.

·        Ipsec (Internet Protocol Security): desenvolvido pelo Internet Engineering Task Force (IETF)

 

Atualmente, dentre estes três principais protocolos, dois são os mais utilizados: o L2Tp e o IPSec. Enquanto o L2TP é tipicamente utilizado pelos SPs (Service Providers) para prover acesso VPN dial-up remoto para clientes, o IPSec é o protocolo de tunelamento mais usado por empresas, Contudo, o IPSec tem apresentado uma tendência em dominar o mercado em função de ser um protocolo padronizado e compatível com a maior parte dos diferentes hardwares e softwares presentes no mercado.

O L2TP (Layer 2 Tunnelling Protocol) é um protocolo de rede (camada 2) é uma combinação do Layer-2 Forwarding (L2F) da Cisco Systems e o Point-to-Point Tunneling Protocol (PPTP) da Microsoft. Ele encapsula qualquer protocolo roteado, incluindo o IP (Internet Protocol), IPX, e AppleTalk para ser enviado sobre protocolos de redes WANs tais como Frame Relay, ATM (Asynchronous Transfer Mode), X.25 e SONET/SDH. Por causa do uso do PPTP da Microsoft no L2TP, ele está incluído como parte das características de acesso remoto da maior parte dos produtos Windows. O benefício do acesso remoto via L2TP é que ele usa PPP para o encapsulamento e não requer instalação de conjunto extra no cliente remoto.

O protocolo IPSec (Internet Protocol Security) foi definido por uma ampla quantidade de padrões e recomendações pelo Internet Engineering Task Force (IETF). Sendo um protocolo de camada 3 é um padrão projetado como um mecanismo fim-a-fim para garantir a segurança dos dados em comunicações baseadas em IP. O IPSec permite payloads de IP serem encriptados e encapsulados em uma cabeçalho IP para uma segura transferência através da Internet. Desde a introdução do IPSec, a proteção de dados na VPN tem se tornado mais padronizada entre os provedores de serviços. O IPSec tem se tornado um padrão de indústria “de fato” para uma infraestrutura VPN baseada em IP. A mais atual definição do padrão IP conhecida como Ipv6 já tem o IPSec incorporado. Devido à sua importância mercadológica atual, este trabalho sobre VPNs irá detalhar o funcionamento apenas do protocolo IPSEc.

 

4.         OS CONTRATOS DE SLA (Serviçe Level Agreement)

 

Mesmo com boas políticas de segurança definidas, a operação de uma VPN sobre uma rede IP nem sempre oferece um transporte garantido e seguro. Se a garantia de serviço não for exigida, a Internet provê o transporte adequado, entretanto, se a garantia de serviço for obrigatória, um acordo de nível de serviço denominado SLA ou Serviçe Level Agreement deve ser estabelecido para o transporte VPN sobre a rede IP gerenciada.

Os contratos de Service Level Agreements são garantias de desempenho mínimo - confiabilidade e disponibilidade - da rede VPN especificado tais como uptime, atraso na rede, perda de pacotes, interoperabilidade, MTTR e segurança.

Apesar dos SLAs, eles não são garantia de tranqüilidade para os usuários VPN. Um dos maiores problemas dos SLAs VPN é que eles se aplicam apenas à rede do SP (Serviçe Provider) específico no contrato não havendo assim garantia quando há o envolvimento de redes VPNs de outros SPs na comunicação. Algumas companhias têm trabalhado com "SLAs estendidos" com múltipla cooperação entre os SPs, contudo, eles raramente funcionam.

 

5.         O PROTOCOLO IPSec

 

Baseado nos padrões desenvolvidos pelo Internet Engineering Task Force (IETF), o IPSec é uma arquitetura aberta que implementa encriptação e autenticação na camada de rede provendo solução de segurança (confidencialidade, integridade e autenticidade) fim-a-fim na própria arquitetura de rede, sobre redes IP. Os controles de encriptação e autenticação podem ser implementados nos vários níveis da infraestrutura de computação como mostrado na figura abaixo

Figure 4 - Localização de implementação de encriptação.

 

A maior parte das VPNs usam tecnologias IPSec. O IPSec é útil porque é compatível com a maior parte dos diferentes hardwares e softwares para VPNs e é o mais popular para redes com acesso remoto de clientes. O IPSec requer pouco conhecimento para os clientes porque a autenticação não é baseada em usuário o que significa que um token (tal como um Secure ID ou um Crypto Card) não é usado. Ao invés disto, a segurança vem de um endereço IP de uma estação de trabalho ou seu certificado, estabelecendo a identidade do usuário e assegurando a integridade da rede.

Dependendo da solução adotada, é possível controlar o tipo de tráfego enviado sobre a solução VPN. Muitos dispositivos permitem que o administrador defina filtros baseados em grupos os quais controlam os endereços IP e os serviços de protocolo e portas permitidos através do túnel. A VPN baseada em IPSec também permite ao administrador definir uma lista específica de redes e aplicações para o qual o tráfego pode fluir.

            Nas redes VPN-IP com IPSec, as pontas do sistema e as aplicações não precisam qualquer modificação para oferecerem segurança. Considerando que os pacotes encriptados são similares a pacotes IP comuns, eles são facilmente roteados através da rede IP ou Internet, sem qualquer modificação nos equipamentos intermediários da rede. Os únicos dispositivos que precisam de mecanismos de encriptação são os das extremidades. Esta característica reduz consideravelmente os custos tanto de implementação quanto de gerenciamento.

Existem três funcionalidades do IPSEc separadas em três protocolos, cada um representando um novo conjunto de cabeçalhos a serem adicionados aos datagramas IP. Estes novos cabeçalhos são colocados após o cabeçalho IP e depois do protocolo de nível 4 (tipicamente o Transmission Control Protocol [TCP] ou o User Datagram Protocol [UDP]). Estes novos cabeçalhos (protocolos) provêem a informação para a segurança do bloco de informação (payload) do pacote IP como segue:

 

·        AH – Authentication Header: este cabeçalho, quando adicionado em um datagrama IP, assegura a integridade e a autenticidade dos dados, incluindo os campos invariantes no cabeçalho IP externo. Ele não provê proteção da confidencialidade. O AH usa uma função “keyed-hash” ao invés de assinaturas digitais, porque a tecnologia de assinatura digital é muito lenta e reduziria enormemente o throughput da rede.

·        Encapsulating security payload (ESP)—Este cabeçalho, quando adicionado em um datagrama IP, protege a confidencialidade, integridade e autenticidade dos dados. Se o ESP é usado para validar a integridade dos dados, ele não inclui os campos invariantes no cabeçalho IP.

·        IKE – Internet Key Exchange: negocia uma Associação de Segurança (AS - Security Association) e troca o material das chaves entre duas entidades. Não é necessário usar a IKE mas associações de segurança manualmente configuradas é um processo manual intensivo e difícil. A IKE deveria ser usada na maior parte das aplicações do mundo real para habilitar comunicações seguras em larga escala.

 

O AH e o ESP podem ser usados independentemente ou juntos, contudo para a maior parte das aplicações apenas um deles é suficiente. Para ambos estes protocolos, o IPSec não define algoritmos de segurança específicos para usar, mas preferivelmente, provêem um quadro aberto para a implementação de algoritmos industriais padrões. Inicialmente, a maior parte das implementações do IPSec suportam o MD5 do RSA Data Security ou o Secure Hash Algorithm (SHA) para a integridade e autenticação. O Data Encryption Standard (DES) é correntemente o mais comumente oferecido algoritmo de encriptação bulk, entretanto os RFCs são os disponíveis que definem como usar muitas outros sistemas de encriptação, incluindo o IDEA, o Blowfish, e o RC4.

O IPSec pode utilizar qualquer algoritmo de encriptação para proteger os dados e qualquer algoritmo para conferir a mensagem para a autenticação dos dados. Entretanto, para a interoperabilidade existe um conjunto padrão de operações criptográficas. Ambos, o AH e ESP, suportam o modo tunelamento. O modo tunelamento também permite a aninhamento (nesting) dos protocolos IPSec. Um uso comum é, por exemplo, proteger um pacote IP com ESP e tunelar o resultado dentro do AH em modo túnel.

Com roteadores de acesso com IPSec habilitado, um provedor pode implementar túneis VPN para seus clientes. Entretanto, para isto o provedor têm que manter uma quantidade significante de configurações nas extremidades dos túneis (também chamados de gateways de segurança).

 

5.1.      Associações de Segurança (SA - Security Association)

 

O IPSec provê muitas opções para a performance de encriptação e autenticação da rede. Cada conexão IPSec pode prover encriptação e/ou integridade. Quando um serviço de seguridade é determinado, os dois nós de comunicação devem determinar exatamente qual o algoritmo a usar. Por exemplo, DES ou IDEA para encriptação; MD5 ou SHA para integridade. Depois de decidir os algoritmos, os dois dispositivos devem trocar chaves de sessão. As Security Associations (Associações de Segurança) – ou simplesmente SA - é o método que o IPSec usa para trilhar todos os particulares concernentes a uma dada sessão de comunicação IPSec. As Security Associations (SA) é um relacionamento entre duas ou mais entidades que descrevem como as entidades usarão os serviços de segurança para comunicarem-se seguramente. A nomenclatura leva a uma pequena confusão às vezes, porque as SAs são usadas mais para outras coisas do que apenas para o IPSec. Por exemplo, as IKE SAs descrevem os parâmetros de segurança entre dois dispositivos IKE.

A SA é unidirecional significando que para cada par do sistema de comunicação existe ao menos duas conexões de segurança—uma de A para B e uma de B para A. A SA é unicamente identificada por um número único randomicamente escolhido denominado de Security Parameter Index (SPI) e o endereço IP de destino. Quando um sistema envia um pacote que requer proteção IPSec, ele consulta a SA em seu banco de dados, aplica o processamento específicado e então insere o SPI da Security Association no cabeçalho IPSec. Quando o par IPSec recebe o pacote, ele consulta a SA em seu banco de dados pela destinação do endereço e SPI e, então, processa o pacote como requerido. Em resumo, a SA é simplesmente uma condição de política de segurança negociada entre dois dispositivos.

 

5.2.      As Topologias IPSec em uso

 

            No IPv4, correntemente mais usado, o IPSec suporta duas diferentes topologias:

 

·        Implementação no cliente: Esta implementação também é denominada de como “Bump In The Stack” ou BITS porque é inserida entre o IP stack (pilha) e os drivers (dispositivos) locais de rede. Uma vez que o código de acesso à fonte na pilha IP não é requerido, esta implementação é apropriada para sistemas legados. Ela pode ser instalada em sistemas operacionais Windows 95/98/NT, Macintosh e Unix. O Windows 2000 tem a implementação do IPSec incorporado e aplica-se a acesso remoto ou para fornecimento de uma rede segura dentro de uma LAN como, por exemplo, um departamento financeiro cujo pessoal encontra-se em pontos de trabalho espalhados pela rede da empresa mas que exige uma comunicação segura para aplicações cliente-servidor. Neste caso, seria implementado um BITS em cada cliente e servidor.

 

·        Implementação no Gateway: Esta implementação é referida como “Bump In The Wire” ou BITW porque existe uma parte do equipamento rodando IPSec na extremidade da rede a ser protegida. Uma implementação de gateway pode ser baseada em software (IPSec rodando em um Firewall ou roteador) ou hardware uma aplicação rodando IPSec em uma “caixa preta” o qual pode ser muito mais rápido porque não existe o overhead do sistema operacional.

 

Uma VPN requer ao menos uma implementação gateway no site central ou na LAN remota e a implementação no cliente para cada site remoto. O cliente remoto pode ser um simples PC com uma localização fixa ou não, como no caso de um viajante acessando o site central de um computador portátil.

 

5.3.      Algoritmos de Autenticação e Encriptação para o IPSec

 

5.3.1.     Autenticação

 

Para autenticação de usuário, os algoritmos suportados são o HMAC MD5 (uso normal) e, para alto nível de segurança na autenticação, o HMAC SHA1 (FIPS-180-1). Diferentes implementações do IPSec oferece uma variedade de métodos de autenticação, incluindo segredo compartilhado, token cards e certificados digitais. Segredo compartilhado é mais fácil para usar para um pequeno número de pontas (clientes e/ou gateways). Token card funciona muito bem para implementações amplas de Intranet mas para uma implementação ampla de extranet o método mais fácil é usar um certificado digital (infraestrutura de chave pública).

 

5.3.2.     Encriptação

 

Os Algoritmos de encriptação hoje disponíveis incluem DES, 3DES, RC5, Cast, Idea e Blowfish com outros sendo adotados para prover diferentes níveis de segurança. Embora o DES tenha sido quebrado em menos de 23 horas, ele ainda é usualmente aceitável para o uso se a chave de sessão for mudada a cada hora. Mesmo se o túnel de dados é interceptado e sujeito a um “ataque de força bruta” para a quebra do código, apenas uma hora de dados estariam comprometidas.

O IPSec foi projetado de forma que apenas um algoritmo é escolhido, o atual material de chaveamento usado pelo algoritmo pode ser regenerado dentro do túnel em um quadro de tempo solicitado (por exemplo uma vez a cada hora, a cada 10MB, etc) para modificar as chaves de sessão efetivamente mudando também a encriptação.

Uma vez que o IPSec foi projetado para ser um algoritmo independente, ele aceita várias opções de algoritmos de encriptação e autenticação, permitindo seleção do nível de segurança desejado para cada VPN específica. Durante a fase de negociação de autenticação prévia ao estabelecimento do túnel, as duas extremidades negociam para encontrar o mais alto nível dos algoritmos de encriptação que ambas as pontas podem usar. Se não houver um requerimento mínimo de encriptação, o túnel não é estabelecido.

 

5.3.3.  Tunelamento

 

O tunelamento em geral é usado para carregar o tráfego de um protocolo sobre uma rede que não suporta aquele protocolo diretamente. Entretanto, no caso do IPSec, o IP é tunelado através por um propósito diferente: para prover total proteção, incluindo o header do pacote encapsulado. Se o pacote encapsulado é encriptado, um intruso não pode descobrir, por exemplo, o endereço de destino do pacote. Já sem o tunelamento o endereço é facilmente identificado. A estrutura interna de uma rede privada pode ser escondida desta forma.

Uma vez que o header encapsulado não é processado pelos roteadores intermediários da Internet, apenas as pontas do túnel (os gateways) têm que ter endereços assinados globalmente; os hosts nas subredes além deles podem ser assinados com endereços privados, por exemplo, 10.X.X.X. Como os endereçamentos IP únicos globais estão se tornando um recurso escasso, este método de interconexão ganha importância.

 

5.4.      Authentication Header (AH)

 

O AH é usado para prover integridade e autenticação para datagramas IP possuindo também proteção replay opcional. Estes serviços são não orientados à conexão, isto é, eles trabalham sobre uma base per-packet.

O AH autentica o datagrama IP tanto quanto possível. Alguns campos no cabeçalho IP mudam durante o roteamento e seus valores não podem ser previstos pelo receptor. Estes campos são chamados mutantes e não são protegidos pelo AH. Os campos IPv4 mutantes são:

 

·        Type of Service (TOS)

·        Flags

·        Fragment Offset

·        Time to Live (TTL)

·        Header Checksum

 

Quando a proteção destes campos é necessária, o tunelamento pode ser usado. O payload do pacote IP é considerado imutável e é sempre protegido pelo AH. O AH é identificado pelo protocolo número 51, assinado pelo IANA. O cabeçalho do protocolo (IPv4, IPv6, or Extensão) imediatamente precedente ao cabeçalho AH contém este valor em seu protocolo (IPv4) ou no campo do próximo cabeçaho (IPv6, Extension).

O processamento AH é aplicado apenas para pacotes IP não fragmentados, contudo, um pacote IP com AH aplicado pode ser fragmentado por roteadores intermediários. Neste caso, o destino primeiro remonta os pacotes e, então, aplica o processamento AH nele. Se um pacote IP que fragmentado (campo offset não nulo ou o bit More Fragments está habilitado) é colocado para processamento AH, ele é descartado. Isto previne o ataque de fragmento overlapping, o qual manipula indevidamente o algoritmo de montagem do fragmento de forma a criar pacotes forjados e forçá-los através do firewall. Pacotes que falham na autenticação são descartados e nunca serão entregues para as camadas mais altas. Este modo de operação reduz enormemente os ataques “denial of service”, os quais ajudam a bloquear a comunicação de um host ou de um gateway inundando-o com pacotes “bogus”.

 

5.4.1.     O formato de cabeçalho AH

 

O formato corrente do cabeçalho AH é descrito no rascunho Internet “draft-ietf-ipsec-auth-header-07.txt”, o qual contém importantes modificações comparadas à especificação AH anterior, RFC 1826. A informação aqui apresentada está neste rascunho Internet.

 

 

Figure 5 - Formato do cabeçalho AH

 

Campo

Comprimento

Função e valores

Next Header

8 bits

Identifica o tipo do próximo payload após o AH. Os valores para este campo são escolhidos do conjunto de números de protocolos IP definidos na mais recente “Assigned Numbers RFC” da Internet Assigned Numbers Authority (IANA).

Payload Length

8 bits

Contém o comprimento do cabeçalho AH expresso em palavras de 32 bits, menos 2. Ele não está relacionado ao comprimento real do payload como um todo. Se opções default são usadas, o valor é 4 (três palavras fixas de 32 bits mais três palavras de 32 bits de dados de autenticação menos dois).

Reserved

6 bits

Campo reservado para uso futuro. Seu valor é zero.

Security Parameter Index (SPI)

32 bits

 

Sequence Number

32 bits

É um contador monotonicamente incrementado usado para proteção “replay”. A proteção Replay é opcional; contudo, este campo é obrigatório. O remetente sempre inclui este campo e ele é separado no receptor para processá-lo ou não. No estabelecimento de um SA o número de seqüência começa em zero e o primeiro pacote transmitido usando o SA tem o número de seqüência 1. Números de seqüência não podem ser repetidos. Então o máximo número de pacotes IP que podem ser transmitidos em um dado AS é 232-1. Quando o mais alto número de seqüência é usado, reinicia-se o processo com um novo AS e uma nova chave. O Anti-replay é habilitado no remetente por default. Se sobre um estabelecimento AS, o receptor escolher não usá-lo, o remetente não relaciona mais nenhum valor neste campo.

Authentication Data (ou Integrity Check Value (ICV).

Variável, múltiplo integral de 32 bits.

É usado pelo receptor para verificar a integridade dos pacotes que chegam. O ICV para o pacote é calculado com o algoritmo selecionado na inicialização do AS. As implementações usualmente suportam dois a quatro algoritmos. Durante o cálculo do ICV, os campos mutáveis são considerados nulos.

 

5.4.2.  Modos de uso do AH

 

O AH pode ser usado de duas formas: modo transporte e modo túnel.

 

AH no Modo Transporte: neste modo o cabeçalho AH é inserido logo após o cabeçalho IP do datagrama IP original tal qual mostrado na figura abaixo. Se o datagrama já tem cabeçalho(s) IPSec, então o cabeçalho AH é inserido antes de algum deles. O modo transporte é usado pelos hosts, não pelos gateways, pois, estes não são preparados para este modo. A vantagem do modo transporte é o menor processamento de overhead. A desvantagem é que os campos mutantes não são autenticados.

 

Figure 6 – AH em modo Transporte

 

AH no Modo Túnel: neste modo um novo datagrama IP é construído e o datagrama IP original transforma-se no payload dele. Portanto o AH em modo transporte é aplicado ao datagrama resultante.

Figura 7 - AH em modo Túnel

 

O modo túnel é usado sempre que qualquer ponta de um AS for um gateway. Então, entre dois firewalls o modo túnel é sempre usado. Entretanto, gateways são propostos para suportar o modo túnel apenas, frequentemente eles podem também funcionar no modo transporte. Este modo é permitido quando o gateway atua como um host, isto é, em casos quando o tráfego é destinado para ele mesmo. Exemplos são os comandos SNMP ou requisições de eco ICMP. No modo túnel os cabeçalhos de endereços IP externos não precisam ser os mesmos que os cabeçalhos de endereços internos. Por exemplo, dois gateways de segurança podem operar um túnel AH o qual é usado para autenticar todo o tráfego entre as subredes que eles conectam. É um modo de operação muito típico. Hosts não são requeridos para suportar o modo túnel, mas frequentemente eles o fazem. As vantagens do modo túnel são a total proteção do datagrama IP encapsulado e a possibilidade do uso de endereçamento privativos. Entretanto, existe um processamento extra do overhead associado com este modo.

 

5.4.3.  Considerações do AH para o IPv6

 

O AH é uma parte integrante do IPv6.  Em um ambiente IPv6, o AH é considerado um payload fim-a-fim e ele aparece após o hop-by-hop, roteamento e os cabeçalhos de extensão de fragmentação. Os cabeçalho(s) de estensão de opções de destino podem aparecer antes ou depois do cabeçalho AH. A figura abaixo ilustra o posicionamento do cabeçalho AH no modo transporte para um pacote IPv6 típico. A posição dos cabeçalhos de extensão marcados com * é variável, se presente no todo.

 

 

Figure 8 - AH em modo Transporte para o IPv6

 

5.5.      Encapsulating Security Payload (ESP)

 

O ESP é usado para prover a verificação da integridade, autenticação e encriptação para datagramas IP. A proteção replay opcional também é possível. Estes serviços são não orientados à conexão; eles operam em base per-packet. O conjunto de serviços desejados são selecionáveis sobre um estabelecimento AS. Entretanto algumas restrições se aplicam:

 

·        verificação de integridade e autenticação juntas.

·        a proteção Replay é selecionável apenas com a verificação de integridade e autenticação.

·        a proteção Replay pode ser selecionada apenas pelo receptor.

 

A Encriptação é selecionável independentemente dos outros serviços. É altamente recomendado que, se a encriptação está habilitada, então a verificação de integridade e autenticação também devem estar. Se apenas a encriptação é usada, intrusos poderiam forjar pacotes em ataques criptanalíticos. Entretanto, ambos, autenticação (com verificação de integridade) e encriptação sendo opcionais, no mínimo um deles deve estar sempre selecionado. De outra forma não faria sentido usar o ESP.

O ESP é identificado pelo protocolo número 50, assinado pelo IANA. O cabeçalho do protocolo (IPv4, IPv6, ou Extensão) imediatamente precedente ao cabeçalho AH conterá este valor em seu Protocolo (IPv4) ou no campo Next Header (IPv6, Extensão).

O processamento ESP é aplicado apenas para pacotes IP não-fragmentados. Entretanto um pacote IP com ESP aplicado pode ser fragmentado por roteadores intermediários. Neste caso o destino primeiro remonta o pacote e, então, aplica o processamento ESP para ele. Se um pacote IP que aparece ser um fragmento (campo offset não nulo, ou o bit More Fragments habilitado) é inserido no processamento ESP, ele é descartado. Isto previne o ataque overlapping fragment. Se ambos, encriptação e autenticação (com verificação de integridade) estão selecionados, então o receptor primeiro autentica o pacote e, apenas se este passo for bem sucedido, procede com a decriptação. Este modo de operação economiza recursos de computação ao mesmo tempo que reduz a vulnerabilidade para ataques “denial of service”.

 

5.5.1.  Formato do Pacote ESP

 

A informação nesta secção está baseada no rascunho Internet “draft-ietf-ipsec-esp-v2-06.txt”, datado de Março de 1998. O formato do pacote ESP é mais complicado que o do pacote AH packet. Na verdade não existe apenas um cabeçalho ESP, mas também um trailer ESP e dados de autenticação ESP. O payload está localizado (encapsulado) entre o cabeçalho e o trailer, daí o nome do protocolo.

Figura 9 – Cabeçalho e Trailer ESP

 

Os seguintes campos são parte do pacote ESP

 

Campo

Comprimento

Função/Valor

Security Parameter Index (SPI)

32 bits

 

Sequence Number

32 bits

É um contador monotonicamente incrementado

Payload Data

(obrigatório)

Número variável de bytes de dados descritos pelo campo Next Header

Este campo é encriptado com o algoritmo criptográfico selecionado durante o estabelecimento do AS.

Padding

Comprimento variável. É um campo opcional. A maior parte dos algoritmos de encriptação requerem que os dados de entrada devam ser um número integral de blocos. Também, o ciphertext resultante (incluindo os campos Padding, Pad Length e o Next Header) deve terminar em um limite de 4 bytes sendo que, então, o campo Next Header é realinhado.

Ele pode ser usado para esconder o comprimento da mensagem original também. Entretanto, isto poderia impactar adversamente a largura de banda efetiva.

Pad Length

8 bits

Contém o número de bytes do padding precedente. Ele está sempre presente e o valor 0 indica “sem padding”

Next Header

8-bit obrigátórios

Mostra o tipo de dados carregados no payload. Os valores são escolhidos do conjunto de números do protocolo IP definidos pelo IANA.

Authentication Data

Variável e opcional.

Contém o ICV calculado para o pacote ESP do campo SPI para o Next Header, inclusive. Eles estará incluso apenas quando a verificação de integridade e autenticação foi selecionada durante a inicialização AS. As especificações ESP requerem dois algoritmos de autenticação: o HMAC com MD5 e HMAC com SHA-1.

 

5.5.2.     Modos de Uso do ESP

 

Exatamente como o AH, o ESP também pode ser usado nos modos Transporte e Túnel.

 

ESP em Modo Transporte: neste modo o cabeçalho ESP é inserido logo após o cabeçalho IP do datagrama IP original tal qual mostrado na figura abaixo. Se o datagrama já tem cabeçalho(s) IPSec, então o cabeçalho ESP é inserido antes de algum deles. O trailer ESP e a autenticação opcional de dados são anexados ao payload.

 

Figure 10 - ESP em modo Transporte

 

ESP no Modo Túnel: conforme esperado, este modo aplica o princípio do tunelamento. Um novo pacote IP é construído com um novo cabeçalho IP e então o ESP no modo transporte é aplicado. Uma vez que o datagrama original torna-se o payload para o novo pacote ESP, sua proteção é total se ambos, encriptação e autenticação, forem selecionados. Entretanto, o novo cabeçalho IP ainda não é protegido.

 

 

Figure 11 - ESP em modo Tunel.

 

O ESP em modo transporte não provê nem autenticação nem encriptação para o cabeçalho IP. Esta é uma desvantagem, uma vez que falsos pacotes podem ser entregues no processamento ESP. A desvantagem no modo transporte é o processamento do overhead mais lento. No caso do AH, o ESP no modo transporte é usado por hosts, não por gateways. Os Gateways não estão nem mesmo preparados para suportar o modo transporte.

O ESP modo túnel é usado sempre que qualquer uma das pontas for um gateway. Então, entre dois firewalls o modo túnel é sempre usado. Entretanto, gateways são propostos para suportar o modo túnel apenas, frequentemente eles podem também funcionar no modo transporte. Este modo é permitido quando o gateway atua como um host, isto é, em casos quando o tráfego é destinado para ele mesmo. Exemplos são os comandos SNMP ou requisições de eco ICMP. No modo túnel os cabeçalhos de endereços IP externos não precisam ser os mesmos que os cabeçalhos de endereços internos. Por exemplo, dois gateways de segurança podem operar um túnel ESP o qual é usado para autenticar todo o tráfego entre as subredes que eles conectam. Hosts não são requeridos para suportar o modo túnel, mas frequentemente eles o fazem. As vantagens do modo túnel são a total proteção do datagrama IP encapsulado e a possibilidade de uso de endereçamento privados. Entretanto, existe um processamento adicional do overhead associado com este modo.

 

5.5.3.     Considerações do ESP para o IPv6

 

Como o AH, o ESP uma parte integrante do IPv6. Em um ambiente IPv6, o ESP é considerado um payload fim-a-fim e ele aparece após o hop-by-hop, roteamento e os cabeçalhos de extensão de fragmentação. O(s) cabeçalho(s) de extensão de opções de destino poderiam aparecer antes ou depois do cabeçalho AH. A figura abaixo ilustra o posicionamento do cabeçalho AH no modo transporte para um pacote IPv6 típico. A posição dos cabeçalhos de extensão marcados com * é variável, se presente no todo.

 

Figura 12- ESP em modo Transporte para o IPv6

 

5.6.      O Internet Key Exchange Protocol (IKE)

 

O quadro de Internet Key Exchange (IKE), previamente referido como ISAKMP/Oakley, suporta negociação automática das SAs e geração automática e refresh das chaves de criptografia. As habilidades para a performance destas funções com pequenas e não manuais configurações de máquinas é um elemento crítico para qualquer implementação IPSec em escala numa empresa. Antes de descrever os detalhes das trocas das chaves e mensagens, algumas explicações são devidas:

 

Internet Security Association e Key Management Protocol (ISAKMP): é um quadro que define o gerenciamento das SAs (negocia, modifica, deleta) e as chaves, e também define os payloads para a troca de gerações de chaves e autenticação de dados.

 

Oakley: é um protocolo de troca de chaves que pode ser usado com o quadro ISAKMP para trocar e atualizar o material de chaveamento para as SAs.

 

DOI - Domain Of Interpretation: é a definição de um conjunto de protocolos para serem usado com o quadro ISAKMP para um ambiente particular, e um conjunto de definições comuns compartilhadas com aqueles protocolos concernentes à sintaxe dos atributos de SA e conteúdo dos payloads, etc. Em relação ao IPSec, o DOI instancia o ISAKMP para o uso com o IP.

 

Internet Key Exchange (IKE): é um protocolo que usa parte do ISAKMP e parte dos protocolos de troca de chaves do Oakley e do SKEME para prover gerenciamento de chaves e SA para os protocolos IPSec AH/ESP e para o próprio ISAKMP.

 

O ISAKMP requer que todas as trocas de informações devam ser encriptadas e autenticadas de modo que nenhum intruso possa interceptá-las e o material de chaveamento só será trocado entre as partes autenticadas. Isto é exigido porque os procedimentos do ISAKMP tratam com a inicialização das chaves e eles devem ser capazes de rodar sobre enlaces onde é assumido não existir segurança alguma. Desta forma, os protocolos ISAKMP usam operações complexas e de processamento intenso no protocolo IPSec. Adicionalmente, o método ISAKMP foi projetado com o objetivo explícito de prover proteção contra várias exposições de ataques bem conhecidas:

 

·        Denial-of-Service: As mensagens são contruídas com cookies únicos que podem ser usadas para rapidamente identificar ou rejeitar mensagens inválidas sem a necessidade de executar operações criptográficas de processamentos intensos.

·        Man-in-the-Middle: proteção é provida contra ataques comuns tais como deleção de mensagens/alterações de mensagens, reflexões de mensagens de volta para o remetente, repetição de antigas mensagens e redirecionamento de mensagens para destinos não desejados.

·        Perfect Forward Secrecy (PFS): compromisso de chaves passadas de não prover pistas úteis para a quebra de outra chave, mesmo se ocorrido antes ou depois da chave comprometida. Isto é, cada chave criada será derivada sem qualquer dependência de chaves antecessoras.

 

Os seguintes métodos de atuenticação são definidos pelo IKE:

 

·        Chave pre-compartilhada

·        Assinaturas digitais (DSS e RSA)

·        Encriptação pública de chaves (RSA e RSA revisada)

 

A robustez de qualquer solução baseada em criptografia depende muito mais da manutenção da chave secreta do que nos verdadeiros detalhes dos algoritmos de criptografias escolhidos. Desta forma, o IETF IPSec Working Group prescreveu um conjunto de protocolos de troca Oakley extremamente robusto. Ele usa uma aproximação de duas fases:

 

Fase 1: Este conjunto de negociações estabelece um segredo maior do qual todas as chaves de criptografia serão subsequentemente derivadas para a proteção do tráfego de dados do usuário. Na maior parte dos casos, a chave pública de criptografia é usada para estabelecer uma associação de segurança ISAKMP entre sistemas e estabelecer as chaves que serão usadas para proteger as mensagens ISAKMP que irão flui na fase 2 de negociações subsequente. A fase 1 concerne apenas ao estabelecimento da série de proteção para as mensagens ISAKMP elas mesmas, mas ela não estabelece qualquer AS ou chaves de proteção de dados do usuário. Na fase 1, as operações de criptografia têm processamento mais intensivo mas não precisam ser feitas com freqüência, e uma troca simples de fase 1 pode ser usada para suportar múltiplas trocas subsequentes de fase 2. Exemplificando, seria aproximadamente assim: as negociações de fase 1 são executadas uma vez ao dia ou talvez uma vez por semana, enquanto as negociações de fase 2 são executadas uma vez a cada poucos minutos.

 

Phase 2: As trocas de fase 2 são menos complexas, uma vez que elas são usadas apenas após a série de proteção de segurança negociada na fase 1 ter sido ativada. Um conjunto de sistemas de comunicação negociam as SAs e chaves que irão proteger as trocas de dados do usuário. As mensagens ISAKMP na fase 2 são protegidas pela AS ISAKMP gerada na fase 1. As negociações de fase 2 geralmente ocorrem mais frequentemente que a fase 1. Por exemplo, uma aplicação típica das negociações de uma fase 2 é a mudança (refresh) das chaves criptográficas uma vez a cada dois ou três minutos.

 

5.6.1.  Identificadores Permanentes

 

O protocolo IKE também oferece uma solução mesmo quando o IP do host remoto não é conhecido com antecedência. O ISAKMP permite um host remoto identificar-se através de um identificador permanente, tal como um nome ou um endereço eletrônico (e-mail). As trocas de fase 1 do ISAKMP autenticarão então a identidade permanente do host remoto usando uma chave de criptografia pública. Certificados criam uma união entre o identificador permanente e a chave pública. Entretanto, as trocas de mensagens de fase 1 baseada em certificado do ISAKMP podem autenticar a identificação permanente do host remoto. Uma vez que as mensagens ISAKMP são elas próprias carregadas dentro dos datagramas IP, o parceiro ISAKMP (por exemplo, um firewall ou host de destino) pode associar o endereço IP dinâmico do host remote com sua identidade permanente autenticada.

 

5.6.2.     Inicializando as ASs com o IKE

 

Esta sessão delineia como os protocolos ISAKMP/Oakley inicialmente estabelecem as ASs e as trocas de chaves entre dois sistemas que desejam comunicar-se seguramente. As partes envolvidas na comunicação serão chamadas de Host A e Host B. O Host A será o iniciador das trocas de fase do ISAKMP e o Host-B será o respondedor. Se necessário, para maior clareza, subscritos A ou B serão usados para identificar a fonte de vários campos nas trocas de mensagens.

 

Phase 1 – Estabelecendo os SAs ISAKMP:

 

As SAs que protegem as mensagens ISAKMP são estabelecidas elas próprias durante as trocas de fase 1. Considerando o começo do “zero”, isto é, nenhuma chave prévia ou SAs foram negociados entre os host, as trocas de fase 1 usarão a troca de proteção de identidade ISAKMP, também conhecida como modo Oakley principal. Seis mensagens são necessárias para completar uma troca:

·        Mensagens 1 e 2 negociam as características das SAs.

·        Mensagens 1 e 2 fluem explícitas para a troca inicial de fase 1, e elas não estão autenticadas.

·        Mensagens 3 e 4 trocam nonces (valores randômicos) e também executam uma troca Diffie-Hellman para estabelecer uma chave maior (SKEYID). Mensagens 3 e 4 fluem explícitas na troca inicial de fase 1 e elas estão não autenticadas.

·        Mensagens 5 e 6 trocam a informação requerida para a autenticação mútua das identidades das partes. Os payloads das mensagens 5 e 6 estão protegidos por algoritmos de encriptação e estabelecimento do material de chaveamento com as mensagens 1 através da 4.

 

A descrição detalhada das mensagens e informações trocadas da fase 1 segue:

 

·        A fase 1 IKE, Mensagem 1: Uma vez que o Host A é a parte iniciadora, ele constrói uma mensagem de texto claro ISAKMP (Mensagem 1) e a envia para o Host-B. A própria mensagem ISAKMP é carregada como o payload de um pacote UDP que por sua vez é carregado como o payload de um datagrama IP normal (ver figura que segue).

 

 

Figure 13 – Message 1 of na ISAKMP Phase 1 Exchange

 

Os endereços de origem e destino a serem colocados no cabeçalho IP são aqueles do Host A (iniciador) e Host B (respondedor), respectivamente. O cabeçalho UDP identificará que a porta de destino é a 500, a qual foi designada para o uso do protocolo ISAKMP. O payload do pacote UDP carrega a própria mensagem ISAKMP. Na mensagem 1, o Host A, o iniciador, propõe um conjunto de um ou mais séries de proteção para a consideração do Host B, o respondedor. Desta forma, a mensagem ISAKMP contém ao menos os seguinte campo em seu payload:

 

Campo

Descritivo

Cabeçalho Header

O cabeçalho ISAKMP na mensagem 1 indica uma mudança do tipo do modo principal (Main Mode), e conterá a mensagem ID de 0. O Host A designará o campo Responder Cookie para 0 e preencherá com umvalor randômico de sua escolha para o Initiator Cookie, denotado como Cookie ª

Security Association

identifica o Domain of Interpretation (DOI). O campo de Associação de Segurança Uma vez que os hosts rodam protocolos IPSec entre eles mesmos, o DOI é simplismente o IP.

Proposal Payload

A proposta de payload do Host A especificará o protocolo PROTO_ISAKMP e designará o SPI para o valor 0.

Transform Payload

 

especificará o KEY_OAKLEY. Para o KEY_OAKLEY transform, o Host A deve també especificar os atributos relevantes: nameamento, o método de autenticação a ser usado, a função pseudo-randômica a ser usada, e o algoritmo de encriptação a ser usado.

 

·        IKE fase 1, Mensagem 2: Na mensagem 1, o Host A propõe um ou mais séries de proteções a serem usadas para proteger as trocas ISAKMP. O Host B usa a mensagem 2 para indicar qual delas, se alguma, irá suportar. Se o Host A propõe apenas uma única opção, o Host B simplesmente precisa saber que a proposta é aceitável. Os endereços de origem e destino colocados no cabeçalho IP são aqueles do Host B (respondedor) e do Host A (iniciador), respectivamente. O cabeçalho UDP identificará que a porta de destino é a 500, a qual terá sido designada para o uso do protocolo ISAKMP. O payload do pacote UDP carrega a mensagem ISAKMP. O conteúdo da mensagem esta indicado na tabela que segue:

 

Campo

Descritivo

cabeçalho ISAKMP

O ISAKMP na mensagem 2 indicará um tipo de troca (indicate an exchange type of Main Mode) do modo principal e contém uma mensagem ID de 0. O Host B designará ao campo Responder Cookie um valor randômico, o qual será chamado de Cookie B e que copiará do campo Initiator Cookie o valor que foi recebido na mansagem 1 do campo do Cookie. O par de valores <Cookie-A, Cookie-B> servirão como o SPI para a Associação de segurança do ISAKMP.

Security Association

O campo Security Association identifica o Domain of Interpretation (DOI). Uma vez que os hosts rodam o protocolo IPSec entre eles mesmos, o DOI é simplesmente o IP.

Proposal Payload

A proposta de payload do Host B especificará o protocolo PROTO_ISAKMP e designará o SPI para o valor 0.

Transform Payload

O Transform Payload especificará o KEY_OAKLEY. Para o KEY_OAKLEY transform, os atributos que serão aceitos da proposta oferecida pelo Host A são copiados dentro de campos apropriados. Neste ponto, as propriedades do ISAKMP SA têm sido concordadas pelos Hosts A e B. A identidade do ISAKMP SA é designada igual ao par <Cookie-A, Cookie-B>. Entretanto, as identidades das partes reclamantes (reivindicantes) para ser os Host A e Host B não têm sido ainda autoritativamente verificadas.

 

·        IKE Phase 1, Message 3: A terceira mensagem da fase 1 da troca ISAKMP começa com a troca de informação de quais chaves de criptografia serão eventualmente derivadas.

É importante ressaltar que nenhuma das mensagens, elas mesmas, carregam chaves de criptografia verdadeiras. Ao invés, elas carregam entradas (inputs) que serão usadas pelos Hosts A e B para derivar as chaves localmente.

 

O payload ISAKMP será usado para trocar dois tipos de informação:

 

·        Valor público Diffie-Hellman: O valor público “gx” Diffie-Hellman do iniciador. O exponente x no valor público é um valor privado que deve ser mantido secreto.

·        Nonce: o nonce Ni do iniciado. (Nonce é um nome fantasia para o valor que é considerado ser randômico mas concordando com algumas regras matemáticas).

·        ID: se a autenticação com chave pública RSA é usada, os nonces são encriptados com chave pública da outra parte. Igualmente são os IDs de cada parte os quais são então também trocados neste estágio.

·        Se a autenticação com chave pública RSA revisada é usada, os payloads KE e ID são encriptados com a chave secreta que é derivada dos nonces e algoritmos de encriptação concordados para as mensagens 1 e 2, evitando então uma operação de CPU intensiva de chave pública. Certificados podem opcionalmente ser trocados em cada caso de autenticação de chave pública, tão bem quanto um valor hash. Estes valores são carregados na troca de chave, nos campos nonce e ID, respectivamente.

 

Figura 14 – Mensagem 3 de uma troca ISAKMP de fase 1

 

6.         CONSIDERAÇÕES NA ESCOLHA DE UMA VPN

 

Um empresa que pretende adquirir um modelo VPN deve analisar alguns ítens antes de implementá-la para ter certeza de que ela é a melhor solução:

 

 

 

 

 

 

 

7.         OS RFCs E RASCUNHOS DE INTERNET

 

O Internet Engineering Task Force (IETF) codifica suas decisões em documentos denominados "Requests For Comments" que são universalmente chamados pelo acrônimo RFC. Muitos RFCs são padrões nos quais a Internet é baseada.

O nível de padronização que um RFC alcança é determinado não apenas por sua qualidade mas por quanto mais amplamente ele é implementado e testado. Alguns RFCs não são padrões sólidos, entretanto, eles são documentos técnicos de grande valia para a Internet sendo usados como guias para a implementação.

Antes de uma proposta ou nota tornar-se um RFC, ela é colocada como um Rascunho de Internet (I-D Internet Draft) e é discutida em vários fóruns, freqüentemente Working Groups do IETF. Os I-Ds são freqüentemente rascunhos rústicos e, portanto, sujeitos a muitas mudanças. Alguns levam anos de análises e podem ser derrubados ou abandonados num dado momento; outros têm uma ascensão rápida até tornarem-se RFCs. Rascunhos de Internet são os primeiros nomes dados, quando eles se tornam RFCs, o nome I-D desaparece e um número RFC é designado.

Nem todos os RFCs Internet são padrões. Padrões de Internet estão sujeitos a extensas revisões e testes. As letras abaixo listadas designam a situação atual de desenvolvimento dos RFCs:

 

 

De acordo com a VPNC [5], padrões e protocolos IPsec encontram-se em amplas categorias largas. É claro que alguns padrões encontram-se classificados mais do que uma categoria mas, em geral, eles podem ser ajustados em pelo menos uma das seguintes categorias:

 

 

Conforme sua classificação, o VPNC [5] criou listas separadas de I-Ds e RFCs relativos às VPNs que podem ser consultadas na sessão de anexos deste trabalho.

 

Conclusão

 

            O conceito VPN não é novo, entretanto tem apresentado uma grande projeção como opção de comunicação de dados para as corporações nos dias atuais. Sobretudo, as IP-VPNs sobressaem-se neste mercado em função da padronização de seus protocolos, à expansão explosiva da rede Internet e o crescimento dos backbones dos PS/Empresas Carriers. Além da redução dos custos, a IP-VPN leva com maior versatilidade a possibilidade dos serviços convergentes, fomentando aplicações de e-commerce e B2B.

Mesmo com outros protocolos correntes, o enfoque exclusivo deste trabalho no protocolo IPSec deveu-se ao fato de este apresentar um crescente domínio no mercado. Baseado nos padrões desenvolvidos pelo Internet Engineering Task Force (IETF), o IPSec é uma arquitetura aberta que implementa a encriptação e autenticação exigidas para a devida segurança na rede do cliente (confidencialidade, integridade e autenticidade). Além dos conceitos básicos dos protocolos correntes envolvidos numa comunicação IP-VPN (Ipv4), também, algumas considerações foram feitas para o protocolo IP futuro, o Ipv6.

            Como conclusão do trabalho, vale apresentadar as vantagens que uma solução VPN pode oferecer a uma corporação. Dentre as várias razões para a escolha de um acesso remoto VPN o maior argumento de venda é a potencial economia de custos.

 

 

 

            Uma empresa que pretende utilizar-se de circuitos privativos para interconexão de suas LANs necessita de N x (N-1)/2 circuitos privativos alugados, considerando que N seja o número de subredes (LANs) a serem interligados. Para poucas interligações, as linhas privadas alugadas são uma solução viável, entretanto, quando o número de subredes a serem interligadas aumenta, o custo pode tornar-se proibitivo. O gráfico 1 ilustra o crescimento de circuitos em função da quantidade de pontos a serem interligados.

No entanto, se a mesma empresa decidir-se por uma rede VPN, basta que cada subrede interligue-se via dial-up ou acesso em banda larga (cable-modem, ADSL, etc) ao provedor de serviços VPN local mais próximo, isto é, a quantidade de circuitos passa a ser a quantidade de pontos. A partir do provedor, a rede fará os devidos roteamentos de forma a interligar as LANs.

Do exposto anteriormente pode-se vislumbrar a economia resultante da adoção de uma VPN, tais como:

 

-         Redução de custos devido à diminuição da necessidade de encargos de telefonia de longas distâncias uma vez que o cliente pode ter um acesso via discagem local para o ponto mais próximo de acesso do provedor de serviços. Isto pode dramaticamente cortar custos para empresas que tenham muitas sedes internacionais. Um relatório de pesquisa em VPN realizado pela Infonetics Research Inc. estimou uma economia de 20% a 47% dos custos de uma WAN pela substituição das linhas alugadas por conexões VPN.

-         Economia nos custos operacionais das companhias no caso de equipamentos que dão suporte aos usuários remotos. Uma companhia usando VPN pode livrar-se de seus “pools” de modens, servidores de acesso remoto e outros equipamentos WAN e simplesmente usar a sua instalação de Internet existente. Segundo o relatório da Infonetics Research Inc. a economia de acessos remotos VPN podem representar de 60% a 80% dos custos dos acessos remotos dial-up corporativos.

·        A responsabilidade de suporte técnico é em geral assumida pelo provedor do serviço VPN visto que em geral são eles os responsáveis pelo suporte técnico de seus clientes dial-up. Isto ocorre porque o provedor de serviços público possui uma rede compartilhada por uma larga base de clientes o que significa diluição de custos em manutenção e gerenciamento.

 

Além da potencial economia, outros fatores importantes constam para fazer da VPN uma boa opção de serviço: