An Overview of Ontologies - Ontology-based Formative Feedback Generators

2.3 Ontology-based Formative Feedback Generators

2.3.1 An Overview of Ontologies

Una vez que el inicio de sesión se confirma, la transmisión de los paquetes de datos FDR debe comenzar. Dentro de este último se consideran los siguientes tres estados:

1. Funcionamiento ideal (sin paquetes perdidos y sin problemas de conexión del enlace y de la red)

2. Pérdida de paquetes

3. Sin conexión (se termina la sesión inesperadamente)

En la figura 4-9 se muestra la operación de una transmisión de paquetes de datos FDR funcionando idealmente, es decir, los paquetes son recibidos y almacenados por el servidor terrestre en su totalidad. Un paquete de control, cuya estructura se define en la sección 4.3.4.6, es enviado periódicamente cada intervalo de tiempo ajustable de acuerdo a las condiciones de la ruta desde el servidor terrestre al servidor del avión para asegurar la calidad de servicio de

transmisión. El servidor del avión debe confirmar la recepción de este paquete y asegurarse que todos los paquetes enviados han sido recibidos en el servidor terrestre. Así mismo es necesario que el servidor terrestre asocie un timestamp a cada paquete recibido con el fin de poder calcular el retraso y el jitter.

Figura 4-9. Transmisión de paquetes de datos FDR sin pérdidas de paquetes.

La figura 4-10 corresponde a una transmisión con pérdida de paquetes. Si un paquete se pierde durante la transmisión no se envía una solicitud específica para el reenvío de ese paquete, ya que la solicitud de reenvío de paquetes se encuentra explicita en el paquete de control periódico. El paquete de control, además de estadísticas de latencia y jitter, también contiene solicitudes de reenvío de paquetes de datos FDR no recibidos por el servidor terrestre durante el tiempo transcurrido desde el envío del último paquete de control. El servidor del avión cuenta con un buffer donde almacena los paquetes que ha enviado, por lo que éstos estarán disponibles si se solicita su reenvío. El servidor del avión debe confirmar la recepción del paquete de control periódico.

Cuando el servidor del avión reenvía paquetes de datos FDR en respuesta a un paquete de control con una solicitud de reenvío de paquetes, el servidor terrestre debe confirmar la recepción de los paquetes reenviados. El servidor terrestre debe verificar si el número de secuencia del paquete FDR había sido reportado perdido anteriormente. En caso afirmativo, el servidor del avión debe enviar acuse de

recibo. El servidor del avión debe reenviar periódicamente los paquetes reportados perdidos hasta que reciba confirmación de cada uno de ellos. Durante este intervalo de tiempo se debe aumentar la rapidez del enlace puesto que no solamente se deben reenviar los paquetes perdidos, sino que se debe continuar con el envío de paquetes de datos FDR ya que la ráfaga de datos leídos originalmente por los sensores del avión es ininterrumpida.

Figura 4-10. Sesión con pérdida de paquetes

Cuando una sesión se termina inesperadamente, el servidor del avión debe solicitar la reanudación de la sesión al servidor terrestre. El proceso tiene similitud con el que se muestra en la figura 4-8, excepto por el comportamiento de la base de datos, ya que como los registros fueron creados al inicio de la sesión, ahora solo se limita a autentificar por medio del Id de la sesión. El identificador único de la sesión, que durante el proceso de inicio de sesión se le proporciona al servidor

en el avión, es comparado con en el que está almacenado en el la base de datos y que es proporcionado al servidor terrestre para que realice la validación. La firma digital garantiza que es el servidor del avión quien envía la solicitud de reinicio. La operación para el reinicio de una sesión se muestra en la figura 4-11.

Figura 4-11. Reinicio de sesión

Es importante implementar una alarma para advertir situaciones como aquellas en las que una sesión se termina inesperadamente y el servidor terrestre confirma una conexión exitosa a la estación satelital terrestre. Esto indicaría que el enlace se encuentra activo, y podría indicar un accidente. La alarma aplica también para situaciones en donde el enlace permanece inactivo después de cierto tiempo, que también indicaría un accidente. Como se mencionó en el capítulo 3, la información que se transmitirá (procesada por el FDAU) tiene un formato ARINC en respuesta a los estándares que gobiernan las redes a bordo del avión. Adicionalmente, el formato específico en cómo se almacenan los datos de vuelo FDR, comúnmente es conocido sólo por el fabricante o descifrable a través de equipo y software proporcionado por dicho fabricante. Lo anterior hace difícil determinar el fin de la sesión. Por ejemplo, el estado del vuelo (despegando, en trayectoria o aterrizando) es desconocido ya que el significado de los bits contenidos en los paquetes es desconocido debido al formato propietario del fabricante del equipo. En consecuencia a lo anterior, un proceso de fin de sesión se debe activar en el servidor terrestre cuando pase cierto tiempo con una sesión interrumpida y no haya recibido una solicitud de reinicio por parte del servidor del

avión. Para distinguir entre un accidente o falla de un evento normal de fin de sesión, el servidor terrestre de confirmar el aterrizaje del vuelo en cuestión a través de una base de datos externa como Sabre.

4. 3. 2

Estructura del encabezado de los paquetes

Esta sección contiene la especificación de los paquetes que se emplean en la operación del protocolo que se propone. Se proponen dos tipos de paquetes, paquetes de datos FDR y paquetes de mensajes de control. Ambos poseen el mismo encabezado diferenciándolos uno de otro un campo determinado en la estructura, el bit ‗F‘. La longitud estándar del encabezado es de 4 bytes y su estructura se muestra en figura 4-12. Los campos son:

Bit ‗F‘ (1 bit): especifica el tipo de paquete de acuerdo a su contenido, ya sea de datos FDR o de mensaje de control. Si el bit ‗F‘ es 1 indica que es un paquete de datos FDR, si es 0 es un paquete de mensaje de control.

Numero de secuencia (15 bits): es un número único de paquete que identifica la posición de éste en la secuencia de paquetes. Es incrementado en uno para cada paquete enviado. Este número de secuencia es utilizado para que los servidores, del avión y terrestre, detecten paquetes perdidos, ya que cada servidor posee su propia secuencia. El servidor del avión también lo utiliza para retransmitir los paquetes perdidos. Una práctica común es empezar con un número aleatorio como secuencia inicial a fin de evitar ciertos ataques tal como se hace en el protocolo RTP de la IETF.

Time-stamp (16 bits): este valor refleja el instante en que el paquete es generado por la fuente, se incrementa en milisegundos. El timestamp tiene el objetivo de permitir al servidor terrestre calcular el retraso y el jitter promedio para incluirlos en los mensajes de control. El reloj del servidor terrestre debe estar sincronizado con un servidor independiente, de modo que los servidores de los aviones puedan a su vez, antes de cada vuelo sincronizar los suyos. En el servidor del avión, el timestamp es utilizado para calcular el tiempo entre llegadas de un paquete de control periódico y otro. De manera que, con base a las estadísticas que el servidor terrestre envía al servidor del avión en dicho paquete de control periódico, el servidor del avión puede ajustar

el tiempo en el que se deben enviar los paquetes periódicos de control de acuerdo a un criterio de minimización de pérdida de paquetes conjuntamente con un balance en la proporción del número de paquetes de datos al número de paquetes de mensajes de control. Payload: el tamaño del payload varía de acuerdo al tipo de paquete que se envíe. Se mostrará explícitamente en las secciones 4.3.3 y 4.3.4.

Figura 4-12. Estructura del encabezado del paquete del protocolo FDRP

4. 3. 3

Consideraciones de Seguridad

La seguridad de la información transmitida es reforzada en la presente propuesta de dos maneras, por tokens de seguridad y por una firma digital. Dependiendo si se trata de iniciar una sesión o de transmitir paquetes de datos FDR se utiliza uno u otro.

El inicio de una sesión dentro del sistema propuesto está protegido mediante un proceso de autentificación en base a tokens. Los tokens de seguridad son dispositivos electrónicos o elementos de software que le proporciona a un usuario autorizado una contraseña de autentificación. Los tokens de seguridad generan una contraseña, estática o dinámica.

Al momento de la autentificación, la contraseña generada por el token en el servidor del avión debe corresponder a una contraseña en el servidor terrestre válida en ese mismo tiempo. Esto implica una sincronización temporal entre el generador de la contraseña en el avión y el generador en el servidor terrestre.

La diferencia entre un token estático y uno dinámico es que en el primero, las contraseñas han sido generadas previamente, mientras que en el segundo, la contraseña se genera aleatoriamente de acuerdo a un algoritmo preestablecido. En ambos casos, la contraseña generada es válida para una sola conexión. Se considera que la mejor solución, para garantizar que todos los accesos sean

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F| Número de secuencia | Time-stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Payload + : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

accesos autorizados al sistema, es adoptar tokens dinámicos, ya que permiten simplificar la administración de tokens al momento de registrar aviones en el sistema terrestre.

La firma digital garantiza la integridad de la transmisión de los paquetes de datos y algunos paquetes de mensajes de control, específicamente para aquellos que se intercambian cuando el proceso de autentificación ha sido realizado con éxito. La firma digital proporciona adicionalmente una garantía del origen de los datos. Consiste en una cadena de dígitos binarios y es generada con base a un conjunto de reglas y parámetros que permite garantizar la identidad del emisor y garantizar que los datos no han sido alterados. La generación y verificación de las firmas se realiza a través de un algoritmo Hash. Las funciones Hash, que reciben como argumentos el mensaje a transmitir y la llave privada, generan una firma digital de la cual es imposible deducir ya sea el mensaje o la llave. Para la generación de la firma digital se emplea la llave privada y para la verificación se usa la llave pública (fig.4-13), teniendo ambas una relación matemática. Se asume que las llaves públicas pueden ser conocidas por el público en general mientras que las llaves privadas por el contrario nunca se comparten. Es decir, cualquiera puede verificar la firma digital de un paquete usando la llave pública, pero la generación de dicha firma solo la puede realizar quien posee la llave privada (FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, 2000).

Al principio de la sesión las llaves públicas se intercambian, el servidor del avión envía la suya al servidor terrestre y viceversa, a través de paquetes de mensajes de control, como fue descrito en el protocolo de la sección 4.3.1.

Figura 4-13. Generación y verificación de la Firma Digital a partir de las llaves privada y pública

4. 3. 4

Tipos de paquetes de mensaje de control

Este tipo de paquete es empleado principalmente durante el establecimiento y el monitoreo de la sesión. De acuerdo al encabezado de un paquete, definido en la sección 4.3.2, el bit ‗F‘ debe ser ‗0‘ para indicar que es un paquete de mensaje de control. Dependiendo del tipo de mensaje de control que transporte el paquete se le agregan otros campos. Se definen los siguientes tipos de mensajes de control:

Descripción Tipo de payload

Solicitud de inicio de sesión 0000

Acuse de recibo 0001

Confirma autentificación 0010

Confirma inicio de sesión 0011

Solicitud de reinicio de sesión 0100

Control periódico 0101

Reenvío de paquete 0110

De uso libre 0111

De uso libre 1000

4. 3. 4. 1

Solicitud de inicio de sesión

Este mensaje de control contiene los campos necesarios para que el servidor del avión solicite un inicio de sesión al servidor terrestre. La estructura de este mensaje se muestra en la fig. 4-14. Los campos de este paquete de mensaje de control son los siguientes:

Tipo de mensaje de control (4 bits): define el tipo de mensaje de control que se envía. Para el mensaje de control de inicio de sesión es 0000.

Bits de relleno (4 bits): indica que no son parte del payload de este paquete de mensaje de control.

Username (88 bits): este campo proporciona el identificador del usuario que es verificado en el proceso de autentificación en tierra. Al momento de registrar un nuevo servidor de avión en la base de datos de aviones del sistema, se crea este username. Los 88 bits implican una contraseña de 11 caracteres.

Contraseña (64 bits): Estos bits representan la contraseña que es valida solo para una conexión proporcionada por un token de seguridad instalado en el avión y sincronizado temporalmente con su contraparte en el servidor terrestre.

Llave pública (256 bits): a través de este campo, el servidor del avión envía la llave pública al servidor terrestre quien la utiliza para verificar la firma digital de los próximos paquetes que recibe del servidor del avión.

Figura 4-14. Estructura del paquete de mensaje de control de solicitud de inicio de sesión

4. 3. 4. 2

Acuse de recibo

Este mensaje de control contiene los campos necesarios para notificar la recepción de un paquete y puede ser enviado por ambos servidores, el del avión y el terrestre. La estructura de este mensaje se muestra en la fig. 4-15. Los campos de este paquete de mensaje de control son los siguientes:

Tipo (4 bits): define el tipo de mensaje de control. Para el mensaje de control de acuse de recibo es 0001.

Número de secuencia de paquete recibido (28 bits): este campo especifica el número de secuencia del paquete del que se confirma su recepción. Los 28 bits permiten aproximadamente una secuencia cronológica durante 7456 horas, suficiente para garantizar este orden durante cualquier vuelo.

Si al transcurrir cierto tiempo t después de enviar un paquete que requiere acuse y éste no se recibe, se debe retransmitir el paquete original.

Figura 4-15.Estructura del paquete de mensaje de control de acuse de recibo

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |F| Número de secuencia | Time-stamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Tipo |Relleno| Username | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Username | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Username | 56 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ bytes | Contraseña | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Contraseña | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | : Llave pública : | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +

4. 3. 4. 3

Confirma autentificación

Este mensaje de control es enviado por el servidor terrestre al servidor del avión, se utiliza durante el inicio de la sesión y le indica al servidor del avión que el proceso de autentificación ha sido realizado así como el resultado de dicha autentificación (éxito o fracaso). Si la autentificación fracasa, el proceso de inicio de sesión se suspende, de lo contrario prosigue. Dependiendo de la razón del fracaso, el servidor puede volver a solicitar un inicio de sesión. La estructura de este mensaje se muestra en la fig. 4-16. Los campos de este paquete de mensaje de control son los siguientes:

Tipo (4): define el tipo de mensaje de control. Para el mensaje de control que confirma la autentificación es 0010.

Bit ‗S‘ (1): define el éxito o fracaso del proceso de autentificación. Si el valor es 1 notifica éxito, si es 0 es fracaso.

Mensaje de retroalimentación (27): este campo es utilizado cuando el resultado del proceso de autentificación es un fracaso. Son cuatro condiciones, si la contraseña es incorrecta, si el usuario es incorrecto, las dos anteriores o que el avión esté suspendido. Esta última condición quiere decir que el avión esta dado de alta en la base de datos de aviones pero por cuestiones administrativas se le ha suspendido el servicio. En caso de contraseña incorrecta, el servidor terrestre debe enviar la dirección IP donde se encuentra el servidor NTP (Network Time Protocol) de donde se sincroniza el reloj. El servidor del avión deberá sincronizar su reloj he intentar de nuevo la solicitud de inicio. Se asignan 30 bits para este campo para que exista la posibilidad de definir nuevos mensajes.

IP del servidor NTP (32 bits): este campo se utiliza cuando el proceso de autentificación sea un fracaso y el motivo sea por contraseña incorrecta. Esta dirección IP indica donde se encuentra el servidor NTP de donde se sincroniza el reloj del servidor del avión para generar una nueva contraseña.

Llave pública (256): a través de este campo, el servidor terrestre envía su llave pública al servidor del avión quien la utiliza para verificar la firma digital de los paquetes que recibe del servidor del avión.

Figura 4-16. Estructura del paquete de mensaje de control de Confirma autentificación

4. 3. 4. 4

Confirma inicio de sesión

Este mensaje de control contiene los campos necesarios para notificar que la sesión previamente solicitada ha sido iniciada. Se envía este paquete una vez que en la base de datos ya estén creados los registros donde se almacenarán los datos FDR, por lo tanto este mensaje le informa al servidor del avión que ya puede enviar los paquetes de datos FDR al servidor terrestre. La estructura de este mensaje se muestra en la fig. 4-17. Los campos de este paquete de mensaje de control son los siguientes:

Tipo (4 bits): define el tipo de mensaje de control. Para el mensaje de control de confirmación de inicio de sesión es 0011.

Bit ‗S‘ (1bits ): especifica si los registros de la base de datos, donde se almacenará la información de los paquetes de datos FDR, han sido creados. El valor 1 significa éxito, es decir que los registros se han creados, de lo contrario el valor es 0.

Bits ‗R‘ se refieren a los bits de relleno (3 bits): indica que no son parte del payload de este paquete de mensaje de control.

Mensaje de retroalimentación (120 bits): se utiliza si el bit ‗S‘ es cero. Este campo indica con un mensaje de texto la razón del fracaso por ejemplo falla de conexión con el servidor.

Firma digital (32 bits): consiste en 32 bits que permite al servidor del avión garantizar la identidad del servidor terrestre.

Identificador de sesión (32 bits): este campo contiene los bits que representan un identificador único asignado por la base de datos, se genera cuando la base de datos crea los registros donde se almacenarán los datos FDR. Su utilidad es relevante si la sesión se 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

desea reiniciar en caso de que sea interrumpida, ya que siendo un identificador de sesión único por cada avión es posible reanudar dicha sesión autentificando al solicitante a través de este identificador.

Figura 4-17. Estructura del paquete de mensaje de control de confirma el inicio de la sesión

4. 3. 4. 5

Solicitud de reinicio de sesión

Este mensaje de control, como su nombre lo indica, contiene los campos necesarios para solicitar un reinicio de sesión. Cuando una sesión se interrumpe el servidor del avión envía este mensaje al servidor terrestre para reiniciar la sesión. Una vez restablecida la sesión se detectarán paquetes perdidos y el servidor del avión reenviará esos paquetes simultáneamente con los actuales que se estén generando. La estructura de este mensaje se muestra en la fig. 4-18. Los campos de este paquete de mensaje de control son los siguientes:

In document Ontology Validation & Utilisation For Personalised Feedback In Education (Page 39-43)