Named Data Networking ( NDN ) (relacionado con content-centric networking (CCN), content-based networking, data-oriented networking o information-centric networking (ICN)) es una propuesta de arquitectura de Internet del futuro que busca abordar problemas en arquitecturas de Internet contemporáneas como IP . [1] [2] NDN tiene sus raíces en un proyecto anterior, Content-Centric Networking (CCN), que Van Jacobson presentó públicamente por primera vez en 2006. El proyecto NDN está investigando la evolución propuesta por Jacobson de la arquitectura de red centrada en el host actual IP a una arquitectura de red centrada en los datos (NDN). El objetivo declarado de este proyecto es que con un cambio conceptualmente simple, se podrían realizar implicaciones de largo alcance para cómo las personas diseñan, desarrollan, implementan y usan redes y aplicaciones. [3]
NDN tiene tres conceptos básicos que distinguen a NDN de otras arquitecturas de red. En primer lugar, las aplicaciones nombran datos y los nombres de los datos se utilizarán directamente en el reenvío de paquetes de red; las aplicaciones de consumidor solicitarían los datos deseados por su nombre, por lo que las comunicaciones en NDN están impulsadas por el consumidor. En segundo lugar, las comunicaciones NDN están protegidas de una manera centrada en los datos, en la que cada pieza de datos (llamado paquete de datos) será firmada criptográficamente por su productor y los componentes de nombre o carga útil sensibles también se pueden cifrar con fines de privacidad. De esta manera, los consumidores pueden verificar el paquete independientemente de cómo se obtenga el paquete. En tercer lugar, NDN adopta un plano de reenvío con estado en el que los reenvíos mantendrán un estado para cada solicitud de datos (llamado paquete de interés) y borrarán el estado cuando regrese un paquete de datos correspondiente. El reenvío con estado de NDN permite estrategias de reenvío inteligentes y elimina bucles.
Su premisa es que Internet se utiliza principalmente como una red de distribución de información , que no es una buena opción para IP , y que la "cintura delgada" de la futura Internet debería basarse en datos con nombre en lugar de hosts con direcciones numéricas. El principio subyacente es que una red de comunicación debería permitir que un usuario se centre en los datos que necesita, contenido con nombre , en lugar de tener que hacer referencia a una ubicación física específica de donde se recuperarán esos datos, hosts con nombre . La motivación para esto se deriva del hecho de que la gran mayoría del uso actual de Internet (un "alto nivel de tráfico del 90%") consiste en datos que se difunden desde una fuente a una serie de usuarios. [4] La red de datos con nombre viene con el potencial de una amplia gama de beneficios, como el almacenamiento en caché de contenido para reducir la congestión y mejorar la velocidad de entrega, una configuración más sencilla de los dispositivos de red y la incorporación de seguridad en la red a nivel de datos.
La arquitectura de reloj de arena de Internet actual se centra en una capa de red universal, IP , que implementa la funcionalidad mínima necesaria para la interconectividad global. La arquitectura contemporánea de Internet gira en torno a un modelo de conversación basado en host, que se creó en la década de 1970 para permitir que los usuarios distribuidos geográficamente utilizaran unas pocas computadoras grandes e inmóviles. [5] Esta delgada cintura permitió el crecimiento explosivo de Internet al permitir que las tecnologías de las capas inferior y superior innovaran de forma independiente. Sin embargo, IP fue diseñado para crear una red de comunicación, donde los paquetes solo nombraban puntos finales de comunicación.
El crecimiento sostenido del comercio electrónico , los medios digitales , las redes sociales y las aplicaciones para teléfonos inteligentes ha llevado al uso dominante de Internet como red de distribución. Las redes de distribución son más generales que las redes de comunicación, y la solución de problemas de distribución a través de un protocolo de comunicación punto a punto es compleja y propensa a errores.
El proyecto Named Data Networking (NDN) propuso una evolución de la arquitectura IP que generaliza el papel de esta delgada cintura, de modo que los paquetes puedan nombrar objetos distintos de los puntos finales de comunicación. Más específicamente, NDN cambia la semántica del servicio de red, desde la entrega del paquete a una dirección de destino dada hasta la obtención de datos identificados por un nombre dado. El nombre en un paquete NDN puede nombrar cualquier cosa: un punto final, un fragmento de datos en una película o un libro, un comando para encender algunas luces, etc. La esperanza es que este cambio conceptualmente simple permita que las redes NDN apliquen casi todas las propiedades de ingeniería bien probadas de Internet a una gama más amplia de problemas más allá de las comunicaciones de extremo a extremo. [6] Ejemplos de NDN que aplican lecciones aprendidas de 30 años de ingeniería de redes son que la autorregulación del tráfico de red (a través del equilibrio de flujo entre el interés (solicitud de datos) y los paquetes de datos) y las primitivas de seguridad (a través de firmas en todos los datos nombrados) están integradas en el protocolo desde el principio.
La filosofía detrás de NDN fue iniciada por Ted Nelson en 1979, y más tarde por Brent Baccala en 2002. En 1999, el proyecto TRIAD en Stanford propuso evitar las búsquedas de DNS utilizando el nombre de un objeto para enrutar hacia una réplica cercana de él. En 2006, el proyecto Data-Oriented Network Architecture (DONA) en UC Berkeley e ICSI propuso una arquitectura de red centrada en el contenido, que mejoró TRIAD al incorporar seguridad (autenticidad) y persistencia como primitivas de primera clase en la arquitectura. Van Jacobson dio una charla de Google, A New Way to Look at Networking, en 2006 sobre la evolución de la red, y argumentó que NDN era el siguiente paso. En 2009, PARC anunció su arquitectura centrada en el contenido dentro del proyecto CCNx , que fue dirigido por Jacobson, quien era investigador en PARC en ese momento. El 21 de septiembre de 2009, PARC publicó las especificaciones de interoperabilidad y lanzó una implementación inicial de código abierto (bajo licencia GPL ) del proyecto de investigación Content-Centric Networking en el sitio Project CCNx. NDN es un ejemplo de una dirección de investigación de redes más general llamada redes centradas en la información (ICN), bajo la cual han surgido diferentes diseños de arquitectura. [7] El Grupo de Trabajo de Investigación de Internet (IRTF) estableció un grupo de trabajo de investigación ICN en 2012.
La NDN incluye dieciséis investigadores principales financiados por la NSF en doce campus y un creciente interés de las comunidades de investigación académica e industrial. [8] [9] Más de 30 instituciones forman un banco de pruebas global. Existe un gran cuerpo de investigación y una base de código en crecimiento activo. contribuyó a la NDN.
El reenvío NDN actualmente es compatible con Ubuntu 18.04 y 20.04, Fedora 20+, CentOS 6+, Gentoo Linux, Raspberry Pi, OpenWRT, FreeBSD 10+ y varias otras plataformas. Las bibliotecas de cliente comunes son compatibles de forma activa con los lenguajes de programación C++, Java, Javascript, Python, .NET Framework (C#) y Squirrel. NDN-LITE es una biblioteca NDN liviana diseñada para redes IoT y dispositivos restringidos. NDN-LITE se está desarrollando de forma activa y, hasta ahora, se ha adaptado a placas POSIX, RIOT OS y NRF. También están disponibles y se están desarrollando de forma activa un simulador y un emulador NDN. Se están desarrollando varias aplicaciones cliente en las áreas de conferencias en tiempo real, sistemas de archivos compatibles con NDN, chat, uso compartido de archivos e IoT.
La comunicación en NDN es impulsada por los receptores, es decir, los consumidores de datos, a través del intercambio de dos tipos de paquetes: de interés y de datos. Ambos tipos de paquetes llevan un nombre que identifica un dato que puede transmitirse en un paquete de datos.
Tipos de paquetes
Para obtener la especificación completa, consulte Especificación de formato de paquete NDN.
Para llevar a cabo las funciones de reenvío de paquetes de datos e intereses, cada enrutador NDN mantiene tres estructuras de datos y una política de reenvío:
Cuando llega un paquete de interés, un enrutador NDN primero verifica el almacén de contenido para ver si hay datos coincidentes; si existen, el enrutador devuelve el paquete de datos en la interfaz desde la que proviene el interés. De lo contrario, el enrutador busca el nombre en su PIT y, si existe una entrada coincidente, simplemente registra la interfaz entrante de este interés en la entrada PIT. En ausencia de una entrada PIT coincidente, el enrutador reenvía el interés hacia el productor o productores de datos según la información en la FIB, así como también en la estrategia de reenvío adaptativa del enrutador. Cuando un enrutador recibe intereses para el mismo nombre de varios nodos descendentes, reenvía solo el primero ascendente hacia el productor o productores de datos.
Cuando llega un paquete de datos, un enrutador NDN encuentra la entrada PIT correspondiente y reenvía los datos a todas las interfaces descendentes enumeradas en esa entrada PIT. Luego elimina esa entrada PIT y almacena en caché los datos en el almacén de contenido. Los paquetes de datos siempre toman la ruta inversa de los intereses y, en ausencia de pérdidas de paquetes, un paquete de intereses da como resultado un paquete de datos en cada enlace, lo que proporciona un equilibrio de flujo. Para obtener objetos de contenido grandes que comprenden varios paquetes, los intereses cumplen una función similar en el control del flujo de tráfico que los ACK de TCP en la Internet actual: un bucle de retroalimentación de grano fino controlado por el consumidor de los datos.
Ni los paquetes de interés ni los de datos llevan ninguna dirección de host o interfaz; los enrutadores reenvían los paquetes de interés hacia los productores de datos basándose en los nombres que llevan los paquetes, y reenvían los paquetes de datos a los consumidores basándose en la información de estado PIT establecida por los intereses en cada salto. Esta simetría de intercambio de paquetes de interés/datos induce un bucle de control salto a salto (que no debe confundirse con el enrutamiento simétrico, ¡ni con el enrutamiento en absoluto!) y elimina la necesidad de cualquier noción de nodos de origen o destino en la entrega de datos, a diferencia del modelo de entrega de paquetes de extremo a extremo de IP.
Los nombres NDN son opacos para la red, lo que permite que cada aplicación elija el esquema de nombres que se ajuste a sus necesidades y, de esta forma, los nombres pueden evolucionar independientemente de la red.
El diseño de NDN asume nombres estructurados jerárquicamente, por ejemplo, un video producido por UCLA puede tener el nombre /ucla/videos/demo.mpg, donde '/' delinea los componentes del nombre en representaciones de texto, de manera similar a las URL. Esta estructura jerárquica tiene muchos beneficios potenciales:
Para recuperar datos generados dinámicamente, los consumidores deben poder construir de manera determinista el nombre de un dato deseado sin haber visto previamente el nombre o los datos a través de:
La investigación actual está explorando cómo las aplicaciones deberían elegir nombres que puedan facilitar tanto el desarrollo de aplicaciones como la distribución en red. El objetivo de este trabajo es desarrollar y refinar los principios y pautas existentes para la asignación de nombres, convirtiendo estas reglas en convenciones de nombres implementadas en bibliotecas de sistemas para simplificar el desarrollo de aplicaciones futuras. [12]
Los datos que se pueden recuperar globalmente deben tener nombres únicos a nivel global, pero los nombres utilizados para comunicaciones locales pueden requerir solo enrutamiento local (o transmisión local) para encontrar datos coincidentes. Los nombres de datos individuales pueden ser significativos en diversos ámbitos y contextos, desde “el interruptor de la luz en esta habitación” hasta “todos los nombres de países del mundo”. La administración del espacio de nombres no es parte de la arquitectura NDN, al igual que la administración del espacio de direcciones no es parte de la arquitectura IP. Sin embargo, la asignación de nombres es la parte más importante de los diseños de aplicaciones NDN. Permitir que los desarrolladores de aplicaciones, y a veces los usuarios, diseñen sus propios espacios de nombres para el intercambio de datos tiene varias ventajas:
NDN enruta y reenvía paquetes basados en nombres, lo que elimina tres problemas causados por las direcciones en la arquitectura IP:
NDN puede utilizar algoritmos de enrutamiento convencionales, como el estado del enlace y el vector de distancia . En lugar de anunciar prefijos de IP , un enrutador NDN anuncia prefijos de nombre que cubren los datos que el enrutador está dispuesto a servir. Los protocolos de enrutamiento convencionales, como OSPF y BGP , se pueden adaptar para enrutar sobre prefijos de nombre al tratar los nombres como una secuencia de componentes opacos y hacer una coincidencia del prefijo más largo por componente de un nombre en un paquete de interés contra la tabla FIB . [14] Esto permite que una amplia gama de entradas se agreguen en tiempo real y se distribuyan en múltiples entornos de interfaz simultáneamente sin comprometer el cifrado de contenido. [15] El proceso también evita el análisis de la interfaz clave. La transferencia de aplicaciones y el uso compartido de datos dentro del entorno se definen mediante un marco de distribución multimodal, de modo que los protocolos de retransmisión en la nube afectados son únicos para el identificador de tiempo de ejecución individual. [16]
El estado PIT en cada enrutador admite el reenvío a través del plano de datos de NDN, registrando cada interés pendiente y las interfaces entrantes, y eliminando el interés después de que se reciben los datos coincidentes o se agota el tiempo de espera. Este estado por salto y por paquete difiere del plano de datos sin estado de IP. Según la información de la FIB y las mediciones de rendimiento, un módulo de estrategia de reenvío adaptativo en cada enrutador toma decisiones informadas sobre:
Si un enrutador decide que no se puede satisfacer el Interés, por ejemplo, el enlace ascendente está inactivo, no hay ninguna entrada de reenvío en la FIB o se produce una congestión extrema, el enrutador puede enviar un NACK a su(s) vecino(s) descendente(s) que transmitieron el Interés. Este Reconocimiento Negativo (NACK) puede hacer que el enrutador receptor reenvíe el Interés a otras interfaces para explorar rutas alternativas. El estado PIT permite a los enrutadores identificar y descartar paquetes en bucle, lo que les permite utilizar libremente múltiples rutas hacia el mismo productor de datos. Los paquetes no pueden realizar bucles en NDN, lo que significa que no hay necesidad de tiempo de vida y otras medidas implementadas en IP y protocolos relacionados para abordar estos problemas.
A diferencia de la seguridad TCP/IP (por ejemplo, TLS), que protege la comunicación mediante la protección de los canales IP a IP, NDN protege los datos en sí mismos al exigir a los productores de datos que firmen criptográficamente cada paquete de datos. La firma del editor garantiza la integridad y permite la autenticación de la procedencia de los datos , lo que permite que la confianza de un consumidor en los datos se desvincule de cómo o dónde se obtienen. NDN también admite la confianza de grano fino, lo que permite a los consumidores razonar sobre si el propietario de una clave pública es un editor aceptable para una pieza específica de datos en un contexto específico. El segundo eje de investigación principal es el diseño y desarrollo de mecanismos utilizables para gestionar la confianza del usuario. Se han realizado investigaciones sobre tres tipos diferentes de modelos de confianza:
La seguridad centrada en los datos de NDN tiene aplicaciones naturales para el control de acceso al contenido y la seguridad de la infraestructura. Las aplicaciones pueden cifrar datos y distribuir claves como paquetes con nombre utilizando la misma infraestructura con nombre para distribuir claves, limitando de manera efectiva el perímetro de seguridad de los datos al contexto de una única aplicación. Para verificar la firma de un paquete de datos, una aplicación puede obtener la clave adecuada, identificada en el campo localizador de clave del paquete, al igual que cualquier otro contenido. Pero la gestión de la confianza, es decir, cómo determinar la autenticidad de una clave dada para un paquete particular en una aplicación dada, es un desafío de investigación principal. En consonancia con un enfoque experimental, la investigación de la gestión de la confianza de NDN está impulsada por el desarrollo y el uso de aplicaciones: primero resolver problemas específicos y luego identificar patrones comunes. Por ejemplo, las necesidades de seguridad de NLSR requerían el desarrollo de un modelo de confianza jerárquico simple, con claves en niveles inferiores (más cercanos a la raíz), que se utilizan para firmar claves en niveles superiores en los que las claves se publican con nombres que reflejan su relación de confianza. En este modelo de confianza, el espacio de nombres coincide con la jerarquía de delegación de confianza, es decir, /root/site/operator/router/process. La publicación de claves con un nombre particular en la jerarquía las autoriza a firmar paquetes de datos específicos y limita su alcance. Este paradigma se puede extender fácilmente a otras aplicaciones donde la confianza del mundo real tiende a seguir un patrón jerárquico, como en nuestros sistemas de gestión de edificios (BMS). [20] Dado que NDN deja el modelo de confianza bajo el control de cada aplicación, también se pueden expresar relaciones de confianza más flexibles y expresivas. Un ejemplo de ello es ChronoChat, [19] que motivó la experimentación con un modelo de red de confianza. El modelo de seguridad es que un participante actual de una sala de chat puede presentar a un recién llegado a otros firmando la clave del recién llegado. Las aplicaciones futuras implementarán un modelo de certificación cruzada (SDSI) [13, 3], que proporciona más redundancia de verificación, lo que permite que los datos y los nombres de clave sean independientes, lo que se adapta más fácilmente a una variedad de relaciones de confianza del mundo real.
Además, NDN trata el enrutamiento de red y los mensajes de control como todos los datos NDN, requiriendo firmas. Esto proporciona una base sólida para proteger los protocolos de enrutamiento contra ataques, por ejemplo, suplantación y manipulación. El uso de NDN de reenvío de múltiples rutas, junto con el módulo de estrategia de reenvío adaptativo, mitiga el secuestro de prefijo porque los enrutadores pueden detectar anomalías causadas por secuestros y recuperar datos a través de rutas alternativas. [21] Debido a la naturaleza de entrega de contenido de multidifusión y múltiples fuentes de Named Data Networking , la codificación lineal aleatoria puede mejorar la eficiencia general de la red. [22] Dado que los paquetes NDN hacen referencia al contenido en lugar de a los dispositivos, es más complicado apuntar maliciosamente a un dispositivo en particular, aunque se necesitarán mecanismos de mitigación contra otros ataques específicos de NDN, por ejemplo, DoS de inundación de intereses . [23] [24] Además, tener una tabla de intereses pendientes, que mantiene el estado de las solicitudes pasadas, que puede tomar decisiones informadas sobre cómo manejar el interés tiene numerosas ventajas de seguridad: [25]