Resumo

  • RFC 3524 criou a semântica SRF para pedir que linhas de mídia identificadas por mid compartilhassem um fluxo de reserva.
  • A linha declarava o mapeamento desejado; admissão, política, estado de QoS, refresh, classificação e reprodução continuavam separados.

a=group:SRF 1 2 reunia dois identificadores em Single Reservation Flow. Um terminal remoto podia saber que áudio e vídeo deveriam alimentar uma única tentativa de reserva, sem deduzir a intenção a partir de portas ou codecs.

O documento distinguia desde o início mídia e reserva. Uma sessão podia agrupar tudo, separar cada mídia ou misturar os dois modelos. SRF escolhia a relação. Não oferecia banda, rota ou prioridade.

As palavras SHOULD e SHOULD NOT preservavam isso: linhas dentro do grupo deveriam ir ao mesmo fluxo; linhas de fora não deveriam entrar nele. Até uma única linha podia formar SRF. A instrução organizava o próximo pedido e não descrevia um recurso já instalado.

O framework de agrupamento tornava as referências verificáveis. Cada mid precisava ser único e o group enumerava esses nomes sob uma semântica. Identificador sem linha correspondente não ganhava realidade por aparecer na lista. RFC 5888 manteve a estrutura; SDP também permite ignorar atributo desconhecido. Receber texto correto não prova suporte.

O mecanismo importava quando o remoto participava da reserva. Se o gerador do SDP pudesse alocar as duas direções, escolheria localmente. Sem group, o remoto do exemplo ficava livre para abrir duas sessões RSVP.

SIP e RSVP eram exemplos, não requisitos. Outra sinalização ou mecanismo de reserva podia realizar a mesma sintaxe. SRF permanecia no plano descritivo.

No RSVP, o receptor ainda enviava Resv com flowspec de QoS e filter spec de pacotes. Cada nó executava admissão para capacidade e controle de política para permissão. Falha em qualquer teste impedia instalar aquele estado. Só depois classificador e escalonador podiam ser configurados.

O estado era soft state, mantido por Path e Resv. Mudanças de rota criavam estado novo e deixavam o antigo expirar. Assim, o SDP podia permanecer autêntico enquanto a reserva desaparecia.

Nem ResvConf era garantia: RFC 2205 admitia confirmação seguida de erro quando outras solicitações ou a fusão mudassem o resultado. Uma linha SRF, anterior a tudo isso, não era recibo de serviço.

RFC 3312 separou estado QoS atual e desejado. A separação existe porque intenção não produz estado. SRF dizia quais mídias compartilharão a tentativa; não dizia que as duas direções atingiram a condição.

O ataque consistia em alterar esse desenho. Linhas SRF inseridas podiam forçar mais ou menos reservas, consumindo recursos do endpoint ou degradando qualidade. Por isso a integridade do SDP foi fortemente recomendada, com S/MIME no SIP.

Integridade prova autoria e ausência de alteração. Não cria capacidade, não vence política, não dá suporte a quem ignora SRF, não renova estado e não prova áudio ouvido. O registro IANA igualmente coordena o token; não observa implantação.

A lição é manter os recibos distintos: SDP válido, mid resolvidos, intenção autenticada, mapeamento escolhido, pedido, admissão por nó, estado instalado, refresh, classificação, pacote e mídia apresentada. A presença de SRF cobre apenas o começo.

Fontes