Servidor de perfiles, mapa de ruta

Actualmente estamos liberando la versión alpha del servidor de perfiles. Su documentación técnica se puede encontrar aquí.

Aquí les presento la lista de características, mejoras de seguridad y optimizaciones que se pueden hacer en la implementación actual del servidor de perfiles. Abrimos todas estas ideas de proyectos a la comunidad de Fermat para proponer estas características a través de nuestro Sistema de Gobernanza de Contribuciones. La siguiente lista fue tomada de aquí. Mientras tanto, nos centraremos en el siguiente servidor para diseñar e implementar: el servidor de proximidad.

Así que lo repito: si eres un desarrollador, un developer o una empresa de desarrollo, puedes enviar cualquiera de estos proyectos a nuestro Sistema de Gobernanza de Contribuciones y recibir pagos en IoPs.

Características aún no implementadas
Algunas de las siguientes características van a ser implementadas, otras serán consideradas.

Simulador de red Soporte LOC
El simulador de red es una herramienta que permite a los desarrolladores ejecutar varias instancias del servidor de perfiles en una sola máquina y crear una red de pruebas en la que se pueden analizar varios escenarios. Actualmente, el simulador de red implementa un servidor LOC ficticio, que simula una funcionalidad básica de un servidor LOC. Necesitamos mejorar el simulador de red para soportar el software LOC real, para ayudarnos a probar la funcionalidad LOC dentro del simulador, así como la integración entre el servidor de perfiles y el servidor LOC.

Soporte del simulador de redes multimáquinas
En la actualidad, el simulador de red sólo puede ejecutarse en una sola máquina, lo que limita el tamaño de la red simulada debido a las demandas del simulador sobre los recursos de hardware. Puede ser posible extender la funcionalidad del simulador de red para soportar la ejecución en múltiples máquinas, lo que le permitiría simular grandes entornos de red en sólo un par de servidores de prueba.

Notificación de cambios de perfil
Algunas aplicaciones IoP de usuario final pueden estar interesadas en ser notificadas cada vez que se actualice un perfil determinado en su servidor de perfiles. En la actualidad, no hay ningún sistema de mensajes sin conexión, por lo que se espera que la notificación sólo pueda proporcionarse si la aplicación interesada tiene una conexión abierta con el servidor de perfiles que aloja el perfil supervisado. Sin embargo, tal implementación podría aumentar significativamente los recursos consumidos por el servidor de perfiles, si el número de observadores es alto.

Planes de Hospedaje y Facturación
En la actualidad, el servidor de perfiles no cobra nada por sus servicios y todo el mundo es libre de registrarse y utilizarlo, a menos que el servidor de perfiles alcance sus límites configurados. Un sistema de planes de hospedaje pretende limitar el uso gratuito del servidor de perfiles mediante la introducción de varias cuotas en cada funcionalidad que ofrece el servidor de perfiles. Se espera que cada servidor de perfiles ofrezca un plan de alojamiento gratuito muy limitado que permitirá a los nuevos usuarios de la red unirse a la red de forma gratuita, así como ofrecer planes pagados a los usuarios que puedan proporcionar pagos mensuales.

La facturación es el sistema previsto de las solicitudes de pago entregadas a los clientes para requerirles que paguen por los servicios del servidor de perfiles, a su cartera.

Nodo de copia de seguridad
Para evitar perder un acceso a la red cuando el servidor de perfil de alojamiento de un cliente no está disponible, se puede crear un sistema de nodos de copia de seguridad. Un nodo de copia de seguridad contendrá información de perfil actualizada sobre el cliente, pero no se utilizará hasta que el cliente lo solicite debido a problemas con su servidor principal de alojamiento. El nodo de copia de seguridad reemplazará la función del servidor de alojamiento del cliente hasta que su servidor principal esté disponible nuevamente. En caso de indisponibilidad permanente del servidor principal, se espera que el cliente migre completamente al servidor de copia de seguridad u otro servidor de perfiles.

Interfaz de administración
Se debe implementar una interfaz especial para el administrador del servidor de perfiles para facilitar la gestión y el cambio de la configuración del servidor de perfiles sin necesidad de reiniciarla, así como para proporcionar varias estadísticas sobre las operaciones y los resultados del servidor de perfiles.

Modo de prueba de regresión
Una vez que la interfaz de administración está lista, podemos implementar un modo de prueba de regresión que permitirá a los desarrolladores crear nuevos tipos de pruebas del servidor de perfiles.

Seguridad

Ataques DoS y Sybil usando el proceso de inicialización de vecindad.
Actualmente, no hay verificación si un servidor de perfiles entrantes que solicita subir su base de datos de perfiles está autorizado para hacerlo. La mitigación de este problema depende de las decisiones de diseño que se tomen sobre la definición final de la vecindad del servidor.

Independientemente del diseño y las definiciones de vecindad, también existe la posibilidad de lanzar un gran número de servidores dentro de un determinado lugar. La mitigación de esto probablemente debería hacerse en el nivel LOC con la limitación basada en la subred IP.

También actualmente, no hay límite en una serie de intentos para el proceso de inicialización de vecindad si falla. Esto permite al atacante realizar un ataque DoS. Para mitigar este problema, podemos introducir límites basados ​​en IP.

Ataque de DoS usando consultas de búsqueda, actualizaciones de perfil y otras solicitudes
Actualmente, no hay límite en un número de consultas de búsqueda que una sola identidad puede enviar al servidor de perfiles. Enviar una consulta de búsqueda es una operación barata para el cliente en comparación con la cantidad de trabajo que el servidor potencialmente está haciendo.

Del mismo modo, actualmente no hay límites para otras solicitudes, como actualizaciones de perfiles.

Para mitigar este problema, tendríamos que introducir límites basados ​​en identidad o basados ​​en IP en las consultas de búsqueda y otras solicitudes.

Ataque Sybil al Registro de Alojamiento de Perfil
Actualmente, no hay límite en una serie de perfiles que una sola dirección IP puede registrar en el servidor. Un solo atacante puede ocupar todas las ranuras libres que el servidor de perfiles tiene para alojar identidades.

Para mitigar este problema, tendríamos que introducir límites basados ​​en IP en los registros de alojamiento.

Optimizaciones

Actualizaciones entre vecinos

Los servidores vecinos comparten sus bases de datos de perfiles y mantienen sincronizada su información. La carga inicial de la base de datos a un vecino es eficiente, pero las actualizaciones individuales que siguen son de alguna manera ineficientes ya que actualmente utilizamos una nueva conexión TCP TLS con el vecino de destino, verificamos nuestra identidad y enviamos una sola actualización de un solo perfil incluso si hay más actualizaciones por hacer.

Como el número de vecinos es potencialmente alto y la frecuencia de cambios en los perfiles alojados es baja, la reutilización de una conexión no parece ser una buena opción a menos que sea utilizada por ambos pares. Tales optimizaciones no deben hacerse hasta que el diseño final del servidor de vecindad se decida porque, actualmente es incierto si cualquier optimización es necesaria.

La realización de actualizaciones por lotes en lugar de actualizaciones individuales ahorraría recursos, pero afectaría potencialmente al UX, ya que la función de búsqueda de perfiles sería muy afectada.

Nota.- Traducción realizada por @jmcpcancino del Artículo de @Luis_fer_Molina publicada originalmente en Medium