Summary

  • FTP negociaba comandos por una conexión de control y enviaba los archivos por una conexión de datos independiente.
  • RFC 1579 reutilizó PASV para cambiar quién iniciaba esa segunda conexión: facilitaba el filtrado en el lado cliente, pero exigía al servidor aceptar puertos entrantes.

Una sesión FTP podía decir «envía este archivo» sin que el archivo viajara por la conexión que llevaba el comando. Esa separación estaba en su diseño. En la práctica, abrir la sesión y recibir una respuesta positiva a RETR no garantizaba que llegaran los bytes: todavía había que establecer otra conexión TCP en la dirección elegida por FTP.

La especificación de 1985, RFC 959, separaba un proceso de control para comandos y respuestas de los procesos de datos para transferencias. En el patrón habitual, el cliente abría la conexión de control hacia el servidor, normalmente en el puerto 21. Antes de transferir, podía enviar PORT con su dirección y un puerto donde quedaría a la escucha. Entonces el servidor iniciaba la conexión de datos hacia el cliente. Como el canal de datos era distinto del canal de comandos, un cortafuegos que permitía el primero no tenía por qué permitir el segundo.

El protocolo ya incluía otra modalidad. Con PASV, el cliente pedía al proceso de datos del servidor que escuchara en un puerto no predeterminado. El servidor devolvía la dirección y el puerto, y el cliente abría la conexión de datos hacia él. El archivo seguía usando una segunda conexión; cambiaba quién la iniciaba. Por tanto, el modo pasivo existía años antes de convertirse en la respuesta recomendada al filtrado de paquetes.

Para 1994, la práctica no siempre coincidía con el modelo predeterminado original. Steven Bellovin escribió en RFC 1579 que los clientes solían abrir una nueva conexión de datos por transferencia, elegir un puerto nuevo para evitar la espera TCP TIME-WAIT y anunciarlo con PORT. Un filtro podía ver una llamada entrante a un puerto imprevisible. Los cortafuegos a menudo aceptaban algunos servicios entrantes y rechazaban esas conexiones, incluso después de que el usuario se hubiera autenticado por el canal de control.

RFC 1579 recomendó a los proveedores convertir los clientes FTP, incluidos los agentes proxy de Gopher, para que usaran PASV en vez de PORT. Así, el canal de datos se convertía en una llamada saliente desde el cliente. Para el cortafuegos del usuario, era más sencillo permitir esa apertura que aceptar una conexión entrante no solicitada a un puerto aleatorio. La nota no proponía cambiar el protocolo: el comando ya existía y ambos modos intercambiaban un mensaje de preparación parecido antes de transferir.

La solución desplazó el límite difícil; no lo eliminó. En modo pasivo, el servidor debía aceptar llamadas entrantes a los puertos elegidos para transferencias. RFC 1579 reconoció que eso podía crear un problema de cortafuegos en el servidor. Su argumento era administrativo: había muchos menos servidores que clientes, y sus operadores podían limitar el rango de puertos de datos. Era una propuesta sobre dónde gestionar la exposición, no una prueba de adopción universal.

Los documentos normativos ayudan a separar una capacidad exigida de un comportamiento realmente extendido. RFC 1123, publicado en 1989, exigía que los servidores FTP implementaran PASV y aclaraba cómo interpretar su respuesta, aunque observaba que el formato aún no estaba bien normalizado. RFC 1579 dijo después que existían al menos dos clientes modificados independientes. Ninguno mide cuántos usuarios o sitios cambiaron de modo. La nota de 1994 registra una recomendación y unas pocas implementaciones, no una migración completa.

FTP tenía dos superficies operativas. La conexión de control llevaba credenciales, comandos y respuestas; la de datos transportaba un listado o archivo. Una respuesta como «abriendo conexión de datos» no era el archivo, y una autenticación correcta no demostraba que la transferencia hubiera terminado. Para diagnosticar había que seguir ambos sockets y determinar qué extremo debía iniciar cada uno.

La lección de RFC 1579 es más concreta que «los cortafuegos rompieron FTP». El protocolo ya ofrecía una elección sobre quién abría la conexión de datos. El filtrado hizo que esa elección tuviera consecuencias. PASV permitía iniciar desde el lado donde el cortafuegos del cliente tenía más probabilidades de autorizarlo, a cambio de que el operador del servidor gestionara un rango limitado de puertos entrantes. El protocolo no cambió; se trasladó la carga operativa.

Sources