Resumen

  • RFC 2351 separó dos clases de tráfico sobre un transporte común: Type A privilegiaba la respuesta rápida y permitía repetir tras el silencio; Type B privilegiaba protección, múltiples destinatarios y prioridades.
  • Abrir TCP y aceptar una sesión MATIP demostraba que los extremos coincidían en cómo transportar el flujo. No demostraba que hubiera asiento reservado, billete emitido, repetición segura o responsabilidad de mensaje transferida.

La migración de una red rara vez coincide con la migración del trabajo que circula por ella. En 1998, muchas oficinas de aerolíneas seguían usando terminales y aplicaciones centrales nacidas décadas antes, aunque TCP/IP ya ofrecía pilas baratas e intranets comunes. Sustituir el medio de transporte era viable; reescribir reservas, emisión y mensajería no lo era.

RFC 2351 propuso MATIP, Mapping of Airline Traffic over Internet Protocol. Su propósito era poner una capa interoperable entre TCP y la aplicación aérea, evitando una colección de pasarelas propietarias que no escalaban. La decisión importante fue no reducir todo el trabajo de la aviación a una sola idea de “entrega”.

En Type A, el silencio podía provocar otra petición

Type A incluía el diálogo entre una agencia u oficina y el ordenador central de reservas o billetes. Era tráfico interactivo, prioritario y con protección limitada. El RFC admitía que podía descartarse y señalaba que, ante la falta de respuesta por pérdida, el usuario podía duplicar la solicitud.

Eso describe una práctica de recuperación, no una propiedad automática de toda transacción. Consultar disponibilidad dos veces puede ser inocuo; ejecutar dos veces una venta puede no serlo. RFC 2351 no definió una clave universal de idempotencia ni un libro de conciliación para las aplicaciones. La capa superior debía decidir si la repetición era una consulta, un duplicado o una segunda orden válida.

MATIP sí conservaba el contexto necesario para llegar a esa capa. El inicio de sesión negociaba subtipo, codificación, presentación, cabecera y multiplexación. H1, H2, A1 y A2 podían identificar una unidad de terminales con independencia de la dirección IP. Un Flow ID separaba flujos host a host. Esos campos dirigían el tráfico; no probaban quién tenía autoridad para reservar ni qué escribió el sistema central.

Type B necesitaba otro tipo de recibo

Type B era mensajería. No dependía de la inmediatez, pero exigía mayor protección, multidifusión a destinatarios y cuatro niveles de prioridad. Sobre MATIP podía operar BATAP, el protocolo de aplicación a aplicación para asegurar el tráfico Type B.

La apertura de Type B incluía PROTEC, que identificaba el protocolo de transferencia de responsabilidad de extremo a extremo. Si los extremos proponían mecanismos distintos, Open Confirm podía rechazar la sesión. Los HLD podían identificar emisor y receptor; también podía usarse la pareja de direcciones IP.

La compatibilidad no era el resultado. Compartir el valor de PROTEC decía que ambos lados entendían el mismo mecanismo. No decía que un mensaje concreto hubiera sido aceptado por BATAP, que todos los destinatarios lo hubieran recibido o que la responsabilidad hubiera cambiado de manos. Para eso hacía falta el acuse de la aplicación y el estado posterior.

Los puertos conservaban la diferencia

IANA asignó el puerto TCP 350 a Type A y el 351 a Type B. Cada conjunto de parámetros requería conexión y sesión propias. Session Open anunciaba las características; Open Confirm aceptaba o rechazaba; Session Close cerraba MATIP. La especificación no añadió un keep-alive propio y dejó los tiempos de espera a TCP.

Los estados se tocaban, pero no eran iguales. MATIP solo podía permanecer abierto si TCP seguía activo, aunque cerrar MATIP no obligaba a cerrar TCP. Por tanto, una conexión TCP viva era una condición, no un recibo de servicio. Una sesión MATIP aceptada era un acuerdo de formato, no una constancia de negocio terminado.

RFC 793 prometía un flujo de bytes fiable y ordenado entre procesos. RFC 1122 fijaba obligaciones para la implementación de las capas de comunicación. Ninguna de esas capas podía ver el inventario de plazas, el número de billete o la aceptación final de un mensaje.

La cadena útil empieza con la ruta y el establecimiento TCP; sigue con Session Open, Open Confirm, la identidad ASCU, Flow ID o HLD, la entrega de datos y el acuse de aplicación; termina con la transferencia de responsabilidad, la escritura del estado comercial y la conciliación de duplicados. Saltarse un eslabón convierte una señal técnica en una prueba que no posee.

La advertencia de seguridad mostraba el precio de la compatibilidad

RFC 2351 permitía reconocer un ASCU por configuración estática o por usuario y contraseña. El cortafuegos podía filtrar por IP o en la capa de aplicación. IPsec ESP y AH aparecían como opciones. El RFC Editor advierte hoy que identificadores estáticos y contraseñas aparentemente en claro no ofrecen seguridad sólida, y que la protección fuerte quedó como facultativa.

La observación limita, pero no invalida, el diseño. MATIP resolvía transporte e interoperabilidad; no podía convertir un identificador heredado en autorización criptográfica. RFC 4301 describe después políticas y asociaciones de seguridad para IPsec. Incluso con esa arquitectura, disponer de la capacidad no demuestra que un intercambio determinado la utilizara: hace falta un registro operativo.

La lección histórica de RFC 2351 es que una red común no exige una ficción común. IP podía transportar consultas rápidas y mensajes protegidos. La responsabilidad de definir silencio, acuse y finalización seguía donde existían los hechos: en las aplicaciones y en sus recibos.

Fuentes