Resumo

  • A RFC 3182 colocou um ou mais elementos AUTH_DATA dentro de POLICY_DATA. Localizador, credencial, assinatura e erro respondiam a perguntas diferentes; nenhum concedia largura de banda por conta própria.
  • A identidade podia mudar de custódia. Em unicast, o localizador do usuário podia vir do salto anterior enquanto a credencial passava a representar o nó atual. Em multicast, a identidade da aplicação podia ser a primeira encontrada ou a escolhida pelo PDP.
  • Autenticar um principal não era autorizar a reserva. A decisão, a execução local, a capacidade, o estado ao longo do caminho, o tratamento dos pacotes e o efeito na aplicação exigiam provas separadas.

A credencial chegou antes do direito

O RSVP separava disponibilidade de recurso e permissão de uso. A RFC 2205 chamava a primeira decisão de admission control e a segunda de policy control. As duas precisavam ser favoráveis. O protocolo transportava os dados de política, mas não transformava automaticamente o conteúdo em decisão.

Publicada em outubro de 2001 como Proposed Standard, a RFC 3182 definiu a estrutura que levava identidade até o controle de política. AUTH_USER representava usuário; AUTH_APP, aplicação. POLICY_LOCATOR apontava para a política associada ao nome distinguido. CREDENTIAL podia carregar identificador textual, ticket Kerberos ou certificado. Uma assinatura protegia os atributos anteriores, e um objeto de erro explicava a falha.

A RFC substituiu a RFC 2752 para corrigir um código de tipo e a largura de um campo de erro. Isso não descreve duas ondas de implantação. A atualização administrativa de 2026 no Datatracker também não é uma nova versão do protocolo: o registro inclui um erratum técnico verificado.

O erratum 2958 corrige a operação Kerberos da seção 6.3. O servidor extrai do ticket a chave de sessão e a usa para autenticar o usuário; não envia o ticket ao KDC para obter essa chave. Uma narrativa histórica precisa usar o mecanismo corrigido, não perpetuar um erro porque o texto original dos RFCs permanece imutável.

O localizador apontava para a regra, não para o resultado

A RFC 2753 distinguia o PDP, onde a política era decidida, do PEP, onde a decisão era executada. O PDP podia consultar diretórios, autenticação, contabilidade, faturamento, grupos, horário e configuração local. Mesmo uma resposta positiva podia encontrar falta de capacidade no controle de recursos.

Essa separação impede que um nome estruturado seja confundido com mandato. O localizador dizia onde procurar uma regra. A credencial oferecia material para validar um sujeito. A assinatura mostrava uma operação de chave sobre determinados bytes. Ainda faltava uma autoridade competente ligar esse sujeito a uma política vigente e mandar executá-la naquele recurso.

O encadeamento defensável é: identidade alegada, subtipo da credencial, validação, principal autenticado, escopo da chave ou realm, localizador e versão da política, decisão do PDP, execução do PEP, resultado de capacidade, estado RSVP, pacotes e aplicação. Um único campo authorized=true apaga as fronteiras mais importantes.

Texto, Kerberos e certificado não eram o mesmo nível de prova

A forma simples carregava um login ASCII ou Unicode. Para aplicações, a RFC dava um nome de executável como vic.exe. O próprio documento dizia que essa forma não continha credencial autenticável com segurança e era inerentemente mais fraca. O nome do arquivo não provava o binário em execução, seu editor, seu dono nem sua integridade.

Kerberos exigia ticket para o próximo nó RSVP ou PDP e infraestrutura compatível. O ticket podia autenticar um principal dentro daquele realm. Não levava uma autorização universal para reservar recursos em todos os domínios seguintes.

A forma de chave pública acrescentava certificado e assinatura. Dependia de chave privada protegida, CA confiável e verificador capaz de validar a cadeia e a assinatura. Mesmo assim, não resolvia sozinha revogação, mandato organizacional, política local ou a identidade do processo que realmente enviava tráfego.

A RFC 4230 observou depois o custo computacional e de largura de banda da chave pública por fluxo, a necessidade de mecanismos de revogação, a privacidade incompleta com Kerberos e o fato de que autenticação podia ser insuficiente para autorização. Uma credencial forte aperfeiçoava um recibo; não executava os passos posteriores.

O porta-voz podia mudar a cada salto

Em uma sessão unicast, o localizador de política do usuário era copiado do salto anterior, mas as credenciais eram da identidade do nó de rede atual. O usuário procurado e o ator que respondia pelo encaminhamento podiam pertencer a momentos diferentes.

Em multicast, localizador e credencial de usuário eram do nó atual. A identidade de aplicação tinha outra regra: era copiada em unicast; em multicast, podia sobreviver a primeira do pacote ou uma selecionada pelo PDP. O valor final não era um cadastro de todos os participantes. Era o resultado de ordem ou escolha.

Vários AUTH_DATA podiam coexistir, e nós conscientes de política podiam substituir conteúdo. Por isso o histórico precisa guardar entrada, saída, autor da transformação, domínio, associação de segurança e motivo. Salvar apenas a identidade final elimina a diferença entre origem, porta-voz atual e seleção de política.

Um roteador podia passar sem avaliar

Nem todo nó RSVP precisava entender política. A RFC 2753 admitia enforcement apenas em alguns pontos, com nós policy-ignorant apoiados em fronteiras confiáveis. A RFC 3182 permitia que um roteador ignorante da política ignorasse os objetos e continuasse o processamento.

Isso facilitava implantação incremental, mas restringia o significado da passagem. Um pacote atravessar o nó não demonstrava que usuário, certificado ou direito tinham sido avaliados. Em uma fronteira capaz, o PEP consultava o PDP; resposta negativa rejeitava, positiva apenas deixava o RSVP continuar. Outro salto ainda podia negar por capacidade, política diferente ou falha de instalação.

Receber o objeto, validar a credencial, aprovar a política, instalar o estado e entregar serviço são estados diferentes. O silêncio de um nó incapaz de avaliar não é aprovação.

O erro dizia onde a política falhou

As causas incluíam tipo de credencial não suportado, privilégios insuficientes, credencial expirada e identidade alterada. Se o PDP não verificasse AUTH_DATA, devia retornar policy control failure ao PEP e deveria fornecer detalhe para o erro RSVP.

Esses códigos separavam autenticação, privilégio e capacidade. Mas EXPIRED_CREDENTIAL não provava retirada de todo estado; IDENTITY_CHANGED não provava que a aplicação fora notificada; um erro em um ramo multicast não descrevia todos os ramos.

O registro IANA atual conserva a classe POLICY_DATA e valores de falha de política. Ele prova coordenação numérica, não implantação de todos os subtipos nem uma decisão observada em um roteador específico.

Integridade não criava legitimidade

Quando a mensagem RSVP inteira não tinha proteção, a RFC 3182 recomendava integridade sobre POLICY_DATA. Isso podia detectar modificação ou replay dentro de uma associação de segurança.

A RFC 4230 distinguiu a proteção da mensagem externa da proteção do contêiner interno. Também mostrou que nós e PDPs podiam alterar elementos por projeto, que informação do usuário podia vazar após o primeiro salto e que não havia confidencialidade geral entre roteadores.

Uma auditoria precisa perguntar: os bytes foram preservados? Qual ator a chave ou o ticket autenticou? Esse ator tinha mandato sob uma política atual? Criptografia ajuda nas duas primeiras perguntas, não decide a terceira.

Entre domínios, a RFC 2753 previa reescrita conforme acordos bilaterais. A RFC 4230 constatou falta de formato padronizado para autorização em roaming e falta de mecanismo consensual para reservas QoS nesse cenário. A identidade podia cruzar a fronteira enquanto a autoridade continuava local.

A prova útil preservava o que foi descartado

O registro começa pela identidade alegada e o elemento bruto. Em seguida entram credencial, verificador, principal, realm ou cadeia, integridade, localizador, política, decisão, execução e capacidade. Só depois vêm estado de escalonamento, tratamento de pacotes e observação da aplicação.

No multicast, é preciso guardar todas as identidades de entrada, sua ordem, quem escolheu a sobrevivente e quais desapareceram. Sem isso, uma redução conveniente pode parecer representação coletiva.

A separação de símbolo, poder e execução nos textos de Lu Heng funciona aqui como lente editorial, não como atribuição aos autores da RFC. A RFC 3182 levou o nome até a decisão. O sistema em funcionamento ainda precisava provar quem tinha autoridade, onde agiu e qual efeito ocorreu.

Fontes e limites

O registro central está no texto da RFC 3182, ficha do RFC Editor, Datatracker, API, erratum 2958 e RFC 2752. A arquitetura e a segurança vêm das RFCs 2205, 2750, 2753, 2747, 4230, 4094 e da posterior 4923. O contexto histórico de credenciais vem das RFCs 1510 e 2459; a visão presente está no registro IANA.

A análise se apoia nas ideias de Lu Heng sobre camadas da realidade e primazia do código em execução. As 18 fontes foram congeladas em 2 de outubro de 2026, Asia/Shanghai. Elas não identificam implementação, operador, usuário, fluxo, incidente, implantação, teste de interoperabilidade nem resultado de serviço. Cada recibo prova apenas seu próprio escopo.