Resumen

  • RFC 1273 fue un memorando informativo sobre un estudio previsto, no la publicación de su resultado: seis campañas debían observar trece servicios TCP en unos 12.700 dominios.
  • El instrumento cerraría toda conexión aceptada sin transferir datos y distinguiría rechazo de expiración mediante reglas de parada diferentes. Esos estados no demostraban uso, seguridad, voluntad institucional ni causa de una desconexión.
  • Avisar a cada sitio resultó más costoso que medir y podía modificar el comportamiento; pedir permiso individual podía crear una muestra autoseleccionada. El diseño eligió anuncio público previo, origen rastreable, exclusión a petición y publicación agregada.

Una metodología sin conclusión retrospectiva

Noviembre de 1991: RFC 1273 describió seis ejecuciones planeadas para los meses alternos de 1992. Cada una duraría entre uno y dos días. La secuencia importa porque el documento no podía conocer todavía el cambio anual que aspiraba a medir.

Lo que sí dejaba fijado era el contrato del instrumento. Intentaría conexiones en aproximadamente 12.700 dominios, sobre daytime, netstat, FTP, Telnet, SMTP, DNS, Finger, Sun portmap, rlogin, rsh, UUCP, klogin y krcmd o kshell. La pregunta se situaba en la alcanzabilidad de servicios, por encima de la conectividad IP básica.

Los autores esperaban usar esa superficie como indicio de la disposición de las organizaciones a participar en computación entre instituciones. Pero el indicio no era la organización. Una respuesta de un puerto pertenecía a una máquina elegida y a un momento. La intención, la política y la capacidad de colaborar pertenecían a otro plano de realidad.

Abrir y cerrar no era usar

Si el establecimiento TCP tenía éxito, el programa cerraría la conexión y sumaría el caso. No enviaría ni recibiría datos de aplicación. El propio texto niega que fuese una prueba de seguridad y dice que no examinaría los mecanismos situados detrás de cada servicio.

El éxito probaba, como máximo, que el extremo aceptó aquella apertura. No probaba autenticación, acceso, transferencia, entrega de correo, corrección de una respuesta ni permiso para utilizar el servicio.

Tampoco había un fracaso único. Tres rechazos detenían las pruebas de ese servicio en el dominio durante la campaña. Tres expiraciones hacían abandonar el dominio, aunque podía repetirse un día después para dar margen a un problema transitorio. Un rechazo visible y un silencio agotado no compartían necesariamente mecanismo. Llamarlos simplemente “desconexión” borraría la diferencia que el programa conservaba.

El diseño examinó una alternativa menos invasiva: leer registros DNS de servicios conocidos. La descartó porque no eran obligatorios para operar la red y resultaban incompletos e incoherentes. Una declaración de directorio y una conexión directa eran evidencias de naturalezas distintas. La segunda no convertía automáticamente a la primera en falsa ni retrataba todos los servicios de un dominio.

Medir el coste del que mide

La contención estaba incorporada al código. Un éxito terminaba las pruebas de ese servicio; los topes de rechazo y expiración frenaban la repetición. El peor caso calculado era de 37 solicitudes por dominio, con una media esperada menor.

En agosto de 1991, una ejecución de prueba realizó 50.549 consultas DNS y 73.760 intentos de conexión en unas diez horas. Nunca mantuvo más de veinte operaciones de red concurrentes. La recogida se controlaba desde un único lugar, con registros y carga observados durante la ejecución y posibilidad de parada inmediata.

Esos números son evidencia del ensayo que los autores describieron. No certifican las campañas futuras, una ausencia universal de impacto ni una equivalencia con mediciones actuales. Un porcentaje de tráfico troncal y el trabajo de quien investiga una alarma local no usan el mismo denominador.

El aviso no era un canal transparente

Los primeros ensayos se anunciaron en alt.security y mediante correo individual. Cerca de la mitad de los mensajes volvieron como no entregables. RFC 1273 afirma que el tráfico y la carga administrativa de avisar superaron ampliamente a los de medir; algunos administradores consideraron innecesario el propio mensaje.

La comunicación podía además actuar sobre la variable. Un sitio advertido podía cerrar o abrir servicios. La exigencia de permiso sitio por sitio seleccionaría a quienes aceptasen participar, un grupo probablemente menos proclive a desconectarse. Una mejora de legitimidad individual alteraba la capacidad de representar al conjunto.

La tensión no anulaba el control operativo remoto. RFC 1262, nacido de las conversaciones que rodearon el estudio, mantuvo la regla general sobre impacto mínimo, contacto con proveedores y permiso explícito antes de una carga indebida. RFC 1273 documentó una solución específica: publicar el plan con antelación, difundir avisos en listas, originar las conexiones desde una cuenta testnet explicable mediante Finger y ofrecer un contacto para retirar un sitio.

Ser rastreable no equivalía a haber entregado una carta a todos. Permitía que quien detectara la actividad pudiera identificarla, preguntar y solicitar que cesara.

La tabla bruta no debía convertirse en mapa público

Una lista de servicios accesibles podía servir como hoja de ruta. El plan reservaba los datos crudos y publicaría únicamente estadísticas globales separadas de los sitios subyacentes. Esta era una decisión de custodia, no una prueba automática de anonimato perfecto.

La fuente principal es RFC 1273. RFC 1262 delimita la guía general vecina. Ninguna contiene el resultado longitudinal terminado ni demuestra que las seis campañas ocurrieran tal como se diseñaron. Tampoco autoriza a convertir una máquina observada en voz completa de su institución.

RFC 1273 conserva un orden que suele perderse: primero se hizo pública la arquitectura de la evidencia. Solo después podía aparecer una cifra de cambio. Así, el resultado futuro no podía fingir que muestra, carga, aviso y privacidad habían sido una sola cosa.