Réinitialisations inappropriées de TCP considérées comme dommageables

Statut de ce mémoire

Le présent document spécifie les bonnes pratiques actuelles de l'Internet pour la communauté de l'Internet, et appelle à des discussions et suggestions pour son amélioration. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2002). Tous droits réservés.

Résumé

Le présent document a été rédigé parce que dans l'Internet un certain nombre de pare-feu réinitialisent de façon inappropriée une connexion TCP à réception de certains paquets TCP SYN, en particulier, les paquets qui ont des fanions établis dans le champ Réservé de l'en-tête TCP. Dans le présent document, nous démontrons que cette pratique n'est pas conforme aux normes de TCP, et qu'elle constitue une surcharge inappropriée de la sémantique de la réinitialisation TCP. Nous considérons aussi les conséquences à plus long terme de ce comportement et d'actions similaires comme des obstacles à l'évolution de l'infrastructure de l'Internet.

1. Introduction

TCP utilise le bit RST (Réinitialiser) dans l'en-tête TCP pour réinitialiser une connexion TCP. Les réinitialisations sont envoyées de façon appropriée en réponse à une demande de connexion sur une connexion non existante, par exemple. Le receveur TCP de la réinitialisation interrompt la connexion TCP, et le notifie à l'application [RFC793, RFC1122, Ste94].

Malheureusement, un certain nombre de pare-feu et d'équilibreurs de charge de l'Internet actuel envoient une réinitialisation en réponse à un paquet TCP SYN qui utilise des fanions provenant du champ Réservé dans l'en-tête TCP. La Section 3 ci-dessous expose l'exemple spécifique des pare-feu qui envoient des réinitialisations en réponse à des paquets TCP SYN à partir d'hôtes à capacité ECN.

Le présent document a été rédigé pour informer les administrateurs de serveurs et pare-feu de la Toile de ce problème, pour inviter au développement de correction des bogues [FIXES]. Un second objet de ce document est de considérer les conséquences à plus long terme de ce comportement des boîtiers de médiation sur l'évolution plus générales des protocoles dans l'Internet.

2. Histoire des réinitialisations TCP

La présente section donne un bref historique de l'utilisation de la réinitialisation TCP dans les normes sur TCP, et conteste l'envoi d'une réinitialisation en réponse à un paquet SYN qui utilise les bits provenant du champ Réservé de l'en-tête TCP comme un comportement non conforme.

La RFC 793 contenait la spécification originale de TCP en septembre 1981 [RFC793]. Ce document définissait le bit RST dans l'en-tête TCP, et expliquait que la réinitialisation était destinée à empêcher les anciennes initialisation de connexions dupliquées de causer la confusion dans la prise de contact en trois temps de TCP. La réinitialisation est aussi utilisée lorsque un hôte reçoit des données pour une connexion TCP qui n'existe plus.

Dans sa section 5, la RFC 793 déclare ce qui suit :

"En règle générale, réinitialisation (RST) doit être envoyé chaque fois qu'un segment arrive qui n'est apparemment pas destiné à la connexion en cours. Une réinitialisation ne doit pas être envoyée si il n'est pas évident que c'est le cas."

La RFC 1122 "amende, corrige, et complète" la RFC 793. La RFC 1122 ne dit rien de spécifique sur l'envoi de réinitialisations, ou le non envoi de réinitialisations, en réponse aux fanions dans le champ Réservé de TCP.

Et donc, il n'y a rien dans la RFC 793 ou dans la RFC 1122 qui suggère qu'il serait acceptable d'envoyer une réinitialisation simplement parce qu'un paquet SYN utilise des fanions Réservé dans l'en-tête TCP, et la RFC 793 interdit explicitement d'envoyer une réinitialisation pour cette raison.

Les RFC 793 et RFC 1122 incluent toutes deux le fameux principe de robustesse de Jon Postel, tiré de la RFC 791: "Soyez libéraux dans ce que vous acceptez, et conservateur dans ce que vous envoyez." La RFC 1122 réitère que ce principe de robustesse "est particulièrement important dans la couche Internet, où le mauvais comportement d'un hôte peut dénier le service de l'Internet à de nombreux hôtes autres." La discussion du principe de robustesse dans la RFC 1122 déclare aussi que "l'adaptabilité aux changements doit être conçue à tous les niveaux du logiciel d'hôte Internet". Le principe "Soyez libéraux dans ce que vous acceptez" ne se transpose pas clairement (sinon du tout) dans le monde des pare-feu, mais la question de "l'adaptabilité au changement" est néanmoins cruciale. Le défi est de protéger les intérêts de sécurité légitimes sans bloquer complémenté la capacité de l'Internet à évoluer pour prendre en charge de nouvelles applications, protocoles, et fonctionnalités.

2.1 Le champ Réservé de TCP

La RFC 793 dit que le champ Réservé dans l'en-tête TCP est réservé pour une utilisation future, et doit être à zéro. Une reformulation plus cohérente avec le reste du document aurait été de dire que le champ Réservé devrait être à zéro à l'envoi et ignoré à la réception, sauf spécification contraire par des actions de normalisation à venir. Cependant, la formulation de la RFC 793 ne permet pas d'envoyer de réinitialisations en réponse à des paquets TCP avec un champ Réservé non à zéro, comme expliqué dans la section ci-dessus.

2.2 Comportement et exigences pour les pare-feu Internet

La RFC 2979 sur le comportement et les exigences pour les pare-feu Internet [RFC2979], une RFC d'information, contient ce qui suit :

"Les applications doivent continuer à fonctionner correctement en présence de pare-feu. Ceci se traduit dans les règles de transparence suivantes : l'introduction d'un pare-feu et de toute facilité de tunnelage ou de négociation d'accès associée NE DOIT PAS causer de défaillance involontaire d'utilisation légitime et conforme aux normes qui fonctionnerait si le pare-feu n'était pas présent."

"Un corollaire nécessaire de cette exigence est que lorsque de telles défaillances se produisent, il appartient au pare-feu et au logiciel associé de régler le problème : les changements à l'une ou l'autre mise en œuvre de protocoles standard existants ou aux protocoles eux-mêmes NE DOIVENT PAS être nécessaires."

"Noter que cette exigence ne s'applique pas seulement à l'utilisation légitime du protocole et aux défaillances gratuites -- un pare-feu est habilité à bloquer toute sorte d'accès qu'un site estime illégitime, sans considération du fait que la tentative d'accès soit ou non conforme aux normes."

Il faut noter que la RFC 2979 est une RFC d'information. La RFC 2026 sur le processus de normalisation de l'Internet dit ce qui suit à son paragraphe 4.2.2: "Une spécification 'pour information' est publiée pour l'information générale de la communauté de l'Internet, et ne représente pas un consensus ou une recommandation de la communauté de l'Internet" [RFC2026].

2.3 Envoi de réinitialisations comme mécanisme de contrôle de l'encombrement

Certains pare-feu et hôtes envoient des réinitialisations en réponse aux paquets SYN comme mécanisme de contrôle de l'encombrement, par exemple, lorsque leurs files d'attente d'écoute sont pleines. Ces réinitialisations sont envoyées sans considération du contenu du champ Réservé de TCP. Éventuellement en réponse à l'utilisation des réinitialisations comme mécanisme de contrôle de l'encombrement, plusieurs mises en œuvre courantes de TCP renvoient immédiatement un paquet SYN en réponse à une réinitialisation, jusqu'à quatre fois.

Nous recommandons que la réinitialisation TCP ne soit pas utilisée comme mécanisme de contrôle de l'encombrement, parce que cela surcharge la sémantique du message de réinitialisation, et conduit inévitablement à des comportements plus agressifs de la part des mises en œuvre de TCP en réponse à une réinitialisation. Nous suggérons d'abandonner simplement le paquet SYN comme la réponse la plus efficace à l'encombrement. L'envoyeur de TCP va retransmettre le paquet SYN, en utilisant la valeur par défaut pour la temporisation de retransmission (RTO, Retransmission Timeout), sauvegardant le temporisateur de retransmission après chaque retransmission.

2.4 Réinitialisations en réponse aux changements dans le champ Préséance

La RFC 793 comporte ce qui suit dans sa Section 5 :

"Si un segment entrant a un niveau de sécurité, ou de compartiment, ou de préséance qui ne correspond pas exactement au niveau, compartiment et préséance exigés pour la connexion, une réinitialisation est envoyée et la connexion passe à l'état FERMÉ."

Le "préséance" se réfère au (vieux) champ Préséance dans le (vieux) champ ToS de l'en-tête IP. Le "sécurité" et "compartiment" se réfèrent à l'option obsolète Sécurité IP. Lors de sa rédaction, cela était cohérent avec les lignes directrices d'une autre partie de la RFC 793 disant que les réinitialisations ne devraient être envoyées que lorsque arrive un segment qui n'est apparemment pas destiné à la connexion actuelle.

La RFC 2873 sur le"Traitement par TCP du champ Préséance dans IPv4" discute des problèmes spécifiques soulevés par l'envoi de réinitialisations lorsque le champ préséance a changé [RFC2873]. La RFC 2873, qui a actuellement le statut de proposition de norme, spécifie que TCP doit ignorer la préséance de tous les segments reçus, et ne doit pas envoyer de réinitialisation en réponse aux changements du champ préséance. Ceci est discuté ici pour expliquer que cette question n'a jamais permis l'envoi d'une réinitialisation en réponse à un segment avec un champ TCP Réservé non à zéro.

2.5 Réinitialisations en réponse à des longueurs d'option illégales

La RFC 1122 dit ce qui suit à son paragraphe 4.2.2.5 sur les options de TCP [RFC1122] :

"Une mise en œuvre de TCP DOIT être capable de recevoir une option TCP dans tout segment. Une mise en œuvre de TCP DOIT ignorer sans erreur toute option TCP qu'elle n'accepte pas, en supposant que l'option a un champ longueur (toutes les options TCP qui seront définies à l'avenir auront des champs longueur). Une mise en œuvre de TCP DOIT être prête à traiter une longueur d'option illégale (par exemple de zéro) sans que cela provoque une défaillance ; une procédure suggérée est de réinitialiser la connexion et d'enregistrer la raison dans le journal d'incidents."

Cela est cohérent, car un receveur dans TCP n'est pas capable d'interpréter le reste des données sur un segment qui a une option TCP avec une longueur d'option illégale. Ici encore, nous allons discuter cela pour préciser que cette possibilité n'a jamais permis l'envoi d'une réinitialisation en réponse avec un segment dont le champ TCP Réservé est non à zéro.

3. L'exemple spécifique de ECN

Cette section explique brièvement ECN (notification explicite d'encombrement) en général, et le paquet SYN d'établissement ECN en particulier.

L'Internet se fonde sur le contrôle d'encombrement de bout en bout, et historiquement l'Internet a utilisé l'abandon de paquet comme seule méthode pour que les routeurs indiquent l'encombrement aux nœuds d'extrémité. ECN est un ajout récent à l'architecture IP pour permettre aux routeurs de régler un bit dans l'en-tête de paquet IP pour informer les nœuds d'extrémité de l'encombrement, au lieu d'abandonner le paquet. ECN exige la coopération des nœuds d'extrémité de transport.

La spécification ECN, la RFC 2481, a été une RFC expérimentale de janvier 1999 jusqu'à juin 2001, lorsque un document révisé, la [RFC3168] a été approuvée comme proposition de norme. Des informations complémentaires sur ECN sont disponibles sur la page ECN de la Toile [ECN].

L'utilisation de ECN avec TCP exige que les deux nœuds d'extrémité TCP aient été mis à niveau pour prendre en charge l'utilisation de ECN, et que les deux nœuds d'extrémité se mettent d'accord pour utiliser ECN sur cette connexion TCP particulière. Cette négociation de la prise en charge de ECN entre les deux nœuds d'extrémité TCP utilise deux fanions qui ont été alloués à partir du champ Réservé dans l'en-tête TCP [RFC2481].

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Longueur d'en-tête				Réservé						URG	ACK	PSH	RST	SYN	FIN

Figure 1 : Définition antérieure des octets 13 et 14 de l'en-tête TCP.

0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15
Longueur d'en-tête				Réservé				CWR	ECE	URG	ACK	PSH	RST	SYN	FIN

Figure 2 : Définition actuelle des octets 13 et 14 de l'en-tête TCP, à partir de la RFC 3168.

Les deux fanions ECN dans l'en-tête TCP sont définis à partir des deux derniers bits du champ Réservé de l'en-tête TCP. Le bit 9 du champ Réservé de l'en-tête TCP est conçu comme fanion ECN-Echo (ECE), et le bit 8 est conçu comme fanion de fenêtre réduite d'encombrement (CWR, Congestion Window Reduced). Pour négocier l'utilisation de ECN, l'envoyeur TCP envoie un "paquet SYN d'établissement ECN", paquet SYN de TCP avec les fanions ECE et CWR établis. Si l'hôte TCP à l'autre extrémité souhaite utiliser ECN pour cette connexion, il envoie alors un "paquet SYN-ACK d'établissement ECN", paquet SYN TCP avec le fanion ECE établi et le fanion CWR non établi. Autrement, l'hôte TCP de l'autre extrémité retourne un paquet SYN-ACK où ni le fanion ECE ni le fanion CWR ne sont établis.

Revenons maintenant aux réinitialisations de TCP. Lorsque un hôte TCP qui négocie ECN envoie un paquet SYN d'établissement ECN, une ancienne mise en œuvre de TCP est supposée ignorer ces fanions dans le champ Réservé, et envoyer un paquet SYN-ACK complet en réponse. Cependant, il y a des pare-feu et équilibreurs de charge vicieux dans l'Internet qui au lieu de cela répondent à un paquet SYN d'établissement ECN par une réinitialisation. À la suite du déploiement de nœud d'extrémité à capacité ECN, il y a eu de nombreuses plaintes contre les hôtes à capacité ECN qui ne peuvent pas accéder à un certain nombre de sites de la Toile [Kelson00]. Il y a eu des investigations par la communauté de Linux, et par le projet TBIT [TBIT] sur des données recueillies de septembre 2000 à mars 2002, et cela a été discuté dans un article de Enterprise Linux Today [Cou01]. Certains des équipements en cause ont été has identifiés, et une page de la Toile [FIXES] contient une liste de produits non conformes et les corrections envoyées par les fabricants. En mars 2002, six mois après l'approbation de ECN comme proposition de norme, il était répondu aux paquets SYN d'établissement ECN par une réinitialisation par 203 des 12 364 sites de la Toile testés, et les paquets SYN d'établissement ECN étaient abandonnés par 420 des sites de la Toile. Installer un logiciel qui bloque les paquets qui utilisent les fanions dans le champ Réservé de TCP est considérablement plus facile que de désinstaller ce logiciel ultérieurement.

3.1 ECN : la solution de rechange

Une solution de rechange pour maintenir la connexité face à des équipements fautifs a été décrite dans [Floyd00], et a été spécifiée dans la RFC 3168 comme une procédure qui peut être incluse dans des mises en œuvre de TCP. On décrit brièvement ci-dessous cette solution de rechange.

Pour fournir une connexité robuste même en présence d'équipements fautifs, un hôte TCP qui reçoit une réinitialisation en réponse à la transmission d'un paquet SYN d'établissement ECN peut renvoyer le SYN avec CWR et ECE non établis. IL en résulterait qu'une connexion TCP serait établie sans utiliser ECN. Cela a aussi le résultat malheureux que l'hôte TCP a capacité ECN ne répondra pas de façon appropriée à la prochaine réinitialisation valide. Si une seconde réinitialisation est envoyée en réponse au second SYN, qui a les fanions CWR et ECE non établis, l'hôte TCP devrait alors répondre correctement en abandonnant la connexion.

De façon similaire, un hôte qui ne reçoit pas de réponse à un SYN d'établissement ECN au sein de la temporisation normale de retransmission de SYN peut renvoyer le SYN et toute retransmissions de SYN ultérieures avec les CWE et ECE non établis. Pour parer à la perte normale de paquet qui résulte de la perte du SYN original, l'hôte d'origine peut retransmettre un ou plusieurs paquets SYN d'établissement ECN avant d'abandonner et de retransmettre le SYN avec les bits CWR et ECE non établis.

Certaines mises en œuvre de TCP ont jusqu'à présent décidé de ne pas développer cette solution de rechange, pour les raisons suivantes :

* Les solutions de rechange auraient pour résultat des hôtes à capacité ECN qui ne répondent pas correctement à la première réinitialisation valide reçue en réponse à un paquet SYN.

* La solution de rechange limiterait la fonctionnalité ECN dans des environnements sans équipement fautif, en désactivant ECN lorsque le premier paquet SYN ou SYN-ACK est abandonné dans le réseau.

* Dans de nombreux cas, les solutions de rechange impliqueraient un délai de six secondes ou plus avant que soit établie la connexité avec le serveur distant, dans le cas d'un équipement fautif qui abandonne les paquets SYN d'établissement d'ECN. En s'accommodant de ces équipements fautifs, la solution de rechange a été jugée comme acceptant implicitement à la fois ce délai et l'équipement fautif qui serait cause de ce délai.

Une possibilité pour ces solutions de rechange serait qu'elles soient configurables par l'utilisateur.

Une conséquence inévitable de la solution de remplacement qui consiste à renvoyer un paquet SYN modifié en réponse à un réinitialisation est que cela érode encore plus la sémantique de la réinitialisation TCP. Et donc, lorsque un appareil du réseau envoie une réinitialisation, l'hôte TCP qui reçoit cette réinitialisation ne sait pas si elle a été envoyée simplement parce que les fanions en rapport avec l'ECN étaient mis dans l'en-tête TCP, ou à cause de quelque problème plus fondamental. Donc, l'hôte TCP renvoie la paquet SYN de TCP sans établir les fanions en rapport avec ECN dans l'en-tête TCP. La conséquence finale de cette absence de communications claires entre le boîtier de médiation et les nœuds d'extrémité pourrait être une spirale sans fin de communications spécifiées pour les protocoles de transport, car les nœuds d'extrémité essayent de sacrifier le moins possible de fonctionnalités dans le processus de détermination des paquets qui seront ou non transmis à l'autre extrémité. Ceci est exposé plus en détail au paragraphe 6.1 ci-dessous.

4. Combattre les obstacles à l'évolution appropriée de l'infrastructure de l'Internet

Une des raisons de l'importance (pour moi) de cette question des réinitialisations inappropriées est qu'elle complique le déploiement de ECN dans l'Internet (bien qu'elle n'ait heureusement pas complètement bloqué son développement). Elle a aussi ajouté un obstacle inutile à l'efficacité future de ECN.

Cependant, un seconde raison, plus générale, pour laquelle cette question est importante est que la présence d'équipements qui dans l'Internet rejettent des paquets TCP valides limite l'évolution future de TCP, tout à fait en dehors de la question de ECN. C'est à dire que le large développement d'équipements qui rejettent les paquets TCP qui utilisent les fanions Réservé dans l'en-tête TCP pourrait effectivement empêcher le développement de nouveaux mécanismes qui utilisent un de ces fanions Réservé. Il importe peu de savoir si ces nouveaux mécanismes sont protégés par le statut de norme expérimentale ou de proposition de norme de la part de l'IETF, parce que les équipements fautifs dans l'Internet n'empêchent pas de regarder le statut actuel des protocoles avant de rejeter les paquets. TCP est un bon protocole, et utile, mais il serait dommage que le développement d' équipement fautif dans l'Internet résulte en un "gel" de TCP dans son état actuel, sans capacité d'utiliser les fanions Réservé dans une évolution future de TCP.

Dans le cas spécifique des boîtiers de médiation qui bloquent les paquets SYN de TCP en essayant de négocier ECN, la solution de remplacement décrite au paragraphe 3.1 est suffisante pour assurer que les nœuds d'extrémité pourront toujours établir la connexité. Cependant, il y aura vraisemblablement des utilisations supplémentaires du champ Réservé de TCP qui seront normalisées dans les un ou deux ans à venir, et ces utilisations supplémentaires pourraient ne pas aussi bien coexister avec les boîtiers de médiation qui envoient des réinitialisations. Considérons les difficultés qui pourraient résulter si un chemin change au milieu de la durée de vie d'une connexion, et si les boîtiers de médiations sur l'ancien et le nouveau chemin ont des politiques différentes sur les fanions du champ Réservé de TCP qu'ils vont ou non bloquer.

D'un point de vue plus large, l'existence de serveurs ou pare-feu sur la Toile qui envoient des réinitialisations inappropriées est seulement un exemple de fonctionnalité de l'Internet qui restreignent sa future évolution. L'impact de toutes ces petites restrictions accumulées représente un obstacle considérable pour le développement de l'architecture de l'Internet.

5. Le problème des protocoles de transport

Une leçon pour les concepteurs de protocoles de transport est que les protocoles de transport devront se protéger eux-mêmes contre les actions inconnues et qui semblent arbitraires des pare-feu, normaliseurs, et autres boîtiers de médiation sur le réseau. Pour le moment, pour TCP, cela signifie d'envoyer un SYN de non établissement d'ECN lorsque ils reçoivent une réinitialisation en réponse à un paquet SYN d'établissement ECN. Des actions défensives du côté des protocoles de transport pourraient comporter d'utiliser les fanions Réservé dans le paquet SYN avant de les utiliser dans le trafic de données, pour se protéger contre les boîtiers de médiation qui bloquent les paquets en utilisant ces fanions. Il est possible que les protocoles de transport aient aussi à ajouter des vérifications supplémentaires durant le cours de la durée de vie de la connexion pour vérifier les interférences des boîtiers de médiation le long du chemin.

La norme de ECN, la RFC 3168, contient un exposé détaillé à la Section 18 sur de "possibles changements au champ ECN dans le réseau", mais inclut ce qui suit sur des changements possibles de l'en-tête TCP :

"Le présent document ne prend pas en considération les dangers potentiels introduits par les changements de l'en-tête de transport au sein du réseau. On note que quand IPsec est utilisé, l'en-tête de transport est protégé à la fois dans le tunnel et dans les nœuds de transport [ESP, AH]."

Avec la modification actuelle des en-têtes de niveau transport dans le réseau par les pare-feu (comme exposé ci-dessous au paragraphe 6.2), les concepteurs de protocoles futurs pourraient n'avoir plus la latitude d'ignorer l'impact éventuel de changements de l'en-tête de transport au sein du réseau.

Les protocoles de transport auront aussi à répondre d'une façon ou d'une autre à un code ICMP de "Communication interdite par décision administrative" si les boîtiers de médiation commencent à utiliser cette forme de message ICMP Destination injoignable pour indiquer que le paquet utilise des fonctionnalité non admises [RFC1812].

6. Le problème des boîtiers de médiation

Étant donné que certains boîtiers de médiation vont abandonner certains paquets parce qu'ils utilisent des fonctionnalités non admises par le boîtier, la grosse question qui reste est celle de la façon dont les boîtiers de médiation devraient communiquer la raison de cette action aux nœuds d'extrémité, s'il en est. Une suggestion, à considérer plus à fond dans un document distinct, serait que les pare-feu envoient un message ICMP Destination injoignable avec le code "Communication interdite par décision administrative" [B01].

Nous reconnaissons que ce n'est pas une solution idéale, pour plusieurs raisons. D'abord, les boîtiers de médiation le long du chemin inverse peuvent bloquer ces messages ICMP. Ensuite, certains opérateurs de pare-feu objecteront à une communication explicite parce qu'elle révèle trop d'informations sur les politiques de sécurité. Et enfin, la réponse des protocoles de transport à de tels messages ICMP n'est pas encore spécifiée.

Cependant, un message ICMP "Interdit par décision administrative" pourrait être un ajout raisonnable, pour les pare-feu qui veulent utiliser une communication explicite. Une possibilité, qui devra elle aussi être explorée dans un document distinct, serait que le message ICMP "Interdit par décision administrative" soit modifié pour apporter des informations supplémentaires à l'hôte final.

Il faut noter que le présent document ne prend pas en considération les boîtiers de médiation qui bloquent des protocoles de transport complets. Il faut aussi noter que le présent document ne traite pas de pare-feu qui envoient des réinitialisations en réponse à un paquet SYN de TCP à un accès TCP au pare-feu désactivé. Une telle utilisation de la réinitialisation paraît cohérente avec la sémantique de la réinitialisation TCP. Le présent document considère seulement les problèmes causés par les boîtiers de médiation qui bloquent des paquets spécifiques au sein d'un protocole de transport alors que d'autres paquets provenant de ce protocole de transport sont transmis sans altération par le boîtier.

Une complication est qu'une fois qu'un mécanisme est installé dans un pare-feu pour bloquer une fonctionnalité particulière, il peut être nécessaire aux administrateurs de réseau de développer des efforts considérables pour "désinstaller" ce blocage. Il a été suggéré que des réglages modulables des pare-feu puissent rendre la récupération d'incidents futurs moins douloureuse. Une fois encore, comme le présent document ne traite pas les questions plus générales sur les pare-feu, le problème d'une plus grande souplesse des pare-feu, et les risques éventuels de sécurité qui en résultent, relèvent d'un document distinct.

6.1 Choix actuels pour les pare-feu

Supposons un pare-feu qui a décidé d'abandonner les paquets TCP qui utilisent les bits réservé dans l'en-tête TCP ; la question se pose de savoir si le pare-feu devrait aussi envoyer une réinitialisation, afin d'empêcher la connexion TCP de consommer inutilement des ressources chez l'envoyeur TCP qui attend la fin de la temporisation de retransmission. On peut toujours dire que le pare-feu se sente obligé ou non d'abandonner le paquet TCP, il n'est pas approprié d'envoyer une réinitialisation TCP. L'envoi d'une réinitialisation TCP en réponse à une fonctionnalité interdite continuerait la surcharge sémantique actuelle de la réinitialisation TCP d'une façon qui pourrait être contre productive tout autour.

Par exemple, le paragraphe 2.3 a déjà fait observer que certains pare-feu envoient des réinitialisations en réponse aux paquets SYN de TCP comme mécanisme de contrôle de l'encombrement. Éventuellement en réponse à cela (ou peut-être en réponse à quelque chose d'autre), certaines mises en œuvre très courantes de TCP renvoient immédiatement un paquet SYN en réponse à une réinitialisation, jusqu'à quatre fois. D'autres mises en œuvre de TCP, conformément aux normes, ne renvoient pas de paquets SYN après réception d'une réinitialisation. Les mise en œuvre de TCP les plus agressives augmentent l'encombrement pour les autres, mais augmentent aussi leurs propres chances de passer finalement au travers. En donnant cette sémantique fluide à la réinitialisation TCP, on peut s'attendre à ce que plus de mises en œuvre de TCP commencent à renvoyer des paquets SYN en réponse à une réinitialisation, indépendamment de toute question en rapport avec ECN. Visiblement, cela affaiblit l'efficacité de la réinitialisation utilisée pour son objet originel, de répondre aux paquets TCP qui ne sont apparemment pas destinés à la connexion actuelle.

Si on ajoute à ce mélange l'utilisation de la réinitialisation TCP par les pare-feu en réponse aux paquets TCP qui utilisent les bits réservés dans l'en-tête TCP, cela embourbe un peu plus la situation. Parce que les réinitialisations TCP pourraient être envoyées à cause de l'encombrement, ou d'une fonctionnalité interdite, ou parce qu'un paquet a été reçu d'une connexion TCP antérieure, les mises en œuvre de TCP (ou plus précisément, les développeurs de mises en œuvre de TCP) auraient maintenant une incitation à persister encore plus à envoyer des paquets SYN en réponse aux réinitialisations TCP. En plus de l'incitation mentionnée ci-dessus à renvoyer des paquets SYN TCP pour augmenter ses chances de se tirer d'affaire en période d'encombrement, la réinitialisation TCP pourrait avoir été due à une fonctionnalité interdite au lieu de l'encombrement, de sorte que la mise en œuvre de TCP peut renvoyer des paquets SYN sous différentes formes pour déterminer exactement quelle fonctionnalité est interdite. De tels changements continuels de la sémantique de la réinitialisation TCP pourraient bien conduire à une escalade continuelle de mesures et contre mesures entre pare-feu et hôtes d'extrémité, avec peu de bénéfice productif pour chaque partie.

On pourrait avancer que *d'abandonner* le paquet SYN TCP du fait de l'utilisation des fonctionnalités interdites conduit à une surcharge de la sémantique de l'abandon de paquet, de la même façon que la réinitialisation conduit à une surcharge de la sémantique de la réinitialisation. C'est vrai; du point de vue de la réponse du système terminal aux messages avec une sémantique surchargée, il serait préférable d'avoir une indication explicite sur la fonctionnalité interdite (pour les pare-feu qui pour une raison ou une autre veulent utiliser des indications explicites). Mais étant donné le choix d'un pare-feu entre l'envoi d'une réinitialisation et le simple abandon du paquet, ont peut avancer que les simple abandon de paquet cause moins de dommages, en termes d'incitation aux hôtes d'extrémité pour adopter des contre mesures. Il est vrai que le simple abandon du paquet, sans envoi d'une réinitialisation provoque un délai à la connexion TCP pour le renvoi du paquet SYN sans la fonctionnalité interdite. Cependant, envoyer une réinitialisation a l'effet indésirable à plus long terme de donner une incitation aux mises en œuvre futures de TCP d'ajouter des combinaisons encore plus baroques de renvoi de paquets SYN en réponse à la réinitialisation, parce que l'envoyeur TCP ne peut pas dire si la réinitialisation est pour une raison standard, pour l'encombrement, ou pour la fonctionnalité interdite de l'option X ou le bit réservé Y dans l'en-tête TCP.

6.2 Complications de la modification des en-têtes de paquet dans le réseau

En plus des pare-feu qui envoient des réinitialisations en réponse aux paquets SYN d'établissement d'ECN et des pare-feu qui abandonnent les paquets SYN d'établissement d'ECN, il y a aussi des pare-feu qui émettent par défaut à zéro les fanions dans le champ Réservé de TCP , y compris les deux fanions utilisés pour ECN. On note que dans certains cas, cela peut avoir des conséquences involontaires et indésirables.

Si un pare-feu met à zéro les fanions qui se rapportent à ECN dans l'en-tête TCP dans la paquet SYN initial, la connexion TCP sera établie sans utiliser ECN, et les fanions qui se rapportent à ECN dans l'en-tête TCP seront envoyés à zéro dans tous les paquets suivants sur cette connexion. Cela réalisera l'objectif du pare-feu de bloquer ECN, tout en permettant à la connexion TCP de continuer efficacement et en douceur sans utiliser ECN.

Si pour une raison quelconque les fanions qui se rapportent à ECN dans l'en-tête TCP ne sont pas mis à zéro dans le paquet SYN initial allant de l'hôte A à l'hôte B, mais si le pare-feu met à zéro les fanions dans le paquet de réponse SYN/ACK de l'hôte B à l'hôte A, la conséquence pourrait être de renverser le contrôle d'encombrement de bout en bout pour la connexion. Les spécifications ECN n'ont pas été écrites pour assurer un fonctionnement robuste en présence d'une mise à zéro arbitraire des champs d'en-tête TCP dans le réseau, parce qu'il n'est pas venu à l'idée des auteurs du protocole que c'était une exigence dans la conception du protocole au moment de sa rédaction.

De même, si les fanions qui se rapportent à ECN dans l'en-tête TCP ne sont pas mis à zéro dans le paquet SYN ni dans le paquet SYN/ACK, mais si le pare-feu met ces fanions à zéro dans des paquets ultérieurs dans cette connexion TCP, cela pourrait aussi avoir la conséquence inattendue de renverser le contrôle d'encombrement de bout en bout pour cette connexion. Les détails des ces interactions éventuelles ne sont pas cruciaux pour le présent document, et ils sont décrits dans l'appendice. Cependant, notre conclusion, à la fois pour les fanions qui se rapportent à ECN dans l'en-tête TCP et pour les utilisations futures des quatre autres bits du champ Réservé de TCP, serait que si il est exigé que les pare-feu soient capables de bloquer l'utilisation d'une nouvelle fonction qui serait ajoutée à un protocole, il serait préférable de régler ce problème lors de la phase initiale de conception par une coopération entre la communauté des pare-feu et les concepteurs du protocole.

7. Conclusions

Notre conclusion est qu'il n'est pas conforme aux normes actuelles des pare-feu, équilibreurs de charge, ou serveurs de la Toile de répondre par une réinitialisation à un paquet SYN de TCP simplement parce que le paquet utilise des fanions dans le champ Réservé de TCP. Plus précisément, il n'est pas conforme de répondre par une réinitialisation à un paquet SYN TCP simplement parce que les fanions ECE et CWR sont établis dans l'en-tête IP. Nous invitons instamment les fabricants à rendre disponibles des correctifs pour tout code non conforme, et nous invitons les FAI et administrateurs de systèmes à déployer ces correctifs sur leurs serveurs et pare-feu sur l'Internet.

Nous ne prétendons pas que l'abandon arbitraire de paquets qui utilisent des fanions dans le champ Réservé de TCP par les boîtiers de médiation viole une norme quelconque, mais nous affirmons que ce type de comportement, en l'absence d'une méthode claire d'information des nœuds d'extrémité des raisons de ces actions, pourrait représenter un obstacle significatif au développement de TCP. Des travaux complémentaires sont clairement nécessaires pour réconcilier les intérêts en conflit entre la fourniture de la sécurité tout en permettant en même temps une évolution contrôlée des protocoles de l'Internet.

8. Remerciements

Le présent document résulte de discussions et de l'activité de nombreuses personnes, aussi me réfrènerai-je d'essayer de remercier ici chacune d'entre elles. Mes remerciements spécifiques vont à Ran Atkinson, Steve Bellovin, Alex Cannara, Dennis Ferguson, Ned Freed, Mark Handley, John Klensin, Allison Mankin, Jitendra Padhye, Vern Paxson, K. K. Ramakrishnan, Jamal Hadi Salim, Pekka Savola, Alex Snoeren et Dan Wing pour leurs réactions sur le présent document, et au groupe de recherches sur le bout en bout, l'IAB, et l'IESG pour la discussion de ces questions. Je remercie Mikael Olsson pour les nombreuses séances de discussions. Je remercie aussi les membres de la liste de diffusion Firewall Wizards pour leurs réactions (généralement de désaccord) sur le précédent projet de ce document.

Les discussions par messagerie électronique avec un certain nombre de personnes, y compris Dax Kelson, Alexey Kuznetsov, Kacheong Poon, David Reed, Jamal Hadi-Salim et Venkat Venkatsubra, ont visé les questions soulevées par les équipements non conformes dans l'Internet qui ne répondent pas aux paquets TCP SYN en mettant les fanions ECE et CWR. Nous remercions Mark Handley, Jitentra Padhye, et les autres pour les discussions sur les procédures d'initialisation de TCP.

9. Références normatives

[RFC793] J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", (STD 7), septembre 1981.

[RFC1122] R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, octobre 1989.

[RFC1812] F. Baker, "Exigences pour les routeurs IP version 4", juin 1995. (Mise à jour par la RFC 2644)

[RFC2026] S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (Remplace RFC1602, RFC1871) (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378)

[RFC2481] K. Ramakrishnan, S. Floyd, "Proposition d'ajout de la notification d'encombrement explicite (ECN) à IP", janvier 1999.

[RFC2873] X. Xiao et autres, "Traitement du champ de préséance IPv4 dans TCP", juin 2000. (P.S.)

[RFC2979] N. Freed, "Exigences de comportement pour les pare-feu Internet", octobre 2000. (Information)

[RFC3168] K. Ramakrishnan et autres, "Ajout de la notification explicite d'encombrement (ECN) à IP", septembre 2001.

10. Références informatives

[B01] Bellovin, S., "A "Reason" Field for ICMP "Administratively Prohibited" Messages", Travail en cours.

[Cou01] Scott Courtney, Why Can't My 2.4 Kernel See Some Web Sites?, Enterprise Linux Today, Apr 17, 2001. URL "http://eltoday.com/article.php3?ltsn=2001-04-17-001-14-PS".

[ECN] "The ECN Web Page", URL "http://www.icir.org/floyd/ecn.html".

[FIXES] ECN-under-Linux Unofficial Vendor Support Page, URL "http://gtf.org/garzik/ecn/".

[Floyd00] Sally Floyd, "Negotiating ECN-Capability in a TCP connection", 2 octobre 2000, message électronique à la liste de diffusion end2end-interest. URL "http://www.icir.org/floyd/papers/ECN.Oct2000.txt".

[Kelson00] Dax Kelson, note envoyée à la liste de diffusion du noyau Linux, 10 septembre 2000.

[QUESO] Toby Miller, "Intrusion Detection Level Analysis of Nmap and Queso", 30 août 2000. URL "http://www.securityfocus.com/infocus/1225".

[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", Addison-Wesley, 1994.

[SFO01] "FreeBSD ipfw Filtering Evasion Vulnerability, Security Focus Online", 23 janvier 2001. URL "http://www.securityfocus.com/bid/2293".

[TBIT] Jitendra Padhye and Sally Floyd, "Identifying the TCP Behavior of Web Servers", SIGCOMM, août 2001. URL "http://www.icir.org/tbit/".

11. Considérations pour la sécurité

Un risque général de l'utilisation des fanions Réservé de TCP est le risque de fournir des informations supplémentaires sur la configuration de l'hôte en question. Cependant, TCP est spécifié de façon suffisamment lâche, avec un nombre suffisant de variantes et d'options, pour que des outils d'examen des accès tels que Nmap et Queso se tirent plutôt bien de l'identification de la configuration des hôtes même sans utiliser les fanions Réservé.

Les considérations pour la sécurité et toutes les autres considérations sur un possible message ICMP Destination injoignable avec le code "Communication interdite par décision administrative" seront exposées dans un document séparé.

Le souci traditionnel des pare-feu est d'empêcher l'accès non autorisé aux systèmes, pour prévenir les attaques de déni de service et autres attaques pour subvertir le terminal d'utilisateur et pour protéger les systèmes terminaux contre les codes fautifs. Nous somme conscients que l'une des faiblesses de la sécurité est imputée à l'utilisation des fanions Réservé dans l'en-tête TCP [SFO01]. Un filtre de paquets destiné uniquement à laisser passer les paquets dans les connexions établies peut laisser passer un paquet qui n'est pas dans une connexion établie si le paquet a le fanion ECE établi dans le champ réservé. "L'exploitation de cette faiblesse peut permettre un accès distant non autorisé à des service protégés par ailleurs." Il est aussi possible que puisse apparaître une mise en œuvre de TCP qui ait une code fautif associée à l'utilisation de fanions Réservé dans l'en-tête TCP, mais nous n'avons pas connaissance d'une telle mise en œuvre pour le moment.

Malheureusement, les problèmes de sécurité mal conçus sont au premier rang des raisons des problèmes décrits dans ce document. En août 2000, un article sur "L'analyse du niveau de détection d'intrusion de Nmap et Queso" décrivait l'outils Queso d'examen d'accès comme envoyant des paquets SYN avec les deux derniers bits Réservé établis dans l"en-tête TCP, et disait ce qui suit : "[QUESO] est facile à identifier, si vous voyez [ces deux bits Réservé et le bit SYN] établis dans le 13^è octet de l'en-tête TCP, vous savez que quelqu'un a des intentions malveillantes à l'égard de votre réseau." Comme exposé sur la page TBIT de la Toile, les boîtiers de médiation qui bloquent les SYN en utilisant les deux fanions Réservé qui se rapportent à ECN dans l'en-tête TCP ne bloquent pas les SYN qui utilisent les autres fanions Réservé dans l'en-tête TCP.

Une leçon à en tirer est que n'importe qui peut effectivement "attaque" une nouvelle fonction TCP simplement en utilisant cette fonction dans leur outil d'examen d'accès publiquement disponible, ce qui amène les boîtiers de médiation de toutes sortes à bloquer l'utilisation de cette fonction.

12. Appendice : Complications de la modification des en-têtes de paquet

Dans cette section nous montrons d'abord que si les fanions qui se rapportent à ECN dans l'en-tête TCP ne sont pas mis à zéro dans le paquet SYN initial allant de l'hôte A à l'hôte B, mais sont mis à zéro dans le paquet SYN/ACK de réponse de l'hôte B à l'hôte A, la conséquence pourrait être la subversion du contrôle d'encombrement de bout en bout pour cette connexion.

Supposons que le paquet SYN d'établissement d'ECN provenant de l'hôte A soit reçu par l'hôte B, mais que le SYN/ACK d'établissement d'ECN provenant de l'hôte B soit modifié par un pare-feu dans le réseau en un SYN/ACK de non établisssement d'ECN, comme dans la Figure 3 ci-dessous. La RFC 3168 ne spécifie pas que le paquet ACK devrait de quelque façon que ce soit faire l'écho des fanions TCP reçus dans le paquet SYN/ACK, parce qu'il n'était pas venu à l'esprit des concepteurs que ces fanions pourraient être modifiés au sein du réseau.

Figure 3 : fanions en rapport avec ECN dans le paquet SYN/ACK éliminés dans le réseau.

Suivant la RFC 3168, l'hôte A a reçu un paquet SYN de non établissement ECN, et ne doit pas établir ECT sur les paquets de données. L'hôte B, cependant, ne sait pas que l'hôte A a reçu un paquet SYN/ACK de non établissement ECN, et l'hôte B peut établir ECT sur les paquets de données. La RFC 3168 n'exige pas que l'hôte A réponde correctement aux paquets de données reçus de l'hôte B avec les codets ECT et CE établis dans l'en-tête IP. Et donc, l'envoyeur des données, l'hôte B, peut n'être jamais informé de l'encombrement rencontré dans le réseau, violant ainsi le contrôle d'encombrement de bout en bout.

Ensuite nous montrons que si les fanions qui se rapportent à ECN dans l'en-tête TCP ne sont mis à zéro ni dans le paquet SYN ni dans le paquet SYN/ACK, mais si le pare-feu met à zéro ces fanions dans des paquets ultérieurs de cette connexion TCP, cela pourrait aussi avoir la conséquence involontaire de subvertir le contrôle d'encombrement de bout en bout pour cette connexion. La Figure 4 montre ce scénario.

Figure 4 : fanions en rapport avec ECN dans le paquet ACK éliminés dans le réseau.

Les fanions en rapport avec ECN ne sont pas changés par le réseau dans les paquets SYN et SYN/ACK d'établissement d'ECN pour le scénario de la Figure 4, et les deux nœuds d'extrémité sont libres d'utiliser ECN, et d'établir le fanion ECT dans le champ ECN de l'en-tête IP. Cependant, si le pare-feu élimine le fanion ECE dans l'en-tête TCP dans les paquets ACK du nœud A au nœud B, le nœud B n'entendra alors jamais parler des encombrements que ses paquets antérieurs ont rencontré dans le réseau, ce qui constitue bien une subversion du contrôle d'encombrement de bout en bout pour cette connexion.

Des complications additionnelles vont survenir lorsque et si l'utilisation du nom occasionnel ECN dans TCP est normalisée par l'IETF [RFC3168], car cela pourrait impliquer la spécification d'un fanion supplémentaire dans le champ Réservé de TCP pour un retour d'information du receveur des données TCP à l'envoyeur des données TCP. La motivation principale du nom occasionnel ECN est de permettre à l'envoyeur des données des mécanismes de vérification que les éléments du réseau ne sont pas en train de supprimer le codet CE, et que les receveurs des données font correctement rapport à l'envoyeur de la réception des paquets avec le codet CE établi.

13. Considérations relatives à l'IANA

Il n'y a pas de considérations relatives à l'IANA dans le présent document.

14. Adresse de l'auteur

Sally Floyd

ICIR (ICSI Center for Internet Research)

téléphone : +1 (510) 666-2989

mél : floyd@icir.org

URL : http://www.icir.org/floyd/

15. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2002). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de copyright ci-dessus et le présent paragraphe soient inclus dans toutes telles copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de copyright ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour le besoin du développement des normes Internet, auquel cas les procédures de copyright définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou successeurs ou ayant droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et LE CONTRIBUTEUR, L’ORGANISATION QU’IL OU ELLE REPRÉSENTE OU QUI LE/LA FINANCE (S’IL EN EST), LA INTERNET SOCIETY ET LA INTERNET ENGINEERING TASK FORCE DÉCLINENT TOUTES GARANTIES, EXPRIMÉES OU IMPLICITES, Y COMPRIS MAIS NON LIMITÉES À TOUTE GARANTIE QUE L’UTILISATION DES INFORMATIONS CI-ENCLOSES NE VIOLENT AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D’APTITUDE À UN OBJET PARTICULIER.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.