Opção de cabeçalho TCP: negociação SACK-allowed (Confirmações Seletivas)

Question

Estou fazendo um projeto de pesquisa, que precisa dividir a conexão tcp. então eu tenho algumas perguntas peculares, o que pode acontecer no meu desenvolvimento. O problema é o entendimento da negociação permitida pelo TCP SACK. Eu li o RFC e não consigo encontrar resposta lá.

Para handshake tcp de 3 vias entre dois programas tcp: A e B. Se A enviar um TCP SYN para B com SACK permitido, B certamente responderá um pacote SYN / ACK com SACK permitido? se B responder com um TCP SYN / ACK sem SACK permitido, isso significa

1) O SACK-permmited é habilitado somente em A. A pode reconhecer seletivamente os pacotes tcp de A, mas A não pode reconhecer seletivamente os pacotes tcp de B.

ou

2) O SACK-permmited não está habilitado em A e B

Se A envia um TCP SYN para B sem SACK permitido, pode B responder um pacote SYN / ACK com SACK permitido?

Além disso, por que SACK-permitido é permitido ou não permitido? isso depende do sistema operacional ou configuração do kernel ou algo mais? é possível controlá-lo? obrigado!

    

Answer 1

O SACK foi adicionado posteriormente, portanto, há uma necessidade de compatibilidade com versões anteriores, tanto para hosts finais quanto para middleboxes (veja também abaixo). A opção SACK-permitted preenche exatamente isso.

SACK-permitted é enviado de A para B para indicar que A está disposto a receber opções de SACK. Para o manuseio de SACK (como para a maioria dos manuseios de retransmissão), o TCP pode ser considerado como consistindo de duas conexões simplex com estados diferentes cada. Portanto, é perfeitamente legal (mas incomum) ter o SACK viajando somente em uma direção (a direção reversa do SACK-permitted durante SYN ou SYNACK).

Normalmente, você pode querer deixar o SACK ativado, pois melhora o desempenho. No entanto, existem (e talvez ainda existam) firewalls e caixas NAT que alteram os campos de cabeçalho SEQ e ACK, mas não têm conhecimento do SACK e, portanto, não adaptam os números de seqüência nas opções do SACK. Isso pode levar a conexões pendentes (como SACK reconheceu um segmento diferente que não foi recebido). Esta é a razão pela qual você pode querer desabilitar o SACK, mesmo que as duas máquinas o suportem.

O SACK pode ser desativado (para testes ou com as middleboxes presentes acima mencionadas) em sistemas * BSD (incluindo MacOS X) inserindo sysctl -w net.inet.tcp.sack=0 e reenabled configurando-o de volta para 1. No Linux, sysctl -w net.ipv4.tcp_sack=0 atinge o mesmo efeito.

O primeiro parágrafo da seção 4 da RFC 2018 permite que o SACK seja enviado quando o SACK permitido tiver recebido. Normalmente, um host com capacidade para SACK anunciará SACK permitido. Não consigo imaginar um cenário útil em que um host com capacidade para SACK não anunciará SACK permitido, mas usará o SACK (um exemplo irreal seria uma middlebox mal mexendo com SACKs em apenas uma direção). Portanto, não espero que o SACK seja usado apenas em uma direção.

Um teste rápido com o Wireshark contra o Linux, MacOSX (provavelmente generalizável para * BSD) e uma impressora HP mostra que eles responderão com o SACK permitido no SYNACK exatamente quando o SACK-permitido estiver no SYN. No entanto, não vejo nada no RFC que exija ou incentive esse comportamento.

    

Answer 2

Esta é uma pergunta que, a menos que Van Jacobsen ou seus colegas estivessem neste fórum, provavelmente implicará um grande esforço por parte de quem tentar responder como você pediu. Se você pensar sobre isso, o nível de pesquisa necessário para responder à sua pergunta seria tão grande ou maior do que o projeto de pesquisa no qual você está atualmente engajado. Isso provavelmente afetará a maioria das pessoas por falta de paridade.

No entanto, muitos de nós também tivemos a oportunidade de fazer perguntas difíceis em que as respostas não eram óbvias nem prontamente disponíveis. Enquanto no meu caso, eu finalmente teria que encontrar a resposta para tais questões, eu tive a sorte de ter pessoas úteis para me apontar na direção certa ...

Atualmente não tenho acesso root em dois sistemas BSD-unix, mas se eu fizesse ... Eu sei que ACks seletivos podem ser controlados com sysctl . No meu Mac, a entrada que habilita os SACKs é net.inet.tcp.sack . Quando ativado, tem um valor de 1; para desativar, sysctl -w net.inet.tcp.sack=0 . Defini vários cenários e usei tcpdump para testar seus problemas.

Outros podem ter dicas diferentes para você ...