Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


sua identidade ao proxy biloxi, mas ela tem uma assinatura CMS detached em um corpo "message/sip" no INVITE. É pouco provável nesse caso que Carol tivesse quaisquer credenciais no realm biloxi.com, já que ela não tem nenhuma associação formal com biloxi.com. O proxy biloxi PODE também ter uma política rígida que o impessa se sequer de preocupar em desafiar requisições que não tem biloxi.com na parte "domainname" do campo-cabeçalho From - ele trata esses usuários como não autenticado.

O proxy biloxi tem uma política para Bob onde todas as requisições não autenticadas devem ser redirecionadas ao endereço de contato apropriado registrado como 'bob@biloxi.com', ou seja, . Carol recebe a resposta de redirecionamento sobre a conexão TLS que ela estabeleceu com o proxy biloxi, de modo que ela confia na veracidade do endereço de contacto.

Carol DEVE então estabelecer uma conexão TCP com o endereço designado e enviar um novo INVITE com um Request-URI contendo o endereço de contato recebido (recomputa a assinatura no corpo enquanto a requisição é preparada). Bob recebe esse INVITE em uma interface insegura, mas seu UA inspeciona e, nesse exemplo, reconhece o campo-cabeçalho From da requisição e, subsequentemente, bate com um certificado em cache localmente com aquele apresentado na assinatura do corpo do INVITE. Ele responde de forma similar, autentica-se com Carol e um diálogo seguro começa.

Às vezes, firewall's ou NAT's em um domínio administrativo pode impedir o estabelecimento de uma conexão TCP direta com um UA. Nesses casos, servidores proxy também podem potencialmente transmitir requisições aos UA's de uma forma que não tenha implicações de confiança (por exemplo, abrir mão de uma conexão TLS existente e encaminhar a requisição sobre o TCP sem criptografia), como dita a política local.


26.3.2.4 Proteção contra DoS

A fim de minimizar o risco de um ataque de negação de serviço contra arquiteturas que usam essas soluções de segurança, implementadores devem tomar nota das seguintes diretrizes.

Quando o host sobre o qual um servidor proxy SIP está operando for roteável a partir da Internet, ele DEVE ser implantado em um domínio administrativo com políticas de defesas operacionais (bloqueio de tráfego roteado pela origem, preferencialmente filtragem de ping). Ambos os TLS e IPSec podem também fazer uso de hosts bastiões nas bordas dos domínios administrativos que participam das associações de segurança para agregar túneis e soquetes seguros. Esses hosts bastiões podem também tirar o peso dos ataques de negação de serviço, assegurando que hosts SIP dentro do domínio administrativo não sejam onerados com a geração de mensagens supérfluas.






Rosenberg, et. al.          Standards Track                   [Página 246]

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.