Por que o tunelamento SSH não pode ser usado para criptografia SIP VOIP?

Question

No link , ele diz "Observe que o tunelamento SSH não é um método viável para Criptografia de caminho de mídia VoIP. " Por que o tunelamento SSH (em oposição a uma VPN) não pode ser usado para criptografia VOIP ao usar protocolos VOIP inseguros (como o SIP normal)?

    

Answer 1

O protocolo SSH é executado na parte TCP da pilha TCP / IP. SIP ou outro tipo de voip geralmente é executado em cima do protocolo UDP.

Uma das diferenças significativas entre o TCP e o UDP é que o TCP (de certa forma) garante a entrega de cada pacote. UDP, por outro lado, não. É fogo e esqueça. A conseqüência disso, se houver algum problema de rede, o TCP irá parar e tentar reenviar os pacotes perdidos / corrompidos. Com o UDP, eles serão simplesmente perdidos.

Quando você o aplica a VOIP, um pacote UDP ausente se transforma em apenas uma palavra ilegível do chamador. Um pacote TCP ausente se torna inconsistente e atrasos incômodos, palavras ainda truncadas e outras interferências durante uma chamada.

Em aplicações onde algumas perdas de pacotes não são críticas, como voip ou streaming de música ou certos tipos de streaming de vídeo ou outros aplicativos relacionados a tempo real, o UDP é perfeitamente aceitável e o TCP fornece sobrecarga e complicações desnecessárias.

O protocolo SSH espera uma conexão sem perdas porque, para ele, cada pacote é crítico para garantir a integridade dos dados criptografados dentro da conexão SSH.

    

Answer 2

Acho que só podemos adivinhar a intenção dos autores e o público-alvo (e tenha em mente que isso foi escrito há mais de 5 anos agora). Eu diria que o problema é que o SSH é projetado para lidar com fluxos TCP em vez de UDP.

Embora eu tenha encontrado referência a encapsulamento de UDP sobre SSH , parece ser um recurso mais complexo hack - provavelmente não é algo ideal para uma rede VOIP. Da mesma forma, enquanto algumas VPNs (OpenVPN, por exemplo) podem criar túneis TCP, acho que você vai achar que a maioria prefere túneis UDP, já que são mais tolerantes à perda de pacotes.

Observando as características de um túnel TCP vs UDP, se um túnel UDP perder um pacote que não se importa, ele o abandona e espera que o fluxo encapsulado (se seu TCP) ou aplicativo (se for seu UDP) o manipule. Um túnel TCP iria tentar e reenviar o pacote, o que poderia ter o impacto de subitamente e altamente aumentando o jitter da conexão, tornando uma conexão VOIP muito infeliz - especialmente se os endpoints estão longe.

    

Answer 3

Note that SSH tunneling is not a viable method for VoIP media path encryption.

Ênfase minha.

O fluxo de mídia é normalmente negociado durante uma chamada SIP usando o Protocolo de descrição de sessão com freqüência como um fluxo de áudio bidirecional usando o < a href="http://en.wikipedia.org/wiki/Real-time_Transport_Protocol"> Protocolo de transporte em tempo real .

Do artigo da wikipedia para a RTP:

The Transmission Control Protocol (TCP), although standardized for RTP use, is not normally used in RTP applications because TCP favors reliability over timeliness. Instead the majority of the RTP implementations are built on the User Datagram Protocol (UDP).

As outras respostas sobre as diferenças entre o UDP e o TCP se aplicam (especialmente no túnel UDP por SSH), mas não são tão significativas para o SIP quanto para o RTP. O SIP é perfeitamente capaz de rodar em cima do TCP (e até do SCTP). A latência e / ou retransmissões da rede podem ser tratadas pelo protocolo de transporte (TCP / SCTP) ou, nos casos em que essas funções não são fornecidas na camada de transporte (UDP), o SIP possui seus próprios mecanismos para retransmissões e tempos limite.

Você pode, no entanto, encontrar problemas ao rotear o SIP sobre o tunelamento TCP via SSH também. Isto é por razões semelhantes pelas quais o SIP atravessando um NAT não é muito fácil. Muitos cabeçalhos nos corpos SIP e SDP incluem endereços IP relevantes, que você pode estar implicitamente obscurecendo no túnel. Os gateways da camada de aplicação geralmente lidam com isso em cenários NAT.

De fato, se você não for cuidadoso, você pode terminar tunelando o SIP pelo SSH sem tunelar o RTP!