Resumen
- El RFC 9511 ofrece un lugar previsible, especialmente
/.well-known/probing.txt, para que el responsable de una medición publique su propósito, vigencia y vía de contacto. - Esa información sirve para acotar una investigación, no para aprobar automáticamente el tráfico: puede ser falsa, quedar obsoleta o señalar a un tercero, por lo que el receptor conserva la decisión de verificar, limitar o bloquear.
Una medición para uno, una incidencia para otro
Quien diseña una prueba ve una herramienta: ping, traceroute, una conexión TCP o un paquete IPv6 construido para observar qué sobrevive en el trayecto. Quien lo recibe ve primero un origen desconocido. Aunque el ritmo sea bajo, el paquete puede parecer reconocimiento, activar una regla o iniciar una revisión manual.
La carga está mal repartida. El emisor conoce el objetivo y la duración del experimento. El receptor sólo conoce lo que llegó. Debe recuperar registros, comprobar frecuencia, resolver DNS, buscar datos de abuso y decidir si el patrón merece una escalada.
El RFC 9511, publicado en noviembre de 2023, intenta reducir esa distancia. Sus autores son Eric Vyncke, Benoît Donnet y Justin Iurman. El documento es Informativo y pasó por la revisión de la IETF; no obliga a los operadores ni convierte la medición activa en una actividad autorizada por defecto.
Su pregunta es más modesta: ¿puede el emisor dejar una pista suficientemente estable para que, después de observar el paquete, otra organización descubra qué se afirma que es, para qué se envió y con quién hablar? La respuesta evita crear un registro central de sondas y evita colocar una decisión de confianza dentro de los routers.
El archivo que abre una conversación
El mecanismo básico es un “Probe Description URI”. Puede apuntar a un archivo, una dirección de correo o un número telefónico. Cuando se usa un archivo, la ruta normalizada es /.well-known/probing.txt. El formato aprovecha la estructura de security.txt del RFC 9116: ubicación canónica, contacto, caducidad e idiomas preferidos. Añade además una descripción de una sola línea para la medición.
El diseño obliga a hacer visible el mantenimiento. Una fecha de caducidad reconoce que una campaña termina y que un dato viejo no debe seguir hablando por la organización. Un contacto genérico evita publicar información personal y hace posible que un equipo, no una sola persona, atienda reclamaciones. Los idiomas preferidos permiten que la atribución funcione entre redes de países diferentes.
La lista de URI bien conocidos de IANA registra probing.txt como sufijo permanente bajo control de cambio de la IETF. Ese registro dice dónde buscar y qué RFC consultar. No valida el contenido alojado en cada dominio. La coordinación común termina en la dirección; la credibilidad se construye después.
Separar la etiqueta del paquete
El método fuera de banda parte de la dirección de origen. Si existe DNS inverso, el analista puede derivar el dominio y buscar allí el archivo. También puede consultar directamente al host de origen. La investigación ocurre fuera del plano de datos y puede hacerse con una captura guardada. Como no se añaden bytes, la sonda conserva mejor la forma que se pretendía medir.
La debilidad está en la relación entre dirección y responsable. NAT, direcciones dinámicas y dispositivos de terceros rompen una asociación simple. RIPE Atlas documenta una red mundial de sondas y anclas alojadas por voluntarios que realizan mediciones activas. En ese modelo, quien hospeda el dispositivo, quien administra la dirección y quien solicita una medición personalizada pueden no ser la misma entidad.
El DNS y la dirección son, por tanto, piezas de evidencia. Son más útiles cuando coinciden con rangos publicados, un archivo vigente y un contacto que responde. No son una sentencia automática de autoría.
Llevar la explicación dentro de la sonda
La alternativa coloca el URI en el propio paquete: al principio de la carga útil de ICMP, UDP o TCP, o dentro de una opción de IPv6. La declaración viaja con el evento y puede seguir funcionando cuando no hay DNS inverso o el dueño de la campaña no controla el alojamiento asociado al origen.
Ese acercamiento introduce el problema del observador. Una carga adicional puede cambiar el tamaño y superar el MTU del camino. Un SYN TCP con datos puede recibir un trato distinto. Ciertas opciones de IPv6 son descartadas por implementaciones que esperan otra forma. La sonda etiquetada puede dejar de recorrer el mismo Internet que una sonda sin etiqueta.
El RFC también desaconseja una cadena mágica reconocible. Un equipo intermedio podría aprenderla y aplicar un tratamiento especial. Si la favorece, la medición verá una red más permisiva de la que encuentra el tráfico común. Si la bloquea, registrará una pérdida causada por el identificador. En ambos casos, la transparencia altera la muestra.
No hay una opción dominante en todos los escenarios. Fuera de banda conserva el paquete y depende más de la asociación de direcciones. Dentro de banda acompaña a cada sonda y corre más riesgo de filtrado. Usar ambas vías añade corroboración, pero no una firma.
La frase que impide convertir el mecanismo en salvoconducto
El RFC 9511 advierte que la información no puede aceptarse ciegamente. Un atacante puede copiar el URI de una institución conocida, publicar datos falsos o dirigir las quejas hacia un tercero. Incluso un archivo legítimo puede estar vencido o describir otra campaña.
Por eso el receptor que no puede confirmar la atribución —o no quiere invertir recursos en confirmarla— debe tratar el flujo como si no hubiera atribución. La existencia de probing.txt no elimina controles normales, no prueba una intención benigna y no obliga a crear una excepción.
Autenticar exigiría vincular de manera más fuerte el paquete, la infraestructura de origen, el dueño de la campaña y una identidad aceptada por el receptor. Autorizar exigiría otra pregunta: ¿puede esa identidad medir este destino, ahora, con esa técnica y esa frecuencia? El documento no responde ninguna de las dos. Sólo hace que una afirmación sea más fácil de encontrar y contrastar.
La limitación es una virtud operativa. Muchas investigaciones no necesitan certeza instantánea; necesitan una ruta corta hacia evidencia adicional. Un rango de direcciones coherente, una fecha actual y un buzón atendido pueden convertir una búsqueda abierta en una verificación concreta. El receptor puede cerrar un falso positivo antes o bloquear con mayor precisión.
La práctica declarada del NCSC
El RFC menciona un ejemplo próximo: la actividad pública de escaneo del National Cyber Security Centre del Reino Unido. Su página de información enumera direcciones, señala DNS directo e inverso coincidente, describe una cabecera HTTP identificadora, explica precauciones y ofrece un canal para solicitar exclusión.
No hay una señal única que baste. La cabecera se puede copiar. Una dirección puede aparecer en otro contexto. La página puede quedarse atrás. La capacidad de comparar varios hechos y contactar con una institución responsable es lo que vuelve útil la declaración.
Además, publicar traslada parte del coste al emisor. Debe mantener rangos y caducidades, responder consultas, procesar exclusiones y vigilar posibles suplantaciones. Si nadie atiende el canal, la etiqueta pierde rápidamente su valor. La responsabilidad se expresa en mantenimiento, no sólo en sintaxis.
Eric Vyncke como hilo conductor, no como dueño único
El perfil de Eric Vyncke en el Datatracker de la IETF lo identifica como director del Área de Internet y sitúa su trabajo en estándares, IPv6, telemetría y seguridad. Registra siete RFC, entre ellos el 9511. La página de miembros de la IESG también lo incluye entre los directores actuales del área.
Esos datos justifican una lectura personal del expediente técnico, no una historia de inventor solitario. El RFC tiene tres autores, reutiliza piezas normativas anteriores y fue revisado colectivamente. IANA mantiene el punto de encuentro. Los operadores de medición deciden publicar. Las redes receptoras deciden creer, investigar o filtrar.
El RFC 7404, que Vyncke coescribió con Michael Behringer, estudió otra elección acotada: usar sólo direcciones link-local en enlaces de infraestructura IPv6. Enumeró ventajas y problemas y dejó la decisión al contexto del operador. En el RFC 9511 aparece la misma disciplina: definir una opción utilizable sin venderla como conclusión universal.
Una mejora en la legibilidad, no en la autoridad
La atribución puede ofrecer propósito, contacto, caducidad y un sitio estable para actualizar información. No demuestra quién controla realmente el paquete. No vuelve ética una campaña. No garantiza que la etiqueta sobreviva. No ordena al receptor permitir nada.
La utilidad está precisamente en esa escala. En un Internet administrado por miles de organizaciones independientes, un mecanismo global no necesita decidir por todas ellas. Puede limitarse a mejorar los datos disponibles para que cada una tome su decisión con menos fricción.
Límites de la evidencia
Las fuentes confirman autores, contenido y estatus del RFC, el registro de IANA, las funciones institucionales declaradas, la práctica publicada del NCSC y el modelo documentado de RIPE Atlas. No muestran cuántos operadores publican o consultan probing.txt, ni permiten medir una reducción de alertas.
Tampoco establecen que Eric Vyncke controle una plataforma concreta, una política de Cisco o la reacción de ninguna red. La atribución personal debe respetar el carácter compartido del trabajo.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
