Este artigo foi traduzido por máquina.

Circulando

Uma introdução a VPNs IPsec em celulares

Ramon Arjona

Esta tarde enquanto estava fora do escritório, recebi um email no meu telefone. A mensagem tinha um link para um documento que deveria para ler--um documento em um site do SharePoint disponível somente por meio de intranet da minha empresa. Isso era um bummer porque eu tive que esperar até que eu poderia acionar meu laptop, colocar meu cartão inteligente na leitora de cartão inteligente, obter uma conexão Wi-Fi em uma cafeteria, conectar-se meu laptop à VPN corporativa e fazer logon antes que pode ler o documento.

Vida seria muito mais fácil se eu poderia simplesmente usar o telefone para acessar o site do SharePoint. É claro que, meu telefone seria necessário de conectando-se com segurança à rede corporativa e autenticação me alguma forma mágica. Em outras palavras, como meu laptop, meu telefone precisaria a capacidade de iniciar uma conexão VPN à rede. Muitos modelos de telefone comercial, incluindo Windows telefones, vêm com um cliente VPN interno. Mas há limitações em clientes VPN mais amplamente disponíveis porque eles são baseados em versão 1 de uma especificação denominada Internet Key Exchange (IKEv1). IKEv1 é uma parte estável da estrutura IPsec e é ótimo para dispositivos com fio ou dispositivos, como laptops, com baterias relativamente grandes que não moverem ao redor muito. No entanto, não é ideal para telefones móveis.

Com certeza, uso uma conexão sem fio no meu laptop para ir do meu escritório para uma sala de conferência e novamente. Pode mudar de uma conexão sem fio para um com fio e esperado sem perda de conectividade. Mas nós não move ao redor quase tantos com um laptop como podemos fazer com um telefone. Um telefone acompanha você tráfego e no e check-out de edifícios, transição de e para o estado móvel. A menos que você use um modem para telefone celular, quando foi a última vez que seu laptop dissemos que era móvel? Geralmente, um telefone altera seu ponto de anexo de rede com uma freqüência e a complexidade que nunca tem um laptop para se preocupar sobre. O equipe que pensamos a especificação IKEv1 não precisa se preocupar cenários de celular, porque não nos anos 90 atrasado, quando RFC 2409 estavam sendo gravadas, telefones inteligentes apenas foram predominantes no mercado. Desde então, o uso de telefones móveis tem skyrocketed e a importância do telefone celular começou a abordar a importância de maiores, outros dispositivos de computação, como a estação de trabalho ou o laptop.

IKEv1 não é bem adequado para um estilo altamente móvel da computação porque IKEv1 não tem uma boa maneira de lidar com um host que pode alterar o seu ponto de anexo de rede várias vezes em poucos segundos. Quando IKEv2 foi esboçada, um conjunto de extensões chamado de protocolo Mobility e multihoming (MOBIKE) também foi Esboçado para acomodar o cenário de telefone celular. Se usar essas extensões, celular 2009a VPN torna muito mais prático. Vários produtos no mercado de suporte IKEv2 e MOBIKE, incluindo o Microsoft Systems Center SCMDM (Mobile dispositivos gerenciador).

Neste artigo, abordarei algumas das noções básicas da tecnologia por trás IKEv2 e MOBIKE. Suponho que você ter um conhecimento de trabalho de IPv4 e de rede, alguns familiaridade com telefones móveis e uma compreensão básica de criptografia. Este artigo não será para cobrir o IPsec em detalhes e não será para discutir outros tipos de tecnologias VPN, como VPNs baseadas em SSL. Também não abordo IPv6. IPsec e IKE são extensões para IPv4, mas eles são bolinhos em IPv6, portanto, algumas das coisas que será tocar aqui ainda será aplicável em uma rede IPv6. No entanto, IPv6 apresenta suficiente complexidade e a terminologia nova que seria possível cobri-lo em detalhes suficientes.

Digamos que ‘ AH ’

Três protocolos formam o núcleo do IPsec: O cabeçalho de autenticação (AH), carga de segurança de encapsulamento (ESP) e de IKE. Para resolver IKE, primeiro preciso discutir AH e ESP.

Em poucas palavras, AH assegura que os pacotes que enviamos não adulterados. Ele protege a integridade do nossos pacotes. AH também garante que os pacotes são enviados de quem alega ter enviado-los. Ele garante a autenticidade do nossos pacotes. AH não, fornece no entanto, qualquer medida de privacidade ou criptografia. Um invasor que tivesse acesso à rede ainda pode detectar pacotes que protegido por AH e extrair seu conteúdo. Ele não, no entanto, poderá se mascarar como um das partes autenticadas nem consiga alterar nossos pacotes em trânsito. AH é definido no RFC 4302.

Por exemplo, Ana Maria e Luís tem estabelecido uma conexão VPN entre si e optou por proteger seus pacotes com o AH. Charlie insere-se para a rede e inicia interceptando pacotes. Charlie é capaz de reconstruir conversação Alice e Bob, pois ele pode ver o conteúdo de seus pacotes e distinguir a que tipo de tráfego está passando entre eles. No entanto, ele não pode falsificar uma mensagem de Alice para Bob sem obter detectada e ele não pode alterar as mensagens de Bob para Alice, ou. Ambas essas coisas são evitadas pelo AH.

AH pode ser usado no modo de transporte ou no modo de encapsulamento. No modo de transporte, a carga de um pacote é protegida e pacotes são roteados diretamente de um host para outro. No modo de encapsulamento, todo o pacote é protegido por AH e pacotes são roteados de uma extremidade de um "encapsulamento" do IPsecpara outro. Encapsulamento é realizada através de encapsulamento do pacote original. Até o final do encapsulamento é um gateway de segurança. O gateway que está enviando um pacote é responsável para encapsular esse pacote adicionando um "externa"Cabeçalho IP e endereço. Esse endereço externo roteia o pacote para o gateway de segurança na outra extremidade do encapsulamento. O gateway recebe o pacote é responsável pelo processamento o AH para determinar que o pacote é de um remetente válido e não foi adulterado, e em seguida, ele roteia o pacote para seu destino final.

No modo de transporte, um AH obtém adicionado ao pacote imediatamente após o cabeçalho IP. O AH vem antes do próximo protocolo da camada no pacote (como TCP ou UDP) e também antes de outros cabeçalhos IPsec no pacote, como o cabeçalho ESP. O cabeçalho IP que precede o AH deve ter o valor 51, que é o número mágico atribuído pela IANA para AH que informa o aplicativo de processamento de pacotes que a próxima coisa de que ele verá é um AH. A Figura 1 mostra a forma de um pacote depois de ter um AH adicionado a ela.

No modo de encapsulamento, o AH é adicionado após o novo cabeçalho IP. O cabeçalho IP encapsulado é tratado como parte da carga, juntamente com tudo. Isso é mostrado no Figura 2. Os primeiros 8 bits de um pacote protegido por AH especificar a ID de protocolo de carga que vem após o AH. Isso que esperar após a carga AH informa o receptor. Por exemplo, se o próximo protocolo da camada TCP, a identificação de protocolo será definida como 6. Este campo é denominado próximo cabeçalho. (Você deve estar imaginando por que ele não é conhecido como protocolo de maneira consistente com outros cabeçalhos no IPv4. O motivo é consistência e a compatibilidade com o IPv6. Felizmente, você não precisa realmente saber muito sobre o IPv6 para compreender como AH funciona em sua rede IPv4, mas se você foram se perguntando por que ele é chamado próximo cabeçalho, é por isso que.)

Em seguida vem o comprimento de 7 bits de carga AH. Já que há somente 7 bits, tamanho da carga é limitado a 128 bytes. Em seguida, vem uma longa seqüência de caracteres de zeros--2 bytes, de fato. Esses 2 bytes são reservados para uso futuro de acordo com a RFC, portanto, até que o uso futuro é definido, temos de 2 bytes vazias que estão apenas junto para o simultaneamente.

Após esses bytes 2 é o índice de parâmetro de segurança (SPI). Isso é um número 32 bits que é usado para determinar qual associação de segurança de IPsec (SA) está associado com o AH. Falarei em detalhes sobre associações de segurança quando eu discutir IKEv2. Esse número é seguido por um número de seqüência de 32 bits, que é incrementado com cada pacote enviado e é usado para impedir ataques de repetição.

Após a seqüência de número é fornecido o valor de verificação de integridade (ICV). O ICV é calculado ao remetente pela aplicação de uma função hash, como SHA-2, para o cabeçalho IP, o AH e a carga. O receptor verifica que o pacote não foi adulterado aplicando a mesma função de hash e confirmando que o mesmo hash é produzido a.

EU ter ESP

Como AH, ESP (Encapsulating Security PAYLOAD) pode fornecer integridade e autenticação. Ao contrário do AH, entretanto, o ESP fornece integridade e autenticação somente para a carga do pacote, não para o cabeçalho do pacote. ESP também pode ser usado para fornecer confidencialidade criptografando a carga do pacote. Em teoria, esses recursos de ESP podem ser ativados independentemente, portanto, é possível ter criptografia sem autenticação e integridade, ou para integridade e autenticação sem criptografia. Na prática, entretanto, seguindo um sem o outro não fazer muito sentido. Por exemplo, saber que uma mensagem foi enviada para mim confidencialmente não me qualquer bom se eu não é possível também ser completamente se quem a enviou. ESP é definido no RFC 4303.

ESP, como AH, pode ser ativado no modo de túnel ou modo de transporte. O cabeçalho ESP deve ser inserido após o AH. No modo de transporte, o ESP criptografa a carga do pacote IP. No modo de encapsulamento ESP tratará todo o pacote encapsulado como a carga e a criptografa. O processo é ilustrado na Figura 3.

O algoritmo de criptografia é escolhido através de um processo de negociação entre os pontos que configurou a SA IPsec. Padrão de criptografia avançada (AES) é uma opção comum de algoritmo de criptografia para implementações modernos. Claro, para usar AES, primeiro você deve ter um segredo compartilhado para os dois hosts que estão prestes a iniciar uma comunicação segura. Dando manualmente a chave compartilhada para o host é uma abordagem impraticável porque ele não escala, mas você pode usar troca de chaves Diffie-Hellman (DH) para configurar o segredo.

Grupos Diffie-Hellman

DH é um protocolo que permite que duas partes compartilhar um segredo por um canal inseguro e é parte integrante a negociação que ocorre no IKE. O segredo compartilhado que é comunicado por meio de DH pode ser usado para criar um canal de comunicação é criptografado com segurança. A matemática entra em DH é complexa e não entrarei em-lo em detalhes aqui. Se você estiver interessado em aprender mais sobre isso, verifique os recursos que abordam modulares grupos (MODP) exponenciais e seus aplicativos para DH. Para nossos objetivos, ele é suficiente dizer que um grupo DH é um conjunto específico de números com uma relação matemática e uma identificação de grupo exclusivas.

Um grupo DH é especificado quando uma conexão segura está sendo configurada com o IPsec, durante a negociação IKE. Essa negociação, os dois pontos tentando estabelecer uma conexão segura precisará localizar um grupo DH que ambos oferecem suporte. Grupos de DH com identificações superiores têm maior segurança criptográfica. Por exemplo, os grupos de DH primeiro chamados na especificação do IKE original tinham sobre a segurança criptográfica mesma como uma chave simétrica com entre os bits de 70 e 80. Com o advento dos algoritmos de criptografia mais fortes, como AES, era necessária de grupos DH para evitar que os grupos de DH se torne um elo fraco da cadeia de criptografia mais intensidade. Portanto, os grupos de DH mais recentes especificados na RFC 3526 fornecem força estimada entre 90 e 190 bits.

Esses grupos DH mais recentes a desvantagem é que sua maior força tem um custo: com os grupos mais fortes, mais tempo de processamento é necessário. Essa é uma das razões por colegas precisam negociar um grupo DH mutuamente aceitável. Por exemplo, meu telefone não pode ter potência de processamento suficiente para lidar com o grupo DH 15, para que ele deseja oferecer suporte a somente grupo DH 2. Enquanto tentando estabelecer uma conexão de IPsec com um servidor, meu telefone irá propor grupo DH 2, e se o servidor suportar grupo DH 2, esse grupo será usado--mesmo se o servidor poderia potencialmente ter usado um grupo DH mais forte. Obviamente, se os dois pontos não concordam em um grupo DH comuns, eles não poderão se comunicar.

Isso é suficiente plano de fundo. Vamos falar sobre IKE.

Eu como IKE (e até deve você)

IKE é usado para estabelecer uma conexão de IPsec entre pontos. Esta conexão é chamada de uma associação de segurança (SA). Há dois tipos de associações de segurança, o IKE_SA e o CHILD_SA. O IKE_SA é configurado primeiro. É onde o segredo compartilhado é negociado sobre DH e onde criptografia e algoritmos de hash também são negociados. O CHILD_SA é onde o tráfego de rede é enviado, protegido por AH, ESP ou ambos.

Todas as solicitações no IKE requer uma resposta, o que torna conveniente pensar em termos de pares de mensagens. A primeira mensagem par é chamado IKE_SA_INIT e é usado para decidir qual algoritmo de criptografia e DH grupo os pontos deve usar. Desde que ainda está sendo determinada criptografia durante essa troca, esse par de mensagem não está criptografado. O próximo par de mensagens é chamado IKE_SA_AUTH. Essa troca autentica as mensagens enviadas durante IKE_SA_INT e comprova a identidade do iniciador e respondedor. Essa etapa é necessária porque a primeira mensagem foi enviada em Limpar--ter estabelecido um canal seguro, os pontos agora precisa provar uns aos outros que elas realmente são quem eles dizem que elas são e que eles realmente devem iniciar esta conversa. A troca de mensagens IKE_SA_AUTH também configura CHILD_SA primeiro, que é freqüentemente CHILD_SA somente criada entre os pontos.

Um CHILD_SA é uma conexão simplex--ou unidirecional--, para que CHILD_SAs sempre são configurados no pares. Se uma SA em um par for excluída, o outro também deverão ser excluído. Isso é manipulado no IKE por meio de mensagens informativa. Por RFC 4306, uma mensagem informativa contém zero ou mais mensagens de notificação, excluir ou configuração. Digamos que temos um iniciador que é um PC e um respondedor é um servidor. O PC decide para fechar a conexão CHILD_SA e encerrar a conexão VPN. Ele envia uma mensagem informativa com uma carga de exclusão para o servidor, que identifica a SA para excluir por seu SPI. O servidor, em seguida, exclui essa entrada SA e envia uma resposta para o PC para excluir sua metade da SA. O computador recebe essa mensagem e exclui sua metade da SA e tudo o que é ótimo.

Obviamente, as coisas podem não funcionar sempre dessa maneira. Ou um iniciador como um respondedor pode terminar com uma SA em um "meia-fechado"estado, onde um membro do par SA é fechado, mas o outro é aberto. A RFC Especifica que esta é uma condição anômalo, mas ele não permita para um ponto fechar as conexões semi abertas por si só. Em vez disso, o elemento de mesmo nível deve para excluir o IKE_SA se o estado da conexão ficar suficientemente instável--mas excluir o IKE_SA exclui alf CHILD_SAs que foram criados abaixo dela. Ambos os casos seria penoso em um telefone porque manter aberto o CHILD_SA poderia consumir recursos do sistema escasso, como faria precisar subdividir e recriar o IKE_SA.

Além disso, é possível que um ponto no final de uma SA para desaparecer completamente, sem informando o sistema no outro lado da SA que é uma boa idéia. Esta é uma circunstância está especialmente propensa a ocorrer com telefones móveis. Por exemplo, considere um cenário em que um usuário de telefone celular estabeleceu uma conexão VPN de IPsec com um servidor. O usuário de telefone celular entra em um porão e perde seu sinal de rádio. O servidor não tem como saber que o telefone desapareceu em um buraco negro para que ele continua a enviar mensagens no CHILD_A, mas não recebe nenhuma resposta. Da mesma forma seria possível para o telefone para começar a enviar mensagens em um buraco negro devido a problemas de roteamento na rede celular. Tudo o que poderia causar um ponto perder o controle de outra pode levar a essa condição, mas o custo no telefone é maior do que o custo no servidor porque os recursos no telefone são mais escassos.

Por que é ruim para subdividir e recriar a associação de segurança?

A resposta curta é que divisão para baixo e recriar a associação de segurança usa recursos caros que can’t desperdiçar o telefone. Especificamente, CPU é consumida na realização de cálculos criptográficos e enquanto o rádio está em usar envio e recebimento de grandes quantidades de dados, ambos os quais custo vida útil da bateria. A grande quantidade de dados sendo transferidos também consome largura de banda, que custa dinheiro — especialmente em locais onde dados planos encargo pela kilobytes.

Como enviar uma mensagem no rádio os custos de energia e energia no telefone é limitada, o telefone precisa detectar essas situações de buraco negro e lidar com eles conservar os recursos do sistema. Isso é geralmente tratado por meio de um processo chamado inativo ponto detecção (DPD), no qual um ponto que suspects falar que ele pode ser com um buraco negro envia uma mensagem solicitando a prova de liveness. Se o destino desta solicitação não responder em um período de tempo apropriado, o remetente poderá levar a ação apropriada para excluir o IKE_SA e recuperar os recursos gastas nele. Em geral, é preferível para enviar mensagens DPD somente quando não há nenhum outro tráfego viajando pela SA e o elemento de mesmo nível tem razão para suspeitar que seu parceiro na SA não está lá. Enquanto há nenhuma exigência para implementar DPD dessa forma, não faz muito sentido para confirmar o liveness de um ponto que está enviando atualmente você outros tipos de tráfego de rede.

Outra situação pode causar problemas em uma conexão VPN é um host alterar seu endereço IP. O endereço IP de um host é usado junto com a SPI de 32 bits para identificar um determinado host e associá-lo com uma associação de segurança. Quando um host perde seu endereço IP, essa associação também é perdida e a SA precisa ser subdividido e recriada com o novo endereço IP.

Como dissemos antes, isso não é grande parte de um problema com computadores de mesa ou laptops. Um PC pode perder uma concessão de DHCP e obter um novo endereço IP, mas a maioria das implementações de DHCP fazer muito provável que o PC receberão o mesmo endereço IP que tinha antes. Em outras palavras, PCs de mesa não alterar endereços IP com muita freqüência. Laptops, porque eles são móveis, podem alterar seu ponto de anexo de rede e, portanto, obter um novo endereço IP, forçando qualquer SA tenham aberto para ser destruída e recriada. No entanto, a taxa em que os laptops alternar endereços IP é ainda relativamente raros quando comparado com a taxa em que um telefone faz. Por exemplo, um telefone que tem a capacidade de transmitir dados por meio de Wi-Fi e celulares canais pode alternar redes toda vez que um usuário percorre dentro ou fora do seu prédio, como o telefone muda de Wi-Fi para uma conexão GPRS e de volta novamente. Ao contrário de um laptop mover ao redor de um prédio, que pode permanecer na mesma conexão de rede e, portanto, continuar a ter um endereço de rede topologically correto sem uma alteração, o telefone alternou entre duas redes fundamentalmente diferentes, para praticamente é garantido para alteração de endereços IP. Isso resulta em uma conexão interrompida no telefone sempre que ocorre uma entrega entre redes. A mesma coisa pode acontecer enquanto o telefone estiver em rede celular sozinha. O telefone pode entrar no modo móvel e alterne de sua rede doméstica para uma rede externa pertencente a um outro operador móvel. O telefone pode mover de uma área de cobertura para outro e tornam-se à parte completamente diferente de rede da operadora do celular.

Não há qualquer número de outros motivos controlada pela operadora do celular pode causar uma conexão interrompida. Essa divisão freqüente para baixo e recriação da SA tornaria a VPN móvel intractable ele não eram para as extensões para IKEv2 conhecido como MOBIKE.

MOBIKE

O protocolo IKEv2 MOBIKE é definido no RFC 4555. Ele permite pontos em uma VPN de IPsec para anunciar que tenham vários endereços IP. Um desses endereços está associado com a SA para esse ponto. Se o elemento de mesmo nível for forçado para alternar o seu endereço IP devido a uma alteração em anexo da rede, um dos endereços IP identificados anteriormente, ou um endereço recém-atribuído, pode ser trocado em sem subdividir e recriar a associação de segurança.

Para indicar a capacidade de usar MOBIKE, um ponto inclui uma notificação MOBIKE_SUPPORTED na troca IKE_SA_AUTH. A troca IKE_AUTH também inclui os endereços adicionais para o iniciador e respondedor. O iniciador é o dispositivo que iniciado a configuração de VPN por enviar a primeira mensagem IKE e é responsável por tomar decisões sobre o qual os endereços IP para usar entre aqueles ele possui disponíveis e aqueles oferecidos a ele, o respondedor.

Como a RFC pontos de, o iniciador é geralmente o dispositivo móvel porque o dispositivo móvel tem mais conhecimento de sua posição na rede, e como um resultado melhor é adequado para tomar decisões sobre quais endereços usar. No entanto, a RFC não especifica como essas decisões devem ser feitas. Geralmente, uma extremidade de VPN IPsec será um dispositivo móvel e a outra extremidade será um servidor de gateway de segurança parado. A especificação não requer essa implementação e permite que ambas as extremidades do gateway para mover--mas ele não fornece uma maneira para as duas extremidades do gateway para encontrar uns aos outros novamente se eles se moverem ao mesmo tempo. Ou seja, se um ponto atualiza seu endereço e o outro ponto faz a mesma coisa ao mesmo tempo, não há nenhuma oportunidade para se comunicar essa alteração para um ponto e a conexão VPN serão perdida.

O iniciador usa a lista de endereços do respondedor para descobrir o melhor par de endereços para usar para a SA. O respondedor não usa endereços do iniciador, exceto como um meio de comunicação ao iniciador do que endereço do respondedor foi alterado.

Por exemplo, quando o iniciador vê que o endereço foi alterado, ele notifica o respondedor deste fato com uma mensagem informativa que contém uma notificação UPDATE_SA_ADDRESSES. Esta mensagem usa o novo endereço, que também inicia o que está sendo usado em mensagens de ESP do computador de mesmo. O receptor de notificação de atualização registra o novo endereço e opcionalmente verifica routability retorno ter certeza de que o endereço pertence a outro nó móvel conforme é solicitado. Depois disso, o respondedor é iniciado usando o novo endereço para o tráfego ESP de saída.

Claro que o iniciador ou respondedor pode não saber todos os endereços IP que ele nunca terá durante a vida útil da SA. Um ponto pode anunciar uma alteração na lista de endereços que ele oferece suporte a com uma mensagem informativa. Se o ponto tiver apenas um endereço, esse endereço está presente no cabeçalho e a mensagem contém a notificação NO_ADDITIONAL_ADDRESSES. Caso contrário, se o computador tiver vários endereços, um desses endereços é colocado no cabeçalho da mensagem informativa, e a outras pessoas são incluídas em uma notificação ADDITIONAL_IP4_ADDRESSES.

Esta lista não é uma atualização--ele é a lista inteira de endereços que deseja que o elemento de mesmo nível para anunciar nesse momento. Em outras palavras, a lista inteira é enviada sempre, mas esse custo é ainda menor do que o custo de divisão para baixo e recriar a associação de segurança sempre que o telefone altera seu ponto de anexo de rede.

Resumindo

Agora você deve ter uma idéia básica de como uma VPN de IPsec com MOBIKE funcionariam em um telefone celular.

A crescente prevalência de telefones inteligentes na home e área de trabalho será fazer essas soluções mais importante quando os usuários começam a exigem uma experiência que corresponde à em mais dispositivos de computação de recurso rich. Por enquanto, as pessoas são dispostas a aceitar telefones que não é possível se conectar a rede corporativa, que têm apenas um dia da vida útil da bateria e que sofrem de outras limitações do telefone inteligente que estão todos os familiarizados com. Isso não último. Concorrência e o surgimento de hardware melhor forçará a adoção de soluções de ponta a ponta, mais completas que permitem experiências para o telefone que estão no mesmo nível com o laptop e a área de trabalho.

E, em seguida, I, juntamente com pessoas, será capaz de procurar sites corporativos apenas clicando em um link no meu telefone.

Agradecimentos especiais a Melissa Johnson para suas sugestões e revisão técnica deste artigo.

Ramon Arjona é um cliente potencial SDET na Microsoft.