Resumo

  • A RFC 2154 anexava uma assinatura persistente a cada LSA e distribuía a chave certificada do roteador em uma Public Key LSA, preservando autoria além do vizinho imediato.
  • O certificado limitava identidade, função e faixas anunciáveis, mas não media a existência do enlace, a honestidade da métrica nem a disponibilidade do destino.
  • A decisão operacional exige recibos separados para confiança, geração de chave, atualidade da LSA, permissão, corroboração, SPF, FIB e entrega observada.

O selo chegou ao destino; a rede não

Uma LSA atravessa uma sequência de roteadores sem perder o selo do originador. Todos verificam os mesmos bytes. No fim da ramificação anunciada, porém, existe apenas um rack vazio. A assinatura funcionou: atribuiu corretamente uma declaração incorreta.

Essa é a fronteira central da RFC 2154, publicada como Experimental em junho de 1997. A autenticação criptográfica comum do OSPFv2 protegia pacotes entre vizinhos. A proposta assinava individualmente as LSAs carregadas no Link State Update. O pacote continuava sob proteção local; a prova do Advertising Router seguia com o dado de roteamento.

A verificação demonstrava origem e integridade dos bytes cobertos durante o flooding. Não demonstrava que o originador observou corretamente o mundo.

Uma chave também precisava de procedência

Qualquer equipamento pode publicar uma chave e reivindicar um Router ID. A RFC criou a Router Public Key LSA, ou PKLSA. Uma Trusted Entity assinava o certificado com identidade, papel, faixas permitidas, horário de criação, algoritmo e chave pública. O receptor verificava a certificação TE e a assinatura do roteador; falhar em qualquer etapa significava descarte.

A chave TE era instalada fora do OSPF. A PKLSA tinha de ser a geração atual. Se a LSA chegasse antes da chave, só poderia aguardar MAX_TRANSIT_DELAY. Uma chave nova substituía a antiga, exigia a reoriginação das LSAs e retirava material assinado pela geração anterior.

As faixas certificadas limitavam o espaço de anúncio. Não provavam que uma interface estava ativa, que a métrica tinha aprovação ou que o host existia. O certificado documentava o envelope do poder de assinar, não a realidade física.

MaxAge separava envelhecimento de retirada

LS Age muda no trânsito e normalmente ficava fora da assinatura. Quando o próprio originador criava uma LSA com MaxAge, a idade entrava na assinatura, permitindo uma retirada sincronizada sem deixar um intermediário forjá-la. Uma LSA órfã ainda envelhecia localmente até MaxAge em cada LSDB, com convergência mais lenta.

Áreas assinadas e não assinadas podiam coexistir, mas não misturar formatos dentro da mesma área. O ABR criava um resumo novo na fronteira, sob sua própria autoridade. A procedência do primeiro objeto não autenticava automaticamente a projeção.

A própria RFC descreveu a mentira assinada

A Seção 9 diz que um roteador interno pode anunciar uma métrica incorreta, declarar ativo um enlace inativo ou inventar uma rede stub ou rota de host. Um enlace de trânsito falso pode exigir uma afirmação correspondente na outra ponta antes de entrar no SPF; o stub não possui segunda ponta para conferência.

ABRs ainda podem originar Summary LSAs falsas sobre outras áreas. A RFC discute corroboração entre ABRs, mas não a inclui por custo. ASBRs podem publicar informação externa incorreta e não existe dentro do AS uma autoridade equivalente para autorizar todas as redes externas possíveis.

A assinatura melhora a responsabilização depois que a contradição aparece. Ela não assegura que a contradição seja descoberta. Encaminhamento de dados está fora do escopo: uma LSA válida pode alimentar SPF correto e instalar um next hop que perde pacotes.

Manter nove recibos alinhados

O registro começa com a chave TE e quem a instalou; segue por certificado, papel e faixa, geração da chave, identidade e hash coberto da LSA, substituição e idade, autorização da mudança, evidência da outra ponta, geração LSDB e SPF, RIB/FIB, e finalmente teste de dados e resultado da aplicação.

O RFC Editor, o Datatracker e o histórico registram o caráter Experimental; a página de errata corrige apenas um erro editorial. A RFC 2328 dá o contexto do OSPFv2. A RFC 6039 relatou ausência de experiência de implantação, e a RFC 6863 separou proteção do dado de replay por pacote. A RFC 7474 tratou outra questão: frescor após reinício. Um Internet-Draft individual expirado criticou ataques internos, sem representar consenso IETF.

Running-Code Primacy, Minimum Initial Specification e Reality Layers são lentes editoriais declaradas para separar documento, validação e execução.

Fontes