ES2716657T3 - Un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red - Google Patents
Un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red Download PDFInfo
- Publication number
- ES2716657T3 ES2716657T3 ES16382153T ES16382153T ES2716657T3 ES 2716657 T3 ES2716657 T3 ES 2716657T3 ES 16382153 T ES16382153 T ES 16382153T ES 16382153 T ES16382153 T ES 16382153T ES 2716657 T3 ES2716657 T3 ES 2716657T3
- Authority
- ES
- Spain
- Prior art keywords
- network
- data packet
- service
- cryptographic
- architecture
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic 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
- H04L9/3236—Cryptographic 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 using cryptographic hash functions
- H04L9/3239—Cryptographic 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 using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/31—Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- 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/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
- H04L9/0637—Modes of operation, e.g. cipher block chaining [CBC], electronic codebook [ECB] or Galois/counter mode [GCM]
-
- 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/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
-
- 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/32—Cryptographic 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
- H04L9/3247—Cryptographic 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 involving digital signatures
- H04L9/3252—Cryptographic 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 involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
-
- 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/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
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)
Description
DESCRIPCIÓN
Un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red
Campo técnico
La presente invención se refiere, en general, al campo de Concatenación de Función de Servicio. En particular, la invención se refiere a un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red usando procedimientos criptográficos.
Antecedentes de la invención
Existe una necesidad de plataformas tecnológicas más flexibles y fáciles de desarrollar, con la capacidad de soportar migraciones desde entornos físicos a unos virtuales, y para el fin de desplegar modelos para funciones de servicio no estrechamente acopladas a la topología de red y recursos físicos. De esta manera sería posible hacerlo alejado de la naturaleza estática de los modelos de despliegue actuales que limitan la introducción de nuevos servicios o modificar los existentes y/o las funciones de servicio.
Para tratar los problemas anteriores, un mecanismo de arquitectura de red posible que facilita la definición y la creación de instancias de un conjunto ordenado de funciones de servicio y dirección posterior de tráfico a través de ellas es la arquitectura de Concatenación de Función de Servicio (SFC) [1]. Otras posibilidades incluyen puntos de unión como se usa en las plataformas en la nube del estado de la técnica [2].
La arquitectura de SFC se establece en independencia topológica de la topología de reenvío subyacente. En esta, como puede observarse en la Figura 1, los paquetes de datos se clasifican en el nodo de entrada para manejar mediante el conjunto requerido de Funciones de Servicio (SF) y a continuación se reenvían a través de ese conjunto ordenado de funciones para procesamiento mediante cada función a su vez. Como resultado de este procesamiento los paquetes tal vez se reclasifiquen.
La arquitectura de SFC incluye Reenviadores de Función de Servicio (SFF), como pueden observarse en la Figura 2, responsables de reenviar paquetes de datos recibidos desde la red a una o más SF asociadas con un SFF dado. El tráfico desde las SF eventualmente vuelve al mismo SFF, que es responsable de inyectar el tráfico de vuelta en la red.
El orden implicado puede no ser una progresión lineal ya que la arquitectura permite a las SFC copiar más de una rama, y permite también casos donde hay flexibilidad en el orden en el que se aplican las funciones de servicio. La entrega de servicios de extremo a extremo a menudo requiere diversas SF que incluyen SF de red tradicional (por ejemplo, cortafuegos y balanceadores de carga de servidor, entre otros), así como características específicas de la aplicación tales como manipulación de encabezamiento de HTTP. Las SF pueden entregarse en el contexto de un usuario aislado (por ejemplo, un arrendatario) o compartirse entre muchos usuarios o grupos de usuarios.
Los modelos de despliegue actual para las SF están a menudo estrechamente acoplados a la topología de red y recursos físicos, dando como resultado por lo tanto despliegues relativamente rígidos y estáticos. La naturaleza estática de tales despliegues reduce enormemente y limita, en muchos casos, la capacidad de un operador para introducir nuevos servicios o modificar los existentes y/o las SF. Adicionalmente existe un efecto en cascada: cambiar uno o más elementos de una cadena de SF a menudo afecta a otros elementos en la cadena y/o los elementos de red usados para construir la cadena.
Este problema es particularmente grave en entornos de servicio elásticos que requieren creación, destrucción o movimiento relativamente rápidos de SF físicas o virtuales o elementos de red. Adicionalmente, el paso a plataformas virtuales requiere un modelo de inserción de servicio ágil que soporte entrega de servicio elástica y muy granular, modificación a posteriori y el movimiento de las SF y cargas de trabajo de aplicación en la red existente. El modelo de inserción de servicio debe retener también las políticas de red y servicio y la capacidad para unir fácilmente política de servicio a información granular tal como por estado de abonado.
Los despliegues de servicio de red no de SFC están acoplados a menudo a la topología de red, ya sea física, virtualizada o una híbrida de las dos. Tal dependencia impone restricciones en la entrega de servicio y limita la escala, capacidad y redundancia a través de los recursos de red, pero por otro lado permite a los operadores de redes y usuarios de servicio verificar la aplicación efectiva de los servicios requeridos para flujos de paquetes
verificando la topología.
A medida que se requieren más funciones de servicio -- a menudo con ordenación estricta -- son necesarios cambios de topología "delante" y "detrás" de cada SF, dando como resultado cambios de red y configuración de dispositivo complejos. En tales topologías, todo el tráfico, se necesite aplicar una SF o no, a menudo pasa a través del mismo orden estricto. Pero, de nuevo, esto proporciona un aseguramiento estricto de la aplicación de función. La naturaleza dinámica de la arquitectura de SFC, que desacopla el servicio de las dependencias de la topología, soporta una configuración muy flexible y escalable de cómo se aplican los servicios a flujos de paquetes, pero limita la capacidad de una verificación efectiva de la aplicación real del procesamiento requerido tanto a flujos como a paquetes individuales. Existen casos de uso donde se requiere una fuerte evidencia de que cada paquete pasa a través de una trayectoria particular en una cadena, en particular en entornos sensibles a seguridad, y cada vez que se han de aplicar políticas de alta prioridad. Un caso arquetípico son servicios de red aplicados en entornos financieros.
Puesto que la práctica actual para proporcionar una fuerte evidencia de aplicación de SF en estos casos de uso requiere verificación física de concatenación de anfitrión y evidencia de topología directa, estos requisitos invalidan virtualmente (o al menos limitan seriamente) la aplicación de SFC en estos entornos.
Por lo tanto son necesarias más tecnologías para asegurar la aplicación efectiva de una cadena de las SF a los flujos de paquetes de datos que provienen desde una red para asegurar un orden dado de recorrido de las SF y para proporcionar fuerte evidencia de que los paquetes de datos han recorrido la trayectoria correcta en la cadena. El documento US20150333930, de 19 de noviembre de 2015 (2015-11-19), describe recursos computacionales distribuidos que pueden ser organizados en una plataforma de servicios para proporcionar determinados servicios con valor añadido - tal como inspección profunda de paquetes, transcodificación, intercepción legal -, o de otra manera utilizando un modelo de encadenamiento de la función de servicio
Referencias:
[1] [RFC7665] J. Halpern, Ed. y C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, octubre de 2015, <http://www.rfc-editor.org/info/rfc7665>.
[2] Centina Systems, "NFV and SDN Assurance; Monitor and optimize virtual networks comprehensively", http://www.centinasystems.com/solutions/nfv-and-sdn-assurance/
Descripción de la invención
Para este fin, las realizaciones de la presente invención proporcionan un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular en una red, en el que dicha red está basada en una cadena de Funciones de Servicio (SF) individuales que están compuestas para implementar servicios de red. El método de una manera característica comprende: la asignación, en un nodo de entrada de una arquitectura de red, a al menos un paquete de datos recibido mediante dicho nodo de entrada desde la red, de una etiqueta criptográfica única; el procesamiento de la etiqueta criptográfica única asignada por medio de una función criptográfica específica para cada Función de Servicio (SF) particular; y la verificación final, en cualquier punto dado de la arquitectura de red, preferentemente en un nodo de salida de la misma, de la etiqueta criptográfica única procesada por medio de aplicar una función de verificación criptográfica.
De acuerdo con el método propuesto, dicha función de verificación criptográfica está compuesta mediante las funciones inversas de las funciones criptográficas asociadas a las SF recorridas mediante el paquete o paquetes de datos.
De acuerdo con la invención, las funciones criptográficas específicas para cada SF que pueden usarse pueden incluir: un Algoritmo de Firma Digital (DSA), un algoritmo SHA256, un Algoritmo de Firma Digital de Curva Elíptica (ECDSA), un algoritmo secp256k1, entre otros. Las diferentes SF pueden usar la misma o diferentes funciones criptográficas. Es decir, una SF dada puede usar un DSA mientras que la siguiente SF en la trayectoria puede usar un algoritmo secp256k1, o como alternativa, ambas SF en la trayectoria pueden usar la misma función criptográfica. De acuerdo con una realización preferida, dicha arquitectura de red comprende una arquitectura de Cadena de Función de Servicio (SFC). En este caso particular, dicho procesamiento de la etiqueta criptográfica única asignada puede realizarse mediante cualquiera de los Reenviadores de Función de Servicio (SFF) o mediante las SF de la trayectoria particular cuando el paquete de datos se envía a cada SF, o como alternativa a cada intermediario de SF.
De acuerdo con una realización, la etiqueta criptográfica única asignada a un paquete de datos está incluida en un Encabezamiento de Función de Red (NSH) del paquete de datos. El NSH tiene una clave única que está asociada con cada SF. Preferentemente, la asignación de la etiqueta criptográfica única en el NSH se hace teniendo en cuenta un formato tipo-longitud-valor, TLV.
De acuerdo con una realización, se proporciona una plataforma de Concatenación de Bloques para asegurar la secuencia de procesamiento para el paquete o paquetes de datos recibidos desde la red. En este caso particular, cada transacción que entra en la arquitectura de red (por ejemplo la arquitectura de SFC) se usa para crear un bloque de la plataforma de Concatenación de Bloques que se agrega en la cadena y se replica en una arquitectura entre iguales descentralizada que comprende una pluralidad de nodos, en el que cada Trayectoria de Función de Servicio (SFP) de la arquitectura de red comprende un nodo.
De acuerdo con otra realización, la etiqueta criptográfica única no es parte de unos metadatos del paquete o paquetes de datos recibidos desde la red, en este caso, el método propuesto comprende proporcionar una plataforma de Concatenación de Bloques separada del plano de servicio de la arquitectura de red para asegurar la secuencia de procesamiento para el paquete o paquetes de datos, teniendo dichos metadatos una clave que está relacionada con un bloque correspondiente de la plataforma de Concatenación de Bloques.
Por lo tanto, la presente invención garantiza la secuencia correcta de procesamiento de paquete o paquetes de datos mediante una trayectoria de función de servicio, y de esta manera puede aprovechar la flexibilidad operativa y de gestión adicional de la arquitectura de red, reduciendo complejidad de las operaciones y el mantenimiento en plataformas de servicio de red avanzadas. Adicionalmente, la presente invención contribuye a mejorar la escalabilidad y reutilización de estas plataformas, con respecto a soluciones específicas basadas en modelos físicos.
Además, la presente invención garantiza la aplicación eficaz de las SF en una trayectoria de acuerdo con una arquitectura de red específica (preferentemente la arquitectura SFC), asegurando un orden dado de recorrido de las SF, con un nivel de aseguramiento equivalente (o incluso superior a) una verificación física de concatenación de anfitrión.
Además, la presente invención también posibilita maneras más potentes para gestionar plataformas de servicio de red virtualizadas con un flujo interno garantizado (u orden de ejecución de SF), y hace la SFC aplicable en casos donde esta ejecución garantizada se requiere estrictamente.
Breve descripción de los dibujos
Las anteriores y otras ventajas y características se entenderán más completamente a partir de la siguiente descripción detallada de las realizaciones, con referencia a las figuras adjuntas, que deben considerarse de una manera ilustrativa y no limitante, en las que:
La Figura 1 ilustra el flujo de tráfico básico para la arquitectura de SFC.
La Figura 2 ilustra la secuencia de procesamiento para paquetes de datos mediante los SFF.
La Figura 3 ilustra un flujo de un paquete de datos en la arquitectura de SFC para asegurar la secuencia de procesamiento de acuerdo con una realización preferida de la presente invención.
La Figura 4 ilustra un flujo de un paquete de datos en la arquitectura de SFC con aseguramiento de secuencia usando SFF de acuerdo con una realización de la presente invención.
La Figura 5 ilustra un flujo de un paquete de datos en la arquitectura de SFC con aseguramiento de secuencia usando las SF y/o Intermediarios de acuerdo con una realización de la presente invención.
Las Figuras 6a-6c ilustran el procesamiento de los paquetes de datos de la realización de la Figura 5 de acuerdo con el tipo de SF o el Intermediario respectivo. La Figura 6a ilustra el caso particular para una SF que es sensible a SFC y sensible a criptografía; La Figura 6b ilustra el caso particular para una SF que es sensible a SFC y no es sensible a criptografía; y la Figura 6c ilustra el caso particular para una SF que no es sensible a SFC y no es sensible a criptografía.
La Figura 7 ilustra una realización del método propuesto en el que se usa una plataforma de Concatenación de Bloques para asegurar la secuencia de procesamiento para paquetes de datos, en el que cada Trayectoria de
Función de Servicio (SFP) tiene un nodo que contiene la plataforma de Concatenación de Bloques.
La Figura 8 ilustra una realización del método propuesto en el que la etiqueta criptográfica única asignada no es parte de los metadatos del paquete de datos.
Descripción detallada de la invención y de realizaciones preferidas
De acuerdo con la invención, pueden usarse los siguientes elementos/entidades:
Cadena de Función de Servicio (SFC): define un conjunto ordenado de funciones de servicio abstractas y restricciones de ordenación que deben aplicarse a paquetes de datos y flujos seleccionados como resultado de la clasificación. Un ejemplo de una función de servicio abstracta es "un cortafuegos".
Función de Servicio (SF): una función de red que es responsable de tratamiento específico de paquetes de datos recibidos. Una SF puede actuar en diversas capas de una pila de protocolo (por ejemplo, en la capa de red u otras capas de OSI). Como un elemento lógico, una SF puede realizarse como un elemento virtual o embeberse en un elemento de red físico. Una o más Funciones de Servicio (SF) pueden embeberse en el mismo elemento de red. Una SF puede ser sensible a encapsulación de SFC (es decir, recibe y actúa sobre información en la encapsulación de SFC) o no sensible (caso en el que, los datos reenviados a la SF no contienen la encapsulación de SFC). Esto se hace referencia en las diferentes figuras de la invención como "sensible a SFC" y "no sensible a SFC", respectivamente. Una SF puede incluir: cortafuegos, DPI, NAT, función de Enriquecimiento de Encabezamiento de HTTP, optimizador de TCP, balanceador de carga, IDS, IPS, etc.
Encapsulación de SFC: la encapsulación de SFC proporciona, como mínimo, identificación de SFP, y se usa mediante las funciones sensibles a SFC, tal como las SF de SFF y sensibles a SFC. La encapsulación de SFC no se usa para reenvío de paquetes de red. Además de identificación de SFP, la encapsulación de SFC lleva metadatos que incluyen información de contexto del plano de datos.
Encabezamiento de Servicio de Red (NSH): una técnica para encapsulación de SFC definida mediante un encabezamiento común que codifica la identificación de SFP y metadatos usando preferentemente el formato TLV. Se define mediante el IETF I-D draft-ietf-sfc-nsh.
Intermediario SFC: elimina e inserta encapsulación de SFC en beneficio de una función de servicio no sensible a SFC. Los intermediarios de SFC son elementos lógicos.
Reenviador de Función de Servicio (SFF): un SFF es responsable de reenviar tráfico a una o más SF conectadas de acuerdo con información llevada en la Encapsulación de SFC, así como manejar tráfico que vuelve desde la SF. Adicionalmente, un SFF es responsable de entregar tráfico a un clasificador cuando sea necesario y se soporte, transportar tráfico a otro SFF (en el mismo o diferente tipo de solapamiento), y terminar la Trayectoria de Función de Servicio (SFP).
La Figura 3 muestra una realización preferida del método propuesto para el caso particular en el que la arquitectura de red es una arquitectura de Concatenación de Función de Servicio (SFC). De acuerdo con esta realización preferida, en primer lugar, los paquetes de datos desde una red se reciben mediante un nodo de entrada de la arquitectura de SFC para realizar la clasificación inicial, por lo que los paquetes se amplían con los metadatos apropiados, que incluyen la identificación de la Trayectoria de Función de Servicio (SFP) asignada que estos paquetes de datos deben seguir. Los Reenviadores de Función de Servicio (SFF) son responsables de reenviar los paquetes de datos recibidos a una o más Funciones de Servicio (SF) asociadas a los SFF particulares, aplicando los metadatos de SFC para los paquetes procesados. Finalmente, el método propuesto asegura el recorrido de paquetes de datos correcto a través de esa trayectoria particular en la cadena de servicio de red basada en SFC aplicando una función de verificación en el extremo de la trayectoria de SFC.
La presente invención proporciona dos opciones para asegurar la secuencia de procesamiento de paquetes de datos, una primera opción usando los SFF, y una segunda opción usando los diferentes tipos de Sf y/o el Intermediario correspondiente (cuando esto se aplique).
La Figura 4 ilustra una realización del método propuesto para recorrido de cadena de servicio de red asegurado usando los SFF. En el flujo de paquetes de datos el método propuesto asegura la secuencia de procesamiento para paquetes de datos usando una etiqueta criptográfica única, que se asigna a cada paquete de datos que proviene desde la red en el nodo de entrada, y que se actualiza (es decir, procesa) mediante cada SFF en la trayectoria cuando se envía a cada SF (o como alternativa, a cada intermediario de SF). Preferentemente, la actualización se
realiza por medio de una función criptográfica que incluye, pero sin limitación, un DSA, un SHA256, un ECDSA, y/o un secp256k1. En este caso particular, el recorrido de trayectoria se consigue mediante un nodo de salida de la arquitectura de SFC que ejecuta una función de verificación en la etiqueta criptográfica única asignada inicialmente mediante el nodo de entrada. La función de verificación comprende la ejecución mediante dicho nodo de salida de una función de verificación criptográfica que es la función inversa de la función o funciones criptográficas previamente usadas.
La función de verificación se implementa preferentemente en la salida de la última SF en la trayectoria. Sin embargo, de acuerdo con la invención, el proceso de verificación puede implementarse en la salida de cualquier SFF en la trayectoria.
La Figura 5 ilustra otra realización del método propuesto para recorrido de cadena de servicio de red asegurado usando SF y/o Intermediario de SFC. La realización de la Figura 5 se diferencia de la realización de la Figura 4 en que la etiqueta criptográfica única asignada inicialmente en el nodo de entrada se actualiza mediante cada SF, o como alternativa mediante un Intermediario correspondiente (cuando esto se aplica, es decir la SF no es sensible a SFC). Se ha de observar que el mismo flujo puede estar presente en una trayectoria de SFC cuando se requiere más de un SFF.
De acuerdo con el tipo de SF (o el respectivo Intermediario) el procesamiento puede ser como se describe a continuación en las Figuras 6a-6c.
Con referencia a la Figura 6a, se ilustra en la misma el procesamiento para el caso de una SF que es sensible a SFC y sensible a criptografía. En este caso, el paquete de datos completo se reenvía desde el SFF a la SF, en la que procesa la etiqueta criptográfica única (CT en las figuras) antes de devolver el paquete de datos al SFF, que genera una nueva firma (CT' en las figuras) que prueba que el paquete de datos ha pasado a través de esta SF específica. Es decir, CT' es la etiqueta criptográfica única cuando el paquete de datos ha atravesado una respectiva SF.
Con referencia a la Figura 6b, se ilustra en la misma el procesamiento para el caso de una SF que es sensible a SFC y no es sensible a criptografía. En este caso, cuando el paquete de datos se reenvía a la SF, en primer lugar un Intermediario de Criptografía elimina la etiqueta criptográfica única asignada, este nuevo paquete de datos se reenvía a la SF y a continuación se devuelve al Intermediario de Criptografía para actualizar (es decir, procesar) la etiqueta criptográfica única asignada, que prueba que el paquete de datos ha pasado a través de esta SF específica. Con referencia a la Figura 6c, se ilustra en la misma el procesamiento para el caso de una SF que no es sensible a SFC y no es sensible a criptografía. En este caso, la SF requiere dos intermediarios, uno de ellos que trata con metadatos de SFC y el otro con la etiqueta criptográfica única asignada, para el procesamiento del paquete de datos a través del SFC.
De acuerdo con una realización, la etiqueta criptográfica única se asigna en el Encabezamiento de Servicio de Red (NSH), (H como se denomina en las diferentes figuras), extendiendo por lo tanto la extensión normal del NSH. La etiqueta criptográfica de cada paquete de datos se obtiene a partir del contenido de paquete de datos y de los metadatos y una clave única que está asociada con cada SF en la trayectoria. La etiqueta criptográfica puede implementarse como un encabezamiento de contexto usando el formato TLV.
Por lo que, de acuerdo con dicha realización, el NSH comprenderá la siguiente información:
Tabla 1: NSH Extendido
Con referencia ahora a la Figura 7, esta figura ilustra otra realización del método propuesto en el que se usa una plataforma de Concatenación de Bloques para asegurar la secuencia de procesamiento para paquetes de datos. Cada transacción, activada mediante un paquete de datos que entra en la Arquitectura de SFC, se usa para crear un bloque de la plataforma de Concatenación de Bloques y este consiste en un encabezamiento (CT), es decir la etiqueta criptográfica única, que enlaza el bloque anterior y proporciona integridad para la plataforma de Concatenación de Bloques y un cuerpo (contenido de paquete de datos y metadatos) que contiene un registro de transacciones que se verificaron durante la creación de bloques.
Cada bloque se agrega en la cadena y se replica en una arquitectura entre pares descentralizada con nodos que están asociados con una SFP (tiene al menos un SFF y una SF), usando una plataforma de aplicaciones transaccionales que establece confianza, responsabilidad y transparencia mientras agiliza procesos empresariales y proporciona un contrato inteligente. Las transacciones necesitan autenticarse, y la criptografía es fundamental para estos procesos. Los pares de protocolo validan y cometen transacciones para alcanzar consenso.
Con referencia ahora a la Figura 8, esta figura ilustra otra realización del método propuesto en el que la etiqueta criptográfica única asignada no es parte de los metadatos del paquete de datos. Se proporciona una plataforma de Concatenación de Bloques separada de un plano de servicio de la arquitectura de SFC para asegurar la secuencia de procesamiento de paquetes de datos. Para este escenario los metadatos de paquetes de datos tienen una clave que está conectada con el bloque correspondiente.
Incluso aunque las realizaciones anteriores se han descrito para el caso de usar una arquitectura de SFC, el método propuesto, de acuerdo con las realizaciones alternativas, en este caso no ilustradas, puede implementar también otras arquitecturas de red tales como plataformas en la nube.
El alcance de la presente invención se define en el siguiente conjunto de reivindicaciones.
Claims (7)
1. Un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red, en el que dicha red está basada en una cadena de Funciones de Servicio, SF, individuales que están compuestas para implementar Servicios de Red, NS, estando el método caracterizado porque comprende:
- asignar, en cada nodo de entrada de una arquitectura de red, a al menos un paquete de datos recibido mediante dicho nodo de entrada desde la red, una etiqueta criptográfica única;
- procesar dicha etiqueta criptográfica única asignada usando una función criptográfica específica para cada Función de Servicio, SF; y
- verificar, en un punto dado de la arquitectura de red, dicha etiqueta criptográfica única procesada aplicando una función de verificación criptográfica, estando compuesta dicha función de verificación criptográfica mediante las funciones inversas de las funciones criptográficas asociadas con las SF recorridas mediante el al menos un paquete de datos.
2. El método de la reivindicación 1, en el que la etiqueta criptográfica única está asignada en un Encabezamiento de Función de Red, NSH, de dicho al menos un paquete de datos recibido, teniendo el NSH una clave única que está asociada con cada SF.
3. El método de la reivindicación 2, que comprende asignar la etiqueta criptográfica única teniendo en cuenta un formato tipo-longitud-valor, TLV.
4. El método de la reivindicación 1, en el que se proporciona una plataforma de Concatenación de Bloques para asegurar la secuencia de procesamiento para dicho al menos un paquete de datos recibido, en el que cada transacción activada mediante el al menos un paquete de datos que entra en la arquitectura de red se usa para crear un bloque de la plataforma de Concatenación de Bloques que se agrega en la cadena y se replica en una arquitectura entre iguales descentralizada con una pluralidad de nodos, en el que cada Trayectoria de Función de Servicio, SFP, de la arquitectura de red comprende un nodo.
5. El método de la reivindicación 1, en el que la etiqueta criptográfica única no es parte de un metadato del al menos un paquete de datos recibido, y el método comprende proporcionar una plataforma de Concatenación de Bloques separada de un plano de servicio de la arquitectura de red para asegurar la secuencia de procesamiento para el al menos un paquete de datos recibido, teniendo dichos metadatos una clave que está relacionada con un bloque correspondiente de la plataforma de Concatenación de Bloques.
6. El método de la reivindicación 1, en el que el punto dado es un nodo de salida de la arquitectura de red.
7. El método de cualquiera de las reivindicaciones anteriores, en el que la arquitectura de red comprende una arquitectura de Cadena de Función de Servicio, SFC.
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP16382153.1A EP3229418B1 (en) | 2016-04-07 | 2016-04-07 | A method to assure correct data packet traversal through a particular path of a network |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2716657T3 true ES2716657T3 (es) | 2019-06-13 |
Family
ID=55809058
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES16382153T Active ES2716657T3 (es) | 2016-04-07 | 2016-04-07 | Un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red |
Country Status (3)
Country | Link |
---|---|
US (1) | US10396993B2 (es) |
EP (1) | EP3229418B1 (es) |
ES (1) | ES2716657T3 (es) |
Families Citing this family (57)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9225638B2 (en) | 2013-05-09 | 2015-12-29 | Vmware, Inc. | Method and system for service switching using service tags |
US9755898B2 (en) | 2014-09-30 | 2017-09-05 | Nicira, Inc. | Elastically managing a service node group |
US9774537B2 (en) | 2014-09-30 | 2017-09-26 | Nicira, Inc. | Dynamically adjusting load balancing |
US10516568B2 (en) | 2014-09-30 | 2019-12-24 | Nicira, Inc. | Controller driven reconfiguration of a multi-layered application or service model |
US10592985B2 (en) | 2015-03-02 | 2020-03-17 | Dell Products L.P. | Systems and methods for a commodity contracts market using a secure distributed transaction ledger |
US9967334B2 (en) * | 2015-03-02 | 2018-05-08 | Dell Products Lp | Computing device configuration and management using a secure decentralized transaction ledger |
US9965628B2 (en) | 2015-03-02 | 2018-05-08 | Dell Products Lp | Device reporting and protection systems and methods using a secure distributed transactional ledger |
US10484168B2 (en) | 2015-03-02 | 2019-11-19 | Dell Products L.P. | Methods and systems for obfuscating data and computations defined in a secure distributed transaction ledger |
US9967333B2 (en) * | 2015-03-02 | 2018-05-08 | Dell Products Lp | Deferred configuration or instruction execution using a secure distributed transaction ledger |
US10594743B2 (en) | 2015-04-03 | 2020-03-17 | Nicira, Inc. | Method, apparatus, and system for implementing a content switch |
US10447535B2 (en) | 2017-02-02 | 2019-10-15 | Nicira, Inc. | Consistent processing of transport node network data in a physical sharding architecture |
US10341437B2 (en) | 2017-02-08 | 2019-07-02 | Nicira, Inc. | Adding logical sharding to a distributed system with only physical sharding |
US10623264B2 (en) * | 2017-04-20 | 2020-04-14 | Cisco Technology, Inc. | Policy assurance for service chaining |
US11336572B2 (en) | 2017-05-12 | 2022-05-17 | Nicira, Inc. | Dynamic chain of service functions for processing network traffic in a virtual computing environment |
US10467132B1 (en) | 2017-05-16 | 2019-11-05 | Intuit, Inc. | Variability system and analytics for continuous reliability in cloud-based workflows |
US10528486B2 (en) * | 2017-06-30 | 2020-01-07 | Intel Corporation | Techniques for crypto-aware cache partitioning |
US10805181B2 (en) | 2017-10-29 | 2020-10-13 | Nicira, Inc. | Service operation chaining |
US11012420B2 (en) | 2017-11-15 | 2021-05-18 | Nicira, Inc. | Third-party service chaining using packet encapsulation in a flow-based forwarding element |
US10630769B2 (en) * | 2017-12-26 | 2020-04-21 | Akamai Technologies, Inc. | Distributed system of record transaction receipt handling in an overlay network |
SE541581C2 (en) * | 2018-01-05 | 2019-11-05 | Telia Co Ab | Method and a node for storage of data in a network |
US10797910B2 (en) | 2018-01-26 | 2020-10-06 | Nicira, Inc. | Specifying and utilizing paths through a network |
US10701054B2 (en) | 2018-01-31 | 2020-06-30 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing super community and community sidechains with consent management for distributed ledger technologies in a cloud based computing environment |
US11257073B2 (en) | 2018-01-31 | 2022-02-22 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing machine learning models for smart contracts using distributed ledger technologies in a cloud based computing environment |
KR102454398B1 (ko) | 2018-02-19 | 2022-10-14 | 한국전자통신연구원 | 분산형 소프트웨어 정의 네트워킹 방법 및 장치 |
US10805192B2 (en) | 2018-03-27 | 2020-10-13 | Nicira, Inc. | Detecting failure of layer 2 service using broadcast messages |
US11595250B2 (en) | 2018-09-02 | 2023-02-28 | Vmware, Inc. | Service insertion at logical network gateway |
US10944673B2 (en) | 2018-09-02 | 2021-03-09 | Vmware, Inc. | Redirection of data messages at logical network gateway |
KR20200034020A (ko) | 2018-09-12 | 2020-03-31 | 삼성전자주식회사 | 전자 장치 및 그의 제어 방법 |
WO2020053792A1 (en) | 2018-09-14 | 2020-03-19 | Telefonaktiebolaget Lm Ericsson (Publ) | Malchain detection |
US11288280B2 (en) | 2018-10-31 | 2022-03-29 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing consumer data validation, matching, and merging across tenants with optional verification prompts utilizing blockchain |
US11568437B2 (en) | 2018-10-31 | 2023-01-31 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing commerce rewards across tenants for commerce cloud customers utilizing blockchain |
US11876910B2 (en) | 2019-01-31 | 2024-01-16 | Salesforce, Inc. | Systems, methods, and apparatuses for implementing a multi tenant blockchain platform for managing Einstein platform decisions using distributed ledger technology (DLT) |
US11886421B2 (en) | 2019-01-31 | 2024-01-30 | Salesforce, Inc. | Systems, methods, and apparatuses for distributing a metadata driven application to customers and non-customers of a host organization using distributed ledger technology (DLT) |
US11783024B2 (en) | 2019-01-31 | 2023-10-10 | Salesforce, Inc. | Systems, methods, and apparatuses for protecting consumer data privacy using solid, blockchain and IPFS integration |
US11811769B2 (en) | 2019-01-31 | 2023-11-07 | Salesforce, Inc. | Systems, methods, and apparatuses for implementing a declarative, metadata driven, cryptographically verifiable multi-network (multi-tenant) shared ledger |
US11803537B2 (en) | 2019-01-31 | 2023-10-31 | Salesforce, Inc. | Systems, methods, and apparatuses for implementing an SQL query and filter mechanism for blockchain stored data using distributed ledger technology (DLT) |
US11875400B2 (en) | 2019-01-31 | 2024-01-16 | Salesforce, Inc. | Systems, methods, and apparatuses for dynamically assigning nodes to a group within blockchains based on transaction type and node intelligence using distributed ledger technology (DLT) |
US11244313B2 (en) * | 2019-01-31 | 2022-02-08 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing declarative smart actions for coins and assets transacted onto a blockchain using distributed ledger technology (DLT) |
US11899817B2 (en) | 2019-01-31 | 2024-02-13 | Salesforce, Inc. | Systems, methods, and apparatuses for storing PII information via a metadata driven blockchain using distributed and decentralized storage for sensitive user information |
US11488176B2 (en) | 2019-01-31 | 2022-11-01 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing certificates of authenticity of digital twins transacted onto a blockchain using distributed ledger technology (DLT) |
US11971874B2 (en) | 2019-01-31 | 2024-04-30 | Salesforce, Inc. | Systems, methods, and apparatuses for implementing efficient storage and validation of data and metadata within a blockchain using distributed ledger technology (DLT) |
US11824864B2 (en) | 2019-01-31 | 2023-11-21 | Salesforce, Inc. | Systems, methods, and apparatuses for implementing a declarative and metadata driven blockchain platform using distributed ledger technology (DLT) |
US11301281B2 (en) | 2019-02-22 | 2022-04-12 | Vmware, Inc. | Service control plane messaging in service data plane |
US11038771B2 (en) | 2019-04-26 | 2021-06-15 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing a metadata driven rules engine on blockchain using distributed ledger technology (DLT) |
US11880349B2 (en) | 2019-04-30 | 2024-01-23 | Salesforce, Inc. | System or method to query or search a metadata driven distributed ledger or blockchain |
US11995647B2 (en) | 2019-04-30 | 2024-05-28 | Salesforce, Inc. | System and method of providing interoperable distributed and decentralized ledgers using consensus on consensus and delegated consensus |
US11140218B2 (en) | 2019-10-30 | 2021-10-05 | Vmware, Inc. | Distributed service chain across multiple clouds |
US11283717B2 (en) | 2019-10-30 | 2022-03-22 | Vmware, Inc. | Distributed fault tolerant service chain |
US11223494B2 (en) | 2020-01-13 | 2022-01-11 | Vmware, Inc. | Service insertion for multicast traffic at boundary |
US11824970B2 (en) | 2020-01-20 | 2023-11-21 | Salesforce, Inc. | Systems, methods, and apparatuses for implementing user access controls in a metadata driven blockchain operating via distributed ledger technology (DLT) using granular access objects and ALFA/XACML visibility rules |
US11153406B2 (en) | 2020-01-20 | 2021-10-19 | Vmware, Inc. | Method of network performance visualization of service function chains |
US11659061B2 (en) | 2020-01-20 | 2023-05-23 | Vmware, Inc. | Method of adjusting service function chains to improve network performance |
US11611560B2 (en) | 2020-01-31 | 2023-03-21 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing consensus on read via a consensus on write smart contract trigger for a distributed ledger technology (DLT) platform |
US11438257B2 (en) | 2020-04-06 | 2022-09-06 | Vmware, Inc. | Generating forward and reverse direction connection-tracking records for service paths at a network edge |
US11734043B2 (en) | 2020-12-15 | 2023-08-22 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
US11611625B2 (en) | 2020-12-15 | 2023-03-21 | Vmware, Inc. | Providing stateful services in a scalable manner for machines executing on host computers |
CN113014382A (zh) * | 2021-03-01 | 2021-06-22 | 西安电子科技大学 | 基于有序聚合数字签名的服务链完整性检测方法、装置及介质 |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20150333930A1 (en) * | 2014-05-15 | 2015-11-19 | Akamai Technologies, Inc. | Dynamic service function chaining |
US9537752B2 (en) * | 2014-07-14 | 2017-01-03 | Cisco Technology, Inc. | Encoding inter-domain shared service paths |
US20170230252A1 (en) * | 2014-10-24 | 2017-08-10 | ZTE CORPORATION (CHINA) ZTE Plaza | Method and system for deep stats inspection (dsi) based smart analytics for network/service function chaining |
US9979704B2 (en) * | 2014-12-17 | 2018-05-22 | Cisco Technology, Inc. | End-to-end security for virtual private service chains |
US9621520B2 (en) * | 2015-03-19 | 2017-04-11 | Cisco Technology, Inc. | Network service packet header security |
US10211987B2 (en) * | 2015-04-27 | 2019-02-19 | Cisco Technology, Inc. | Transport mechanism for carrying in-band metadata for network path proof of transit |
US10015208B2 (en) * | 2015-06-09 | 2018-07-03 | Cisco Technology, Inc. | Single proxies in secure communication using service function chaining |
US9742790B2 (en) * | 2015-06-16 | 2017-08-22 | Intel Corporation | Technologies for secure personalization of a security monitoring virtual network function |
US10402792B2 (en) * | 2015-08-13 | 2019-09-03 | The Toronto-Dominion Bank | Systems and method for tracking enterprise events using hybrid public-private blockchain ledgers |
US11082515B2 (en) * | 2015-09-26 | 2021-08-03 | Intel Corporation | Technologies for offloading data object replication and service function chain management |
EP3394818A4 (en) * | 2015-12-21 | 2019-08-14 | Kochava Inc. | AUTOREGULATING TRANSACTION SYSTEM AND ASSOCIATED METHODS |
-
2016
- 2016-04-07 EP EP16382153.1A patent/EP3229418B1/en active Active
- 2016-04-07 ES ES16382153T patent/ES2716657T3/es active Active
-
2017
- 2017-04-06 US US15/480,659 patent/US10396993B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
EP3229418A1 (en) | 2017-10-11 |
US10396993B2 (en) | 2019-08-27 |
US20170295021A1 (en) | 2017-10-12 |
EP3229418B1 (en) | 2019-01-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2716657T3 (es) | Un método para asegurar el recorrido de paquetes de datos correcto a través de una trayectoria particular de una red | |
US10237068B2 (en) | Network path proof of transit using in-band metadata | |
US9621463B2 (en) | System and method for context aware network | |
US10382362B2 (en) | Network server having hardware-based virtual router integrated circuit for virtual networking | |
US20230171193A1 (en) | Tunnel-based service insertion in public cloud environments | |
CN108293020B (zh) | 基础设施独有的服务转发 | |
US20190068490A1 (en) | Generating Packets in a Reverse Direction of a Service Function Chain | |
US9571405B2 (en) | Metadata augmentation in a service function chain | |
US9755959B2 (en) | Dynamic service path creation | |
US20200059459A1 (en) | Secure forwarding of tenant workloads in virtual networks | |
US9178812B2 (en) | Stacking metadata contexts for service chains | |
US10250444B2 (en) | Hybrid SDN/legacy policy enforcement | |
CN107533471A (zh) | 通过禁用不必要的功能改进虚拟化应用性能 | |
CN104320350A (zh) | 用于提供基于信用的流控制的方法及系统 | |
US11165653B2 (en) | Node discovery mechanisms in a switchless network | |
ES2922924T3 (es) | Métodos y aparato para proporcionar un reenviador de tráfico a través de una red dinámica superpuesta | |
US10904132B2 (en) | Method, system, and computer program product for configuring an attribute for propagating management datagrams in a switchless network | |
WO2018195112A1 (en) | Regulation based switching system for electronic message routing | |
US10659390B2 (en) | Network interface device | |
USRE48131E1 (en) | Metadata augmentation in a service function chain | |
US10659353B2 (en) | Dynamic scriptable routing | |
ES2763842T3 (es) | Sistema y método para múltiples redes virtuales concurrentes | |
JP6475768B2 (ja) | サーバ装置及びプログラム |