Resumo

  • A RFC 3327 permitiu que proxies acrescentassem um Path ordenado durante o REGISTER; depois do registro bem-sucedido, o registrador associava esse vetor ao vínculo entre AOR e Contact e o devolvia.
  • Mais tarde, o proxy do domínio de origem podia copiar o vetor salvo para um cabeçalho Route em pedidos dirigidos àquele Contact. O vetor não prova qual caminho o pacote REGISTER realmente percorreu.

A capacidade vinha antes do vetor

Um registrador SIP pode guardar o endereço em que um agente de usuário, ou UA, está disponível. Esse vínculo responde a uma pergunta estreita: qual Contact deve receber um pedido para este address-of-record, ou AOR? Ele não responde necessariamente outra: quais proxies intermediários o pedido precisa atravessar para alcançar aquele Contact?

A lacuna aparece quando o REGISTER cruza proxies de borda que o proxy do domínio de origem não consegue reconstruir pelo DNS nem por suas próprias tabelas de roteamento. O UA pode se registrar a partir de uma rede visitada, o registrador pode estar em outro lugar e uma chamada de entrada futura talvez precise voltar por nós que não aparecem no URI do Contact. Publicada em dezembro de 2002, a RFC 3327 deu a esses nós um modo de deixar um vetor de rota na troca de registro.

O nome “Path” pode soar como uma medição de caminho. Não era essa a função. Um proxy atravessado pelo REGISTER podia acrescentar um valor Path. O registrador guardava os valores em ordem junto ao vínculo do Contact e da AOR e os refletia numa resposta REGISTER bem-sucedida. Depois, ao consultar o vínculo, um proxy do domínio de origem podia inserir o vetor em um Route pré-carregado e encaminhar o novo pedido por aqueles proxies. A memória ficava com o vínculo, não com uma captura de pacotes da transação REGISTER.

Uma rota que atravessa a fronteira da transação

Path se parece com Record-Route, mas os dois têm horizontes diferentes. Record-Route estabelece o roteamento de pedidos dentro do diálogo que o criou. Path aparece no REGISTER e na resposta bem-sucedida para que uma sequência de proxies possa ser usada em diálogos futuros. A infraestrutura de roteamento já definida pela RFC 3261 executa Route; a RFC 3327 transporta a sequência para além do registro.

O escopo era limitado. O mecanismo se aplica a pedidos que atravessam ou se originam no domínio de origem do usuário. Os valores seguem a sintaxe de um elemento Route e usam o parâmetro de roteamento solto ;lr. O UA pode anunciar suporte com Supported: path; em geral, proxies não devem acrescentar Path sem essa indicação. Se o registrador recebe Path sem indicação de suporte, a RFC recomenda rejeitar o pedido, mas permite que a política local determine como agir.

A mudança histórica não foi fazer o SIP saber por onde cada pacote passou. O registro virou o lugar em que proxies podem associar contexto de roteamento ao vínculo que orientará pedidos de entrada futuros. A resposta do registrador também devolve Path ao UA, deixando os proxies acrescentados visíveis para inspeção em vez de transformá-los, silenciosamente, em um mapa universal da topologia.

O vetor não é testemunha

A RFC 3327 permite explicitamente que um proxy com conhecimento da topologia acrescente um Path que aponta para outro nó, ainda que o valor não corresponda ao caminho que o REGISTER percorreu. Isso define como interpretar o campo: Path é uma prescrição ordenada de rota, montada sob políticas de proxy e de registrador, não uma evidência forense do trajeto dos pacotes. Sozinho, não prova que um proxy encaminhou uma mensagem anterior, que a rota proposta continua alcançável nem que uma chamada futura será entregue.

Essa opção também criou uma fronteira de segurança. Um proxy inserido no vetor salvo poderia entrar no caminho de pedidos futuros e interceptar chamadas. Por isso, a RFC 3327 trata da integridade do transporte e da autenticação mútua, como TLS ou IPsec, e descreve cópias S/MIME protegidas para que o UA possa detectar alterações no Path devolvido. Um URI sintaticamente válido não é, por isso, um intermediário autorizado.

Trabalhos posteriores reutilizaram o mecanismo para um fim mais específico. A RFC 5626 coloca um token de fluxo único em Path para que o proxy de borda associe um pedido futuro a uma conexão iniciada pelo cliente. Esse comportamento por fluxo pertence à extensão posterior; não deve ser atribuído a todo vetor RFC 3327. No sentido oposto, o Service-Route da RFC 3608 dá ao UA uma rota para seus próprios pedidos de saída, não um caminho para pedidos de entrada dirigidos ao UA.

Fontes