Resumo

  • A revisão 04 do Internet-Draft SAND exige proteção BPSec, mas permite que o anunciante selecione tipos e instâncias segundo ULN, ponto de terminação e destino BP; o próprio texto prevê vizinhos com conjuntos diferentes ou sem sobreposição.
  • O receptor decide localmente o que autoriza e elimina, enquanto uma Router Advertisement protegida continua separada da autorização para instalar e usar a rota.
  • Um recibo de projeção deve ligar Source, Security Source, Previous Node, destino, interface, versão de filtro, Reference Time, validade, supersession e decisão receptora antes que uma divergência alimente automação.

Há uma diferença decisiva entre saber quem fez uma afirmação e conceder à afirmação poder operacional. O SAND oferece mecanismos fortes para a primeira tarefa. A segunda permanece distribuída.

O projeto Bundle Protocol Secure Advertisement and Neighborhood Discovery descreve descoberta em redes tolerantes a atraso baseadas em BPv7. Seus messages podem transportar solicitações, credenciais, underlayer networks, convergence layers, recursos, topologia local, disposição de roteamento e endpoints. Esse catálogo torna a descoberta útil para bootstrap e operação. Também cria o risco de que um sistema de gestão chame toda informação protegida de “verdade do nó”.

Na revisão 04, não existe uma única verdade exportada automaticamente. Existe uma declaração contextual do anunciante e uma decisão contextual do descobridor. A evidência precisa manter as duas.

O caminho de identidade tem mais de um sujeito

O SAND Bundle parte de uma Source EID e vai para o SAND Group EID ou para outro SAND Singleton EID. Uma mensagem destinada a vizinhos de um salto usa Hop Limit 1. Mesmo assim, a fonte do bundle e o nó que o entregou neste salto podem ser diferentes.

Para identificar o previous hop, a especificação prioriza a identidade autenticada pela convergence layer. Se ela não estiver disponível, usa-se um Previous Node extension block autenticado. No primeiro salto, o Source Node ID autenticado também pode servir. Em encaminhamento, preservar essa separação é mais rigoroso do que simplesmente presumir que a origem foi o último transmissor.

Todo SAND Bundle deve conter Block Integrity Block para o payload. A Security Source desse BIB identifica o mesmo nó da Source EID, embora políticas possam usar EIDs diferentes para representar aquele nó. Um Previous Node block recebe proteção própria, com Security Source correspondente ao nó anterior.

Portanto, Source, Security Source e Previous Node não são três grafias decorativas de uma mesma coluna. Respondem a perguntas diferentes: autoria, proteção de bloco e entrega do salto. O sistema que faz a união pode estar certo, mas precisa registrar a regra, os valores originais e o objeto efetivamente protegido.

BPSec torna a declaração atribuível e detecta alteração. Não obriga o autor a divulgar tudo, nem transforma o conteúdo em permissão de roteamento.

A política do anunciante vence a curiosidade do solicitante

Data Solicitation informa que outro nó deseja certos dados. Não é ordem. A revisão 04 exige que ela não sobreponha a política local sobre o que pode ser anunciado. O anunciante escolhe quais message types usa e quais instances inclui em cada tipo.

Às vezes a escolha serve à eficiência. Uma credencial estável não precisa acompanhar cada atualização. Um termination point pode estar desativado para descoberta. Um parâmetro de uma tecnologia pode ser irrelevante em outra. Em outros casos, o filtro limita exposição: group messaging recebe o mínimo para iniciar contato, e uma destination singleton protegida recebe material mais sensível.

Context-Specific Advertisement Filtering permite condicionar o conjunto à ULN, ao termination point e à source ou destination BP. Certificados de uma CA privada podem aparecer apenas na rede em que aquela raiz tem sentido. CL instances IPv6 podem ser anunciadas apenas na terminação IPv6. Filtros ortogonais podem atuar juntos.

O texto reconhece a consequência como uma espécie de “split brain”: vizinhos diferentes podem observar conjuntos distintos, possivelmente sem sobreposição, associados ao mesmo anunciante. Isso pede cuidado, não uma política automática de uniformização. A ausência em uma projeção não nega a presença em outra.

Há ainda o risco de vazamento. No bootstrap por group messaging, o payload inicial é observável se não houver confidencialidade adicional. Hop Limit 1 não impede um middlebox ou eavesdropper de enxergar o conteúdo. Omitir nomes DNS, endereços, CL instances, vizinhos ou certificados em certos pontos de terminação pode ser uma medida correta de minimização.

Um inventário que elimina o contexto converte “não revelado aqui” em “não existe”. Essa conversão não vem do protocolo; vem do produto.

O descobridor não é um arquivo passivo

Receber um SAND message dentro das condições corretas de transporte não obriga o nó a usar tudo. A implementação deve compreender as estruturas, mas cada mecanismo continua facultativo para uso.

A autorização pode depender do tipo, source, destination, parâmetros da CL na recepção ou informações negociadas anteriormente. Depois, o receptor pode fazer culling de dados irrelevantes. Um nó IP-only pode retirar parâmetros não IP. Um endereço sem rota local no momento pode ficar fora da representação ativa.

Esse descarte não prova falsidade. A configuração de roteamento pode mudar. Uma versão futura pode interpretar o que a atual não entende. Se o pipeline exportar apenas a tabela final, perderá a diferença entre omissão do anunciante, recusa do receptor, limitação de software e condição transitória.

A autorização contextual exige ainda que o message permaneça ligado ao SAND Bundle original e à CL instance local pela qual chegou. A própria revisão 04 admite que algumas interfaces BPA–application não oferecem essa visibilidade. Nesse caso, a política pode ser expressa, mas não executada com base em evidência real.

Running code importa: não basta configurar “aceite apenas nesta rede” se o componente decisor não recebe a identidade da rede.

Supersession define qual mensagem pode mudar estado

Mensagens SAND carregam o conjunto completo de um tipo, não uma sequência de deltas dependentes. Isso torna o processamento idempotente e lida bem com duplicatas. A contrapartida é uma ordem temporal explícita.

Depois de processar uma mensagem, o receptor registra Reference Time por bundle source e message type, ou Creation Timestamp como alternativa. Antes de processar outra, compara os valores. Mensagem idêntica ou anterior deve ser ignorada. A ordenação usa DTN Time e depois Sequence Number. Ignorar conteúdo superseded não é falha.

Duas capturas podem mostrar bundles criptograficamente válidos, mas só o mais novo altera a informação vigente. Replay pode gastar capacidade, porém não deve restaurar estado anterior quando a regra funciona. Já uma estratégia que só envia após mudança pode manter uma projeção antiga se a atualização se perder.

Validity Duration, Repetition Interval, timers periódicos e envio por evento estabelecem a semântica do silêncio. Horário de chegada ao coletor não substitui Reference Time nem prova vigência.

SYMMETRIC não significa experiência simétrica

Local Topology Advertisement usa estados que parecem intuitivos, mas têm escopo preciso. HEARD diz que o nó recebeu mensagem do peer sem ainda se ver na topologia anunciada por ele. SYMMETRIC diz que o peer anunciou este nó, portanto ao menos uma mensagem foi recebida em cada direção. LOST diz que nenhuma mensagem chegou durante timeout definido pela implementação.

Nenhum estado prova capacidade contínua, entrega da aplicação ou sucesso de uma sessão. As routing metrics entre vizinhos mútuos não são sincronizadas. Mesmo quando anunciam os mesmos itens, a revisão 04 não garante nem espera valores iguais. A reconciliação é decisão de implementação.

Router Advertisement expõe willingness de zero a seis e pode incluir padrões de Attached Networks. O padrão *:** pode representar comportamento de gateway, mas o texto diz que apenas uma stub network adequada deveria ver essa publicidade. Registrar o padrão, autorizar seu uso e instalar a rota são passos separados.

Sem autorização correta, continuam os riscos de route leaking e hijacking. O projeto observa que não existe equivalente a RPKI para autorizar BP routing. Logo, uma Router Advertisement autenticada é uma oferta atribuível, não um mandato operacional.

Dar identidade à projeção

O controle proposto é um recibo de projeção de anúncio. Ele não altera o wire protocol e não é requisito normativo da revisão 04; é uma forma de impedir que contexto desapareça durante ingestão.

O recibo inclui hash e identidade do bundle protegido, Source EID, BIB Security Source, Previous Node, destination, Hop Limit, Creation Timestamp e recepção. Registra qual caminho de autenticação de identidade venceu e associa o message à ULN, ao termination point e à CL instance usados.

Para cada message type, guarda instances, Reference Time, Validity Duration, Repetition Interval e verdict de supersession. Se disponível, fixa a versão de filter/configuração do anunciante. No receptor, grava authorization e culling com motivos e produz hash da projeção pós-política armazenada.

Uma decisão de rota fica em outro recibo. A observação de forwarding e o outcome da aplicação ficam em evidências posteriores. Não se trata de duplicar logs, mas de impedir que authenticated=true silenciosamente signifique completo, autorizado, roteado e entregue.

Com esse objeto, uma divergência pode ser classificada como escopo deliberado, policy epoch diferente, staleness, supersession, culling, parâmetro não suportado, perda, erro de configuração ou comportamento ainda sem explicação. Sem ele, cada equipe defende sua captura sem poder reproduzir a formação da vista.

O estado editorial também tem limite

Datatracker registra a revisão 04 como Internet-Draft ativo do grupo DTN, publicada em 8 de setembro de 2026 e com expiração em 12 de março de 2027. O cabeçalho diz Standards Track; o campo intended RFC status estava vazio no congelamento. Não é RFC nem alocação IANA final.

A seção Implementation Status menciona um proof of concept. O mesmo texto afirma que as informações vieram de contribuidores, não foram verificadas, não formam catálogo e não implicam endosso do IETF. Este artigo não afirma adoção, interoperabilidade, comportamento de produto, incidente, route leak ou indisponibilidade real.

RFC 9171 estabelece BPv7 e RFC 9172, BPSec. RFC 8949 e RFC 8610 cobrem CBOR/CDDL. RFC 6130 fornece comparação com neighborhood discovery. RFC 4593, RFC 7908 e RFC 6480 esclarecem ameaças de routing, route leaks e RPKI. Nenhuma dessas fontes transforma uma projeção local em mapa universal.

O que se pode afirmar é mais preciso: a autenticação sustenta quem declarou algo naquele contexto. Completude, autorização e resultado permanecem em outras camadas.