Resource location and distribution base protocol

Resource Location and Discovery Base Protocol (también llamado RELOAD), es un Draft publicado por el IETF y ya ha sido presentado al IESG para su aprobación. Es un protocolo de señalización P2P que sirve para proveer almacenamiento y un servicio de mensajes de señalización entre un conjunto de peers cooperantes que forman una red Overlay.

Tiene un modelo de seguridad basado en un servicio de registro que provee identidades únicas. NAT traversal es un servicio fundamental del protocolo usado para acceder a peers situados detrás de NATs o firewalls .

Características principales

Destaca por ofrecer características muy beneficiosas para un protocolo P2P:

Marco de seguridad

Una red P2P normalmente suele establecerse entre peers que no confían unos con otros. RELOAD proporciona un servidor de inscripción central que puede ser usado por los peers para autentificar cada operación realizada. Además, este mecanismo reduce las posibilidades de que se produzca un ataque.

Modelo de uso

Este protocolo está diseñado para soportar gran variedad de aplicaciones. Permite la definición de nuevos usos de aplicación, ya que cada uno de ellos puede definir sus propios tipos de datos, con sus reglas de uso.

NAT Traversal

Permite funcionar con la mayoría de los nodos dentro de un NAT o un firewall. Para ello incluye ICE​ (Interactive Connectivity Establishment) para establecer nuevos RELOAD o conexiones del protocolo de aplicación.

Enrutamiento optimizado

Los peers participan en la petición de las rutas en la red P2P pidiendo en nombre de otros peers. Esto implica carga en los peers. Por ello, la cabecera de reenvío se ha hecho ligera para minimizarla.

Plugable overlay algorithms

RELOAD está diseñado para facilitar la implementación de algoritmos Overlay tanto estructurados como desestructurados. Para permitirlo se ha diseñado una interfaz en la capa Overlay.

Soporte para clientes

Diferencia entre clientes y peers lo que permite usos distintos de este protocolo.

Instancia Overlay

Una instancia Overlay consiste en un conjunto de nodos parcialmente conectados. A cada uno de estos nodos se le asigna un ID numérico que determina su posición dentro de la instancia y el conjunto de nodos a los que está conectado.

Al estar parcialmente conectado, no puede hablar con todos los nodos de forma directa. En estos casos, se comunicará primero a un nodos directo para obtener instrucciones de cómo llegar al nodo deseado. Estas conexiones dependerán del algoritmo utilizado.

Además de lo anterior, también es una red de almacenamiento. Los registros se almacenan en direcciones numéricas, los ID de los recursos, que ocupan el mismo espacio que los identificadores de los nodos. Los peers son los encargados de almacenar los datos asociados al conjunto de direcciones determinadas por su ID de nodo.

Aparte de los peers también soporta clientes.

Peers y clientes

Llamamos peer a un nodo que enruta mensajes de otros nodos a los que está directamente conectado. Aparte de esto, también tiene funciones de almacenamiento. Los clientes al contrario, son nodos que no hacen esa función de enrutamiento ni tienen responsabilidades de almacenamiento.

Arquitectura

RELOAD es fundamentalmente una red Overlay. Tiene una arquitectura en capas equiparable al modelo de internet en Overlay:

Por tanto, sus capas o componentes son los siguientes:

Usage layer

Cada aplicación define un conjunto de tipos de datos y comportamientos que describen cómo usar los servicios proporcionados por RELOAD. La comunicación RELOAD entre estos es realizada a través del servicio Message Transport común a todos ellos. Tiene usos de aplicación tales como el ‘SIP Registration Usage’ (I-D ietf-p2psip-sip​).

El objetivo de esta capa es implementar los usos de la aplicación específica de los servicios Overlay genéricos provistos por RELOAD. Es decir, define como una aplicación específica mapea sus datos en algo que puede ser almacenado en el Overlay, dónde almacenar los datos, cómo ofrecer seguridad a estos y como las aplicaciones pueden recuperar y usar los datos.

Message Transport

Provee un servicio de enrutamiento de mensajes genérico para el Overlay. Es responsable de las transacciones end-to-end. Cada peer es identificado por su localización en el Overlay, con su ID de nodo.

Un componente que sea cliente del ‘Message Transport’ puede realizar dos funciones básicas:

• Enviar un mensaje a un peer especificado por el ID del nodo o el peer responsable del ID del recurso.
• Recibir mensajes que otros peers enviaron al ID del nodo o al ID del recurso del que el receptor es responsable.

Esta capa no provee control de congestión puesto que está basado en pregunta-respuesta lo que no permite su control. En la realidad, se suele usar un temporizador para la retransmisión end-to-end.

Storage

Procesa mensajes relacionados con el almacenamiento y la recuperación de datos en el Overlay. Se comunica con el ‘Topology plugin’ para manejar la duplicidad y migración de los datos, y con el componente ‘Message Transport’ para enviar y recibir mensajes.

El ID del nodo determina el conjunto de recursos del que es responsable de almacenar. Esto dependerá en parte del algoritmo utilizado. Cuando el ID de un recurso cambia, esto es notificado al ‘Topology plugin’ y el componente ‘Storage’ se ha de encargar entonces de migrar el recurso a otros peers.

Topology plugin

Sirve para implementar el algoritmo Overlay usado. Tiene dos funciones: la construcción de las instrucciones de envío locales, y la selección de la topología de funcionamiento, como, por ejemplo, la creación de enlaces para enviar mensajes de gestión Overlay. La razón de ser implementados mediante un plugin es permitir trabajar con distintas topologías.

Se encarga de la tabla de enrutamiento, de crear nuevas conexiones y de proporcionar datos redundantes para evitar la pérdida de información en el caso de que un nodo falle.

Forwarding and Link Management

Proporciona servicios de reenvío de paquetes entre nodos. También maneja el establecimiento de nuevos enlaces entre nodos y establece y mantiene conexiones de red según el Topology plugin.

Algo importante a mencionar es que permite configurar conexiones entre peers a través de firewalls y NATs mediante ICE (Interactive Connectivity Establishment).

Overlay Link Layer

Se encarga de transportar directamente el tráfico entre nodos. Para la comunicación salto a salto utiliza TLS [RFC5246] y DTLS [RFC637]. También es posible definir nuevos protocolos para ello.

Además, los nodos pueden comunicarse con una infraestructura central de almacenamiento para conseguir información de configuración, credenciales de autenticación, y el conjunto de nodos inicial con los que comunicarse para unirse al Overlay.

Seguridad

La seguridad está implementada mediante la posesión por parte de cada nodo de una o más claves públicas certificadas. Estos certificados son proporcionados por un servidor central que también asigna el ID de los nodos. Este ID ha de ser único dentro de una instancia Overlay. Si la red fuese pequeña, se podrían utilizar certificados auto-firmados. Las credenciales son utilizadas para proporcionar seguridad a la comunicación en tres niveles:

• Nivel de conexión: las conexiones entre los nodos se protegen mediante TLS, DTLS u otros protocolos.
• Nivel de mensaje: cada mensaje RELOAD es firmado.
• Nivel de objeto: los objetos almacenados son firmados por el nodo que lo ha creado.

De esta forma, es posible verificar el origen y la recepción correcta de los datos. Su ID permite identificar a los nodos y va a permitir dirigirse a sí mismo, determinar su posición en la topología y saber el conjunto de recursos de los que es responsable.

El certificado va a servir para:

• Permitir al usuario almacenar datos en ubicaciones específicas dentro de la instancia. Cada tipo de dato define una regla específica para determinar qué certificado puede acceder a cada para ID de tipo – ID de recurso.
• Permitir al usuario operar en el nodo cuyo ID se encuentra en el certificado.
• Permitir al usuario usar el nombre de usuario incluido en el certificado.

Opcionalmente, provee una función de admisión basada en la compartición de secretos. En este modelo, todos los peers comparten un clave única que es usada para la autenticación entre peers mediante conexiones a través de TLS-PSK​ (RFC 4279) o TLS-SRP​ (RFC 5054).

Enrutamiento

El enrutamiento de RELOAD proporciona capacidades tales como:

• Enrutamiento basado en el recurso. Estos mensajes son entregados al nodo responsable del recurso. Soporta tanto Overlays estructuradas como desestructuradas.
• 'Enrutamiento de mensajes a un nodo específico en el Overlay.
• Clientes. Soporta solicitudes hacia y desde clientes que no participan en el enrutamiento Overlay.
• NAT Traversal. permite la conexión entre nodos separados por uno o más NATs.
• Low state. los algoritmos de enrutamiento no requieren estados significativos para almacenar peers intermedios.
• Enrutamiento en topologías inestables. Se permite volver a enrutar cuando se producen fallos para conseguir llegar al destino.

Para realizar el enrutamiento utiliza tres mecanismos básicos que permite realizar acciones como especificar rutas específicas o responder a un mensaje por la misma ruta que la petición. Estos mecanismos son:

• Destination List: proporciona una capacidad de enrutamiento como Listas de Destinos que proveen una lista de nodos por los que debe circular el mensaje. En esta lista debe aparecer al menos un nodo.
• Via List: permite responder por el mismo camino por el que se ha recibido un mensaje. Esto es porque se van añadiendo en esta lista los nodos por los que ha pasado el mensaje.
• RouteQuery: Sirve para indicar una cola que irá indicando por donde enviar en el siguiente salto.

Para el enrutamiento utiliza principalmente Symmetric Recursive. Esto es, cada nodo reenvía a otro nodo más cercano al destino hasta llegar al deseado. La respuesta sigue el mismo camino por el que se ha recibido el mensaje. Es el algoritmo usado por defecto en los nodos para enrutar mensajes a través del Overlay.

Gestión de conectividad

Para proveer un enrutamiento eficiente, los peers necesitan mantener un conjunto de conexiones directas a otros nodos. En el caso de que haya NATs entre estos, usamos ICE para establecer la conexión.

En general, un peer necesita mantener conexiones con todos los peers cercanos en la instancia Overlay. Uno de los parámetros del algoritmo ‘Topology plugin’ indica un número determinado de conexiones directas que el peer ha de tener establecidas. Si no se tiene este número, puede seguir funcionando, pero en cuanto sea posible establecer esas conexiones con peers cercanos deberán establecerse.

Estructura del mensaje

RELOAD es un protocolo orientado a mensajes de tipo pregunta-respuesta. Los mensajes son codificados usando campos binarios.

El principal planteamiento de los campos es utilizar el modelo TLV, es decir, tipo, longitud y valor. De esta forma, permiten que el mensaje sea extensible.

Por otro lado, los campos que sean siempre obligatorios, se están definidos con una posición fija no siendo necesario el tipo y la longitud. Los mensajes están estructurados en tres partes.

Cabecera de reenvío

Es una cabecera general para permitir el reenvío entre peers hasta llegar al destino. Es la única parte del mensaje que se examina en los nodos intermedios. La estructura de esta cabecera es como sigue:

Campos:

• relo token (32bits): identifica el mensaje como mensaje RELOAD. El valor del campo será siempre 0x2454c4f.
• overlay (32bits): hash del Overlay en uso. Se forma cogiendo los 32 bits más bajos del hash SHA-1 del nombre del Overlay. Pensado para que los nodos puedan participar a la vez en varios Overlays.
• Configuration sequence (16bits): número de secuencia del fichero de configuración.
• version (8bits): versión del protocolo en uso. En nuestro caso 1.0, valor 0x0a.
• ttl (8 bits): número máximo de saltos antes de que el mensaje sea descartado. Se decrementa en 1 por cada salto a lo largo de la ruta del mensaje. Al llegar a 0 y el nodo que lo ha recibido no es el destino, el mensaje no se reenvía más.
• Fragment (32bits): para permitir fragmentación indicando si es último fragmento o no. También incluye el offset del fragmento.
• Length (32bits): número de bytes del mensaje incluyendo la cabecera y una vez hecha la fragmentación.
• Transaction ID (64bits): número único que identifica la transacción. Se ha de generar de forma aleatoria. La respuesta llevará el mismo ID.
• Max response length (32bits): número máximo de bytes permitidos en la respuesta. En la respuesta su valor es 0.
• Via list length (16bits): longitud en bytes de la via list.
• Destination list length (16bits): longitud en bytes de la destination list.
• Options length (16bits): longitud en bytes de las opciones de cabecera.
• Via list (variable): secuencia de destinos a través de los cuales el mensaje ha pasado.
• Destination list (variable): secuencia de destinos por los que el mensaje debería pasar. Se crea en el nodo origen. El primer elemento de esta secuencia es el destino de reenvío siguiente.

Contenido del mensaje

Es el mensaje, la información que desea transmitirse entre peers. No es analizada por los nodos intermedios, pero sí por capas superiores.

Campos:

• Message code(16bits):indica mensaje enviado. El valor 0 está reservado. Entre el 1 y el 0x7fff indican número de petición o repuesta. Las peticiones siempre serán números impares y su respectiva respuesta el número de la petición más 1. Si el código fuese 0xffff indicaría que se ha producido un error.
• Message body (16bits): cadena de longitud variable. Dependen del valor del campo anterior.
• Extensions: actualmente no existe ninguna extensión. Aunque estas podrían ser definidas. Las extensiones están formadas por
• Type: tipo de la extensión.
• Critical: si es necesario que sea entendida la extensión para procesar el mensaje. En el caso de que valga TRUE, se enviará un mensaje de error si el receptor no puede entenderla.
• Extension contents: contenido de la extensión, dependiente del tipo.

Bloque de seguridad

Contiene certificados y la firma digital de la parte del contenido del mensaje. Han de estar obligatoriamente firmados por el peer origen del mensaje.

Algunos métodos importantes

• Join - Unión de un nodo

Cuando un peer desea unirse a la instancia Overlay, necesitará un ID y un conjunto de credenciales unidos a ese ID. Existe la posibilidad de que ese peer no disponga todavía de credenciales. En ese caso, si existe un servidor para ello, este le proporciona un certificado en el que está incluido el ID del nodo.

Una vez se tienen credenciales, se utiliza el mensaje JoinReq para unirse al Overlay. Depende del ‘Topology plugin’ a qué nodo será enviada esta petición. Si todo es correcto, se responde con el mensaje JoinAns.

Ahora se ha de ejecutar una secuencia de operaciones de almacenamiento y actualizaciones para transferir la sección asignada al espacio Overlay del nodo.

• Leave - Salida de un nodo

Se utiliza el mensaje LeaveReq para indicar que va a salir del Overlay. Este mensaje ha de enviarse a todos los nodos a los que está directamente conectado. Los nodos que reciban este mensaje tendrán que actualizar su tabla de enrutamiento y enviar las secuencias de almacenamiento y actualización necesarias para restablecer el Overlay.

• Update - Actualización

Para ello se utiliza el mensaje Update. Se envía a los nodos a los que está conectado directamente. Sirve para informar del estado actual de su tabla de enrutamiento. Estos mensajes se envían cuando se detecta un cambio.

• RouteQuery

Es una solicitud que permite al emisor preguntar a un peer por donde enrutaría hacia un determinado destino. Uno de sus usos es permitir el enrutamiento iterativo.

• Probe

Permite a un nodo determinar de qué recursos son responsables otros nodos.

• Attach - Solicitud de conexión

Es un mensaje enviado por un nodo para solicitar una conexión directa con un determinado nodo para el envío de mensajes RELOAD. Puede ser enrutado como un ID de nodo o como un ID de un recurso.

• Almacenamiento

Para almacenar datos en el Overlay se utiliza el mensaje StoreReq.

• Fetch - Búsqueda

Para buscar uno o más elementos almacenados en un determinado ID de recurso, se utiliza la petición Fetch.

Véase también

• Session Initiation Protocol
• TURN
• STUN

Enlaces externos

• Información del Draft de IETF sobre RELOAD/p2psip-base-26
• Organismo responsable de la gestión de los IETF

• Datos: Q16624989
• Multimedia: Resource location and distribution base protocol / Q16624989