Resumo

  • O AUTH_SESSION da RFC 3520 leva uma declaração limitada de autorização para o pedido de reserva. Assinatura, frescor e correspondência de campos apoiam a admissão, mas não executam a reserva nem provam que a mídia ou o resultado do aplicativo chegaram.
  • Um recibo de serviço confiável distingue o autorizador, a abrangência, os bytes exatos, o controle de replay, a política local, a decisão do PDP, a aplicação pelo PEP, o estado RSVP, as precondições SIP, o tráfego observado e a confirmação autenticada do aplicativo.

É tentador usar a primeira confirmação inequívoca como encerramento. O token foi validado; a reserva foi admitida; então a sessão “deu certo”. Essa sequência parece natural em um painel, mas mistura três objetos: uma declaração de permissão, um estado de recursos e uma experiência de aplicação.

Publicada em abril de 2003 no Standards Track e hoje registrada como Proposed Standard, a RFC 3520 define um Session Authorization Policy Element para autorização e controle de admissão por sessão. Um host recebe o elemento pela sinalização e o copia sem alteração para o objeto RSVP POLICY_DATA. Ele pode ser um transportador não confiável dos bytes sem ganhar autoridade sobre o conteúdo.

O mecanismo permite que a decisão do serviço chegue ao plano de recursos. Não converte automaticamente uma autorização em capacidade instalada, nem capacidade em mídia entregue.

A reserva é posterior ao token e anterior ao resultado

O fluxo apresentado pela RFC 3521 é sequencial. O servidor de gerenciamento pode dizer que a configuração terminou ou ainda progride e entregar o token. O host envia uma mensagem PATH. O roteador de borda consulta um servidor de política, que pode até modificar os recursos. Depois da negociação de ponta a ponta, uma RESV pode informar que a reserva está completa ou continua progredindo.

Cada transição precisa de identidade própria. Se o servidor de política reduziu a largura, a admissão não corresponde literalmente à solicitação inicial. Se a RESV ainda está em progresso, a palavra “completa” não pode migrar do plano de sinalização para o de serviço.

A RFC 3312 reforça essa separação. As precondições de QoS em SIP mantêm status desejado e atual. Enquanto uma precondição obrigatória não for satisfeita, o estabelecimento fica suspenso e a mídia não deve fluir. Um evento de reserva pode atualizar o status atual, mas ainda faltam a continuação da sinalização, a observação do transporte e a confirmação da aplicação.

Uma fila reservada não é voz decodificada. Um pacote transmitido não é experiência contínua. Uma resposta de aplicação não é consentimento retroativo. O recibo final deve responder à promessa efetivamente feita.

O token descreve um mandato estreito

AUTH_SESSION pode trazer a entidade autorizadora, o identificador da sessão, endereços de origem e destino, início e fim, recursos e dados de autenticação. O recurso pode ser representado por banda máxima, flow spec RSVP, descrição SDP ou DSCP.

No modelo não associado, todos os campos precisam corresponder ao pedido. Origem e destino do datagrama devem coincidir, e a QoS solicitada não pode exceder o autorizado. Divergência deve levar à negação.

Até a ausência de uma lista é material. Sem lista de portas para um lado, todas as portas daquele lado são consideradas válidas pelas regras do documento. Com uma lista, apenas as portas enumeradas cabem no mandato. O registro precisa conservar campo, ausência, normalização, valor observado e resultado, não apenas “QoS autorizada”.

Testes devem variar endereço, porta, banda, DSCP e duração separadamente. Verificar só uma assinatura corrompida testa integridade, não a fronteira semântica do direito.

A topologia define onde mora a confiança

No modelo acoplado, o mesmo servidor participa das decisões de serviço e de recurso. Só SESSION_ID é obrigatório, porque ele aponta para o estado guardado. A implementação escolhe o formato, mas precisa manter o estado em réplicas, reinícios e failover.

No associado, o elemento também identifica o autorizador. O domínio de recursos localiza o servidor que mantém a decisão sobre mídia. Se não puder saber por outra fonte que essa identidade é um servidor legítimo, precisa de autenticação para evitar o desvio a um autorizador falso.

Na variante com dois servidores, um conhece o serviço e outro controla o recurso. Consulta, resposta e condição local de confiança fazem parte da evidência. No modelo não associado, o verificador talvez não compartilhe qualquer estado com o emissor; por isso o token carrega contexto suficiente para decisão autônoma.

Uma caixa “token válido” não audita todas essas arquiteturas. Ela esconde dependências diferentes sob o mesmo adjetivo.

Identidade autenticada não é autoridade automática

AUTHENTICATION_DATA protege os atributos anteriores. A especificação histórica descreve chave compartilhada, Kerberos e chave pública; o caso de chave pública inclui caminho de certificados, revogação e assinatura.

Depois de identificar o autorizador e validar o pedido de serviço, o roteador ou Policy Decision Point ainda consulta tabelas de política local. O conteúdo dessas tabelas é local. Informação suplementar usada na decisão deve ser obtida com segurança.

A criptografia diz que uma chave aceita protegeu aqueles bytes. A política diz se o titular da chave pode comprometer aquele recurso naquele domínio. Confundir as duas respostas transforma origem verificável em delegação sem limite. Os algoritmos citados em 2003 não são recomendação atual de implantação criptográfica.

Frescor exige relógio ou memória

Para impedir replay, a construção do elemento requer START_TIME ou SESSION_ID. O início cria dependência de fonte de tempo, diferença de relógio e janela de aceitação. No modelo não associado, os servidores devem suportar sincronização NTP; o texto alerta que relógios fora de sincronia podem permitir repetição.

O identificador cria dependência de estado: quando nasceu, se já foi usado e se o registro resistiu a replicação, reinício e troca de servidor. A mesma assinatura continua correta na repetição. A criptografia não lembra o primeiro uso.

O recibo deve preservar fonte temporal, offset, janela e decisão anti-replay, ou criação, uso e replicação durável do identificador. A RFC 5905 fornece contexto NTP posterior, não evidência de disciplina temporal de uma implantação.

Parte do caminho pode ignorar a política

Um roteador RSVP policy-aware encaminha a mensagem ao PDP e espera resposta. Um roteador policy-unaware ignora os objetos de dados de política e segue processando RSVP. A presença de AUTH_SESSION não demonstra enforcement em cada salto.

É necessário mapear quais nós são PEP, qual PDP cada um consultou, quais ignoraram o objeto e qual estado foi de fato instalado. O trajeto dos bytes e a cobertura da política são fatos separados.

Se o PDP não verificar o elemento, a RFC 3520 determina Policy Control Failure, Error Code 02, e recomenda detalhe em AUTH_DATA. Esse erro delimita uma falha de verificação. Sua ausência não prova política aprovada, capacidade disponível, reserva completa ou aplicativo funcional.

Um livro-razão em camadas

Preserve o pedido original, o ator autenticado e o principal por quem age. Registre identidade e alcance do autorizador, versão da decisão, estado retido, hash dos bytes exatos, credencial, certificado, revogação e decisão de replay.

Compare origem, destino, portas, recurso e validade entre token e reserva. Guarde qualquer alteração do PDP. Registre quem decidiu, quem aplicou e quem ignorou. Correlacione PATH, RESV e erros à mesma transação.

Depois acrescente status desejado e atual de SIP, telemetria do tráfego e confirmação autenticada do aplicativo. O sistema comercial deve declarar qual recibo fecha “concluído”.

No failover, o substituto não pode aprovar replay por perder o estado anterior. Um salto de relógio não pode ampliar o mandato silenciosamente. Uma rota nova não pode manter a etiqueta de admissão fora da cobertura conhecida.

Limite da evidência

Este Artigo não identifica produto, fornecedor, operadora, roteador, servidor, cliente, usuário, sessão, mídia, incidente ou implantação. Não afirma uso atual, conformidade, segurança, desempenho, QoS ou resultado comercial de sistema algum.

A RFC 3520 é tratada como trabalho Standards Track de abril de 2003 atualmente Proposed Standard. As RFCs 3521, 3313 e 5866 mantêm seus status e escopos. As premissas especializadas de domínio da RFC 3313 não são generalizadas à internet pública. NTP e Diameter posteriores entram apenas como comparação.

As notas de Heng Lu sobre autoridade e running code são lentes editoriais declaradas. Ajudam a distinguir declaração formal de controle e resultado observável; não documentam intenção da IETF.

A conclusão é limitada: autorização autêntica, fresca, correspondente e admitida ainda não é prova de que a sessão foi entregue.

Fontes