El formato general de los paquetes propuestos aqu´ı consistir´a de una cabecera IP, una cabecera del protocolo CTP, la carga ´util del mensaje y un campo de autentificaci´on. En la figura 29 podemos observar el formato gen´erico de los paquetes4
del protocolo CTP propuesto en este trabajo.
Carga útil del mensaje (solo para mensajes de datos de CT) Cabecera IP
Cabecera IPSec ESP (opcional) Cabecera CT
Campo de autentificación para ESP
Figura 29. Formato gen´erico de los paquetes para la transferencia de contexto.
El tama˜no total del paquete incluyendo las cabeceras del protocolo de transporte debe ser menor que el MTU (Maximum Transmisi´on Unit) para evitar la fragmentaci´on de los paquetes. La descripci´on de cada uno de los campos del paquete gen´erico CTP es la siguiente:
Cabecera IP.-Los datos del contexto son enviados usando paquetes IP. En caso que el tr´afico en la red pueda ser manejado con esquemas de calidad de servicio, los paquetes IP que llevan el contexto deben ser marcados para que sean tratados con m´as que “me- jor esfuerzo”, para que de esta manera se tenga mayor robustez en la transferencia del contexto.
Cabecera IPSec ESP (opcional).-En caso de que sea necesaria la encriptaci´on y/o
4
autentificaci´on de la carga ´util (payload), se puede agregar una cabecera ESP (Encap- sulating Security Payload) para agregar seguridad a la transferencia del contexto.
Cabecera CT (Transfer Context).-Esta cabecera consiste en la informaci´on com´un a los mensajes de transferencia de contexto, ya sea de datos o de se˜nalizaci´on (ver figura 30). El prop´osito de cada uno de los campos de esta cabecera es el siguiente:
Tipo Banderas Longitud
Dirección IP del MN No.Secuencia
Figura 30. Cabecera CT.
Tipo.- Es el tipo de mensaje en la transferencia de contexto y es definido de la siguiente manera:
0 Mensaje de petici´on de inicio de CT. 1 - 2 Reservado.
3 Mensaje de datos de CT. 4 Reservado.
5 Mensaje PNACK CT (opcional). 6 Mensaje FNACK CT (opcional). 7 Mensaje abortar CT.
8 Mensaje abortar caracter´ıstica de CT (opcional). 9 Reservado.
Banderas.- Este espacio puede ser utilizado para establecer banderas, ya sea de confiabilidad en la transmisi´on o para indicar si el paquete es una retransmisi´on, actualizaci´on, etc.
N´umero de Secuencia.- En caso de que los paquetes del contexto sean transmitidos en varios paquetes o fases, este campo puede ayudar al nuevo AR a ordenar los paquetes y/o a detectar p´erdida de paquetes. El n´umero de secuencia para el primer paquete es 0. Retransmisiones o actualizaciones de los datos del contexto deben usar el mismo n´umero de secuencia.
Longitud.-Longitud de la carga ´util del mensaje en bytes.
Direcci´on IP del MN.-Este campo es usado para identificar el due˜no del contexto, de esta manera el nuevo AR entrega el contexto al MN que ten´ıa anteriormente esa direcci´on IP.
Carga ´util del mensaje.- Este mensaje utilizar´a la cabecera mostrada en la figura 30 cuyo campo tipo ser´a igual a 3 para mensaje de datos. La carga ´util del paquete contiene datos del contexto en forma de opciones (uno por cada servicio) como se mues- tra en la figura 31. Cada una de las opciones de los datos es construida como se muestra en la figura 32, y la descripci´on de cada uno de ´estos es la siguiente:
&('*),+.-0/),1.243657285797:)73 1
&'*),+.-0/);1.273657285797:)73 N
Figura 31. Mensajes de datos en CT.
Identificador de microflujo.- Este campo debe contener el identificador de un microflujo dado. Un microflujo [Blake et al., 1998] es una instancia
Longitud de los datos CT No.Secuencia dato
Datos del tipo de contexto Identificador de microflujo
Checksum(opcional) Tipo de contexto Banderas
Figura 32. Aspectos de los datos CT.
de un flujo de una aplicaci´on-a-aplicaci´on, el cual es identificado por una direcci´on fuente, un puerto fuente, una direcci´on destino, un puerto destino y un identificador de protocolo.
Tipo de contexto.-Identifica el servicio al cual corresponde ese contexto, por ejemplo: compresi´on de cabeceras, QoS, etc.
Banderas.- Este campo es utilizado para establecer banderas, las cuales pueden identificar si se requiere el uso de confiabilidad, si existen otros aspectos del contexto en el paquete o si ya es el ´ultimo, actualizaci´on de contexto, etc.
No. Secuencia dato.-Es usado en caso de que el contexto sea enviado en varios datagramas. Este n´umero de secuencia es iniciado en 0 para cada uno de los servicios transferidos. Las actualizaciones o retransmisiones deben utilizar el mismo n´umero de secuencia del paquete que se va a actualizar.
Longitud de los datos CT.-Indica la longitud de los datos del contexto.
Datos del tipo de contexto.-Contienen la informaci´on del estado actual del servicio a ser transmitido.
Checksum (opcional).-Este campo es utilizado para verificar que los da- tos no sean corrompidos durante la transmisi´on.
Campo de autentificaci´on para ESP.-Este campo contendr´a la llave de seguridad ESP para que las comunicaciones puedan ser establecidas de manera segura.
Los siguientes mensajes son definidos para ayudar a verificar si existen errores en la transferencia o si se desea cancelar la misma. El protocolo CTP reconocer´a estos men- sajes debido a que ya se les asign´o un n´umero que debe ir en el campo tipo de la cabecera CTP.
Mensaje PNACK CT.- Este mensaje indica uno o m´as paquetes de datos CT fal- tantes. Este mensaje puede ser usado cuando existan criterios de confiabilidad (relia- bility).
Mensaje FNACK CT.-Este mensaje indica que se ha recibido un paquete de datos CT con aspectos de contexto faltantes. Este tipo de mensaje tambi´en puede ser usado en casos de confiabilidad.
Mensaje abortar CT.- La transferencia de contexto debe ser abortada en dos casos: 1. El MN se mueve a un tercer AR, mientras se est´a realizando una transferencia de
contexto.
2. El contexto es innecesario, debido a que el nuevo AR determina que no necesita el contexto que le provee el AR actual (por ejemplo: en caso que el MN comience a establecer las negociaciones de contexto directamente con el nuevo AR). En ambos casos, el AR nuevo debe enviar este mensaje al AR actual para abortar la transferencia del contexto. Este mensaje es formado asignando al campo tipo de la cabecera CT el valor de 7.
Mensaje abortar caracter´ıstica de CT.-Este mensaje es usado en caso que el MN comience a establecer caracter´ısticas del contexto directamente con el nuevo AR.
Este grupo de mensajes se utilizar´an en el desarrollo de un prototipo del protocolo para la transferencia del contexto CTP. El desarrollo de este prototipo est´a fuera del alcance de este trabajo.
V.3.2
Consideraciones de seguridad
El protocolo para la transferencia de contexto (CTP) transfiere estados entre los ARs. Si los MN no son autentificados y autorizados antes de moverse en la red, existe la posibilidad de ataques del estilo DoS (Denial of Service), intercambio de estados entre los ARs, etc., causando interrupciones en la red. Para evitar introducir latencia a la transferencia de contexto debido a la necesidad del establecimiento de canales seguros entre los dos puntos (ARs), los dos ARs deben establecer tales canales anticipada- mente. Si el protocolo IPSec [Kent y Atkinson, 1998a; Kent y Atkinson, 1998b; Kent y Atkinson, 1998c] es usado, los dos ARs necesitan comprometerse (anticipadamente a cualquier transferencia del contexto) con mecanismos para el intercambio de llaves, como por ejemplo: establecer asociaciones seguras IPSec, definici´on de las llaves IPSec, algoritmos y protocolos IPSec (como ESP). Esto puede minimizar el tiempo necesitado para transmitir el contexto de un MN durante un handoff a trav´es de canales seguros. Adem´as, uno o ambos ARs deben autentificar al MN y autorizar sus credenciales antes de autorizar la transferencia de contexto o la entrega del contexto al MN. Otra conside- raci´on importante es que el MN reclame su propio contexto y no el de alg´un otro MN. Un m´etodo posible para lograr esto es a trav´es de una “cookie” de autentificaci´on, la cual ser´a incluida en la transferencia de contexto y la cual debe ser confirmada por el MN antes de que el AR nuevo pueda entregarle su contexto.