ES2877067T3 - Configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet - Google Patents

Configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet Download PDF

Info

Publication number
ES2877067T3
ES2877067T3 ES20159748T ES20159748T ES2877067T3 ES 2877067 T3 ES2877067 T3 ES 2877067T3 ES 20159748 T ES20159748 T ES 20159748T ES 20159748 T ES20159748 T ES 20159748T ES 2877067 T3 ES2877067 T3 ES 2877067T3
Authority
ES
Spain
Prior art keywords
check
key exchange
user equipment
vivacity
internet key
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
Application number
ES20159748T
Other languages
English (en)
Inventor
Ivo Sedlacek
Rickard Eriksson
Ralf Keller
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Application granted granted Critical
Publication of ES2877067T3 publication Critical patent/ES2877067T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/143—Termination or inactivation of sessions, e.g. event-controlled end of session
    • H04L67/145—Termination or inactivation of sessions, e.g. event-controlled end of session avoiding end of session, e.g. keep-alive, heartbeats, resumption message or wake-up for inactive or interrupted session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • 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]
    • 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/041—Key generation or derivation
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/1896—ARQ related signaling
    • 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
    • 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/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent
    • 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)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un método para la configuración y realización de una comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, siendo realizado el método por un equipo de usuario (11), comprendiendo el método: transmitir (S102), desde el equipo de usuario sobre una interfaz aérea a un nodo (12) de red central, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad, en donde el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad es un período de tiempo de espera para el atributo de comprobación de vivacidad con el campo de longitud ajustado a cero, recibir (S104), en el equipo de usuario sobre la interfaz aérea desde el nodo de red central, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad, realizar (S106) dicha comprobación de vivacidad de acuerdo con el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad, que comprende: transmitir (S108) una solicitud informativa sin carga útil si un período de tiempo de espera para el atributo de comprobación de vivacidad está incluido en el atributo de configuración recibido que indica un período de tiempo de espera para dicha comprobación de vivacidad, y en ausencia de la recepción de un paquete de seguridad de protocolo de internet protegido criptográficamente, IPSec, o un paquete de intercambio criptográfico de claves de internet durante el período de tiempo de espera para dicha comprobación de vivacidad, y en donde, en ausencia de la recepción de una respuesta informativa en respuesta a la solicitud informativa transmitida sin carga útil, se lleva a cabo uno o más de: determinar (S110) un fallo de la asociación de seguridad de intercambio de claves de internet; descartar (S112) cualquier información de estado asociada con la asociación de seguridad de intercambio de claves de internet; y/o descartar (S114) cualesquiera asociaciones de seguridad de seguridad de protocolo de internet, IPSec, negociadas utilizando la asociación de seguridad de intercambio de claves de internet

Description

DESCRIPCIÓN
Configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet
Campo técnico
Las realizaciones presentadas en este documento se refieren a la comprobación de vivacidad, y en particular a métodos, a un equipo de usuario, a un nodo de red central, a programas informáticos y a un producto de programa informáti
Antecedentes
En las redes de comunicaciones, puede resultar difícil obtener un buen rendimiento y una buena capacidad para un determinado protocolo de comunicaciones, sus parámetros y el entorno físico en el que se despliega la red de comunicaciones.
Por ejemplo, un parámetro para proporcionar un buen rendimiento y una buena capacidad para un protocolo de comunicaciones determinado en una red de comunicaciones es la capacidad de proporcionar una comprobación de vivacidad eficiente y fiable, también llamada detección de pares muertos, por ejemplo, en redes de acceso no 3GPP y no fiables, donde 3GPP es abreviatura de Programa de Asociación de 3a Generación (en inglés, Third Generation Partnership Program).
La comprobación de vivacidad permite garantizar que ambos extremos de una asociación de seguridad de intercambio de claves de internet (tal como el intercambio de claves de internet v1, IKEvl o el intercambio de claves de internet v2, IKEv2) están activos.
En términos generales, una comprobación de vivacidad puede implicar que un extremo de la asociación de seguridad de intercambio de claves de internet envíe un mensaje de solicitud informativa sin cargas útiles (que no sean la carga útil cifrada vacía requerida por la sintaxis), al que el otro extremo de la asociación de seguridad de intercambio de claves de internet responde con un mensaje de respuesta informativa. El protocolo de acuerdo con la RFC (Solicitud de comentarios) 5996 del IETF (Grupo de trabajo de ingeniería de internet) espera que el mensaje de solicitud informativa se envíe periódicamente, si el punto final no ha recibido ningún paquete de seguridad de protocolo de internet protegido criptográficamente (IPSec) o de intercambio de claves de internet como parte de la asociación de seguridad de intercambio de claves de internet durante un tiempo de espera determinado.
Cuando se utiliza intercambio de claves de internet en una red de acceso no fiable, un equipo de usuario y una pasarela de datos por paquetes evolucionada (ePDG) actúan como puntos finales de la asociación de seguridad de intercambio de claves de internet.
La ePDG puede enviar el mensaje de solicitud informativa para monitorizar la vivacidad del equipo de usuario, pero esto requiere temporizadores en la ePDG.
El equipo de usuario puede enviar el mensaje de solicitud informativa para monitorizar la vivacidad de la ePDG, pero el operador no tiene control de cuál es el tiempo de espera. Por lo tanto, existe una posibilidad limitada de que la red controle el uso real de la comprobación de vivacidad desde el equipo de usuario. El borrador 3GPP "Access to the 3GPP Evolved Packet Core via non-3GPP access networks" (3GPPTS 24.302 V12.7.0) publicado el 19 de diciembre de 2014 (19/12/2014), XP050906830, da a conocer que una ePDG establece un tiempo de mantenimiento en activo del túnel transversal del cortafuegos (FTT KAT) utilizando mensajes IKE CFG_REQu EsT/CFG_REPLY.
El documento ETF RFC 3706 de Huang G et al .: "A Traffic-Based Method of Detecting Dead Internet KeyExchange (IKE) Peers", publicado en febrero de 2004, XP015009486, da a conocer que los intervalos para mantenimientos en activo/pulsos de funcionamiento tienen que negociarse por razones de escalabilidad.
Por tanto, existe la necesidad de una comprobación de vivacidad mejorada de un equipo de usuario.
Resumen
La invención se define mediante las reivindicaciones adjuntas. Un objetivo de las realizaciones del presente documento es dar a conocer una comprobación de vivacidad eficiente de un equipo de usuario.
Según un primer aspecto, se presenta un método para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet. El método es llevado a cabo por un equipo de usuario, por ejemplo un UE. El método comprende transmitir, a un nodo de red central, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. El método comprende recibir, desde el nodo de red central, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad. De manera ventajosa, esto proporciona una comprobación de vivacidad eficiente en el equipo de usuario. De manera ventajosa, esto permite el control dinámico del uso del equipo de usuario de la comprobación de vivacidad desde el nodo de red central.
Ventajosamente, esto permite controlar el período de tiempo de espera utilizado por el equipo de usuario que realiza su parte de la comprobación de vivacidad.
De acuerdo con un segundo aspecto, se presenta un equipo de usuario para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet. El equipo de usuario comprende una unidad de procesamiento. La unidad de procesamiento está configurada para hacer que el equipo de usuario transmita, a un nodo de red central, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. La unidad de procesamiento está configurada para hacer que el equipo de usuario reciba, desde el nodo de red central, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
Según un tercer aspecto, se presenta un programa informáti
vivacidad utilizando mensajes de intercambio de claves de internet, comprendiendo el programa informático un código de programa informático que, cuando se ejecuta en una unidad de procesamiento de un equipo de usuario, hace que el equipo de usuario realice un método según el primer aspecto.
Según un cuarto aspecto, se presenta un método para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet. El método es llevado a cabo por un nodo de red central. El método comprende recibir, desde un equipo de usuario, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. El método comprende transmitir, al equipo de usuario, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
De acuerdo con un quinto aspecto, se presenta un nodo de red central para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet. El nodo de red central comprende una unidad de procesamiento. La unidad de procesamiento está configurada para hacer que el nodo de red central reciba, desde un equipo de usuario, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. La unidad de procesamiento está configurada para hacer que el nodo de red central transmita, al equipo de usuario, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
Según una realización, el nodo de red central es una pasarela de datos por paquetes evolucionada (ePDG).
De acuerdo con un sexto aspecto, se presenta un programa informáti
vivacidad utilizando mensajes de intercambio de claves de internet, comprendiendo el programa informático un código de programa informático que, cuando se ejecuta en una unidad de procesamiento de un nodo de red central, hace que el nodo de red central lleve a cabo un método según el cuarto aspecto.
Según un séptimo aspecto, se presenta un producto de programa informático que comprende un programa informático según al menos uno del tercer aspecto y el sexto aspecto y un medio legible por ordenador en el que se almacena el programa informático.
Cabe señalar que cualquier característica de los aspectos primero, segundo, tercero, cuarto, quinto, sexto y séptimo puede aplicarse a cualquier otro aspecto, siempre que sea apropiado. Asimismo, cualquier ventaja del primer aspecto puede aplicarse igualmente al segundo, tercer, cuarto, quinto, sexto y/o séptimo aspecto, respectivamente, y viceversa. Otros objetivos, características y ventajas de las realizaciones adjuntas resultarán evidentes a partir de la siguiente descripción detallada, de las reivindicaciones dependientes adjuntas así como de los dibujos.
En general, todos los términos usados en las reivindicaciones deben interpretarse de acuerdo con su significado ordinario en el campo técnico, a menos que se defina explícitamente lo contrario en el presente documento. Todas las referencias a "un//el/la elemento, aparato, componente, medio, etapa, etc." deben interpretarse abiertamente como una referencia a, por lo menos, una instancia del elemento, aparato, componente, medio, etapa, etc., a menos que se indique explícitamente lo contrario. Las etapas de cualquier método dado a conocer en este documento no tienen que realizarse en el orden exacto dado a conocer, a menos que se indique explícitamente.
Breve descripción de los dibujos
El concepto inventivo se describe a continuación, a modo de ejemplo, haciendo referencia a los dibujos adjuntos, en los que:
La figura 1 es un diagrama esquemático que ilustra una red de comunicaciones según realizaciones.
La figura 2a es un diagrama esquemático que muestra unidades funcionales de un equipo de usuario, UE, según una realización.
La figura 2b es un diagrama esquemático que muestra módulos funcionales de un equipo de usuario según una realización.
La figura 3a es un diagrama esquemático que muestra unidades funcionales de un nodo de red central según una realización.
La figura 3b es un diagrama esquemático que muestra módulos funcionales de un nodo de red central según una realización.
La figura 4 muestra un ejemplo de un producto de programa informático que comprende medios legibles por ordenador según una realización;
las figuras 5, 6, 7 y 8 son diagramas de flujo de métodos según realizaciones; y
La figura 9 es un diagrama de señalización según realizaciones; y
La figura 10 es una ilustración esquemática de un período de tiempo de espera para el atributo de comprobación de vivacidad según una realización.
Descripción detallada
El concepto inventivo se describirá a continuación con más detalle haciendo referencia a los dibujos adjuntos, en los que se muestran ciertas realizaciones del concepto inventivo. Sin embargo, este concepto inventivo puede realizarse de muchas formas diferentes y no debe interpretarse que está limitado a las realizaciones expuestas en el presente documento; más bien, estas realizaciones se proporcionan a modo de ejemplo de modo que esta divulgación sea minuciosa y completa, y transmita completamente el alcance del concepto inventivo a los expertos en la técnica. Los números similares se refieren a elementos similares a lo largo de la descripción. Cualquier etapa o característica ilustrada con líneas discontinuas debe considerarse opcional.
La figura 1 muestra una descripción esquemática de una red de comunicaciones inalámbricas 10 a modo de ejemplo, donde se pueden aplicar las realizaciones presentadas en este documento. La red de comunicaciones inalámbricas 10 de la figura 1 está basada en evolución a largo plazo(LTE, Long Term Evolution). Cabe señalar que los términos "LTE" y "basado en LTE" se utilizan aquí de manera que abarcan redes basadas en LTE presentes y futuras, tales como, por ejemplo, redes LTE avanzadas. Debe apreciarse que, aunque la figura 1 muestra una red de comunicaciones basada en LTE, las realizaciones de ejemplo en este documento también se pueden utilizar en conexión con otras redes de comunicaciones inalámbricas, tales como, por ejemplo, el Sistema Global de Comunicaciones (GSM) o el Sistema Universal de Telecomunicaciones Móviles ( UMTS), que comprenden nodos y funciones que corresponden a los nodos y funciones de la red en la figura 1.
La red de comunicaciones inalámbricas comprende una o más estaciones base en forma de eNodoB, operativamente conectadas a una pasarela de servicio (SGW), a su vez operativamente conectada a una entidad de gestión de movilidad (MME) y una pasarela de red de datos de paquetes (PGW) que, a su vez, está operativamente conectada a una función de política y reglas de cobro (PCRF). El eNodoB es un nodo de acceso por radio que interactúa con el equipo de usuario 11. Los eNodoB de la red forman la denominada Red de Acceso de Radio Terrestre Universal Evolucionada (E-UTRAN) para comunicar con el equipo de usuario a través de una interfaz aérea, tal como LTE- Uu. La red central en LTE se conoce como núcleo de paquetes evolucionado (EPC), y el EPC junto con E-UTRAN se conoce como sistema de paquetes evolucionado (EPS). El SGW enruta y reenvía paquetes de datos de usuario a través de la interfaz S1-U, mientras que también actúa como el ancla de movilidad para el plano de usuario durante los traspasos entre los eNodoB y como el ancla para la movilidad entre LTE y otras tecnologías del Proyecto de Asociación de 3a Generación (3GPP) ( terminando la interfaz S4 y retransmitiendo el tráfico entre los sistemas 2G/3G y PGW). Para un equipo de usuario en estado inactivo, la SGW termina el trayecto de datos de enlace descendente y activa una radiobúsqueda cuando llegan datos de enlace descendente para el equipo de usuario, y además gestiona y almacena contextos de equipo de usuario, por ejemplo parámetros del servicio de portadora IP, información de enrutamiento interno de la red. La SGW comunica con la MME a través de la interfaz S11 y con la PGW a través de la interfaz S5. Además, la SGW puede comunicar a través de la interfaz S12 con los NodoB de la Red de acceso de radio terrestre universal (UTRAN) y con transceptores de estación base (BTS) de la Red de acceso de radio GSM EDGE ("Enhanced Data rates for GSM Evolution", "Velocidades de datos mejoradas para evolución de GSM") (GERAN) .
La MME es responsable del procedimiento de rastreo y radiobúsqueda de equipos de usuario en modo inactivo, incluidas las retransmisiones. Está involucrado en el proceso de activación/desactivación de portadoras y también es responsable de elegir la SGW para un equipo de usuario en la conexión inicial y en el momento del traspaso intra-LTE que implica la reubicación del nodo de red central. Es responsable de autenticar al usuario interactuando con el servidor de abonado local (HSS). La señalización del estrato de no acceso (NAS) termina en la MME y también es responsable de la generación y asignación de identidades temporales al equipo de usuario a través de la interfaz S1MME. Comprueba la autorización del equipo de usuario para acampar en la Red Móvil Terrestre Pública (PLMN) del proveedor de servicios y hace cumplir las restricciones de itinerancia del equipo de usuario. La MME es el punto de terminación en la red para la protección de cifrado/integridad para la señalización NAS y se encarga de la gestión de claves de seguridad. La MME también proporciona la función de plano de control para la movilidad entre redes de acceso LTE y 2G/3G, con la interfaz S3 terminando en la MME desde el Nodo de soporte del Servicio de radio por paquetes general de servicio (GPRS) (SGSN). La MME también termina la interfaz S6a hacia e1HSS doméstico para el equipo de usuario en itinerancia. Además, hay una interfaz S10 configurada para la comunicación entre las MME para reubicación de MME y la transferencia de información de MME a MME.
La PGW proporciona al equipo de usuario conectividad a redes externas de paquetes de datos (PDN) al ser el punto de salida y entrada del tráfico para el equipo de usuario. Un equipo de usuario puede tener conectividad simultánea con más de una PGW para acceder a múltiples PDN. La PGW realiza aplicación de políticas, filtrado de paquetes para cada usuario, soporte de cobros, interceptación legal y detección de paquetes. Otro papel de la PGW es actuar como ancla para movilidad entre tecnologías 3g PP y no 3GPP, tales como WiMAX y 3GPP2 (CDMA 1X y EvDO). La interfaz entre la PGW y la red de datos de paquete, que es, por ejemplo, internet, se denomina SGi. La red de datos de paquete puede ser una red de datos de paquete privada o pública externa del operador, o una red de datos de paquete interna del operador, por ejemplo para la prestación de servicios de subsistema multimedia IP (IMS).
La PCRF determina reglas de política en tiempo real con respecto al equipo de usuario de la red. Esto puede, por ejemplo, incluir la agregación de información en tiempo real, hacia y desde la red central y los sistemas de soporte operativo, etc. de la red para dar soporte a la creación de reglas y/o adoptar automáticamente decisiones de políticas para los equipos de usuario actualmente activos en la red en base a dichas reglas o similares. La PCRF proporciona a la PGW dichas reglas y/o políticas o similares para ser utilizadas por la PGW activa como una función de aplicación de políticas y cargos (PCEF) a través de la interfaz Gx. La PCRF comunica además con la red de datos de paquete a través de la interfaz Rx.
Una función principal de la pasarela de datos por paquetes evolucionada (ePDG) 12 es asegurar la transmisión de datos con un equipo de usuario conectado al EPC a través de un acceso no fiable no 3GPP. Para ello, la ePDG actúa como nodo de terminación de los túneles IPsec establecidos con el equipo de usuario.
El servidor AAA 3GPP se encuentra dentro de la Red Móvil Terrestre Pública Local 3GPP (HPLMN). Este realiza funciones de autenticación, autorización y contabilidad (AAA) y también puede actuar como un servidor intermediario AAA. Para WLAN 3GPP IP Access, proporciona información de autorización, aplicación de políticas y enrutamiento a la PDG, la pasarela de acceso WLAN y la red de acceso WLAN.
Tal como se señaló anteriormente, el equipo de usuario puede enviar el mensaje de solicitud informativa para monitorizar la vivacidad de la ePDG, pero el operador no tiene control de cuál es el tiempo de espera. Por lo tanto, existe una posibilidad limitada de que la red controle el uso real de la comprobación de vivacidad desde el equipo de usuario.
Puede ser útil habilitar un nodo en la red para configurar el equipo de usuario con respecto a cómo enviar mensajes de solicitud informativa con un tiempo de espera especificado por la red. Esto permitiría a la red controlar y adaptar dinámicamente el uso de la comprobación de vivacidad, por ejemplo, para evitar una carga de tráfico innecesaria en la red.
Además, puede ser útil requerir que el equipo de usuario envíe una solicitud informativa incluso si el equipo de usuario recibe un paquete IPSec/IKEv2 protegido criptográficamente pero no envía ningún paquete IPSec/IKEv2 protegido criptográficamente como parte de la asociación de seguridad IKEv2 para el tiempo de espera dado. Esto eliminaría el requisito de ejecutar los temporizadores para la comprobación de vivacidad en un nodo de red central, tal como una ePDG, dependiendo en cambio de que el equipo de usuario envíe un paquete IPSec/IKEv2 protegido criptográficamente dentro del tiempo de espera dado (ya sea un paquete IKEv2/IPSec o la solicitud informativa). Tal como se señaló anteriormente, la ePDG puede enviar el mensaje de solicitud informativa para monitorizar la vivacidad del equipo de usuario, pero esto requiere temporizadores en la ePDG.
Existen problemas similares en IKEv1, donde el protocolo de detección de pares muertos de acuerdo con la RFC (Solicitud de comentarios) 3706 del IETF (Grupo de trabajo de ingeniería de internet) se utiliza para detectar la comprobación de vivacidad del par. En lugar de enviar un mensaje de solicitud informativa IKEv2, se puede enviar un mensaje R-U-THERE definido por RFC3706. En lugar de enviar un mensaje de respuesta informativa IKEv2, se puede enviar un mensaje R-U-THERE-ACK definido por RFC3706.
Las realizaciones dadas a conocer en el presente documento se refieren, por tanto, a la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet. Con el fin de obtener dicha comprobación de vivacidad, se da a conocer un equipo de usuario, un método realizado por el equipo de usuario, un programa informático que comprende código, por ejemplo en forma de un producto de programa informático, que cuando se ejecuta en una unidad de procesamiento del equipo de usuario, hace que el equipo de usuario realice el método. Con el fin de obtener dicha comprobación de vivacidad, se proporciona además un nodo de red central, tal como una ePDG, un método llevado a cabo por el nodo de red central, y un programa informático que comprende código, por ejemplo en forma de un producto de programa informático, que cuando se ejecuta en una unidad de procesamiento del nodo de red central, hace que el nodo de red central lleve a cabo el método.
La figura 2a ilustra esquemáticamente, en términos de varias unidades funcionales, los componentes de un equipo de usuario 11 según una realización. Se dispone una unidad de procesamiento 21 usando cualquier combinación de una o más de una unidad central de procesamiento (CPU) adecuada, un multiprocesador, un microcontrolador, un procesador de señal digital (DSP), un circuito integrado de aplicación específica (ASIC), matrices de puertas programables in situ (FPGA), etc., que pueda ejecutar instrucciones de software almacenadas en un producto de programa informático 41a (tal como en la figura 4), por ejemplo en forma de un medio de almacenamiento 23. Por tanto, la unidad de procesamiento 21 está dispuesta de este modo para ejecutar métodos como los descritos en el presente documento. El medio de almacenamiento 23 también puede comprender almacenamiento persistente, que, por ejemplo, puede ser uno cualquiera o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada de forma remota. El equipo de usuario puede comprender además una interfaz de comunicaciones 22 para comunicaciones con nodos, dispositivos, equipo de usuario y entidades lógicas en la red. Como tal, la interfaz de comunicaciones 22 puede comprender uno o más transmisores y receptores, que comprenden componentes analógicos y digitales y un número adecuado de antenas para comunicaciones inalámbricas. La unidad de procesamiento 21 controla el funcionamiento general del equipo de usuario, por ejemplo enviando datos y señales de control a la interfaz de comunicaciones 22 y al medio de almacenamiento 23, recibiendo datos e informes desde la interfaz de comunicaciones 22 y recuperando datos e instrucciones del medio de almacenamiento 23. Otros componentes, así como la funcionalidad relacionada, del equipo de usuario se omiten para no oscurecer los conceptos aquí presentados. En términos generales, el equipo de usuario puede ser un dispositivo inalámbrico, tal como un dispositivo inalámbrico portátil, y puede estar dispuesto como una estación móvil, un teléfono móvil, un auricular, un teléfono de bucle local inalámbrico, un teléfono inteligente, un ordenador portátil, un ordenador de tableta, un módem inalámbrico, un sensor o un dispositivo de internet de las cosas.
La figura 2b ilustra esquemáticamente, en términos de varios módulos funcionales, los componentes de un equipo de usuario 11 según una realización. El equipo de usuario de la figura 2b comprende varios módulos funcionales; un primer módulo de transmisión 21a configurado para realizar la siguiente etapa S102, y un segundo módulo de recepción 21b configurado para realizar la siguiente etapa S104. El equipo de usuario 11 de la figura 2b puede comprender además una serie de módulos funcionales opcionales, tal como cualquiera de un módulo 21c de comprobación de vivacidad configurado para realizar la siguiente etapa S106, un módulo de solicitud de transmisión 21d configurado para realizar la siguiente etapa S108, un módulo de determinación de fallos 21e configurado para realizar la siguiente etapa S110, y un módulo de descarte 21f configurado para realizar las etapas siguientes S112 y S114. La funcionalidad de cada módulo funcional 21a-e se describirá en mayor detalle a continuación en el contexto en que se pueden usar los módulos funcionales 21a-e. En términos generales, cada módulo funcional 21a-e puede implementarse en hardware o en software. Preferiblemente, uno o más, o todos los módulos funcionales 21a-e pueden ser implementados por la unidad de procesamiento 21, posiblemente en cooperación con las unidades funcionales 22 y/o 23. La unidad de procesamiento 21 puede, por tanto, estar dispuesta para, desde el medio de almacenamiento 23, obtener instrucciones proporcionadas por un módulo funcional 21a-e y ejecutar estas instrucciones, realizando de este modo cualesquiera etapas, tal como se describirá a continuación.
La figura 3a ilustra esquemáticamente, en términos de varias unidades funcionales, los componentes de un nodo 12 de red central según una realización. Se dispone una unidad de procesamiento 31 usando cualquier combinación de una o más de una unidad central de procesamiento (CPU) adecuada, un multiprocesador, un microcontrolador, un procesador de señal digital (DSP), un circuito integrado de aplicación específica (ASIC), matrices de puertas programables in situ (FPGA), etc., que pueda ejecutar instrucciones de software almacenadas en un producto de programa informático 41 b (como en la figura 4), por ejemplo en forma de un medio de almacenamiento 33. Por tanto, la unidad de procesamiento 31 está dispuesta de este modo para ejecutar métodos como se los descritos el presente documento. El medio de almacenamiento 33 también puede comprender almacenamiento persistente, que, por ejemplo, puede ser uno cualquiera o una combinación de memoria magnética, memoria óptica, memoria de estado sólido o incluso memoria montada de forma remota. El nodo 12 de red central puede comprender además una interfaz 32 de comunicaciones para comunicaciones con nodos, dispositivos, equipos de usuario y entidades lógicas en la red. Como tal, la interfaz de comunicaciones 32 puede comprender uno o más transmisores y receptores, que comprenden componentes analógicos y digitales y un número adecuado de antenas para comunicaciones inalámbricas y/o puertos para comunicaciones por cable. La unidad de procesamiento 31 controla el funcionamiento general del nodo 12 de red central, por ejemplo enviando datos y señales de control a la interfaz de comunicaciones 32 y al medio de almacenamiento 33, recibiendo datos e informes desde la interfaz de comunicaciones 32 y recuperando datos e instrucciones del medio de almacenamiento 33. Otros componentes, así como la funcionalidad relacionada, del nodo 12 de red central se omiten para no oscurecer los conceptos aquí presentados. Según una realización, el nodo de red central es una pasarela de datos por paquetes evolucionada (ePDG).
La figura 3b ilustra esquemáticamente, en términos de varios módulos funcionales, los componentes de un nodo 12 de red central según una realización. El nodo 12 de red central de la figura 3b comprende varios módulos funcionales; un primer módulo de recepción 31a configurado para realizar la siguiente etapa S202, y un segundo módulo de transmisión 31b configurado para realizar la siguiente etapa S210. El nodo 12 de red central de la figura 3b puede comprender además una serie de módulos funcionales opcionales, tal como cualquiera de un módulo indicador 31c configurado para realizar la siguiente etapa S206, un módulo de recibir valor 31d configurado para realizar la siguiente etapa S208, un módulo de recibir solicitud 31e configurado para realizar la siguiente etapa S212, un módulo de transmitir respuesta 31f configurado para realizar la siguiente etapa S214, y un módulo de determinación 31g configurado para realizar la siguiente etapa S204. La funcionalidad de cada módulo funcional 31 a-g se describirá en mayor detalle a continuación en el contexto en el que se pueden usar los módulos funcionales 31a-g. En términos generales, cada módulo funcional 31a-g puede implementarse en hardware o en software. Preferiblemente, uno o más o todos los módulos funcionales 31a-g pueden ser implementados por la unidad de procesamiento 31, posiblemente en cooperación con unidades funcionales 32 y/o 33. La unidad de procesamiento 31 puede por tanto estar dispuesta para, desde el medio de almacenamiento 33, obtener instrucciones proporcionadas por un módulo funcional 31a-g y para ejecutar estas instrucciones, realizando de ese modo cualesquiera etapas, tal como se describirá más adelante.
La figura 4 muestra un ejemplo de un producto de programa informático 41a, 41b que comprende medios 43 legibles por ordenador. En estos medios 43 legibles por ordenador, se puede almacenar un programa informático 42a, programa informático 42a que puede hacer que la unidad de procesamiento 21 y dispositivos y entidades acopladas operativamente a la misma, tales como la interfaz de comunicaciones 22 y el medio de almacenamiento 23, ejecuten métodos de acuerdo con las realizaciones descritas en el presente documento. El programa informático 42a y/o el producto de programa informático 41a pueden así proporcionar medios para realizar cualesquiera etapas del equipo de usuario, tal como se describe en este documento. En este medio 43 legible por ordenador, se puede almacenar un programa informático 42b, programa informático 42b que puede hacer que la unidad de procesamiento 31 y entidades y dispositivos acoplados operativamente a la misma, tales como la interfaz 32 de comunicaciones y el medio de almacenamiento 33, ejecuten métodos de acuerdo con realizaciones descritas en el presente documento. El programa informático 42b y/o el producto de programa informático 41b pueden por tanto proporcionar medios para realizar cualesquiera etapas del nodo de red central, tal como se describe en este documento.
En el ejemplo de la figura 4, el producto de programa informático 41a, 41b se ilustra como un disco óptico, tal como un CD (disco compacto) o un DVD (disco versátil digital) o un disco Blu-Ray. El producto de programa informático 41a, 41b también podría incorporarse como una memoria, tal como una memoria de acceso aleatorio (RAM), una memoria de solo lectura (ROM), una memoria de solo lectura programable borrable (EPROM) o una memoria de solo lectura programable borrable eléctricamente. (EEPROM) y, más particularmente, como un medio de almacenamiento no volátil de un dispositivo en una memoria externa, tal como una memoria USB (Universal Serial Bus, bus en serie universal) o una memoria flash, tal como una memoria flash compacta. Así, mientras que el programa informático 42a, 42b se muestra aquí esquemáticamente como una pista en el disco óptico representado, el programa informático 42a, 42b puede almacenarse de cualquier forma que sea adecuada para el producto de programa informático 41 a, 41 b.
Las figuras 5 y 6 son diagramas de flujo que ilustran realizaciones de métodos para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, realizadas el equipo de usuario 11. Las figuras 7 y 8 son diagramas de flujo que ilustran realizaciones de métodos para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, realizados por el nodo 11 de red central. Los métodos se proporcionan ventajosamente como programas informáticos 42a, 42b.
Se hace a continuación referencia a la figura 5, que ilustra un método para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, llevado a cabo por el equipo de usuario 11 según una realización.
El equipo de usuario está configurado para, en una etapa S102, transmitir, a un nodo de red central, un primer mensaje de intercambio de claves de internet. El primer mensaje de intercambio de claves de internet comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad.
Tal como se describirá con más detalle a continuación, se supone que este mensaje lo recibe el nodo de red central, que, a su vez, responde a este mensaje. Por tanto, el equipo de usuario está configurado para, en una etapa S104, recibir, desde el nodo de red central, un segundo mensaje de intercambio de claves de internet. El segundo mensaje de intercambio de claves de internet comprende un atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
A continuación se darán a conocer realizaciones relacionadas con detalles adicionales de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, realizada por el equipo de usuario 11.
Puede haber diferentes formas de proporcionar el primer mensaje de intercambio de claves de internet y el segundo mensaje de intercambio de claves de internet. A continuación, se describirán sucesivamente realizaciones relativas a los mismos. Según una realización, el primer mensaje de intercambio de claves de internet es un mensaje de solicitud IKE_AUTH. Según una realización, el segundo mensaje de intercambio de claves de internet es un mensaje de respuesta IKE_AUTH.
Puede haber diferentes formas de proporcionar el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad y el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. A continuación, se describirán sucesivamente las realizaciones relativas a las mismas. Según una realización, el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad es un período de tiempo de espera para el atributo de comprobación de vivacidad, con el campo de longitud ajustado a cero. Según una realización, el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad se proporciona en una carga útil de configuración CFG_REQUEST. Según una realización, el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad es un período de tiempo de espera para el atributo de comprobación de vivacidad con un campo de período de tiempo de espera. Según una realización, el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad se proporciona en una carga útil de configuración CFG_REPLY. El atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad puede basarse en una política local. Alternativamente, el atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad se basa en información de un sistema de configuración o sistema de gestión. Se proporcionarán más detalles a continuación.
Se hace referencia a continuación a la figura 6 que ilustra métodos para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet realizada por el equipo de usuario 11 según realizaciones adicionales.
El primer mensaje de intercambio de claves de internet puede transmitirse en un mensaje de intercambio de claves de internet versión 2 (IKEv2), y el segundo mensaje de intercambio de claves de internet puede recibirse en un mensaje IKEv2. Más detalladamente, en una realización, si el UE admite la capacidad de estar configurado para la comprobación de vivacidad, el UE incluye un atributo de configuración IKEv2 que indica la capacidad de ser configurado para la comprobación de vivacidad en un mensaje IKEv2 enviado al nodo 12 de red central. En esta realización, si el UE admite la capacidad de ser configurado para la comprobación de vivacidad, y el atributo de configuración IKEv2 indica el período de tiempo de espera para la comprobación de vivacidad en el mensaje IKEv2 recibido, entonces el UE realiza la comprobación de vivacidad de acuerdo con el valor de este atributo de configuración IKEv2. Por tanto, el equipo de usuario puede configurarse para, en una etapa S106, realizar la comprobación de vivacidad según el atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
En una realización, el atributo de configuración IKEv2 comprende además una indicación de si se requiere que el UE envíe una solicitud informativa IKEv2 también cuando el UE recibe un paquete de seguridad de protocolo de internet protegido criptográficamente (IPSec) o IKEv2 durante el tiempo de espera dado, pero no envía ningún paquete protegido criptográficamente IPSec/IKEv2 como parte de la asociación de seguridad IKEv2 para el tiempo de espera dado. El atributo de configuración del segundo mensaje de intercambio de claves de internet puede comprender una indicación de si se requiere que el equipo de usuario transmita una solicitud informativa o no, también si el equipo de usuario recibe al menos uno de un paquete IPSec protegido criptográficamente y un paquete de intercambio criptográfico de claves de internet durante el período de tiempo de espera. La solicitud informativa puede estar incluida en el mensaje de solicitud informativa IKEv2.
La comprobación de vivacidad puede ser parte de una asociación de seguridad de intercambio de claves de internet, y el equipo de usuario no transmite ningún paquete IPSec protegido criptográficamente o paquete de intercambio criptográfico de claves de internet como parte de la asociación de seguridad de intercambio de claves de internet durante dicho período de tiempo de espera. Por lo tanto, el equipo de usuario puede configurarse para, en una etapa S108, transmitir una solicitud informativa sin carga útil si un período de tiempo de espera para el atributo de comprobación de vivacidad está incluido en el atributo de configuración recibido que indica un período de tiempo de espera para dicha comprobación de vivacidad, y en ausencia de recepción de un paquete IPSec protegido criptográficamente o de un paquete de intercambio criptográfico de claves de internet durante el período de tiempo de espera para la comprobación de vivacidad.
En las realizaciones en las que la comprobación de vivacidad es parte de una asociación de seguridad de intercambio de claves de internet, el equipo de usuario está configurado para, en ausencia de la recepción de una respuesta informativa en respuesta a la solicitud informativa transmitida sin carga útil, en una etapa S110, determinar un fallo del asociación de seguridad de intercambio de claves de internet. El equipo de usuario está configurado además para, en una etapa S112, descartar cualquier información de estado asociada con la asociación de seguridad de intercambio de claves de internet; y/o, en una etapa S114, descartar cualesquiera asociaciones de seguridad IPSec negociada usando la asociación de seguridad de intercambio de claves de internet
En una realización, el intercambio de claves de internet versión 1 (IKEvi) se usa junto con el protocolo de detección de pares muertos (RFC3706). Es decir, en lugar de utilizar atributos de configuración IKEv2 como se ha descrito anteriormente, se utilizan nuevos atributos de IKEv1 que llevan la información. Es decir, según una realización, el primer mensaje de intercambio de claves de internet se transmite en un mensaje IKEv1, y el segundo mensaje de intercambio de claves de internet se recibe en un mensaje IKEv1.
Además, en lugar de enviar un mensaje de solicitud informativa IKEv2, se envía un mensaje R-U-THERE definido por RFC3706, y en lugar de enviar un mensaje de respuesta informativa IKEv2, se envía un mensaje R-U-THERE-ACK definido por RFC3706. Es decir, según una realización, el atributo de configuración del segundo mensaje de intercambio de claves de internet comprende una indicación de si se requiere que el equipo de usuario transmita un mensaje ”¿estás ahí?” o no, también si el equipo de usuario recibe al menos uno de un paquete IPSec protegido criptográficamente y un paquete de intercambio criptográfico de claves de internet durante el período de tiempo de espera. El mensaje “¿estás ahí?'' puede estar incluido en un mensaje R-U-THERE definido por RFC3706.
A continuación se hace referencia a la figura 7, que ilustra un método para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet llevada a cabo por el nodo 12 de red central según una realización.
Tal como se señaló anteriormente, el equipo de usuario 11 en la etapa S102 transmite un mensaje a un nodo 12 de red central. Se supone, con el propósito de divulgar el concepto inventivo aquí descrito, que este mensaje es recibido por un nodo 12 de red central. Por tanto, el nodo de red central está configurado para, en una etapa S202, recibir, desde un equipo de usuario 11, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. El nodo 12 de red central responde a este mensaje recibido. Particularmente, el nodo de red central está configurado para, en una etapa S210, transmitir, al equipo de usuario, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
Se darán a conocer a continuación realizaciones relacionadas con detalles adicionales de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet realizada por el nodo 12 de red central.
Se hace a continuación referencia a la figura 8, que ilustra métodos para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet llevada a cabo por el nodo 12 de red central de acuerdo con realizaciones adicionales.
En una realización, si el nodo 12 de red central admite la capacidad de poder configurar el equipo de usuario para la comprobación de vivacidad y un atributo de configuración IKEv2 que indica la capacidad de ser configurado para la comprobación de vivacidad se incluye en el mensaje IKEv2 recibido, entonces el nodo 12 de red central incluye un atributo de configuración IKEv2 que indica el período de tiempo de espera para la comprobación de vivacidad en un mensaje IKEv2 enviado al equipo de usuario.
Puede haber diferentes formas para que el nodo 12 de red central determine el contenido del atributo de configuración que indica un período de tiempo de espera. A continuación se describirán sucesivamente diferentes realizaciones relacionadas con el mismo.
Por ejemplo, el nodo 12 de red central puede determinar el contenido del atributo de configuración que indica un período de tiempo de espera en base a una política local. Por tanto, según una realización, el nodo de red central está configurado para, en una etapa S204, determinar, en base a una política local, un valor del período de tiempo de espera en el atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
Por ejemplo, el nodo 12 de red central puede determinar el contenido del atributo de configuración que indica un período de tiempo de espera en base a información de otra configuración o sistema de gestión.
Por ejemplo, el nodo 12 de red central puede determinar el contenido del atributo de configuración que indica un período de tiempo de espera indicando a una PGW que el nodo de red central admite la capacidad de poder configurar el equipo de usuario para la comprobación de vivacidad y donde la PGW proporciona, por ejemplo a través de GTP o de PMIP, un valor del atributo de configuración al nodo de red central. Por tanto, según una realización, el nodo de red central está configurado para, en una etapa S206, indicar a una pasarela de red de datos de paquetes, PGW, que el nodo de red central admite la recepción de un período de tiempo de espera para dicha comprobación de vivacidad. El nodo de red central puede estar configurado entonces para, en una etapa S208, recibir, de la PGW, un valor del atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad. El valor puede recibirse por medio de un protocolo de tunelización del servicio de radio por paquetes (GTP).
Alternativamente, el valor se puede recibir por medio de un protocolo de internet móvil intermediario (PMIP).
A continuación se darán a conocer más ejemplos del atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad. Por ejemplo, el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad puede ser un período de tiempo de espera para el atributo de comprobación de vivacidad con el campo de longitud ajustado a cero. Por ejemplo, el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad puede proporcionarse en una carga útil de configuración CFG_REQUEST. Por ejemplo, el atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad puede ser un período de tiempo de espera para el atributo de comprobación de vivacidad con un campo de período de tiempo de espera. Por ejemplo, el atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad puede proporcionarse en una carga útil de configuración CFG_REPLY.
Tal como se indicó anteriormente para las realizaciones relacionadas con el equipo de usuario, en una realización los mensajes se basan en IKEv1 usado junto con el protocolo de detección de pares muertos (RFC3706). Tal realización es igualmente aplicable al nodo de red central. Por lo tanto, en lugar de usar los atributos de configuración IKEv2 como se describe en este documento, se usan nuevos atributos de IKEv1 que llevan la información. En lugar de enviar/recibir un mensaje de solicitud informativa IKEv2, se puede enviar/recibir un mensaje R-U-THERE definido por RFC3706. En lugar de enviar/recibir un mensaje de respuesta informativa IKEv2, se puede enviar/recibir un mensaje R-U-THERE-ACK definido por RFC3706. Por tanto, según una realización, el nodo de red central está configurado para, en una etapa S212, recibir un mensaje de solicitud informativa del equipo de usuario; y en respuesta a ello, para, en una etapa S214, transmitir un mensaje de respuesta informativa al equipo de usuario. El mensaje de respuesta informativa puede incluirse en un mensaje de respuesta informativa IKEv2. El mensaje de respuesta informativa puede incluirse en un mensaje R-U-THERE-ACK definido por RFC3706.
A continuación se dará a conocer en detalle una realización particular para la configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet basándose, al menos, en algunas de las realizaciones descritas anteriormente, y en 3GPP TS 24.302, versión 13.0.0, sección 7.2.2 y 7.4.1. La realización particular se basa en el establecimiento de túneles. En esta realización, la funcionalidad del nodo de red central se proporciona en una ePDG.
Una vez se ha seleccionado la ePDG, el equipo de usuario inicia un procedimiento de establecimiento de túnel IPsec utilizando el protocolo IKEv2 de acuerdo con IeTF RFC 5996 y 3GPP TS 33.402, p. versión 12.5.0, sección 8.2.2. El equipo de usuario envía un mensaje de solicitud IKE SA INIT a la ePDG seleccionada, para configurar una asociación de seguridad IKEv2. Al recibir una respuesta IKE_SA_INIT, el equipo de usuario envía un mensaje de solicitud IKE_AUTH a la ePDG, incluyendo el tipo de dirección IP (dirección IPv4 o prefijo IPv6 o ambos) que se tiene que configurar en una carga útil de configuración CFG_REQUEST IKEv2. Si el equipo de usuario solicita tanto la dirección IPv4 como el prefijo IPv6, el equipo de usuario envía dos atributos de configuración en la carga útil de configuración CFG_REQUEST, un atributo de configuración para la dirección IPv4 y un atributo de configuración para el prefijo IPv6. El mensaje de solicitud IKE_AUTH comprende en la carga útil ''IDr" el APN y en la carga útil "IDi" la NAI. El equipo de usuario indica una solicitud para el APN predeterminado omitiendo la carga útil IDr, en conformidad con el protocolo IKEv2 de acuerdo con IETF RFC 5996. El mensaje de solicitud IKE_AUTH puede comprender, en una carga útil de notificación, una indicación de que el denominado MOBIKE está soportado por el equipo de usuario. El equipo de usuario también puede incluir el atributo INTERNAL_IP6_DNS o el INTERNAL_IP4_DNS en la carga útil de configuración CFG_REQUEST. El equipo de usuario puede obtener cero o más servidores DNS direccionados en la carga útil CFG_REPLY de acuerdo con IETF RFC 5996. El equipo de usuario también puede incluir el atributo P-CSCF_IP6_ADDRESS, el atributo P-CSCF_IP4_ADDRESS o ambos en la carga útil de configuración CFG_REQUEST. El equipo de usuario puede obtener cero o más direcciones de servidor P-CSCF en la carga útil de configuración CFG_REPLY, tal como se especifica en IETF draft-gundavelliipsecme-3gpp-ims-options. El equipo de usuario también puede incluir el atributo TIMEOUT_PERIOD_FOR_LIVENESS_CHECK, tal como se describe en el presente documento, indicando soporte del período de tiempo de espera de recepción para la comprobación de vivacidad en la carga útil de configuración CFG_REQUEST. Si el atributo TIMEOUT_PERIOD_FOR_LIVENESS_CHECK, tal como se describe en este documento (es decir, que indica el período de tiempo de espera para la comprobación de vivacidad), está incluido en la carga útil de configuración CFG_REPLY, el equipo de usuario realiza comprobaciones de vivacidad del túnel Durante el establecimiento de la asociación de seguridad y autenticación IKEv2, si el equipo de usuario admite una indicación explícita sobre los protocolos de movilidad admitidos, el equipo de usuario proporciona una indicación. Durante la autenticación IKEv2 y el establecimiento del túnel para la conexión inicial, el equipo de usuario proporciona una indicación sobre el tipo de conexión, que indica la conexión inicial. Para indicar la conexión debido a la conexión inicial, el equipo de usuario incluye el atributo INTERNAL_IP4_ADDRESS o el INTERNAL_IP6_ADDRESS o ambos en la carga útil de configuración CFG_REQUEST dentro del mensaje de solicitud IKE_AUTH. INTERNAL_IP4_ADDRESS no comprende ningún valor y el campo de longitud se fija a o (es decir, cero). INTERNAL_IP6_ADDRESS no comprende ningún valor y el campo de longitud se establece en o (es decir, cero).
Durante la autenticación IKEv2 y el establecimiento del túnel para el traspaso, un equipo de usuario que no admita conservación de la dirección IP para NBM indica Conexión inicial, tal como se describió anteriormente.
Durante el establecimiento de la asociación de seguridad y autenticación IKEv2 para el traspaso, un equipo de usuario que soporta conservación de dirección IP para NBM, proporciona una indicación sobre el tipo de conexión, que indica conexión de traspaso. Para indicar la conexión debida al traspaso, el equipo de usuario incluye la información de dirección local previamente asignada durante el establecimiento del túnel IPSec. Dependiendo de la versión de IP, el equipo de usuario incluye el atributo INTERNAL_IP4_ADDRESS o el INTER.NAL_IP6_ADDR.ESS o ambos en la carga útil de configuración CFG_REQUEST dentro del mensaje de solicitud IKE_AUTH para indicar la información de dirección local que es conforme con el protocolo IKEv2. El equipo de usuario admite IPSec ESP para proporcionar túneles seguros entre el equipo de usuario y la ePDG.
El equipo de usuario puede admitir múltiples intercambios de autenticación en el protocolo IKEv2 para admitir la autenticación y autorización con un servidor AAA externo que permite al UE admitir el procedimiento de autenticación PAP, el procedimiento de autenticación CHAP, o ambos.
Si se utiliza NBM y el equipo de usuario desea acceder a un PDN externo y, por lo tanto, necesita realizar autenticación y autorización con un servidor AAA externo, el equipo de usuario realiza lo siguiente:
Si la respuesta IKE_SA_INIT contiene una carga útil de notificación "MULTIPLE_AUTH_SUPPORTED", entonces el equipo de usuario incluye una carga útil de notificación "MULTIPLE_AUTH_SUPPORTED" en un una solicitud IKE_AUTH y realiza más etapas de autenticación.
Si la respuesta IKE_SA_INIT no contiene una carga útil de notificación "MULTIPLE_AUTH_SUPPORTED", entonces el equipo de usuario realiza la desconexión iniciada por el equipo de usuario. La acción del equipo de usuario subsiguiente depende de la implementación (por ejemplo, dependiendo de si se selecciona o no un nuevo ePDG). Si se utiliza NBM y si el equipo de usuario recibe de la ePDG un mensaje de respuesta IKE_AUTH que contiene una carga útil de notificación con un tipo de mensaje de notificación privado PDN_CONNECTION_REJECTION que incluye una información de dirección IP en el campo de datos de notificación, el equipo de usuario no intenta restablecer esta conexión PDN mientras está operativamente conectado a la ePDG actual y el equipo de usuario cierra los estados de asociación de seguridad IKEv2 relacionados.
Si se utiliza NBM y si el equipo de usuario recibe de la ePDG un mensaje de respuesta IKE_AUTH que contiene una carga útil de notificación con un tipo de mensaje de notificación privado PDN_CONNECTION_REJECTION y ningún campo de datos de notificación, el equipo de usuario no intenta establecer conexiones PDN adicionales a este APN mientras está conectado a la ePDG actual. El equipo de usuario cierra los estados de asociación de seguridad de IKEv2 relacionados. Posteriormente, el equipo de usuario puede intentar establecer conexiones PDN adicionales con el APN dado si se liberan una o más conexiones PDN existentes con el APN dado. Mientras está conectado operativamente a la ePDG actual, si esta conexión PDN es la primera conexión PDN para con el APN dado, el equipo de usuario no intenta establecer una conexión PDN al APN dado.
Si se utiliza NBM y si el equipo de usuario recibe de la ePDG un mensaje de respuesta IKE_AUTH que comprende una carga útil de notificación con un tipo de mensaje de notificación privado MAX_CONNECTION_REACHED, el equipo de usuario no intenta establecer ninguna conexión PDN adicional mientras está conectado operativamente a la ePDG actual. El equipo de usuario cierra los estados de asociación de seguridad de IKEv2 relacionados. Posteriormente, el equipo de usuario puede intentar establecer conexiones PDN adicionales si se liberan una o más conexiones PDN existentes.
Después de la autenticación exitosa con el servidor AAA 3GPP, el equipo de usuario recibe de la ePDG un mensaje de respuesta IKE_AUTH que comprende una única carga útil de configuración CFG_REPLY que incluye la información de dirección IP remota asignada (dirección IPv4 o prefijo IPv6). Dependiendo del mecanismo de gestión de movilidad IP utilizado, se pueden diferenciar los siguientes casos:
Si se utiliza DSMIPv6 para gestión de movilidad IP, el equipo de usuario configura una dirección IP remota en base a la información de dirección IP contenida en el atributo iNt ERNAL_IP4_ADDRESS o INTERNAL_IP6_SUBNET de la carga útil de configuración CFG_REPLY. El equipo de usuario utiliza la dirección IP remota como Care-of-Address para contactar con el HA.
Si se utiliza NBM para gestión de movilidad IP y el equipo de usuario realiza una conexión inicial, el equipo de usuario configura una dirección local en base a la información de dirección de la carga útil de configuración CFG_REPLY. De lo contrario, si se utiliza NBM y el equipo de usuario realiza una conexión de traspaso, el equipo de usuario continúa utilizando su dirección IP configurada antes del traspaso, si la información de dirección proporcionada en la carga útil de configuración CFG_REPLY coincide con la dirección IP del equipo de usuario que está configurada antes del traspaso. Si la dirección IP del equipo de usuario no coincide con la información de dirección de la carga útil de configuración CFG_REPLY, el equipo de usuario configura una nueva dirección local basada en la información de dirección IP contenida en el atributo INTERNAL_IP4_ADDRESS o INTERNAL_IP6_SUBNET de la carga útil de configuración CFG_REPLY. En el último caso, la conservación de la dirección IP no es posible.
Si el equipo de usuario soporta DSMIPv6, el equipo de usuario puede solicitar la dirección o direcciones IP de HA, incluyendo una correspondiente Carga útil de configuración CFG_REQUEST que contiene un atributo de dirección de agente local. La dirección o direcciones IP de HA solicitadas en este atributo son para el APN para el que está configurado el túnel IPsec con la ePDG. En CFG_REQUEST, el equipo de usuario establece respectivamente el campo de dirección IPv6 y el campo de dirección IPv4 opcional del atributo de dirección de agente local en o::o y en 0.0.0.0, Si el equipo de usuario no puede obtener las direcciones IP del HA por medio de señalización IKEv2, el equipo de usuario utiliza el descubrimiento de direcciones de agente local.
En caso de que el equipo de usuario desee establecer múltiples conexiones PDN y si el equipo de usuario usa DSMIPv6 para gestión de movilidad, el equipo de usuario usa DNS para descubrir la dirección o direcciones IP de HA para las conexiones PDN adicionales después de que se estableció la asociación de seguridad IKEv2 con la ePDG.
Si el atributo TIMEOUT_PERIOD_FOR_LIVENESS_CHECK que indica el período de tiempo de espera para la comprobación de vivacidad se incluyó en una carga útil de configuración CFG_REPLY y el equipo de usuario no ha recibido ningún mensaje IKEv2 o IPSec protegido criptográficamente durante el período de tiempo de espera para la comprobación de vivacidad indicada en el atributo TIMEOUT_PERIOD_FOR_LIVENESS_c HeCK, el equipo de usuario envía una solicitud informativa sin cargas útiles. Si no se recibe una respuesta informativa para la solicitud informativa, el equipo de usuario considera que la asociación de seguridad IKEv2 ha fallado y descarta todos los estados asociados con la asociación de seguridad IKEv2 y cualesquiera asociaciones de seguridad IPSec que se hayan negociado utilizando la asociación de seguridad IKE.
Tras la recepción de un mensaje de solicitud IKE_AUTH del equipo de usuario solicitando el establecimiento de un túnel, la ePDG procede con una autenticación y autorización, proporcionándose más detalles a continuación.
Durante el procedimiento de autenticación y autorización del equipo de usuario, el servidor AAA 3GPP proporciona a la ePDG una indicación sobre el mecanismo de movilidad IP seleccionado.
La ePDG continúa con la finalización del establecimiento del túnel IPsec y retransmite en la carga útil de configuración IKEv2 (CFG_REPLY) del mensaje de respuesta IKE_AUTH final la información de dirección IP remota al equipo de usuario. Si se utiliza NBM como mecanismo de movilidad IP, la ePDG asigna una dirección IPv4 o un prefijo de red local IPv6 o ambos al equipo de usuario por medio de una única carga útil de configuración CFG_REPLY. Si el equipo de usuario solicita tanto la dirección IPv4 como el prefijo IPv6, pero la ePDG solo asigna una dirección IPv4 o un prefijo de red local IPv6 debido a una restricción de suscripción o preferencia de red, la ePDG incluye la información de dirección IP remota asignada (dirección IPv4 o prefijo IPv6 ) por medio de una única carga útil de configuración CFG_REPLY. Si la ePDG asigna una dirección IPv4, CFG_REPLY comprende el atributo INTERNAL_IP4_ADDRESS. Si la ePDG asigna un prefijo de red local IPv6, c Fg_REPLY comprende el atributo de configuración INTERNAL_IP6_SUBNET. La ePDG obtiene la dirección IPv4 y/o el prefijo de red local IPv6 de la PDN GW (PGW). Si el equipo de usuario no proporciona un APN a la ePDG durante el establecimiento del túnel, la ePDG incluye el APN predeterminado en la carga útil IDr del mensaje de respuesta IKE_AUTH. Si el equipo de usuario incluyó INTERNAL_IP6_DNS o INTERNAL_IP4_DNS en la carga útil de configuración CFG_REQu EsT, la ePDG incluye el mismo atributo en la carga útil de configuración CFG_REPLY incluyendo cero o más direcciones de servidor DNS, de acuerdo con IETF RFC 5996. Si el equipo de usuario incluye el atributo P-CSCF_IP6_ADDRESS, el atributo P-CSCF_IP4_ADDRESS o ambos en la carga útil de configuración CFG_REQUEST, la ePDG puede incluir una o más instancias del mismo atributo en la carga útil de configuración CFG_REPLY como se especifica en IETF draft-gundavelli-ipsecme-3gpp-ims-options. Si el equipo de usuario incluyó el atributo TIMEOUT_PERIOD_FOR_LIVENESS_CHECK que indica soporte para recibir el período de tiempo de espera para la comprobación de vivacidad en la carga útil de configuración CFG_REQUEST, la ePDG puede incluir el atributo TIMEOUT_PERIOD_FOR_LIVENESS_CHECK que indica el período de tiempo de espera para la comprobación de vivacidad en la carga útil de configuración CFG_REPLY.
Si DSMIPv6 se utiliza como mecanismo de movilidad IP, dependiendo de la información proporcionada por el equipo de usuario en la carga útil CFG_REQUEST, las ePDG asignan al equipo de usuario una dirección IPv4 local o una dirección IPv6 local (o un prefijo IPv6 local) por medio de una única carga útil de configuración CFG_REPLY. Si la ePDG asigna una dirección IPv4 local, CFG_REPLY comprende el atributo INTERNAL_IP4_ADDRESS. Si la ePDG asigna una dirección IPv6 local o un prefijo IPv6 local, CFG_REPLY comprende correspondientemente el atributo INTERNAL_IP6_ADDRESS o INTErNa L_IP6_SUBNET. Si el equipo de usuario proporcionó un APN a la ePDG durante el establecimiento del túnel, la ePDG no cambia el APN proporcionado e incluye el APN en la carga útil IDr del mensaje de respuesta IKE_AUTH. A continuación se establece un túnel IPsec entre el equipo de usuario y la ePDG.
Si se utiliza NBM y si la ePDG necesita rechazar una conexión PDN, por ejemplo debido a condiciones específicas, a las políticas de red o a las capacidades de ePDG para indicar que no se pueden aceptar más solicitudes de conexión PDN del APN dado para el equipo de usuario, la ePDG incluye, en el mensaje de respuesta IKE_AUTH, una carga útil de notificación con una notificación privada Tipo de mensaje PDN_CONNECTION_REJECTION. Además, si el mensaje de solicitud IKE_AUTH del equipo de usuario indicó conexión de traspaso, el campo de datos de notificación de la carga útil de notificación incluye la información de dirección IP de la indicación de conexión de traspaso. Si el equipo de usuario indicó conexión inicial, se omite el campo Datos de notificación. Si la ePDG necesita rechazar una conexión PDN debido a las políticas o capacidades de la red para indicar que no se pueden aceptar más solicitudes de conexión PDN con ningún APN para el equipo de usuario, la ePDG incluye en el mensaje de respuesta IKE_AUTH que contiene la carga útil IDr una carga útil de notificación con un tipo de mensaje de notificación privado MAX_CONNECTION_REACHED. Si la ePDG determina que el equipo de usuario no tiene permiso para acceder a EPC, la ePDG incluye, en el mensaje de respuesta IKE_AUTH, una carga útil de notificación con un tipo de mensaje de notificación AUTHENTICATION_FAILED.
Si el equipo de usuario indica conexión de traspaso al incluir la información de dirección local previamente asignada y la ePDG obtiene una o más identidades PDN GW del servidor AAA 3GPP, la ePDG usa estas PDN Gw identificadas en el proceso de selección de PDN GW subsiguiente. Si el equipo de usuario indica Conexión inicial, es decir, no se incluye información de dirección local, la ePDG puede ejecutar su proceso de selección de PDN GW inicial para determinar la PDN GW sin utilizar las identidades de PDN GW recibidas.
La ePDG soporta IPSec ESP para proporcionar túneles seguros entre el equipo de usuario y la ePDG.
Durante la autenticación IKEv2 y el establecimiento del túnel, si el equipo de usuario solicitó la dirección o direcciones IP de HA y si se eligió DSMIPv6, y si la dirección o direcciones IP de HA están disponibles, la ePDG proporciona la dirección o direcciones IP de HA (dirección IPv6) y opcionalmente dirección IPv4) para el APN correspondiente según se especifica por la carga útil "IDr" en el mensaje de solicitud IKE_AUTH incluyendo en la carga útil de configuración CFG REPLY un atributo HOME_AGENT_ADDRESS. En CFG_REPLY, la ePDG establece respectivamente el campo de dirección de agente local IPv6 y, opcionalmente, el campo de dirección de agente local IPv4 del atributo de dirección de agente local a la dirección IPv6 de1HA y a la dirección IPv4 de1HA. Si no hay una dirección HA IPv4 disponible en la ePDG o si esta no fue solicitada por el equipo de usuario, la ePDG omite el campo dirección de agente local IPv4. Si la ePDG no puede proporcionar una dirección HA IPv6 para el APN correspondiente, entonces la ePDG no incluye un atributo de dirección de agente local en CFG_REPLY.
La ePDG puede admitir múltiples intercambios de autenticación en el protocolo IKEv2 para admitir autenticación y autorización adicionales del equipo de usuario con un servidor AAA externo.
Si la ePDG admite autenticación y autorización del equipo de usuario con un servidor AAA externo, al recibir un mensaje IKE_SA_INIT, la ePDG incluye una carga útil de notificación del tipo "MULTIPLE_AUTH_SUPPORTED" en el mensaje de respuesta IKE_SA_INIT al equipo de usuario.
Al completar con éxito el procedimiento de autenticación y autorización del equipo de usuario que accede a EPC y al recibir una solicitud IKE_AUTH que contiene una carga útil de notificación de tipo "ANOTHER_AUTH_FOLLOWS", la ePDG envía una respuesta IKE_AUTH que contiene la carga útil "AUTH".
Al recibir una solicitud IKE_AUTH posterior desde el equipo de usuario, que comprende la identidad del usuario en la red privada dentro de la carga útil "IDi", la ePDG realiza lo siguiente:
Si se requiere autenticación PAP, entonces la ePDG envía una solicitud EAP-GTC al equipo de usuario dentro de un mensaje de respuesta IKE_AUTH. Al recibir una respuesta EAP-GTC del equipo de usuario, la ePDG autentica al usuario (equipo de usuario) con el servidor AAA externo.
Si se requiere autenticación CHAP, entonces la ePDG envía una solicitud de desafío MD5 EAP al equipo de usuario. Al recibir una respuesta de desafío MD5 EAP dentro de un mensaje de solicitud IKE_AUTH del equipo de usuario, la ePDG autentica al usuario (equipo de usuario) con el servidor AAA externo. Si la ePDG recibe una respuesta Nakheredada que comprende el tipo EAP-GTC desde el equipo de usuario, la ePDG puede cambiar el procedimiento de autenticación y autorización. Si la ePDG no cambia el procedimiento de autenticación y autorización o si la ePDG recibe una respuesta Nak-heredada que no incluye EAP-GTC, la ePDG envía fallo-EAP al equipo de usuario.
La señalización general fluye para autenticación y autorización con un servidor AAA externo.
En términos generales, los requisitos de IETF RFC 5996 aplican a esta realización.
El atributo TIMEOUT_PERIOD_FOR_LIVENESS_CHECK de acuerdo con esta realización se muestra en la figura 10.
En la figura 10, las entradas del atributo se codifican como sigue: El bit R en el primer octeto. El campo de tipo de atributo que indica TIMEOUT_PERIOD_FOR_LIVENESS_CHECK tiene el valor xx. El campo de longitud se establece en cero o cuatro. Si el campo de longitud se establece en cero, el campo de período de tiempo de espera no se incluye. Si no se incluye el campo de período de tiempo de espera, esto indica que se admite la recepción del período de tiempo de espera para la comprobación de vivacidad. Si se incluye el campo de período de tiempo de espera, el campo de período de tiempo de espera indica el período de tiempo de espera para la comprobación de vivacidad en segundos.
En esta realización, el punto final del túnel en la red es la ePDG. Como parte del intento de establecimiento del túnel, se solicita el uso de un determinado APN. Cuando el UE realiza un nuevo intento de establecimiento de túnel, el UE utiliza IKEv2. La autenticación del UE en su función de iniciador IKEv2 termina en el servidor AAA 3GPP. El UE envía mensajes EAP sobre IKEv2 a la ePDG. La ePDG extrae los mensajes EAP recibidos del UE sobre IKEv2 y los envía al servidor AAA 3GPP. El UE utiliza la carga útil de configuración IKEv2 para obtener la dirección IP remota.
A continuación, se omiten los parámetros de mensaje EAP-AKA y los procedimientos relacionados con la autenticación; solo dan a conocer las decisiones y los procesos relevantes para el uso de EAP-AKA dentro de IKEv2.
El flujo de mensajes para la autenticación completa se ilustra en el diagrama de señalización de la figura 9.
A medida que el equipo de usuario y la ePDG generan nonces como entrada para derivar claves de cifrado y autenticación en IKEv2, se proporciona protección de reproducción. Por al menos esta razón, no hay necesidad de que el servidor AAA 3GPP vuelva a solicitar la identidad del usuario utilizando los métodos específicos de EAP-AKA, porque el servidor AAA 3GPP está seguro de que ningún nodo intermedio ha modificado o cambiado la identidad del usuario.
5301. El UE y la ePDG intercambian un primer par de mensajes, conocidos como IKE_SA_INIT, donde la ePDG y el UE negocian algoritmos criptográficos, intercambian nonces y realizan un intercambio Diffie_Hellman. En el diagrama de señalización de la figura 9, el atributo X en la etapa S301 representa un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad.
5302. El UE envía la identidad del usuario (en la carga útil IDi) y la información APN (en la carga útil IDr) en este primer mensaje de la fase IKE_AUTH y comienza la negociación de asociaciones de seguridad secundarias. El UE omite el parámetro AUTH para indicar a la ePDG que quiere usar EAP sobre IKEv2. La identidad del usuario cumple con un formato de identificador de acceso a la red (NAI), que contiene el IMSI o el seudónimo, según se define para EAP-AKA. El UE envía la carga útil de configuración (CfG_REQUEST) dentro del mensaje de solicitud IKE_AUTH para obtener una dirección IP local IPv4 y/o IPV6 y/o una dirección de agente local.
5303. La ePDG envía el mensaje de solicitud de autenticación y autorización al servidor AAA 3GPP, que contiene la identidad del usuario y el APN. El UE usa el NAI; el servidor AAA 3GPP identifica, basándose en la parte de dominio de la NAI, que se está realizando autenticación y autorización combinadas para el establecimiento de túneles con una ePDG que solo permite EAP-AKA (y no un I-WLAN PDG, que también permitiría EAP- SIM). Las diferentes ID de aplicación de Diameter ayudarán al servidor AAA 3GPP a distinguir entre autenticaciones para acceso fiable (que requiere autenticación EAP-AKA) y autenticaciones para establecimiento de túnel en EPS (que solo permite EAP-AKA).
5304. El servidor AAA 3GPP obtiene los vectores de autenticación del HSS/HLR (si estos parámetros no están disponibles en el servidor AAA 3GPP). El servidor AAA 3GPP realiza una búsqueda de la IMSI del usuario autenticado (UE) basándose en la identidad del usuario recibido (NAI raíz o seudónimo) e incluye el EAP-AKA como método de autenticación solicitado en la solicitud enviada al HSS. A continuación, e1HSS genera vectores de autenticación con bit de separación AMF = 0 y los envía de vuelta al servidor AAA 3GPP.
5305. El servidor AAA 3GPP inicia el desafío de autenticación. No se vuelve a solicitar la identidad del usuario. 5306. La ePDG responde con su identidad, un certificado y envía el parámetro AUTH para proteger el mensaje anterior que envió al UE (en el intercambio IKE_SA_INIT). El mensaje EAP recibido del servidor AAA 3GPP (solicitud-EAP/desafío-AKA) se incluye para iniciar el procedimiento EAP sobre IKEv2.
5307. El UE comprueba los parámetros de autenticación y responde al desafío de autenticación. La única carga útil (aparte del encabezado) en el mensaje IKEv2 es el mensaje EAP.
5308. La ePDG reenvía el mensaje respuesta-EAP/desafío-AKA al servidor AAA 3GPP.
S308.a El servidor AAA 3GPP comprueba si la respuesta de autenticación es correcta.
5308. b-e Si la selección dinámica de movilidad IP se ejecuta incorporada en la autenticación y autorización, el modo de movilidad seleccionado se envía al usuario (UE) en una solicitud de notificación AKA, sobre la respuesta Diameter A&A y el mensaje IKE_AUTH. El UE responde a esto sobre IKEv2 y la ePDG envía la respuesta al servidor AAA 3GPP.
S308A. El servidor AAA 3GPP inicia la recuperación del perfil de abonado y el registro del servidor AAA 3GPP en el HSS. El servidor AAA 3GPP comprueba en la suscripción del equipo de usuario si el usuario está autorizado para el acceso no 3GPP.
5309. Cuando todas las comprobaciones son satisfactorias, el servidor AAA 3GPP envía una respuesta de autenticación y autorización final (con un código de resultado que indica el éxito) que incluye la información de autorización de servicio relevante, un éxito de EAP y el material de claves a la ePDG. Este material de claves comprende el MSK generado durante el proceso de autenticación. Cuando las interfaces SWm y SWd entre la ePDG y el servidor AAA 3GPP se implementan usando Diameter, el MSK se encapsula en el EAP-Master-Session-Key-AVP.
5310. La ePDG utiliza el MSK para generar los parámetros AUTH con el fin de autenticar los mensajes de la fase IKE_SA_INIT. Estos dos primeros mensajes no se habían autenticado antes ya que todavía no había material de claves disponible. El secreto compartido generado en un intercambio EAP (el MSK), cuando se usa sobre IKEv2, se usa para generar los parámetros AUTH.
5311. El mensaje EAP éxito/fallo se reenvía al equipo de usuario sobre IKEv2.
5312. El equipo de usuario toma su propia copia del MSK como entrada para generar el parámetro AUTH para autenticar el primer mensaje IKE_SA_INIT. El parámetro AUTH se envía a la ePDG.
5313. La ePDG comprueba la corrección de la AUTH recibida del equipo de usuario. En este punto, se autentica el equipo de usuario. Si se utiliza el caso S2b, a continuación puede comenzar la señalización PMIP entre la ePDG y la PDN GW. La ePDG continúa con la siguiente etapa en el procedimiento descrito aquí solo después de completar con éxito el procedimiento de actualización del enlace PMIP.
S314. La ePDG calcula el parámetro AUTH que autentica el segundo mensaje IKE_SA_INIT. La ePDG envía la dirección IP remota asignada, en la carga útil de configuración (CFG_REPLY).
S315.El parámetro AUTH se envía al UE junto con la carga útil de configuración, las asociaciones de seguridad y el resto de los parámetros IKEv2 y termina la negociación IKEv2. En el diagrama de señalización de la figura 9, el atributo Y en la etapa S315 representa un atributo de configuración que indica un período de tiempo de espera para la comprobación de vivacidad.
El concepto inventivo se ha descrito principalmente anteriormente haciendo referencia a algunas realizaciones. Sin embargo, tal como apreciará fácilmente un experto en la técnica, otras realizaciones distintas de las descritas anteriormente son igualmente posibles dentro del alcance del concepto inventivo, tal como se define en las reivindicaciones de patente adjuntas.

Claims (7)

REIVINDICACIONES
1. Un método para la configuración y realización de una comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, siendo realizado el método por un equipo de usuario (11), comprendiendo el método:
transmitir (S102), desde el equipo de usuario sobre una interfaz aérea a un nodo (12) de red central, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad, en donde el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad es un período de tiempo de espera para el atributo de comprobación de vivacidad con el campo de longitud ajustado a cero,
recibir (S104), en el equipo de usuario sobre la interfaz aérea desde el nodo de red central, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad,
realizar (S106) dicha comprobación de vivacidad de acuerdo con el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad, que comprende:
transmitir (S108) una solicitud informativa sin carga útil si un período de tiempo de espera para el atributo de comprobación de vivacidad está incluido en el atributo de configuración recibido que indica un período de tiempo de espera para dicha comprobación de vivacidad, y en ausencia de la recepción de un paquete de seguridad de protocolo de internet protegido criptográficamente, IPSec, o un paquete de intercambio criptográfico de claves de internet durante el período de tiempo de espera para dicha comprobación de vivacidad, y en donde, en ausencia de la recepción de una respuesta informativa en respuesta a la solicitud informativa transmitida sin carga útil, se lleva a cabo uno o más de:
determinar (S110) un fallo de la asociación de seguridad de intercambio de claves de internet;
descartar (S112) cualquier información de estado asociada con la asociación de seguridad de intercambio de claves de internet; y/o
descartar (S114) cualesquiera asociaciones de seguridad de seguridad de protocolo de internet, IPSec, negociadas utilizando la asociación de seguridad de intercambio de claves de internet
2. El método según la reivindicación 1, en el que el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad se proporciona en una carga útil de configuración CFG_REQUEST.
3. El método según cualquiera de las reivindicaciones anteriores, en el que el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad es un período de tiempo de espera para el atributo de comprobación de vivacidad con un campo de período de tiempo de espera.
4. El método según cualquiera de las reivindicaciones anteriores, en el que el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad se proporciona en una carga útil de configuración CFG_REPLY.
5. El método según cualquiera de las reivindicaciones anteriores, en el que dicho atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad se basa en información de un sistema de configuración o sistema de gestión.
6. El método según cualquiera de las reivindicaciones anteriores, en el que el primer mensaje de intercambio de claves de internet se transmite en un mensaje de intercambio de claves de internet versión 2, IKEv2, y en el que el segundo mensaje de intercambio de claves de internet se recibe en un mensaje IKEv2.
7. Un equipo de usuario (11) para la configuración y realización de una comprobación de vivacidad utilizando mensajes de intercambio de claves de internet, comprendiendo el equipo de usuario una unidad de procesamiento (21), estando configurada la unidad de procesamiento para hacer que el equipo de usuario:
transmita, desde el equipo de usuario sobre una interfaz aérea a un nodo (12) de red central, un primer mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad; en donde el atributo de configuración que indica soporte para recibir un período de tiempo de espera para la comprobación de vivacidad es un período de tiempo de espera para el atributo de comprobación de vivacidad con el campo de longitud ajustado a cero,
recibir, en el equipo de usuario sobre la interfaz aérea desde el nodo de red central, un segundo mensaje de intercambio de claves de internet que comprende un atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad, y
realizar dicha comprobación de vivacidad de acuerdo con el atributo de configuración que indica un período de tiempo de espera para dicha comprobación de vivacidad, lo que comprende:
transmitir una solicitud informativa sin carga útil si un período de tiempo de espera para el atributo de comprobación de vivacidad está incluido en el atributo de configuración recibido que indica un período de tiempo de espera para dicha comprobación de vivacidad, y en ausencia de la recepción de un paquete de seguridad de protocolo de internet protegido criptográficamente, IPSec, o de un paquete de intercambio criptográfico de claves de internet durante el período de tiempo de espera para dicha comprobación de vivacidad, y en donde, en ausencia de la recepción de una respuesta informativa en respuesta a la solicitud informativa transmitida sin carga útil, además:
determinar un fallo de la asociación de seguridad de intercambio de claves de internet;
descartar cualquier información de estado asociada con la asociación de seguridad de intercambio de claves de internet; y/o
descartar cualesquiera asociaciones de seguridad de seguridad de protocolo de internet, IPSec, negociadas utilizando la asociación de seguridad de intercambio de claves de internet.
ES20159748T 2015-03-25 2015-03-25 Configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet Active ES2877067T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP20159748.1A EP3678349B1 (en) 2015-03-25 2015-03-25 Configuration of liveness check using internet key exchange messages
PCT/SE2015/050357 WO2016153402A1 (en) 2015-03-25 2015-03-25 Configuration of liveness check timeout using ike messages

Publications (1)

Publication Number Publication Date
ES2877067T3 true ES2877067T3 (es) 2021-11-16

Family

ID=52991925

Family Applications (2)

Application Number Title Priority Date Filing Date
ES20159748T Active ES2877067T3 (es) 2015-03-25 2015-03-25 Configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet
ES15717677T Active ES2807606T3 (es) 2015-03-25 2015-03-25 Configuración de plazo de espera de comprobación de operatividad usando mensajes IKE

Family Applications After (1)

Application Number Title Priority Date Filing Date
ES15717677T Active ES2807606T3 (es) 2015-03-25 2015-03-25 Configuración de plazo de espera de comprobación de operatividad usando mensajes IKE

Country Status (11)

Country Link
US (2) US9800404B2 (es)
EP (2) EP3275149B1 (es)
CN (2) CN111726228B (es)
DK (2) DK3275149T3 (es)
ES (2) ES2877067T3 (es)
HU (1) HUE050006T2 (es)
MX (1) MX369580B (es)
PL (2) PL3275149T3 (es)
PT (1) PT3678349T (es)
WO (1) WO2016153402A1 (es)
ZA (1) ZA201705976B (es)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016187871A1 (en) * 2015-05-28 2016-12-01 Telefonaktiebolaget Lm Ericsson (Publ) Multiple pdn connections over untrusted wlan access
US9998970B2 (en) * 2016-04-28 2018-06-12 Samsung Electronics Co., Ltd. Fast VoWiFi handoff using IKE v2 optimization
EP3545702B1 (en) * 2016-11-23 2021-03-24 Telefonaktiebolaget LM Ericsson (publ) User identity privacy protection in public wireless local access network, wlan, access
US10390277B2 (en) * 2016-11-30 2019-08-20 Samsung Electronics Co., Ltd. MOBIKE aware LTE to Wi-Fi handoff optimization
US10624020B2 (en) * 2017-02-06 2020-04-14 Qualcomm Incorporated Non-access stratum transport for non-mobility management messages
WO2019003106A1 (en) * 2017-06-26 2019-01-03 Telefonaktiebolaget Lm Ericsson (Publ) REFRESHMENT OF A SECURITY CONTEXT FOR A MOBILE DEVICE
CN110972090B (zh) * 2018-09-29 2022-04-15 中兴通讯股份有限公司 Pcf+pcrf选择方法、amf、bsf及存储介质
KR20210130640A (ko) * 2020-04-22 2021-11-01 현대자동차주식회사 M2m 시스템에서 라이브니스를 검사하기 위한 방법 및 장치
EP4066529A4 (en) 2020-05-29 2023-08-09 ZTE Corporation METHOD AND DEVICE FOR SECURE CONNECTION BETWEEN AN ARTIFICIAL INTELLIGENCE SERVER AND A BASE STATION NODE

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6976071B1 (en) * 2000-05-03 2005-12-13 Nortel Networks Limited Detecting if a secure link is alive
US20020143946A1 (en) * 2001-03-28 2002-10-03 Daniel Crosson Software based internet protocol address selection method and system
US7228421B1 (en) * 2001-06-27 2007-06-05 Cisco Technology, Inc. Technique for generating control messages with reason information between nodes in a data network
KR20040068499A (ko) * 2003-01-24 2004-07-31 마쯔시다덴기산교 가부시키가이샤 공유키 교환방법과 통신기기
GB0504868D0 (en) * 2005-03-09 2005-04-13 Nokia Corp A method of configuring a communication device
DE602005013410D1 (de) * 2005-12-15 2009-04-30 Nokia Corp Verfahren, Apparat und Computerprogrammprodukt zur Beibehaltung von Abbildungszuordnungen
US8229427B2 (en) * 2006-07-14 2012-07-24 Qualcomm Incorporated Status validation for terminals in a wireless communication system
US8213295B2 (en) * 2006-09-12 2012-07-03 Qualcomm Incorporated Transaction timeout handling in communication session management
US20080172582A1 (en) * 2007-01-12 2008-07-17 David Sinicrope Method and system for providing peer liveness for high speed environments
EP2003841B1 (en) * 2007-06-14 2010-08-11 Nokia Siemens Networks Oy Reducing keep-alive messages in connection with element traversal by relay mechanism
JP4980151B2 (ja) * 2007-06-18 2012-07-18 株式会社日立製作所 移動体通信システム、ｐｄｉｆ及び移動端末の死活監視方法
US7961725B2 (en) * 2007-07-31 2011-06-14 Symbol Technologies, Inc. Enterprise network architecture for implementing a virtual private network for wireless users by mapping wireless LANs to IP tunnels
WO2010049574A1 (en) * 2008-10-29 2010-05-06 Nokia Corporation Connection management
EP2194686A1 (en) * 2008-12-03 2010-06-09 Panasonic Corporation Secure tunnel establishment upon attachment or handover to an access network
US8656481B2 (en) * 2009-09-15 2014-02-18 General Instrument Corporation System and method for IPSec link configuration
EP2362688B1 (en) * 2010-02-23 2016-05-25 Alcatel Lucent Transport of multihoming service related information between user equipment and 3GPP evolved packet core
US8219606B2 (en) * 2010-02-27 2012-07-10 Robert Paul Morris Methods, systems, and computer program products for sharing information for detecting an idle TCP connection
US8458248B2 (en) * 2010-09-24 2013-06-04 Research In Motion Limited System and method for enabling VPN tunnel status checking
CN102801545B (zh) * 2011-05-25 2015-12-09 华为技术有限公司 配置信息的获取方法和设备
US9344397B2 (en) * 2011-09-27 2016-05-17 Aruba Networks, Inc. Client aware DHCP lease management
EP2907272B1 (en) * 2012-10-10 2016-11-30 Nokia Solutions and Networks Oy Peer revival detection
TW201434292A (zh) * 2012-10-15 2014-09-01 Interdigital Patent Holdings 邊緣組件失效切換恢復方法
CN103179225B (zh) * 2013-03-18 2016-12-28 杭州华三通信技术有限公司 一种基于IPsec的NAT表项保活方法和设备
US10187478B2 (en) * 2014-07-18 2019-01-22 Hewlett Packard Enterprise Development Lp Dynamic detection of inactive virtual private network clients

Also Published As

Publication number Publication date
EP3275149B1 (en) 2020-05-06
MX369580B (es) 2019-11-13
WO2016153402A1 (en) 2016-09-29
HUE050006T2 (hu) 2020-11-30
CN107466465B (zh) 2020-08-11
EP3678349B1 (en) 2021-05-05
CN111726228A (zh) 2020-09-29
PL3678349T3 (pl) 2021-09-27
US20170310476A1 (en) 2017-10-26
ES2807606T3 (es) 2021-02-23
US9800404B2 (en) 2017-10-24
EP3678349A1 (en) 2020-07-08
DK3275149T3 (da) 2020-06-29
CN107466465A (zh) 2017-12-12
MX2017011691A (es) 2017-11-10
CN111726228B (zh) 2023-08-25
PL3275149T3 (pl) 2020-11-02
DK3678349T3 (da) 2021-06-07
EP3275149A1 (en) 2018-01-31
US9973338B2 (en) 2018-05-15
US20160285627A1 (en) 2016-09-29
ZA201705976B (en) 2019-01-30
PT3678349T (pt) 2021-06-17

Similar Documents

Publication Publication Date Title
ES2877067T3 (es) Configuración de la comprobación de vivacidad utilizando mensajes de intercambio de claves de internet
US20210250767A1 (en) Systems and methods for accessing a network
ES2393577T3 (es) Seguridad para un acceso no 3GPP a un sistema de paquetes evolucionado
EP3304980B1 (en) Multiple pdn connections over untrusted wlan access
US20190380033A1 (en) User Identity Privacy Protection in Public Wireless Local Access Network, WLAN, Access
US8964695B2 (en) Optimization of handovers to untrusted non-3GPP networks
JP6628295B2 (ja) 認証されていないユーザのための３ｇｐｐ進化型パケットコアへのｗｌａｎアクセスを介した緊急サービスのサポート
US9226153B2 (en) Integrated IP tunnel and authentication protocol based on expanded proxy mobile IP
TW201507526A (zh) 受信任無線區域網路（ｗｌａｎ）存取場景
TW201725931A (zh) 通訊系統中閘道器節點之選擇
US20220038904A1 (en) Wireless-network attack detection
JP2020505845A (ja) 緊急アクセス中のパラメータ交換のための方法およびデバイス
US10382958B2 (en) Methods and devices of registering, verifying identity of, and invalidating non-SIM mobile terminals accessing a wireless communication network