Est-ce que TCP / IP empêche les replays de paquets?

Question

TCP / IP empêche-t-il plusieurs copies du même paquet d'atteindre la destination? Ou est-ce au niveau du noeud final de superposer la logique idempotency au-dessus?

Si possible, faites référence à des paragraphes spécifiques de la spécification TCP / IP.

Answer 1

Il s’agit du travail de la pile TCP à récupérer à partir de paquets dupliqués:

  

Le TCP doit récupérer des données qui sont   endommagé, perdu, dupliqué ou       livré hors service par le système de communication Internet. Ce       est obtenu en attribuant un numéro de séquence à chaque octet       transmis, et nécessitant un accusé de réception positif (ACK) de la       recevoir TCP. Si le ACK n'est pas reçu dans un délai       intervalle, les données sont retransmises. Au récepteur, le   séquence       les nombres servent à ordonner correctement les segments pouvant être reçus       hors service et pour éliminer les doublons. Les dommages sont gérés par       en ajoutant une somme de contrôle à chaque segment transmis, en la vérifiant à la       récepteur et en éliminant les segments endommagés.

- RFC 793 - Protocole de contrôle de transmission, Section 1.5

Cependant, si ce sont les mêmes paquets avec de nouveaux numéros de séquence, alors non.

Answer 2

TCP utilise des numéros de séquence pour détecter les doublons en cas de retransmission, ce qui empêchera également les attaques de relecture triviales.

Tiré de la RFC 793, Section 3.3 - Numéros de séquence:

  

Une notion fondamentale dans le design   est-ce que chaque octet de données envoyé   sur une connexion TCP a une séquence   nombre. Comme chaque octet est   séquencés, chacun d’eux peut être   reconnu. La reconnaissance   mécanisme utilisé est donc cumulatif   qu'un acquittement de séquence   le nombre X indique que tous les octets jusqu'à   à mais non compris X ont été   reçu. Ce mécanisme permet de   détection directe des doublons   en présence de retransmission.   Numérotation des octets dans un segment   est-ce le premier octet de données   immédiatement après l'en-tête est   le plus petit numéroté, et le suivant   les octets sont numérotés consécutivement.

La détection des doublons garantira que le même paquet ne peut pas être retransmis de manière triviale. Les numéros de séquence garantiront également que l’insertion (plutôt que le remplacement) de données dans le flux de données sera remarquée, étant donné que les paquets légitimes qui suivent les paquets falsifiés auront des numéros de séquence en double, ce qui perturbera le flux de données. Cela entraînera probablement la suppression de ces paquets sous forme de doublons, ce qui rompra probablement le protocole utilisé.

Pour plus d'informations sur la spécification TCP / IP d'origine (1981), consultez la RFC 793 et les nombreux autres RFC impliquant des extensions ou des modifications du protocole TCP / IP.

Answer 3

Oui, la couche TCP empêche les paquets en double. La couche IP située en dessous ne le fait pas.

Détails dans la RFC 1122 .

Answer 4

Vous semblez être préoccupé par deux choses différentes:

1. Quelles sont les garanties fournies par la livraison fiable TCP
2. Un attaquant peut-il affecter le traitement de mon serveur avec une attaque par rejeu

Réponse à 1:

TCP garantit la livraison fiable et dans l’ordre d’une séquence d’octets. Quelles que soient les données que l’application cliente envoie à TCP via write () , le résultat sera identique lors de l’appel read () du serveur.

Réponse à 2:

Les attaques par relecture ne fonctionnent pas bien avec TCP, car chaque connexion dépend de deux nombres aléatoires de 32 bits générés respectivement par le client et le serveur. Pour qu’une attaque par rejeu fonctionne, l’attaquant doit deviner le numéro de séquence généré par le serveur pour la fausse connexion qu’il initie (théoriquement, l’attaquant a une chance sur deux de deviner correctement). Si l'attaquant calcule une erreur, il va dans le pire des cas créer une mise en mémoire tampon des données dans votre système d'exploitation.

Notez que, même si une attaque par rejeu ne fonctionne pas, rien n'empêche un attaquant de créer une connexion légitime avec votre serveur et de transmettre le flux de données qu'il souhaite à votre application. C’est pourquoi il est important de toujours valider l’entrée .

Answer 5

Les couches inférieures à TCP peuvent rencontrer plusieurs paquets ou des paquets abandonnés. Les couches supérieures à TCP ne subissent pas de répétition ni de paquets perdus.

Answer 6

Je ne connais pas le repitition de paquets, mais je ne l'ai jamais rencontré avec TCP / IP et je sais que cela garantit que tous les paquets arrivent dans le bon ordre. Je ne comprends donc pas pourquoi 't.

Answer 7

Cela dépend vraiment de la façon dont vous recevez vos données. Même si techniquement, le protocole ne devrait pas vous donner des doublons (c'est-à-dire des paquets avec la même somme de contrôle tcp), d'autres facteurs peuvent vous amener à voir les doublons - par exemple, le matériel réseau que vous utilisez. en utilisant; De même, si vous utilisez des renifleurs pour consulter les flux TCP, plutôt que de simplement lire un socket ouvert dans votre application, il est possible d'obtenir des paquets dupliqués des renifleurs même si les flux TCP qu'ils surveillaient ne contenaient pas de duplications.

Pour donner un exemple concret - pour le moment, je travaille sur une analyse tcp des réseaux internes d’une grande bourse. Les données que je regarde proviennent de plusieurs renifleurs et sont ensuite fusionnées. Ainsi, en extrayant les données, j'ai constaté que je devais effectuer un certain nombre d'étapes de prétraitement, notamment la recherche et la suppression des doublons. Par exemple, dans un flux que je viens de lire, d'environ 60 000 paquets de données, j'ai localisé et supprimé 95 paquets en double.

La stratégie que je prends ici est de garder une fenêtre continue des 10 dernières sommes de contrôle TCP et d’ignorer les paquets qui correspondent à ces sommes de contrôle. Notez que cela fonctionne bien pour les paquets PSH, mais pas si bien pour les paquets ACK - mais cela m'inquiète moins de toute façon.

J'ai écrit une collection spéciale dans le but de suivre cette fenêtre glissante de sommes de contrôle TCP, ce qui pourrait être utile aux autres:

/// <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

Vous ne comprenez pas bien le problème. Voir ce lien: http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Sur cette page, écrivez:

"Les horodatages TCP, définis dans la RFC 1323, aident le protocole TCP à calculer le temps d'aller-retour entre l'expéditeur et le destinataire. Les options d'horodatage incluent une valeur d'horodatage de 4 octets, dans laquelle l'expéditeur insère la valeur actuelle de son horodatage, et une valeur d'horodatage de réponse d'écho de 4 octets, dans laquelle le destinataire insère généralement la dernière valeur d'horodatage reçue. L'expéditeur utilise l'horodatage de réponse d'écho dans un accusé de réception pour calculer le temps total écoulé depuis l'envoi du segment avec accusé de réception. [2]

Les horodatages TCP sont également utilisés pour aider les cas où les numéros de séquence TCP rencontrent leur limite 2 ^ 32 et sont "enveloppés". l'espace du numéro de séquence. Ce schéma est connu sous le nom de numéros de séquence de protection contre les paquets enveloppés (PAWS) (voir RFC 1323 pour plus de détails).

Cordialement, Joint (Pologne)