ES2319171T3 - Metodo y sistema para garantizar el reenvio seguro de mensajes. - Google Patents
Metodo y sistema para garantizar el reenvio seguro de mensajes. Download PDFInfo
- Publication number
- ES2319171T3 ES2319171T3 ES02764898T ES02764898T ES2319171T3 ES 2319171 T3 ES2319171 T3 ES 2319171T3 ES 02764898 T ES02764898 T ES 02764898T ES 02764898 T ES02764898 T ES 02764898T ES 2319171 T3 ES2319171 T3 ES 2319171T3
- Authority
- ES
- Spain
- Prior art keywords
- terminal
- address
- ipsec
- message
- secure connection
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
- H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
-
- 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/04—Key management, e.g. using generic bootstrapping architecture [GBA]
- H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
- H04W12/0431—Key distribution or pre-distribution; Key agreement
-
- 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0272—Virtual private networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- 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]
Abstract
Método para garantizar el reenvío seguro de un mensaje en una red de telecomunicaciones, que comprende por lo menos un primer terminal desde el que se envía el mensaje y por lo menos otro terminal hacia el que se envía el mensaje, caracterizado porque a) se establecen una o más conexiones seguras entre direcciones diferentes del primer terminal y una dirección del otro terminal, definiendo estas conexiones por lo menos dichas direcciones de los dos terminales, b) el primer terminal se mueve de una dirección a otra dirección, c) se registra una conexión segura entre dicha otra dirección y la dirección del otro terminal de manera que sea por lo menos una de las conexiones activas a usar.
Description
Método y sistema para garantizar el reenvío
seguro de mensajes.
El método y el sistema de la invención están
destinados a proteger conexiones en redes de telecomunicaciones. En
particular, la invención está destinada a ser usada en redes
inalámbricas como parte de una solución IP móvil o una solución
IPSec.
Una inter-red es un conjunto de
redes individuales conectadas con dispositivos intermedios de
conexión de redes que funcionan como una única red de grandes
dimensiones. Se pueden interconectar redes diferentes mediante
encaminadores y otros dispositivos de conexión de redes para crear
una inter-red.
Una red de área local (LAN) es una red de datos
que comprende 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
comunicaciones de datos que comprende un área geográfica
relativamente amplia. Las redes de área extensa (WANs)
interconectan LANs a través de redes telefónicas y otros medios;
interconectando de este modo usuarios dispuestos
geográficamente.
En las redes fijas, existen soluciones para
cubrir la necesidad de proteger datos y recursos contra su
revelación, garantizar la autenticidad de datos, y proteger
sistemas contra ataques basados en redes. La IPSec es una de estas
tecnologías por medio de la cual se obtiene seguridad.
Los protocolos de seguridad IP (IPSec)
proporcionan la capacidad de proteger comunicaciones a través de una
LAN, a través de redes de área extensa (WANs) privadas y públicas y
a través de internet. La IPSec se puede usar de diferentes maneras,
tales como para construir redes privadas virtuales seguras, para
obtener un acceso seguro a una red empresarial (con un uso de la
IPSec de acceso remoto), o para proteger una comunicación con otras
organizaciones, garantizando la autenticación y la confidencialidad
y proporcionando un mecanismo de intercambio de claves. Incluso si
algunas aplicaciones ya disponen de protocolos de seguridad
incorporados, el uso de la IPSec potencia adicionalmente la
seguridad.
La IPSec puede cifrar y/o autenticar tráfico en
el nivel IP. Típicamente, el tráfico que va hacia una WAN se cifra
y/o autentica y el tráfico que viene de una WAN se descifra y/o
autentica. La IPSec está definida por ciertos documentos, los
cuales contienen normas para la arquitectura IPSec.
Se usan dos protocolos para proporcionar
seguridad en la capa IP, un protocolo de autenticación designado
por el encabezamiento del protocolo, Encabezamiento de Autenticación
(AH), y un protocolo combinado de cifrado/autenti-
cación designado por el formato del paquete para ese protocolo, Carga Útil de Seguridad de Encapsulado (ESP). Tanto el AH como el ESP son vehículos para el control del acceso basado en la distribución de claves criptográficas y la gestión de flujos de tráfico relacionados con estos protocolos de seguridad.
cación designado por el formato del paquete para ese protocolo, Carga Útil de Seguridad de Encapsulado (ESP). Tanto el AH como el ESP son vehículos para el control del acceso basado en la distribución de claves criptográficas y la gestión de flujos de tráfico relacionados con estos protocolos de seguridad.
La asociación de seguridad (SA) es un concepto
clave en la autenticación y los mecanismos de confidencialidad para
el IP. Una asociación de seguridad es una relación de un solo
sentido entre un emisor y un receptor que ofrece servicios de
seguridad para el tráfico transportado sobre ella. Si es necesaria
una relación segura de doble sentido, entonces se requieren dos
asociaciones de seguridad.
La expresión conexión IPSec se usa en lo
sucesivo en lugar de un agrupamiento IPSec de una o más asociaciones
de seguridad SAs, o un par de agrupamientos IPSec - un agrupamiento
para cada dirección - de una o más asociaciones de seguridad. Así,
esta expresión comprende la protección del tráfico tanto
unidireccional como bidireccional. No existe ninguna implicación de
simetría de las direcciones, es decir, los algoritmos y las
transformadas IPSec usados para cada dirección pueden ser
diferentes.
Una asociación de seguridad queda identificada
de forma exclusiva por tres parámetros. El primero, el Índice de
Parámetros de Seguridad (SPI), es una cadena de 32 bits asignada a
esta SA. El SPI se transporta en encabezamientos AH y ESP para
permitir que el sistema receptor seleccione la SA bajo la cual se
procesará un paquete recibido. La dirección de destino IP es el
segundo parámetro, siendo esta la dirección del punto extremo 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 ó ESP.
Tanto el AH como el ESP soportan dos modos
usados, el modo de transporte y de túneles.
El modo de transporte proporciona protección
principalmente para protocolos de capa superiores y se extiende a
la carga útil de un paquete IP. Típicamente, el modo de transporte
se usa para la comunicación de
extremo-a-extremo entre dos
anfitriones. El modo de transporte se puede usar conjuntamente con
un protocolo de tunelización (diferente a la tunelización
IPSec).
El modo de túneles proporciona protección para
el paquete IP completo y se usa para enviar mensajes a través de
más de dos componentes. El modo de túneles se usa frecuentemente
cuando uno o ambos extremos de una SA es una pasarela de seguridad,
tal como un cortafuegos o un encaminador que implementa la IPSec.
Con el modo de túneles, varios anfitriones en redes por detrás de
cortafuegos se pueden dedicar a comunicaciones seguras sin
implementar la IPSec. Los paquetes no protegidos generados por
dichos anfitriones se tunelizan a través de redes externas mediante
SAs en modo de túneles establecidas por el software IPSec en el
cortafuegos o el encaminador seguro en la frontera de la red
local.
Para lograr esto, después de que al paquete IP
se le añadan los campos AH ó ESP, el paquete completo más campos de
seguridad se tratan como la carga útil de un nuevo paquete IP
externo con un nuevo encabezamiento IP externo. El paquete completo
original, o interno, viaja a través de un túnel desde un punto de
una red IP a otro: ningún encaminador a lo largo del camino puede
revisar el paquete IP interno. Como el paquete original está
encapsulado, el nuevo paquete más grande puede tener direcciones de
origen y de destino totalmente diferentes, aumentando la seguridad.
En otras palabras, la primera etapa en la protección del paquete
usando el modo de túneles es añadir un encabezamiento IP nuevo al
paquete; de este modo, el paquete "IP | carga útil" se
convierte en "IP | IP | carga útil". La siguiente etapa es
proteger el paquete usando ESP y/ó AH. En el caso del ESP, el
paquete resultante es "IP | ESP | IP | carga
útil". El paquete interno completo queda cubierto por la
protección ESP y AH. El AH protege también partes del
encabezamiento externo, además del paquete interno completo.
El modo de túneles IPSec funciona, por ejemplo,
de tal manera que si un anfitrión en una red genera un paquete IP
con una dirección de destino de otro anfitrión en otra red, el
paquete se encamina desde el anfitrión de origen a una pasarela de
seguridad (SGW), un cortafuegos u otro encaminador seguro en la
frontera de la primera red. La SGW filtra todos los paquetes
salientes para determinar la necesidad del procesado IPSec. Si este
paquete del primer anfitrión a otro anfitrión requiere una IPSec, el
cortafuegos realiza un procesado IPSec que conlleva un encapsulado
del paquete en un encabezamiento IP externo. La dirección IP de
origen de este paquete IP externo es este cortafuegos y la
dirección de destino puede ser un cortafuegos que forme la frontera
con la otra red local. A continuación, este paquete se encamina
hacia el cortafuegos del otro anfitrión con encaminadores
intermedios que únicamente revisan el encabezamiento IP externo. En
el cortafuegos del otro anfitrión, se extrae el encabezamiento IP
externo y el paquete interno es entregado al otro anfitrión.
El ESP en modo de túneles cifra y opcionalmente
autentica el paquete IP interno completo, incluyendo el
encabezamiento IP interno. El AH en el modo de túneles autentica el
paquete IP interno completo y campos seleccionados del
encabezamiento IP externo.
La parte de gestión de claves de la IPSec
conlleva la determinación y distribución de claves secretas. Al
protocolo por defecto de gestión automatizada de claves para la
IPSec se le hace referencia como ISAKMP/Oakley y consta del
protocolo de determinación de claves Oakley y del Protocolo de
Gestión de Claves y de Asociación de Seguridad de Internet
(ISAKMP). El Intercambio de Claves de Internet (IKE) es un nombre
más nuevo para el ISAKMP/Oakley. El IKE se basa en el algoritmo de
intercambio de claves Diffie-Hellman, y,
entre otros modos, soporta la autenticación de firmas RSA. El IKE
es fácilmente ampliable para características futuras y específicas
de cada proveedor sin interrumpir la compatibilidad retroactiva.
El protocolo IPSec resuelve de una manera
satisfactoria los problemas conocidos de seguridad del Protocolo de
Internet (IP). No obstante, el mismo está diseñado para una Internet
estática, en la que los anfitriones que usan la IPSec son
relativamente estáticos. Por lo tanto, la IPSec no funciona bien con
dispositivos móviles.
Por ejemplo, si un terminal móvil se mueve de
una red a otra, se requiere un establecimiento de una conexión
IPSec, típicamente usando el protocolo de intercambio de claves IKE.
Un establecimiento de este tipo resulta costoso en términos de
latencia, ya que el IKE puede requerir varios segundos para su
finalización. Resulta también costoso en términos de cómputo, ya
que los cálculos Diffie-Hellman y los relacionados
con la autenticación del IKE consumen una gran cantidad de
tiempo.
Encaminamiento significa movimiento de
información a través de una inter-red de un origen a
otro. Por el camino, habitualmente se encuentra por lo menos un
nodo intermedio. El encaminamiento implica tanto la determinación
del trayecto de encaminamiento óptimo como el transporte de paquetes
de información. Para ayudar al encaminamiento de paquetes de
información, los algoritmos de encaminamiento inicializan y
mantienen tablas de encaminamiento, las cuales contienen
información de encaminamiento. Los encaminadores se comunican entre
sí y mantienen sus tablas de encaminamiento a través de la
transmisión de una variedad de mensajes. El mensaje de actualización
de encaminamiento es uno de estos mensajes que generalmente consta
de la totalidad o de parte de una tabla de
encaminamiento.
encaminamiento.
El problema fundamental con la movilidad IP es
el hecho de que el encaminamiento IP está basado en direcciones
fijas. El espacio de direcciones se ha dividido en subredes, que
residen en ubicaciones prácticamente fijas con respecto a la
topología de la red (el encaminamiento se puede cambiar, pero este
es un proceso lento, posiblemente del orden de minutos). Cuando un
anfitrión móvil se aleja de su red doméstica (en la que su dirección
IP es correcta), existe un problema con el encaminamiento de los
paquetes hacia la ubicación nueva si la red IP en cuestión no
soporta dicho movimiento.
En este texto, el término movilidad y terminal
móvil no significan solamente movilidad física, sino que el término
movilidad pretende significar en primera instancia movimiento de una
red a otra, el cual también puede ser realizado por un terminal
fijo en términos físicos.
La normativa IP Móvil para IPv4 utiliza, por
ejemplo, la tunelización IP-IP y de Encapsulado de
Encaminamiento Genérico (GRE) para superar este problema (véanse
más detalles en la figura 1 con el texto adjunto). Existen también
otros métodos de tunelización, y por lo tanto, la tunelización
IP-IP y GRE se usan únicamente como ejemplo en este
texto. El IPv4 móvil tiene dos modos de funcionamiento. En el modo
de dirección de auxilio de ubicación conjunta el terminal móvil
realiza un encapsulado y desencapsulado IP-IP. Este
modo requiere una dirección prestada - la dirección de auxilio de
ubicación conjunta - de la red visitada. El otro modo es el modo de
agente foráneo, en el que el IP-IP u otra
tunelización se realiza por parte de un anfitrión especial en la
red visitada, denominado Agente Foráneo (FA). El terminal móvil se
comunica directamente con el FA (para esta comunicación directa no
se requiere una dirección IP), y en este modo no necesita una
dirección prestada.
En la tunelización IP-IP, se
toma prestada una dirección IP (la denominada dirección de auxilio
de ubicación conjunta) de una red que está siendo visitada. Esta
dirección es topológicamente correcta, es decir, encaminable desde
otras partes de la red. Cuando un terminal móvil necesita enviar un
paquete a un ordenador objetivo determinado, en primer lugar
construye un paquete IP, cuya dirección de origen es su dirección
doméstica, es decir, la dirección que no es topológicamente
correcta en la red nueva, y cuya dirección de destino es el
ordenador objetivo.
Como este paquete puede que no sea directamente
encaminable, el mismo se encapsula en otro paquete IP (mediante el
denominado encapsulado IP-IP, o tunelización
IP-IP). La dirección de origen de este paquete IP es
la dirección de auxilio, y la dirección objetivo es el denominado
servidor doméstico del terminal móvil. Al producirse la recepción
de dicho paquete encapsulado, el servidor doméstico desenvuelve el
túnel IP-IP, y procede con el encaminamiento del
paquete, que estaba dentro del encapsulado.
Los paquetes inversos desde el ordenador
objetivo al terminal móvil se gestionan de forma similar; en primer
lugar el paquete se encamina hacia el servidor doméstico, a
continuación se encapsula en IP-IP y se entrega a
la red actual en la que se encuentra el terminal móvil. La
vinculación de movilidad actual determina qué dirección de auxilio
actual se corresponde con una dirección doméstica determinada.
(También puede haber vinculaciones denominadas simultáneas, en cuyo
caso la dirección doméstica se corresponde con un conjunto de
direcciones de auxilio; el paquete se encapsula y es enviado a cada
dirección de auxilio por separado).
Cuando el terminal móvil se mueve a una red
nueva, se realiza un intercambio de mensajes de señalización
autenticados entre el terminal móvil y el servidor doméstico. El
terminal móvil envía una Solicitud de Registro al servidor
doméstico, solicitando una actualización de la vinculación de
movilidad actual. El servidor responde usando una Respuesta de
Registro que puede o bien aceptar o bien denegar la solicitud.
Cuando se usa el modo de funcionamiento de Agente Foráneo, los
mensajes de registro pasan a través del Agente Foráneo.
La versión 4 del IP (IPv4) es la versión del
Protocolo de internet desplegada actualmente de forma generalizada.
Su principal desventaja es el pequeño número de dirección IP
públicas, exclusivas. La versión 6 del IP (IPv6) dispone de un
espacio de direcciones mucho mayor, lo cual arregla el problema más
importante del IPv4 conocido actualmente. El IPv6 también cambia
algunas otras cosas en el Protocolo de Internet, por ejemplo, la
forma en la que se realiza la fragmentación de paquetes, aunque
estos cambios son bastante pequeños. La mayoría de protocolos
tienen definiciones independientes sobre cómo se usan los mismos
dentro del contexto IPv4 e IPv6. Por ejemplo, existen versiones
independientes de la IPSec y el IP Móvil para ser usadas con el IPv4
y el IPv6. No obstante, dichas modificaciones sobre los protocolos
son bastante pequeñas, y habitualmente no cambian de forma
significativa las partes esenciales de los protocolos.
El protocolo IPSec resuelve los problemas de
seguridad conocidos del Protocolo de Internet (IP) de una manera
satisfactoria. No obstante, el mismo está diseñado para una Internet
estática, en la que los anfitriones que usan la IPSec son
relativamente estáticos. Por lo tanto, la IPSec no funciona bien con
dispositivos móviles. Por ejemplo, si un terminal móvil se mueve de
una red a otra, se requiere un establecimiento de conexión IPSec,
típicamente usando el protocolo de intercambio de claves IKE. Un
establecimiento de este tipo es costoso en términos de latencia, ya
que el IKE puede requerir varios segundos para su finalización.
También es costoso en términos de cómputo, ya que los cálculos del
Diffie-Hellman y los relacionados con la
autenticación del IKE consumen una gran cantidad de tiempo.
La descripción anterior presenta las ideas
esenciales del IP Móvil.
El planteamiento IP móvil de la técnica anterior
presenta algunos inconvenientes y problemas.
El protocolo IP Móvil normalizado proporciona a
un terminal móvil una conexión móvil, y define mecanismos para
realizar traspasos eficaces de una red a otra. No obstante, el IP
Móvil presenta varios inconvenientes. La seguridad del IP Móvil es
muy limitada. Los mensajes de señalización de movilidad están
autenticados, pero no cifrados, y el tráfico de datos de usuario
está completamente desprotegido. Además, no existe ningún mecanismo
de intercambio de claves para establecer las claves criptográficas
requeridas para autenticar la señalización de movilidad.
Típicamente es necesario distribuir dichas claves de forma manual.
En la gestión manual de claves de la técnica anterior, el mecanismo
de autenticación de señalización requiere que el anfitrión móvil y
el servidor doméstico compartan una clave de autenticación secreta
y la distribución de esa clave, que se lleva a cabo manualmente, no
es muy práctica. 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).
No obstante, dicho problema con los dispositivos
de Traducción de Direcciones de Red (NAT), incluso si los
dispositivos NAT pueden traducir direcciones de redes privadas
incluidas en mensajes en direcciones IP públicas de manera que los
mensajes se puedan enviar a través de internet, es que actualmente
no hay ninguna normativa para conseguir que el IP Móvil funcione a
través de dispositivos NAT. Los dispositivos NAT están desplegados
de forma generalizada debido a que el uso de direcciones privadas
requiere menos direcciones IP públicas de las que, de otro modo,
serían necesarias.
\vskip1.000000\baselineskip
La siguiente es una lista de referencias útiles
para entender la tecnología que subyace tras la invención.
\vskip1.000000\baselineskip
IP en general, UDP y TCP:
[RFC768]
J. Postel, User Datagram Protocol,
RFC 768, agosto de 1980. ftp://ftp.isi.
edu/in-notes/rfc768.txt
[RFC791]
J. Postel, Internet Protocol, RFC
791, septiembre de 1981.
ftp://ftp.isi.edu/in-notes/rfc791.txt
[RFC792]
J. Postel, Internet Control Message
Protocol, RFC 792, septiembre de 1981.
ftp://ftp.edu/in-notes/rfc792.txt
[RFC793]
J. Postel, Transmission Control
Protocol, RFC 793, septiembre de 1981.
ftp://ftp.isi.eduin-notes/rfc793.bct
[RFC826]
D. C. Plummer, An Ethernet Address
Resolution Protocol, RFC 826, noviembre de 1982.
ftp://ftp.isi.edu/in-notes/rfc826.txt
[RFC2460]
S. Deering, R. Hinden, Internet
Protocol, Version 6 (IPv6) Specification, RFC 2460, diciembre de
1998.
\vskip1.000000\baselineskip
IP Móvil; IP-IP; DHCP:
[RFC2002]
C. Perkins, IP Mobility Support,
RFC 2002, octubre de 1996. ftp://ftp.isi.
edu/in-notes/rfc2002.txt
[RFC2003]
C. Perkins, IP Encapsulation Within
IP, RFC 2003, octubre de 1996. ftp://ftp.isi.
edu/in-notes/rfc2003.txt
[RFC2131]
R. Droms, Dynamic Host Configuration
Protocol, RFC 2131, marzo de 1997.
ftp://ftp.isi.edu/in-notes/rfc2131.txt
[RFC3115]
G. Dommety, y K. Leung, Mobile
IP VendorlOrganization-specific Extensions, RFC
3115, abril de 2001.
ftp://ftp.isi.edu/in-notes/rfc3115.txt
ftp://ftp.isi.edu/in-notes/rfc3115.txt
\newpage
[MOBILEIPV6]
D. B. Johnson, C. Perkins,
Mobility Support in IPv6, Trabajo en curso (hay disponible un
proyecto de Internet), julio de 2000.
[DHCPV6]
J. Bound, M. Carney, C.
Perking, R. Droms, Dynamic Host Configuration
Protocol for IPv6 (DHCPv6), Trabajo en curso (hay disponible un
proyecto de Internet), junio de 2001.
\vskip1.000000\baselineskip
Normativas IPSec:
[RFC2401]
S. Kent, and R. Atkinson,
Security Architecture for the Internet Protocol, RFC 2401,
noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2401.txt
ftp://ftp.isi.edu/in-notes/rfc2401.txt
[RFC2402]
S. Kent, y R. Atkinson, IP
Authentication Header, RFC 2402, noviembre de 1998.
ftp://ftp.isi.edu/in-notes/
rfc2402.txt
[RFC2403]
C. Madson, R. Glenn, The Use of
HMAC-MD5-96 within ESP and AH,
RFC 2403, noviembre de 1998.
[RFC2404]
C. Madson, R. Glenn, The Use of
HMAC-SHA-1-96 within
ESP and AH, RFC 2404, noviembre de 1998.
[RFC2405]
C. Madson, N. Doraswamy, The
ESP DES-CBC Cipher Algorithm With Explicit IV,
RFC 2405, noviembre de 1998.
[RFC2406]
S. Kent, y R. Atkinson, IP
Encapsulating Security Payload (ESP), RFC 2406, noviembre de
1998.
ftp://ftp.isi.edu/in-notes/rfc2406.txt
ftp://ftp.isi.edu/in-notes/rfc2406.txt
[RFC2407]
D. Piper, The internet IP Security
Domain of Interpretation for ISAKMP, RFC 2407, noviembre de
1998.
ftp://ftp.isi.edu/in-notes/rfc2407.txt
ftp://ftp.isi.edu/in-notes/rfc2407.txt
[RFC2408]
D. Maughan, M. Schneider, M.
Schertier, y J. Tumer, Internet Security
Association and Key Management Protocol (ISAKMP), RFC
2408, noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2408.txt
[RFC2409]
D. Harkins, y D. Carrel, The
Internet Key Exchange (IKE), RFC 2409, noviembre de 1998.
ftp://ftp.isi.edu/in-notes/rfc2409.txt
[RFC2410]
R. Glenn, S. Kent, The NULL
Encryption Algorithm and Its Use With IPsec, RFC 2410, noviembre
de 1998.
[RFC2411]
R. Thayer, N. Doraswamy, R.
Glenn, IP Security Document Roadmap, RFC 2411,
noviembre de 1998.
[RFC2412]
H. Orman, The OAKLEY Key Determination
Protocol, RFC 2412, noviembre de 1998.
\vskip1.000000\baselineskip
NAT:
[RFC2694]
P. Srisuresh, G. Tsirtsis, P.
Akkiraju, y A. Heffernan, DNS extensions to Network
Address Translators (DNS_ALG), RFC 2694, septiembre de
1999.
[RFC3022]
P. Shisuresh, K. Egevang,
Traditional IP Network Address Translator (Traditional NAT),
RFC 3022, enero de 2001.
\vskip1.000000\baselineskip
El objetivo de la invención es garantizar el
reenvío seguro de mensajes desde y hacia terminales móviles evitando
los problemas de la técnica anterior descritos anteriormente.
El método de la invención para garantizar el
reenvío seguro de un mensaje se realiza en una red de
telecomunicaciones, que comprende por lo menos un terminal desde el
que se envía el mensaje y por lo menos otro terminal hacia el que
se envía el mensaje. En el método, se establecen una o más
conexiones seguras entre direcciones diferentes del primer terminal
y una dirección del otro terminal, definiendo las conexiones por lo
menos dichas direcciones de los dos terminales. Cuando el primer
terminal se mueve de una dirección a otra dirección, se registra una
conexión segura, cuyos puntos extremos son la dirección nueva del
primer terminal y la dirección del otro terminal, de manera que sea
por lo menos una de las conexiones activas.
Si no existe ya una conexión segura de este tipo
entre la dirección nueva y el otro terminal, se debe formar una
conexión nueva segura entre la dirección nueva y la dirección del
otro terminal.
Los terminales podrían tener varias conexiones
activas. En la invención, en una de las formas de realización el
terminal también podría tener solamente una conexión activa segura
cada vez, la cual se puede cambiar según la invención para quedar
definida de manera que se sitúe entre la dirección a la que se mueve
el terminal y la dirección del otro terminal.
En la presente invención, el primer terminal es
movible de una red a otra. Un terminal de este tipo puede ser
físicamente un terminal móvil o un terminal fijo.
Por otra parte, la invención se refiere a un
sistema, el cual puede ejecutar el método de la invención. Las
características del sistema quedan definidas por la reivindicación
principal del sistema, definiendo la reivindicación secundaria las
funciones que se pueden realizar mediante el sistema de la
invención.
Las conexiones seguras se establecen
preferentemente mediante la formación de Asociaciones de Seguridad
(SAs) que usan los protocolos IPSec y el mensaje a reenviar
consiste en paquetes IP. El intercambio de claves que es una parte
de la formación de una conexión segura se realiza de forma manual o
automáticamente con el IKE ó algún otro protocolo de intercambio
automatizado de claves.
Cuando se forma una conexión segura nueva, la
misma se registra para un uso inmediato y/o posterior. El registro
para un uso posterior se realiza usando una tabla de conexiones,
cuyo mantenimiento lo realizan ambos anfitriones que participan en
la formación de la conexión segura. La tabla de conexiones se usa
también, por ejemplo, cuando el primer terminal se mueve, y
necesita determinar si ya existe un túnel seguro para la dirección
nueva. La tabla puede ser, por ejemplo, una Base de Datos de
Asociaciones de Seguridad (SADB), la cual es el sitio nominal para
almacenar SAs IPSec en el modelo IPSec.
En la forma de realización preferida, como
conexiones seguras se usan asociaciones de seguridad IPSec. La
tabla, a través de la cual se determina la existencia de una SA
IPSec determinada (o bien en el primer terminal o bien en el otro
terminal), es entonces la Base de Datos de Asociaciones de Seguridad
(SADB) IPSec.
La(s) conexión(es) real(es)
a usar se registra por medio de un mensaje de señalización o un
intercambio de mensajes de señalización entre el primer terminal y
el otro terminal, por ejemplo, por medio de mensajes de Solicitud
de Registro y posiblemente de Respuesta de Registro.
El mensaje de solicitud puede actualizar un
conjunto de asociaciones de seguridad, por ejemplo, una única
asociación de seguridad, un agrupamiento de asociaciones de
seguridad, una conexión IPSec, un grupo de conexiones IPSec, o
cualesquiera combinaciones de las mismas. En la práctica, resulta
útil actualizar o bien una única conexión IPSec ó bien un grupo de
conexiones IPSec. Esto último puede resultar importante si se usan
conexiones IPSec independientes para tipos diferentes de tráfico. A
continuación, un único mensaje de solicitud puede actualizar la
totalidad (o un cierto conjunto) de estas conexiones a una dirección
nueva, en lugar de requerir solicitudes independientes para cada
conexión IPSec. A continuación se describe el caso de actualización
de una única conexión IPSec, sin limitar la invención a este
comportamiento.
La dirección nueva del primer terminal también
se puede actualizar automáticamente por parte del otro terminal
cuando el primer terminal envía un mensaje desde su dirección
nueva.
La SA activa es una vinculación de movilidad
almacenada que establece una correspondencia de una dirección de
terminal determinada con una o más SAs (o ninguna de estas SAs, si
el terminal en cuestión no está conectado) en modo de túneles
IPSec. Estas vinculaciones de movilidad se manipulan cuando se
procesan mensajes de Solicitud de Registro y de Respuesta de
Registro cuando se envían paquetes al primer terminal. Es posible
restringir tráfico del primer terminal a solamente las SAs IPSec
que están registradas en ese momento en la vinculación de
movilidad, aunque también es razonable permitir tráfico de todas las
SAs compartidas.
La vinculación de movilidad es necesaria ya que
cada una de las asociaciones de seguridad IPSec compartidas es
válida para proteger tráfico. Debe existir alguna manera de que el
primer terminal determine qué asociación(es) de seguridad
usar realmente cuando se procesan paquetes. En la invención, la
vinculación de movilidad sirve para este fin.
El primer terminal puede usar cualquier SA de
túnel IPSec que comparta con el otro terminal. Es posible restringir
tráfico del primer terminal a solamente las SAs IPSec que están
registradas en ese momento, aunque esto no constituye una
característica esencial. De este modo, el primer terminal puede usar
cualquier SA de túnel IPSec que comparta con el otro terminal
cuando se envíen paquetes. El otro terminal puede restringir tráfico
solamente a SAs IPSec que estén activas en ese momento en la
vinculación de movilidad, aunque también es razonable permitir
tráfico de todas las SAs compartidas.
La invención se puede usar para una comunicación
directa de extremo-a-extremo, en
cuyo caso el túnel seguro se establece entre estos ordenadores
extremos. Si se aplica a la IPSec, esta situación se podría
corresponder con una SA ó bien de modo túnel o bien de modo
transporte IPSec. El mensaje también se podría enviar en primer
lugar a un ordenador intermedio, con lo cual el ordenador intermedio
desenvuelve la dirección externa del túnel IPSec y el mensaje se
reenvía como texto sin formato al computador extremo de destino.
De este modo, en la solución de la invención, se
usa una asociación de seguridad IPSec en lugar de la tunelización
IP-IP. La invención también se puede usar para
tunelización con un modo de transporte IPSec y un mecanismo de
tunelización externo, tal como el Protocolo de Tunelización de Capa
2 (L2TP).
La invención proporciona las siguientes
ventajas.
La gestión de claves y la autenticación fuerte
IPSec se pueden aprovechar para esta aplicación que implica una
autenticación asimétrica (RSA), el uso del algoritmo de intercambio
de claves Diffie-Hellman, la posibilidad de usar
certificados, etcétera.
Los métodos simétricos de cifrado y
autenticación IPSec se pueden usar para proteger el tráfico tanto de
señalización como de datos. Esto proporciona confidencialidad e
integridad y se puede aprovechar cualquier evolución futura de la
IPSec.
El problema de atravesar NATs se puede resolver
usando cualesquiera mecanismos disponibles para atravesar NATs
correspondientes a la IPSec. Actualmente, se está normalizando uno
para la IPSec, aunque se puede usar cualquier otro mecanismo IPSec
para atravesar NATs.
La invención se puede usar en redes diferentes,
tales como IPv4 e IPv6.
A continuación, la invención se describe más
detalladamente por medio de una forma de realización ventajosa en
una red a título de ejemplo, aunque no se limita a los detalles de
esta última.
La Figura 1 describe la tunelización IP móvil de
la técnica anterior por medio de un diagrama de señalización
la Figura 2 describe el método de la invención
por medio de un diagrama de señalización.
La comunicación de datos en la figura 1 tiene
lugar desde un terminal móvil a un anfitrión objetivo X a través de
un ordenador intermedio, el cual funciona como un servidor doméstico
para el anfitrión X.
Los paquetes enviados desde la dirección
doméstica del terminal móvil se pueden encaminar directamente hacia
la dirección objetivo X por medio del ordenador intermedio, ya que
la dirección doméstica está registrada en tablas de encaminamiento
a través de lo cual tiene lugar el encaminamiento.
La figura 1 describe un método de la técnica
anterior, en el que se usa la tunelización IP-IP
para encaminar paquetes de datos cuando el anfitrión móvil se mueve
de una dirección a otra, es decir, desde la dirección doméstica a
una dirección nueva.
El IP móvil soporta también el modo de
encaminamiento denominado triangular, en el que los paquetes
enviados por el terminal móvil se encaminan directamente hacia el
destinatario del paquete, eludiendo el servidor doméstico, mientras
que los paquetes enviados al terminal móvil se encaminan en primer
lugar hacia el servidor doméstico y a continuación se tunelizan en
IP-IP hacia el terminal móvil. Este modo es más
eficaz, aunque es incompatible con los encaminadores denominados de
filtrado de entrada, los cuales no encaminan paquetes IP cuyas
direcciones de origen sean topológicamente incorrectas, tal como es
el caso correspondiente a un terminal móvil que está alejado de la
red doméstica. Los detalles de este modo son diferentes, aunque la
idea general es la misma. En el siguiente texto se describe el caso
más general en el que la tunelización IP-IP se usa
para el tráfico entre el terminal móvil y el servidor doméstico en
ambas direcciones.
En la figura 1, cuando un terminal móvil que
está en una red visitada desea enviar un paquete a un anfitrión
objetivo X usando su dirección de auxilio actual, que es una
dirección que se ha tomado prestada de la red visitada, en primer
lugar construye un paquete de datos, cuya dirección de origen es su
dirección doméstica - la cual no es una dirección topológicamente
correcta en la red actual en la que se encuentra el terminal móvil
- y cuya dirección de destino es X. Como la dirección de origen del
paquete es topológicamente incorrecta, es decir, no pertenece a la
red en la que se encuentra el terminal móvil, algunos encaminadores,
especialmente aquellos que implementan el algoritmo denominado del
filtrado de entrada, no encaminarán el paquete correctamente. Para
superar esto, el paquete se encapsula en otro paquete IP; a este
proceso se le denomina tunelización IP-IP ó
encapsulado IP-IP. La nueva dirección externa de
origen del encabezamiento IP es la dirección de auxilio de la red
visitada - que es una dirección topológicamente correcta - y la
dirección externa de destino del encabezamiento IP es el servidor
doméstico del terminal móvil. De este modo, la dirección interna de
origen del encabezamiento IP es la dirección doméstica del terminal
móvil, mientras que la dirección interna de destino del
encabezamiento IP es la correspondiente al anfitrión X. Esto se
indica en la figura 1 con IP | datos, lo cual describe un mensaje
que contiene datos y el encabezamiento IP original, el cual está
encapsulado adicionalmente en un encabezamiento IP externo con
fines relacionados con el encaminamiento. A continuación, este
paquete IP se envía al servidor doméstico en la etapa 1 de
la
figura 1.
figura 1.
Al producirse la recepción del paquete IP
encapsulado, el servidor doméstico desenvuelve el túnel
IP-IP, y procede, en la etapa 2 de la figura 2, con
el encaminamiento de un paquete indicado con IP/Datos, encontrándose
dicho paquete en el interior del encapsulado (en el interior del
encabezamiento IP externo). El encaminamiento se realiza en
concordancia con la dirección interna de destino, presentando en
este momento el paquete, después de haber sido desenvuelto, la
dirección doméstica del terminal móvil como su dirección de origen y
el anfitrión X como su dirección de destino.
Los paquetes inversos desde X al terminal móvil
se gestionan de forma similar; el paquete se encamina en primer
lugar hacia el servidor doméstico en la etapa 3, a continuación se
encapsula en IP-IP y se entrega a la red actual (en
la etapa 4) en la que se encuentra el terminal móvil. La vinculación
de movilidad determina a qué dirección(es) de auxilio se
reenvía el paquete.
En el método de la invención, en lugar de la
tunelización IP-IP se usa una asociación de
seguridad de modo de transporte o en modo de túneles IPSec. La
figura 2 describe un ejemplo del método de la invención para enviar
mensajes cuando un terminal móvil se mueve a una dirección
nueva.
Entre la dirección de auxilio y la dirección del
servidor doméstico, por ejemplo, la dirección de auxilio del
terminal móvil y la dirección del servidor doméstico, se establece
una conexión segura, preferentemente una asociación de seguridad
(SA) IPSec ó más específicamente un agrupamiento de SAs IPsec para
cada dirección de comunicación. La SA también puede incluir
parámetros y atributos adicionales, referentes posiblemente a
extensiones IPSec normalizadas o no normalizadas, tales como
mecanismos para atravesar NATs, que son usadas convencionalmente en
las SAs. Un mensaje a enviar a través de este túnel se señala
IP/IPSec/IP/Datos en la figura 2, que ilustra que el mensaje
contiene una parte de datos con una dirección IP de destino y que se
puede enviar a través de un túnel IPSec, aunque está encapsulado
con un encabezamiento IP externo.
Los paquetes inversos desde X al terminal móvil
se gestionan de forma similar; el paquete en primer lugar se
encamina hacia el servidor doméstico en la etapa 3, a continuación
se procesa en IPSec usando la SA en modo de túneles IPSec, proceso
durante el cual se añade un encabezamiento IP externo al paquete y
el mismo se entrega a la(s) red(es) actual(es)
(en la etapa 4) en la(s) que se encuentra el terminal
móvil.
Cuando se usa el modo de transporte IPSec, el
terminal móvil o bien se puede comunicar directamente con el
servidor doméstico, o bien alternativamente se puede usar algún
protocolo de tunelización externo (aparte de la tunelización IPSec)
para permitir el encaminamiento de paquetes de forma adicional. Por
ejemplo, el Protocolo de Tunelización de la Capa 2 (L2TP) se puede
usar con el modo de transporte IPSec para proporcionar una
funcionalidad similar a la tunelización IPSec.
Cuando el terminal móvil se mueve a una red
nueva, en primer lugar obtiene una dirección de auxilio de la red
visitada. A continuación, el terminal móvil comprueba si ya existe
una SA (o de forma más precisa, un par de agrupamientos SA) entre
la dirección de auxilio nueva y la dirección del servidor
doméstico.
Esta comprobación se realiza normalmente
inspeccionando el contenido de una Base de Datos de Asociaciones de
Seguridad (SADB), tal como especifica el protocolo IPSec. La
implementación real se puede desviar algo con respecto al procesado
nominal. Con frecuencia, el modelo nominal y las operaciones reales
son en realidad algo diferentes (por ejemplo, las implementaciones
IPSec en hardware tienen una implementación de la "SADB"
radicalmente diferente con respecto a una simple consulta). Si ya
existe una asociación de seguridad (SA) IPSec entre el terminal
móvil y el servidor doméstico que define la dirección de auxilio del
terminal móvil en un extremo (la dirección nueva del terminal
móvil) y la dirección del servidor doméstico en el otro extremo,
esta SA se registra de manera que sea la SA real a usar.
Esto se produce por medio de un mensaje de
señalización o un intercambio de mensajes de señalización realizado
entre el terminal móvil y el servidor doméstico, lo cual se describe
mediante las etapas 5 y 6 en la figura 2. Los mensajes
preferentemente se autentican y/o cifran usando la IPSec, y
preferentemente usando la misma SA IPSec que se usa para la
protección de tráfico ordinaria. En algunas formas de realización no
se usa respuesta. La etapa 5 es una solicitud de registro desde el
anfitrión móvil al servidor doméstico para registrar la dirección
nueva y la etapa 6 es una respuesta de registro de vuelta hacia el
terminal móvil.
Cuando no existe una SA entre la dirección de
auxilio nueva y el servidor doméstico, se produce un establecimiento
de SA entre las etapas 4 y 5 de la figura 2. Este establecimiento
de SA puede ser manual, o puede conllevar algún protocolo
automático de intercambio de claves, tal como el Intercambio de
Claves de Internet (IKE).
Al recibir el paquete protegido en IPSec,
enviado usando la SA nueva, el servidor doméstico procesa los
encabezamientos IPSec y descubre el paquete original del túnel
IPSec, y a continuación encamina el paquete IP hacia el anfitrión
X. Si se usa el modo de transporte IPSec, el servidor doméstico
procesa los encabezamientos IPSec y procesa el paquete resultante
en texto sin formato directamente sin encaminarlo hacia delante. No
obstante, si se usa un protocolo de tunelización externo, tal como
el L2TP, el protocolo de tunelización puede reenviar el paquete
después del procesado IPSec.
En la figura 2, los mensajes RREQ y RREP se
muestran sin protección IPSec. En una forma de realización IPSec,
los mensajes protegidos con IPSec se expresarían, por ejemplo, como
IP | IPSec | IP | IP resp. RREQ | IPSec | IP | RREP en
lugar de IP | IP resp. RREQ | RREP. De este modo, se pueden
proteger RREQ/RREP y uno de los métodos de protección sería la
IPSec. Si los mismos se protegen usando la IPSec, para este fin se
puede aprovechar la SA IPSec existente. La protección IPSec de
mensaje(s) de señalización puede usar un modo o bien de
túneles o bien de transporte.
La abreviatura RREQ en la figura 2 significa
Solicitud de Registro mientras que la abreviatura RREP significa
Respuesta de Registro. Las mismas son preferentemente los mensajes
de Solicitud de Registro y Respuesta de Registro IP Móvil, usados
conjuntamente con la IPSec en la invención, aunque se pueden usar
otros formatos de registro. El alcance de la invención incluye
también el uso solamente de un mensaje Solicitud de Registro (que
no use necesariamente el formato IP Móvil exacto), pero no el uso de
un mensaje de Respuesta de Registro.
La invención comprende también tanto el caso en
el que como solicitud de registro implícita se usa el tráfico
autenticado correctamente, como en el que se realiza automáticamente
una actualización de vinculación de movilidad. Como ejemplo
específico, entre el terminal móvil y el servidor doméstico se usa
un agrupamiento SA en modo de túneles IPSec, que incluye un AH
usado para enviar tráfico, en cuyo caso las direcciones del
encabezamiento IP más exterior quedan cubiertas por autenticación
AH. Cuando el terminal móvil se mueve a una red nueva, envía un
paquete de datos que puede ser un paquete de datos vacío si no hay
datos a enviar que se procesen usando el agrupamiento SA IPsec y
que se envíen al servidor doméstico. Una vez que el servidor
doméstico autentica correctamente el mensaje, incluyendo el
encabezamiento IP más exterior, y determina que el mismo proviene
de una dirección que difiere con respecto a la vinculación de
movilidad actual, puede actualizar la vinculación de movilidad
automáticamente. La actualización de la vinculación da como
resultado que la totalidad de los paquetes subsiguientes que estén
destinados al terminal móvil se envíen usando la vinculación de
movilidad actualizada, es decir, la dirección nueva que está usando
el cliente. De este modo, en este caso no se requiere ninguna
señalización de actualización de vinculación de movilidad
explícita.
La descripción anterior de la invención se ha
simplificado en aras de clarificar la descripción. La invención se
puede ampliar de varias maneras sin cambiar, por ello, la idea
subyacente en la misma. A continuación se describen algunas
ampliaciones.
Se pueden usar el concepto IP Móvil de
vinculaciones simultáneas, y la n-difusión de
tráfico asociada desde el servidor doméstico al terminal móvil. En
este caso, los paquetes enviados hacia el terminal móvil se
procesarían usando varias SAs IPSec, una por cada registro
simultáneo, y se enviarían hacia las diferentes redes visitadas
usadas por el terminal móvil. En este caso, el(los)
mensaje(s) de registro contiene(n) campos que indican
cómo se va a modificar la vinculación de movilidad, por ejemplo, si
sustituir vinculaciones existentes, o añadir una vinculación nueva
además de las existentes. También se puede usar el registro
implícito basado en paquetes de datos, posiblemente junto con
mensaje(s) de registro para mantener las vinculaciones.
Cuando entre la dirección de auxilio nueva y la
dirección del servidor doméstico no existe ninguna SA IPSec, y se
establece una SA IPSec, por ejemplo, usando un protocolo
automatizado de intercambio de claves, la finalización del
establecimiento de la SA se puede usar como registro implícito,
eliminando el registro adicional en las etapas 5 y posiblemente 6
de la figura 2.
Cuando anteriormente se hace referencia a "una
Asociación de Seguridad SA" o "un agrupamiento de Asociaciones
de Seguridad SAs", esto significa en la práctica que en ambos
casos se puede usar un agrupamiento SA IPSec - una o más
asociaciones de seguridad IPSec aplicadas secuencialmente - para
cada dirección de tráfico.
La invención no es específica del IPv4 ó IPv6, y
se puede usar con el IP Móvil para IPv4 y el IP Móvil para IPv6. La
ampliación de la invención para versiones IPSec futuras también es
directa.
Claims (18)
-
\global\parskip0.950000\baselineskip
1. Método para garantizar el reenvío seguro de un mensaje en una red de telecomunicaciones, que comprende por lo menos un primer terminal desde el que se envía el mensaje y por lo menos otro terminal hacia el que se envía el mensaje,caracterizado porque- a)
- se establecen una o más conexiones seguras entre direcciones diferentes del primer terminal y una dirección del otro terminal, definiendo estas conexiones por lo menos dichas direcciones de los dos terminales,
- b)
- el primer terminal se mueve de una dirección a otra dirección,
- c)
- se registra una conexión segura entre dicha otra dirección y la dirección del otro terminal de manera que sea por lo menos una de las conexiones activas a usar.
- 2. Método según la reivindicación 1, caracterizado porque se forma una nueva conexión segura entre la otra dirección del primer terminal y la dirección del otro terminal, para el registro en la etapa c), si dicha conexión segura no existe todavía.
- 3. Método según la reivindicación 1, caracterizado porque, la conexión segura se establece en la etapa a) y la reivindicación 2 mediante la formación de una o más Asociaciones de Seguridad, SAs, usando los protocolos IPSec, tal como un agrupamiento de SAs.
- 4. Método según cualquiera de las reivindicaciones 1 a 3, caracterizado porque el mensaje a reenviar consta de paquetes IP.
- 5. Método según cualquiera de las reivindicaciones 1 a 4, caracterizado porque, después de la etapa b), cuando el primer terminal desea enviar un mensaje desde la dirección a la que se ha movido, en primer lugar comprueba si ya existe una conexión segura entre la dirección nueva y el otro terminal.
- 6. Método según la reivindicación 5, caracterizado porque la existencia de la conexión segura nueva se comprueba por medio de una tabla de conexiones.
- 7. Método según cualquiera de las reivindicaciones 1 a 6, caracterizado porque, en la etapa c), la(s) conexión(es) real(es) a usar se registra(n) por medio de un mensaje de señalización o un intercambio de mensajes de señalización entre el terminal móvil y el otro terminal.
- 8. Método según cualquiera de las reivindicaciones 1 a 6, caracterizado porque, la dirección nueva del terminal móvil se actualiza automáticamente por parte del otro terminal cuando el primer terminal envía un mensaje desde su dirección nueva.
- 9. Método según cualquiera de las reivindicaciones 1 a 8, caracterizado porque el intercambio de claves que es parte de la formación de la conexión segura en la etapa a) y la reivindicación 2 se realiza manualmente.
- 10. Método según cualquiera de las reivindicaciones 1 a 8, caracterizado porque un intercambio de claves que es parte de la formación de la conexión segura en la etapa a) y la reivindicación 2 se realiza con el IKE o algún otro protocolo automatizado de intercambio de claves.
- 11. Método según cualquiera de las reivindicaciones 1 a 10, caracterizado porque la conexión segura entre la dirección nueva del primer terminal y el otro terminal se registra en la etapa c) para un uso inmediato y/o posterior.
- 12. Método según la reivindicación 11, caracterizado porque el registro para un uso posterior se realiza por parte del otro terminal en una tabla de conexiones.
- 13. Método según cualquiera de las reivindicaciones 3 a 12, caracterizado porque cuando se envían mensajes a través de la conexión segura, se usa el modo de transporte IPSec para proteger el tráfico entre el ordenador móvil y el ordenador de destino.
- 14. Método según la reivindicación 13, caracterizado porque se usa un protocolo de tunelización junto con la IPSec para proporcionar una capacidad de tunelización.
- 15. Método según la reivindicación 14, caracterizado porque para proporcionar una capacidad de tunelización se usa el protocolo de tunelización Protocolo de Tunelización de la Capa 2, L2TP, junto con la IPSec.
- 16. Método según cualquiera de las reivindicaciones 3 a 15, caracterizado porque cuando se envía un mensaje a través de la conexión segura, se usa el modo de túneles IPSec para proteger el tráfico entre el ordenador móvil y el ordenador de destino.
\global\parskip1.000000\baselineskip
- 17. Sistema para garantizar el reenvío seguro de un mensaje en una red de telecomunicaciones, que comprende por lo menos un primer terminal desde el que se envía el mensaje y por lo menos otro terminal hacia el que se envía el mensaje,caracterizado porque presenta
- unos medios para formar conexiones seguras entre la dirección del otro terminal y direcciones diferentes del primer terminal, tablas con listas de dichas conexiones seguras, y
- unos medios de registro para formar dichas listas.
- 18. Sistema según la reivindicación 17, caracterizado porque presenta unos medios para ejecutar el método de cualquiera de las reivindicaciones 9 a 16.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FI20011911A FI116027B (fi) | 2001-09-28 | 2001-09-28 | Menetelmä ja järjestelmä viestien turvallisen lähettämisen varmistamiseksi |
| FI20011911 | 2001-09-28 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2319171T3 true ES2319171T3 (es) | 2009-05-05 |
Family
ID=8561975
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02764898T Expired - Lifetime ES2319171T3 (es) | 2001-09-28 | 2002-09-27 | Metodo y sistema para garantizar el reenvio seguro de mensajes. |
Country Status (7)
| Country | Link |
|---|---|
| US (1) | US8037302B2 (es) |
| EP (1) | EP1466458B1 (es) |
| AT (1) | ATE417445T1 (es) |
| DE (1) | DE60230326D1 (es) |
| ES (1) | ES2319171T3 (es) |
| FI (1) | FI116027B (es) |
| WO (1) | WO2003030488A1 (es) |
Families Citing this family (21)
| 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 |
| GB0216000D0 (en) * | 2002-07-10 | 2002-08-21 | Nokia Corp | A method for setting up a security association |
| US7804826B1 (en) * | 2002-11-15 | 2010-09-28 | Nortel Networks Limited | Mobile IP over VPN communication protocol |
| US8244875B2 (en) * | 2002-12-13 | 2012-08-14 | ANXeBusiness Corporation | Secure network computing |
| US8332464B2 (en) * | 2002-12-13 | 2012-12-11 | Anxebusiness Corp. | System and method for remote network access |
| 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 |
| EP2099195A1 (en) * | 2005-03-31 | 2009-09-09 | Panasonic Corporation | Privacy protection for mobile internet protocol sessions |
| JP4190521B2 (ja) * | 2005-07-14 | 2008-12-03 | 株式会社東芝 | マルチプロトコルアドレス登録方法、マルチプロトコルアドレス登録システム、マルチプロトコルアドレス登録サーバおよびマルチプロトコルアドレス通信端末 |
| US7853691B2 (en) * | 2006-11-29 | 2010-12-14 | Broadcom Corporation | Method and system for securing a network utilizing IPsec and MACsec protocols |
| US7937747B2 (en) | 2007-03-27 | 2011-05-03 | Panasonic Corporation | Privacy protection for mobile internet protocol sessions |
| WO2009099358A1 (en) * | 2008-02-08 | 2009-08-13 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for use in a communications network |
| US8411691B2 (en) * | 2009-01-12 | 2013-04-02 | Juniper Networks, Inc. | Transfer of mobile subscriber context in cellular networks using extended routing protocol |
| US8385332B2 (en) * | 2009-01-12 | 2013-02-26 | Juniper Networks, Inc. | Network-based macro mobility in cellular networks using an extended routing protocol |
| CN102484783B (zh) * | 2009-08-20 | 2014-11-26 | Nec欧洲有限公司 | 用于控制网络结构与网络结构之间的业务量的方法 |
| US8711843B2 (en) * | 2010-10-29 | 2014-04-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Cryptographically generated addresses using backward key chain for secure route optimization in mobile internet protocol |
| CN104205896B (zh) * | 2012-03-23 | 2018-12-28 | 诺基亚技术有限公司 | 有拓扑不准确的源地址的IPv6数据包的自动隧道传输方法 |
| US8924612B2 (en) * | 2012-04-04 | 2014-12-30 | Arm Limited | Apparatus and method for providing a bidirectional communications link between a master device and a slave device |
| US10051000B2 (en) * | 2015-07-28 | 2018-08-14 | Citrix Systems, Inc. | Efficient use of IPsec tunnels in multi-path environment |
| US10198724B2 (en) * | 2015-08-21 | 2019-02-05 | Mastercard International Incorporated | Payment networks and methods for facilitating data transfers within payment networks |
| US10547597B2 (en) * | 2017-01-24 | 2020-01-28 | International Business Machines Corporation | Secure network connections |
| US11108739B2 (en) * | 2018-02-20 | 2021-08-31 | Blackberry Limited | Firewall incorporating network security information |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6091951A (en) * | 1997-05-14 | 2000-07-18 | Telxon Corporation | Seamless roaming among multiple networks |
| US6452915B1 (en) * | 1998-07-10 | 2002-09-17 | Malibu Networks, Inc. | IP-flow classification in a wireless point to multi-point (PTMP) transmission system |
| US6418130B1 (en) * | 1999-01-08 | 2002-07-09 | Telefonaktiebolaget L M Ericsson (Publ) | Reuse of security associations for improving hand-over performance |
| DE60024237T2 (de) * | 1999-03-17 | 2006-06-29 | 3Com Corp., Rolling Meadows | Verfahren und system zur netzwerkadressübersetzung mit sicherheitseigenschaften |
| 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 |
| JP3730480B2 (ja) * | 2000-05-23 | 2006-01-05 | 株式会社東芝 | ゲートウェイ装置 |
-
2001
- 2001-09-28 FI FI20011911A patent/FI116027B/fi not_active IP Right Cessation
-
2002
- 2002-09-27 US US10/490,933 patent/US8037302B2/en active Active
- 2002-09-27 DE DE60230326T patent/DE60230326D1/de not_active Expired - Lifetime
- 2002-09-27 WO PCT/FI2002/000771 patent/WO2003030488A1/en not_active Application Discontinuation
- 2002-09-27 EP EP02764898A patent/EP1466458B1/en not_active Expired - Lifetime
- 2002-09-27 AT AT02764898T patent/ATE417445T1/de not_active IP Right Cessation
- 2002-09-27 ES ES02764898T patent/ES2319171T3/es not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| US8037302B2 (en) | 2011-10-11 |
| EP1466458A1 (en) | 2004-10-13 |
| US20050177722A1 (en) | 2005-08-11 |
| EP1466458B1 (en) | 2008-12-10 |
| FI116027B (fi) | 2005-08-31 |
| WO2003030488A1 (en) | 2003-04-10 |
| FI20011911A0 (fi) | 2001-09-28 |
| ATE417445T1 (de) | 2008-12-15 |
| DE60230326D1 (de) | 2009-01-22 |
| FI20011911A (fi) | 2003-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2319171T3 (es) | Metodo y sistema para garantizar el reenvio seguro de mensajes. | |
| ES2336898T3 (es) | Metodo y red para asegurar el envio seguro de mensajes. | |
| US6839338B1 (en) | Method to provide dynamic internet protocol security policy service | |
| ES2362993T3 (es) | Un método y disposición para proporcionar seguridad a través de conversión de direcciones de red utilizando tunelado y compensaciones. | |
| KR100679882B1 (ko) | 사설 네트워크와 로밍 모바일 단말 사이의 통신 | |
| Arkko et al. | Using IPsec to protect mobile IPv6 signaling between mobile nodes and home agents | |
| ES2287697T3 (es) | Metodo de direccionamiento y aparato para establecer conexiones de protocolo de identidad de anfitrion (hip) entre legados y nodos hip. | |
| US9300634B2 (en) | Mobile IP over VPN communication protocol | |
| JP5087012B2 (ja) | ロケーションプライバシをサポートする経路最適化 | |
| US20040037260A1 (en) | Virtual private network system | |
| US20020066036A1 (en) | System and method for secure network mobility | |
| KR20070097547A (ko) | 모바일 노드 간의 저지연성 보안 세션 연속성을 제공하는방법 및 장치 | |
| BRPI0611781A2 (pt) | método e equipamento para atribuição dinámica de endereço nativo por agente nativo em interfuncionamento de múltiplas redes | |
| EP2201742B1 (en) | Provisioning mobility services to legacy terminals | |
| KR100799575B1 (ko) | ＩＰｖ６ 네트워크에서 이동노드에게 ＶＰＮ 서비스를제공하는 방법 및 이를 위한 게이트웨이 | |
| FI113597B (fi) | Menetelmä viestien lähettämiseksi usean yhteyden läpi | |
| Arkko et al. | RFC 3776: Using IPsec to protect mobile IPv6 signaling between mobile nodes and home agents | |
| Pulkkis et al. | Mobile virtual private networking | |
| Wang et al. | IPSec-based key management in mobile IP networks | |
| Dupont | Network Working Group J. Arkko Request for Comments: 3776 Ericsson Category: Standards Track V. Devarapalli Nokia Research Center |