Resumen

  • La comunidad bien conocida BLACKHOLE expresa una solicitud consultiva: descartar el tráfico destinado al prefijo marcado. El receptor solo la ejecuta si existe acuerdo previo, autorización de prefijo y política local explícita.
  • El RTBH por destino protege capacidad compartida instalando una ruta de descarte más específica. El ataque deja de cruzar el enlace, pero el tráfico legítimo hacia la misma dirección también desaparece.
  • La auditoría debe unir UPDATE, sesión, prefijo autorizado, aprobación del incidente, estado ROV, política de importación, contención, RIB, FIB, contadores, paquetes, retirada y recuperación. “Established” no demuestra que el servicio siga vivo.

La mitigación que apaga su objetivo

Imaginemos un cliente de tránsito que recibe un ataque contra 203.0.113.19. El caudal llena su circuito antes de llegar a cualquier filtro local. El cliente anuncia 203.0.113.19/32 a su proveedor con la comunidad BLACKHOLE. La sesión está habilitada para el servicio y el proveedor reconoce que el cliente puede anunciar el agregado 203.0.113.0/24.

La política acepta el /32 y los routers de entrada resuelven su siguiente salto a descarte. El tráfico deja de ocupar el circuito. Eso incluye los paquetes del atacante y las conexiones legítimas. El resto del /24 continúa accesible. El mecanismo salva el recurso común sacrificando la dirección atacada.

Después, un sistema automático envía 203.0.113.91/32, una aplicación sana dentro del mismo agregado. El vecino, la cobertura y la comunidad siguen siendo correctos. Si esos son los únicos controles, la red ejecuta una solicitud bien formada con una intención equivocada. No hay caída de sesión ni retirada de la ruta agregada; solo silencio en la aplicación seleccionada.

El caso es sintético. Su utilidad consiste en separar la seguridad formal del resultado: estar autorizado para anunciar dentro de un bloque no prueba que alguien haya decidido correctamente qué host debe dejar de existir durante ese incidente.

65535:666 es una palabra, no un mando a distancia

RFC 7999 define BLACKHOLE como una comunidad BGP consultiva, transitiva y bien conocida. IANA registra 0xFFFF029A; la notación habitual es 65535:666. El valor común reduce la dependencia de códigos privados diferentes en cada proveedor.

Pero el documento deja la ejecución en manos del receptor. Cada operador decide si la acepta y la honra. En una relación bilateral, ambas redes deben acordar su uso antes de anunciarla. Sin una directiva explícita, un equipo no debería descartar tráfico solo porque reconoce el valor.

La normalización fija una semántica mínima. No concede a un AS autoridad universal sobre el plano de reenvío de otro. El emisor formula una petición; el receptor determina si la sesión, el prefijo y su política constituyen una delegación válida. Una tercera red puede ignorar el atributo, conservarlo para observación o eliminarlo según su política.

Esa es una aplicación directa de la decisión futura localizada de Heng Lu. Lo común es estrecho: código y significado. La oferta comercial, los clientes admitidos, la región, la duración y la acción FIB permanecen locales. No adoptar el servicio no convierte a una red en incumplidora.

Una ruta elegida para no reenviar

En el RTBH por destino, los routers participantes disponen de una ruta hacia una interfaz nula o de descarte. Una política asociada a la comunidad hace que el prefijo más específico resuelva hacia esa ruta. Los paquetes se eliminan cerca de los puntos de entrada y no consumen la capacidad que conduce al cliente.

Esto rompe una inferencia habitual. La presencia de la ruta en Loc-RIB no significa que haya entrega. Puede ser la mejor ruta precisamente porque su disposición es tirar los paquetes. Hace falta inspeccionar FIB, resolución del siguiente salto y acción efectiva en cada clase de ingreso.

RFC 5635 explica el coste sin ambigüedad: el blackhole por destino deja la víctima completamente fuera de línea. El beneficio es limitar el daño colateral sobre el resto del cliente o de la red. Por eso un informe debe mostrar dos indicadores distintos: capacidad protegida y disponibilidad de la dirección sacrificada.

Un descenso de tráfico en el enlace puede ser éxito de contención y fracaso de servicio. Si la dirección crítica pertenecía a autenticación, DNS o control, el daño comercial puede superar el alivio técnico. La decisión no puede delegarse a un contador sin contexto.

Autorización de espacio no equivale a autorización de incidente

RFC 7999 impone dos condiciones al receptor bilateral. El prefijo debe estar cubierto por otro igual o menos específico que el vecino esté autorizado a anunciar. Además, el receptor debe haber acordado honrar la comunidad en esa sesión concreta.

El primer control evita que un cliente anule destinos ajenos. El segundo evita que cualquier peering se convierta por accidente en un canal de descarte. Juntos fijan quién y sobre qué espacio puede pedir la acción.

No fijan por completo por qué ni hasta cuándo. Un /32 equivocado sigue dentro del /24 correcto. Una credencial puede estar comprometida. Una solicitud anterior puede reaparecer cuando ya no existe el ataque. BGP no incorpora un expediente de crisis verificable con aprobador, servicio, caducidad y responsable de retirada.

El sistema operativo debe aportar ese tercer control. Cada activación necesita identidad del solicitante, incidente, dirección exacta, servicio afectado, razón, alcance, hora, vencimiento y propietario de la reversión. El registro se enlaza con la sesión, AFI/SAFI y versión de política que procesaron el UPDATE.

El filtro determinista limita errores y abuso. La aprobación contextual limita el poder de una automatización técnicamente autorizada. Ninguno sustituye al otro.

El host route más preciso atraviesa una frontera

Para reducir daño colateral, RFC 7999 recomienda la mayor especificidad posible: normalmente /32 en IPv4 y /128 en IPv6. En el Internet global, sin embargo, suelen filtrarse rutas más largas que /24 y /48.

El servicio RTBH abre una excepción intencionada. Acepta una ruta que el tránsito ordinario rechazaría, la usa dentro del dominio de descarte y evita que escape como ruta pública. Esa excepción debe combinar agregados autorizados, longitudes permitidas, sesión, comunidad, alcance geográfico y acción local.

La especificidad reduce cantidad de direcciones afectadas, no garantiza que la dirección sea correcta. Un solo /32 puede alojar una función crítica. Un /24 puede ser necesario ante un ataque amplio, pero elimina muchas aplicaciones. La longitud de prefijo es una decisión de impacto.

También hay que controlar simultaneidad y tiempo. Un cliente con permiso permanente para generar cientos de host routes posee una superficie de apagado mucho mayor que la que expresa un simple filtro de cobertura. Establecer máximos, exclusiones y caducidad convierte la autorización abstracta en una capacidad limitada.

La ruta destructiva no debe viajar libremente

RFC 7999 recomienda añadir NO_ADVERTISE, NO_EXPORT o una marca equivalente. RFC 1997 distingue sus efectos: la primera impide anunciar la ruta a cualquier otro par; la segunda permite distribución interna, pero bloquea la salida del AS o de la confederación.

Un proveedor puede necesitar que todos sus bordes de ingreso conozcan la ruta. También puede limitar el descarte a una región donde entra el ataque. El control elegido debe reproducir ese diseño. Aplicar NO_ADVERTISE demasiado pronto puede impedir la distribución necesaria; depender de NO_EXPORT sin filtros puede no cubrir una redistribución inesperada.

Una fuga de la ruta más específica puede atraer tráfico por longest-prefix match aunque la siguiente red ignore la semántica BLACKHOLE. Si la honra, el descarte se extiende. RFC 5635 recomienda filtros de egreso precisamente porque el trigger puede escapar.

FRRouting documenta que añade NO_ADVERTISE automáticamente cuando recibe BLACKHOLE. Es un dato de una implementación actual, no una propiedad universal. Otro equipo puede exigir una política explícita; una regla que sustituye comunidades puede retirar la protección añadida.

La comprobación válida es el Adj-RIB-Out posterior a política para cada vecino relevante. La configuración deseada no demuestra lo que el equipo estuvo dispuesto a anunciar.

Un canal autenticado puede transportar una intención falsa

La comunidad clásica vive en un atributo que RFC 1997 permite modificar según política local. RFC 7999 advierte que BGP no impide de forma específica que un agente añada, quite o altere comunidades. BGPsec tampoco resuelve esa integridad. Añadir BLACKHOLE sin permiso puede causar denegación de alcanzabilidad.

Autenticar la sesión limita la suplantación del par, pero no verifica que el operador eligiera el servicio correcto. RPKI valida otra relación: prefijo, AS de origen y maxLength de los VRP. No firma la comunidad ni el objetivo del incidente.

La interacción con ROV es delicada. Un /32 legítimo de blackhole puede resultar Invalid si la ROA solo permite el /24. RFC 7999 pide evitar que la validación bloquee inadvertidamente esos anuncios. Convertir BLACKHOLE en exención general sería peligroso porque un atributo modificable actuaría como bypass. Ampliar todas las ROA hasta host length también aumenta la clase de más específicos que pueden validar.

En 2022, un Internet-Draft individual propuso una Discard Origin Authorization firmada para separar ambos permisos. El borrador expiró y no tiene estatus formal del IETF. Sirve para entender la brecha; no es un mecanismo desplegado que pueda marcarse como control existente.

La decisión actual requiere varios testimonios independientes: identidad de sesión, prefijo permitido, tratamiento ROV, comunidad exacta, autorización de incidente, política local y FIB observada.

Destino, fuente, FlowSpec y scrubbing no son sinónimos

El RTBH por destino descarta todo lo dirigido al objetivo. El RTBH por fuente combina rutas de descarte con uRPF para hacer fallar la comprobación del origen del paquete en puntos elegidos. RFC 5635 indica que no debe reutilizarse la comunidad de destino y que esas rutas de fuente deberían proceder de sistemas locales de mitigación, no de pares externos de manera ordinaria.

FlowSpec distribuye reglas de coincidencia y acción para flujos; RFC 7999 dice que BLACKHOLE no está destinado a sus NLRI. Un sinkhole redirige tráfico para observarlo. El scrubbing trata de conservar tráfico legítimo. El blackhole por destino no clasifica ni limpia: elimina.

Nombrar correctamente el mecanismo evita afirmar que la víctima fue protegida cuando en realidad fue desconectada para proteger el entorno.

Prueba desde el UPDATE hasta el paquete ausente

El registro previo debe enumerar cliente, sesión, AFI/SAFI, bloques, longitudes, comunidad, destinos excluidos, regiones, regla ROV, duración y dueño de retirada.

Para cada activación deben conservarse:

  1. UPDATE bruto, hora, vecino, AS_PATH, origen, next hop y comunidades;
  2. coincidencia exacta del filtro de prefijo y su procedencia;
  3. estado ROV y excepción explícita, si existe;
  4. término de importación que coincidió y modificaciones aplicadas;
  5. Adj-RIB-In, selección Loc-RIB y motivo;
  6. FIB en cada clase de ingreso y resolución a descarte;
  7. contadores de drop con contexto y línea base;
  8. observación de paquetes a ambos lados del límite;
  9. Adj-RIB-Out de cada vecino que no debe ver la ruta;
  10. retirada, eliminación FIB, reselección normal y recuperación del servicio.

El UPDATE prueba la entrada; la política, la decisión; la RIB, la selección; la FIB, la instrucción ejecutable; los paquetes, el resultado. La salida prueba el confinamiento. La verificación posterior prueba que la autoridad terminó.

Un único estado “activo” no distingue ruta no elegida, next hop mal resuelto, flota parcialmente programada o descarte persistente después de la retirada. RFC 7999 alienta conservar los UPDATE BLACKHOLE; una auditoría completa retiene además política, FIB y medición.

Ensayar también la vuelta

Un prefijo canario controlado debe recorrer cada tipo de sesión, familia, región, plataforma y versión. El ensayo acepta el caso autorizado y rechaza prefijo ajeno, sesión equivocada y longitud no permitida. Comprueba contención, FIB, contadores, efecto acotado y restauración tras retirada.

Pausar si falta un incidente vigente, la dirección está protegida, ROV es inexplicable, desaparece la contención, la ruta llega a un borde externo, las versiones discrepan o no existe vencimiento. Revertir ante pérdida del servicio equivocado, expansión de alcance, fuga, comportamiento FIB desigual o daño fuera del prefijo.

Retirar el UPDATE no basta. Cada FIB debe perder la entrada de descarte, la ruta ordinaria debe regresar y las sondas deben confirmar entrega. La reversibilidad técnica no repara una historia perdida: sin UPDATE, aprobación, versión de política y contadores, después nadie podrá atribuir la decisión.

Fuentes