Resumen

  • El RFC 9505 divide la censura en prescripción, identificación e interferencia; una lista de bloqueo y un paquete descartado pertenecen a etapas distintas.
  • El control puede ejercerse en pasarelas, operadores, instituciones, servicios, autoridades de confianza, plataformas o dispositivos, no solo en una caja intermedia.
  • El cifrado oculta algunas señales de identificación, pero también puede trasladar la presión a metadatos, bloqueos más amplios o actores capaces de retirar el servicio.

El fallo visible llega al final

Cuando una conexión termina con un reset, una respuesta DNS extraña o un silencio, es natural escribir «bloqueada». Para operaciones, esa abreviatura puede servir. Para atribuir poder e intención, todavía faltan piezas. La congestión, una avería y una mala configuración dejan rastros parecidos. Incluso una interferencia deliberada puede ser ejecutada por una organización que solo recibió una orden de otra.

El RFC 9505, publicado en 2023 como documento informativo del IRTF, propone una gramática precisa. La prescripción decide qué contenido, usuario, protocolo o servicio debe ser censurado. La identificación reconoce tráfico o identificadores que encajan en esa regla. La interferencia bloquea el acceso o degrada la conexión. Knodel es una de seis personas autoras del estudio consensuado en PEARG; no es una norma del IETF.

Esta división impide que tres objetos se fundan. Una lista de dominios prueba que alguien seleccionó dominios, no que el sistema la aplicó. Un clasificador que marca un flujo prueba una coincidencia, no una interrupción. Una caída repetida puede demostrar un efecto en un punto de observación, pero no revela por sí sola la autoridad, la lista ni el criterio que la provocó.

Prescribir, reconocer, actuar

La primera carpeta debe guardar la decisión. ¿Quién eligió el objetivo? ¿Con qué mandato, alcance territorial, fecha de entrada y vencimiento? La prescripción puede expresarse como palabras clave, nombres, direcciones, hashes, categorías de cuentas o modelos probabilísticos. Puede cambiar sin tocar todavía la red.

La segunda carpeta debe explicar la visibilidad. Un censor puede observar un host, una URL, una cabecera, un certificado, un puerto, una dirección IP, una ruta o una huella de protocolo. La inspección profunda puede recomponer un flujo para buscar contenido. Pero la capacidad de ver no equivale a la decisión de actuar, y una acción tosca puede aplicarse sin identificar con precisión cada comunicación.

La tercera carpeta registra el resultado: manipulación de DNS, degradación, pérdida de paquetes, inyección de RST, anuncio adversario de rutas, desconexión, DDoS, retirada de servidores o presión sobre una plataforma. Dos mecanismos con costes y daños muy distintos pueden producir la misma pantalla vacía.

Por eso conviene mantener el rótulo operativo y limitar su significado. «Interferencia compatible con censura en esta red y a esta hora» puede ser una conclusión sólida. Nombrar al prescriptor desde una sola captura suele ser otra cosa: una inferencia que debe conservar su etiqueta.

El punto de control puede mudarse

El inventario del RFC recorre la arquitectura: backbone y pasarelas internacionales, ISP, instituciones, CDN, autoridades de certificados y registros, servicios, sitios de contenido y dispositivos personales. La censura no tiene un domicilio técnico único.

Un gobierno puede ordenar, un operador identificar y una aplicación ejecutar. Una plataforma puede retirar contenido sin que exista anomalía en la ruta. Un empleador puede filtrar dentro de su red. Un software en el teléfono puede impedir la conexión antes de que el proveedor la vea. También es posible combinar capas.

El RFC llama «censura en profundidad» al uso simultáneo de varios métodos o sistemas paralelos. Bloquear un mismo recurso por DNS, dirección y señal de aplicación aumenta el coste, pero reduce la posibilidad de que un único rodeo restaure el acceso. En medición, la lección es incómoda: que desaparezca un síntoma no significa necesariamente que desapareció la interferencia.

Cifrar eleva el precio, no borra el poder

El cifrado sí cambia el terreno. HTTPS oculta rutas y contenido; proteger datos del saludo puede eliminar un nombre de servidor barato de inspeccionar. El RFC 9505 considera que el crecimiento de los protocolos cifrados es una contramedida eficaz frente a algunas técnicas.

No dice que sea una cura universal. Si pierde una señal fina, el actor puede bloquear direcciones completas, rechazar el protocolo protegido, tolerar más falsos positivos o exigir que intervenga el servicio o el dispositivo. Son opciones que surgen del mapa de control, no predicciones inevitables.

En ese punto aparece el daño colateral. El RFC 7754 analiza el bloqueo según alcance, granularidad y eficacia. Una regla precisa puede perjudicar a menos terceros, aunque sea más cara y fácil de eludir. Una medida amplia puede ser barata y, al mismo tiempo, cortar usos legítimos. El documento deja fuera el juicio legal y ético particular; la técnica no sustituye el contexto.

Una fotografía de investigación

El RFC 9505 compila literatura y ejemplos empíricos disponibles al redactarse. Se define como una fotografía temporal, pide actualizaciones comparables y no ofrece recomendaciones para protocolos individuales. Sus casos no deben reciclarse como si fueran mediciones actuales de cada país.

Esa cautela coincide con otra lección documental. El RFC 6973 separa correlación, identificación y contexto al evaluar privacidad: la propiedad de un protocolo no determina por sí sola la conducta de un sistema desplegado. El RFC 8890 formula la posición del IAB de favorecer a los usuarios finales cuando sus intereses chocan con otros. Ninguno permite convertir un timeout aislado en una certeza política.

El valor del trabajo de Knodel y sus coautores está en ordenar la investigación. Antes de afirmar que «Internet fue bloqueado», hay que preguntar qué se prescribió, cómo se reconoció y dónde se intervino. El paquete descartado es real; la historia completa exige unir los registros correctos.

Fuentes