Resumo

  • O RFC 2908 separou a alocação multicast em três camadas: cliente-servidor, coordenação dentro do domínio e alocação entre domínios. O RFC 2909, experimental, descreveu o MASC para que domínios reivindicassem prefixos temporários e depois os subdividissem ou delegassem.
  • O RFC 2909 advertiu que o IPsec pode proteger dois pares sem autenticar a origem de um UPDATE retransmitido: um nó MASC não confiável em outro ponto da topologia poderia injetar atualizações maliciosas. A fronteira proposta era a confiança administrativa nos pares — não uma prova de implantação, exploração ou tráfego.

Em setembro de 2000, a arquitetura de endereçamento multicast precisava responder a duas perguntas fáceis de confundir: quem entrega um endereço de grupo a uma aplicação e quem reserva o espaço maior de onde esse endereço será escolhido? O RFC 2908 não reuniu as duas coisas numa só operação. Separou o trabalho em três camadas: o cliente pede um endereço a um servidor; os servidores coordenam as alocações dentro do domínio; e um mecanismo entre domínios fornece faixas a cada domínio. O MADCAP podia atender à primeira camada, o AAP ou a configuração manual à segunda, e o MASC era uma opção para a terceira.

Com essa separação, a alocação multicast deixou de parecer um contador global único. Um nó MASC — normalmente imaginado num roteador de borda — agia em nome de um domínio, muitas vezes correspondente a um Sistema Autônomo. Ele escolhia um prefixo de uma faixa maior, enviava a reivindicação aos pares configurados e esperava para detectar reivindicações em conflito. A hierarquia de pais e filhos permitia subdividir o prefixo recebido para os servidores de alocação locais ou delegar subprefixos a domínios filhos. O prefixo também podia ser inserido nas informações de rota multicast para uso por outro protocolo de roteamento.

São superfícies de controle relacionadas, mas distintas: a alocação MASC, por si só, não cria uma rota, a adesão de um receptor ao grupo nem a entrega de pacotes.

As reivindicações tinham prazo. Cada prefixo vinha com uma duração; para continuar usando a faixa, o domínio precisava renová-la antes do vencimento. Se não conseguisse, a especificação dizia que deveria parar de usar o prefixo e remover o estado de rota correspondente. Portanto, o espaço delegado não era permanente por padrão. Ainda assim, estado de alocação, estado de roteamento e uso pela aplicação poderiam divergir se o operador observasse apenas um deles. Um registro do plano de controle não é uma captura de pacotes.

A arquitetura também explicitava a escolha difícil quando o espaço era escasso. Uma partição rígida poderia garantir que domínios não colidissem, mas as reservas necessárias para suportar partições de rede e failover fragmentariam o espaço disponível. O RFC 2908 preferiu o bom aproveitamento e a disponibilidade contínua à garantia absoluta de que conflitos nunca ocorreriam. Buscava uma probabilidade muito alta de evitá-los, aceitando que ela não seria zero. As reivindicações, a espera e a escolha de outro prefixo após uma colisão materializavam essa decisão probabilística; não ofereciam certeza matemática.

O RFC 2909 identificou, então, outro limite: a procedência da atualização. Um UPDATE não precisava parar no primeiro par que o recebesse. Os nós MASC podiam armazená-lo e encaminhá-lo entre pais, irmãos, filhos e pares internos. O documento diz que o IPsec pode proteger dois nós em peering. Mas, se um nó MASC não confiável se conectasse em qualquer ponto da topologia, poderia injetar UPDATEs maliciosos que os demais talvez não reconhecessem como tal. Por isso, a recomendação é que cada nó forme peering somente com nós confiáveis.

Na recuperação após uma reinicialização, informações recebidas de um pai ou par interno costumam ser consideradas confiáveis; já os UPDATEs próprios que chegam por um irmão ou filho podem ser descartados.

Isso não quer dizer que “o IPsec não funcione”. A proteção do enlace protege uma adjacência específica. A lacuna surge quando a mensagem segue além dela: o próximo salto sabe qual par a enviou, mas talvez não consiga estabelecer de forma independente quem a originou nem se cada intermediário tinha autoridade para repeti-la. Os timestamps e identificadores de origem do MASC ajudam a comparar reivindicações concorrentes, mas o RFC 2909 não os apresenta como autenticação criptográfica da origem. Tampouco relata uma exploração real. Descreve uma ameaça e deixa a configuração da topologia de pares como decisão operacional.

A distinção importa porque uma reivindicação de prefixo pode influenciar mais de um servidor de alocação. Uma atualização aceita e propagada pode restringir reivindicações vizinhas e alimentar o estado de rotas multicast antes mesmo de uma aplicação pedir um endereço. A solução do RFC 2909 não é uma autoridade global que certifique cada reivindicação: é limitar o peering a nós confiáveis e usar regras sensíveis ao caminho para aceitar atualizações retransmitidas. O controle efetivo fica no desenho da topologia e na administração da confiança.

O status dos documentos também limita o que podemos dizer sobre a história. O RFC 2908 é Informativo e apresenta uma arquitetura proposta; o RFC 2909 é um protocolo Experimental, não um padrão da Internet. Eles provam que os autores formalizaram um modelo em camadas e seus riscos, mas não quantas redes implantaram MASC, se o uso se tornou comum ou se alguma atualização maliciosa interrompeu um serviço. O GLOP do RFC 3180 e o registro IANA do RFC 3171 são escolhas de alocação diferentes, não provas de implantação do MASC.

A conclusão sustentada é mais específica: uma reivindicação de prefixo, um enlace protegido, uma origem confiável, uma rota e um fluxo multicast recebido são fatos distintos. Um plano de controle seguro precisa dizer qual evidência autoriza cada transição.

Fontes