ES2336898T3 - Metodo y red para asegurar el envio seguro de mensajes. - Google Patents
Metodo y red para asegurar el envio seguro de mensajes. Download PDFInfo
- Publication number
- ES2336898T3 ES2336898T3 ES02762486T ES02762486T ES2336898T3 ES 2336898 T3 ES2336898 T3 ES 2336898T3 ES 02762486 T ES02762486 T ES 02762486T ES 02762486 T ES02762486 T ES 02762486T ES 2336898 T3 ES2336898 T3 ES 2336898T3
- Authority
- ES
- Spain
- Prior art keywords
- terminal
- ipsec
- mobile terminal
- address
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/03—Protecting confidentiality, e.g. by encryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/20—Manipulation of established connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
- H04W80/04—Network layer protocols, e.g. mobile IP [Internet Protocol]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Small-Scale Networks (AREA)
Abstract
El método para asegurar el envío seguro de mensajes en una red de telecomunicación, que comprende al menos un terminal móvil (1) y otro terminal (2), el método que comprende: a) establecer una conexión segura entre la dirección del terminal móvil (1) y el otro terminal (2), la conexión segura que se define por al menos las direcciones de los dos terminales (1, 2), b) el terminal móvil (1) moviéndose a una nueva dirección, caracterizado por c) enviar un mensaje desde el terminal móvil (1) al otro terminal móvil (2) para el registro de la nueva dirección del terminal móvil (1), como un resultado de cuyo mensaje se actualiza la conexión segura entre el terminal móvil (1) y dicho otro terminal (2) cambiando la dirección del terminal móvil (1) en la definición de dicha conexión segura establecida entre los dos terminales (1, 2).
Description
Método y red para asegurar el envío seguro de
mensajes.
El método y la red de la invención pretenden
asegurar las conexiones móviles en redes de telecomunicaciones.
Especialmente, está dirigido a conexiones IPSec.
Una interred es una colección de redes
individuales conectadas con dispositivos de conexión en red
(creación de redes) intermedios y funciones como una red grande
única. Se pueden interconectar distintas redes por encaminadores y
otros dispositivos de conexión en red para crear una interred.
Una red de área local (LAN) es una red de datos
que cubre un área geográfica relativamente pequeña. Típicamente
conecta estaciones de trabajo, ordenadores personales, impresoras y
otros dispositivos. Una red de área extensa (WAN) es una red de
comunicación de datos que cubre un área geográfica relativamente
amplia. Las redes de área extensa (WANs) interconectan LANs a
través de líneas telefónicas normales y, por ejemplo, redes ópticas;
interconectando por ello usuarios dispuestos geográficamente.
Hay una necesidad de proteger los datos y los
recursos de la divulgación, para asegurar la autenticidad de los
datos, y proteger los sistemas de los ataques basados en la red. Más
en detalle, hay una necesidad de confidencialidad (proteger los
contenidos de los datos de ser leídos), integridad (proteger los
datos de ser modificados, lo que es una propiedad que es
independiente de la confidencialidad), autenticación (obtener
certeza sobre el remitente real de los datos), protección de
repetición (garantizar que los datos son recientes, y no una copia
de datos previamente enviados), protección de identidad (mantener
las identidades de las partes que intercambian los datos secretas
de intrusos), alta disponibilidad, es decir protección de denegación
de servicio (asegurando que el sistema funciona incluso cuando se
encuentran bajo ataque) y control de acceso. IPSec es una
tecnología que proporciona la mayoría de éstas, pero no todas ellas.
(En particular, la protección de identidad no se maneja
completamente por IPSec, y tampoco lo es la protección de denegación
de servicio).
Los protocolos de seguridad IP (IPSec)
proporcionan la capacidad de asegurar las comunicaciones entre
ordenadores principales arbitrarios, por ejemplo a través de una
LAN, a través de redes de área extensa (WANs) públicas y privadas y
a través de Internet. IPSec se puede usar de diferentes maneras, tal
como para redes privadas virtuales seguras de edificios, para
obtener un acceso seguro a una red de empresa, o para asegurar la
comunicación con otras organizaciones, asegurando la autenticación
y la confidencialidad y proporcionando un mecanismo de intercambio
de claves. IPSec asegura confidencialidad, integridad,
autenticación, protección de repetición, confidencialidad limitada
del flujo de tráfico, protección limitada de identidad, y control de
acceso basado en identidades autenticadas. Incluso si algunas
aplicaciones ya se han incorporado en los protocolos de seguridad,
el uso de IPSec además mejora la seguridad.
IPSec puede cifrar y/o autenticar el tráfico a
nivel IP. El tráfico que va a una WAN típicamente se comprime y se
cifra y el tráfico que viene de una WAN está descifrado y
descomprimido. IPSec se define por ciertos documentos, que
contienen reglas para la arquitectura IPSec. Los documentos que
definen IPSec, son, por el momento, la serie de Petición de
Comentarios (RFC) del Grupo de Trabajo de Ingeniería de Internet
(IETF), en particular, las RFCs 2401-2412.
Se usan dos protocolos para proporcionar
seguridad en la capa IP; un protocolo de autenticación designado
por la cabecera del protocolo, Cabecera de Autenticación (AH), y un
protocolo combinado de cifrado/autenticación designado por el
formato del paquete para ese protocolo, Encapsulación de la Carga
Útil de Seguridad (ESP). AH y ESP son sin embargo protocolos
similares, ambos funcionando por medio de añadir una cabecera de
protocolo. Tanto AH como ESP son vehículos para el control de
acceso basado en la distribución de claves criptográficas y la
gestión de los flujos de tráfico relativos a estos protocolos de
seguridad.
La asociación de seguridad (SA) es un concepto
clave en la autenticación y los mecanismos de confidencialidad para
IP. Una asociación de seguridad es una relación en un sentido entre
un remitente y un destinatario que ofrece que ofrece servicios de
seguridad al tráfico mantenido en ella. Si es necesaria una
asociación segura en dos sentidos, entonces se requieren dos
asociaciones seguras. Si ESP y AH se combinan, o si ESP y/o AH se
aplican más de una vez, se usa el término manojo de SA, lo
que significa que se usan dos o más SAs. De esta manera, el manojo
SA se refiere a una o más SAs aplicadas en secuencia, por ejemplo
realizando primero una protección ESP, y luego una protección AH.
El manojo de SA es la combinación de todas las SA usadas para
asegurar un paquete.
El término conexión IPSec se usa a continuación
en lugar de un manojo IPSec de una o más asociaciones de seguridad,
o un par de manojos IPSec -un manojo para cada dirección- de una o
más asociaciones de seguridad. Este término cubre de esta manera
tanto la protección de tráfico unidireccional como bidireccional. No
hay implicación de simetría de las direcciones, es decir, las
transformaciones IPSec y los algoritmos usados para cada dirección
pueden ser diferentes.
Una asociación de seguridad se identifica
únicamente por tres parámetros. El primero, el Índice de los
Parámetros de Seguridad (SPI), es una cadena de bits asignada a
esta SA. El SPI se lleva en las cabeceras de AH y ESP para permitir
al sistema de recepción seleccionar la SA bajo la cual se procesará
un paquete recibido. La dirección de destino IP es el segundo
parámetro, que es la dirección del punto final de destino de la SA,
que puede ser un sistema de usuario final o un sistema de red tal
como un cortafuegos o un encaminador. El tercer parámetro, el
identificador de protocolo de seguridad indica si la asociación es
una asociación de seguridad AH o ESP.
En cada implementación IPSec, hay una base de
datos de asociación de seguridad (SADB) nominal que define los
parámetros asociados con cada SA. Una asociación de seguridad
normalmente se define por los siguientes parámetros. El Contador
del Número de Secuencia es un valor de 32 bits usado para generar el
campo de número de secuencia en las cabeceras AH o ESP. El
Desbordamiento del Contador de Secuencia es una bandera que indica
si el desbordamiento del contador del número de secuencia debería
generar un suceso auditable y prevenir la transmisión adicional de
paquetes en esta SA. Se usa una Ventana Anti Repetición para
determinar si un paquete entrante AH o ESP es una repetición. La
información AH implica la información sobre el algoritmo de
autenticación, las claves y los parámetros relacionados que se usan
con AH. La información ESP implica información de algoritmos de
autenticación y cifrado, claves, vectores de inicialización, y
parámetros relacionados que se usan con IPSec. El sexto parámetro,
el Tiempo de Vida de esta Asociación de Seguridad, es un intervalo
de tiempo y/o cuenta de bytes después de la cual una SA debe ser
sustituida con una nueva SA (y nuevo SPI) o terminada más una
indicación de cuál de estas acciones deberían ocurrir. El Modo de
Protocolo IPSec es o bien modo túnel o bien modo de transporte. La
MTU del Trayecto, que es una característica opcional, define el
máximo tamaño de un paquete que puede ser transmitido sin
fragmentación.
Tanto AH como ESP soportan los dos modos usados,
modo túnel y transporte.
El modo transporte proporciona protección
principalmente para los protocolos de capa superior y se extiende a
la carga útil de un paquete IP. Típicamente, el modo transporte se
usa para comunicación extremo a extremo entre dos ordenadores
principales. El modo transporte se puede usar en unión con un
protocolo de tunelización (distinto de tunelización IPSec).
El modo túnel proporciona protección al paquete
IP entero y generalmente se usa para enviar mensajes a través de
más de dos componentes, aunque el modo túnel se puede usar también
para comunicación extremo a extremo entre dos ordenadores
principales. El modo túnel se usa a menudo cuando uno o ambos
extremos de una SA son una pasarela de seguridad, tal como un
cortafuegos o un encaminador que implementa IPSec. Con el modo
túnel, una pluralidad de ordenadores principales en redes detrás de
los cortafuegos pueden participar en comunicaciones seguras sin
implementar IPSec. Los paquetes desprotegidos generados por tales
ordenadores principales se tunelizan a través de redes externas por
las SAs del modo túnel establecidas por los programas de IPSec en el
cortafuegos o el encaminador seguro en el límite de la red
local.
Para lograr esto, después de que son añadidos
los campos AH o ESP al paquete IP, el paquete entero más los campos
de seguridad se tratan como carga útil de un nuevo paquete IP
externo con una nueva cabecera IP externa. El paquete entero
original, o interno, viaja a través de un túnel de un punto de una
red IP a otro: ningún encaminador a lo largo del camino es capaz de
examinar el paquete IP interno. Debido a que el paquete original se
encapsula, el nuevo paquete mayor puede tener direcciones de origen
y destino totalmente distintas, añadiendo seguridad. En otras
palabras, el primer paso en protección del paquete usando modo túnel
es añadir una nueva cabecera IP al paquete; de esta manera el
paquete "IPIpayload" llega a ser "IPIIPIpayload". El
siguiente paso es asegurar el paquete usando ESP y/o AH. En el caso
de ESP, el paquete resultante es "IPIEPSIPIpayload". El
paquete interno entero se cubre por la protección AH y/o ESP. AH
también protege partes de la cabecera externa, además del paquete
interno entero.
El modo túnel de IPSec funciona por ejemplo de
tal forma que si un ordenador principal en una red genera un
paquete IP con una dirección de destino de otro ordenador principal
en otra red, el paquete se encamina desde el ordenador principal
originario a una pasarela de seguridad (SGW), cortafuegos u otro
encaminador seguro en el límite de la primera red. La SGW o similar
filtra todos los paquetes salientes para determinar la necesidad de
procesamiento IPSec. Si este paquete del primer ordenador principal
a otro ordenador principal requiere IPSec, el cortafuegos realiza
el procesamiento IPSec y encapsula el paquete en una cabecera IP
externa. La dirección IP de origen de esta cabecera IP externa es
este cortafuegos la dirección destino puede ser un cortafuegos que
forma el límite a la otra red local. Este paquete se encamina ahora
al otro cortafuegos del ordenador principal con encaminadores
intermedios que examinan solamente la cabecera IP externa. En el
otro cortafuegos de ordenador principal, la cabecera IP externa se
quita y el paquete interno se entrega al otro ordenador
principal.
ESP en el modo túnel cifra y opcionalmente
autentifica el paquete IP interno entero, incluyendo la cabecera IP
interna. AH en el modo túnel autentifica el paquete IP interno
entero, incluyendo la cabecera IP interna, y partes seleccionadas
de la cabecera IP externa. La parte de gestión de claves de IPSec
implica la determinación y distribución de claves secretas. El
protocolo de gestión de claves automatizadas por defecto para IPSec
se denomina ISAKMP/Oakley y consta del protocolo de determinación de
claves Oakley y el Protocolo de Gestión de Claves y Asociación de
Seguridad en Internet (ISAKMP). Intercambio de Claves en Internet
(IKE) es un nombre más nuevo para el protocolo ISAKMP/Oakley. IKE
se basa en el algoritmo Diffie-Hellman y soporta
autenticación de firma RSA entre otros modos. IKE es un protocolo
extensible, y permite que se añadan características específicas del
vendedor y futuras sin comprometer la funcionalidad.
IPSec se ha diseñado para proporcionar
confidencialidad, integridad, y protección de repetición para
paquetes IP. No obstante, IPSec tiene previsto trabajar con
topología de red estática, donde los ordenadores principales están
fijados a ciertas subredes. Por ejemplo, cuando un túnel IPSec se ha
formado usando el protocolo de Intercambio de Claves en Internet
(IKE), los puntos finales del túnel son fijos y permanecen
constantes. Si IPSec se usa con un ordenador principal móvil, el
intercambio de claves IKE tendrá que ser rehecho a partir de cada
nueva red visitada. Esto es problemático, porque los intercambios de
claves IKE implican cálculos de algoritmo de intercambio de claves
Diffie-Hellman caros computacionalmente y
posiblemente cálculos RSA. Adicionalmente, el intercambio de claves
requiere al menos tres idas y vueltas (seis mensajes) si se usa el
modo agresivo IKE seguido por el modo rápido IKE, y nueve mensajes
si se usa el modo principal IKE seguido por el modo rápido IKE.
Esto puede ser un gran problema en redes con alta latencia, tal como
el Servicio General de Radio por Paquetes (GPRS) a parte de los
gastos de cálculo.
En este texto, el término movilidad y terminal
móvil no significan solamente movilidad física, en su lugar el
término movilidad significa en primer lugar movimiento de una red a
otra, lo cual se puede realizar por un terminal físicamente fijo
también.
El problema con los puntos finales del túnel
IPSec estándar es que son fijos. Una SA está vinculada a una cierta
dirección IP y si se cambia, la SA IPSec existente llega a ser
inútil debido a que ha sido establecida usando distintas
direcciones de los puntos finales. El problema se ha tratado en el
foro de estandarización del IETF, www.IETF.org, en donde una idea
para soportar movilidad para los túneles ESP IPSec por medio de
señalización para actualizar la dirección de un extremo después de
un movimiento se mencionó por Francis Dupont. Ninguna solución no
obstante ha sido presentada hasta la fecha.
El protocolo IP Móvil estándar proporciona un
terminal móvil con una conexión móvil, y define los mecanismos para
realizar traspasos eficientes de una red a otra. No obstante, IP
Móvil tiene varias desventajas. La seguridad de IP Móvil es muy
limitada. Los mensajes de señalización de movilidad son
autenticados, pero no cifrados, y el tráfico de datos de usuario
está completamente desprotegido. También, no hay mecanismo de
intercambio de claves para establecer las claves criptográficas
requeridas para autenticar la señalización de movilidad. Tales
claves necesitan ser distribuidas típicamente de manera manual.
Finalmente, el protocolo IP Móvil actual no define un método para
trabajar a través de dispositivos de Traducción de Direcciones de
Red (NAT).
Una forma de resolver este problema es usar por
ejemplo IP Móvil para manejar la movilidad del ordenador principal,
y usar IPSec en la parte superior de la dirección IP estática
proporcionada por IP Móvil. De esta manera, las SAs IPSec se
vinculan a direcciones estáticas, y las SAs IPSec pueden salvar la
movilidad del ordenador principal. No obstante, este planteamiento
sufre de sobredimensionado del tamaño del paquete tanto de IP Móvil
como de los túneles IPSec, lo que puede afectar considerablemente el
rendimiento cuando se usan enlaces con flujo pequeño.
Las publicaciones WO 01/39538, 00/41427,
01/24560, y US2001/009025 y EP1 124 397 se mencionan como técnica
previa. La WO 01/39538 presenta una solución para transferir una
asociación de seguridad durante un traspaso del terminal móvil a un
nuevo punto de acceso. La WO 00/41427 está relacionada con la
reutilización de las asociaciones de seguridad para mejorar el
rendimiento de traspaso. Este método también implica desconectar la
unidad móvil de una primera unidad estacionaria y a partir de
entonces conectar la unidad móvil a una segunda unidad estacionaria
a la que se transfiere la asociación de seguridad. La WO 01/24560
presenta una técnica para el traspaso de una estación móvil
transfiriendo los parámetros clave necesarios para el cifrado a una
nueva estación base. La US 2001/009025 presenta una solución para
negociar una o más asociaciones de seguridad entre un ordenador
principal móvil y otro ordenador principal móvil sobre una Red
Privada Virtual (VPN). La EP1 124 397 presenta una solución para
seguridad simplificada para la transferencia en comunicaciones
inalámbricas. La información de seguridad se transfiere desde una
estación base directamente a otra.
Los documentos que definen IP en general son los
estándares RFC, RFC 768, RFC 791, RFC 793, RFC 826 y RFC 2460. Los
RFC 2002, RFC 2003, RFC 2131, RFC3115, IPv4 e IPv6 MÓVIL, y DHCPV6
definen IP Móvil, IP-IP y DHCP.
\vskip1.000000\baselineskip
La siguiente es una lista de referencias útiles
de los estándares mencionados. En general IP, TCP y UDP:
[RFC768]
J. Postel, Protocolo de Datagrama de
Usuario, RFC 768, agosto de 1980.
ftp://ftp.isi.edu/in-notes/rfc768.txt
\vskip1.000000\baselineskip
[RFC791]
J. Postel, Protocolo de Internet, RFC
791, septiembre de 1981.
ftp://ftp.isi.edu/in-notes/rfc791.txt
\vskip1.000000\baselineskip
[RFC792]
J. Postel, Protocolo de Mensaje de
Control en Internet, RFC 792, septiembre de 1981.
ftp://ftp.isi.edu/in-notes/rfc792.txt
\vskip1.000000\baselineskip
[RFC793]
J. Postel, Protocolo de Control de
Transmisión, RFC 793, septiembre de 1981.
ftp://ftp.isi.edu/in-notes/rfc793.txt
\vskip1.000000\baselineskip
[RFC826]
D.C. Plummer, Un Protocolo de Resolución
de Direcciones Ethernet, RFC 826, noviembre de 1982.
ftp://ftp.isi.
edu/in-notes/rfc826.txt
edu/in-notes/rfc826.txt
\vskip1.000000\baselineskip
[RFC2460]
S. Deering, R. Hinden,
Especificación del Protocolo de Internet, Versión 6 (IPv6), RFC
2460, diciembre de 1998.
\vskip1.000000\baselineskip
IP Móvil; IP-IP; DHCP:
[RFC2002]
C. Perkins, Soporte de Movilidad IP, RFC
2002, octubre de 1996.
ftp://ftp.isi.edu/in-notes/rfc2002.txt
\vskip1.000000\baselineskip
[RFC2003]
C. Perkins, Encapsulación IP dentro de
IP, RFC 2003, octubre de 1996.
ftp://ftp.isi.edu/in-notes/rfc2003.txt
\vskip1.000000\baselineskip
[RFC2131]
R. Droms, Protocolo de Configuración
Dinámica de Servidor, RFC 2131, marzo de 1997.
ftp://ftp.isi.edu/in-notes/rfc2131.txt
\vskip1.000000\baselineskip
[RFC3115]
G. Dommety, y K. Leung,
Extensiones de Vendedor/Organización específicas de IP Móvil, RFC
3115, abril de 2001.
ftp://ftp.isi.edu/in-notes/rfc3115.txt
\vskip1.000000\baselineskip
[MOBILEIPv6]
D. B. Johnson, C. Perkins, Soporte
de Movilidad en IPv6, Trabajo en curso (está disponible el borrador
en Internet), julio de 2000.
\vskip1.000000\baselineskip
[DHCPV6]
J. Bound, M. Carney, C.
Perkins, R. Droms, Protocolo de Configuración Dinámica
de Servidor para IPv6 (DHCPv6), Trabajo en curso (está disponible
el borrador en Internet), junio de 2001.
\vskip1.000000\baselineskip
Estándares IPSec:
[RFC2401]
S. Kent, y R. Atkinson,
Arquitectura de Seguridad para el Protocolo de Internet, RFC 2401,
noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2401.txt
\newpage
\global\parskip0.970000\baselineskip
[RFC2402]
S. Kent, y R. Atkinson, Cabecera
de Autenticación IP, RFC 2402, noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2402.txt
\vskip1.000000\baselineskip
[RFC2403]
C. Madson, R. Glenn, El Uso de
HMAC-MD5-96 dentro de ESP y AH, RFC
2403, noviembre de 1998.
\vskip1.000000\baselineskip
[RFC2404]
C. Madson, R. Glenn, El Uso de
HMAC-SHA-1-96 dentro
de ESP y AH, RFC 2404, noviembre de 1998.
\vskip1.000000\baselineskip
[RFC2405]
C. Madson, N. Doraswamy, El
Algoritmo de Cifrado ESP DES-CBC Con IV Explícita,
RFC 2405, noviembre de 1998.
\vskip1.000000\baselineskip
[RFC2406]
S. Kent, y R. Atkinson,
Encapsulación IP de la Carga Útil de Seguridad (ESP), RFC 2406,
noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2406.txt
\vskip1.000000\baselineskip
[RFC2407]
D. Piper, El Dominio de Seguridad IP en
Internet de Interpretación para ISAKMP, RFC 2407, noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2407.txt
\vskip1.000000\baselineskip
[RFC2408]
D. Maughan, M. Schneider, M.
Schertler, y J. Turner, Asociación de Seguridad en
Internet y Protocolo de Gestión de Claves (ISAKMP), RFC 2408,
noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2408.txt
\vskip1.000000\baselineskip
[RFC2409]
D. Harkins, y D. Carrel, El
Intercambio de Claves en Internet (IKE), RFC 2409, noviembre de
1998.
ftp://ftp.isi.
edu/in-notes/rfc2409.txt
edu/in-notes/rfc2409.txt
\vskip1.000000\baselineskip
[RFC2410]
R. Glenn, S. Kent, El Algoritmo de
Cifrado NULL y su Uso Con IPSec, RFC 2410, noviembre de 1998.
\vskip1.000000\baselineskip
[RFC2411]
R. Thayer, N. Doraswamy, R.
Glenn, Hoja de Ruta del Documento de Seguridad IP, RFC 2411,
noviembre de 1998.
\vskip1.000000\baselineskip
[RFC2412]
H. Orman, El Protocolo de Determinación
de Claves OAKLEY, RFC 2412, noviembre de 1998.
\vskip1.000000\baselineskip
NAT:
[RFC2694]
P. Srisuresh, G. Tsirtsis, P.
Akkiraju, y A. Heffern-an, Extensiones
de DNS a Traductores de Direcciones de Red (DNS_ALG), RFC 2694,
septiembre de 1999.
\global\parskip1.000000\baselineskip
[RFC3022]
P. Shisuresh, K. Egevang,
Traductor de Direcciones de Red IP Tradicional (NAT Tradicional),
RFC 3022, enero de 2001.
ftp://ftp.isi.edu/in-notes/rfc3022.txt
\vskip1.000000\baselineskip
El objeto de la invención es asegurar el envío
seguro de mensajes desde y hacia terminales móviles evitando los
problemas de la técnica previa.
Un objetivo de la presente invención es
proporcionar un método para asegurar el envío seguro de mensajes en
una red de telecomunicación y una red de telecomunicación para
superar los problemas mencionados arriba. Los objetivos de la
invención se logran por un método y una red de telecomunicación que
se caracterizan por lo que se fija en las reivindicaciones
independientes 1 y 6. Las realizaciones preferentes de la invención
se exponen en las reivindicaciones dependientes.
En la invención, el primer terminal es movible
de una red a otra. Tal terminal puede ser físicamente un terminal
móvil o un terminal fijo.
La conexión segura es una conexión IPSec
establecida formando una o más Asociaciones de Seguridad (SAs) que
usan los protocolos IPSec. La petición y/o el mensaje de respuesta
se puede proteger por ejemplo por medio de autenticación y/o
cifrado IPSec, posiblemente usando la misma SA IPSec que se usa para
los propósitos de protección del tráfico.
En general, la petición de registro y la
respuesta de registro son términos IP Móvil mientras que la
invención no está vinculada a IP Móvil. En la invención, los
términos petición y respuesta se usan en el sentido genérico, y
pueden ser o pueden no ser relativos a IP Móvil.
El método de la invención se puede usar en
diferentes tipos de redes. Si el primer terminal y el otro terminal
forman una conexión extremo a extremo, la conexión segura puede ser
una conexión en modo túnel IPSec o en modo transporte.
Adicionalmente, uno o ambos del primer terminal y el otro terminal
pueden ser una pasarela de seguridad que protege uno o más
ordenadores, por lo cual el modo túnel IPSec, o el modo transporte
IPSec junto con un protocolo de tunelización (tal como el Protocolo
de Tunelización de Capa 2, L2TP), se usa para la conexión segura
entre el primer terminal y el otro terminal.
Si ambos terminales son móviles, se requiere una
solución especial para la situación en que ambos terminales se
mueven simultáneamente en caso de una situación denominada "salto
doble". Esta solución se puede implementar por ejemplo usando un
registro centralizado de ubicaciones actuales de los ordenadores
principales, aunque existen otras soluciones para el problema. No
obstante, las SAs en modo transporte o túnel IPSec "cambiables"
de la invención se podrían usar en este caso, también.
El solicitante ha resuelto los problemas de
arriba de la técnica previa definiendo un mecanismo de señalización
que permite una asociación de seguridad IPSec existente, es decir,
los algoritmos de cifrado simétrico y de autenticación usados para
el procesamiento del paquete, junto con sus claves y otros
parámetros, sea movida de una red a otra. Para ser más preciso, un
punto final de túnel IPSec existente se puede mover en la invención
de un punto de colocación a otro. Por ejemplo, un túnel IPSec
establecido entre las direcciones de túnel A y X se puede cambiar
usando la señalización definida para estar entre las direcciones B y
X, usando solamente una única ida y vuelta para señalización (2
mensajes), o la mitad de una ida y vuelta (1 mensaje, si no se usa
un mensaje de respuesta) para señalización. La solución requiere
sobredimensionamiento mínimo de cálculo comparado con
Diffie-Hellman o los notables cálculos de
autenticación.
El mecanismo de señalización es preferentemente
similar al de IP Móvil, es decir una petición de registro (RREQ) se
envía al otro extremo de la SA seguido por una respuesta de registro
(RREP) de vuelta al remitente del mensaje RREQ, ambos de los cuales
son extensibles para características futuras y atributos opcionales.
El par de mensajes RREQ/RREP se envían desde la nueva red, y una
vez autenticados adecuadamente, se actualiza el punto final del
túnel IPSec remitente a partir de la vieja red a la nueva red.
En el caso de que la asociación de seguridad
usada para la protección del tráfico de usuario se use también para
propósitos de señalización, la recepción del mensaje RREQ por el
otro extremo de la SA requiere un cambio en una implementación
IPSec normal para aceptar un paquete que aparece para pertenecer a
un cierto túnel IPSec, pero llega desde una dirección equivocada
(es decir el túnel está actualmente entre A y X, y la RREQ viene de
la dirección B). Esto solamente es necesario para el mensaje RREQ.
Tal implementación se proporciona por la invención; es necesario
modificar IPSec si IPSec se usa para la señalización RREQ/RREP. En
ese caso, se requiere específicamente procesamiento de los mensajes
de RREQ y RREP, si el mensaje de respuesta va a ser usado.
El mensaje de petición puede actualizar un
conjunto de asociaciones de seguridad, por ejemplo, una asociación
de seguridad única, un manojo de asociaciones de seguridad, una
conexión IPSec, un grupo de conexiones IPSec, o cualesquiera
combinaciones de éstas. En la práctica, es útil actualizar o bien
una conexión IPSec única o bien un grupo de conexiones IPSec. La
última puede ser importante si se usan conexiones IPSec separadas
para diferentes tipos de tráfico. Un mensaje de petición único
entonces puede actualizar todas (o un cierto conjunto) de tales
conexiones a una nueva dirección, en lugar de requerir peticiones
separadas para cada conexión IPSec. A continuación, se trata el
caso de actualizar una conexión IPSec única, sin limitar la
invención a este comportamiento.
Otro método de realizar la señalización es usar
un protocolo separado. El protocolo debería preferentemente
proporcionar cifrado y/o autenticación de los mensajes de
señalización. El protocolo IKE ya tiene mensajes definidos para por
ejemplo eliminar las SAs IPSec. Un método para proporcionar la
señalización necesaria sería añadir un nuevo tipo de mensaje de
notificación IKE que requiere un cambio en una SA IPSec existente.
Tal mensaje debería proporcionar su propio cifrado y/o
autenticación para evitar requerir un establecimiento de la
conexión IKE desde la nueva dirección, lo cual requeriría mensajería
adicional.
IP versión 4 (IPv4) es la versión del Protocolo
de Internet desplegada extensamente en la actualidad. Su mayor
desventaja es el pequeño número de direcciones IP públicas, únicas.
IP versión 6 (IPv6) tiene un espacio de direcciones mucho mayor, lo
que soluciona el problema de IPv4 más importante conocido hoy. IPv6
también cambia algunas otras cosas en el Protocolo de Internet, por
ejemplo cómo se hace la fragmentación de paquetes, pero estos
cambios son bastante pequeños. La mayoría de los protocolos tienen
definiciones separadas sobre cómo se usan dentro del contexto de
IPv4 y el de IPv6. Por ejemplo, hay versiones separadas de IPSec e
IP Móvil para usar con IPv4 e IPv6. No obstante, tales
modificaciones a los protocolos son bastante pequeñas, y no cambian
normalmente de manera significativa lo esencial de los protocolos.
La invención se puede aplicar tanto a IPv4 como a IPv6.
A continuación, la invención se describe además
por medio de figuras y algunos ejemplos. La intención no es
restringir la invención a los detalles de la descripción siguiente o
a los detalles de los protocolos tales como los protocolos IPSec e
IKE que se pueden cambiar en el futuro.
La figura 1 ilustra un ejemplo de una red de
telecomunicación para ser usada en la invención.
La figura 2 ilustra un segundo ejemplo de una
red de telecomunicación para ser usada en la invención.
La figura 3 ilustra un tercer ejemplo de una red
de telecomunicación para ser usada en la invención.
La figura 4 describe la solución de la técnica
previa para permitir movilidad para conexiones IPSec.
La figura 5 describe el método de la invención
para permitir movilidad para conexiones IPSec.
La figura 1 ilustra un ejemplo de una red de
telecomunicación para ser usada en la invención. De esta manera, en
la figura 1, el ordenador 1 puede ser un ordenador cliente y el
ordenador 2 un ordenador destino, al que son enviados los mensajes
de seguridad en la invención por medio de un túnel IPSec establecido
entre el ordenador 1 y el ordenador 2. El ordenador 2 puede ser una
pasarela de seguridad para un tercer ordenador 3. Entonces, los
mensajes enviados desde el ordenador 2 al ordenador 3 se envían en
texto común. La pasarela de seguridad puede ser una pasarela de
seguridad común para por ejemplo una LAN de empresa, por lo cual hay
varios ordenadores en la LAN protegidos por el ordenador 2. Los
otros ordenadores protegidos no se muestran en la figura 1, pero
naturalmente, la invención cubre también tales redes.
La red de la figura 2 por lo demás corresponde a
aquélla de la figura 1, pero en la figura 2 también el ordenador 1
es una pasarela de seguridad, por ejemplo para el ordenador 4.
También aquí, la pasarela de seguridad 1 puede ser una pasarela de
seguridad común para por ejemplo una LAN de empresa, por lo cual hay
varios ordenadores en la LAN protegidos por el ordenador 1. Los
otros ordenadores protegidos no se muestran en la figura 2. Pero
naturalmente, la invención cubre también tales redes. Los mensajes
entre la pasarela de seguridad 1 y los ordenadores que protege se
envían en texto común ya que el túnel IPSec solamente existe entre
los ordenadores 1 y 2.
La red de la figura 3 es una red, en donde los
mensajes IPSec se envían entre una conexión extremo a extremo entre
dos ordenadores 1, 2 solamente por lo cual el modo transporte IPSec
se puede usar en lugar del modo túnel.
La figura 4 describe la solución de la técnica
previa para permitir movilidad para conexiones IPSec. Como
diagrama, éste es el procedimiento IPSec estándar cuando se
establece un túnel entre las direcciones A y X, y luego B y X.
El protocolo comienza con el modo principal IKE
que requiere 6 mensajes en total, ver los pasos 1a - 6a en la
figura 4. El protocolo implica autenticación de usuario notable,
negociación de políticas, y el uso del algoritmo
Diffie-Hellman. Cualquier otro modo de fase 1 IKE
puede ser usado por supuesto como alternativa. Otro planteamiento
para minimizar el número de intercambios de mensajes sería evitar la
fase 1 IKE y realizar solamente el modo rápido IKE (3 mensajes). No
obstante, la fase 1 IKE se asocia con las direcciones IP (junto con
otra información de identificación). Una implementación modificada
puede ignorar las direcciones IP cuando se procesan los mensajes
IKE, y de esta manera ser capaz de mantener el estado de la fase 1
IKE entre los puntos de conexión.
El protocolo entonces continúa con el modo
rápido IKE que requiere 3 mensajes en total (pasos 7a - 9a en la
figura 4). El modo rápido incluye negociación de políticas IPSec y
opcionalmente el uso del algoritmo Diffie-Hellman.
Un intercambio de la fase 2 IKE alternativo podría ser usado por
supuesto en lugar del modo rápido.
En este punto el túnel se ha establecido entre
las direcciones A y X. Se han usado 9 mensajes junto con el gasto
de cálculo (cada cálculo Diffie-Hellman puede llevar
cientos de milisegundos, por ejemplo, dependiendo del ordenador
principal), también los tiempos de ida y vuelta que son
considerables (9/2=4,5 idas y vueltas, con un tiempo de ida y
vuelta de 500 ms esto es 2,25 segundos para solo la latencia).
El movimiento del terminal móvil para abordar B
causa renegociación completa y de nuevo el modo principal IKE
requiere 6 mensajes en total (pasos 1b - 6b en la figura 4),
autenticación de usuario notable, negociación de políticas, y
opcionalmente el uso del algoritmo
Diffie-Hellman.
El uso del protocolo continúa con el modo rápido
IKE que requiere el total de 3 mensajes (pasos 7b - 9b). El túnel
entre las direcciones B y X se completa ahora.
La figura 5 describe el método de la invención.
Para establecer el túnel entre la dirección A y el ordenador
principal X, el modo principal IKE se usa de nuevo requiriendo 6
mensajes en total (pasos 1a - 6a en la figura 5) como en la figura
4 incluyendo autenticación de usuario notable, negociación de
políticas y el uso del algoritmo
Diffie-Hellman.
Entonces se usa de nuevo el modo rápido IKE
requiriendo 3 mensajes en total (pasos 7a - 9a en la figura 5). El
modo rápido incluye negociación de políticas IPSec, y opcionalmente
el uso del algoritmo Diffie-Hellman.
De nuevo, el modo principal IKE se puede
sustituir por cualquier otro modo de fase 1 IKE, y el modo rápido
IKE por cualquier otro modo de fase 2 IKE.
En este punto el túnel se ha establecido entre
las direcciones A y X. Se han usado 9 mensajes junto con el gasto
de cálculo.
En la invención, el movimiento para abordar B
requiere solamente una ida y vuelta única, cuando se usan mensajes
de petición de registro para ser enviados desde el terminal móvil,
cuando se mueve de la dirección A a la dirección B. En la señal 10a
de la figura 5, que se envía del terminal móvil al otro extremo del
túnel IPSec establecido cuando se ha movido para abordar B, se
envía una petición de registro (RREQ) de la nueva dirección.
Preferentemente, se envía (paso 11a) un mensaje de respuesta (RREP)
desde el ordenador principal para confirmar el cambio de dirección.
Ambas señales 10a y 11a se pueden cifrar y/o autenticar. El cifrado
y/o autenticación se realiza preferentemente usando IPSec, el cuyo
caso es preferible usar la misma SA IPSec para proteger tanto los
datos como el tráfico de registro.
11a es opcional en la invención. El método de
cifrado preferible es IPSec, preferentemente con el procesamiento
de recepción modificado descrito previamente. No obstante, el método
exacto de señalización no es importante, lo esencial es conservar
la SA IPSec al nuevo punto de conexión.
La SA que existía entre las direcciones A y X se
ha cambiado ahora para estar entre las direcciones B y X y ahora
está completa. La próxima vez que el terminal móvil envía un
mensaje, el ordenador principal 2 en la figura 1 - 3 es capaz de
manejar adecuadamente los paquetes IPSec que vienen de la dirección
B y viceversa. El tráfico puede fluir ahora dentro del túnel como
normal con IPSec.
Cualquier otro movimiento desde la red a otra se
puede consumar con un intercambio similar de mensaje(s) de
señalización. La SA IPSec no necesita ser
re-establecida hasta que el tiempo de vida de la SA
se ha agotado.
La invención requiere la mitad de una ida y
vuelta si solamente se usa un mensaje de petición sin una respuesta,
y se usa una ida y vuelta del mensaje de respuesta.
El ejemplo describe el modo túnel de IPSec, pero
también se puede usar el modo transporte. Las conexiones del modo
transporte IPSec en los ejemplos se pueden sustituir con conexiones
modo túnel IPSec y viceversa. El modo transporte IPSec combinado
con un protocolo de tunelización externo, tal como el Protocolo de
Tunelización de Capa 2 (L2TP), es un sustituto para el modo túnel
IPSec con respecto a la funcionalidad.
La implementación puede optimizar el comienzo de
los flujos de tráfico con respecto al mensaje 10a (y opcionalmente
11a); por ejemplo después de enviar 10a, el cliente puede enviar
directamente tráfico protegido IPSec. Esto esencialmente hace la
latencia de traspaso cero, aunque requiere procesamiento más
complicado si el mensaje 10a se pierde mientras que se entrega. No
obstante, la parte esencial de la invención es que es posible hacer
que la invención proporcione esencialmente traspaso de latencia cero
para el tráfico cliente a servidor, y la mitad de una latencia de
ida y vuelta para el tráfico servidor a cliente.
Se pueden usar, por supuesto, distintas
topologías de red en la invención. Por ejemplo en la figura 1, la
conexión entre los ordenadores principales 2 y 3 pueden usar modo
túnel o modo transporte IPSec, en lugar de ser texto común,
etc.
Claims (10)
1. El método para asegurar el envío seguro de
mensajes en una red de telecomunicación, que comprende al menos un
terminal móvil (1) y otro terminal (2), el método que comprende:
- a)
- establecer una conexión segura entre la dirección del terminal móvil (1) y el otro terminal (2), la conexión segura que se define por al menos las direcciones de los dos terminales (1, 2),
- b)
- el terminal móvil (1) moviéndose a una nueva dirección, caracterizado por
- c)
- enviar un mensaje desde el terminal móvil (1) al otro terminal móvil (2) para el registro de la nueva dirección del terminal móvil (1), como un resultado de cuyo mensaje se actualiza la conexión segura entre el terminal móvil (1) y dicho otro terminal (2) cambiando la dirección del terminal móvil (1) en la definición de dicha conexión segura establecida entre los dos terminales (1, 2).
\vskip1.000000\baselineskip
2. El método de la reivindicación 1,
caracterizado porque, la conexión segura se establece en el
paso a) formando una Asociación Segura, SA, usando el protocolo de
seguridad IP, los protocolos IPSec.
3. El método de la reivindicación 1 o 2,
caracterizado porque en el paso c) se envía de vuelta una
respuesta al terminal móvil (1) desde el otro terminal (2) después
del mensaje del terminal móvil (1) para registrar la segunda
dirección, por lo cual el método requiere una ida y vuelta de
mensajes para cambiar la conexión de seguridad existente.
4. El método de cualquiera de las
reivindicaciones 1 - 3, caracterizado porque el mensaje de
registro y/o el mensaje de respuesta se cifra y/o autentica usando
la misma SA ya establecida.
5. El método de cualquiera de las
reivindicaciones 1 - 4, caracterizado porque el cambio de
direcciones en la conexión segura como resultado del mensaje para
registrar la segunda dirección se realiza por medio de un registro
central de direcciones actuales de los terminales que pertenecen a
la red.
6. La red de telecomunicación, que comprende al
menos un terminal móvil (1) y otro terminal (2), por la cual hay
una conexión segura establecida entre la dirección del terminal
móvil (1) y el otro terminal (2), la conexión segura que se define
por al menos las direcciones de los dos terminales (1, 2),
caracterizada por
los medios para enviar un mensaje desde el
terminal móvil (1) al otro terminal (2) para el registro de una
nueva dirección del terminal móvil (1) cuando el terminal móvil (1)
se mueve, y
los medios para actualizar la conexión segura
entre el terminal móvil (1) y dicho otro terminal (2) cambiando la
dirección del terminal móvil (1) en la definición de dicha conexión
segura establecida entre los dos terminales como resultado del
mensaje para el registro del cambio de dirección.
7. La red de la reivindicación 6,
caracterizada porque el terminal móvil (1) y el otro terminal
(2) forman una conexión extremo a extremo, por la cual la conexión
segura es una conexión de transporte del protocolo de seguridad IP,
IPSec, o una conexión de túnel del protocolo de seguridad IP,
IPSec.
8. La red de la reivindicación 6,
caracterizada porque uno o ambos del terminal móvil (1) y el
otro terminal (2) es una pasarela de seguridad que protege a uno o
más ordenadores, por lo cual se usa el modo túnel del protocolo de
seguridad IP, IPSec, o el modo transporte del protocolo de
seguridad, IPSec, junto con un protocolo de tunelización para la
conexión segura entre el terminal móvil (1) y el otro terminal
(2).
9. La red de la reivindicación 6,
caracterizada porque ambos terminales son terminales móviles
(1, 2).
10. La red de la reivindicación 9,
caracterizada porque además contiene un registro central de
las ubicaciones actuales de los terminales que pertenecen a la
red.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20011910 | 2001-09-28 | ||
| FI20011910A FI116025B (fi) | 2001-09-28 | 2001-09-28 | Menetelmä ja verkko viestien turvallisen lähettämisen varmistamiseksi |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2336898T3 true ES2336898T3 (es) | 2010-04-19 |
Family
ID=8561974
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02762486T Expired - Lifetime ES2336898T3 (es) | 2001-09-28 | 2002-09-27 | Metodo y red para asegurar el envio seguro de mensajes. |
Country Status (8)
| Country | Link |
|---|---|
| US (2) | US7620810B2 (es) |
| EP (1) | EP1461925B1 (es) |
| AT (1) | ATE449490T1 (es) |
| DE (1) | DE60234470D1 (es) |
| DK (1) | DK1461925T3 (es) |
| ES (1) | ES2336898T3 (es) |
| FI (1) | FI116025B (es) |
| WO (1) | WO2003030487A1 (es) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI118170B (fi) * | 2002-01-22 | 2007-07-31 | Netseal Mobility Technologies | Menetelmä ja järjestelmä viestin lähettämiseksi turvallisen yhteyden läpi |
| US20030204741A1 (en) * | 2002-04-26 | 2003-10-30 | Isadore Schoen | Secure PKI proxy and method for instant messaging clients |
| US7392382B1 (en) * | 2003-04-21 | 2008-06-24 | Cisco Technology, Inc. | Method and apparatus for verifying data timeliness with time-based derived cryptographic keys |
| EP1665855B1 (en) * | 2003-09-12 | 2007-11-07 | NTT DoCoMo INC. | Seamless handover in heterogeneous network |
| US7895648B1 (en) * | 2004-03-01 | 2011-02-22 | Cisco Technology, Inc. | Reliably continuing a secure connection when the address of a machine at one end of the connection changes |
| US7676679B2 (en) * | 2005-02-15 | 2010-03-09 | Cisco Technology, Inc. | Method for self-synchronizing time between communicating networked systems using timestamps |
| US7468981B2 (en) | 2005-02-15 | 2008-12-23 | Cisco Technology, Inc. | Clock-based replay protection |
| CN101142784B (zh) * | 2005-03-17 | 2012-12-19 | 韩国电子通信研究院 | 无线便携式因特网系统中用户站安全相关功能的协商方法 |
| CN1838590B (zh) * | 2005-03-21 | 2011-01-19 | 松下电器产业株式会社 | 在会话起始协议信号过程提供因特网密钥交换的方法及系统 |
| US20070186281A1 (en) * | 2006-01-06 | 2007-08-09 | Mcalister Donald K | Securing network traffic using distributed key generation and dissemination over secure tunnels |
| US8082574B2 (en) * | 2006-08-11 | 2011-12-20 | Certes Networks, Inc. | Enforcing security groups in network of data processors |
| US20080072281A1 (en) * | 2006-09-14 | 2008-03-20 | Willis Ronald B | Enterprise data protection management for providing secure communication in a network |
| US8284943B2 (en) * | 2006-09-27 | 2012-10-09 | Certes Networks, Inc. | IP encryption over resilient BGP/MPLS IP VPN |
| US20080083011A1 (en) * | 2006-09-29 | 2008-04-03 | Mcalister Donald | Protocol/API between a key server (KAP) and an enforcement point (PEP) |
| US7864762B2 (en) * | 2007-02-14 | 2011-01-04 | Cipheroptics, Inc. | Ethernet encryption over resilient virtual private LAN services |
| US8908700B2 (en) | 2007-09-07 | 2014-12-09 | Citrix Systems, Inc. | Systems and methods for bridging a WAN accelerator with a security gateway |
| KR20090096121A (ko) * | 2008-03-07 | 2009-09-10 | 삼성전자주식회사 | ＩＰｖ６ 네트워크의 상태 보존형 주소 설정 프로토콜 처리방법 및 그 장치 |
| JP2011077931A (ja) * | 2009-09-30 | 2011-04-14 | Canon Inc | ＩＰｓｅｃ通信方法および装置 |
| CN102223353A (zh) * | 2010-04-14 | 2011-10-19 | 华为技术有限公司 | 主机标识协议安全通道复用方法及装置 |
| US8762706B2 (en) | 2011-04-11 | 2014-06-24 | International Business Machines Corporation | Computer systems, methods and program product for multi-level communications |
| US8898769B2 (en) | 2012-11-16 | 2014-11-25 | At&T Intellectual Property I, Lp | Methods for provisioning universal integrated circuit cards |
| US9124564B2 (en) * | 2013-08-22 | 2015-09-01 | Cisco Technology, Inc. | Context awareness during first negotiation of secure key exchange |
| US9036820B2 (en) | 2013-09-11 | 2015-05-19 | At&T Intellectual Property I, Lp | System and methods for UICC-based secure communication |
| US9208300B2 (en) | 2013-10-23 | 2015-12-08 | At&T Intellectual Property I, Lp | Apparatus and method for secure authentication of a communication device |
| US9240994B2 (en) | 2013-10-28 | 2016-01-19 | At&T Intellectual Property I, Lp | Apparatus and method for securely managing the accessibility to content and applications |
| US9240989B2 (en) * | 2013-11-01 | 2016-01-19 | At&T Intellectual Property I, Lp | Apparatus and method for secure over the air programming of a communication device |
| US9313660B2 (en) | 2013-11-01 | 2016-04-12 | At&T Intellectual Property I, Lp | Apparatus and method for secure provisioning of a communication device |
| US9713006B2 (en) | 2014-05-01 | 2017-07-18 | At&T Intellectual Property I, Lp | Apparatus and method for managing security domains for a universal integrated circuit card |
| US20190097968A1 (en) * | 2017-09-28 | 2019-03-28 | Unisys Corporation | Scip and ipsec over nat/pat routers |
| TWI713793B (zh) * | 2017-10-19 | 2020-12-21 | 中華電信股份有限公司 | 使用ＩＰｖ６的物聯網系統及其操作方法 |
| US11064208B2 (en) | 2018-02-20 | 2021-07-13 | Arlo Technologies, Inc. | Transcoding in security camera applications |
| US11558626B2 (en) * | 2018-02-20 | 2023-01-17 | Netgear, Inc. | Battery efficient wireless network connection and registration for a low-power device |
| US11272189B2 (en) | 2018-02-20 | 2022-03-08 | Netgear, Inc. | Adaptive encoding in security camera applications |
| US11756390B2 (en) | 2018-02-20 | 2023-09-12 | Arlo Technologies, Inc. | Notification priority sequencing for video security |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| AU706160B2 (en) | 1994-06-08 | 1999-06-10 | Hughes Electronics Corporation | Apparatus and method for hybrid network access |
| US6701370B1 (en) | 1994-06-08 | 2004-03-02 | Hughes Electronics Corporation | Network system with TCP/IP protocol spoofing |
| JP3492865B2 (ja) * | 1996-10-16 | 2004-02-03 | 株式会社東芝 | 移動計算機装置及びパケット暗号化認証方法 |
| US6418130B1 (en) * | 1999-01-08 | 2002-07-09 | Telefonaktiebolaget L M Ericsson (Publ) | Reuse of security associations for improving hand-over performance |
| JP3668047B2 (ja) * | 1999-05-20 | 2005-07-06 | 株式会社東芝 | 移動通信方法、移動計算機装置及び暗号化通信装置 |
| US7174018B1 (en) * | 1999-06-24 | 2007-02-06 | Nortel Networks Limited | Security framework for an IP mobility system using variable-based security associations and broker redirection |
| GB9922847D0 (en) * | 1999-09-27 | 1999-11-24 | Simoco Int Ltd | Radio communications |
| US6587680B1 (en) * | 1999-11-23 | 2003-07-01 | Nokia Corporation | Transfer of security association during a mobile terminal handover |
| GB2364477B (en) * | 2000-01-18 | 2003-11-05 | Ericsson Telefon Ab L M | Virtual private networks |
| US7486952B1 (en) * | 2000-02-09 | 2009-02-03 | Alcatel-Lucent Usa Inc. | Facilitated security for handoff in wireless communications |
| AU2002239249A1 (en) * | 2000-11-13 | 2002-06-03 | Ecutel, Inc | System and method for secure network mobility |
| US7245405B2 (en) | 2001-04-11 | 2007-07-17 | Hughes Network Systems, Llc | Method and system for performing stateless compression of messages |
| US7146428B2 (en) * | 2001-12-12 | 2006-12-05 | At&T Corp. | Secure in-band signaling method for mobility management crossing firewalls |
| US6947725B2 (en) * | 2002-03-04 | 2005-09-20 | Microsoft Corporation | Mobile authentication system with reduced authentication delay |
| US6839338B1 (en) * | 2002-03-20 | 2005-01-04 | Utstarcom Incorporated | Method to provide dynamic internet protocol security policy service |
-
2001
- 2001-09-28 FI FI20011910A patent/FI116025B/fi not_active IP Right Cessation
-
2002
- 2002-09-27 ES ES02762486T patent/ES2336898T3/es not_active Expired - Lifetime
- 2002-09-27 DE DE60234470T patent/DE60234470D1/de not_active Expired - Lifetime
- 2002-09-27 US US10/490,932 patent/US7620810B2/en not_active Expired - Lifetime
- 2002-09-27 WO PCT/FI2002/000770 patent/WO2003030487A1/en not_active Application Discontinuation
- 2002-09-27 AT AT02762486T patent/ATE449490T1/de active
- 2002-09-27 EP EP02762486A patent/EP1461925B1/en not_active Expired - Lifetime
- 2002-09-27 DK DK02762486.5T patent/DK1461925T3/da active
-
2009
- 2009-09-16 US US12/560,481 patent/US7937581B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| EP1461925A1 (en) | 2004-09-29 |
| DE60234470D1 (de) | 2009-12-31 |
| ATE449490T1 (de) | 2009-12-15 |
| US7937581B2 (en) | 2011-05-03 |
| FI20011910A0 (fi) | 2001-09-28 |
| DK1461925T3 (da) | 2010-04-06 |
| US20100049967A1 (en) | 2010-02-25 |
| WO2003030487A1 (en) | 2003-04-10 |
| US20050083947A1 (en) | 2005-04-21 |
| FI116025B (fi) | 2005-08-31 |
| US7620810B2 (en) | 2009-11-17 |
| EP1461925B1 (en) | 2009-11-18 |
| FI20011910A (fi) | 2003-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2336898T3 (es) | Metodo y red para asegurar el envio seguro de mensajes. | |
| US11283772B2 (en) | Method and system for sending a message through a secure connection | |
| KR100679882B1 (ko) | 사설 네트워크와 로밍 모바일 단말 사이의 통신 | |
| US8179890B2 (en) | Mobile IP over VPN communication protocol | |
| US8037302B2 (en) | Method and system for ensuring secure forwarding of messages | |
| JP5087012B2 (ja) | ロケーションプライバシをサポートする経路最適化 | |
| KR100799575B1 (ko) | ＩＰｖ６ 네트워크에서 이동노드에게 ＶＰＮ 서비스를제공하는 방법 및 이를 위한 게이트웨이 | |
| JP6075871B2 (ja) | ネットワークシステム、通信制御方法、通信制御装置及び通信制御プログラム | |
| FI113597B (fi) | Menetelmä viestien lähettämiseksi usean yhteyden läpi | |
| Cabellos-Aparicio et al. | Mobility Agents: Avoiding the Signaling of Route Optimization on Large Servers | |
| Wang et al. | IPSec-based key management in mobile IP networks | |
| Liu et al. | A secure mobile-IPv6 network model | |
| Oschwald et al. | Mobile IP |