RFC 3261 SIP: Session Initiation Protocol Junho 2002
descrito na seção anterior, ele DEVE reusar a conexão TLS com o servidor proxy local quando ele envia uma requisição INVITE a um outro usuário. O UA DEVE reusar as credenciais cache-ada no INVITE para evitar acionar o usuário desnecessariamente.
Quando o servidor proxy sainte local validou as credenciais apresentadas pelo UA no INVITE, ele DEVE inspecionar o Request-URI para determinar como a mensagem deve ser roteada (ver [4]). Se a parte "domainname" do Request-URI correspondeu ao domínio local (atlanta.com) ao invés de biloxi.com, então o servidor proxy consultaria seu serviço de localização para determinar como melhor alcançar o usuário requisitado.
"alice@atlanta.com" foi acionada para contactar, digamos, com "alex@atlanta.com", o proxy local teria proxy-iado a requisição na conexão TLS que Alex estabeleceu com o registrador quando ele se registrou. Como Alex receberia essa requisição sobre seu canal autenticado, ele estaria seguro que a requisição de Alice foi autorizada pelo servidor proxy do domínio administrativo local.
Contudo, nesse exemplo o Request-URI designa um domínio remoto. O servidor proxy sainte local no atlanta.com DEVE, portanto, estabelecer uma conexão TLS com o servidor proxy biloxi.com remoto. Como ambos os participantes nessa conexão TLS são servidores que possuem certificados de site, autenticação TLS mútua DEVE ocorrer. Cada lado da conexão DEVE verificar e inspecionar o certificado do outro, observando o nome de domínio que aparece no certificado por comparação com os campos-cabeçalhos de mensagens SIP. O servidor proxy atlanta.com, por exemplo, DEVE verificar nesse estágio que o certificado recebido do lado remoto corresponde ao domínio biloxi.com. Uma vez feito assim, e a negociação TLS concluída, resultando em um canal seguro entre os dois proxy's, o proxy atlanta.com pode encaminhar a requisição INVITE ao biloxi.com.
O servidor proxy em biloxi.com DEVE inspecionar o certificado do servidor proxy em atlanta.com por sua vez, e comparar o domínio declarado pelo certificado com a parte "domainname" do campo-cabeçalho From na requisição INVITE. O proxy biloxi PODE ter uma política de segurança rígida que o obriga a rejeitar requisições que não batem com o domínio administrativo do qual elas foram proxy-iadas.
Tais políticas de segurança poderiam ser instituídas a fim de prevenir o equivalente SIP dos 'open relays' do SMTP que são frequentemente explorados para gerar spam.
Rosenberg, et. al. Standards Track [Página 244]
Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:
User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.
Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:
MUST:
PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO,
NECESSITAR, É MANDATÓRIO.
MUST NOT:
NÃO PODE, É PROIBIDO, É VEDADO.
SHOULD:
DEVE, É RECOMENDADO.
SHOULD NOT:
NÃO DEVE, NÃO É RECOMENDADO.
MAY:
PODE, É OPCIONAL.
Nenhum comentário:
Postar um comentário