Este artículo proviene de un motor de traducción automática.

Avance

Una introducción a los IPsec de VPN en teléfonos móviles

Ramon Arjona

Esta tarde mientras estaba fuera de la oficina, aparece un mensaje de correo electrónico en mi teléfono. El mensaje tenía un vínculo a un documento que debía para leer--un documento en un sitio de SharePoint disponible sólo a través de intranet de mi organización. Esto fue un bummer porque tenía que esperar hasta que podría activar mi equipo portátil, poner mi tarjeta inteligente en el lector de tarjetas inteligentes, obtener una conexión Wi-Fi en una cafetería, conectar mi equipo portátil a la VPN corporativa y sesión antes de no se pudo leer el documento.

Vida sería mucho más fácil si sólo podría utilizar el teléfono para tener acceso al sitio de SharePoint. Por supuesto, mi teléfono necesitaría alguna forma mágica de conectarse de forma segura a la red corporativa y autenticarme. En otras palabras, como mi equipo portátil, mi teléfono sería necesario que la capacidad de iniciar una conexión VPN a la red. Muchos modelos de teléfono comercial, incluidos teléfonos de Windows vienen con un cliente VPN integrado. Pero hay inconvenientes en los clientes VPN más ampliamente disponibles como se basan en la versión 1 de una especificación de intercambio de claves de Internet (IKEv1). IKEv1 es una parte estable del marco de trabajo de IPsec y es ideal para dispositivos con cable o dispositivos, como los equipos portátiles con baterías relativamente grandes que no se mueven alrededor demasiado. Sin embargo, no es ideal para teléfonos móviles.

Por supuesto, utilizar una conexión inalámbrica en mi equipo portátil para ir desde mi oficina a una sala de conferencias y vuelva a hacer. Podría cambiar de una conexión inalámbrica a una red cableada y no espera pérdida de conectividad. Pero nos no mover casi tantos con un equipo portátil como se haría con un teléfono. Un teléfono le acompañará a través de tráfico y en y fuera de los edificios, transición dentro y fuera del estado móvil. ¿A menos que utilice un módem celular, cuándo se la última vez su equipo portátil dijimos que era móviles? Generalmente, un teléfono cambia su punto de datos adjuntos de la red con una frecuencia y la complejidad que un equipo portátil no tiene que preocuparse nunca. Los chicos que considerar acerca de la especificación IKEv1 no tienen que preocuparse de escenarios de teléfono móvil, porque no en la década, cuando se escribía la RFC 2409, teléfonos inteligentes sólo eran muy extendidos en el mercado. Desde entonces, ha skyrocketed el uso de teléfonos móviles y la importancia del teléfono móvil ha empezado a enfocar la importancia de mayores, otros dispositivos informáticos, como la estación de trabajo o el equipo portátil.

No es adecuado para un estilo muy móvil de la informática porque IKEv1 no tiene una buena forma hacer frente a un host que pueden cambiar su punto de datos adjuntos de red several times en segundos a few IKEv1. Cuando se redactó IKEv2, un conjunto de extensiones denominado protocolo de movilidad y de host múltiple (MOBIKE) también se ha redactado para acomodar el escenario de teléfono móvil. Mediante estas extensiones, 2009a móvil VPN será mucho más práctico. Varios productos en el mercado admiten IKEv2 y MOBIKE, incluidos Microsoft Systems Center Mobile Device Manager (SCMDM).

En este artículo, trataré algunos de los fundamentos de la tecnología subyacente IKEv2 y MOBIKE. Supone que tiene conocimientos de IPv4 y redes familiarizado con teléfonos móviles y un conocimiento básico de criptografía. En este artículo no se va a cubrir IPsec en detalle y no se va a tratar a otros tipos de tecnologías VPN, tales como VPN basadas en SSL. También no trataré IPv6. IPsec e IKE son extensiones a IPv4, pero están preparados en IPv6, por lo tanto, algunas cosas que se va Aluda aquí seguirá aplicable en una red IPv6. Sin embargo, IPv6 presenta suficiente complejidad y la terminología nueva que sería posible cubrir con suficiente detalle.

Diga ‘ AH ’

Tres protocolos constituyen el núcleo de IPsec: Encabezado de autenticación (AH), carga de seguridad de encapsulación (ESP) y IKE. Para dirección a IKE, primero es necesario tratar AH y ESP.

En pocas palabras, AH asegura que los paquetes que enviamos no alterados. Protege la integridad de nuestros paquetes. AH también garantiza que se envían los paquetes de quien dice les ha enviado. Se garantiza la autenticidad de nuestros paquetes. AH no, proporciona sin embargo, cualquier medida de privacidad o cifrado. Un atacante que obtuviera acceso a la red aún no pudo rastrear paquetes que protegido mediante AH y extraer su contenido. No, no obstante, podrán enmascararse como una de las partes autenticadas ni podrá cambiar nuestros paquetes en tránsito. AH se define en RFC 4302.

Por ejemplo, Alicia y Roberto ha establecido una conexión VPN entre sí y ha decidido proteger sus paquetes con AH. Carlos inserta a sí mismo en la red y inicia intercepten los paquetes. Carlos es capaz de reconstruir Alice y Bob conversación ya que puede ver el contenido de sus paquetes y discernir qué tipo de tráfico pasa entre ellos. Sin embargo, no puede falsificar un mensaje desde Alicia a Benito sin obtener detectada y no puede modificar los mensajes de Bob a Alicia, o bien. Ambas características pueden evitarse con AH.

AH puede utilizarse en modo de transporte o en modo de túnel. En modo de transporte, la carga de un paquete está protegida y los paquetes se enrutan directamente desde un host a otro. En modo de túnel, todo el paquete está protegido mediante AH y los paquetes se enrutan desde un extremo de un "túnel" IPseca otro. Túnel se consigue mediante la encapsulación del paquete original. En cualquier extremo del túnel es una puerta de enlace de seguridad. La puerta de enlace que está enviando un paquete es responsable de encapsular ese paquete agregando un "outer"Encabezado IP y dirección. Esta dirección externa enruta el paquete a la puerta de enlace de seguridad el otro extremo del túnel. La puerta de enlace que recibe el paquete es responsable de procesar el encabezado de autenticación para determinar que el paquete es de un remitente válido y no ha sido alterado, y a continuación, enruta el paquete a su destino final.

En el modo de transporte, se agrega un AH al paquete justo después del encabezado IP. El AH precede el protocolo de capa siguiente en el paquete (como UDP o TCP) y también antes otros encabezados de IPsec en el paquete, como el encabezado de ESP. El encabezado IP que precede el encabezado de autenticación debe tener el valor 51, que es el número mágico asignado por la IANA a AH que indica la aplicación de procesamiento del paquete que lo siguiente que verá es un AH. La figura 1 muestra la forma de un paquete después de tener un AH agregan a él.

En el modo de túnel, el encabezado de autenticación se agrega después del encabezado IP nuevo. El encabezado IP encapsulado se trata como parte de la carga, junto con todo lo demás. Esto se muestra en la figura 2. Los primeros 8 bits de un paquete protegido mediante AH especifique el identificador protocolo de la carga que viene después el encabezado de autenticación. Esto indica qué esperar después de la carga AH el receptor. Por ejemplo, si el siguiente protocolo de capa es TCP, el identificador de protocolo se establecerá a 6. Este campo se denomina encabezado siguiente. (Puede estar preguntando por qué no es la denominada protocolo de manera coherente con otros encabezados en IPv4. El motivo es la coherencia y la compatibilidad con IPv6. Afortunadamente, realmente no es necesario saber mucho sobre IPv6 para comprender cómo AH funciona en la red de IPv4, pero si se pregunta por qué se denomina encabezado siguiente, por eso.)

A continuación se incluye la longitud de 7 bits de la carga AH. Puesto que hay sólo 7 bits, tamaño de carga está limitado a 128 bytes. A continuación, incluye una cadena larga de ceros--2 bytes de ellos, de hecho. Estos 2 bytes están reservados para futuro uso según a la solicitud de cambio, por lo tanto, hasta que se define un uso futuro, tenemos 2 bytes vacías que simplemente junto el golpe.

Siguiente estos bytes 2 es el índice de parámetros de seguridad (SPI). Esto es un número de 32 bits que se utiliza para determinar qué asociación de seguridad IPsec (SA) está asociado con el encabezado de autenticación. Hablaré en detalle acerca de SA cuando hable de IKEv2. Este número es seguido por un número de secuencia de 32 bits, que se incrementa con cada paquete enviado y se utiliza para evitar ataques de reproducción.

Después de la secuencia de número incluye el valor de comprobar integridad (ICV). El valor ICV se calcula en el remitente aplicando una función hash, como SHA-2, el encabezado IP, el encabezado de autenticación y la carga. El receptor comprueba que el paquete no ha sido alterado aplicando el hash función mismo y confirmar que se produce el mismo valor hash.

Utilizar ESP

Como AH, carga de seguridad encapsuladora (ESP) puede proporcionar integridad y autenticación. A diferencia de AH, sin embargo, ESP proporciona autenticación e integridad sólo para la carga del paquete, no para el encabezado del paquete. ESP puede utilizarse también para proporcionar confidencialidad al cifrar la carga del paquete. En teoría, estas características de ESP se pueden habilitar de forma independiente, por lo que es posible tener cifrado sin autenticación e integridad, o integridad y autenticación sin cifrado. No en la práctica, obstante, uno sin el otro no realizar una gran idea. Por ejemplo, saber que un mensaje se ha enviado a mí confidencialmente no me cualquier buena si no se puede también ser completamente seguro quién lo envió. ESP está definido en RFC 4303.

ESP como AH, puede habilitarse en modo de túnel o en modo de transporte. El encabezado ESP debe insertarse tras el encabezado de autenticación. En el modo de transporte, ESP cifra la carga del paquete IP. En el modo de túnel, ESP trata todo el paquete encapsulado como la carga y lo cifra. Esto se muestra en la figura 3.

Se elige el algoritmo de cifrado mediante un proceso de negociación entre los interlocutores de establecer la SA de IPsec. Estándar de cifrado avanzado (AES) es una elección comunes de algoritmo de cifrado para implementaciones modernas. Por supuesto, para usar AES, debe tener un secreto compartido para los dos hosts que se va a iniciar una comunicación segura. Dar manualmente la clave compartida al host es un enfoque práctico, porque no escala, pero puede utilizar el intercambio de claves de Diffie-Hellman (DH) para suministrar el secreto.

Grupos Diffie-Hellman

DH es un protocolo que permite que dos partes comparten un secreto en un canal inseguro, y es esencial para la negociación tiene lugar en IKE. El secreto compartido que se comunica a través de DH puede utilizarse para crear un canal de comunicación se cifra de forma segura. Los cálculos se trasladará DH es complejo y no se entraré en aquí en detalle. Si está interesado en aprender más sobre él, compruebe los recursos que cubren modulares grupos (MODP) exponenciales y su aplicación a DH. Para nuestros fines, es suficiente para decir que un grupo DH es una colección específica de números con una relación matemática y un ID de grupo único.

Un grupo DH se especifica cuando una conexión segura se está configurando con IPsec, durante la negociación IKE. En esta negociación, necesita buscar un grupo DH que ambos admiten los dos interlocutores intentaba establecer una conexión segura. Los grupos DH identificadores superiores tener mayor intensidad de cifrado. Por ejemplo, los grupos DH primero que se llaman de la especificación original de IKE tenían acerca de la misma eficacia criptográfica como una clave simétrica, con entre 70 y 80 bits. Con la llegada de algoritmos de cifrado más seguros como AES, era necesario de los grupos DH para impedir que los grupos DH convertirse en un vínculo débil en la cadena de cifrado más intensidad. Por tanto, los grupos DH más recientes especificados en RFC 3526 proporcionan estimado intensidad entre 90 y 190 bits.

La desventaja de estos grupos DH más recientes es que sus mayor intensidad tiene un costo: con los grupos más seguros, es necesario más tiempo de procesamiento. Éste es uno de los motivos por qué compañeros necesitan negociar un grupo DH mutuamente aceptable. Por ejemplo, mi teléfono podría no tener suficiente capacidad de procesamiento para tratar con el grupo DH 15, por lo que desea admitir sólo grupo DH 2. Mientras intentaba establecer una conexión de IPsec con un servidor, mi teléfono propondrá grupo DH 2 y, si el servidor admite grupo DH 2, ese grupo se utilizará--incluso si el servidor podría haber utilizado potencialmente un grupo DH más eficaces. Por supuesto, si los dos interlocutores no acepta en un grupo DH comunes, no podrán comunicarse.

Eso en segundo plano suficiente. Hablemos de IKE.

Como a IKE (y para que se debe)

IKE se utiliza para establecer una conexión de IPsec entre interlocutores. Esta conexión se denomina una asociación de seguridad (SA). Hay dos tipos de SA y la IKE_SA el CHILD_SA. El IKE_SA se configura primero. Es donde se negocia el secreto compartido a través de DH y donde también se negocian cifrado y algoritmos hash. El CHILD_SA es donde se envía tráfico de red, protegido por AH, ESP o ambos.

Cada solicitud en IKE requiere una respuesta, que resulta conveniente pensar en términos de pares de mensajes. Debe utilizar el primer mensaje par se llama IKE_SA_INIT y se utiliza para decidir qué algoritmo criptográfico y DH agrupar a los interlocutores. Puesto que todavía se determina el cifrado durante este intercambio, este par de mensaje no está cifrado. El siguiente par de mensajes se denomina IKE_SA_AUTH. Este intercambio autentica los mensajes enviados durante IKE_SA_INT y demuestra la identidad del iniciador y el contestador. Este paso es necesario porque el primer mensaje se envió sin cifrar--tener establecido un canal seguro, los interlocutores ahora necesita demostrar a ellos que realmente son quienes dicen que son y que realmente pretendía iniciar esta conversación. El intercambio de mensajes IKE_SA_AUTH también configura el primer CHILD_SA, que es con frecuencia el CHILD_SA sólo creó entre los interlocutores.

Un CHILD_SA es una conexión más simple, o unidireccional--, por lo que CHILD_SAs siempre se configuran en pares. Si se elimina una SA en un par, debe también se eliminará el otro. Esto se controla en IKE mediante mensajes de información. Por RFC 4306, un mensaje de información contiene cero o más mensajes de notificación, eliminación o configuración. Supongamos que tenemos un iniciador de un equipo y un contestador de un servidor. El equipo decide cerrar la conexión CHILD_SA y terminar la VPN. Envía un mensaje de información con una carga eliminar al servidor, que identifica la SA para eliminar por su SPI. El servidor elimina esta SA entrante y envía una respuesta al equipo para eliminar su mitad de la SA. El equipo recibe este mensaje y elimina su mitad de la SA, y todo es estupendo.

Por supuesto, las cosas no siempre funcionen de esta forma. En un iniciador o un contestador podría acabar con una SA en un "cerrado en mitad"estado, donde un miembro del par de SA está cerrado, pero el otro está todavía abierto. La solicitud especifica que ésta es una condición anómala, pero no permite para que un interlocutor cerrar estas conexiones semiabiertas por sí mismo. En su lugar, se supone que el interlocutor para eliminar el IKE_SA si el estado de conexión inestable suficientemente--pero eliminar el IKE_SA elimina alf CHILD_SAs en el que se crearon por debajo de ella. Cualquiera de los casos sería difícil en un teléfono dado que mantener abierta la CHILD_SA podría consumir recursos escasos del sistema, ya debería tener que destruir y volver a generar el IKE_SA.

Además, es posible que un igual al final de una SA a desaparecer por completo, sin que indica el sistema del otro lado de la SA es bueno. Se trata de una circunstancia que es especialmente propensa a producir con teléfonos móviles. Por ejemplo, considere un escenario en que un usuario móvil ha establecido una conexión VPN de IPsec con un servidor. El usuario de teléfono móvil entra en un sótano y pierde su señal de radio. El servidor no tiene forma de saber que el teléfono ha desaparecido en un agujero negro para continúa enviando mensajes en el CHILD_A pero no recibe ninguna respuesta. Asimismo, sería posible para el teléfono iniciar el envío de mensajes en un agujero negro debido de problemas de enrutamiento en la red celular. Todo lo que podría provocar un interlocutor de perder la pista de otra puede provocar esta condición, pero el coste en el teléfono es mayor que el costo en el servidor porque los recursos en el teléfono son más escasos.

¿Por qué está dañado incorrecta a TEAR Down y volver a generar la SA?

La respuesta corta es que desgarro hacia abajo y volver a generar la SA utiliza recursos costosos que el teléfono no puede permitirse perder. Específicamente, se consume CPU en cálculos criptográficos y mientras la radio está en Utilice enviar y recibir grandes cantidades de datos, de costo de la batería. La gran cantidad de datos transferidos también consume ancho de banda, lo que cuesta dinero, especialmente en lugares donde los datos planes cargo por el kilobytes.

Dado que enviar un mensaje de la energía de los costos de radio y energía en el teléfono está limitado, el teléfono necesita estas situaciones de agujero negro de detectar y tratar con ellos para ahorrar recursos del sistema. Normalmente esto se controla mediante un proceso denominado detección de punto muerto (DPD), en el que un interlocutor que sospecha que podría ser hablar a un agujero negro envía un mensaje exigentes pruebas de liveness. Si el destino de esta solicitud no responde en un período de tiempo apropiado, el remitente puede tardar acción apropiada para eliminar el IKE_SA y reclamar los recursos dedicado en él. En general, es preferible enviar mensajes DPD sólo cuando no hay ningún otro tráfico viaja a través de la asociación de seguridad y el interlocutor tiene razón sospecha que su socio en la asociación de seguridad ya no existe. Aunque no existe ningún requisito para implementar DPD esta forma, no tiene sentido mucho para confirmar liveness de un interlocutor que actualmente es enviar a otros tipos de tráfico de red.

Otra situación que puede causar problemas en una conexión VPN es un host cambie su dirección IP. La dirección IP de un host se utiliza junto con el SPI de 32 bits para identificar un host determinado y asociarlo con una asociación de seguridad. Cuando un host pierde su dirección IP, también se pierde esta asociación y la asociación de seguridad debe ser destruido y vuelve a crear con la nueva dirección IP.

Como ha dijimos antes, esto no es gran parte de un problema con equipos de escritorio o portátiles. Un equipo puede perder una concesión DHCP y obtener una nueva dirección IP, pero la mayoría de implementaciones de DHCP facilitar muy probable que el equipo se asignará la misma dirección IP que tenía antes. En otras palabras, equipos de escritorio no cambian las direcciones IP de muy a menudo. Los equipos portátiles, porque son portátiles, pueden cambiar su punto de datos adjuntos de la red y, por lo tanto, obtener una nueva dirección IP, forzar cualquier SA tienen abierto a se destruye y vuelve a crear. Sin embargo, la velocidad a la que los equipos portátiles cambiar direcciones IP es todavía relativamente poco frecuente cuando se compara con la velocidad a la que tiene un teléfono. Por ejemplo, un teléfono que tenga la capacidad de transmitir datos a través de Wi-Fi y canales celulares podría cambiar redes cada vez que un usuario recorre o salen de su edificio que el teléfono cambia desde una fidelidad a una conexión GPRS y nuevo. A diferencia de un equipo portátil desplazarse por un edificio, de oficinas que podría permanecer en el mismo vínculo de red y, por lo tanto, sigue teniendo una dirección de red topologically correcta sin un cambio, el teléfono ha cambiado entre dos redes fundamentalmente diferentes, por lo que se garantiza prácticamente para cambiar direcciones IP. Esto produce una conexión interrumpida en el teléfono produce una entrega entre redes. Lo mismo puede ocurrir mientras el teléfono está en la red celular únicamente. El teléfono podría entrar en modo móvil y cambiar de su red doméstica a una red externa que pertenecen a un operador móvil diferente. El teléfono podría mover de un área de cobertura a otro y se adjunta a una parte totalmente distinta de red del operador móvil.

Hay cualquier número de otros motivos controlado por el operador móvil que podría provocar que una conexión interrumpida. Este desgarro frecuentes hacia abajo y regeneración de la asociación de seguridad sería la VPN móvil irreparable no eran las extensiones para IKEv2 conocido como MOBIKE.

MOBIKE

El protocolo IKEv2 MOBIKE se define en RFC 4555. Permite colegas en una VPN de IPsec para anunciar que tienen varias direcciones IP. Una de estas direcciones se asocia con la SA para ese punto. Si el interlocutor se fuerza para cambiar su dirección IP debido a un cambio en datos adjuntos de la red de, una de las direcciones IP identificadas previamente, o una dirección recién asignada, se puede intercambiar en sin tener que destruir y volver a generar la SA.

Para indicar su capacidad de utilizar MOBIKE, un elemento homólogo (peer) incluye una notificación MOBIKE_SUPPORTED en el intercambio IKE_SA_AUTH. El intercambio IKE_AUTH también incluye las direcciones adicionales para el iniciador y el contestador. El iniciador es el dispositivo que inicia la instalación de la VPN envía el primer mensaje de IKE y es responsable de tomar decisiones acerca de cuál de las direcciones IP para utilizar entre los tiene disponible y los que ofrece a ella por el interlocutor que responde.

Como se señala la solicitud de cambio, el iniciador resulta normalmente el dispositivo móvil porque el dispositivo móvil tiene más conocimiento de su posición en la red y como resultado mejor es adecuado para tomar decisiones sobre qué direcciones para utilizar. Sin embargo, la solicitud no especifica cómo deben hacerse estas decisiones. Generalmente, un extremo de la VPN IPsec será un dispositivo móvil, y el otro extremo será un servidor de puerta de enlace de seguridad fija. La especificación no requiere esta implementación y permite ambos extremos de la puerta para mover--pero no proporciona una manera para los dos extremos de la puerta de enlace para encontrar entre sí nuevo si mueven al mismo tiempo. Es decir, si un interlocutor actualiza su dirección y el otro interlocutor hace lo mismo al mismo tiempo, no hay ninguna oportunidad para comunicar este cambio a cualquier punto y se perderán la conexión VPN.

El iniciador utiliza lista de direcciones del contestador para averiguar la mejor pareja de direcciones para la SA. El contestador no utiliza las direcciones del autor, excepto como medio para comunicarse con el iniciador que dirección del contestador ha cambiado.

Por ejemplo, cuando el iniciador ve que ha cambiado su dirección, lo notifica al contestador de este hecho con un mensaje información que contiene una notificación UPDATE_SA_ADDRESSES. Este mensaje utiliza la dirección nueva, que inicia también se utiliza en mensajes de ESP del interlocutor. El receptor de la notificación de actualización registra la nueva dirección y, opcionalmente, comprueba routability devuelto para asegurarse de que la dirección pertenece a otro nodo móvil como reclama. A continuación, el contestador inicia con la nueva dirección para su tráfico saliente de ESP.

Por supuesto el iniciador o contestador podría no saber todas las direcciones IP que nunca tendrá la duración de la asociación de seguridad. Un interlocutor puede anunciar un cambio en la lista de direcciones que admite con un mensaje de información. Si el interlocutor tiene sólo una dirección, esta dirección está presente en el encabezado y el mensaje contiene la notificación NO_ADDITIONAL_ADDRESSES. En caso contrario, si el interlocutor tiene varias direcciones, una de estas direcciones se coloca en el encabezado del mensaje de información y los otros se incluyen en una notificación ADDITIONAL_IP4_ADDRESSES.

Esta lista no es una actualización, es la lista completa de direcciones que el interlocutor desea anunciar en ese momento. En otras palabras, la lista completa se envía cada vez, pero este costo es aún menor que el costo de desgarro hacia abajo y volver a generar la SA cada vez que el teléfono cambia su punto de datos adjuntos de la red.

Conclusión

Ahora debería tener una idea básica de cómo una VPN de IPsec con MOBIKE funcionarían en un teléfono móvil.

La creciente presencia de los teléfonos inteligentes en el principal y el área de trabajo va a realizar estas soluciones más importante como los usuarios comienzan a petición una experiencia que coincida con en dispositivos informáticos de más completo de recursos. Por el momento, las personas están dispuestas a Aceptar teléfonos que no se pueden conectar a la red corporativa, que tienen sólo un día de la batería y que sufren los otros defectos del teléfono inteligente que se conocen todos los. No esto último. Competencia y la aparición de hardware mejor forzará la adopción de soluciones más completos y extremo a extremo que habilitar experiencias para el teléfono que están junto con el equipo portátil y escritorio.

Y, a continuación, I, junto con todos los demás, será capaz de explorar sitios de SharePoint corporativos sólo haciendo un vínculo en mi teléfono.

Agradecimientos especiales a Melissa Johnson para su sugerencias y revisión técnica de este artículo.

Ramon Arjona es un jefe SDET en Microsoft.