Pourquoi net.ipv4.tcp_rfc1337 n'est-il pas activé par défaut ?

Question

Pourquoi net.ipv4.tcp_rfc1337 n'est-il pas activé par défaut ?

Demandé el 3 de Juillet, 2016: Quand la question a-t-elle été
10606 affichage: Nombre de visites la question a
2 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

Le paramètre tcp_rfc1337 semble avoir une solution pour l'assassinat TIME-WAIT.

Le premier problème est que les anciennes données dupliquées peuvent être acceptées par erreur dans les nouvelles connexions, ce qui entraîne la corruption des données envoyées.
Le deuxième problème est que les connexions peuvent se désynchroniser et entrer dans une boucle ACK à cause des anciens paquets dupliqués qui entrent dans les nouvelles connexions, lesquelles se désynchronisent à leur tour.
Le troisième et dernier problème est que les anciens paquets en double peuvent entrer par erreur dans les connexions nouvellement établies et tuer la nouvelle connexion.

D'après ce que j'ai lu, pour résoudre les problèmes, ce que l'établissement fait c'est ignorer les paquets RST (reset) lorsque la socket est dans son état TIME-WAIT .

Alors, pourquoi ce paramètre n'est-il pas activé par défaut ? Quels sont les inconvénients de son utilisation ?

En fait, j'ai appris l'existence de cette variable en faisant des recherches sur l'arrêt des attaques par inondation SYN. Pensez-vous que ce paramètre aide à les arrêter ?

Demandé el 3 de Juillet, 2016 par mononym

Answer 1

2 Réponses

Answer 2

11voto

Mark Riddell Points 1083

Je suis d'accord avec le commentaire de Greg. RFC 1337 est un RFC informatif seulement et ne fait pas partie de la norme TCP. Pour s'assurer qu'il n'y a pas de changements inattendus dans les réseaux de production, il est logique de garder cette fonctionnalité désactivée par défaut et de laisser aux administrateurs de réseau le soin de décider s'ils souhaitent l'activer pour les tests.

Abandonner les paquets RST pour les sockets en TIME-WAIT ne serait pas apparaître Il n'y a pas de conséquences négatives, mais cela ne veut pas dire qu'il n'y en a pas - peut-être un cas particulier qui n'a pas été entièrement exploré.

Il est intéressant de noter que le documentation du noyau pour tcp_rfc1337 semble être incorrecte :

tcp_rfc1337 - BOOLEAN
    If set, the TCP stack behaves conforming to RFC1337. If unset,
    we are not conforming to RFC, but prevent TCP TIME_WAIT
    assassination.
    Default: 0

Si l'option est activée, nous nous conformons à la RFC 1337 et abandonnons les paquets RST, empêchant ainsi l'assassinat de TIME-WAIT. Si l'option n'est pas définie (par défaut), nous ne nous conformons pas à la RFC 1337 et sommes susceptibles d'être victimes de TIME-WAIT Assassination.

Répondu el 11 de Juillet, 2016 par Mark Riddell (1083 Points )

Answer 3

2voto

JRun Points 271

J'ai trouvé le code source du noyau et pour moi la doc est correcte : default = 0 : kill

if (th->rst) {
    /* This is TIME_WAIT assassination, in two flavors.
     * Oh well... nobody has a sufficient solution to this
     * protocol bug yet.
     */
    if (sysctl_tcp_rfc1337 == 0) {
kill:
        inet_twsk_deschedule_put(tw);
        return TCP_TW_SUCCESS;
    }
}

La valeur par défaut est logique : le RFC est informatif, vous devez donc régler ce bouton (valeur = 1) pour vous y conformer.

Répondu el 5 de Juillet, 2017 par JRun (271 Points )

Pourquoi net.ipv4.tcp_rfc1337 n'est-il pas activé par défaut ?

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

Pourquoi net.ipv4.tcp_rfc1337 n'est-il pas activé par défaut ?

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: