Redes de datos con nombre

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.

• Principio de extremo a extremo : permite el desarrollo de aplicaciones robustas ante fallas de red. NDN conserva y amplía este principio de diseño.
• Separación del plano de enrutamiento y reenvío: esto ha demostrado ser necesario para el desarrollo de Internet. Permite que el plano de reenvío funcione mientras el sistema de enrutamiento continúa evolucionando con el tiempo. NDN utiliza el mismo principio para permitir la implementación de NDN con la mejor tecnología de reenvío disponible mientras se realizan investigaciones sobre nuevos sistemas de enrutamiento.
• Reenvío con estado: los enrutadores NDN mantienen el estado de los paquetes reenviados recientemente, lo que permite un reenvío inteligente, detección de bucles, equilibrio de flujo, almacenamiento en caché ubicuo, etc.
• Seguridad incorporada: en NDN, la transferencia de datos está protegida en la capa de red mediante la firma y verificación de cualquier dato nombrado. ^[10]
• Permitir la elección y la competencia por parte del usuario: la arquitectura debe facilitar la elección y la competencia por parte del usuario siempre que sea posible. Aunque no fue un factor relevante en el diseño original de Internet, la implementación global ha demostrado que “la arquitectura no es neutral”. ^[11] NDN hace un esfuerzo consciente para empoderar a los usuarios finales y permitir la competencia.

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

• Interés: un consumidor coloca el nombre de un dato deseado en un paquete de interés y lo envía a la red. Los enrutadores utilizan este nombre para reenviar el interés hacia el o los productores de datos.
• Datos: Una vez que el Interés llega a un nodo que tiene los datos solicitados, el nodo devolverá un paquete de Datos que contiene tanto el nombre como el contenido, junto con una firma con la clave del productor que vincula ambos. Este paquete de Datos sigue en sentido inverso el camino tomado por el Interés para volver al consumidor solicitante.

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:

• Tabla de intereses pendientes (PIT): almacena todos los intereses que un enrutador ha reenviado pero que aún no ha satisfecho. Cada entrada de PIT registra el nombre de los datos que contiene el interés, junto con sus interfaces de entrada y salida.
• Base de información de reenvío (FIB): una tabla de enrutamiento que asigna componentes de nombre a interfaces. La propia FIB se completa con un protocolo de enrutamiento basado en prefijos de nombre y puede tener múltiples interfaces de salida para cada prefijo.
• Almacén de contenido (CS): un caché temporal de paquetes de datos que el enrutador ha recibido. Debido a que un paquete de datos NDN es significativo independientemente de dónde provenga o a dónde se reenvíe, se puede almacenar en caché para satisfacer intereses futuros. La estrategia de reemplazo se utiliza tradicionalmente menos recientemente, pero la estrategia de reemplazo la determina el enrutador y puede diferir.
• Estrategias de reenvío: una serie de políticas y reglas sobre el reenvío de intereses y paquetes de datos. Tenga en cuenta que la estrategia de reenvío puede decidir descartar un interés en determinadas situaciones, por ejemplo, si todos los enlaces ascendentes están congestionados o si se sospecha que el interés es parte de un ataque DoS. Estas estrategias utilizan una serie de activadores en la secuencia de reenvío y se asignan a prefijos de nombre. Por ejemplo, de forma predeterminada, /localhost utiliza la estrategia de reenvío de multidifusión para reenviar intereses y datos a cualquier aplicación local que se ejecute en un NFD cliente. La estrategia de reenvío predeterminada (es decir, "/") es la estrategia de reenvío de mejor ruta.

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:

• Especificación de relación: permite que las aplicaciones representen el contexto y las relaciones de los elementos de datos. Por ejemplo: el segmento 3 de la versión 1 de un video de demostración de la UCLA podría llamarse /ucla/videos/demo.mpg/1/3
• Agregación de nombres: /ucla podría corresponder a un sistema autónomo que originó el video
• Enrutamiento: permite que el sistema se escale y ayuda a proporcionar el contexto necesario para los datos.

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:

• Un algoritmo permite al productor y al consumidor llegar al mismo nombre basándose en la información disponible para ambos.
• Los selectores de interés junto con la coincidencia del prefijo más largo recuperan los datos deseados a través de una o más iteraciones.

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:

• aumentar la cercanía del mapeo entre los datos de una aplicación y su uso de la red.
• reduciendo la necesidad de notación secundaria (mantenimiento de registros para asignar la configuración de la aplicación a la configuración de la red).
• ampliando la gama de abstracciones disponibles para los desarrolladores.
• Las solicitudes de contenido basadas en nombres también plantean inquietudes sobre la fuga de información privada . Gracias a la separación de la gestión del espacio de nombres de la arquitectura NDN, es posible proporcionar un esquema de nombres que preserve la privacidad haciendo cambios menores en el esquema de nombres NDN convencional. ^[13]

NDN enruta y reenvía paquetes basados ​​en nombres, lo que elimina tres problemas causados ​​por las direcciones en la arquitectura IP:

• Agotamiento del espacio de direcciones : el espacio de nombres NDN es esencialmente ilimitado. El espacio de nombres solo está limitado por el tamaño máximo de paquete de interés de 8 kb y la cantidad de posibles combinaciones únicas de caracteres que componen los nombres.
• Travesía NAT : NDN elimina las direcciones, públicas o privadas, por lo que NAT es innecesario.
• Gestión de direcciones: la asignación y gestión de direcciones ya no es necesaria en las redes locales.
• En la multidifusión de red : un productor de datos no necesita recibir múltiples intereses para los mismos datos, ya que las entradas PIT en los reenvíos descendentes agregarán intereses. El productor recibe y responde a un único interés y aquellos nodos de reenvío en los que se recibieron múltiples intereses entrantes enviarán por multidifusión las respuestas de datos a las interfaces desde las que se recibieron esos intereses.
• Alta confiabilidad de extremo a extremo con pérdida: las redes basadas en IP requieren que el remitente retransmita los paquetes perdidos o descartados. Sin embargo, en NDN, si un interés vence antes de que una respuesta de datos llegue al solicitante, los reenvíos aún almacenan en caché la respuesta de datos a lo largo de la ruta de retorno. El interés retransmitido solo necesita llegar a un reenvío con una copia en caché de los datos, lo que brinda a las redes basadas en NDN un mayor rendimiento que las redes basadas en IP cuando las tasas de pérdida de paquetes son altas.

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:

• Flujo de control: dado que cada interés recupera como máximo un paquete de datos, un enrutador puede controlar directamente el flujo controlando la cantidad de intereses pendientes que mantiene.
• Entrega de datos de multidifusión: el PIT que registra el conjunto de interfaces a las que han llegado los mismos datos, naturalmente admite esta función.
• Actualización de rutas para acomodar cambios en su visión de la red. ^[17]
• Entrega: un enrutador puede razonar sobre qué intereses reenviar a qué interfaces, cuántos intereses insatisfechos permitir en el PIT, así como la prioridad relativa de los diferentes intereses.

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:

• Modelo de confianza jerárquico: donde un espacio de nombres de claves autoriza el uso de claves. Un paquete de datos que lleva una clave pública es efectivamente un certificado, ya que está firmado por un tercero y esta clave pública se utiliza para firmar datos específicos. ^[18]
• Red de confianza : para permitir una comunicación segura sin necesidad de anclajes de confianza previamente acordados. ^[19]
• Confianza ligera para IoT : el modelo de confianza NDN se basa principalmente en criptografía asimétrica , lo cual no es viable para dispositivos con restricciones de recursos en el paradigma IoT. ^[13]

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]

• Equilibrio de carga: la cantidad de entradas PIT es un indicador de la carga del enrutador; restringir su tamaño limita el efecto de un ataque DDoS.
• Tiempo de espera de interés: los tiempos de espera de entrada PIT ofrecen una detección de ataques relativamente barata, y la información de la interfaz de llegada en cada entrada PIT podría respaldar un esquema de retroceso en el cual los enrutadores descendentes son informados de los intereses no atendidos, lo que ayuda a detectar ataques.

• Políticas de almacenamiento en caché de redes centradas en la información
• Investigación y experimentación en Internet del futuro (UE)

• ¡MUERTE AL TCP/IP! Cisco, Intel, el gobierno de EE.UU. y un montón de científicos gritan:
• FIA-NP: Investigación colaborativa: Red de datos con nombre, siguiente fase (NDN-NP)
• Página de inicio de investigación de datos con nombre
• Premios NSF para NDN 2
• FIA: Investigación colaborativa: Redes de datos con nombre (NDN)
• Redes de funciones con nombre (NFN)
• NDN en Galileo (captura de pantalla de WebArchive)