Resumen

  • Peer-RPF elige desde qué vecino es admisible un mensaje Source-Active según la ruta hacia el RP originador. Un par por defecto puede sustituir esa inferencia en topologías concretas; entonces la configuración, no el camino BGP, se convierte en la autoridad.
  • Ninguno de los dos casos demuestra que la fuente siga enviando, que esté autorizada, que el árbol PIM se haya instalado o que un receptor haya obtenido datos útiles.

La excepción no era un fallo del protocolo

Una empresa pequeña tiene una sola sesión MSDP con su proveedor. No ejecuta BGP con ese vecino. Si aplicara literalmente una comprobación dependiente del camino BGP, los anuncios externos no pasarían. RFC 4611 contempla este caso: puede configurarse un par por defecto y omitir peer-RPF.

Eso no convierte la instalación en insegura por definición. Convierte una inferencia automática en una decisión administrativa. La diferencia es decisiva para la rendición de cuentas. Cuando el tablero dice «aceptado», hay que saber si el mensaje coincidió con la ruta calculada o si una persona autorizó una excepción que acepta todos los SA de ese par dentro de una política determinada.

RFC 3618 se publicó en octubre de 2003 como Experimental. Describe MSDP para intercambiar información de fuentes activas entre dominios IPv4 PIM-SM. Un RP que aprende de un nuevo emisor construye un mensaje Source-Active con dirección de fuente, grupo y RP. Los pares lo propagan; un dominio con receptores interesados puede iniciar después un join hacia la fuente.

El mensaje abre la posibilidad de construir el camino de datos. No es el camino ni su resultado.

Peer-RPF resolvía un problema de propagación

La inundación necesita una regla que evite aceptar copias arbitrarias del mismo anuncio. MSDP consulta la MRIB y aplica una secuencia determinista: par directo con el RP, siguiente salto eBGP, vecino que anunció la ruta, IGP, AS más cercano o par estático, según corresponda. Los pares no establecidos no son elegibles.

La decisión responde: «¿llegó este SA desde el vecino que mi topología considera orientado hacia el RP que figura en el mensaje?». No responde: «¿existe realmente la fuente?», «¿tiene permiso para el grupo?» o «¿recibió un usuario el flujo?».

RFC 4611 documenta escenarios donde las direcciones de las sesiones MSDP y MBGP deben coincidir para evitar fallos. También registra casos en que la comprobación BGP se suspende: una sola sesión, RP directamente conectado, mesh-group, selección mediante IGP o par por defecto. La diversidad no es un defecto accidental; refleja redes con distintas fuentes de autoridad topológica.

Por eso una auditoría necesita el tipo de decisión. Guardar únicamente rpf-pass=true borra si la aceptación se derivó de BGP, IGP, vecindad directa, malla, regla estática o excepción por defecto. Dos resultados iguales pueden tener responsables, riesgos y procedimientos de retirada distintos.

La confianza en el vecino seguía sin ser confianza en la fuente

RFC 3618 exige que las implementaciones soporten la opción TCP MD5 para proteger mensajes de control. Una sesión configurada con el secreto esperado reduce la posibilidad de que un tercero fabrique o modifique el flujo TCP. La posterior evaluación KARP de RFC 6952 analiza las limitaciones de claves y autenticación en MSDP y otros protocolos.

Esa protección termina en el par. El vecino autenticado puede transmitir una observación equivocada, una política demasiado amplia o un estado que ya no corresponde al tráfico. La fuente pudo falsificar su dirección antes de llegar al RP. El RP pudo tener una configuración incorrecta. La sesión puede ser auténtica y el contenido semánticamente falso.

El par por defecto amplifica la necesidad de separar ambos niveles. Se confía en que ese vecino sea la puerta externa; no se delega automáticamente la autorización de cada fuente y grupo. Las listas de SA, los límites y la observación posterior siguen siendo necesarios.

La regla de Heng Lu sobre autoridad local encaja aquí: quien soporta el coste debe conservar la facultad de aceptar, limitar y revocar. La existencia de una relación técnica no transfiere toda la autoridad decisoria al otro extremo.

Un mensaje aceptado todavía tenía que encontrar demanda

MSDP aplica «flood-and-join». Difunde anuncios de fuentes sin difundir globalmente la membresía de receptores. Cuando un RP receptor tiene interés (*,G), puede iniciar un join (S,G) hacia la fuente anunciada. PIM construye el árbol que llevará los paquetes.

Hay, por tanto, varias decisiones: aceptar el SA; conservarlo; detectar interés; emitir el join; elegir la interfaz RPF de datos; instalar estado; recibir paquetes; entregarlos a la aplicación. Un par por defecto solo afecta una parte de la primera decisión.

La ausencia de datos después de aceptar un SA puede deberse a una fuente detenida, un anuncio viejo, falta de interés, join perdido, RPF diferente, filtro de datos, árbol incompleto o aplicación. Rechazar el SA puede ocultar una fuente real. Sin la cadena completa, el mismo síntoma produce diagnósticos opuestos.

Un SA puede encapsular un paquete para ayudar a fuentes breves antes de que el árbol quede listo. Ese paquete es una muestra, no una garantía de continuidad. Tampoco prueba que la aplicación lo haya considerado válido.

El caché convertía una excepción en estado duradero

Los pares deben almacenar los SA. El RP originador vuelve a anunciarlos cada 60 segundos mientras considera activa la fuente, y una implementación debería enviar el caché al restablecer una conexión. Cada entrada tiene su propio temporizador.

Una política de par por defecto no actúa solo sobre un instante. Puede permitir que muchos anuncios entren, se conserven, se repitan y desencadenen joins posteriores cuando aparezcan receptores. Por eso la excepción debe tener límites de fuente, grupo, tasa y cantidad de estado. Su efecto es acumulativo.

RFC 3618 recomienda precisamente filtros, máximos de entradas y límites de creación contra explosiones de estado y ataques de denegación de servicio. RFC 4609 explica la presión que la difusión periódica puede producir. RFC 8916 modela el par por defecto, los filtros, los límites y los contadores operativos.

Una excepción sin telemetría es una autoridad sin recibos. Una excepción con métricas, alcance y caducidad puede ser una decisión local verificable.

La malla y Anycast cambiaban quién podía hablar

Un mesh-group evita la retransmisión entre miembros bajo la premisa de que el originador envía a todos. Debe ser una malla completa. En ese entorno, la relación de aceptación no se reduce a un camino BGP. Si falta un enlace, algunos RPs pueden desconocer una fuente aunque otros tengan un caché reciente.

Anycast-RP usa MSDP para compartir estado entre varios RPs que presentan la misma dirección de servicio. RFC 3446 exige que el SA use una dirección individual del RP, no la anycast, porque peer-RPF necesita una procedencia enrutable. La identidad compartida facilita continuidad; la identidad individual mantiene atribuible el anuncio.

El cambio de un RP a otro debe dejar evidencia: qué instancia originó el SA, qué sesiones estaban activas, cuándo convergieron los cachés y si los joins y datos continuaron. La disponibilidad de la dirección anycast no cubre automáticamente esas preguntas.

Gobernar la excepción antes de necesitarla

El catálogo operativo debe enumerar cada par por defecto y la razón de su existencia. Debe indicar qué alternativa topológica no está disponible, qué prefijos de fuentes y grupos se admiten, qué límites protegen el estado y quién puede modificar la regla. La política debe producir una alerta si aparece un segundo par, si cambia la ruta o si el volumen de SA supera la hipótesis que justificó la excepción.

El riesgo de segundo orden es normalizar la excepción. Lo que comenzó como solución para una red stub puede sobrevivir a una fusión, a la incorporación de BGP o a una nueva malla y convertirse en una ruta de confianza demasiado amplia. El riesgo de tercer orden es que los investigadores vean mensajes correctamente autenticados y olviden que fueron aceptados por una política heredada.

RFC 3618 no prometía que peer-RPF certificara fuentes. Su valor consistía en ordenar la propagación. La responsabilidad del operador empieza justo donde termina esa promesa: documentar por qué un mensajero fue admisible y comprobar por separado si su anuncio produjo el servicio esperado.

Sources