Resumo

  • O RFC 5159 é um documento Informational de março de 2008 para quatro atributos SDP produzidos no contexto OMA BCAST.
  • stkmstream associava uma mídia protegida aos fluxos de Short Term Key Messages que o terminal deveria processar.
  • A repetição do atributo podia expressar alternativas ou a necessidade de receber mais de um fluxo.
  • A simples presença de referências não provava que qualquer mensagem de chave tivesse chegado ou fosse utilizável.
  • Uma declaração no nível de mídia substituía a lista no nível da sessão, fazendo do escopo parte do estado efetivo.
  • O número do fluxo só precisava ser único na sessão SDP e não constituía identidade global persistente.
  • bcastversion declarava uma versão, mas um valor sem integridade podia ser alterado para forçar downgrade.
  • SRTPAuthentication selecionava RCCm1, RCCm2 ou RCCm3 sem autenticar por si só um pacote.
  • SRTPROCTxRate anunciava a frequência de transmissão do rollover counter, com padrão igual a um.
  • A frequência configurada não demonstrava recepção autenticada do contador nem sincronismo vivo.
  • IETF e IANA registraram os nomes, enquanto a OMA preservou o controle de mudança de significado.
  • Evidência confiável separa mapa, escolha, pacote, autorização, chave, estado instalado, autenticação, decifragem e reprodução.

Cardinalidade era parte da política

Uma sessão de radiodifusão podia transportar muitos fluxos, e o terminal não deveria gastar rádio, bateria e processamento com todos eles. stkmstream oferecia uma forma econômica de indicar onde estavam as mensagens de chave relevantes para a mídia escolhida.

O atributo podia aparecer mais de uma vez. Essa repetição não tinha uma única leitura operacional automática. Dependendo da especificação BCAST aplicável, os fluxos podiam servir como opções equivalentes ou como partes que precisavam ser processadas em conjunto. Assim, o número de linhas na SDP não era o número de sucessos esperados.

Um painel que marca o item como concluído depois do primeiro fluxo recebido pode estar certo para uma alternativa e errado para uma composição obrigatória. Um painel que exige todos pode causar falha artificial quando bastava uma opção. A decisão depende da versão semântica e da política da sessão, não apenas da sintaxe.

O registro útil precisa guardar a regra de cardinalidade, qual alternativa foi selecionada, quais fluxos eram obrigatórios e o resultado individual de cada ramo. Sem isso, uma lista expressiva vira apenas uma contagem enganosa.

O caminho apontado não transportava o objeto

Mesmo depois de resolver a cardinalidade, stkmstream continuava sendo um mapa. O terminal ainda tinha de assinar ou sintonizar o fluxo, receber os pacotes, verificar o que fosse exigido, interpretar a mensagem, demonstrar direito, desembrulhar o material de chave e instalar o contexto correto.

Depois disso, o tráfego SRTP precisava passar pela autenticação e pela decifragem. A aplicação ainda precisava entregar imagem ou som. Cada etapa podia falhar sem tornar a linha SDP sintaticamente incorreta.

Essa sequência mostra por que “fluxo de chave presente” não deve ser usado como métrica de acesso. A presença pertence ao plano de descrição. A recepção pertence ao transporte. O direito pertence à política de acesso. A instalação pertence ao estado do terminal. A decifragem e a reprodução pertencem ao resultado. Misturá-los produz uma taxa de sucesso que não identifica onde o serviço realmente parou.

Para mídia não criptografada, o atributo era opcional. A ausência, portanto, tampouco era falha por definição. Antes de avaliar completude, o sistema de observação tinha de saber se aquela mídia exigia proteção.

O nível de mídia podia reescrever a lista

Uma declaração stkmstream no nível da sessão fornecia um conjunto comum. Quando aparecia no nível de uma mídia, substituía a declaração global para aquela seção. Não era uma simples união.

Essa regra de escopo pode separar o estado do servidor do estado do terminal. O servidor publica uma atualização que troca os fluxos da faixa de vídeo. O terminal pode manter a versão antiga em cache, receber a nova sem aplicá-la ou achatar a estrutura e unir valores que deveriam substituir uns aos outros. A configuração de origem continua correta, mas a execução diverge.

A prova deve conter a SDP exata recebida, sua versão ou hash, a seção de mídia, a resolução de escopo feita pelo receptor e a decisão de sintonização. Guardar apenas a descrição enviada não prova a descrição aplicada. Guardar somente o resultado resolvido impede verificar se o software executou a regra certa.

Os identificadores também eram números diferentes de zero únicos apenas dentro daquela sessão. Exportar stream=6 sem a identidade da sessão cria uma chave falsa. Outra sessão pode reutilizar seis para conteúdo, chaves e política completamente diferentes.

Um valor de autenticação era uma instrução

O RFC definiu SRTPAuthentication para escolher RCCm1, RCCm2 ou RCCm3. A escolha permitia que as pontas alinhassem o procedimento. Não produzia um veredito sobre nenhum pacote específico. Esse veredito só surgia ao processar o pacote com chave, contador e estado corretos.

SRTPROCTxRate informava a taxa de envio do rollover counter entre 1 e 65535, usando um quando ausente. O ROC complementa o espaço do número de sequência. Se o receptor perde a atualização relevante ou a rejeita, ele pode ficar com um valor diferente do emissor ainda que ambos mostrem a mesma configuração estática.

É preciso registrar a taxa declarada e a taxa observada, o pacote de controle, sua autenticação, o contador aceito e o resultado SRTP subsequente. “Programado para cada pacote” não equivale a “recebido e aplicado a cada pacote”.

Metadados de versão podiam reduzir a segurança

bcastversion parecia um rótulo de compatibilidade. O RFC, porém, avisou que a alteração de um valor sem proteção poderia levar o terminal a uma versão anterior. O atributo não continha segredo, mas escolhia regras que afetavam proteção.

Uma alteração de stkmstream podia desviar o terminal dos fluxos necessários ou fazê-lo processar fluxos inúteis, causando negação de serviço. Isso mostra que a integridade precisa alcançar os metadados que comandam a busca e o uso de segredos.

A cópia publicada pelo servidor e a cópia recebida pelo dispositivo são recibos distintos. Para demonstrar ausência de downgrade, é necessário ligar a descrição recebida, a verificação de integridade, a interpretação de versão e o comportamento efetivamente selecionado.

O nome estava registrado onde o significado não era controlado

O RFC 5159 foi publicado como Informational porque a tecnologia vinha da Open Mobile Alliance. O registro IANA deu aos atributos nomes estáveis no espaço SDP, enquanto a OMA manteve o controle sobre a interpretação técnica. A coordenação do vocabulário e a custódia semântica pertenciam a instituições diferentes.

Uma linha de registro prova alocação e reduz colisões. Ela não certifica uma implementação, não transfere propriedade e não prova adoção. A classificação posterior de multiplexação marcou bcastversion e stkmstream como NORMAL, deixando a categoria dos dois atributos SRTP sem determinação. Esse rótulo trata de cópia entre descrições agrupadas, não de segurança ou maturidade.

O documento dizia que os atributos eram esperados em ambientes 3GPP MBMS, 3GPP2 BCMCS e DVB-H. A frase preserva o contexto de projeto de 2008. Para afirmar que um operador implantou o mecanismo, seriam necessários artefatos operacionais. Para afirmar que um usuário reproduziu conteúdo, seria necessário seguir a cadeia até o terminal.

Fontes

  1. RFC 5159, HTML
  2. RFC 5159, texto
  3. Registro do RFC Editor
  4. Registro do IETF Datatracker
  5. Histórico do RFC 5159
  6. Referências do RFC 5159
  7. Errata do RFC 5159
  8. RFC 4566
  9. RFC 8866
  10. RFC 4771
  11. RFC 3711
  12. RFC 8859
  13. RFC 5761
  14. RFC 7201
  15. RFC 5764
  16. RFC 8126
  17. Parâmetros SDP da IANA
  18. Declaração de IPR 2092
  19. RFC 2119
  20. RFC 8174
  21. RFC 3264
  22. Especificação inicial mínima
  23. Sobre camadas de realidade
  24. Primazia do código em execução