Resumen

  • RFC 831 fue una propuesta para discusión de diciembre de 1982, no un estándar ni la prueba de que el diseño se desplegara. Su objetivo era conservar acceso de software a la parte europea de SATNET durante una partición.
  • Un host multiconectado, M, aplicaría lógica de encaminamiento de origen y cambiaría origen y destino en ambos sentidos, pero no enviaría actualizaciones de rutas. Podía ejecutar una función de gateway sin reclamar autoridad de tránsito.
  • Cuando el equipo remoto no podía invertir la ruta registrada, M aprendía una correspondencia de vuelta llamada “soft state”. El documento no definía autenticación, caducidad, borrado ni auditoría, y la clave ambigua admitía un único host estadounidense por objetivo.

La restricción de uno contaba una historia de dos extremos

Para entender aquella colisión hay que reconstruir primero la rotura. El host de control H solía atravesar Internet hasta el gateway B de BBN, entrar en SATNET por el SIMP S1, cruzar la red de satélite hacia S2 y alcanzar el gateway G de University College London. Una partición hacía que S2, G y un controlador de acceso terminal de UCL resultaran inalcanzables desde los gateways estadounidenses. El paquete ordinario podía acabar en ICMP Unreachable.

En dirección contraria ocurría lo mismo: H no era alcanzable desde el lado británico. Una solicitud introducida por algún paso alternativo no era útil si la respuesta seguía apuntando a una dirección que el Reino Unido no podía encaminar.

Robert Braden planteó esa dificultad en RFC 831. El memorando utilizaba la expresión “back door” para el acceso alternativo y declaraba que el planteamiento no pretendía ser un estándar en ese momento. Por tanto, debemos leerlo como diseño sometido a discusión, no como crónica de una recuperación real.

La cadena propuesta salía de H, llegaba al gateway VAN, cruzaba un túnel IP de VANNET, entraba en un sistema de UCL, recorría UCLNET y terminaba en G y S2. El código especial se concentraba en H y/o en el extremo de UCL. G, S2 y el gateway VAN no tenían que cambiar.

Una emergencia no justificaba anunciar UCLNET

El extremo ordinario U del túnel tenía que seguir siendo un host. Si funcionara como gateway, el gateway VAN podría aprender a través de él una ruta hacia UCLNET y desviar por VANNET tráfico normal destinado a UCL o RSRE. El remedio de mantenimiento capturaría comunicaciones ajenas a la avería.

La alternativa era M, el “Header Munger”, con dos presencias: M2 en VANNET y M1 en UCLNET. M necesitaba el algoritmo con el que un gateway procesa una ruta de origen, pero fuera de esa operación actuaría como dos hosts y no publicaría actualizaciones de routing.

Esa frase dibuja una frontera institucional. Ejecutar el algoritmo sobre un paquete concreto no equivale a decirle a la red que entregue a M cualquier paquete para una familia de destinos. La primera facultad es una excepción de datos; la segunda cambia la topología compartida. RFC 831 quería la excepción y rechazaba la reclamación general.

Por eso “no anunciar” era una propiedad positiva del sistema. El diseño no se limitaba a lograr que el tráfico pasara. También preservaba la ruta normal para quienes no participaban en la reparación.

Reescribir solo un campo no bastaba

H podía alcanzar M2 y dirigía allí la petición. Una vez recibida, M sustituía la dirección de origen por M1 y la de destino por S2. G veía entonces un paquete con extremos utilizables en UCLNET.

S2 contestaba a M1. En el camino inverso, M cambiaba de nuevo las direcciones para producir un paquete encaminable por VANNET e Internet hasta H. La doble transformación reparaba dos ausencias distintas. Modificar únicamente el destino no daba a S2 una ruta de vuelta a H; modificar únicamente el origen no llevaba la solicitud desde Estados Unidos hasta la parte aislada.

Cada sustitución afectaba a la evidencia. Los registros posteriores podían atribuir la solicitud a M1, no a H. Los sistemas anteriores podían conocer M2 y no la identidad observada por S2. Un retorno correcto probaba continuidad en una cadena determinada, no la identidad de la persona, el permiso para intervenir en S2 ni la aplicación satisfactoria de un cambio.

La comparación posterior con NAT es útil solo si se mantiene esa distancia. RFC 3022 sistematizó mucho después las traducciones estáticas y dinámicas y el intercambio entre significado de extremo a extremo y estado interno. RFC 831 no se autodenominó NAT, no lo inventó y las fuentes no establecen una genealogía directa.

Dirección fija, retorno grabado o memoria aprendida

El memorando estudiaba primero una correspondencia fija. M podía responder por varios pares de direcciones M1/M2 y asociarlos administrativamente a fuentes estadounidenses y destinos SATNET. La tabla era explícita, pero cada relación exigía planificación previa.

Otra posibilidad era usar source routing en ambos sentidos. RFC 791 definió las opciones Loose y Strict Source and Record Route. El origen enumeraba hitos; al llegar a uno, el siguiente sustituía el destino IP y la interfaz actual quedaba anotada. Un receptor capaz de invertir la lista podía crear la vuelta.

G entendía ese mecanismo, pero S2 o el controlador terminal podían no saber invertir el recorrido. De ahí el método híbrido preferido: H enviaba una ruta de origen hacia M; al procesarla, M aprendía la asociación entre H y el objetivo SATNET; una respuesta ordinaria a M1 podía utilizar luego esa asociación para volver a H.

RFC 831 llamó “soft state” a la correspondencia. La etiqueta no incluía un contrato completo de vida. No hay tiempo de refresco, temporizador de expiración, regla de eliminación, recuperación tras caída ni auditoría. Tampoco hay un procedimiento de autenticación para crearla.

Y precisamente ahí reaparece la restricción inicial. Una respuesta sin ruta de retorno solo identificaba suficientemente el destino SATNET. Si dos hosts estadounidenses hablaban a la vez con ese mismo destino, M no sabía a cuál entregar la respuesta. “Uno por objetivo” documentaba una pérdida de contexto, no una medida de rendimiento.

El precio de la llamada orientaba el túnel

VANNET utilizaba X.25 conmutado y pagaba quien iniciaba la llamada. En la operación habitual, UCL abría el túnel desde U. Para llegar a M2, lo abría el extremo estadounidense. El sentido de establecimiento decidía tanto la disponibilidad como la factura.

UCL solo tenía una línea física PSS. Alojar U y M sobre ella requería subdirecciones X.25 diferentes. Además, el gateway VAN debía manejar direcciones X.121 de catorce dígitos, no solo las de doce. La validez de una idea IP dependía de dos dígitos en un equipo subyacente.

No hay que convertir ese dato en una teoría universal sobre costes. Su valor está en demostrar que una ruta de contingencia es también una lista de circuitos, formatos, iniciadores y cuentas. Quien solo conserva el dibujo IP puede descubrir durante el incidente que nadie puede colocar la llamada.

Las obligaciones seguían al acto, no a la etiqueta de la máquina

Más tarde, RFC 1122 permitió que un host actuara como salto intermedio de una ruta de origen, pero exigió un comportamiento comparable al de un gateway: procesamiento de TTL, ICMP y opciones. El forwarding a un destino no local debía depender de un interruptor configurable, desactivado por defecto, y de filtros de política.

Así quedaba formalizado el papel extraño de M. Seguir llamándolo host no reducía las consecuencias del acto de encaminamiento. El software debía cumplir las responsabilidades del salto que estaba representando.

Las expectativas operativas cambiaron gradualmente. En 1995, RFC 1812 todavía exigía a los routers soportar las opciones de ruta de origen al reenviar y contemplaba un interruptor de descarte que no estaba activo por defecto. Es evidencia histórica de otro punto de partida, no una configuración aconsejable ahora.

RFC 6274 evaluó después riesgos como eludir firewalls, alcanzar sistemas que de otro modo serían inaccesibles, ocultar conexiones, descubrir topología y agotar recursos. Recomendó descartar por defecto. RFC 7126 constató que el filtrado extendido había vuelto LSRR prácticamente inútil para diagnóstico y recomendó controles documentados por opción, manteniendo el descarte como postura normal.

Por eso la especificación de un mecanismo nunca garantizó su disponibilidad universal. El desvío de RFC 831 dependía del consentimiento de operadores que conservaban el derecho local a rechazar la opción.

El nombre “middlebox” explica el mecanismo, no el mandato

El posterior RFC 3234 utilizó middlebox para intermediarios que transforman o desvían flujos más allá del routing IP ordinario. M encaja analíticamente: cambiaba cabeceras, mantenía una asociación y agregaba fallos y configuración. El memorando de 1982 no empleó ese término.

Pero clasificar no responde quién puede invocar M, qué destinos admite, cuándo acaba el estado o quién demuestra su limpieza. Llamarlo gateway puede ser aún más confuso, porque sugiere una autoridad de tránsito que el diseño negaba explícitamente.

La descripción ajustada es más larga y más exacta: host multiconectado, con procesamiento de gateway para tráfico de mantenimiento seleccionado, sin actualizaciones de rutas. La ausencia de anuncio era parte de su mandato.

Recibir una respuesta no era recibir autorización

RFC 831 no definió autenticación, autorización de destinos, cifrado, comandos de mantenimiento, aprobación de cambios ni un recibo del resultado. “Back door” nombraba una vía alternativa, no un ataque. Sin embargo, toda vía alternativa abre una capacidad que la topología ordinaria había cerrado.

El operador debe mantener separados cuatro hechos: la petición llegó a la entrada; el principal quedó identificado; la acción y el objetivo fueron autorizados; el sistema final confirmó el resultado. El paquete que M consigue devolver apoya el primero. No reemplaza los demás.

La aportación duradera del diseño fue su negativa a convertir la necesidad en autoridad general. El código especial estaba localizado, el tráfico común no debía desviarse y M no proclamaba un camino hacia UCLNET.

La puerta trasera seguía siendo puerta porque no se anunciaba como ruta.