ES2318785T3 - Autenticacion de anuncio de ruta en un descubrimiento de enrutador rapido (frd). - Google Patents
Autenticacion de anuncio de ruta en un descubrimiento de enrutador rapido (frd). Download PDFInfo
- Publication number
- ES2318785T3 ES2318785T3 ES06780273T ES06780273T ES2318785T3 ES 2318785 T3 ES2318785 T3 ES 2318785T3 ES 06780273 T ES06780273 T ES 06780273T ES 06780273 T ES06780273 T ES 06780273T ES 2318785 T3 ES2318785 T3 ES 2318785T3
- Authority
- ES
- Spain
- Prior art keywords
- quad
- mobile node
- router
- address
- nonce
- 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.)
- Active
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/12—Applying verification of the received information
- H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
-
- 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/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/16—Discovering, processing access restriction or access information
-
- 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)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Un método para autentificar en un Nodo Móvil (110) un primer Anuncio de Enrutador recibido de un Punto de Acceso (128), comprendiendo el método las operaciones de: recibir en el Nodo Móvil desde el Punto de Acceso el primer Anuncio de Enrutador que comprende un primer Prefijo de Red, un Índice Nonce y un primer Valor Nonce Hasheado; configurar en el Nodo Móvil una primera dirección IP mediante el uso de un primer Prefijo de Red, y concurrentemente autentificar el primer Anuncio de Enrutador mediante: recibir en el Nodo Móvil desde un Enrutador de Acceso (150) un segundo Anuncio de Enrutador, comprendiendo el segundo Anuncio de Enrutador un Valor Nonce correspondiente al Índice Nonce y un segundo Prefijo de Red; hashear en el Nodo Móvil el Valor Nonce para calcular un segundo Valor Nonce Hasheado; y comparar en el Nodo Móvil el primer Valor Nonce Hashed y el segundo Valor Nonce Hashed; y mantener en el Nodo Móvil la primera dirección IP si el primer Valor Nonce Hasheado es igual al segundo Valor Nonce Hasheado.
Description
Autenticación de anuncio de ruta en un
descubrimiento de enrutador rápido (FRD).
La presente invención se refiere a un método y a
un Nodo Móvil para soportar autenticación en un mensaje de Anuncio
de Enrutamiento recibido directamente de un Punto de Acceso.
Cuando un Nodo Móvil (MN) entra en el dominio de
un nuevo Punto de Acceso (AP), debe configurar una nueva dirección
de Protocolo de Internet (IP), que normalmente consiste en una
dirección de Protocolo de Internet versión 6 (IPv6), para
comunicarse con una red de Internet a través de ese AP. Para
conseguir esto, el MN necesita recibir, desde un Enrutador de
Acceso (AR) conectado al AP, un mensaje de Anuncio de Enrutamiento
(RtAdv) que comprende Prefijos de Red que el MN utiliza para
configurar la nueva dirección IP. Sólo cuando la nueva dirección IP
se ha configurado completamente puede empezar el MN la comunicación
de paquetes de datos con la red de Internet.
La configuración de la dirección IP es un
proceso lento. En primer lugar, aunque el AR envía mensajes RtAdv
periódicos, normalmente en modo Multidifusión, no está autorizado
para enviar dichos mensajes a una frecuencia mayor de uno cada tres
(3) segundos (RFC2461, "Descubrimiento de vecinos para IP versión
6 (IPv6)", T. Narten, E. Nordmark, W. Simpson, IETF, Diciembre
1998). En segundo lugar, para evitar que diferentes Nodos Móviles,
u otros clientes, adquieran la misma dirección IP y afecten
negativamente la comunicación de los otros, el MN debe, como parte
del proceso de configuración de IP, iniciar un procedimiento de
Detección de Dirección Duplicada (DAD). El procedimiento DAD
introduce elevados retardos, del orden de un (1) segundo, en el
proceso de adquisición de IP. Los retardos introducidos debido a la
baja periodicidad de los mensajes de Anuncio de Enrutamiento y por
el procedimiento DAD se vuelven críticos durante la transferencia de
la conexión, ya que añaden una latencia indeseada. Esta latencia es
especialmente dañina cuando el Nodo Móvil (MN) está ejecutando
aplicaciones sensibles al
tiempo.
tiempo.
La Propuesta de Descubrimiento de Enrutador
Rápido (FRD) ("Descubrimiento de Enrutador Rápido con Cacheado
RA",
draft-jinchoi-dna-frd-00.txt,
JinHyeock. Choi, DongYun, Shin, IETF, Julio 12, 2004) trata de
minimizar el retardo obligatorio, según se describe en RFC2461, que
evita que el MN reciba un RtADV de un nuevo AR inmediatamente
después de cambiar a un nuevo enlace. Con este objeto, el
Descubrimiento de Enrutador Rápido (FRD) consiste en cachear un
contenido de un(os) mensaje(s) RtAdv en el AP. Cuando
el MN entra en el dominio de un AP dado, envía en dirección al AP
un mensaje de Solicitud de Asociación. Debido a que el AP ha
cacheado el contenido de los mensajes RtAdv, entonces envía este
contenido en paralelo al envío de un mensaje de Respuesta de
Asociación al MN. Esto habilita al MN a comenzar el proceso de
configurar su dirección IP sin esperar un RtAdv periódico.
La mayor amenaza en la situación descrita arriba
consiste en cachear un mensaje RtAdv falso en un AP malicioso, que
permite lanzar fácilmente un ataque de Denegación de Servicio (DoS)
contra el MN.
Habría claras ventajas si existiera un método y
un Nodo Móvil para permitir la verificación de la validez de un
mensaje de Anuncio de Enrutamiento recibido directamente de un Punto
de Acceso, en el contexto de la tecnología de Descubrimiento de
Enrutador Rápido. Por ejemplo, US 2004/0240669A1 describe cómo
asegurar el descubrimiento de un enrutador en un sistema IP móvil
basado en mensajes de descubrimiento de enrutador de autenticación
vía firmas digitales comprendidas en anuncios de enrutador.
Es por tanto un amplio objeto de esta invención
proporcionar un método y un Nodo Móvil (MN) para permitir dotar al
MN de un cierto nivel de confianza relativo a que un mensaje de
Anuncio de Enrutamiento (RtAdv) cacheado en un Punto de Acceso (AP)
pertenece a un Enrutador de Acceso (AR) legítimo.
Un primer aspecto de la presente invención está
dirigido a un método para autentificar en un MN un primer Anuncio
recibido de un AP, representando el Anuncio datos recibidos de un AR
y cacheados en el AP. El Anuncio comprende un Prefijo de Red
requerido por el MN para establecer una dirección de Protocolo de
Internet (IP)El Anuncio comprende además un Índice Nonce y
un Valor Nonce Hasheado. El MN inicia un proceso de establecimiento
de la dirección IP inmediatamente después de recibir el primer
Anuncio del AP. En paralelo, envía una Solicitud, que incluye el
Índice Nonce, al Enrutador de Acceso. Mientras el proceso de
establecer la dirección IP se está efectuando, el MN recibe un
segundo Anuncio que comprende un Valor Nonce. El MN hashea el Valor
Nonce y compara un Resultado del hasheado con el Valor Nonce
Hasheado. Si la comparación tiene éxito, el MN mantiene la
dirección IP.
Un segundo aspecto de la presente invención está
dirigido al método de autentificar en el MN el primer Anuncio
recibido del AP donde, cuando la comparación del Valor Nonce
Hasheado con el Resultado de hashear el Valor once en el MN no
tiene éxito, el MN abandona la dirección IP e inicia el
establecimiento de una nueva dirección IP utilizando un Prefijo de
Red recibido en el segundo Anuncio.
Un tercer aspecto de la presente invención está
dirigido al método de autentificar en el MN el primer Anuncio
recibido del AP donde el MN y el AR utilizan claves de Dirección
Generada Criptográficamente (CGA) para autentificar aún mejor los
Anuncios y la Solicitud.
Un cuarto aspecto de la presente invención está
dirigido a un MN para autentificar un primer Anuncio recibido de un
AP, representando el Anuncio datos recibidos de un AR y cacheados en
el AP. El Nodo Móvil comprende un Receptor para recibir Anuncios,
una Memoria Temporal para almacenar elementos de información
recibidos en los Anuncios y para almacenar una dirección IP, un
Transmisor para enviar una Solicitud, un Procesador para configurar
la dirección IP y para hashear un Valor Nonce recibido en los
Anuncios, y una Lógica de Decisión. El Procesador configura la
dirección IP basándose en un Prefijo de Red recibido en un primer
Anuncio. Mientras tanto, el transmisor envía la Solicitud que
comprende un Índice Nonce recibido en el primer Anuncio. El Receptor
recibe un segundo Anuncio que comprende un Valor Nonce. El
Procesador hashea el Valor Nonce. La Lógica de Decisión compara un
Resultado del hasheado con un Valor Nonce Hasheado recibido en el
primer Anuncio. La Lógica de Decisión decide mantener la dirección
IP, en caso de que la comparación sea positiva.
Para una comprensión más detallada de la
invención, para otros objetos y ventajas de la misma, se puede hacer
ahora referencia a la siguiente descripción, tomada en conjunto con
los dibujos adjuntos, en los que:
La Figura 1 es una representación de una red
Móvil IPv6;
Las Figuras 2a y 2b muestran una representación
ejemplar de un método para autentificar un Anuncio recibido en un
Nodo Móvil de un Punto de Acceso; y
La Figura 3 muestra un Nodo Móvil ejemplar
fabricado de acuerdo con la presente invención.
Las enseñanzas innovadoras de la presente
invención se describirán haciendo referencia particular a varios
usos ejemplares y a aspectos de la realización preferida. Sin
embargo, se debe entender que esta realización sólo proporciona
unos pocos ejemplos de los múltiples usos ventajosos de las
enseñanzas de la invención. En general, las afirmaciones de la
descripción de la presente solicitud no limitan necesariamente
ninguno de los varios aspectos reivindicados de la presente
invención. Además, algunas afirmaciones se pueden aplicar a algunas
características inventivas pero no a otras. En la descripción de las
figuras, números iguales representan elementos equivalentes de la
invención.
La presente invención proporciona un método y un
Nodo Móvil (MN) para soportar un método de Descubrimiento de
Enrutador Rápido (FRD) en el que un contenido de Anuncios periódicos
enviados desde Enrutadores de Acceso (AR), por ejemplo mensajes de
Anuncio de Enrutamiento (RtAdv), son cacheados en Puntos de Acceso
(AP). Cuando el MN entra en un dominio o área de cobertura, de un
AP dado, envía en dirección al AP un mensaje de Solicitud de
Asociación (AssReq). De acuerdo con el método FRD, el AP responde al
AssReq enviando una Respuesta de Asociación (AssResp) junto con
elementos de información, que forman el contenido de un RtAdv,
previamente cacheado en el AP. El RtAdv proporcionado al MN por el
AP puede ser enviado bien como una parte del AssResp o bien puede
ser enviado en paralelo con el AssResp. Para proporcionar medios al
MN para autentificar que el RtAdv proporcionado por el AP es
legítimo, el RtAdv periódico enviado por el AR y cacheado en el AP
comprende, de acuerdo con la presente invención, valores de
autentificación. Los valores de autentificación preferiblemente
consisten en un Índice Nonce y un Valor Nonce Hashed; habiendo sido
producido el Valor Nonce Hasheado en el AR hasheando un Valor Nonce
que puede estar direccionado en una tabla del AR por uso del Índice
Nonce. Se define un Nonce, en el presente documento, como un número
que se utiliza sólo una vez. Tan pronto como recibe el RtAdv, el MN
inicia un procedimiento para configurar una dirección IP, por el
método FRD. En paralelo con este proceso de configuración, y para
verificar que el RtAdv recibido del AP es legítimo, el MN envía una
Solicitud en dirección al AR. En la Solicitud, de acuerdo con la
presente invención, el MN incluye el Índice Nonce. El AR recibe el
Índice Nonce y adquiere el Valor Nonce correspondiente. El AR envía
el Valor Nonce hacia el MN en un nuevo RtAdv. Cuando el MN recibe
este nuevo RtAdv, hashea el Valor Nonce y compara un Resultado de
este hasheado con el Valor Nonce Hasheado que había recibido con el
RtAdv anterior. Si los dos valores hasheados son iguales, significa
que el RtAdv anterior que había recibido provenía de este AR, y no
un resultado de información maliciosa enviada por el AP. Tanto si
el proceso de configurar la dirección IP está completado en este
momento o no, el MN considera que la dirección IP resultante será
válida.
En el contexto de la presente invención, el MN
puede comprender un teléfono móvil celular, un asistente personal
digital, un ordenador portátil y similares. El AP puede comprender
un Punto de Acceso IEEE 802.11, un Punto de Acceso IEEE 802.16, y
similares. El AP y el AR se pueden implementar en un único aparato o
como elementos distintos conectados por un enlace de
comunicación.
Para proporcionar una base para una descripción
de la realización preferida de la presente invención, se hace ahora
referencia a los Dibujos, en los que la Figura 1 muestra una
representación parcial de una red Móvil IPv6 (MIPv6) 100. La red
MIPv6 100 comprende un Nodo Móvil (MN) 110, Puntos de Acceso (AP)
120, 130 y 140, y Enrutadores de Acceso (AR) 150 y 160. Un AR puede
estar conectado a uno o a muchos AP. Los expertos medios en la
materia reconocerán que la red MIPv6 100 normalmente comprenderían
un gran número de MN 110. El MN 110 sólo se comunica a través de AP
120, 130 o 140, pero un mensaje enviado por el MN 110 puede tener
como destinatario el AP 120, 130 o 140, o el AR 150 o 160. El AR
150 y 160 periódicamente envía mensajes RtAdv para permitir a
cualquier MN 110 configurar una dirección IP. Los mensajes RtAdv son
enviados al MN 110 a través del AP 120, 130 y 140. De acuerdo con
el método FRD, los AP 120, 130 y 140 son capaces de mantener una
copia del contenido del RtAdv en sus caches.
Cuando el MN 100 entra en el dominio, o área de
cobertura, de alguno de los AP 120, 130 o 140, envía un AssReq por
un Camino 180 hacia un AP seleccionado de entre los AP 120, 130 o
140, solicitando el establecimiento de una sesión. Si el AP 120,
130 o 140 puede efectuar FRD, incluye en un AssResp enviado al MN
110 un contenido de un RtAdv recientemente cacheado. El contenido
del RtAdv es recibido en el MN 110 a través del camino 180,
generalmente más rápido que un eventual RtAdv periódico enviado
directamente por el AR 150 o 160. Esto permite al MN 110 iniciar
inmediatamente la configuración de una dirección IP para comunicarse
con el AR 150 o 160.
Con mucha frecuencia, puede haber un AP 170
Malicioso en la red MIPv6 100 de la Figura 1. Si, en lugar de
acceder a uno de los AP 120, 130 140 legítimos, el MN accede al AP
170 Malicioso, envía un AssReq por el camino 190. El AP 170
Malicioso responde con un AssResp que comprende información RtAdv
maliciosa. El MN 110 configura entonces una dirección IP inválida
basada en la información fraudulenta. El MN 110 puede entonces
intentar establecer una sesión con la dirección IP inválida, basado
en la creencia de que la sesión es legítima. El AP 170 Malicioso
puede utilizar la sesión para provocar daños al MN 110 o a su
usuario, por ejemplo, enviando un virus al MN 110 o extrayendo
información confidencial del MN 110.
Una vez descrito en las líneas anteriores un
contexto de una red MIPv6 que soporta el método FRD, un aspecto de
la realización preferida de la presente invención se describirá
ahora haciendo referencia a las Figuras 2a y 2b, que muestran una
representación ejemplar de un método para autentificar un Anuncio
recibido en un Nodo Móvil desde un Punto de Acceso. El MN 110, el
AP 120 y el AR 150 de las Figuras 2a y 2b están construidos de
acuerdo con las enseñanzas de la presente invención.
En la operación 205, el AR 150 envía
periódicamente Anuncios, como mensajes de Anuncio de Enrutamiento
(RtAdv), a través del AP 120, a una frecuencia que no excede uno
cada tres (3) segundos. Los mensajes RtAdv son enviados por
multidifusión hacia todos los terminales, como dispositivos
portátiles de usuario, que puedan estar dentro de la cobertura del
AP 120. El RtAdv comprende información en la forma de un Prefijo de
Red el AR 150, un Índice Nonce (NI), un Valor Nonce Hasheado (HNV),
una dirección del AR 150 y, opcionalmente, una Clave Pública del AR
(ARK+). En una realización preferida de la presente invención, la
ARK+ es una clave de Dirección Generada Criptográficamente (CGA).
Si en la operación 205 un MN 110 dado ya está dentro de la cobertura
del AP 120, recibe el RtAdv periódico. Opcionalmente, el AR 150
también puede enviar al AP 120, a una frecuencia mayor, otros pares
NI-HNV en la operación 207. El AP 120 cachea la
información del RtAdv 205 periódico, así como los pares
NI-HNV opcionales en su memoria interna en la
operación 210.
En la operación 215, otro MN 110 que no recibió
anteriormente un mensaje RtAdv entra en la cobertura, o dominio, el
AP 120. Para establecer una sesión, envía en la operación 220 un
mensaje de Solicitud de Asociación (AssReq) al AP 120, para
solicitar el establecimiento de una conexión. En la operación 225,
el AP 120 responde con una Respuesta de Asociación (AssResp). La
AssResp comprende toda la información que ha cacheado recientemente
para el RtAdv, incluyendo un par NI-HNV par dado que
preferiblemente es uno de muchos pares NI-HNV
actualmente cacheados en el AP 120. Alternativamente, el AP 120
puede enviar la AssResp y el RtAdv secuencialmente, como dos
mensajes distintos, en un período de tiempo muy breve.
Opcionalmente, el AP 120 puede, en la operación 227, enviar una
Solicitud al AR 150, por ejemplo un mensaje de Solicitud de Ruta
(RtSol), en nombre del MN 110. Este mensaje RtSol, si se envía en
esta operación, provocará el envío por el AR 150 de otro mensaje
RtAdv al MN 110, como se describe a continuación. Si el AP 120 está
configurado para enviar el mensaje RtSol, incluye un parámetro para
informar al MN 110 de este hecho en la AssResp enviado en la
operación 225.
Volviendo a la operación 225, el MN 110 que ha
recibido el primer contenido RtAdv almacena el HNV, que es un
primer HNV para la sesión, el NI, el Prefijo de Red, la dirección
del AR 150, y el ARK+ si se le ha proporcionado. El MN 110 puede
empezar a configurar una dirección IP, por ejemplo una dirección
IPv6, en la operación 230, utilizando el Prefijo de Red del AR 150.
Debido a que el proceso de configurar la dirección IP, posiblemente
incluyendo un procedimiento de Detección de Dirección Duplicada
(DAD), típicamente toma más de un segundo, y debido a que un RtAdv
periódico eventual, obtenido directamente del AR 150, podría no
recibirse hasta pasado un retardo de tres segundos, o incluso
mayor, iniciar el proceso de configuración de la dirección IP ya en
la operación 230 ahorra una gran cantidad de tiempo y favorece el
rápido establecimiento de aplicaciones sensibles al retardo por el
MN 110. En este punto, sin embargo, el MN 110 no tiene ninguna
prueba de la legitimidad del contenido RtAdv.
Para autentificar el contenido RtAdv mientras el
proceso de configuración de la dirección IP se está llevando a
cabo, el MN 110 puede enviar en la operación 235 una Solicitud al AR
150, por ejemplo un mensaje de Solicitud de Ruta (RtSol). En una
realización alternativa, el AP 120 puede haber enviado ya el mensaje
RtSol en la operación 227, en nombre del MN 110, como se ha
descrito anteriormente. En cualquier caso, el mensaje RtSol, tanto
si es enviado por el AP 120 en la operación 227 o por el MN 110 en
la operación 235, comprende el NI que se proporcionó por el AR 150
en el RtAdv periódico, en la operación 205. El mensaje RtSol es
preferiblemente enviado en Monodifusión utilizando la dirección del
AR 150. El mensaje RtSol está opcionalmente firmado con una Clave
Privada del MN (MNK-). En una realización preferida de la presente
invención, el MNK- es una clave de Dirección Criptográficamente
Generada (CGA).
En la operación 240, el AR 150 preferiblemente
quita el NI y un Valor Nonce correspondiente de una tabla interna,
para forzar a ese futuro RtAdv a utilizar un par
NI-HNV diferente. En la operación 245, el AR 150
responde al MN 110 con otro RtAdv, que es un segundo RtAdv que
llega al MN 110. Este segundo RtAdv también comprende el Prefijo de
Red del AR 150. También comprende el Valor Nonce que corresponde al
NI. También comprende preferiblemente el ARK+ del AR 150. En una
realización preferida de la presente invención, el segundo RtAdv es
Monodifusión y está firmado utilizando una Clave Privada del AR 150
(ARK-).
Opcionalmente, en la operación 250, el MN 110
hace una primera verificación de la validez el segundo RtAdv
utilizando la ARK+. Si la verificación falla en la operación 255, el
MN 110 envía un nuevo mensaje RtSol en Multidifusión en la
operación 280. El MN 110 entonces espera en la operación 285 a un
nuevo RtAdv periódico. El MN 110 eventualmente recibirá un RtAdv
periódico que comprende un Prefijo de Red del AR 150, y de acuerdo
con eso configurará una nueva dirección IP.
Si la verificación tiene éxito en la operación
255, el MN 110 ha autentificado el segundo RtAdv. El MN 110 hashea
el Valor Nonce en la operación 260 para obtener un segundo HNV. En
la operación 265, el MN 110 compara el primer y segundo HNV. Si
éstos son idénticos, el MN 110 ha autentificado el primer RtAdv.
Puede comenzar a utilizar la dirección IP en la operación 270 para
enviar y recibir paquetes de datos bien inmediatamente, o poco
después cuando el proceso de configuración de la dirección IP, que
se está ejecutando en paralelo con el proceso de autentificación,
se haya completado. Si, sin embargo, los valores del primer y
segundo HNV no son idénticos, en la operación 265, el MN 110 no ha
autentificado el primer RtAdv. Elimina todo el contenido almacenado
previamente para el primer RtAdv en la operación 290. Comienza a
configurar, en la operación 295, una nueva dirección IP utilizando
el Prefijo de Red recibido del AR 150 en el segundo RtAdv. Al final
del proceso de la operación 295, el MN 110 podrá utilizar la nueva
dirección IP para enviar y recibir paquetes de datos.
Aquellos expertos en la materia verán fácilmente
a partir de la descripción precedente que el método de la presente
invención proporciona un medio para que el MN 110 obtenga una
dirección IP válida más rápidamente que en una red MIPv6
tradicional, de un modo más seguro que sólo con el método FRD.
Una construcción ejemplar de un Nodo Móvil
utilizado en la descripción precedente, se describirá ahora haciendo
referencia a la Figura 3, que muestra un MN 110 ejemplar. El MN 110
comprende un Transmisor (TX) 310, un Receptor (RX) 320, un
Procesador 330, un Manipulador 340 de Paquetes de Datos, una Memoria
350 Permanente, una Memoria 360 Temporal y una Lógica de Decisión
370. El MN 110 también puede comprender más elementos, como una
pantalla, una antena, un teclado, una batería, etc. como es bien
conocido en la técnica.
La Memoria 350 Permanente almacena una Clave
Pública del Nodo Móvil (MNK+) y una Clave Privada del Nodo Móvil
(MNK-). La Memoria 350 Permanente también almacena otros datos como,
por ejemplo, una identidad permanente del MN 110, como es bien
conocido en la técnica.
El TX 310 envía mensajes directamente a Puntos
de Acceso, y a Enrutadores de Acceso a través de Puntos de Acceso.
Estos mensajes comprenden AssReq, RtSol, así como paquetes de datos.
Específicamente, el mensaje RtSol enviado por el TX 310 puede ser
un mensaje RtSol Monodifusión enviado a direcciones específicas, o
un mensaje RtSol Multidifusión.
El RX 320 recibe mensajes directamente de Puntos
de Acceso y de Enrutadores de Acceso a través de Puntos de Acceso.
Estos mensajes comprenden AssResp, RtAdv así como paquetes de datos.
Específicamente, el RtAdv recibido por el RX 320 puede ser un RtAdv
Monodifusión y un RtAdv periódico Multidifusión.
La Memoria Temporal 360 almacena información
relacionada con una sesión abierta con un AP y un AR. Dicha
información comprende un NI, un primer HNV, un Valor Nonce, un
Prefijo de Red, una dirección del AR, un ARK+, una dirección IP y
otros datos requeridos para tener la sesión. La Memoria 350 Temporal
puede, a petición de la Lógica 370 de Decisión o del Procesador
330, sobrescribir información con otra información parecida.
El Procesador 330 ejecuta un proceso para
establecer una dirección IP, por ejemplo una dirección IPv6, para
la sesión con el AP y el AR, utilizando el Prefijo de Red. El
proceso de establecer la dirección IP preferiblemente comprende un
procedimiento DAD. El Procesador 330 puede ejecutar el proceso de
establecimiento de IP tantas veces como sea solicitado por la
Decisión 370 en la misma sesión. Cuando el Procesador 330 ejecuta el
proceso de establecimiento de IP como un resultado de recibir el
AssResp por el RX 320, preferiblemente inicia este proceso de
establecimiento del IP concurrentemente con un proceso para
autentificar un primer Anuncio. El Procesador 330 también tiene una
capacidad hasheado utilizada para hashear el Valor Nonce y para
proporcionar, como un resultado de este hasheado del Valor Nonce,
un segundo HNV a la Lógica 370 de Decisión. El Procesador 330 tiene
además una capacidad de verificación para verificar una firma del
mensaje RtAdv con el ARK+, y una capacidad de firma para firmar el
mensaje RtSol con el MNK-. Las capacidades de verificación y firma
son preferiblemente del tipo CGA.
La Lógica 370 de Decisión determina, basándose
en información recibida por el RX 320 en el AssResp, si se debe
enviar o no una Solicitud por el TX 310. Alternativamente, esta
característica pueden no estar implementada por la Lógica 370 de
Decisión y la Solicitud puede siempre ser enviada por el TX 310. La
Lógica 370 de Decisión realiza una comparación del primer HNV
obtenido del mensaje RtAdv con el segundo HNV obtenido del
Procesador 330. La Lógica 370 de Decisión decide, basándose en esta
comparación, si el primer Anuncio es autentificado o no y,
consecuentemente, decide si mantener la dirección IP, o liberar la
dirección IP y ordenar al Procesador 330 el establecimiento de una
nueva dirección IP. La Lógica 370 de Decisión también puede decidir
mantener o liberar la dirección IP basándose en una verificación de
firma positiva o fallida del mensaje RtAdv.
El Manipulador 340 de Paquetes de Datos, cuando
la Lógica 370 de Decisión ha decidido mantener la dirección IP,
recibe paquetes de datos del RX 320 y los reenvía a las aplicaciones
en el MN 110. El Manipulador 340 de Paquetes de Datos entonces
recibe también paquetes de datos de aplicaciones y las reenvía al TX
310.
Aunque múltiples aspectos de la realización
preferida del método y del Nodo Móvil de la presente invención se
han ilustrado en los Dibujos adjuntos y se han descrito en la
Descripción Detallada precedente, se entenderá que la invención no
está limitada a la realización descrita, sino que soporta numerosos
cambios, modificaciones y sustituciones sin salirse del ámbito de
la invención según establecen y definen las siguientes
reivindicaciones.
Claims (23)
1. Un método para autentificar en un Nodo Móvil
(110) un primer Anuncio de Enrutador recibido de un Punto de Acceso
(128), comprendiendo el método las operaciones de:
- \quad
- recibir en el Nodo Móvil desde el Punto de Acceso el primer Anuncio de Enrutador que comprende un primer Prefijo de Red, un Índice Nonce y un primer Valor Nonce Hasheado;
- \quad
- configurar en el Nodo Móvil una primera dirección IP mediante el uso de un primer Prefijo de Red, y concurrentemente autentificar el primer Anuncio de Enrutador mediante:
- recibir en el Nodo Móvil desde un Enrutador de Acceso (150) un segundo Anuncio de Enrutador, comprendiendo el segundo Anuncio de Enrutador un Valor Nonce correspondiente al Índice Nonce y un segundo Prefijo de Red;
- hashear en el Nodo Móvil el Valor Nonce para calcular un segundo Valor Nonce Hasheado; y
- comparar en el Nodo Móvil el primer Valor Nonce Hashed y el segundo Valor Nonce Hashed; y
- \quad
- mantener en el Nodo Móvil la primera dirección IP si el primer Valor Nonce Hasheado es igual al segundo Valor Nonce Hasheado.
2. El método de la Reivindicación 1, que además
comprende las operaciones de:
- \quad
- si el primer Valor Nonce Hasheado no es igual al segundo Valor Nonce Hasheado, eliminar en el Nodo Móvil un contenido del primer Anuncio de Enrutador; y
- \quad
- configurar en el Nodo Móvil una segunda dirección IP utilizando el segundo Prefijo de Red contenido en el segundo Anuncio de Enrutador.
3. El método de la Reivindicación 1, donde:
- \quad
- al menos uno del primer y segundo Anuncio de Enrutador además comprende una Clave Pública del Enrutador de Acceso.
4. El método de la reivindicación 3, que además
comprende las operaciones de:
- \quad
- verificar en el Nodo móvil el segundo Anuncio de Enrutador mediante el uso de la Clave Pública del Enrutador de Acceso; y
- \quad
- si la verificación del segundo Anuncio de Enrutador fracasa:
- \quad
- enviar desde el Nodo Móvil en dirección al Enrutador de Acceso una Solicitud; y
- \quad
- esperar en el Nodo Móvil por un Anuncio de Enrutador Periódico.
5. El método de la Reivindicación 1, donde:
- \quad
- el segundo Anuncio de Enrutador es Monodifusión.
6. El método de la Reivindicación 1, que además
comprende la operación de:
- \quad
- recibir en el Nodo Móvil Anuncios de Enrutador Periódicos.
7. El método de la Reivindicación 1, donde:
- \quad
- autentificar el primer Anuncio de Enrutador comprende además la operación de, en respuesta a la recepción en el Nodo Móvil del primer Anuncio de Enrutador, enviar desde el Nodo Móvil en dirección al Enrutador de Acceso una Solicitud que comprende el Índice Nonce.
8. El método de la Reivindicación 7, donde:
- \quad
- la Solicitud está firmada con una Clave Privada del Nodo Móvil.
9. El método de la Reivindicación 1, donde:
- \quad
- el primer Anuncio de Enrutador es enviado en paralelo a una Respuesta de Asociación enviada por el Punto de Acceso.
10. El método de la Reivindicación 9, donde:
- \quad
- la Respuesta de Asociación es enviada en respuesta a una Solicitud de Asociación enviada por el Nodo Móvil en dirección al Punto de Acceso.
11. El método de la Reivindicación 1, que además
comprende la operación de:
- \quad
- después de la operación de mantener en el Nodo Móvil la primera dirección IP, iniciar en el Nodo Móvil un Intercambio de Paquetes de Datos.
12. El método de la Reivindicación 1, donde:
- \quad
- configurar en el Nodo Móvil la primera dirección IP mediante el uso del primer Prefijo de Red comprende un procedimiento de Detección de Dirección Duplicada.
13. Un Nodo Móvil (110), que comprende:
- \quad
- un Receptor para recibir un primer y un segundo Anuncios de Enrutador;
- \quad
- una Memoria Temporal para almacenar un Prefijo de Red, un Índice Nonce y un Valor Nonce Hasheado recibido en el primer Anuncio de Enrutador, para almacenar un Valor Nonce correspondiente al Índice Nonce recibido en el segundo Anuncio de Enrutador, y para almacenar una primera dirección IP,
- \quad
- un Procesador para configurar la primera dirección IP basándose en el Prefijo de Red, comenzando la configuración concurrentemente con una autentificación del primer Anuncio de Enrutador, y para hashear el Valor Nonce; y
- \quad
- una Lógica de Decisión para autentificar el primer Anuncio de Enrutador comparando un Resultado del hasheado con el Valor Nonce Hasheado y para decidir mantener la primera dirección IP basándose en un resultado de la comparación.
14. El Nodo Móvil de la Reivindicación 13,
donde:
- \quad
- la Lógica de Decisión sirve además para liberar la primera dirección IP si el resultado de la comparación es negativo;
- \quad
- el Procesador sirve además para configurar una segunda dirección IP basándose en el segundo Anuncio de Enrutador si la Lógica de Decisión libera la primera dirección IP; y
- \quad
- la Memoria Temporal sirve para además sobrescribir la primera dirección IP con la segunda dirección IP.
15. El Nodo Móvil de la Reivindicación 13,
donde:
- \quad
- la Memoria Temporal sirve además para almacenar una Clave Pública de un Enrutador de Acceso recibida en uno de los primer o segundo Anuncios de Enrutador;
- \quad
- el Procesador sirve además para verificar una firma del segundo Anuncio de Enrutador mediante el uso de la Clave Pública del Enrutador de Acceso; y
- \quad
- la Lógica de Decisión sirve además para decidir mantener la primera decisión IP basándose en el resultado de la verificación.
16. El Nodo Móvil de la Reivindicación 15,
donde:
- \quad
- la Lógica de Decisión sirve además para liberar la primera dirección IP si el resultado de la verificación es negativo; y
- \quad
- el Nodo Móvil comprende además un Transmisor para enviar una Solicitud cuando la Lógica de Decisión determina que el resultado de la verificación es negativo.
17. El Nodo Móvil de la Reivindicación 13, que
además comprende:
- \quad
- una Memoria Permanente para almacenar una Clave Privada del Nodo Móvil.
18. El Nodo Móvil de la Reivindicación 17,
donde:
- \quad
- el Procesador sirve además para firmar la Solicitud con la Clave Privada del Nodo Móvil.
\newpage
19. El Nodo Móvil de la Reivindicación 13, que
además comprende:
- \quad
- un Transmisor para enviar una Solicitud que comprende el Índice Nonce.
20. El Nodo Móvil de la Reivindicación 19, que
además comprende:
- \quad
- un Manipulador de Paquetes de datos para manipular el envío y recepción de paquetes de datos cuando la Lógica de Decisión decide mantener la primera dirección IP.
21. El Nodo Móvil de la Reivindicación 20,
donde:
- \quad
- el Transmisor sirve además para enviar paquetes de datos; y
- \quad
- el Receptor sirve además para recibir paquetes de datos.
22. El Nodo Móvil de la Reivindicación 13,
donde:
- \quad
- el Procesador sirve además para utilizar un procedimiento de Detección de Dirección Duplicada como parte de la configuración de la primera dirección IP.
23. El Nodo Móvil de la Reivindicación 13,
donde:
- \quad
- el Receptor sirve además para recibir Anuncios de Enrutador Monodifusión y Anuncios de Enrutador Periódicos; y
- \quad
- el segundo Anuncio de Enrutador es un Anuncio de Enrutador Monodifusión.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US70797805P | 2005-08-15 | 2005-08-15 | |
| US707978P | 2005-08-15 | ||
| US11/494,547 US8230221B2 (en) | 2005-08-15 | 2006-07-28 | Routing advertisement authentication in fast router discovery |
| US494547 | 2006-07-28 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2318785T3 true ES2318785T3 (es) | 2009-05-01 |
Family
ID=37742431
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES06780273T Active ES2318785T3 (es) | 2005-08-15 | 2006-08-01 | Autenticacion de anuncio de ruta en un descubrimiento de enrutador rapido (frd). |
Country Status (9)
| Country | Link |
|---|---|
| US (1) | US8230221B2 (es) |
| EP (1) | EP1929742B1 (es) |
| AT (1) | ATE418835T1 (es) |
| BR (1) | BRPI0614316A2 (es) |
| CA (1) | CA2618664C (es) |
| DE (1) | DE602006004470D1 (es) |
| ES (1) | ES2318785T3 (es) |
| HK (1) | HK1120178A1 (es) |
| WO (1) | WO2007020548A2 (es) |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100656378B1 (ko) * | 2005-10-15 | 2006-12-11 | 한국전자통신연구원 | 단대단（Ｐｏｉｎｔ－ｔｏ－Ｐｏｉｎｔ）성격의 광대역무선 접속망에서의 ｌＰｖ６ 이웃 탐색 지원 방법 및시스템 |
| US8478300B2 (en) * | 2005-12-20 | 2013-07-02 | Microsoft Corporation | Proximity service discovery in wireless networks |
| US8559350B2 (en) * | 2005-12-20 | 2013-10-15 | Microsoft Corporation | Mechanism to convey discovery information in a wireless network |
| US7613426B2 (en) * | 2005-12-20 | 2009-11-03 | Microsoft Corporation | Proximity service discovery in wireless networks |
| US10681151B2 (en) | 2006-05-15 | 2020-06-09 | Microsoft Technology Licensing, Llc | Notification framework for wireless networks |
| US9497028B1 (en) * | 2007-05-03 | 2016-11-15 | Google Inc. | System and method for remote storage auditing |
| KR100917392B1 (ko) | 2007-10-26 | 2009-09-17 | 경희대학교 산학협력단 | ＩＰｖ6 네트워크에서 인접 노드의 탐색 메시지를송수신하는 방법 |
| US9105031B2 (en) | 2008-02-22 | 2015-08-11 | Microsoft Technology Licensing, Llc | Authentication mechanisms for wireless networks |
| US20090327465A1 (en) * | 2008-06-27 | 2009-12-31 | Microsoft Corporation | Distributed Configuration Orchestration for Network Client Management |
| CN102804829A (zh) * | 2009-06-24 | 2012-11-28 | 诺基亚公司 | 用于避免欺骗接入点的拒绝服务攻击的方法和装置 |
| US8838706B2 (en) | 2010-06-24 | 2014-09-16 | Microsoft Corporation | WiFi proximity messaging |
| US8953798B2 (en) * | 2010-10-29 | 2015-02-10 | Telefonaktiebolaget L M Ericsson (Publ) | Enhanced cryptographically generated addresses for secure route optimization in mobile internet protocol |
| WO2012092261A2 (en) * | 2010-12-29 | 2012-07-05 | Citrix Systems, Inc. | Systems and methods for multi-level tagging of encrypted items for additional security and efficient encrypted item determination |
| KR20150106122A (ko) * | 2014-03-11 | 2015-09-21 | 한국전자통신연구원 | ＩＰｖ6 주소 설정 방법 |
| US20150278873A1 (en) * | 2014-03-25 | 2015-10-01 | Richard S. Sylvester | Local advertisement via mobile device |
| CN108134739B (zh) * | 2016-12-01 | 2020-10-02 | 深圳市中兴微电子技术有限公司 | 一种基于索引特里树的路由查找方法及装置 |
| US10484932B2 (en) * | 2017-06-17 | 2019-11-19 | Link Labs, Inc. | BLE networking systems and methods providing central and peripheral role reversal with enhanced peripheral location determination using ultrasonic waveform |
| US10499196B2 (en) * | 2017-06-17 | 2019-12-03 | Link Labs, Inc. | BLE networking systems and methods providing central and peripheral role reversal with enhanced peripheral location determination |
| US10506498B1 (en) | 2018-11-01 | 2019-12-10 | Link Labs, Inc. | BLE networking systems and methods providing central and peripheral role reversal with enhanced peripheral location determination using ultrasonic waveform and correlation therefor |
| US10708970B2 (en) | 2017-06-17 | 2020-07-07 | Link Labs, Inc. | BLE networking systems and methods providing central and peripheral role reversal with enhanced peripheral location determination using constant tone extension analysis for a same channel |
| US11778540B1 (en) | 2022-10-12 | 2023-10-03 | Link Labs, Inc. | BLE networking systems and methods including filtering for selectively collecting and processing advertisement data |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5838790A (en) * | 1996-04-19 | 1998-11-17 | Juno Online Services, L.P. | Advertisement authentication system in which advertisements are downloaded for off-line display |
| US7089240B2 (en) * | 2000-04-06 | 2006-08-08 | International Business Machines Corporation | Longest prefix match lookup using hash function |
| US6920559B1 (en) * | 2000-04-28 | 2005-07-19 | 3Com Corporation | Using a key lease in a secondary authentication protocol after a primary authentication protocol has been performed |
| JP3898498B2 (ja) * | 2001-12-06 | 2007-03-28 | 富士通株式会社 | サーバ負荷分散システム |
| US20040240669A1 (en) * | 2002-02-19 | 2004-12-02 | James Kempf | Securing neighbor discovery using address based keys |
| US7145911B2 (en) * | 2002-03-05 | 2006-12-05 | Hewlett-Packard Company | Method and system for parallel hash transformation for an address input |
| US7126948B2 (en) * | 2002-03-21 | 2006-10-24 | Hewlett-Packard Development Company, L.P. | Method and system for performing a hash transformation to generate a hash pointer for an address input by using rotation |
| US7461251B2 (en) * | 2002-05-09 | 2008-12-02 | Canon Kabushiki Kaisha | Public key certification issuing apparatus |
| US7383577B2 (en) * | 2002-05-20 | 2008-06-03 | Airdefense, Inc. | Method and system for encrypted network management and intrusion detection |
| US7350077B2 (en) * | 2002-11-26 | 2008-03-25 | Cisco Technology, Inc. | 802.11 using a compressed reassociation exchange to facilitate fast handoff |
| US7656840B2 (en) * | 2003-02-26 | 2010-02-02 | Nokia Corporation | Method of reducing denial-of-service attacks and a system as well as an access router therefor |
| US7743408B2 (en) * | 2003-05-30 | 2010-06-22 | Microsoft Corporation | Secure association and management frame verification |
| US7533184B2 (en) * | 2003-06-13 | 2009-05-12 | Microsoft Corporation | Peer-to-peer name resolution wire protocol and message format data structure for use therein |
| US7401217B2 (en) * | 2003-08-12 | 2008-07-15 | Mitsubishi Electric Research Laboratories, Inc. | Secure routing protocol for an ad hoc network using one-way/one-time hash functions |
| US8341700B2 (en) * | 2003-10-13 | 2012-12-25 | Nokia Corporation | Authentication in heterogeneous IP networks |
| JP4475514B2 (ja) * | 2004-09-02 | 2010-06-09 | Ｋｄｄｉ株式会社 | ＩＰｖ６／ＩＰｖ４トンネリング方法 |
| US7706776B2 (en) * | 2004-12-06 | 2010-04-27 | Meshnetworks, Inc. | Scheme for MAC address privacy in infrastructure-based multi-hop wireless networks |
| KR100755536B1 (ko) * | 2005-12-15 | 2007-09-06 | 주식회사 팬택앤큐리텔 | 복제단말기에 대한 ｉｐ 할당 방지시스템 |
| US7532587B2 (en) * | 2006-09-06 | 2009-05-12 | Motorola, Inc. | Method and apparatus for performing anonymous source routing |
-
2006
- 2006-07-28 US US11/494,547 patent/US8230221B2/en active Active
- 2006-08-01 DE DE602006004470T patent/DE602006004470D1/de active Active
- 2006-08-01 ES ES06780273T patent/ES2318785T3/es active Active
- 2006-08-01 EP EP06780273A patent/EP1929742B1/en not_active Not-in-force
- 2006-08-01 BR BRPI0614316-4A patent/BRPI0614316A2/pt not_active Application Discontinuation
- 2006-08-01 CA CA2618664A patent/CA2618664C/en active Active
- 2006-08-01 AT AT06780273T patent/ATE418835T1/de not_active IP Right Cessation
- 2006-08-01 WO PCT/IB2006/052636 patent/WO2007020548A2/en active Application Filing
-
2008
- 2008-10-30 HK HK08111970.3A patent/HK1120178A1/xx not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| HK1120178A1 (en) | 2009-03-20 |
| CA2618664A1 (en) | 2007-02-22 |
| BRPI0614316A2 (pt) | 2012-11-27 |
| ATE418835T1 (de) | 2009-01-15 |
| WO2007020548A3 (en) | 2007-05-31 |
| WO2007020548A2 (en) | 2007-02-22 |
| DE602006004470D1 (en) | 2009-02-05 |
| EP1929742A2 (en) | 2008-06-11 |
| EP1929742B1 (en) | 2008-12-24 |
| US20070036119A1 (en) | 2007-02-15 |
| CA2618664C (en) | 2014-04-22 |
| US8230221B2 (en) | 2012-07-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2318785T3 (es) | Autenticacion de anuncio de ruta en un descubrimiento de enrutador rapido (frd). | |
| US7286671B2 (en) | Secure network access method | |
| Johnson et al. | Mobility support in IPv6 | |
| US8498414B2 (en) | Secure route optimization in mobile internet protocol using trusted domain name servers | |
| EP2589197B1 (en) | Method and devices for a light-weight security solution for host-based mobility and multihoming protocols | |
| BRPI0410612B1 (pt) | método de remeter pacotes de protocolo de internet, roteador de acesso para uso em uma rede de acesso comutada por pacote, e, nó móvel para uso no método | |
| US8953798B2 (en) | Enhanced cryptographically generated addresses for secure route optimization in mobile internet protocol | |
| JP2010527549A (ja) | ネットワーク・ベースおよびホスト・ベース混合型のモビリティ管理における方法 | |
| JP2009516435A (ja) | 複数鍵暗号化生成アドレスを使ったモバイルネットワークのためのセキュアな経路最適化 | |
| JP2010507301A (ja) | ネットワーク・ベース及びホスト・ベースの混合モビリティ管理における方法 | |
| US8711843B2 (en) | Cryptographically generated addresses using backward key chain for secure route optimization in mobile internet protocol | |
| JP3822555B2 (ja) | 安全なネットワークアクセス方法 | |
| EP2151114A2 (en) | Method and apparatus for combining internet protocol authentication and mobility signaling | |
| US20140004830A1 (en) | System and Method for Femto ID verification | |
| Aura et al. | Security of Internet location management | |
| Wang et al. | Secure address auto-configuration for mobile ad hoc networks | |
| Kempf et al. | Mobile IPv6 security | |
| Qiu et al. | A pmipv6-based secured mobility scheme for 6lowpan | |
| Zhang et al. | TRDP: a trusted router discovery protocol | |
| JP4960359B2 (ja) | 高速ルータ探索におけるルーティングアドバタイズメント認証 | |
| Oryema et al. | Secure mobility management using CoAP in the Internet of Things | |
| Hassan et al. | One-time key and diameter message authentication protocol for proxy mobile IPv6 | |
| Durr et al. | An analysis of security threats to mobile IPv6 | |
| Georgiades et al. | Distributed authentication protocol for the security of binding updates in mobile IPv6 | |
| Nordmark | Secure Neighborhood Discovery P. Nikander (editor) Working Group Ericsson Research Nomadic Lab Internet-Draft J. Kempf Expires: July 24, 2003 DoCoMo USA Labs |