Resumen

  • RFC 2908 separó la asignación de direcciones multicast en tres capas: cliente-servidor, coordinación dentro del dominio y asignación entre dominios. RFC 2909, de carácter experimental, describió MASC para que cada dominio reclamara prefijos temporales y luego los subdividiera o delegara.
  • RFC 2909 advirtió que IPsec podía proteger dos pares sin autenticar el origen de un UPDATE reenviado: un nodo MASC no confiable situado en otra parte de la topología podía inyectar actualizaciones maliciosas. La frontera propuesta era la confianza administrativa en los pares, no una prueba de despliegue, explotación o tráfico.

En septiembre de 2000, la arquitectura de asignación multicast debía separar dos preguntas que suelen confundirse: ¿quién entrega una dirección de grupo a una aplicación y quién reserva el bloque del que saldrá esa dirección? RFC 2908 no las trató como una única operación. Dividió el trabajo en tres capas: un cliente solicita una dirección a un servidor; los servidores coordinan sus asignaciones dentro de un dominio; y un mecanismo entre dominios proporciona bloques a esos dominios. MADCAP podía atender la primera capa, AAP o la configuración manual la segunda, y MASC era una propuesta para la tercera.

Así, la asignación multicast dejaba de parecerse a un contador global compartido. Un nodo MASC —que normalmente se esperaba en un router de borde— actuaba por un dominio, a menudo equivalente a un Sistema Autónomo. Elegía un prefijo de un bloque mayor, enviaba la reclamación a sus pares configurados y esperaba a que aparecieran posibles conflictos. La jerarquía de padres e hijos permitía dividir el prefijo recibido para los servidores de asignación propios o entregar subprefijos a dominios subordinados. El prefijo también podía incorporarse a la información de rutas multicast para que otro protocolo de enrutamiento lo utilizara.

Son planos de control relacionados, pero distintos: una asignación MASC no crea por sí sola una ruta, la pertenencia de un receptor al grupo ni la entrega de paquetes.

Las reclamaciones tenían vencimiento. Cada prefijo llevaba una vida útil; el dominio debía renovarla antes de que expirara si quería conservarlo. Si no lograba renovarlo, la especificación decía que debía dejar de usarlo y retirar el estado de ruta correspondiente. El espacio delegado no era permanente por defecto. Aun así, el estado de asignación, el de enrutamiento y el uso de una aplicación podían divergir si el operador solo observaba uno. Una reclamación de control no equivale a una captura de paquetes.

El diseño también explicitaba su compromiso cuando las direcciones escaseaban. Una partición estricta puede impedir que dos dominios reclamen el mismo bloque, pero las reservas para particiones de red y conmutación por error fragmentan el espacio. RFC 2908 priorizó el aprovechamiento y la disponibilidad continua frente a una garantía absoluta de cero conflictos. Buscaba una probabilidad muy alta de evitarlos, aceptando que no sería nula. Las reclamaciones MASC, el periodo de espera y la selección de otro prefijo al detectar un choque concretaban esa elección probabilística; no la convertían en certeza matemática.

RFC 2909 identificó después otra frontera: la procedencia de las actualizaciones. Un UPDATE no tenía por qué detenerse en el par que lo recibió primero. Los nodos MASC podían almacenarlo y reenviarlo entre padres, hermanos, hijos y pares internos. El documento dice que IPsec puede proteger a dos nodos entre los que existe una relación de peering. Pero si se conecta a la topología un nodo MASC no confiable, este puede inyectar UPDATE maliciosos que otros nodos quizá no reconozcan como tales. Por eso recomienda que cada nodo solo establezca peering con nodos confiables.

Al recuperar el estado tras un reinicio, normalmente se considera fiable la información de un padre o par interno; un nodo también puede descartar sus propios UPDATE recibidos desde un hermano o un hijo.

Esto no significa que «IPsec no funcione». La protección de enlace protege una adyacencia concreta. La brecha aparece cuando el mensaje viaja más allá: el siguiente salto sabe qué par se lo entregó, pero quizá no pueda establecer por sí solo quién lo originó ni si todos los intermediarios tenían derecho a retransmitirlo. Las marcas de tiempo y los identificadores de origen ayudan a resolver reclamaciones en conflicto, pero RFC 2909 no presenta esos campos como autenticación criptográfica del origen. Tampoco documenta un ataque real: plantea un modelo de amenaza y deja la configuración de la topología de pares en manos de sus operadores.

La distinción importa porque una reclamación de prefijo puede afectar a varios servidores de asignación. Si se acepta y propaga, podría condicionar reclamaciones vecinas y alimentar el estado de rutas multicast antes de que una aplicación solicite una dirección. La respuesta del RFC no era un árbitro mundial que certificara cada reclamación; era limitar el peering a nodos de confianza y aplicar reglas que tuvieran en cuenta la ruta al aceptar UPDATE reenviados. El poder operativo quedaba en el diseño de la topología y la administración de la confianza.

Las categorías de los documentos acotan la conclusión histórica. RFC 2908 es informativo y describe una arquitectura propuesta; RFC 2909 es experimental, no un estándar de Internet. Prueban que sus autores formularon un modelo por capas y discutieron sus riesgos, no cuántas redes implementaron MASC, si llegó a ser habitual o si una actualización maliciosa interrumpió algún servicio. GLOP en RFC 3180 y el registro IANA de RFC 3171 son opciones de asignación distintas; tampoco demuestran que MASC se desplegara.

La lección sustentable es más acotada: una reclamación de prefijo, un enlace protegido, un origen confiable, una ruta y un flujo multicast recibido son hechos diferentes. Un plano de control seguro debe especificar qué evidencia autoriza cada transición.

Fuentes