Discussion:SYN cookie

Le contenu de la page n’est pas pris en charge dans d’autres langues.
Une page de Wikipédia, l'encyclopédie libre.
Autres discussions [liste]
  • Admissibilité
  • Neutralité
  • Droit d'auteur
  • Article de qualité
  • Bon article
  • Lumière sur
  • À faire
  • Archives
  • Commons

Dans la partie Principe, dans la figure expliquant le "TCP handshake", il y avait une confusion entre les flags SYN,ACK et les champs SN (sequence number) et ACK. Dimanche 6 aout 2006.

Refonte de l'article[modifier le code]

Bonjour,

Dans le cadre d'un projet universitaire (Projet:Informatique 2.0) nous avons refait cette page en l’étoffant. Le brouillon se trouve ici. Nous comptons la mettre en ligne ce dimanche 12 janvier 2020. Si vous êtes intéressé pour relire et indiquer d'éventuel erreurs. Merci d'avance.

Relecture Master TiiR[modifier le code]

Bonjour, je suis Thanusan l'un des relecteurs de votre sujet.
Tout d'abord bravo pour ce travail, ayant fait l'exercice je connais toute la difficulté de produire un article.
Je vais vous faire un retour par chapitre sur les éléments qui me semblent bon d'améliorer. Thanusan R (discuter) 23 janvier 2020 à 15:53 (CET)[répondre]

Bonjour, je suis David, le deuxième relecteur. Je tiens également à vous féliciter pour votre article, pour avoir fait le même travail, je sais à quel point c'est un exercice difficile. A l'image de Thanusan, je vais vous faire mes retours sur certains éléments de votre article, dans le but d'améliorer ce dernier. --David De Macedo (discuter) 28 janvier 2020 à 12:01 (CET)[répondre]

Remarques générales[modifier le code]

  1. Pour une description complète du sujet, il faut ajouter un chapitre qui présente ou liste les alternatives à SYN Cookie et faire une comparaison avec SYN Cookie. Exemple : Synkill (voir document "Analysis of a denial of service attack on TCP"); Syn-agent (voir document "Defending against tcp syn flooding with a new kind of syn-agen"; ou encore SYN Proxy.Thanusan R (discuter) 30 janvier 2020 à 11:52 (CET)[répondre]
C'est ajouté. Daamaad (discuter) 8 février 2020 à 19:08 (CET)[répondre]
  1. Il manque un élément important dans votre sujet, c'est l'implémentation de SYN Cookie dans les différents équipements /systèmes. J'en déduis qu'il est implémenté dans Linux d'après votre partie sur l'activation de SYN Cookie et Histoire. Implémenté sous Linux depuis quelle version ? Toujours d'actualité ou remplacé par une autre solution ? L'option est-elle disponible sur les firewalls ? Thanusan R (discuter) 30 janvier 2020 à 11:52 (CET)[répondre]
  2. Il me semble important d’intégrer le point suivant dans votre explication (à reformuler), dans la définition par exemple. « Les cookies ont été conçus pour lutter contre les attaques de SYN footing sans modifier les implémentations TCP utilisées par les hôtes clients; seuls les serveurs qui les utilisent doivent être modifiés pour les produire et les valider, et leur utilisation doit être aussi transparente que possible pour les clients. » Zúquete 2002, p. 61 Thanusan R (discuter) 30 janvier 2020 à 13:35 (CET)[répondre]
  3. Il faut enlever le gras sur "(ISN: Initiale Séquence Number)" dans votre résumé introductif. Thanusan R (discuter) 31 janvier 2020 à 10:46 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 19:10 (CET)[répondre]
  1. J'ai bien compris la logique de votre plan, mais je pense qu'il faut regrouper "Améliorations des performances" et "Extensions de SYN Cookie" dans une même section et faire deux sous-sections. Au moins mettre "Activation de SYN Cookie" avant "Améliorations des performances" pour qu'améliorations et extensions se suivent. --Thanusan R (discuter) 31 janvier 2020 à 12:16 (CET) En plus de mutualiser ces 2 sections, on pourrait aussi ajouter une 3ième sous sections qui parlerait des différentes études concernant l'amélioration de SYN Cookie en général. Vous avez déjà une référence qui parle de ce sujet : "Improving the Functionality of SYN Cookies" --David De Macedo (discuter) 31 janvier 2020 à 17:13 (CET)[répondre]
  2. Le titre de la section "Systèmes contraints" n'est pas très explicite je trouves. Un titre du genre "Syn Cookie dans l'internet des objets" serait à mon sens plus parlant. --David De Macedo (discuter) 31 janvier 2020 à 17:09 (CET)[répondre]
Merci pour cette proposition de titre de section, je suis d'accord avec vous. Daamaad (discuter) 8 février 2020 à 10:57 (CET)[répondre]

Principe[modifier le code]

Définition[modifier le code]

  1. « Il permet au serveur de sauvegarder l'état des connexions semi-ouvertes en dehors de son espace mémoire ». Il est stocké où ? Il me semble important d'expliquer que les informations de l'état de connexion sont tout simplement renvoyées au client (dans ISN). Donc stocké directement dans l'échange de messages d'initialisation de connexion. Thanusan R (discuter) 23 janvier 2020 à 16:40 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 18:08 (CET)[répondre]
  1. « qui cherche, à partir de paquet SYN falsifié avec des adresses sources aléatoires, à allouer la totalité de la mémoire du serveur afin qu'il se trouve dans l'incapacité de pouvoir répondre aux clients légitimes. » Référence mal définie ou manquante; c’est Liu2008, p. 1218 et pour le reste du texte c'est bien Liu2008, p1219 ref 5.Thanusan R (discuter) 23 janvier 2020 à 16:40 (CET)[répondre]
Merci, c'est corrigé. Daamaad (discuter) 8 février 2020 à 18:22 (CET)[répondre]
  1. « Néanmoins, la génération et la vérification du cookie consomme beaucoup de ressource CPU, ce qui rend cette méthode efficace uniquement en cas d'attaque par inondation de requêtes SYN de faible envergure.».
    * Le mot cookie ne devrait pas être tout seul, sinon il faut le définir. De plus dans l’article ref 5, il dit précisément que c’est la génération et le décodage de clé qui est à l’origine de la consommation CPU.
    * L’article que vous citez parle très peu de SYN Cookie, elle est dédiée plutôt à une alternative à SYN Cookie (Syn-agent). La source est-elle suffisante pour dire que c’est inefficace contre les inondations à forte envergure ? Surtout dans la définition ? Et quel type de solution déploie-t-on contre les attaques à forte envergure ? Thanusan R (discuter) 23 janvier 2020 à 16:40 (CET)[répondre]
  2. Il me semble important de mettre dans la définition la phrase que vous avez mise dans le paragraphe Perte des informations du paquet SYN => "SYN cookies s'active uniquement lorsque le serveur subit une attaque, c'est-à-dire lorsqu'il y a trop de connexions semi-ouvertes.(ref 7 et 13)" S'il y a déclenchement, il faut le faire apparaitre dans la définition ou dans une section dédiée. Thanusan R (discuter) 28 janvier 2020 à 14:20 (CET)[répondre]
C'est ajouté. Daamaad (discuter) 8 février 2020 à 18:34 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 17:29 (CET)[répondre]

Valeur d'un SYN Cookie[modifier le code]

  1. J’aime bien votre présentation, je comprends mieux avec votre typographie, mais sauf erreur cela ne correspond pas à la convention typographique de Wikipédia https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Conventions_typographiques#Italique
    Exemple: pourquoi mettre en italique « numéro de séquence » ? Ou encore SYN en < code> ? Valable pour tout le document. Thanusan R (discuter) 27 janvier 2020 à 15:51 (CET)[répondre]
En effet, l'utilisation de la typographie italique ne correspond pas à la convention de Wikipédia. Concernant les balises < code>< /code>, nous avons repris cette typographie de l'auteur original de la page. Effectivement, les articles traitant par exemple du SYN Flood ou encore de TCP n'utilisent pas ces balises lorsqu'ils emploient les mots SYN ou ACK. C'est corrigé. Daamaad (discuter) 8 février 2020 à 15:33 (CET)[répondre]
  1. « T » majuscules sur le schéma et « t » minuscule dans la formule math de wiki. Thanusan R (discuter) 27 janvier 2020 à 15:51 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 15:35 (CET)[répondre]
  1. (MSS = Maximum Segment Size) Il faut mettre le terme au complet la 1ère fois puis l'acronyme. Thanusan R (discuter) 27 janvier 2020 à 15:51 (CET)[répondre]
C'est corrigé également. Daamaad (discuter) 8 février 2020 à 15:36 (CET)[répondre]
  1. Pour la formule de calcul du syncookie, il faut trouvé une autre source qui affirme que c'est bien la formule originale. (Juan Jose Echevarria 2018 , p742 ou encore André Zúquete 2012, p19 nous donnent une formule différente (H2 + MSS) mod 224 à la fin) une formule dérivée pour l'implémentation sous Linux? Même remarque pour la formule de validation Thanusan R (discuter) 27 janvier 2020 à 15:51 (CET)[répondre]
Selon la RFC 4987, la méthode de calcul et de vérification des SYN cookies n'est pas précisée et peut varier selon les implémentations. Les formules que nous avons données sont celles utilisées pour calculer et vérifier les SYN cookies au sein de Linux. J'ai précisé ces détails manquants dans l'article. Merci pour cette remarque. Daamaad (discuter) 8 février 2020 à 17:16 (CET)[répondre]
  1. La description des éléments n’est pas dans le même ordre que la formule mathématique. Je pense que c’est mieux de le mettre dans l’ordre (commencé par H puis s1, s2…)

--Thanusan R (discuter) 27 janvier 2020 à 15:51 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 14:29 (CET)[répondre]

Déroulement d'une connexion TCP avec SYN Cookie[modifier le code]

  1. « (voir le schéma ci-contre)», ce texte n’est pas nécessaire sur une page Wikipédia. Thanusan R (discuter) 28 janvier 2020 à 09:15 (CET)[répondre]
Effectivement, c'est corrigé.Daamaad (discuter) 8 février 2020 à 14:14 (CET)[répondre]
  1. Vous parlez de 3 phases, donc pourquoi ne pas séparer votre explication en 3 pour une meilleure visibilité et compréhension.
    1) SYN: …
    2) SYN-ACK: …
    3) ACK:… Thanusan R (discuter) 28 janvier 2020 à 09:15 (CET)[répondre]
C'est corrigé, merci pour cette suggestion. Daamaad (discuter) 8 février 2020 à 14:19 (CET)[répondre]
  1. Deuxième paragraphe : je ne comprends pas pourquoi vous avez cité une source par phrase alors que tous disent la même chose. Il faut regrouper l’ensemble et mettre vos 3-4 sources ensemble pour renforcer votre texte/argument. Comme dans votre paragraphe « Inconvénients ». Thanusan R (discuter) 28 janvier 2020 à 09:15 (CET)[répondre]
  2. Pour la formule de calcul du MSS, voir la remarque 4 du chapitre "Valeur d'un SYN Cookie". Il faut soit trouvée une autre source, soit expliquée l'autre formule en disant que c'est la formule choisie pour l'implémentation sous Linux. --Thanusan R (discuter) 28 janvier 2020 à 09:15 (CET)[répondre]
C'est corrigé (voir la remarque 4 du chapitre "Valeur d'un SYN Cookie"). Daamaad (discuter) 8 février 2020 à 17:59 (CET)[répondre]

Inconvénients[modifier le code]

Falsification de connexion[modifier le code]

  1. «Il a été montré11 que les SYN Cookies dépendent uniquement du paquet ACK final.», je pense qu'il faut mettre la référence à la fin, juste avant le point.
    Même remarque pour le 2ème paragraphe: «Il a également été montré11...24 derniers bits est suffisant.» ; «..paquets ACK13, ce qui correspond à un débit de 85 Mb/s.»; Thanusan R (discuter) 29 janvier 2020 à 11:53 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 14:09 (CET)[répondre]
  1. «il ne peut savoir si le paquet SYN+ACK a été perdu11 et ne peut donc pas le retransmettre11» Il n'est pas nécessaire de mettre la même référence (11) deux fois dans une même phrase alors qu'il n'y a pas d'autre réf entre les deux.
    Même remarque pour le 2ème paragraphe: «Il peut ensuite inonder le serveur de paquet ACK falsifié, c'est-à-dire de paquet ACK contenant des numéros de séquence aléatoires4,11, en espérant que l'un d'entre-eux soit un SYN Cookie considéré par le serveur comme étant valide4,11.» ; «Elle cherche plutôt à consommer son CPU13 en lui faisant valider la totalité des SYN Cookies qui, pour la plupart d'entre-eux, sont invalides13»;

--Thanusan R (discuter) 29 janvier 2020 à 11:53 (CET)[répondre]

C'est corrigé également. Daamaad (discuter) 8 février 2020 à 14:12 (CET)[répondre]

Perte des informations du paquet SYN[modifier le code]

  1. Il faut mettre les termes suivantes au complet suivi de l'acronyme: "Round-Trip Time (RTT)"; "Protect Against Wrapped Sequences (PAWS)".Thanusan R (discuter) 29 janvier 2020 à 17:10 (CET)[répondre]
Vous avez raison, c'est corrigé. Daamaad (discuter) 8 février 2020 à 12:04 (CET)[répondre]
  1. « En effet, les paramètres supplémentaires inclus dans le paquet SYN original sont perdus. » Je pense qu’il faut être un peu plus précis. Dire que le serveur ne prend pas en compte les paramètres contenus dans le champ « options » lorsque le client envoie son segment SYN.Thanusan R (discuter) 29 janvier 2020 à 17:10 (CET)[répondre]
Effectivement c'est plus précis, merci. Daamaad (discuter) 8 février 2020 à 12:42 (CET)[répondre]
  1. Erreur de page dans l'article référence 3 (Zúquete 2002, p. 57) pour tout le paragraphe, c'est plutôt, référence 9 (Zúquete 2002, p. 61) Thanusan R (discuter) 29 janvier 2020 à 17:10 (CET)[répondre]
C'est corrigé, merci. Daamaad (discuter) 8 février 2020 à 13:49 (CET)[répondre]
  1. «...le MSS3,13,7 permettent des communications plus efficaces.» Référence 3,13 et 7 à mettre plutôt en fin de phrase. --Thanusan R (discuter) 29 janvier 2020 à 17:10 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 13:52 (CET)[répondre]
  1. « c'est-à-dire lorsqu'il y a trop de connexions semi-ouvertes », je vous propose plutôt cette phase : "c'est-à-dire lorsque toutes les ressources du serveur sont occupées par des connexions semi-ouvertes." Kim 2008, p. 457 --Thanusan R (discuter) 31 janvier 2020 à 11:19 (CET)[répondre]
Effectivement, votre formulation est plus claire, merci. Daamaad (discuter) 8 février 2020 à 13:57 (CET)[répondre]

Autres inconvénients[modifier le code]

  1. Le point 1 et 2 peuvent être regroupés vu que c'est les mêmes références: " Les coûts de calcul supplémentaires nécessaires au traitement des paquets SYN entrant et ACK entrant;" Thanusan R (discuter) 29 janvier 2020 à 10:05 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 11:46 (CET)[répondre]
  1. "Inadaptés pour la protection des machines virtuelles" j'aurais bien voulu savoir pourquoi.

Thanusan R (discuter) 29 janvier 2020 à 10:05 (CET)[répondre]

Corrigé également. Daamaad (discuter) 8 février 2020 à 11:59 (CET)[répondre]

Améliorations des performances[modifier le code]

1. Dans cette rubrique, vous faites référence à des auteurs qui proposent des améliorations. Je ne comprends pas vraiment l'intérêt de les citer à partir du moment où vos informations sont référencées. De plus, je pense qu'il y a une erreur lorsque vous nommez l'auteur "al." Al , n'apparaît pas comme auteur dans vos différentes sources. --David De Macedo (discuter) 29 janvier 2020 à 10:19 (CET)[répondre]

Bonjour,
Le "et al." est une locution latine Et_al. qui ne désigne pas un auteur mais l'ensemble des autres auteurs aillant participé à la publication. Nous l'avons d'ailleurs mis en italique afin de faciliter la compréhension. --Daikimi (discuter) 30 janvier 2020 à 11:10 (CET)[répondre]
OK autant pour moi, mais, la référence 10 a été écrite uniquement par un auteur, dans ce cas, "al" n'a pas à apparaitre. --David De Macedo (discuter) 30 janvier 2020 à 16:18 (CET)[répondre]
Effectivement, c'est corrigé. Daamaad (discuter) 8 février 2020 à 11:14 (CET)[répondre]

2. La même référence apparaît plusieurs fois dans le même paragraphe. Ce n'est pas vraiment utile, il est préférable dans ce cas, d'ajouter votre référence à la fin dudit paragraphe.--David De Macedo (discuter) 29 janvier 2020 à 10:56 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 11:19 (CET)[répondre]

3. Selon moi, la phrase "Puisque cette méthode sauvegarde l'état des connexions, elle peut utiliser ces informations afin de proposer une connexion optimale" n'est pas exacte ou manque de compréhension. Dans la source, il est plutôt indiqué que la méthode proposée prend en compte également les connexions "optimal" dans le sens connexions valides, alors que SYN Cookie, ne rentre en compte que lorsque "la SYN queue" est pleine. --David De Macedo (discuter) 28 janvier 2020 à 16:29 (CET)[répondre]

4. Concernant le paragraphe suivant : "En 2007, plusieurs améliorations ont été proposées. Han Jianying et al. ont proposé une amélioration consistant à stocker....."

La source utilisée qui a pour référence 6 (Hang 2009, p. 446) ne correspond pas à ce que vous indiquez dans ce paragraphe. Soit vous supprimez cette partie, soit vous trouvez les sources correspondantes. --David De Macedo (discuter) 29 janvier 2020 à 10:56 (CET)[répondre]

5. Concernant le paragraphe : "En 2009, Bo Hang et al. ont proposé une amélioration consistant à modifier....", l'explication de l'amélioration proposée est incomplète. Il conviendrait d'indiquer que la méthode est basée sur 3 composants : le contrôleur, la détection d'attaque et la réponse à l'attaque. C'est en cas de détections d'attaque que le nouvel algorithme est utilisé. Aussi, la description des champs du syn cookie proposée est erronée. Ils proposent 1 bit pour l'horodatage du cookie (ou la certification de l'épuisement du délai d'attente) et non pas pour la "certification". --David De Macedo (discuter) 29 janvier 2020 à 11:49 (CET)[répondre]

Effectivement, c'est corrigé. Daamaad (discuter) 8 février 2020 à 23:08 (CET)[répondre]

Activation de SYN Cookie[modifier le code]

Windows[modifier le code]

1. La référence 18 (Korn 2011, p. 49) concernant la méthode à activer dans windows : SynAttackProtect ne fait pas référence à la bonne page. En effet, dans la source, il s'agit de la page 42 où SynAttackProtect est évoqué. --David De Macedo (discuter) 29 janvier 2020 à 15:08 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 22:02 (CET)[répondre]

2. Même remarque pour la référence 14 (Korn 2011, p. 48), c'est toujours en page 42 qu'il est recommandé d'appliquer la valeur 2. --David De Macedo (discuter) 29 janvier 2020 à 15:08 (CET)[répondre]

C'est corrigé également. Daamaad (discuter) 8 février 2020 à 22:03 (CET)[répondre]

3. Concernant la clef de registre SynAttackProtect se trouvant dans HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters, il serait souhaitable de référencer cette information. --David De Macedo (discuter) 29 janvier 2020 à 15:08 (CET)[répondre]

4. La référence 18 (Korn 2011, p. 49) concernant les clés de registre TcpMaxHalfOpen, TcpMaxHalfOpenRetried et TcpMaxPortsExhausted ne fait pas référence à la bonne page. C'est en page 43 que ces informations sont mentionnées. --David De Macedo (discuter) 29 janvier 2020 à 15:08 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 22:05 (CET)[répondre]

5. Je me demande s'il est légitime de parler d'activation de SYN Cookie dans Windows. SYN Cookie est propre à Linux & FreeBSD. Il est indiqué que des équivalences existent dans windows mais elles sont différentes. Il serait préférable d'indiquer, selon moi, que des équivalences à SYN Cookie existent dans windows, comme SynAttackProtect, mais pas inclure cette information dans cette rubrique. --David De Macedo (discuter) 29 janvier 2020 à 15:08 (CET)[répondre]

Linux[modifier le code]

1. Sur Linux, concernant l'activation de syncookies, il y a une erreur à la fin du paragraphe : "Sinon, il faut exécuter la commande echo 1 > /proc/sys/net/ipv4/tcp_syncookies et recharger la configuration à l'aide de la commande sysctl -p". echo 1 > /proc/sys/net/ipv4/tcp_syncookies active dynamiquement la fonction tcp_syncookie, mais en cas de redémarrage du système, la valeur reviendra à sa valeur par défaut. La commande sysctl -p rechargera les valeurs présentes dans le fichier /etc/sysctl.conf, donc, si dans ce fichier, tcp_syncookies est égal à 0, le fait de recharger la configuration avec la commande sysctl -p après avoir fait un echo 1 > /proc/sys/net/ipv4/tcp_syncookies repassera la valeur tcp_syncookies à 0. Pour rendre persistante cette modification, il faut éditer le fichier /etc/sysctl.conf, passer la valeur net.ipv4.tcp_syncookies à 1 au lieu de 0, et recharger la configuration à l'aide de la commande sysctl -p ou bien redémarrer le serveur. Il existe de nombreuses sources sur Internet à ce sujet. --David De Macedo (discuter) 29 janvier 2020 à 15:33 (CET)[répondre]

Effectivement, c'est corrigé. Daamaad (discuter) 8 février 2020 à 22:23 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 22:07 (CET)[répondre]

Extension de SYN Cookie[modifier le code]

On peut voir cette rubrique comme une amélioration ou une évolution de syn cookie. Je pense donc que la fusionner avec la rubrique Améliorations des performances aurait du sens. --David De Macedo (discuter) 30 janvier 2020 à 16:22 (CET)[répondre]

Flow-Cookies[modifier le code]

1. La référence 20 (Casado 2006, p. 286) concernant la phrase : "Le serveur web peut également demander à la cookie box de filtrer l'IP d'un client ayant un comportement anormal", n'indique pas la bonne page, cette information est évoquée dans la page 287. Il conviendrait de créer une nouvelle référence. --David De Macedo (discuter) 29 janvier 2020 à 16:40 (CET)[répondre]

Effectivement, c'est corrigé. Daamaad (discuter) 8 février 2020 à 21:45 (CET)[répondre]

2. La référence 20 apparaît plusieurs fois dans le même paragraphe, il serait préférable d'indiquer qu'une seule référence à la fin de ce paragraphe. --David De Macedo (discuter) 29 janvier 2020 à 16:40 (CET)[répondre]

C'est corrigé également. Daamaad (discuter) 8 février 2020 à 21:45 (CET)[répondre]

M-SYN cookies[modifier le code]

1. Le passage suivant n'est pas très clair : "À l'instar de SYN Cookie, il s'agit d'un choix particulier de numéro de séquence initial". Je pense qu'il faudrait plutôt reformuler ainsi: Ce dernier est conçu pour partager les états de connexion entre les pare-feux via un choix particulier de numéro de séquence TCP. --David De Macedo (discuter) 29 janvier 2020 à 18:08 (CET)[répondre]

Effectivement, votre phrase est plus claire, merci. Daamaad (discuter) 8 février 2020 à 20:02 (CET)[répondre]

2. Avant de décrire le déroulement d'échange de connexion via M-SYN Cookie, je pense que pour une meilleure compréhension, il faudrait ajouter les informations suivantes (que l'on retrouve dans la même page de la source): "Le M-SYN Cookie utilise l'ID du par-feu à la place l'index MSS du cookie SYN afin d'enregistrer en toute sécurité les informations de l'expéditeur du cookie. La vérification des paquets SYN/ACK s'effectue par une fonction de hachage par clé. Pour utiliser cette fonction, tous les pare-feux doivent partager la même clé secrète. Le déroulement d'échange d'état de connexion........."--David De Macedo (discuter) 29 janvier 2020 à 18:46 (CET)[répondre]

Merci pour cette suggestion, c'est ajouté. Daamaad (discuter) 8 février 2020 à 20:05 (CET)[répondre]

3. Pour être complet sur le M-SYN Cookie, il faudrait ajouter des informations sur les rubriques suivantes : M-SYN Cookies with TCP Reincarnation / M-SYN Cookie Messages / State Synchronization --David De Macedo (discuter) 29 janvier 2020 à 18:46 (CET)[répondre]

4. "Le déroulement d'échange d'état de connexion avec M-SYN Cookie est le suivant (voir schéma ci-contre) : ", pour faire court je vous propose "Protocole d'échange d'état de connexion avec M-SYN Cookie:" et pas besoin de mettre voir schéma ci-contre. --Thanusan R (discuter) 31 janvier 2020 à 12:22 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 20:06 (CET)[répondre]

Systèmes contraints[modifier le code]

1. La référence 24 apparaît plusieurs fois dans le même paragraphe, il serait préférable de mettre uniquement une seul référence à la fin de ce paragraphe. --David De Macedo (discuter) 30 janvier 2020 à 18:16 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 19:41 (CET)[répondre]

2. On ne comprend pas vraiment ce qu'est un système de classe 2. Il aurait été intéressant de spécifier en plus, qu'il s'agit de dispositifs de l'internet des objets (IoT) à ressources limitées. --David De Macedo (discuter) 30 janvier 2020 à 18:16 (CET)[répondre]

C'est corrigé, merci. Daamaad (discuter) 8 février 2020 à 19:44 (CET)[répondre]

3. Je suis pas d'accord avec cette information  : "Ces systèmes sont particulièrement vulnérables à ce type d'attaque, car ils se connectent directement à Internet sans passer par une passerelle". Je n'ai pas pu vérifier cette information dans la source bibliographique que vous indiquez. Les dispositifs de classe 2 se connectent en effet directement à internet car ils peuvent partiellement prendre en charge la pile de protocoles tcp/ip. Leur vulnérabilité provient de leur mémoire disponible limitée comme indiqué dans la source bibliographique en page 740 et 748. --David De Macedo (discuter) 30 janvier 2020 à 18:16 (CET)[répondre]

Vous avez raison, c'est une erreur. Daamaad (discuter) 8 février 2020 à 19:57 (CET)[répondre]

4. L'étude à comparer 2 méthodes de protections : SYN Cookie et le recyclage des anciennes connexions semi-ouvertes. Il faut donc indiquer que, entre ces 2 méthodes, c'est le SYN cookie qui est le plus efficace. --David De Macedo (discuter) 30 janvier 2020 à 18:22 (CET)[répondre]

Effectivement, c'est corrigé. Daamaad (discuter) 8 février 2020 à 19:48 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 19:45 (CET)[répondre]

Histoire[modifier le code]

1. Concernant "Phil Karn (en) est le premier à avoir conçu un protocole Internet qui utilise les cookies afin de se protéger contre les attaques par déni de service", afin de compléter l'information, il serait intéressant d'ajouter une référence bibliographique vers la RFC2522 correspondant à l'étude de Phil Karl : Photuris: Session-Key Management Protocol --David De Macedo (discuter) 30 janvier 2020 à 21:33 (CET)[répondre]

C'est ajouté, merci pour cette suggestion. Daamaad (discuter) 8 février 2020 à 19:29 (CET)[répondre]

2. Concernant : "Le 16 septembre 1996, D. J. Bernstein eu l'idée d'utiliser des cookies", il faudrait plutôt indiquer SYN cookies plutôt qu'uniquement cookies.--David De Macedo (discuter) 30 janvier 2020 à 21:58 (CET)[répondre]

C'est corrigé. Daamaad (discuter) 8 février 2020 à 19:30 (CET)[répondre]

3. "Avec l'aide d'Eric Schenk, D. J. Bernstein a travaillé " Il faudrait plutôt indiquer qu'Eric Schenk et D. J. Bernstein ont travaillé...--David De Macedo (discuter) 30 janvier 2020 à 21:58 (CET)[répondre]

Effectivement, c'est plus clair. Daamaad (discuter) 8 février 2020 à 19:32 (CET)[répondre]

4. "Ils ont notamment modifier la première proposition émise par D. J. Bernstein car elle n'était pas conforme à l'exigence de TCP qui est d'utiliser des numéros de séquence initiale croissants" : La source indique que c'est Eric Schenk qui a eu l'idée d'ajouter quelque chose au numéro de séquence initial du client afin d'être conforme aux exigences tcp. Il faudrait donc reformuler dans ce sens. --David De Macedo (discuter) 30 janvier 2020 à 21:58 (CET)[répondre]

C'est reformulé. Daamaad (discuter) 8 février 2020 à 19:35 (CET)[répondre]

5. La référence 1 est stipuler plusieurs fois dans le même paragraphe, il serait préférable d'ajouter une seule référence à la fin de ce paragraphe. --David De Macedo (discuter) 30 janvier 2020 à 21:58 (CET)[répondre]

C'est corrigé également. Daamaad (discuter) 8 février 2020 à 19:37 (CET)[répondre]
C'est corrigé. Daamaad (discuter) 8 février 2020 à 19:37 (CET)[répondre]