SIP ALG

Operação SIP ALG

Existem dois tipos de tráfego SIP, a sinalização e o fluxo de mídia. O tráfego de sinalização SIP consiste em mensagens de solicitação e resposta entre cliente e servidor e usa protocolos de transporte, como UDP ou TCP. O fluxo de mídia transporta os dados (dados de áudio, por exemplo) usando protocolos de transporte.

A partir do Junos OS Release 12.3X48-D25 e do Junos OS Release 17.3R1, o SIP ALG oferece suporte a TCP. O suporte a TCP no SIP ALG reduz o tráfego para o servidor eliminando a necessidade de reregistor ou atualizar o servidor com frequência.

Por padrão, o Junos OS oferece suporte a mensagens de sinalização SIP na porta 5060. Você pode configurar a porta criando uma política que permite o serviço SIP, e o software filtra o tráfego de sinalização SIP como qualquer outro tipo de tráfego, permitindo ou negando. O fluxo de mídia, no entanto, usa números de porta atribuídos dinamicamente que podem mudar várias vezes durante uma chamada. Sem portas fixas, é inseguro criar uma política estática para controlar o tráfego de mídia. Nesse caso, o dispositivo invoca o SIP ALG. As portas de transporte de dispositivos usadas para as sessões de mídia não são conhecidas com antecedência; no entanto, as portas usadas para a negociação sip são bem conhecidas (ou predefinidas). O ALG registra interesse em pacotes da sessão de controle, que pode distinguir facilmente dos outros pacotes, e inspeciona a negociação das informações de transporte usadas para a sessão de mídia (endereços IP e portas).

O SIP ALG monitora transações sip e cria e gerencia dinamicamente pinholes com base nas informações que extrai dessas transações. O SIP ALG da Juniper Networks oferece suporte a todos os métodos e respostas sip. Você pode permitir que as transações SIP atravessem o firewall da Juniper Networks, criando uma política estática que permite o serviço SIP. Se a política for configurada para inspecionar o tráfego SIP (ou, mais apropriadamente, se a política enviar algum tráfego ao SIP ALG para inspeção), as ações permitidas são para permitir o tráfego (nesse caso os pinholes apropriados são abertos) ou negar o tráfego.

O SIP ALG intercepta mensagens SIP que contêm SDP e, usando um parser, extrai as informações necessárias para criar pinholes. O SIP ALG examina a porção SDP do pacote, e um parser extrai informações como endereços IP e números de porta, que o SIP ALG registra em uma tabela de pinhole. O SIP ALG usa os endereços IP e os números de porta registrados na tabela de pinhole para abrir pinholes e permitir que fluxos de mídia atravessem o dispositivo.

Os produtos NEC SIP são compatíveis condicionalmente.

Descrições da sessão SDP

Uma descrição da sessão SDP é um formato bem definido para transmitir informações suficientes para descobrir e participar de uma sessão multimídia. Uma sessão é descrita por uma série de pares de atributos/valor, um por linha. Os nomes de atributos são caracteres únicos, seguidos de =e um valor. Os valores opcionais são especificados com =*. Os valores são uma string ASCII ou uma sequência de tipos específicos separados por espaços. Os nomes de atributos são únicos apenas dentro da construção sintática associada, como apenas na sessão, tempo ou mídia.

Dos muitos campos na descrição do SDP, dois são particularmente úteis para o SIP ALG porque contêm informações da Camada de Transporte.

• c= para informações de conexão

  Este campo pode aparecer no nível de sessão ou mídia. Ele aparece neste formato:

  c=< tipo de rede>< endereço><conexão>

  O Junos OS oferece suporte apenas a "IN" (para Internet) como o tipo de rede, "IPv4" como tipo de endereço, e um endereço IP ou nome de domínio unicast como endereço IP de destino (conexão). A partir do Junos OS Release 15.1X49-D40 e do Junos OS Release 17.3R1, o tipo de endereço "IPv6" também é suportado.

  Se o endereço IP de destino for um endereço IP unicast, o SIP ALG cria pinholes usando o endereço IP e os números de porta especificados no campo de descrição da mídia m=.

• m= para comunicado de mídia

  Este campo aparece no nível da mídia e contém a descrição da mídia. Ele aparece neste formato:

  lista m=<media><port><transport><fmt>

  Atualmente, o Junos OS oferece suporte a "RTP" como o protocolo de transporte da Camada de Aplicativos. O número da porta indica a porta de destino do fluxo de mídia (a origem é alocada pelo UA remoto). A lista de formatos (lista fmt) fornece informações sobre o protocolo de Camada de Aplicativo que a mídia usa.

  O software abre portas apenas para RTP e protocolo de controle em tempo real (RTCP). Cada sessão RTP tem uma sessão RTCP correspondente. Portanto, sempre que um fluxo de mídia usa RTP, o SIP ALG deve reservar portas (criar pinholes) para tráfego RTP e RTCP. Por padrão, o número de porta para RTCP é um superior ao número da porta RTP.

Criação de pinhole

Cada pinhole (um para tráfego RTP e outro para tráfego RTCP) compartilham o mesmo endereço IP de destino. O endereço IP vem do campo c= na descrição da sessão SDP. Como o campo c= pode aparecer no nível de sessão ou na parte de nível de mídia da descrição da sessão SDP, o parser determina o endereço IP com base nas seguintes regras (de acordo com as convenções SDP):

• Primeiro, o parser SIP ALG procura um campo c= contendo um endereço IP no nível de mídia. Se houver esse campo, o parser extrai esse endereço IP e o SIP ALG usa esse endereço para criar um pinhole para a mídia.

• Se não houver campo c= no nível de mídia, o parser SIP ALG extrai o endereço IP do campo c= no nível de sessão, e o SIP ALG usa esse endereço IP para criar um pinhole para a mídia. Se a descrição da sessão não conter um campo c= em ambos os níveis, isso indica um erro na pilha de protocolos, e o dispositivo derruba o pacote e registra o evento.

O SIP ALG também abre buracos para tráfego de sinal. Esses pinholes de sinal são úteis após o intervalo de sessão de sinal anterior, e também são úteis para o tráfego de sinal enviado a um endereço de terceiros que não combina com a sessão de sinal anterior. Os pinholes de sinal SIP ALG nunca envelhecem, ao contrário dos pinholes RTP ou RTCP, onde apenas o IP de destino e a porta de destino são especificados.

O SIP ALG abre buracos de sinal para os seguintes cabeçalhos, se necessário:

• VIA

• CONTATO

• ROTA

• ROTA RECORDE

O SIP ALG precisa das seguintes informações para criar um pinhole. Essas informações são provenientes da descrição da sessão SDP ou dos cabeçalhos SIP (conforme listado acima).

• Protocolo — UDP ou TCP.

• IP de origem — desconhecido.

• Porta de origem — desconhecida.

• IP de destino — o parser extrai o endereço IP de destino do campo c= no nível de mídia ou sessão.

• Porta de destino — o parser extrai o número da porta de destino para RTP do campo m= no nível de mídia e calcula o número da porta de destino para RTCP usando a seguinte fórmula:

  Porta RTP número + um

• Vida útil — Esse valor indica o tempo (em segundos) durante o qual um pinhole está aberto para permitir a passagem de um pacote. Um pacote deve passar pelo pinhole antes que a vida útil expira. Quando a vida útil expira, o SIP ALG remove o pinhole.

  Quando um pacote passa pelo pinhole dentro do período de vida útil, imediatamente depois o SIP ALG remove o pinhole para a direção de onde o pacote veio.

  A Figura 1 descreve uma configuração de chamada entre dois clientes SIP e como o SIP ALG cria pinholes para permitir tráfego RTP e RTCP. A ilustração pressupõe que o dispositivo tenha uma política que permite o SIP, abrindo assim a porta 5060 para mensagens de sinalização SIP.

  Figura 1: Configuração da chamada SIP ALG

• Entender o suporte IPv6 para SIP ALG
• Entender o dimensionamento do suporte de campo de lâmpada ocupado para o SIP ALG baseado em UDP
• Entender os métodos de solicitação do SIP ALG
• Visão geral da configuração do SIP ALG
• Entender a proteção contra ataques SIP ALG DoS
• Entender os tipos de mensagens desconhecidas SIP ALG
• Entender a duração e os intervalos de chamada do SIP ALG

Retenção de recursos de retenção SIP ALG (procedimento CLI)

Para acomodar fluxos de chamada SIP proprietários:

Chamadas de saída

Quando uma chamada SIP é iniciada com uma mensagem de solicitação sip da rede interna para a rede externa, o NAT substitui os endereços IP e os números de porta no SDP e vincula os endereços IP e os números de porta ao firewall Juniper Networks. Os campos de cabeçalho SIP via contato, rota e rota de registro, se presentes, também estão vinculados ao endereço IP do firewall. A ALG armazena esses mapeamentos para uso em retransmissões e para mensagens de resposta sip.

Em seguida, o SIP ALG abre pinholes no firewall para permitir que a mídia através do dispositivo nas portas dinamicamente atribuídas negociadas com base em informações no SDP e nos campos de cabeçalho via, contato e rota de registro. Os pinholes também permitem que os pacotes de entrada cheguem aos endereços e portas IP de contato, via e registro de rotas. Ao processar o tráfego de retorno, o ALG insere os campos SIP originais de contato, via, rota e rota de registro de volta em pacotes.

Chamadas recebidas

As chamadas recebidas são iniciadas da rede pública para endereços NAT estáticos públicos ou para interface de endereços IP no dispositivo. NATs estáticos são endereços IP configurados estaticamente que apontam para hosts internos; os endereços IP de interface são registrados dinamicamente pelo ALG enquanto monitora as mensagens REGISTER enviadas por hosts internos ao registrador SIP. Quando o dispositivo recebe um pacote SIP de entrada, ele configura uma sessão e encaminha a carga do pacote para o SIP ALG.

O ALG examina a mensagem de solicitação de SIP (inicialmente um CONVITE) e, com base em informações no SDP, abre portões para a mídia de saída. Quando uma mensagem de resposta de 200 OK chega, o SIP ALG executa NAT nos endereços e portas IP e abre buracos na direção de saída. (Os portões abertos têm pouco tempo de vida, e eles saem se uma mensagem de resposta de 200 OK não for recebida rapidamente.)

Quando uma resposta de 200 OK chega, o proxy SIP examina as informações do SDP e lê os endereços IP e os números das portas para cada sessão de mídia. O SIP ALG no dispositivo executa NAT nos endereços e números de porta, abre pinholes para tráfego de saída e atualiza o tempo limite para portões na direção de entrada.

Quando o ACK chega para o 200 OK, ele também passa pelo SIP ALG. Se a mensagem contém informações de SDP, o SIP ALG garante que os endereços IP e os números das portas não sejam alterados em relação ao CONVITE anterior — se forem, o ALG elimina pinholes antigos e cria novos pinholes para permitir que a mídia passe. O ALG também monitora os campos SIP via, contato e registro de rotas e abre novos pinholes se determinar que esses campos mudaram.

Ligações encaminhadas

Uma chamada encaminhada é quando, por exemplo, o usuário A fora da rede chama o usuário B dentro da rede, e o usuário B encaminha a chamada para o usuário C fora da rede. O SIP ALG processa o CONVITE do usuário A como uma chamada de entrada normal. No entanto, quando o ALG examina a chamada encaminhada de B para C fora da rede e percebe que B e C são alcançados usando a mesma interface, ele não abre pinholes no firewall, porque a mídia fluirá diretamente entre o usuário A e o usuário C.

Encerramento de chamadas

A mensagem BYE encerra uma chamada. Quando o dispositivo recebe uma mensagem BYE, ele traduz os campos de cabeçalho da mesma forma que faz para qualquer outra mensagem. Mas como uma mensagem BYE deve ser reconhecida pelo receptor com um 200 OK, o ALG atrasa a chamada de demolição por 5 segundos para permitir o tempo de transmissão do 200 OK.

Mensagens de re-CONVITE de chamada

As mensagens de re-CONVITE adicionam novas sessões de mídia a uma chamada e removem as sessões de mídia existentes. Quando novas sessões de mídia são adicionadas a uma chamada, novos pinholes são abertos no firewall e novas vinculações de endereço são criadas. O processo é idêntico à configuração de chamada original. Quando todas as sessões de mídia ou pinholes de mídia são removidas de uma chamada, a chamada é removida quando uma mensagem BYE é recebida.

Call Session Timers

Como medida de precaução, o SIP ALG usa valores de tempo limite difíceis para definir a quantidade máxima de tempo que uma chamada pode existir. Isso garante que o dispositivo esteja protegido caso ocorra um dos seguintes eventos:

• Os sistemas finais falham durante uma chamada e uma mensagem BYE não é recebida.

• Usuários mal-intencionados nunca enviam um BYE na tentativa de atacar um SIP ALG.

• Implementações ruins de proxy SIP não processam a Rota de Registro e nunca enviam uma mensagem BYE.

• Falhas de rede impedem que uma mensagem BYE seja recebida.

Cancelamento de chamadas

Qualquer uma das partes pode cancelar uma ligação enviando uma mensagem CANCEL. Ao receber uma mensagem CANCEL, o SIP ALG fecha os pinholes através do firewall — se houver algum foi aberto — e libera as vinculações de endereço. Antes de liberar os recursos, o ALG atrasa o envelhecimento do canal de controle por aproximadamente 5 segundos para permitir a passagem do 200 OK final. A chamada é encerrada quando o intervalo de 5 segundos expira, independentemente de uma resposta 487 ou não 200 chegar.

Bifurcação

A forking permite que um proxy SIP envie uma única mensagem DE CONVITE para vários destinos simultaneamente. Quando as várias mensagens de resposta a 200 OK chegam para a chamada única, o SIP ALG analisa, mas atualiza as informações de chamada com as primeiras 200 mensagens OK que recebe.

Mensagens SIP

O formato de mensagem SIP consiste em uma seção de cabeçalho SIP e o corpo SIP. Nas mensagens de solicitação, a primeira linha da seção de cabeçalho é a linha de solicitação, que inclui o tipo de método, solicitação-URI e versão de protocolo. Em mensagens de resposta, a primeira linha é a linha de status, que contém um código de status. Os cabeçalhos SIP contêm endereços IP e números de porta usados para sinalização. O corpo SIP, separado da seção de cabeçalho por uma linha em branco, está reservado para informações de descrição da sessão, que são opcionais. Atualmente, o Junos OS oferece suporte apenas ao SDP. O órgão SIP contém endereços IP e números de porta usados para transportar a mídia.

Cabeçalhos SIP

Na mensagem de solicitação de SIP da amostra a seguir, o NAT substitui os endereços IP nos campos de cabeçalho para escondê-los da rede externa.

A forma como a tradução do endereço IP é executada depende do tipo e direção da mensagem. Uma mensagem pode ser qualquer uma das seguintes:

• Solicitação de entrada

• Resposta de saída

• Solicitação de saída

• Resposta de entrada

A Tabela 1 mostra como o NAT é realizado em cada um desses casos. Observe que, para vários dos campos de cabeçalho, o ALG determina mais do que apenas se as mensagens vêm de dentro ou fora da rede. Ele também deve determinar qual cliente iniciou a chamada e se a mensagem é uma solicitação ou resposta.

Corpo SIP

As informações de SDP no órgão SIP incluem endereços IP que o ALG usa para criar canais para o fluxo de mídia. A tradução da seção SDP também aloca recursos, ou seja, números de porta para enviar e receber a mídia.

O trecho a seguir de uma seção de SDP amostral mostra os campos traduzidos para alocação de recursos.

As mensagens SIP podem conter mais de um fluxo de mídia. O conceito é semelhante à anexação de vários arquivos a uma mensagem de e-mail. Por exemplo, uma mensagem DE CONVITE enviada de um cliente SIP para um servidor SIP pode ter os seguintes campos:

O Junos OS oferece suporte a até 6 canais SDP negociados para cada direção, para um total de 12 canais por chamada. Para obter mais informações, consulte Entender o SIP ALG.

Cenário SIP NAT

Figura 2 e Figura 3 mostram um CONVITE de chamada SIP e 200 OK. Na Figura 2, o ph1 envia uma mensagem SIP INVITE para o ph2. Observe como os endereços IP nos campos de cabeçalho — mostrados em fonte ousada — são traduzidos pelo dispositivo.

A seção SDP da mensagem INVITE indica onde o interlocutor está disposto a receber mídia. Observe que o Media Pinhole contém dois números de porta, 52002 e 52003, para RTCP e RTP. O Pinhole via/contato fornece a porta número 5060 para sinalização SIP.

Observe como, na mensagem de resposta de 200 OK na Figura 3, as traduções executadas na mensagem INVITE são invertidas. Os endereços IP nesta mensagem, sendo públicos, não são traduzidos, mas os portões são abertos para permitir o acesso do fluxo de mídia à rede privada.

Figura 2: CENÁRIO SIP NAT 1

Figura 3: CENÁRIO SIP NAT 2

Aulas de respostas de SIP

As respostas do SIP fornecem informações de status sobre transações SIP e incluem um código de resposta e uma frase de motivo. As respostas do SIP são agrupadas nas seguintes classes:

• Informações (100 a 199)— Solicitação recebida, continuando a processar a solicitação.

• Sucesso (200 a 299)— A ação recebeu, entendeu e aceitou com sucesso.

• Redirecionamento (300 a 399)— Mais ações necessárias para concluir a solicitação.

• Erro do cliente (400 a 499)— A solicitação contém sintaxe ruim ou não pode ser cumprida neste servidor.

• Erro do servidor (500 a 599)— o servidor não conseguiu atender a uma solicitação aparentemente válida.

• Falha global (600 a 699)— A solicitação não pode ser atendida em nenhum servidor.

A Tabela 2 fornece uma lista completa das respostas atuais do SIP.

Modo NAT no modo IPv6 puro (NAT66) para SIP IPv6 ALG

O SIP IPv6 ALG oferece suporte ao NAT66, assim como o NAT44. O NAT66 (IPv6 NAT) fornece NAT de origem e funções NAT estáticas semelhantes ao NAT44 (IPv4 NAT).

NAT-PT

Network Address Translation Protocol Translation (NAT-PT) (RFC 2766) é um mecanismo de tradução de protocolo que permite a comunicação entre nós somente IPv6 e IPv4 por meio de tradução independente de protocolo de datagrams IPv4 e IPv6, sem exigir informações de estado para a sessão.

O NAT-PT é implementado pelo NAT normal desde o endereço IPv6 até o endereço IPv4 e vice-versa. O SIP ALG processa essas traduções de endereço na carga, assim como os endereços são processados em NAT normal.

O NAT-PT vincula os endereços na rede IPv6 com endereços na rede IPv4 e vice-versa para fornecer roteamento transparente para os datagrams que atravessam entre os reinos de endereço.

A principal vantagem do NAT-PT é que os dispositivos finais e as redes podem executar endereços IPv4 ou endereços IPv6 e o tráfego pode ser iniciado de qualquer lado.

NAT64

O NAT64 é um mecanismo para permitir que hosts IPv6 se comuniquem com servidores IPv4. O NAT64 é necessário para manter o mapeamento de endereços IPv6 a IPv4. Esse mapeamento de endereços é configurado estaticamente pelo administrador do sistema (tradução stateless) ou, mais frequentemente, criado automaticamente quando o primeiro pacote da rede IPv6 chega ao NAT64 para ser traduzido (stateful).

O NAT64 é implementado em dispositivos usando NAT persistente. Quando a primeira mensagem de solicitação sip (primeiro pacote deve ser apenas do IPv6) transversa o DUT, a vinculação de endereço é criada e, em seguida, os pacotes podem fluir em ambas as direções.

O mecanismo NAT64 traduz pacotes IPv6 para pacotes IPv4 e vice-versa, o que permite que os clientes IPv6 entrem em contato com os servidores IPv4 usando UDP unicast, TCP ou ICMP. O comportamento do NAT-PT e do NAT64 parece semelhante, mas esses mecanismos são implementados de maneira diferente.

Quando o NAT64 com NAT persistente é implementado, o SIP ALG com suporte para IPv6 adiciona a tradução de NAT à tabela de ligação NAT persistente se o NAT estiver configurado no endereço de registro. Como o NAT persistente não pode duplicar o endereço configurado, a coexistência de NAT66 e NAT64 configuradas no mesmo endereço não é suportada.

Apenas uma vinculação é criada para o mesmo endereço IP de origem.

STUN e SIP ALG

Session Traversal Utilities for NAT (STUN) é uma solução para fazer o VoIP funcionar através de NAT e firewall.

Anteriormente, a STUN trabalhava sem o SIP ALG. Isso significa que o SIP ALG não estava envolvido quando o NAT persistente estava configurado.

O STUN pode coexistir com o SIP ALG e o SIP ALG está envolvido quando o NAT persistente está configurado.

Entender o suporte a chamadas SIP ALG que chegam usando o registrador SIP e o NAT

O registro do Protocolo de Iniciação de Sessão (SIP) oferece um recurso de descoberta pelo qual os servidores SIP e de localização podem identificar a localização ou os locais onde os usuários desejam ser contatados. Um usuário registra um ou mais locais de contato enviando uma mensagem DE REGISTRO ao registrador. Os campos de Entrada e Contato na mensagem REGISTER contêm o identificador de recursos uniformes (URI) de endereço de registro e uma ou mais URIs de contato, conforme mostrado na Figura 4. O registro cria vinculações em um serviço de localização que associa o endereço de registro com o endereço de contato ou endereços.

O dispositivo monitora mensagens DE REGISTRO de saída, executa a tradução de endereços de rede (NAT) nesses endereços e armazena as informações em uma tabela NAT de entrada. Em seguida, quando uma mensagem INVITE é recebida de fora da rede, o dispositivo usa a tabela NAT de entrada para identificar qual host interno roteia a mensagem INVITE. Você pode aproveitar o serviço de registro de proxy SIP para permitir chamadas recebidas configurando nat de origem da interface ou pools NAT na interface de saída do dispositivo. O NAT de origem da interface é adequado para lidar com chamadas recebidas em um escritório pequeno, enquanto recomendamos a criação de pools NAT de origem para redes maiores ou um ambiente empresarial.

Nota:

O suporte a chamadas recebidas usando NAT de origem de interface ou um pool NAT de origem é suportado apenas para serviços SIP e H.323. Para chamadas recebidas, o Junos OS atualmente oferece suporte apenas a UDP e TCP. A resolução de nomes de domínio também não é suportada no momento; portanto, as URIs devem conter endereços IP, conforme mostrado na Figura 4.

Figura 4: Usando o registrador SIP