Atravessando Firewalls em IP Móvel Por MARCIO BELO (mbelo@ic.uff.br) PPGC/IC/UFF Disciplina Computação Móvel Prof. Julius Leite Abril de 2003

Introdução (1) Tunelamento IP Móvel: Mobile Node migra para outra sub-rede (foreign link) Mantém o mesmo IP à medida que muda seu ponto de acesso à Internet. Sem uso de Firewalls

Introdução (2) Rede Pública Rede Privada Rede Privada: separada da Internet por hospedeiros impondo restrições de acesso (firewalls). Hospedeiros podem possuir endereços privados, não roteáveis na Internet Rede Pública: hospedeiros são capazes de se comunicar com outros através da rede pública sem restrições impostas por um firewall Firewall: impõe restrições nos pacotes que entram e deixam a rede por ele protegida. Pacotes não o atravessam sem antes eles atenderem uma determinada especificação ou então haver uma negociação envolvendo algum tipo de autenticação. Por usarem endereços IPs privados, todos os pacotes Internet endereçados para nodos da rede privada devem ser direcionados para o endereço (chamado real) do firewall.

Objetivos Prover ao Mobile Node o mesmo nível de conectividade e segurança que ele dispõe quando está em seu Home Link

Requisitos para a solução O Foreign Link é na parte pública da Internet: não existe um Firewall separando-o dela Firewall não precisa saber nada sobre IP Móvel Funcionar com redes privadas de endereços Internet não roteáveis [RFC1918] Funcionar na presença de outros Firewalls entre o Home Agent e o Firewall no perímetro da rede privada O Foreign Link é na parte pública da Internet: não existe um FireWall separando-o dela: (...) Firewall não precisa saber nada sobre IP Móvel: basta que ele implemente autenticação de cabeçalho do IP, Encapsulamento de segurança do Payload IP, e implementar um protocolo de gerenciamento de chaves, como o SKIP Funcionar com redes privadas de endereços Internet não-roteáveis [RFC1918]: ou seja, numa rede cujos endereços utilizados internamente são privados Funcionar na presença de outros Firewalls entre o Home Agent e o Firewall no perímetro da rede privada: para fins de simplicidade, consideraremos nos exemplos a existência de apenas um firewall

Atravessando Firewalls usando SKIP (1) Já é um RFC, ou seja, implementado Consideraremos: Firewall deve implementar SKIP Mobile Node possui a chave pública do Firewall e vice-versa Firewall e nodo móvel devem implementar algoritmos de autenticação e encriptação Mobile Node deve ser capaz de reconhecer se está “dentro” da rede privada Home Agent também deve saber se está recebendo uma requisição de dentro da rede privada ou de fora Já é um RFC, ou seja, implementado: novo livro cita como um Internet Draft, porém no momento da produção desta apresentação o padrão já havia sido estabelecido: RFC2356. É um protocolo sessionless. Consideraremos: Firewall deve implementar SKIP: algoritmo de gerenciamento de chaves. Repare que isso não quebra os novos requisitos, pois a grande maioria dos firewalls implementam esse algoritmo. Mobile Node possui a chave pública do Firewall e vice-versa: configurado manualmente. Alternativamente, pode haver uma maneira de trocar essas chaves dinamicamente usando um dos mecanismos definidos pelo protocolo SKIP (on-line certificate directory service). O Home Agent e o Firewall também devem conhecer cada um a chave pública do outro. Firewall e nodo móvel devem implementar algoritmos de autenticação e encriptação: assumiremos os algoritmos Keyed MD5 authentication [rfc1828] e Triple-DES encryption [rfc1851]. Devem ser implementados a nível de hardware ou software. Mobile Node deve ser capaz de reconhecer se está “dentro” da rede privada: deve ser configurado com um intervalo de endereços IP que são conhecidos como pertencentes à rede privada Home Agent também deve saber se está recebendo uma requisição de dentro da rede privada ou de fora: o home agent também deve ser configurado com o intervalo de endereços IPs que pertencem à rede privada. Isso permite que o home agent sabe ser o Mobile Node está tentando registrar um endereço care-of, para que desta forma ele modifique seu funcionamento para entregar pacotes pelo tunelamento para o firewall e o mesmo possa repassá-los para o endereço care-of.

Atravessando Firewalls usando SKIP (2) Procedimento de registro: Mobile Node conecta a um Foreign Link e obtém um IP MN determina se está fora ou dentro de sua rede privada. Prosseguimos considerando MN externo: MN registra care-of externo no Mobile Agent, através de tunelamento seguro (Registration Request) ao Firewall O Firewall determina a identidade do MN e descobre como a mensagem foi codificada O Firewall encaminha a mensagem para o Home Agent Home Agent recebe a mensagem e a processa Caso OK, Home Agent retorna uma mensagem de confirmação Firewall envia através do tunelamento a mensagem para o MN MN determina a identidade do Firewall. Caso seja válida, verifica também a validade do Home Agent Mobile Node conecta a um Foreign Link e obtém um IP: via DHCP, PPP´s IPCP (dinâmicos) ou configuração manual (estático) MN determina se está fora ou dentro de sua rede privada: faz isso consulta a lista de endereços conhecidos com pertencentes à rede privada, ou seja, determina de seu endereço care-of pertence à rede privada ou a Internet pública. Atenção que mesmo dentro da rede privada o MB pode estar em outro enlace, porém não precisará se preocupar com o atravessamento do firewall, pois estará dentro dele. Consideraremos a partir daqui que o care-of é externo. MN registra care-of no Mobile Agent: é montada uma mensagem Registration Request normal (UDP/IP). O MN depois gera um cabeçalho IP externo com endereço de origem care-of e de destino do Firewall. O campo IP Protocol é setado como SKIP, para identificar o próximo cabeçalho. Finalmente o MN monta o cabeçalho SKIP, contendo uma chave de autenticação. É usada a chave pública do Firewall. O Firewall determina a identidade do MN e descobre como a mensagem foi codificada: a identidade do MN é validada através do envio da chave pública do mesmo. Com essa chave é feito o procedimento de decodificação da mensagem, verificando se ela é válida ou não. O Firewall encaminha a mensagem para o Home Agent: o Firewall verifica que o IP do remetente (care-of) é externo. Se a sub-rede isolada pelo Firewall usa endereços privados, é feito um tunelamento para a entrega da mensagem de registro (Registration Request) para o Home Agent. Caso use endereços internet, essa mensagem é apenas repassada. Home Agent recebe a mensagem e a processa: neste momento é feita uma validação da identidade do MN através do MN Authetication Extension da pilha. Caso OK, Home Agent retorna uma mensagem de confirmação: é envia a mensagem Registration Reply. Novamente, se o Home Link usa endereços privados e o endereço care-of não pertence a mensagem rede, a mensagem é encaminha para o Firewall Firewall envia através do tunelamento a mensagem para o MN MN determina a identidade do Firewall. Caso seja válida, verifica também a validade do Home Agent: o MN usa o cabeçalho SKIP para identificar a identidade do Firewall e determinar como decifrar o pacote. Caso seja validade, o MN decodifica a mensagem Registration Reply e verifica a identidade do Home Agent através da validação Mobile Home Authentication Extension.

Mensagem encaminha ao Firewall Parte clara: texto puro Parte escura: texto codificado

Fluxo de Dados (1) Consideramos que o processo de registro foi feito com sucesso. Mobile Node envia pacotes para um nodo: MN envia um pacote seguro pelo tunelamento para o Firewall; O Firewall verifica a autenticidade e decodifica o pacote. Depois encaminha para o nodo correspondente. O Nodo responde com um pacote enviado para MN através do Home Agent. O Home Agent intercepta o pacote e o envia através do tunelamento para o Firewall. O Firewall envia a mensagem através do tunelamento para o endereço care-of do MN. O MN verifica a autenticidade e decodifica o pacote. O pacote, após decodificado, é finalmente consumido

Fluxo de Dados (2) Ocorre o processo inverso

Análise do método usando SKIP Baixa complexidade Não necessita de negociação de parâmetros de segurança antes de uma transmissão Overhead do cabeçalho SKIP em cada pacote Criptógrafos reclamam que o tipo de codificação é indicado em texto puro no cabeçalho do pacote SKIP Por consenso, o grupo do IETF aponta o ISAKMP/Oakley como o futuro padrão para gerenciamento de chaves Baixa complexidade: comparado a proposta ISAKMP/Oakley. Não necessita de negociação de parâmetros de segurança antes de uma transmissão: chaves não precisam ser trocadas antes do envio de um pacote. Overhead do cabeçalho SKIP em cada pacote: 20 ou mais bytes enviados a cada transmissão. Criptógrafos reclamam que o tipo de codificação é indicado em texto puro no cabeçalho do pacote SKIP: no campo IP Protocol desprotegido é indicado o texto 57, indicado que a seguir vem um cabeçalho SKIP. Isso permite um hacker saber quais algoritmos de codificação estão envolvidos Por consenso, o grupo do IETF aponta o ISAKMP/Oakley como o futuro padrão para gerenciamento de chaves: este padrão ainda está em desenvolvimento.

Método ISAKMP/Oakley Existe uma negociação de parâmetros de segurança entre o MN e o Firewall O MN pode negociar uma máscara de IPs com o Firewall, evitando desta forma negociar novamente parâmetro de segurança num mesmo Foreign Link Os pacotes não conterão um cabeçalho de gerenciamento de chave, como ocorre com o SKIP Existe uma negociação de parâmetros de segurança entre o MN e o Firewall: aumenta o overhead para criar o tunelamento O MN pode negociar uma máscara de IPs com o Firewall, evitando desta forma negociar novamente parâmetro de segurança num mesmo Foreign Link: facilita a mobilidade do MN dentro de um mesmo enlace (Foreign Link) Os pacotes não conterão um cabeçalho de gerenciamento de chave, como ocorre com o SKIP: evitando desta forma identificar qual o algoritmo de encriptação utilizado para codificar o pacote

Apresentação pode ser obtida em: Referências “Mobile IP – The Internet Unplugged”, James D. Solomon, Chapter 9 “Sun's SKIP Firewall Traversal for Mobile IP”, RFC2356, IETF Apresentação pode ser obtida em: http://www.ic.uff.br/~mbelo