Qual é o gargalo de IPsec no Linux?

19

Estou tentando comparar o desempenho de vários protocolos de segurança de rede entre dois hosts conectados na Gigabit Ethernet.

Meu objetivo aqui é ver se consigo saturar minha largura de banda e, se não, qual é o fator limitante.

com SSL, posso atingir 981 MBit / s; portanto, o link Ethernet é obviamente o fator limitante;
com o SSH, posso atingir apenas 750 MBit / s, mas um dos meus núcleos tem 100% de uso. Como o SSH é de thread único, a CPU é o fator limitante;
com o IPsec, li cerca de 500 MBit / s, mas nenhum dos meus núcleos está em 100% (eles estão abaixo de 50%).

Portanto, minha pergunta é: por que o IPsec não pode alcançar uma largura de banda maior?

Os dois hosts estão executando o Debian Wheezy e o Strongswan para IPsec.

performance bandwidth ipsec

— user50228
fonte

3

Você precisará garantir que sua CPU tenha as aesinstruções para decriptografar melhor os pacotes nos dois sites intel.co.jp/content/dam/www/public/us/en/documents/white-papers/… e verifique se você está tornando o ipsec paralelo e usando o Tunnel Mode + ESP - strongswan.org/docs/Steffen_Klassert_Parallelizing_IPsec.pdf . Essa é a melhor maneira de obter desempenho com este protocolo.

Infelizmente, tenho processadores i3 sem suporte AES-NI e trabalho no modo de encapsulamento entre os dois hosts. Entendo como os dois conselhos aumentariam a largura de banda no caso em que uma CPU estivesse com 100% de uso. O uso do AES-NI permitiria o processamento de mais pacotes e aumentaria o BW. Mas aqui a CPU não parece ser o fator limitante.

— user50228

3

Hum, isso é interessante. Eu suspeitaria que algo no kernel está atrasando as coisas. Você se importaria de compartilhar sua configuração ipsec? Gostaria de instrumentar uma VM e ver quais resultados obterei com configurações diferentes.

— Lmwangi

1

Existem muitíssimos fatores para isso. A NIC atinge mais partes do quadro do que você pode imaginar. Qualquer conjunto, se as instruções puderem atravessar o fio e atingir uma parte do sistema do driver e engarrafá-lo para baixo. Você pode pegar um único núcleo de 1200 mhz e ajustar o hardware para explodir as portas e 3600 mhz de quatro núcleos. Esta é realmente uma questão específica de hardware.

Como eles fazem isso? com algo assim http://www.ixiacom.com/products/ixn2x Esse é o dispositivo de US $ 165k "I will break you". ou seja, 2 shows de tráfego incorreto em um tubo de 1gig. Depois que você começa a espancar o sistema e a quebrar coisas, o gargalo da garrafa 'se revela'. Aprimore suas habilidades no GDB!

Todo sistema tem um método diferente para resolver o problema. Algumas placas possuem limitações de tecnologia que podem limitar você.

A resposta é ambígua porque a solução é ambígua. Eu posso pensar em 20 possibilidades diferentes, incluindo paginação, que pode variar de versão do SO para versão.

— Brad
fonte

0

Gostaria de saber se é porque esperas ou dormidas artificiais foram inseridas na criptografia. Não é muito provável que seja imo, mas ...

http://www.tau.ac.il/~tromer/acoustic/

Não foi possível postar isso como um comentário, teria sido melhor assim.

— Raymond Bannan
fonte

0

Pode ser que em um momento específico apenas um dos dois núcleos esteja saturado, mas, em média, parece que ambos estão em cerca de 50% (porque o kernel atribui aleatoriamente um processo IPsec de thread único aos dois núcleos; no entanto, tanto quanto eu notei que o Linux (diferente do Windows) geralmente tenta manter um segmento no mesmo núcleo).

Em alguns períodos curtos, o IPSec pode esperar também pela rede que, em conjunto com a baixa taxa de transferência, seria um sinal de buffer insuficiente.

Além disso, a compactação (se houver) e a sobrecarga do protocolo podem afetar seus testes.

— mik
fonte