TCP / IP impede replays de pacotes?

Question

TCP / IP impede que várias cópias do mesmo pacote de chegar ao destino? Ou é até o ponto final para a lógica camada idempotency acima dela?

Por favor parágrafos específicos de referência da especificação TCP / IP, se possível.

Answer 1

É o trabalho do pilha TCP para se recuperar de pacotes duplicados:

O TCP deve recuperar-se de dados que é danificado, perdido, duplicado ou entregues fora de ordem pelo sistema de comunicação internet. este é conseguido através da atribuição de um número de sequência para cada octeto transmitida, e que exige um reconhecimento positivo (ACK) do receber TCP. Se o ACK não é recebido dentro de um tempo limite intervalo, os dados são retransmitidos. No receptor, o seqüência números são usados ??para os segmentos correctamente pedidos que podem ser recebidos fora de ordem e eliminar duplicatas. Dano é tratado por adicionando uma soma de verificação para cada segmento transmitido, verificando-o no receptor, e descartando segmentos danificados.

- RFC 793 - Transmission Control Protocol, Seção 1.5

No entanto, se eles são os mesmos pacotes com novos números de seqüência, então não.

Answer 2

TCP usa números de seqüência para detectar a duplicação no caso de retransmissão, que também irá impedir ataques de repetição triviais.

De RFC 793, Seção 3.3 - Sequência Números:

A noção fundamental na concepção é que cada octeto de dados enviados através de uma ligação TCP tem uma sequência número. Uma vez que cada octeto é seqüenciado, cada um deles pode ser reconhecido. o reconhecimento mecanismo empregue é de modo cumulativo que um reconhecimento da sequência X número indica que todos os octetos-se mas não incluindo X ter sido recebido. Este mecanismo permite detecção duplicado direta na presença de retransmissão. Numeração de octetos dentro de um segmento é que os primeiros dados de octeto imediatamente a seguir ao cabeçalho é o número mais baixo, e a seguir octetos são numeradas consecutivamente.

A detecção de duplicados irá garantir que o mesmo pacote não pode ser trivialmente retransmitido. Os números de sequência irá também assegurar que a inserção (em vez de substituição) de dados no fluxo de dados irá ser notado, como os pacotes mais legítimos seguinte pacotes forjados terá números de sequência de duplicados, o que vai perturbar o fluxo de dados. Isso provavelmente vai fazer com que esses pacotes para ser descartado como duplicados, o que provavelmente vai quebrar o protocolo a ser utilizado.

Mais informações sobre o original (1981) especificação de TCP / IP pode ser encontrado em RFC 793 , e as muitas outras RFCs envolvendo expansões ou modificações ao protocolo TCP / IP.

Answer 3

Sim, os impede de camada TCP duplicar pacotes. A camada IP abaixo dela não.

Detalhes no RFC 1122 .

Answer 4

Você parece estar preocupado com duas coisas diferentes:

1. O que garante que a entrega confiável TCP fornecer
2. Pode um atacante afetar meu processo de servidor com um ataque de repetição

Resposta a 1:

TCP garante na ordem de entrega fiável, de uma sequência de bytes. O que sempre os dados do envio aplicativo cliente para TCP via write() sairá exatamente o mesmo durante a chamada read() do servidor.

Resposta a 2:

ataques de repetição não funcionam bem com o TCP, uma vez que cada ligação depende de dois 32 números de bits aleatórios gerados pelo cliente e servidor, respectivamente. Para um ataque de repetição de trabalho, o atacante deve adivinhar o número de sequência gerado pelo servidor para a conexão fingir está iniciando (teoricamente, o atacante tem uma chance de 1/2 ** 32 de adivinhar corretamente). Se as suposições atacante incorretamente, ela vai na pior das hipóteses causar algum buffer de dados em seu sistema operacional.

Note que só porque um ataque de repetição não funcionar, nada impede um atacante de formar uma conexão legítima com o servidor e transmitir o que quer transmitir dados ela quer a sua aplicação. É por isso que é importante de entrada sempre validar .

Answer 5

Camadas abaixo TCP pode experimentar vários pacotes ou pacotes descartados. Camadas acima TCP não fazer a experiência de repetição ou pacotes descartados.

Answer 6

Eu não sei sobre pacote de repetição, mas eu nunca encontrei-o usando TCP / IP e sei que ele faz garantia de que os pacotes de todos chegam e na ordem correta, então não posso entender por que ele não iria 't.

Answer 7

Ela realmente depende de como você está recebendo seus dados - embora tecnicamente o protocolo não deve dar-lhe duplica (ou seja, os pacotes com a mesma soma de verificação TCP), outros fatores podem fazer com que você veja duplicatas - por exemplo, o hardware de rede você está usando; Também se você estiver usando sniffers de olhar para fluxos TCP, em vez de apenas ler um soquete aberto no aplicativo, é possível obter pacotes dup dos sniffers mesmo se o TCP real córregos eles estavam monitorando não têm pacotes duplicados.

Para dar um exemplo do mundo real - No momento eu estou trabalhando em algumas análises tcp de redes internas para uma grande bolsa de valores, e os dados que eu estou olhando é vindo de vários sniffers e ser emendados de volta juntos. Então, em puxar nos dados, eu descobri que eu preciso fazer uma série de etapas de pré-processamento, incluindo encontrar e remover duplicatas. Por exemplo, em um fluxo Acabei de ler no, de aproximadamente 60.000 pacotes de dados, tenho localizado e removido 95 pacotes duplicados.

A estratégia tomo aqui é manter uma janela de rolamento das 10 somas de verificação TCP mais recentes, e ignorar pacotes que combinam com aquelas somas de verificação. Observe isso funciona bem para pacotes PSH, mas não tão bem para pacotes ACK -. Mas estou menos preocupado com aqueles de qualquer maneira

Eu escrevi uma coleção especial para a finalidade de acompanhar esta janela de rolamento de somas de verificação TCP, que poderia ser útil para outras pessoas:

/// <summary>
/// Combination of a double-linked-list and a hashset with a max bound; 
/// Works like a bounded queue where new incoming items force old items to be dequeued; 
/// Re-uses item containers to avoid GC'ing;
/// Public Add() and Contains() methods are fully thread safe through a ReaderWriterLockSlim;
/// </summary>
public class BoundedHashQueue<T>
{
    private readonly int _maxSize = 100;
    private readonly HashSet<T> _hashSet = new HashSet<T>();
    private readonly ReaderWriterLockSlim _lock = new ReaderWriterLockSlim();
    private readonly Item _head;
    private readonly Item _tail;
    private int _currentCount = 0;

    public BoundedHashQueue(int maxSize)
    {
        _maxSize = maxSize;
        _head = _tail = new Item();
    }

    private class Item
    {
        internal T Value;
        internal Item Next;
        internal Item Previous;
    }

    public void Add(T value)
    {
        _lock.Write(() =>
            {
                if (_currentCount == 0)
                {
                    Item item = new Item();
                    item.Value = value;
                    _head.Next = item;
                    item.Previous = _head;
                    item.Next = _tail;
                    _tail.Previous = item;
                    _currentCount++;
                }
                else
                {
                    Item item;
                    if (_currentCount >= _maxSize)
                    {
                        item = _tail.Previous;
                        _tail.Previous = item.Previous;
                        _tail.Previous.Next = _tail;
                        _hashSet.Remove(item.Value);
                    }
                    else
                    {
                        item = new Item();
                        _currentCount++;
                    }
                    item.Value = value;
                    item.Next = _head.Next;
                    item.Next.Previous = item;
                    item.Previous = _head;
                    _head.Next = item;
                    _hashSet.Add(value);
                }
            });
    }

    public bool Contains(T value)
    {
        return _lock.Read(() => _hashSet.Contains(value));
    }
}}

Answer 8

Você não entende totalmente o problema. Veja este link: http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Nesta página é escrita:

"TCP timestamps, definido na RFC 1323, compute ajuda TCP o tempo de ida e volta entre o emissor eo receptor. Opções Timestamp incluem um valor de 4 bytes timestamp, onde o remetente insere seu valor atual de seu timestamp relógio, e uma 4 bytes de resposta de eco valor timestamp, em que o receptor geralmente insere o valor timestamp recente mais que ele recebeu. o remetente utiliza o timestamp eco resposta em um reconhecimento para calcular o total de tempo decorrido desde o segmento reconhecido foi enviada. [2]

timestamps TCP também são usados ??para ajudar no caso em que os números de seqüência TCP encontrar sua 2 ^ 32 amarrado e "envolvente", o número sequencial espaço. Este esquema é conhecido como proteger contra Números de seqüência Embrulhado, ou patas (ver RFC 1323 para detalhes). "

Saudações, Conjunta (Polónia)