MX2007000588A - Control portador de flujos de datos encriptados en comunicaciones de datos en paquete. - Google Patents

Control portador de flujos de datos encriptados en comunicaciones de datos en paquete.

Info

Publication number
MX2007000588A
MX2007000588A MX2007000588A MX2007000588A MX2007000588A MX 2007000588 A MX2007000588 A MX 2007000588A MX 2007000588 A MX2007000588 A MX 2007000588A MX 2007000588 A MX2007000588 A MX 2007000588A MX 2007000588 A MX2007000588 A MX 2007000588A
Authority
MX
Mexico
Prior art keywords
communication session
index
message
signaling message
data packets
Prior art date
Application number
MX2007000588A
Other languages
English (en)
Inventor
Wangjun
Arungundram C Mahendran
Raymond Tah-Sheng Hsu
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of MX2007000588A publication Critical patent/MX2007000588A/es

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/164Implementing security features at a particular protocol layer at the network layer

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

En una sesion de comunicacion en la que los flujos de datos con paquetes de datos encriptados pasan a traves de un intermediario de monitoreo para el control de trafico de datos. Los paquetes de datos enciptados incluyen SPIs (Indices de Parametro Seguros) los cuales se utilizan para identificar SAs (Asociaciones de Seguridad) para la desencriptacion de datos. Durante el proceso de senalizacion inicial para la sesion de comunicacion, los nodos que buscan la sesion de comunicacion incluyen los SPIs en los mensajes de senalizacion y envian los mensajes de senalizacion a traves del intermediario de monitoreo el cual en turno compara los SPIs de los mensajes de senalizacion con los SPIs correspondientes extraidos de los paquetes de datos. Al reforzar el control del trafico de datos, el intermediario de monitoreo permite que los datos fluyan para pasar si la comparacion coincide en los SPIs que se 'encuentran. De otro modo, los flujos de datos se rechazan.

Description

CONTROL PORTADOR DE FLUJOS DE DATOS ENCRIPTADOS EN COMUNICACIONES DE DATOS EN PAQUETE CAMPO DE LA INVENCIÓN La presente invención generalmente se refiere a comunicaciones de datos en paquete, y muy particularmente, al monitoreo y control de flujos de datos en paquete durante comunicaciones de datos en paquete.
ANTECEDENTES DE LA INVENCIÓN La interconexión de redes globalmente permite que se pueda tener acceso a la información sin considerar las distancias geográficas. La figura 1 muestra un dibujo esquemático simplificado de la conexión global de redes, comúnmente denominada como la Internet indicada por el número de referencia 20. La Internet 20 en esencia son muchas redes con diferentes niveles de jerarquía vinculada entre sí. La Internet 20 es operada bajo el IP (Protocolo de Internet) promulgado por la IETF (Fuerza Operante de Ingeniería de Internet) . Detalles del IP se pueden encontrar en RFC (Solicitud de Comentarios) 791 publicada por la IETF. Conectadas a la Internet 20 están varias redes individuales, algunas veces denominadas LAN (Redes de Área Local) o WAN (Redes de Área Amplia) dependiendo de los tamaños de la red. En la figura 1 se muestran algunas de esas redes 22, 24 y 26. Dentro de cada una de las redes 22, 24, y 26, puede haber varias piezas de equipo conectado a y en comunicación entre sí. Ejemplos son computadoras, impresoras y servidores, por mencionar algunos. Cada pieza de equipo tiene una dirección de hardware única, comúnmente denominada dirección MAC (Control de Acceso de Medios) . La pieza de equipo con la dirección MAC en ocasiones se denomina un nodo. Cuando el nodo establece comunicación más allá de su propia red a través de la Internet 20, una dirección IP necesita ser asignada al nodo. La asignación de la dirección IP puede ser manual o automática. La asignación manual de la dirección IP puede ser ejecutada por un administrador de red, por ejemplo. Con mayor frecuencia, la dirección IP es asignada automáticamente. Por ejemplo, en una LAN, la dirección IP puede ser asignada por un servidor denominado el servidor DHCP (Protocolo de Control Huésped Dinámico) (que no se muestra) el cual reside dentro de la LAN del nodo. Además, en una WAN la cual soporta tecnologías inalámbricas, las direcciones IP pueden ser asignadas de manera automática y remota.
Volviendo ahora a la figura 1, como un ejemplo, asumir que un nodo 30 en la red 22 intenta enviar un paquete de datos a otro nodo 34 en la red 24. Bajo el IP, cada paquete de datos necesita tener una dirección fuente y una dirección de destino. En este caso, la dirección fuente es la dirección del nodo 30 en la red 22. La dirección de destino es la dirección del nodo 34 en la red 24. Operando en esa forma, los nodos 30 y 34 se dice que están en comunicación bajo el modo de transporte IP Simple en el cual, ambos nodos 30 y 34 simplemente utilizan sus propias direcciones IP en el intercambio de paquetes de datos para ajustarse con el IP. La llegada de las tecnologías inalámbricas permite a los nodos moverse lejos de su red originalmente registrada a otra red. Por ejemplo, refiriéndose nuevamente a la figura 1, el nodo 30, en lugar de estar permanentemente cableada a la red 22, puede ser un dispositivo inalámbrico, tal como un PDA (Asistente de Dispositivo Personal) , un teléfono celular, o una computadora móvil. El nodo inalámbrico 30 se puede desplazar más allá del límite de su red local 22. Por lo tanto, el nodo 30 puede tener seguimiento lejos de su red local 22 a una red exterior 26. Bajo dicho escenario, la dirección original asignada al nodo 30 no se aplicaría más al nodo 30. Como tal, los paquetes de datos destinados para esa dirección del nodo 30 pueden no estar al alcance del nodo 30. El IP Móvil (Protocolo de Internet Móvil) mencionado por la IETF pretende tratar los problemas de movilidad del nodo. De acuerdo con la RFC 2002 publicada por la IETF, siempre que esté lejos de la red local 22 y con seguimiento en otra red, al nodo 30 se le asigna un "precaución de dirección" abreviado como CoA (Precaución de Dirección) . Bajo la RFC 2002, existen dos tipos de CoA, concretamente, la CoA FA (Precaución de Dirección de Agente Exterior) y CCoA (Precaución de Dirección Co-übicada) . La CoA fa es en esencia la dirección de un FA (Agente Exterior) el cual es un servidor diseñado en la red exterior donde se ubica el nodo 30. El uso de la CoA FA es aplicable en el IPv4. La CCoA es una dirección individual pero temporal asignada al nodo 30 por la red exterior. El uso de la CCoA se puede aplicar tanto en el IPv4 como en el IPv6. En cualquier caso, en cualquier momento que el nodo 30 esté en un territorio exterior, el nodo 30 debe registrar la CoA, ya sea la CoA FA o la CCoA, con su red local 22, de manera que la red local 22 siempre tiene conocimiento de los paraderos del nodo 30. Después del registro, la CoA es almacenada en el cuadro de enrutamiento mantenido por el servidor designado, denominado el HA (Agente Local) 25 de la red local 22. Tomar algunos ejemplos para ilustración. Para el caso de la CoA FA, asumir que el nodo 30 tiene seguimiento en la red exterior 26. Al momento de alcanzar el límite territorial de la red exterior 26, el nodo 30 recibe un mensaje de anuncio proveniente de la red exterior 26 informando al nodo 30 sobre su presencia en el territorio exterior. A partir del mensaje de anuncio, el nodo 30 conoce la dirección del FA 36 de la red exterior 26. El nodo 30 entonces registra la CoA FA con el HA 25 en la red local 22. Cuando el nodo 30 en la red exterior 26 envía un paquete de datos al nodo 34 en la red 24, por ejemplo, conociendo la dirección del nodo 34 en la red 24, el paquete de datos puede ser enviado directamente. Es decir, de acuerdo con el IP, en el paquete de datos, la dirección fuente puede ser establecida como la HoA del nodo 30 y la dirección de destino puede ser establecida a la dirección del nodo 34 en la red 24. La dirección del paquete de datos se muestra como la trayectoria de datos 38 en la figura 1. En lo que respecta al tráfico de datos inverso, éste no es directo. En la ruta de datos inversa, cuando el nodo 34 en la red 24 intenta enviar un paquete de datos al nodo 30, ahora en la red exterior 26, como se mencionó anteriormente, de acuerdo con el IP, tanto la dirección fuente como la dirección de' destino deben ser especificadas en el paquete de datos. En este caso, la dirección fuente es la dirección IP del nodo 34 en la red 24. En lo que respecta a la dirección de destino, sin ninguna notificación de actualización proveniente del nodo 30, el nodo 34 solo conoce la HoA del nodo 30, no la CoA FA del nodo 30. Por lo tanto, la dirección de destino se establecerá a la HoA del nodo 30. Sin embargo, debido a que la CoA FA del nodo 30 es almacenada en el cuadro de enrutamiento del HA 25 en la red local 22, cuando el paquete de datos alcanza la red local 22, el HA 25 de la red 22 encapsula el paquete de datos recibido con la CoA FA almacenada y lo envía al nodo 30 en la red exterior 26. Es decir, el paquete de datos encapsulado utiliza la CoA FA como la dirección de destino. Una vez que la red exterior 26 recibe el paquete de datos encapsulado, el FA 36 simplemente separa la CoA FA encapsulada y entrega el paquete original al nodo móvil 30. La ruta del paquete de datos se muestra como la trayectoria de datos 40 en la figura 1. También se debería apreciar que las trayectorias de datos, tal como las trayectorias 38 y 40, en realidad pasan a través de la Internet 20 muchas veces. Para propósitos de claridad a fin de no obscurecer la figura 1, las trayectorias simplemente se muestra como pasando a través de los servidores relevantes, tal como el HA 25 y el FA 36. Es decir, las trayectorias de datos 38 y 40 se muestran como trayectorias lógicas en la figura 1. Operando en la forma descrita anteriormente, el nodo móvil 30 se dice que está en comunicación con el nodo correspondiente 34 bajo el modo de tunelización IP Móvil utilizando CoA FA. En el ejemplo anterior, se dice que existe un túnel de datos entre los nodos 30 y 34 a través del HA 25 incluso cuando el nodo móvil 30 parece recibir paquetes de datos directamente desde el nodo correspondiente 90. La ventaja de utilizar el modo de tunelización es que, cuando el nodo móvil 30 se desplaza a otra red exterior, diferente a la notificación de actualización para la red local 22, no hay necesidad de que el nodo móvil 30 envíe una notificación similar al nodo correspondiente 34. Por lo tanto, los datos enviados y recibidos por el nodo correspondiente 34 aparecen como ininterrumpidos. En lo que respecta al caso de la CCoA, cuando el nodo 30 tiene seguimiento lejos de la red local 22, en lugar de solicitar una CoA FA, el nodo 30 puede solicitar una CCoA de la red exterior. Si la red 26 es una WAN que soporta tecnologías inalámbricas tal como las normas cdma2000 promulgadas por la TIA/EIA (Asociación de la Industria de Telecomunicaciones/Asociación de Industrias de Electrónica) y el 3GPP2 (Proyecto 2 de Sociedad de 3era Generación) , la CCoA puede ser solicitada y asignada remotamente por la red exterior 26 a través de un PPP (Protocolo de Punto-a-Punto entre un PDSN (Nodo de Servicio de Datos en Paquete) 41 y el nodo móvil 30, por ejemplo. El PDSN 41 es básicamente un servidor en la red 36 que provee servicio y procesa el tráfico de datos en la porción inalámbrica de la red 26. Sin embargo, a diferencia de la asignación de la CCoA por parte de la red exterior 26, el nodo 30 ejecuta todas las funciones de un agente exterior, tal como el FA 36, como se mencionó previamente. Una vez más, el nodo móvil 30 necesita registrar la CCoA con la red local 22. Por ejemplo, para corresponder con el nodo 34 en la red 24, el nodo 30 envía un paquete de datos con dos capas de direcciones. En la capa exterior, la dirección fuente se configura a la CCoA, y la dirección de destino se configura al HA 25. En la capa interior, la dirección fuente es la HoA del nodo 30 y la dirección de destino es la dirección del nodo 34 en la red exterior 24. Al momento de recibir el paquete de datos proveniente del nodo de seguimiento 30, el HA 25 separa la capa de dirección exterior y envía el paquete de datos al nodo 34 con la capa de dirección interior. La trayectoria lógica del paquete de daos se muestra como la trayectoria de datos 42 en la figura 1. En la trayectoria de datos inversa, es decir, cuando el nodo 34 envía un paquete de datos al nodo 30, el paquete de datos solo tiene una capa de dirección con la dirección fuente configurada al nodo 34 y la dirección de destino configurada a la HoA del nodo 30. Al momento de la recepción del paquete de datos, el HA 25 encapsula el paquete de datos con la CCoA como la dirección de destino y la dirección del HA 25 como la dirección fuente y envía el paquete de datos encapsulado al nodo 30. El nodo 30 ejecuta la des-encapsulación por sí mismo sin pasar por el FA 36. La dirección del paquete de datos se muestra como la trayectoria de datos 44 en la figura 1. Operando en la forma descrita anteriormente, el nodo de seguimiento 30 se dice que está en comunicación con el nodo correspondiente 34 bajo el modo de tunelización IP móvil utilizando la CCoA. Con mucha frecuencia, las comunicaciones de datos entre los nodos necesitan ser monitoreadas y controladas por diferentes motivos. Por ejemplo, cuando el nodo móvil 30 y el nodo correspondiente 34 están en una sesión VoIP (Voz sobre IP) , éste necesita tener la seguridad de que las partes participantes, el nodo móvil 30 y el nodo correspondiente 34 en este caso, están autorizados. Entre otras cosas, para cada paquete de datos, la dirección fuente, la dirección de destino, y el puerto de destino necesitan ser establecidos. Si la sesión está basada en tarifa, se tienen que poner en práctica medios de rastreo para propósito de contabilidad. Por motivos de seguridad y privacidad, es común que los paquetes de datos intercambiados entre los nodos estén encriptados. Los esquemas de encriptación para los datos en paquete bajo el modo de transporte y el modo de tunelización son diferentes. El monitoreo de los paquetes de datos encriptados entonces representa un reto especial. Incluso existe una demanda creciente de comunicaciones seguras y privadas en redes compartidas. Por consiguiente, existe la necesidad de proveer esquemas de monitoreo seguros para comunicaciones de datos en paquete con flujos de datos encriptados.
SUMARIO DE LA INVENCIÓN Por motivos de seguridad y confidencialidad, con mucha frecuencia, los flujos de datos son transmitidos de manera segura con los paquetes de datos de comunicación encriptados. En ocasiones, los flujos de datos necesitan ser monitoreados a través de un intermediario de monitoreo para el control de tráfico de datos. Los paquetes de datos encriptados incluyen SPI (índices de Parámetros Seguros) los cuales se utilizan para identificar SA (Asociaciones de Seguridad) para la desencriptación de datos. De acuerdo con una modalidad ejemplar de la invención, los nodos que buscan comunicaciones entre sí antes de establecer cualquier tráfico de datos formal, primero envían los SPI en mensajes de señalización a través del intermediario de monitoreo. Posteriormente, el intermediario de monitoreo compara los SPI de los mensajes de señalización con los SPI extraídos de los paquetes de datos. Durante el control de tráfico de datos, el intermediario de monitoreo permite el paso a los flujos de datos si se encuentran coincidencias en los " SPI. De otra forma, los flujos de datos son rechazados . Al operar en la forma en que están colocados, el intermediario de monitoreo puede entonces ejercer relativamente el control de tráfico de datos. Estas y otras características y ventajas serán aparentes para aquellos expertos en la técnica a partir de la siguiente descripción detallada, tomada junto con las figuras anexas, en donde números de referencia similares se refieren a partes similares.
BREVE DESCRIPCIÓN DE LAS FIGURAS La figura 1 es un dibujo esquemático de la conexión global de redes; La figura 2 es un dibujo esquemático que muestra una modalidad de la invención; La figura 3 es un dibujo esquemático de los diversos formatos de paquetes de datos no encriptados y encriptados . La figura 4 es un diagrama de flujo que muestra los pasos para iniciar la señalización y establecimiento de tráfico de contenido de acuerdo con la modalidad de la invención; La figura 5 es un dibujo esquemático de la circuitería de un nodo móvil configurado de acuerdo con la invención; y La figura 6 es un dibujo esquemático de la circuitería de un intermediario de monitoreo de acuerdo con la invención.
DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La siguiente descripción se presenta para permitir a aquellos expertos en la técnica hacer o utilizar la invención. En la siguiente descripción se proporcionan detalles para propósitos de explicación. Se debería apreciar que aquellos expertos en la técnica podrán percatarse que la invención se puede practicar sin el uso de estos detalles específicos. En otros casos, no se elaboran estructuras y procesos bien conocidos a fin de no oscurecer la descripción de la invención con detalles innecesarios. Por lo tanto, la presente invención no pretende quedar limitada por las modalidades mostradas, sino que se le acordará el alcance más amplio consistente con los principios y características aquí descritas. Las modalidades descritas a continuación se pueden operar de acuerdo con las normas IMS/MMD (Subsistema de Multimedia IP/Dominio de Multimedia) promulgadas por el Proyecto de Sociedad de 3era Generación (3GPP) y el Proyecto 2 de Sociedad de 3era Generación (3GPP2) . Un análisis general de los IMS/MMD se puede encontrar en los documentos publicados titulados "3rd Generation Partnership Project : Technical Specif ication Group Services and System Aspects , IP Multimedia Subsystem (IMS) , Stage 2" 3GPP TS 23.228 3rd Generation Partnership Project : Technical Specif ication Group Core Network, End-to-end Quality of Service (QoS) Signaling Flows, " 3GPP TS 29.208; y "IP Multimedia System, Stage 2" , 3GPP2 X.S0013-002 y 3GPP2 X.P0013-012. IMS se puede aplicar en una amplia variedad de normas, tal como la cdma2000, WCDMA (Acceso Múltiple por División de Código de Banda Ancha) , GPRS (Servicio de Radio de Paquete General) y otras WAN. Ahora se hace referencia a la figura 2, la cual muestra de forma esquemática una modalidad ejemplar de la invención. El sistema global generalmente queda expresado por el número de referencia 50 el cual incluye una red de estructura principal 52, tal como una intranet o la Internet. A manera de ejemplo, como se muestra en la figura 2, conectadas a la red de estructura principal 52, entre otras redes, están una HN (Red Local) 54, una FN (Red Exterior) 56, y una RN (Red Remota) 58. En la HN 54, existe un HA (Agente Local) 62 el cual asume la obligación de administrar el tráfico de datos dentro del HN 54 y también para controlar el tráfico de datos de la HN 54 para enrutamiento de entrada y salida. Si la HN 54 soporta tecnologías inalámbricas, normalmente existe una RAN (Red de Acceso de Radio) 55 instalada y conectada a un PDSN (Nodo de Servicio de Datos en Paquete) 64. Por ejemplo, si la RAN 55 opera bajo las normas cdma2000, la RAN 55 por lo regular incluye por lo menos un BSC (Controlador de Estación Base) y una pluralidad de BS (Estaciones Base) . El PDSN 64 en esencia es una compuerta de acceso entre la red de estructura principal 52 y la RAN 55. Para ejecutar las diversas funciones y características de IMS/MMD, los proveedores de servicios instalan diferentes servidores en la HN 54. Ejemplos de dichos servidores incluyen una P-CSCF (Función de Sesión de Estado de Llamada Proxi) 70, y una S-CSCF (Función de Sesión de Estado de Llamada de Servicio) 72. La descripción funcional de estos servidores se mostrará más adelante junto con la descripción operativa del sistema 50. Además de los nodos descritos anteriormente, existen otros nodos dentro de la HN 54 pero no se muestran por propósitos de claridad. Dichos nodos pueden ser computadoras de varios tipos, impresoras, y cualquier otro dispositivo que pueda ser móvil o no móvil. Mostradas en la figura 2 están la FN 56 y la RN 58 vinculadas a la red de estructura principal 52. Además, para simplicidad y facilidad de explicación, la FN 56 y la RN 58 se ilustran, de cierta forma, similares a la HN 54. Se debería apreciar que, dependiendo del uso, la FN 56 y la RN 58 pueden estar estructuradas de manera muy diferente. Por lo tanto, en este caso, la FN 56 también incluye, entre otras cosas, un FA (Agente Exterior) 66, una RAN 76, un PDSN 68, una P-CSCF 71, y una PCRF (Función de Reglas de Policía y Carga) 75. De manera similar, la RN 58 también incluye, entre otras cosas, un PDSN 78, una P-CSCF 80, una S-CSCF 82, y una PCRF 84. Se debería apreciar que en la figura 2, el FA 66 y el PDSN 68 en la FN 56 se muestran como entidades separadas. Con mucha frecuencia, el FA 66 y el PDSN 68 están integrados como una unidad. En el sistema 50, existe un MN (Nodo Móvil) 60 el cual originalmente está registrado con el HA 62 en la HN 54 con una HoA (Dirección Local) . El MN 60 tiene la capacidad para migrar a otras redes exteriores, tal como la FN 56, y puede tener acceso a la red de estructura principal 52 a través de la FN 56 u otras redes bajo el IP Móvil (Protocolo de Internet Móvil) . El MN 60 en la práctica puede tener la forma de un PDA (Asistente Digital Personal) , una computadora portátil, o un teléfono móvil, por ejemplo. Asumir que el MN 60 está en seguimiento en la FN 56. En este ejemplo específico, asumir que el usuario del MN 60 desea tener una sesión de conferencia de video con otro usuario operando un CN (Nodo Correspondiente) 90 en la RN 58. El nodo 90 puede ser móvil o no móvil. Al momento de alcanzar el territorio de la FN 56, el MN 60 puede adquirir la dirección del FA 66 a través de anuncio por parte de la FN 56. El MN 60 entonces registra la CoA FA con el HA 62 en la HN 54 de manera que el HA 62 puede mantener un registro de la ubicación del MN 60. Como una alternativa, el MN 60 puede solicitar una CCoA del FA 66. El MN 60 entonces registra también la CCoA con el HA 62 por el mismo motivo, es decir, para permitir al HA 62 mantener contacto con el MN 60. Antes de establecer cualquier tráfico de comunicación, • el MN 60 necesita pasar a través de un proceso de señalización. Para lograr este objetivo, el MN 60 envía un mensaje de invitación al CN 90 a través de un intermediario, tal como se describirá a continuación. De manera similar, el CN 90 necesita reconocer el mensaje de invitación con un proceso de señalización de respuesta. En este ejemplo, el MN 60 utiliza la HoA originalmente asignada por el HA 62 en la HN 54 para registro con la S-CSCF 72 en la HN 54 para el acceso de la red SIP (Protocolo de Iniciación de Sesión) la cual incluye la S-CSCF 72 en la HN 54. El MN 60 entonces envía un mensaje de INVITACIÓN SIP a la P-CSCF 70 en la HN 54. Se debería apreciar que en operación real, al igual que con todo el otro tráfico de datos, el mensaje de IVITACION SIP primero pasa a través de la RAN 76, el PDSN 68, el FA 66, la red de estructura principal 52, y el HA 62 antes de alcanzar el P-CSCF 70. Además, tal como se conoce en la técnica, el tráfico de datos es en la forma de señales eléctricas a través de una portadora de señal que se desplaza a través del sistema 50.
Para propósitos de claridad, en una forma similarmente mostrada anteriormente, el tráfico de datos se ilustra simplemente como trayectorias lógicas. Es decir, en la siguiente descripción, a menos que específicamente se enfatice, solo se describen las trayectorias lógicas del tráfico de datos. Además se debería apreciar que el MN 60 puede enviar el mensaje de INVITACIÓN SIP a la P-CSCF 71 en la FN 56 para iniciar la sesión de conferencia como una alternativa. Es decir, en lugar de utilizar la red SIP en la HN 54 para señalización, el MN 60 puede utilizar la red SIP en la FN 56 como una alternativa. Para consistencia y claridad en la explicación, en la siguiente descripción, la red SIP en la HN 54 se utiliza para el proceso de señalización. Suponer que la sesión de conferencia de video pretende ser una sesión privada. Como tal, los paquetes de datos intercambiados entre el MN 60 y el CN 90 son encriptados, como resulta común en la práctica. En esta coyuntura, esto ayuda a hacer una digresión que explica la seguridad de IP en general y además las diferencias entre un paquete de datos encriptado y no encriptado en particular. Bajo el IP, los paquetes de datos son encriptados de acuerdo con IPSec (Seguridad de Protocolo de Internet) , el cual es un protocolo de seguridad que tiene varias normas referentes a la confidencialidad, integridad y autenticación de datos entre partes participantes. Detalles del IPSec se pueden encontrar en RFC 2401, 2412 y 2451. De acuerdo con el IPSec, los nodos de comunicación que buscan comunicaciones aseguradas primero necesitan, por anticipado, llegar a un acuerdo respecto a un conjunto de parámetros de seguridad, denominado (SA (Asociación de Seguridad) . La SA puede incluir, entre otras cosas, un algoritmo de encriptación, un algoritmo de autenticación, una clave de encriptación, y una clave de autenticación. Por lo tanto, después del acuerdo, la SA es almacenada en cada uno de los nodos que solicita la sesión de comunicación asegurada. La SA común puede ser identificada por un SPI (índice de Parámetro de Seguridad) transmitido junto con cada paquete de datos. Durante cualquier sesión de comunicación asegurada, el nodo de recepción siempre puede extraer el SPI de cualquier paquete de datos y recurrir a la SA almacenada para desencriptación. La SA con el algoritmo y la clave de encriptación común permite al nodo de recepción desencriptar los paquetes de datos encriptados. En la figura 3 se muestran diferentes formas de paquetes de datos encriptados y no encriptados. El número de referencia 100 denota un paquete de datos previamente encriptado común. El paquete de datos 100 incluye un encabezado IP 102 el cual almacena información tal como las direcciones fuente y de destino del paquete 100, conforme a lo requerido bajo el IP. Junto al encabezado IP 102 está un encabezado de capa 4 104. La capa 4 es una capa de transporte la cual incluye información referente a si el paquete de datos 100 está bajo el TCP (Protocolo de Control de Transporte) o el UDP (Protocolo de Datagrama de Usuario) . Detalles del TCP y el UDP se pueden encontrar en RFC 793 y RFC 768, respectivamente. Por lo tanto, el encabezado de Capa 4 104 identifica, mínimo, si el paquete 100 es un paquete TCP o un paquete UDP, y además incluye las ubicaciones de los puertos fuente y de destino. La información referente al puerto de destino es esencial para que el intermediario de monitoreo lleve a cabo su obligación de monitorear los datos. Junto al encabezado de Capa 4 104 están los datos de carga útil 106 portados por el paquete de datos 100. El número de referencia 108 denota un paquete de datos encriptado bajo el modo de transporte. Las porciones sombreadas indican las áreas de datos bajo encriptación. El paquete de datos encriptado 108 también incluye un encabezado IP 102 igual a aquel del paquete no encriptado 100. Sin embargo, el encabezado de Capa 4 104A y los datos de carga útil 106A del paquete de datos encriptado 100 son las contrapartes encriptadas del encabezado de Capa 4 104 correspondiente y los datos de carga útil 106 del paquete de datos no encriptado 100. En el paquete de datos 108, colocado entre el encabezado de IP 102 y el encabezado de Capa 4 104A está un encabezado ESP (Carga Util de Seguridad de Encapsulación) 110. El encabezado ESP 110 incluye el SPI que se puede utilizar para identificar la SA con el algoritmo previamente arreglado para desencriptar el paquete de datos 108, tal como se mencionó previamente. Al final del paquete de datos 108 está un indicador de fin ESP 112 y datos de autenticación 114. El indicador de fin ESP 112, entre otras cosas,, incluye información que identifica el siguiente encabezado ESP. Si se lleva a cabo cualquier protocolo de autenticación, el segmento de datos de autenticación 114 tiene información para dicho propósito. El número de referencia 118 designa un paquete de datos encriptado bajo el modo de tunelización, de acuerdo con el IPSec. En el paquete de datos 118, básicamente, el paquete previamente encriptado 100 es encriptado y encapsulado en el paquete 118. Por lo tanto, el encabezado IP 102B de segmentos de paquete, el encabezado de Capa 4 104B, y los datos de carga útil 106B contienen información de los segmentos correspondientes del paquete original 110. Sin embargo, el encabezado IP frontal 102 del paquete 118 tiene contenido diferente de aquel del encabezado IP 102B.
Por ejemplo, el encabezado IP 120 incluye las direcciones de capa exterior del túnel, y el encabezado IP 102B tiene las direcciones de la capa interior del túnel. Junto al encabezado 1P 120 está el encabezado ESP 110 el cual es esencialmente el mismo que aquel del encabezado ESP 110 en el paquete de datos 108. Es decir, el encabezado ESP 110 incluye el SPI para identificar la SA con un algoritmo previamente arreglado para desencriptar el paquete de datos 118. El indicador de fin ESP 112 y los datos de autenticación 114 son sustancialmente los mismos que aquellos del paquete 108. Se debería apreciar que bajo el IPv6, después del Encabezado IP 102 en cada uno de los paquetes 108, 100 y 118, existe un encabezado opcional denominado una "etiqueta de flujo" que incluye información que identifica si el paquete de datos 108, 100 ó 118 está en un paquete de audio o un paquete de video. El encabezado de la etiqueta de flujo no se muestra en la figura 3 por motivos de brevedad y concisión. Como se puede apreciar en la figura 3, en el paquete de datos 108 está encriptado el encabezado de Capa 4 104A. Como tal, el intermediario de monitoreo no puede identificar si el paquete 108 es un paquete TCP o un paquete UDP, por ejemplo. Sobre todo, el encabezado de Capa 4 104A incluye información referente a si el puerto de destino tampoco está fácilmente disponible. Cualquier intermediario de monitoreo, sin información sobre el puerto de destino, no puede realizar cualquier monitoreo de datos. De manera similar, en el paquete de datos 118, además de la encriptación del encabezado de Capa 4 104B, el encabezado IP 102B también está encriptado. Sin la información del encabezado IP 104B, el intermediario de monitoreo además no conoce las direcciones de capa interior del paquete de datos 118, por ejemplo. En consecuencia, el paquete de datos 118 posiblemente no pueda ser monitoreado. Como se mencionó anteriormente, incorporado en cada uno de los paquetes de datos 108 y 118 está el SPI, el cual se puede utilizar para identificar la SA asociada para la encriptación de datos. Sin embargo, en esta modalidad, el SPI también se utiliza de manera implícita para identificar y corresponder con un puerto de destino particular asociado con el paquete de datos encriptado 108 ó 118. De manera más específica, en el paquete de datos encriptado 108 ó 118, cada SPI en el encabezado ESP respectivo 110 corresponde a un flujo de datos particular el cual, a su vez, se diferencia por el hecho de saber si el flujo es un flujo de audio o un flujo de video, por ejemplo, y además por la identificación del puerto de destino. De acuerdo con la modalidad ejemplar, el SPI es enviado directamente y por último llega al intermediario de monitoreo durante el proceso de señalización inicial. Durante el monítoreo de datos, el intermediario de monitoreo simplemente tiene que comparar el SPI obtenido durante el proceso de señalización con el SPI correspondiente extraído del paquete de datos encriptado. Si se encuentra una coincidencia, el flujo particular, es decir, si el flujo es audio o video junto con el puerto de destino del paquete de datos encriptado, se puede entonces identificar de manera implícita. Ahora se vuelve a hacer referencia a la figura 2.
Para iniciar la sesión de conferencia de video, el MN 60 envía un mensaje de INVITACIÓN SIP a través de la red SIP, tal como se describió previamente. El mensaje de INVITACIÓN SIP incluye una porción de descripción denominada el SDP (Protocolo de Descripción de Sesión) el cual en esencia describe los requerimientos básicos para la ejecución adecuada de la sesión de conferencia de video solicitada. Por ejemplo, incluido en el SDP están la dirección IP y el número de puerto del MN 60, y la especificación codee para la sesión. De manera más importante, en esta modalidad, el SDP incluye los SPI que van a ser utilizados por el MN 60. En este ejemplo, en el cual la sesión de comunicación es una sesión de conferencia de video, se necesitan dos SPI, es decir, uno para el flujo de video y el otro para el flujo de audio. Como se mencionó anteriormente, cada SPI corresponde a un flujo de datos particular el cual, a su vez, se asocia de manera única con un puerto de destino particular. Para reiterar, durante el monitoreo de datos, si el SPI incluido en el mensaje de INVITACIÓN SIP coincide con el SPI extraído de los paquetes de datos de tráfico portador, el puerto de destino se puede identificar de manera implícita. El tráfico portador es el flujo de contendido de señales de audio y video de la sesión de conferencia. Con la identificación de la dirección del puerto de destino, junto con las direcciones fuente y de destino, el intermediario de monitoreo de datos puede cumplir con su obligación de monitorear datos . Volviendo ahora a la figura 2, la P-CSCF 70 en la HN 54 es un nodo que asume la obligación de la gestión de sesión de llamada. Al momento de la recepción del mensaje de INVITACIÓN SIP, la P-CSCF 70 reenvía el mensaje de INVITACIÓN SIP a la S-CSCF 72 en la HN 54. La C-CSCF 72 a su vez envía el mensaje de INVITACIÓN SIP a la RN 58 para solicitud de aceptación. Al momento de la aprobación de la sesión por parte de la S-CSCF 72 en la HN 54 y la aceptación de la sesión de conferencia por parte del CN 90 en la RN 58, la P-CSCF 70 entonces envía la información relacionada con la política, tal como las reglas de cargos, QoS (Calidad de Servicio) autorizada y los identificadores de flujo a la PCRF 74 en la HN 54. Al mismo tiempo, es decir, después de la aceptación por parte del CN 90, el MN 60 envía una TFT (Plantilla de Flujo de Tráfico), junto con el QoS solicitado al PDSN 68 en la FN 56 para establecer el tráfico portador. El PDSN 68 entonces solicita la misma información relacionada con la política como se mencionó anteriormente, es decir, el QoS autorizado, las reglas de cargos, y los identificadores de flujo para la sesión de conferencia de la PCRF 75 en la FN 56. La PCRF 75 entonces trasmite la solicitud a la PCRF 74 en la HN 54 y obtiene los parámetros antes mencionados para los flujos. Cualesquiera parámetros otorgados por la PCRF 75 tienen que estar en conformidad con algunas políticas obligatorias. Dichas políticas pueden incluir reglas dictadas bajo las normas IMS/MMD, acuerdos específicos entre redes, tal como acuerdos entre la HN 54 y la FN 56 relacionadas con el manejo del tráfico portador, políticas particulares a una red, tal como las políticas únicas solo para la FN 56. Si la sesión de conferencia solicitada está basada en tarifas, las políticas pueden incluir algunos procedimientos de rastreo para propósitos de contabilidad. Sobre todo, se bloqueará el tráfico no autorizado. La ejecución de las políticas se denomina SBBC (Control de Portador Basado en el Servicio) bajo las normas IMS/MMD. Los detalles operativos del SBBC se pueden encontrar en un documento titulado, "3GGP2 MMD Service Based Bearer Control Document , Work in Progress," 3GPP2 X.P0013-012. Las descripciones del SDP se pueden encontrar en el documento titulado "IP Multimedia Cali Control Protocol Based on SIP and SDP", Etapa 3: 3GPP2 X.S0013-0004. La PCRF 75 en la FN 56 es instalada para la decisión de todas las políticas impuestas. En el proceso de decisión, la PCRF 75 es interpuesta entre la PCRF 74 en la HN 54 y el PDSN 68 en la FN 56. Además, existe una interfaz Ty 92 interpuesta entre el PDSN 68 y la PCRF 75. También existe una interfaz TX 94 colocada entre la PCRF 74 y la P-CSCF 70 en la HN 54, como se muestra en la figura 2. Las interfaces Ty y Tx antes mencionadas se utilizan para el control de política entre la sesión de conferencia y el tráfico portador. Detalles de las interfaces Ty y Tx se pueden encontrar en los documentos, 3GPP TS 23.107 publicado por 3GPP, y 3GPP2 X.P0013-012 publicado por 3GPP2. Volviendo ahora a la figura 2, los parámetros de sesión solicitados estipulados en el mensaje de INVITACIÓN SIP, si se autoriza, se pasan al PDSN 68 desde la P-CSCF 70 a través de la PCRF 74 en la HN 54 y la PCRF 75 en la FN 56. En esta modalidad, se asume que el CN 90 tiene una CCoA, la cual es asignada por la RN 58. Por lo tanto, al momento de la recepción de los mensajes de INVITACIÓN SIP, el CN 90 responden de regreso con un mensaje SIP 200 OK. El mensaje SIP 200 OK básicamente reafirma los parámetros del mensaje de INVITACIÓN SIP original. Además, en esta modalidad, el CN 90 también incluye en el SDP del mensaje SIP 200 OK el SPI que va a ser utilizado por el CN 90 para el tráfico portador. El SIP 200 OK sigue la misma trayectoria de datos que el mensaje de INVITACIÓN SIP, pero en el orden inverso. El MN 60 entonces confirma la recepción del mensaje SIP 200 OK enviando un mensaje de acuse (ACK) de regreso a lo largo de la misma trayectoria de datos que el mensaje de INVITACIÓN SIP. El tráfico portador queda, por lo tanto, listo para ser establecido por el PDSN 68 en la FN 56, de acuerdo con los parámetros autorizados tal como se estipula en el mensaje de INVITACIÓN SIP. Como se mencionó anteriormente, bajo las normas IMS/MMD, el tráfico portador necesita ser monitoreado y controlado a través del SBBC por la red. En este ejemplo, el PDSN 68 dirigido por la PCRF 75 en la FN 56 asume la obligación de ejecutar el SBBC para que se ajuste a las políticas según lo mencionado anteriormente. Durante la ejecución del SBBC, cada paquete de datos necesita ser protegido antes de permitirle el paso. Debido a que los paquetes de daos del tráfico portador están encriptados, como se mencionó anteriormente, cierta información esencial tal como la identificación del puerto de destino, no puede quedar disponible de manera fácil y conveniente. En esta modalidad, como se mencionó anteriormente, el PDSN 68 tiene información de los SPI del flujo de datos con bastante tiempo de anticipación proveniente del mensaje de INVITACIÓN SIP y el mensaje SIP 200 OK durante los procesos iniciales de señalización. En operación, el PDSN 68 extrae la información esencial necesaria para el SBBC de cada paquete de datos, tal como las direcciones fuente y de destino y el SPI que de manera implícita identifica el flujo de datos, y si la información coincide con la información correspondiente obtenida del proceso de señalización, el paquete de datos se deja pasar como parte de la ejecución del SBBC. Por otra parte, si no existe una coincidencia, el paquete de datos se dice que falló en el SBBC y se abandona. La operación en la forma anteriormente descrita, es decir, con los SPI incluidos en el SDP de los mensajes de señalización, el PDSN 68 puede hacer valer el SBBC para tráfico de datos encriptado de la sesión de conferencia de video solicitada. La ejecución del SBBC es continua hasta que finaliza la sesión entre el MN 60 y el CN 90. El proceso, tal como se mencionó anteriormente, se muestra en el diagrama de flujo de la figura 4. La figura 5 muestra de manera esquemática la parte de la ejecución de hardware de un aparato de nodo móvil reconocido por el número de referencia 121 de acuerdo con la invención. El aparato 121 se puede construir e incorporar en varios dispositivos, tal como una computadora personal, un PDA, o un teléfono celular, por ejemplo. El aparato 121 comprende un enlace de datos central 122 que vincula varios circuitos entre sí. Los circuitos incluyen un CPU (Unidad de Procesamiento Central) o un controlador 124, un circuito receptor 126, un circuito transmisor 128, y una unidad de memoria 130. Los circuitos receptor y transmisor 126 y 128 se pueden conectar a un circuito RF (Radio Frecuencia) pero no se muestra en la figura. El circuito receptor 126 procesa y almacena en memoria intermedia señales recibidas antes de enviarlas al enlace de datos 122. Por otra parte, el circuito transmisor 128 procesa y almacena en memoria intermedia los datos del enlace de datos 122 antes de enviarlos fuera del dispositivo 121. El CPU/controlador 124 ejecuta la función de gestión de datos del enlace de datos 122 y además la función de procesamiento general de datos, incluyendo la ejecución del contenido de instrucciones de la unidad de memoria 130. La unidad de memoria 130 incluye un conjunto de instrucciones generalmente indicadas por el número de 5 referencia 131. En esta modalidad, las instrucciones incluyen, entre otras cosas, porciones tal como el Cliente IP Móvil 132 y el cliente SIP 134. El cliente SIP 134 incluye el conjunto de instrucciones de acuerdo con la invención, tal como se describió previamente. El cliente IP 10 Móvil 132 incluye el conjunto de instrucciones para permitir al aparato 121 operar bajo el IP y el IP Móvil, tal como adquirir varios tipos de direcciones para los diversos modos de comunicaciones, también como se describió anteriormente . 15 En esta modalidad, la unidad de memoria 130 es un circuito RAM (Memoria de Acceso Aleatorio) . Las porciones de instrucciones ejemplares 132 y 134 son rutinas o módulos de software. La unidad de memoria 130 se puede vincular a otro circuito de memoria (que no se muestra) la cual puede 20. ser de tipo volátil o no volátil. Como una alternativa, la unidad de memoria 130 puede estar hecha de otros tipos de circuito, tal como una EEPROM (Memoria de Solo Lectura Programable Eléctricamente Borrable) , una EPROM (Memoria de Solo Lectura Programable Borrable) , una ROM (Memoria de 25 Solo Lectura) , un disco magnético, un disco óptico, y otras bien conocidas en la técnica. La figura 6 muestra de manera esquemática la parte de la ejecución de hardware del aparato PDSN, de acuerdo con la invención, y queda indicada por el número de referencia 140. El aparato PDSN 140 comprende un enlace de datos central 142 que vincula varios circuitos entre sí. Los circuitos incluyen un CPU (Unidad de Procesamiento Central) o un controlador 144, un circuito receptor 146, un circuito transmisor 148, una unidad de almacenamiento de base de datos 149, y una unidad de memoria 150. Los circuitos de recepción y transmisión 146 y 148 se pueden conectar a un enlace de datos de red (que no se muestra) donde el aparato PDSN 140 está vinculado al mismo. El circuito receptor 146 procesa y almacena en memoria intermedia las señales recibidas provenientes del enlace de datos de red (que no - se muestra) antes de enlutarlas al enlace de datos interno 142. El circuito transmisor 148 procesa y almacena en memoria intermedia los datos provenientes del enlace de datos 142 antes de enviarlos fuera del aparato 140. El CPU/controlador 144 ejecuta la obligación de gestión de datos del enlace de datos 142 y para la función del procesamiento de datos general, incluyendo la ejecución del contenido de instrucciones de la unidad de memoria 150. La unidad de almacenamiento de base de datos 149 almacena registros de datos, tal como las SA con sus diversos parámetros. La unidad de memoria 150 incluye un conjunto de instrucciones generalmente indicadas por el número de referencia 154. En esta modalidad, las instrucciones incluyen porciones, entre otras cosas, una función PDSN 156 y una función SBBC 158. La unidad de memoria puede estar hecha de tipos de circuito de memoria, tal como se mencionó anteriormente y no se repetirán otra vez. Las funciones PDSN y SBBC 156 y 158 incluyen los conjuntos de instrucciones de acuerdo con la invención, tal como se describió anteriormente. Finalmente, en la modalidad se describe el MN 60 operando bajo la IP Móvil utilizando la CCoA. Como se mencionó anteriormente, el MN 60 puede operar bien bajo otros modos de comunicaciones y asumir otros tipos de direcciones. Por ejemplo, una ejemplificación de las muchas alternativas, el MN 60 puede utilizar la CoA FA y establecer comunicación con el CN 90 bajo el modo de tunelización IP móvil. Además, en la modalidad se describe la encriptación tal como se aplica bidireccionalmente entre el MN 60 y el CN 90. También es posible que la encriptación de datos se aplique de una forma solamente, en lugar de una forma bidireccional. Además, tal como se describió, el nodo 60 se muestra como un seguimiento de dispositivo móvil a una red exterior. Se debería entender que el nodo 60 puede ser estacionario. Además, cualesquiera bloques lógicos, circuitos y pasos de algoritmo descritos en relación con las modalidades se pueden ejecutar en hardware, software, microprogramación cableada o combinaciones de los mismos. Aquellos expertos en la técnica entenderán que estos y otros cambios en la forma y detalle se pueden realizar en los mismos sin apartarse del alcance y espíritu de la invención.

Claims (29)

NOVEDAD DE LA INVENCIÓN Habiendo descrito el presente invento, se considera como una novedad y, por lo tanto, se reclama como prioridad lo contenido en las siguientes: REIVINDICACIONES
1.- Un método para una sesión de comunicación con paquetes de datos encriptados a través de un intermediario de monitoreo, que comprende: proveer un índice que identifique un proceso de encriptación; incluir dicho índice en un mensaje de señalización; y señalizar para dicha sesión de comunicación mediante el envío de dicho mensaje de señalización que tiene dicho índice a través de dicho intermediario de monitoreo.
2.- El método de conformidad con la reivindicación 1, caracterizado porque dicha señalización para dicha sesión de comunicación incluye responder a través de dicho intermediario de monitoreo a una invitación a dicha sesión de comunicación.
3. - El método de conformidad con la reivindicación 1, que además comprende proveer dicho índice en dichos paquetes de datos de dicha sesión de comunicación .
4. - Un método para una sesión de comunicación con paquetes de datos encriptados a través de un intermediario de monitoreo en un sistema de comunicación soportado por el IP (Protocolo de Internet), que comprende: proveer un SPI (índice de Parámetro de Seguridad) que identifique una SA (Asociación de Seguridad) ; incluir dicho SPI en un mensaje de señalización seleccionado de un grupo que consiste de un mensaje de INVITACIÓN SIP y un mensaje SIP 200 OK; y señalizar para dicha sesión de comunicación mediante el envío de dicho mensaje de señalización que tiene dicho SPI a través de dicho intermediario de monitoreo para permitir a dicho intermediario de monitoreo utilizar dicho SPI para el monitoreo de datos en paquete.
5.- Un método para monitorear una sesión de comunicación con paquetes de datos encriptados, que comprende: recibir un primer índice el cual identifica un proceso de desencriptación desde un mensaje de señalización; recibir un segundo índice desde dichos paquetes de datos de dicha sesión de comunicación; y ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la comparación de dicho primer y segundo índices.
6.- El método de conformidad con la reivindicación 5, que además comprende permitir que dichos paquetes de datos de dicha sesión de comunicación pasen cuando dicha comparación de dicho primer y segundo índices resulte en una coincidencia de comparación y rechazar el paso de dichos paquetes de datos de dicha sesión de comunicación cuando dicha comparación de dicho primer y segundo índices resulta en una comparación que no coincide.
7. - El método de conformidad con la reivindicación 5, caracterizado porque dicho mensaje de señalización es un primer mensaje de señalización, dicho método además incluye recibir dicho primer índice de un segundo mensaje de señalización.
8. - El método de conformidad con la reivindicación 7, caracterizado porque dicho primer mensaje de señalización es un mensaje de invitación para dicha sesión de comunicación, y dicho segundo mensaje de señalización es un mensaje de respuesta para dicho mensaje de invitación.
9.- Un método para monitorear una sesión de comunicación con paquetes de datos encriptados en un sistema de comunicación soportado por el IP (Protocolo de Internet), que comprende: recibir un primer SPI (índice de Parámetro de Seguridad) desde un mensaje de señalización proveniente de un grupo que consiste de un mensaje de INVITACIÓN SIP y un mensaje SIP 200 OK; recibir un segundo SPI desde dichos paquetes de datos de dicha sesión de comunicación; y ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la inclusión de la comparación de dicho primer SPI y dicho segundo SPI.
10.- Un aparato para una sesión de comunicación con paquetes de datos encriptados a través de un intermediario de monitoreo, que comprende: medios para proveer un índice que identifique un proceso de encriptación; medios para incluir dicho índice en un mensaje de señalización; y medios para enviar dicho mensaje de señalización que tiene dicho índice a través de dicho intermediario de monitoreo.
11.- El aparato de conformidad con la reivindicación 10, caracterizado porque dicho mensaje de señalización es un mensaje de invitación, dicho aparato además incluye medios para comprender dicho índice en un mensaje de respuesta en respuesta a dicho mensaje de invitación.
12.- El aparato de conformidad con la reivindicación 10, que además comprende medios para incluir índice en dichos paquetes de datos encriptados de dicha sesión de comunicación.
13.- Un aparato para una sesión de comunicación con paquetes de datos encriptados a través de un intermediario de monitoreo en un sistema de comunicación soportado por el IP (Protocolo de Internet), que comprende: medios para proveer un SPI (índice de Parámetro de Seguridad) que identifique una SA (Asociación de Seguridad) ; medios para incluir dicho SPI en un mensaje de señalización seleccionado de un grupo que consiste de un mensaje de INVITACIÓN SIP y un mensaje SIP 200 OK; y medios para enviar dicho mensaje de señalización que tiene dicho SPI a través de dicho intermediario de monitoreo para permitir a dicho intermediario de monitoreo utilizar dicho índice para el monitoreo de datos en paquete.
14.- Un aparato para monitorear una sesión de comunicación con paquetes de datos encriptados, que comprende : medios para recibir un primer índice el cual identifica un proceso de desencriptación desde un mensaje de señalización; medios para recibir un segundo índice desde dichos paquetes de datos de dicha sesión de comunicación; y medios para ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la comparación de dicho primer y segundo índices.
15.- El aparato de conformidad con la reivindicación 14, que además comprende medios para permitir que dichos paquetes de datos de dicha sesión de comunicación pasen cuando dicha comparación de dicho primer y segundo índices resulte en una coincidencia de comparación y medios para rechazar el paso de dichos paquetes de datos de dicha sesión de comunicación cuando dicha comparación de dicho primer y segundo índices resulta en una comparación que no coincide.
16.- El aparato de conformidad con la reivindicación 14, caracterizado porque dicho mensaje de señalización es un primer mensaje de señalización, dicho método además incluye medios para recibir dicho primer índice de un segundo mensaje de señalización.
17.- El aparato de conformidad con la reivindicación 16, caracterizado porque dicho primer mensaje de señalización es un mensaje de invitación para dicha sesión de comunicación de datos en paquete , y dicho segundo mensaje de señalización es un mensaje de respuesta para dicho mensaje de invitación.
18.- Un aparato para monitorear datos en paquete encriptados de una sesión de comunicación con paquetes de datos encriptados en un sistema de comunicación soportado por el IP (Protocolo de Internet), que comprende: medios para recibir un primer SPI (índice de Parámetro de Seguridad) desde un mensaje de señalización seleccionado de un grupo que consiste de un mensaje de INVITACIÓN SIP y un mensaje SIP 200 OK; medios para recibir un segundo SPI desde dichos paquetes de datos de dicha sesión de comunicación; y medios para ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la inclusión de la comparación de dicho primer SPI y dicho segundo SPI.
19.- Un aparato para una sesión de comunicación con paquetes de datos encriptados a través de un intermediario de monitoreo, que comprende: una unidad de memoria que tiene instrucciones legibles por computadora para proveer un índice que identifique un proceso de encriptación, incluyendo dicho índice en un mensaje de señalización, y enviar dicho mensaje de señalización que tiene dicho índice a través de dicho intermediario de monitoreo; y un circuito de procesador acoplado a dicha unidad de memoria para procesamiento de dichas instrucciones legibles por computadora.
20.- El aparato de conformidad con la reivindicación 19, caracterizado porque dicho mensaje de señalización es un mensaje de invitación, dicho aparato además incluye instrucciones legibles por computadora para incluir dicho índice en un mensaje de respuesta en respuesta a dicho mensaje de invitación.
21.- El aparato de conformidad con la reivindicación 19, que además comprende instrucciones legibles por computadora para incluir dicho índice en dichos paquetes de datos de dicha sesión de comunicación.
22.- Un aparato para una sesión de comunicación con paquetes de datos encriptados a través de un intermediario de monitoreo en un sistema de comunicación soportado por el IP (Protocolo de Internet), que comprende: una unidad de memoria que tiene instrucciones legibles por computadora para proveer un SPI (índice de Parámetro de Seguridad) que identifica una SA (Asociación de Seguridad), para incluir dicho SPI en un mensaje de señalización seleccionado de un grupo que consiste de un mensaje de INVITACIÓN SIP y un mensaje SIP 200 OK, y enviar dicho mensaje de señalización que tiene dicho SPI a través de dicho intermediario de monitoreo para permitir a dicho intermediario de monitoreo utilizar dicho índice para el monitoreo de datos en paquete; y un circuito de procesador acoplado a dicha unidad de memoria para el procesamiento de dichas instrucciones legibles por computadora.
23.- Un aparato para monitorear una sesión de comunicación con paquetes de datos encriptados, que comprende : una unidad de memoria que tiene instrucciones legibles por computadora para recibir un primer índice el cual identifica un proceso de desencriptación de un mensaje de señalización, recibir un segundo índice de dichos paquetes de datos de dicha sesión de comunicación, y ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la comparación de dicho primer y segundo índices; y un circuito de procesador acoplado a dicha unidad de memoria para procesar dichas instrucciones legibles por computadora.
24.- El aparato de conformidad con la reivindicación 23, que además comprende instrucciones legibles por computadora para permitir el paso de dichos paquetes de datos de dicha sesión de comunicación cuando dicha comparación de dicho primer y segundo índices resulta en una coincidencia de comparación y medios para rechazar el paso de dicho paquete de datos de dicha sesión de comunicación cuando dicha comparación de dicho primer y segundo índices resulta en una comparación que no coincide.
25.- El aparato de conformidad con la reivindicación 23, caracterizado porque dicho mensaje de señalización es un primer mensaje de señalización, dicho aparato además comprende instrucciones legibles por computadora para recibir dicho primer índice desde un segundo mensaje de señalización.
26.- El aparato de conformidad con la reivindicación 25, caracterizado porque dicho primer mensaje de señalización es un mensaje de invitación para dicha sesión de comunicación, y dicho segundo mensaje de señalización es un mensaje de respuesta para dicho mensaje de invitación.
27.- Un aparato para monitorear una sesión de comunicación con paquetes de datos encriptados en un sistema de comunicación soportado por el IP (Protocolo de Internet), que comprende: una unidad de memoria que tiene instrucciones legibles por computadora para recibir un primer SPI (índice de Parámetro de Seguridad) proveniente de un mensaje de señalización seleccionado de un grupo que consiste de un mensaje de INVITACIÓN SIP y un mensaje SIP 200 OK, y recibir un segundo SPI desde dichos paquetes de datos de dicha sesión de comunicación, y ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la comparación de dicho primer SPI y dicho segundo SPI; y un circuito de procesador acoplado a dicha unidad de memoria para el procesamiento de dichas instrucciones legibles por computadora.
28.- Señales eléctricas transmitidas a través de una portadora de señales en un sistema de comunicación, dichas señales eléctricas comprenden instrucciones legibles por computadora para: proveer un índice que identifique un proceso de encriptación; incluir dicho índice en un mensaje de señalización; y señalizar para dicha sesión de comunicación mediante el envío de dicho mensaje de señalización que tiene dicho índice a través de dicho intermediario de monitoreo.
29.- Señales eléctricas transmitidas a través de una portadora de señales en un sistema de comunicación, dichas señales eléctricas comprenden instrucciones legibles por computadora para: recibir un primer índice el cual identifica un proceso de desencriptación desde un mensaje de señalización; recibir un segundo índice desde paquetes de datos de dicha sesión de comunicación; y ejecutar un conjunto de políticas en dicha sesión de comunicación mediante la comparación de dicho primer y segundo índices.
MX2007000588A 2004-07-15 2005-07-14 Control portador de flujos de datos encriptados en comunicaciones de datos en paquete. MX2007000588A (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US58866404P 2004-07-15 2004-07-15
US11/180,131 US8042170B2 (en) 2004-07-15 2005-07-12 Bearer control of encrypted data flows in packet data communications
PCT/US2005/025150 WO2006020014A1 (en) 2004-07-15 2005-07-14 Bearer control of encrypted data flows in packet data communications

Publications (1)

Publication Number Publication Date
MX2007000588A true MX2007000588A (es) 2007-03-30

Family

ID=35169843

Family Applications (1)

Application Number Title Priority Date Filing Date
MX2007000588A MX2007000588A (es) 2004-07-15 2005-07-14 Control portador de flujos de datos encriptados en comunicaciones de datos en paquete.

Country Status (8)

Country Link
US (1) US8042170B2 (es)
EP (1) EP1766496B1 (es)
JP (2) JP5112864B2 (es)
KR (3) KR100899960B1 (es)
BR (1) BRPI0513342A (es)
CA (1) CA2573917A1 (es)
MX (1) MX2007000588A (es)
WO (1) WO2006020014A1 (es)

Families Citing this family (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8265060B2 (en) 2004-07-15 2012-09-11 Qualcomm, Incorporated Packet data filtering
US8042170B2 (en) 2004-07-15 2011-10-18 Qualcomm Incorporated Bearer control of encrypted data flows in packet data communications
US20070067387A1 (en) * 2005-09-19 2007-03-22 Cisco Technology, Inc. Conferencing system and method for temporary blocking / restoring of individual participants
US8635450B2 (en) * 2005-12-28 2014-01-21 Intel Corporation IP encapsulation with exposed classifiers
KR100738567B1 (ko) * 2006-02-01 2007-07-11 삼성전자주식회사 동적 네트워크 보안 시스템 및 그 제어방법
KR100656481B1 (ko) * 2006-02-03 2006-12-11 삼성전자주식회사 동적 네트워크 보안 시스템 및 그 제어방법
US8583929B2 (en) * 2006-05-26 2013-11-12 Alcatel Lucent Encryption method for secure packet transmission
JP4864797B2 (ja) 2006-09-11 2012-02-01 Kddi株式会社 P−cscf高速ハンドオフシステム及びp−cscf高速ハンドオフ方法
JP4866802B2 (ja) * 2006-09-11 2012-02-01 Kddi株式会社 セキュリティ最適化システムおよびセキュリティ最適化方法
US7899161B2 (en) 2006-10-11 2011-03-01 Cisco Technology, Inc. Voicemail messaging with dynamic content
US20080109517A1 (en) * 2006-11-08 2008-05-08 Cisco Technology, Inc. Scheduling a conference in situations where a particular invitee is unavailable
US8116236B2 (en) * 2007-01-04 2012-02-14 Cisco Technology, Inc. Audio conferencing utilizing packets with unencrypted power level information
US7720919B2 (en) * 2007-02-27 2010-05-18 Cisco Technology, Inc. Automatic restriction of reply emails
US8706091B2 (en) * 2007-03-23 2014-04-22 Cisco Technology, Inc. Attachment of rich content to a unified message left as a voicemail
KR101409456B1 (ko) * 2007-06-12 2014-06-24 삼성전자주식회사 IP converged 시스템에서의 패킷 처리 방법 및그 시스템
US8620654B2 (en) * 2007-07-20 2013-12-31 Cisco Technology, Inc. Text oriented, user-friendly editing of a voicemail message
US8295306B2 (en) * 2007-08-28 2012-10-23 Cisco Technologies, Inc. Layer-4 transparent secure transport protocol for end-to-end application protection
CN101505296A (zh) * 2008-02-05 2009-08-12 华为技术有限公司 隧道业务数据流的控制方法和装置
US8270404B2 (en) * 2008-02-13 2012-09-18 International Business Machines Corporation System, method, and computer program product for improved distribution of data
US20090300207A1 (en) * 2008-06-02 2009-12-03 Qualcomm Incorporated Pcc enhancements for ciphering support
US10116493B2 (en) 2014-11-21 2018-10-30 Cisco Technology, Inc. Recovering from virtual port channel peer failure
KR102240727B1 (ko) * 2015-01-28 2021-04-15 삼성전자주식회사 통신 시스템에서 보안 연계를 설정하기 위한 장치 및 방법
US10333828B2 (en) 2016-05-31 2019-06-25 Cisco Technology, Inc. Bidirectional multicasting over virtual port channel
US11509501B2 (en) * 2016-07-20 2022-11-22 Cisco Technology, Inc. Automatic port verification and policy application for rogue devices
US10193750B2 (en) 2016-09-07 2019-01-29 Cisco Technology, Inc. Managing virtual port channel switch peers from software-defined network controller
US10367752B2 (en) 2016-11-18 2019-07-30 International Business Machines Corporation Data packet management in a memory constrained environment
US10547509B2 (en) 2017-06-19 2020-01-28 Cisco Technology, Inc. Validation of a virtual port channel (VPC) endpoint in the network fabric
EP3422657A1 (de) * 2017-06-26 2019-01-02 Siemens Aktiengesellschaft Verfahren und sicherheits-steuerungseinrichtungen zum senden und empfangen kryptographisch geschützter netzwerkpakete

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5081678A (en) * 1989-06-28 1992-01-14 Digital Equipment Corporation Method for utilizing an encrypted key as a key identifier in a data packet in a computer network
JP3597756B2 (ja) * 2000-06-09 2004-12-08 日本電信電話株式会社 ネットワークアドレス変換装置およびvpnクライアント多重化システム
GB2371186A (en) 2001-01-11 2002-07-17 Marconi Comm Ltd Checking packets
KR100510434B1 (ko) 2001-04-09 2005-08-26 니폰덴신뎅와 가부시키가이샤 Ofdm신호전달 시스템, ofdm신호 송신장치 및ofdm신호 수신장치
US7496748B2 (en) 2001-07-23 2009-02-24 Itt Manufacturing Enterprises Method for establishing a security association between two or more computers communicating via an interconnected computer network
DE10142959A1 (de) 2001-09-03 2003-04-03 Siemens Ag Verfahren, System und Rechner zum Aushandeln einer Sicherheitsbeziehung auf der Anwendungsschicht
US7580424B2 (en) 2001-09-25 2009-08-25 Hughes Network System, Llc System and method for providing real-time and non-real-time services over a communications system
US20030097584A1 (en) * 2001-11-20 2003-05-22 Nokia Corporation SIP-level confidentiality protection
FI115687B (fi) 2002-04-09 2005-06-15 Nokia Corp Pakettidatan siirtäminen langattomaan päätelaitteeseen
US7277455B2 (en) 2002-06-10 2007-10-02 Qualcomm Incorporated Packet flow processing in a communication system
CN1675909B (zh) 2002-06-10 2011-01-26 高通股份有限公司 通信系统中的分组流处理
JP4426443B2 (ja) * 2002-06-13 2010-03-03 エヌヴィディア コーポレイション ネットワークを経て通信するための改善セキュリティ方法及び装置
US7120930B2 (en) * 2002-06-13 2006-10-10 Nvidia Corporation Method and apparatus for control of security protocol negotiation
US20040109459A1 (en) 2002-07-25 2004-06-10 Lila Madour Packet filter provisioning to a packet data access node
US7562393B2 (en) 2002-10-21 2009-07-14 Alcatel-Lucent Usa Inc. Mobility access gateway
GB0226289D0 (en) 2002-11-11 2002-12-18 Orange Personal Comm Serv Ltd Telecommunications
JP2004180155A (ja) 2002-11-28 2004-06-24 Ntt Docomo Inc 通信制御装置、ファイアウォール装置、通信制御システム、及び、データ通信方法
US7539186B2 (en) 2003-03-31 2009-05-26 Motorola, Inc. Packet filtering for emergency service access in a packet data network communication system
US7668145B2 (en) 2003-12-22 2010-02-23 Nokia Corporation Method to support mobile IP mobility in 3GPP networks with SIP established communications
JP3944182B2 (ja) 2004-03-31 2007-07-11 キヤノン株式会社 セキュリティ通信方法
US8042170B2 (en) 2004-07-15 2011-10-18 Qualcomm Incorporated Bearer control of encrypted data flows in packet data communications

Also Published As

Publication number Publication date
JP2011091833A (ja) 2011-05-06
EP1766496A1 (en) 2007-03-28
KR100948524B1 (ko) 2010-03-23
KR20080113092A (ko) 2008-12-26
CA2573917A1 (en) 2006-02-23
JP5112864B2 (ja) 2013-01-09
US8042170B2 (en) 2011-10-18
EP1766496B1 (en) 2012-05-30
KR20090125842A (ko) 2009-12-07
KR100899960B1 (ko) 2009-05-28
WO2006020014A1 (en) 2006-02-23
KR100996405B1 (ko) 2010-11-24
KR20070030328A (ko) 2007-03-15
JP2008507209A (ja) 2008-03-06
BRPI0513342A (pt) 2008-05-06
US20060078120A1 (en) 2006-04-13

Similar Documents

Publication Publication Date Title
MX2007000588A (es) Control portador de flujos de datos encriptados en comunicaciones de datos en paquete.
US8190739B2 (en) Method for lawfully intercepting communication IP packets exchanged between terminals
US9025771B2 (en) Security optimization for IMS/MMD architecture
US20050102514A1 (en) Method, apparatus and system for pre-establishing secure communication channels
US20040255156A1 (en) System and method for dynamically creating at least one pinhole in a firewall
EP2028812B1 (en) Methods, apparatuses, system, and related computer program product for user equipment access
MX2007000570A (es) Filtracion de datos de paquete.
EP3192224B1 (en) Establishment of a secure connection for a communication session
US20060288423A1 (en) Method, system and network elements for establishing media protection over networks
JP2009284492A (ja) 通信ネットワーク間のセキュアな通信を提供する方法及びシステム
US20100299446A1 (en) Method and apparatus for controlling service data flows transmitted in a tunnel
TW201108829A (en) Fixed mobile convergence (FMC) with PDIF and SIP gateway
TWI378694B (en) Bearer control of encrypted data flows in packet data communications
Orrblad Alternatives to MIKEY/SRTP to secure VoIP
Diab et al. VPN solution for securing voice over third generation networks

Legal Events

Date Code Title Description
FG Grant or registration