Groupe de travail Réseau	L. Eggert, Nokia
Request for Comments: 5482	F. Gont, UTN/FRH
Catégorie : Sur la voie de la normalisation	mars 2009
	Traduction Claude Brière de L'Isle

Option Temporisation d'utilisateur TCP

Statut de ce mémoire
Le présent document spécifie un protocole sur la voie de la normalisation de l’Internet pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Normes officielles des protocoles de l’Internet" (STD 1) pour connaître l’état de la normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document.

Résumé
La temporisation d'utilisateur TCP contrôle la durée pendant laquelle les données transmises peuvent rester non acquittées avant qu'une connexion soit close de force. C'est un paramètre local, par connexion. Le présent document spécifie une nouvelle option TCP -- l'option de temporisation d'utilisateur TCP -- qui permet à une extrémité d'une connexion TCP d'annoncer sa valeur actuelle de temporisateur d'utilisateur. Cette information donne un avis à l'autre extrémité de la connexion TCP pour adapter sa temporisation d'utilisateur en conséquence. Augmenter les temporisations d'utilisateur sur les deux extrémités d'une connexion TCP lui permet de survivre sur des périodes étendues sans connexité de bout en bout. Diminuer les temporisations d'utilisateur permet aux serveurs occupés de notifier explicitement à leurs clients qu'il ne vont conserver l'état de connexion que pour une courte période sans connexité.
Table des matières
1. Introduction	1
2. Conventions	2
3. Fonctionnement	2
3.1 Changement de la temporisation locale d'utilisateur	3
3.2 Fiabilité de l'option UTO	4
3.3 Format d'option	5
3.4 Valeurs d'option réservées	5
4. Questions d'interopérabilité	6
4.1 Boîtiers de médiation	6
4.2 Maintien en vie TCP	6
5. Considérations de programmation et de gestion	6
6. Considérations sur la sécurité	6
7. Considérations relatives à l'IANA	7
8. Remerciements	7
9. Références	8
9.1 Références normatives	8
9.2 Références pour information	8
Adresse des auteurs	9

 	1.	Introduction

La spécification du protocole de contrôle de transmission (TCP, Transmission Control Protocol) [RFC0793] définit un paramètre local, par connexion "user timeout" (temporisation d'utilisateur) qui spécifie la durée maximum pendant laquelle des données transmises peuvent rester sans accusé de réception avant que TCP soit forcé de clore la connexion correspondante. Les applications peuvent régler et changer ce paramètre avec des invocations de OPEN et SEND. Si une interruption de connexité de bout en bout dure plus que la temporisation d'utilisateur, un envoyeur ne va pas recevoir d'accusé de réception pour une tentative  de transmission, incluant de maintien en vie, et va clore la connexion TCP quand la fin de temporisation d'utilisateur survient.

Le présent document spécifie une nouvelle option TCP -- l'option Temporisation d'utilisateur (UTO, User Timeout Option) TCP -- qui permet à une extrémité d'une connexion TCP d'annoncer sa valeur actuelle de temporisation d'utilisateur. Cette information donne avis à l'autre extrémité de la connexion d'adapter sa temporisation d'utilisateur en conséquence. C'est-à-dire que TCP reste libre de ne pas considérer l'avis donné dans l'option UTO si sa politique locale lui suggère que c'est approprié.

Augmenter la temporisation d'utilisateur sur les deux extrémités d'une connexion TCP lui permet de survivre à des périodes étendues sans connexité de bout en bout. Diminuer la temporisation d'utilisateur permet aux serveurs encombrés de notifier explicitement à leurs clients qu'ils ne vont maintenir l'état de connexion que pour un court instant sans connexité.

En l'absence d'une fin de temporisation d'utilisateur spécifiée par l'application, la spécification TCP [RFC0793] définit une temporisation d'utilisateur par défaut de 5 minutes. La RFC sur les exigences pour les hôtes [RFC1122] précise cette définition en introduisant deux seuils, R1 et R2 (R2 > R1) qui contrôlent le nombre de tentatives de retransmission pour un seul segment. Elle suggère que TCP devrait notifier aux applications quand R1 est atteint pour un segment, et clore la connexion quand R2 est atteint. La [RFC1122] définit aussi les valeurs recommandées pour R1 (3 retransmissions) et R2 (100 secondes) en notant que R2 pour les segments SYN devrait être d'au moins 3 minutes. Au lieu d'une seule temporisation d'utilisateur, certaines mises en œuvre de TCP offrent des politiques de granularité plus fine. Par exemple, Solaris prend en charge différentes temporisations selon que la connexion TCP est dans l'état SYN-SENT, SYN-RECEIVED, ou ESTABLISHED [SOLARIS].

Bien que certaines mises en œuvre de TCP permettent aux applications de régler leur temporisation d'utilisateur locale, TCP n'a pas de mécanisme de protocole pour signaler les changements de la temporisation d'utilisateur locale à l'autre extrémité de la connexion. Cela cause l'inefficacité des changements locaux en permettant à une connexion de survivre pendant des durées étendues sans connexité, parce que l'autre extrémité va quand même clore la connexion après l'expiration de sa temporisation d'utilisateur.

La capacité d'informer l'autre extrémité d'une connexion de la temporisation d'utilisateur locale peut améliorer le fonctionnement de TCP dans des scénarios qui ne sont actuellement pas bien pris en charge. Un exemple de ce scénario est celui des hôtes mobiles qui changent de point de rattachement au réseau. De tels hôtes, utilisant peut-être IP mobile [RFC3344], HIP [RFC4423], ou des mécanismes de mobilité de la couche de transport [TCP_MOB], sont seulement connectés de façon intermittente à l'Internet. Entre les périodes de connexion, les hôtes mobiles peuvent subir des périodes sans connexité de bout en bout. D'autres facteurs qui peuvent causer des interruptions transitoires de connexité sont de hauts niveaux d'encombrement ou des défaillances de liaison ou d'acheminement à l'intérieur du réseau. Dans ces scénarios, un hôte peut ne pas savoir exactement quand ou pour combien de temps les interruptions de connexité vont se produire, mais il pourrait être capable de déterminer une probabilité accrue de tels événements sur la base des schémas passés de mobilité et donc bénéficier de l'utilisation de plus longues temporisations d'utilisateur. Dans d'autres scénarios, le temps et la durée d'une interruption de connexité peut même être prévisible. Par exemple, un nœud dans l'espace pourrait rencontrer des interruptions de connexité dues au blocage de la ligne de vue par des corps planétaires. Le moment de ces événements peut être calculé à partir des mécaniques orbitales.

 	2.	Conventions

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119],.

 	3.	Fonctionnement

L'utilisation de l'option Temporisation d'utilisateur TCP peut être activée connexion par connexion, par exemple, par une option d'API, ou contrôlé par un réglage à l'échelle du système. TCP tient quatre variables d'état par connexion pour contrôler le fonctionnement de l'option UTO, dont trois (ADV_UTO, ENABLED, et CHANGEABLE) sont nouvelles :

USER_TIMEOUT : paramètre USER TIMEOUT de TCP, comme spécifié dans la [RFC0793].

ADV_UTO : option UTO annoncée à l'homologue TCP distant. C'est une valeur spécifiée par l'application, et peut être spécifiée au niveau du système. Si elle n'est pas spécifiée, elle prend par défaut le USER TIMEOUT par défaut du système.

ENABLED (booléen) : fanion qui contrôle si l'option UTO est activée pour une connexion. Ce fanion s'applique à l'envoi et à la réception. Il est faux par défaut.

CHANGEABLE (booléen) : fanion qui contrôle si USER_TIMEOUT (le paramètre USER TIMEOUT de TCP) peut être changé sur la base d'une option UTO reçue de l'autre extrémité de la connexion. Il est vrai par défaut et devient faux quand une application établit explicitement USER_TIMEOUT.

Noter qu'un échange d'options UTO entre les deux extrémités d'une connexion n'est pas une négociation qui les lie. La transmission d'une option UTO est une suggestion que l'autre extrémité considère d'adapter sa temporisation d'utilisateur. Cette adaptation ne se fait que si l'autre extrémité de la connexion l'a explicitement permise (ENABLED et CHANGEABLE sont tous deux vrais).

Avant d'ouvrir une connexion, une application qui souhaite utiliser l'option UTO active son utilisation en réglant ENABLED à vrai. Elle peut choisir un UTO local approprié en établissant explicitement ADV_UTO ; autrement, UTO est réglé à la valeur de USER TIMEOUT par défaut. Finalement, l'application devrait déterminer si elle va permettre au USER TIMEOUT local de changer sur la base des options UTO reçues de l'autre extrémité d'une connexion. Ceci est permis par défaut pour les connexions qui n'ont pas de soucis spécifiques de temporisation d'utilisateur. Si une application établit explicitement le USER_TIMEOUT, CHANGEABLE DOIT devenir faux afin d'empêcher les options UTO (provenant de l'autre extrémité) de supplanter les demandes d'application locales. Autrement, les applications peuvent établir ou annuler CHANGEABLE directement par des invocations d'API.

Effectuer ces étapes avant l'ouverture d'une session active ou passive cause l'échange des options UTO dans les paquets SYN et SYN-ACK et est une façon fiable d'échanger initialement les valeurs d'UTO, et potentiellement s'y adapter. Les mises en œuvre de TCP PEUVENT fournir des réglages par défaut au niveau du système pour les paramètres de connexion ENABLED, ADV_UTO et CHANGEABLE.

En plus d'échanger les options UTO dans les segments SYN, une connexion qui a activé les options UTO DEVRAIT inclure une option UTO dans le premier paquet qui n'a pas le fanion SYN établi. Cela aide à minimiser la quantité d'informations d'état que TCP doit conserver pour les connexions dans les états non synchronisés. Aussi, il est particulièrement utile quand des mécanismes comme des "mouchards SYN" [RFC4987] sont mis en œuvre, permettant à une connexion TCP nouvellement établie de bénéficier des informations annoncées par l'option UTO, même si l'UTO contenue dans le segment SYN initial n'était pas enregistrée.

Un hôte qui prend en charge l'option UTO DEVRAIT en inclure une dans le plus prochain segment sortant possible chaque fois qu'il commence à utiliser une nouvelle temporisation d'utilisateur pour la connexion. Cela permet à l'autre extrémité de la connexion d'adapter en conséquence sa temporisation d'utilisateur locale. Une mise en œuvre de TCP qui ne prend pas en charge l'option UTO DOIT l'ignorer en silence [RFC1122], assurant donc l'interopérabilité.

Les hôtes DOIVENT imposer des limites inférieures et supérieures aux temporisations d'utilisateur qu'ils utilisent pour une connexion. Le paragraphe 3.1 discute des limites de temporisation d'utilisateur et des effets potentiellement problématiques de certains réglages de temporisation d'utilisateur.

Finalement, on notera que l'espace d'options de TCP est limité à 40 octets. Par suite, si d'autres options TCP sont utilisées, cela peut déjà consommer tout l'espace d'options TCP disponible, empêchant donc l'utilisation de l'option UTO spécifiée dans ce document. Donc, les questions d'espace d'option TCP devraient être examinées avant de permettre l'option UTO.

 	3.1	Changement de la temporisation locale d'utilisateur
Quand un hôte reçoit une option TCP Temporisation d'utilisateur, il doit décider si il change la temporisation d'utilisateur locale de la connexion correspondante. Si le fanion CHANGEABLE est faux, USER_TIMEOUT NE DOIT PAS être changé, sans considération de l'option UTO reçue. Sans cette restriction, l'option UTO modifierait la sémantique de TCP, parce qu'une temporisation d'utilisateur demandée par l'application pourrait être outrepassée par des demandes de l'homologue. Dans ce cas, TCP DEVRAIT cependant notifier à l'application la valeur de la temporisation d'utilisateur reçue du système de l'autre extrémité.

En général, sauf si l'application de l'hôte local a demandé une temporisation d'utilisateur spécifique pour la connexion, CHANGEABLE va être vrai et les hôtes DEVRAIENT ajuster la temporisation d'utilisateur TCP locale (USER_TIMEOUT) en réponse à la réception d'une option UTO, comme décrit dans la suite de ce paragraphe.

L'option UTO spécifie la temporisation d'utilisateur en secondes ou minutes, plutôt qu'en un nombre de retransmissions ou de temps d'aller-retour (RTT, Round-Trip Time). Donc, l'option UTO permet aux hôtes d'échanger les valeurs de temporisation d'utilisateur de 1 seconde à plus de 9 heures à la granularité de secondes, et de 1 minute à plus de 22 jours à une granularité de minutes.

Des valeurs très courtes de temporisation d'utilisateur peuvent affecter les transmissions TCP sur des chemin à fort retard. Si la temporisation d'utilisateur se produit avant qu'un accusé de réception arrive pour un segment en instance, éventuellement à cause de la perte de paquets, la connexion ferme. De nombreuses mises en œuvre de TCP prennent par défaut des valeurs de temporisation d'utilisateur de quelques minutes. Bien que l'option UTO permette la suggestion de courtes temporisations, les applications qui les annoncent devraient tenir compte de ces effets.

De longues valeurs de temporisation d'utilisateur permettent aux hôtes de tolérer des périodes étendues sans connexité de bout en bout. Cependant, elles exigent aussi que les hôtes maintiennent les informations d'état de TCP associées aux connexions pendant de longues périodes. La Section 6 discute des implications pour la sécurité de longues valeurs de temporisation.

Pour protéger contre ces effets, les mises en œuvre DOIVENT imposer des limites aux valeurs de temporisation d'utilisateur qu'elles acceptent et utilisent. Le reste de ce paragraphe décrit un schéma RECOMMANDÉ pour limiter les temporisations d'utilisateur de TCP sur la base de limites supérieures et inférieures.

Dans le schéma RECOMMANDÉ, et quand CHANGEABLE est vrai, chaque extrémité DEVRAIT calculer la temporisation d'utilisateur locale pour une connexion selon la formule suivante :

USER_TIMEOUT = min(U_LIMIT, max(ADV_UTO, REMOTE_UTO, L_LIMIT))

Chaque champ est à interpréter comme suit :

USER_TIMEOUT : valeur de temporisation d'utilisateur à adopter par le TCP local pour cette connexion.

U_LIMIT : limite supérieure actuelle imposée à la temporisation d'utilisateur d'une connexion par l'hôte local.

ADV_UTO : temporisation d'utilisateur annoncée à l'homologue TCP distant dans une option User Timeout TCP.

REMOTE_UTO : dernière valeur de temporisation d'utilisateur reçue de l'autre extrémité d'une option User Timeout TCP.

L_LIMIT : limite inférieure actuelle imposée à la temporisation d'utilisateur d'une connexion par l'hôte local.

La formule RECOMMANDÉE résulte en le maximum des deux valeurs annoncées, ajustées pour les limites supérieure et inférieure configurées, à adopter pour la temporisation d'utilisateur de la connexion aux deux extrémités. La raison de cela est que le choix du maximum des deux valeurs va laisser la connexion survivre sur de plus longues périodes sans connexité de bout en bout. Si l'extrémité qui a annoncé la plus faible des deux valeurs de temporisation d'utilisateur l'a fait pour réduire la quantité d'informations d'état TCP qui doit être conservée sur l'hôte, elle peut clore ou interrompre la connexion quand elle le veut.

On notera que les deux points d'extrémité de la connexion ne vont pas nécessairement adopter la même temporisation d'utilisateur.

Appliquer une limite inférieure (L_LIMIT) empêche les connexions de clore à cause de conditions transitoires du réseau, incluant de l'encombrement temporaire, des transferts de mobilité, et des instabilités d'acheminement.

Une limite supérieure (U_LIMIT) peut réduire les effets d'une attaque en épuisement de ressources. La Section 6 discute les détails de ces attaques.

Noter que ces limites PEUVENT être spécifiées dans des constantes au niveau du système ou à une autre granularité, comme par hôte, par utilisateur, par interface sortante, ou même par connexion. De plus, ces limites n'ont pas besoin d'être statiques. Par exemple, elles PEUVENT être fonction de l'utilisation des ressources du système ou de l'état d'attaque et pourraient être adaptées de façon dynamique.

La RFC d'exigences pour les hôtes [RFC1122] n'impose aucune limite à la longueur de la temporisation d'utilisateur. Cependant, elle recommande un intervalle d'au moins 100 secondes. Par conséquent, la limite inférieure (L_LIMIT) DEVRAIT être réglée à au moins 100 secondes quand on suit le schéma RECOMMANDÉ décrit dans cette section. Adopter une temporisation d'utilisateur plus petite que la temporisation de retransmission actuelle (RTO) pour la connexion causera probablement l'interruption de la connexion sans nécessité. Donc, la limite inférieure (L_LIMIT) DOIT être supérieure à la temporisation de retransmission courante (RTO) pour la connexion. On notera qu'une limite supérieure peut être imposée au RTO, pourvu qu'il fasse au moins 60 secondes [RFC2988].

 	3.2	Fiabilité de l'option UTO
L'option TCP User Timeout est une option TCP facultative qui ne change pas le traitement des segments suivants. À la différence des autres options TCP, elle n'a pas besoin d'être échangée de façon fiable. Par conséquent, la spécification ne définit pas de prise de contact de fiabilité pour les échanges d'option UTO. Quand un segment qui porte une option UTO est perdu, l'autre extrémité va simplement ne pas avoir l'opportunité de mettre à jour sa temporisation d'utilisateur locale.

Les mises en œuvre PEUVENT utiliser des mécanismes locaux pour améliorer la fiabilité de livraison, comme en retransmettant une option UTO quand elles retransmettent un segment qui la portait à l'origine, ou en "rattachant" l'option à un octet dans le flux et en retransmettant l'option chaque fois que cet octet ou son ACK est retransmis.

Il est important de noter que bien que ces mécanismes puissent améliorer la fiabilité de transmission pour l'option UTO, ils ne garantissent pas la livraison (une prise de contact en trois phases serait nécessaire pour cela). Par conséquent, les mises en œuvre NE DOIVENT PAS supposer que les options UTO sont transmises de façon fiable.

 	3.3	Format d'option
L'envoi d'une option TCP User Timeout informe l'autre extrémité de la connexion de la temporisation d'utilisateur locale actuelle et suggère que l'autre extrémité adapte sa temporisation d'utilisateur en conséquence. La valeur de la temporisation d'utilisateur incluse dans une option UTO contient la valeur de ADV_UTO dont l'adoption est attendue pour le paramètre USER TIMEOUT de TCP durant les états synchronisés d'une connexion (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, ou LAST-ACK). Les connexions dans d'autres états DOIVENT utiliser les valeurs de temporisation par défaut définies dans les [RFC0793] et [RFC1122].

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 28   | Longueur = 4  |G| Temporisation d'utilisateur |
+---------------+---------------+-+-------------+---------------+

(Une marque numérotée représente un bit.)

Figure 1 : Format de l'option TCP User Timeout

La Figure 1 montre le format de l'option TCP User Timeout. Elle contient les champs suivants :

Type (8 bits) : il DOIT être 28, c'est-à-dire, le numéro d'ooption TCP [RFC0793] alloué par l'IANA (Section 7).

Longueur (8 bits) : longueur de l'option TCP en octets [RFC0793] ; sa valeur DOIT être 4.

Granularité (1 bit) : le bit de granularité indique la granularité du champ "Temporisation d'utilisateur". Établi (G = 1) l'intervalle dans le champ "Temporisation d'utilisateur" DOIT être interprété en minutes. Autrement (G = 0) l'intervalle dans le champ "Temporisation d'utilisateur" DOIT être interprété en secondes.

Temporisation d'utilisateur (15 bits) : spécifie la suggestion de temporisation d'utilisateur pour cette connexion. Elle DOIT être interprétée comme un entier non signé de 15 bits. La granularité de la temporisation (minutes ou secondes) dépend du champ "G".

 	3.4	Valeurs d'option réservées
Une option TCP User Timeout avec un champ "Temporisation d'utilisateur" de zéro et un bit "Granularité de minutes (1) ou secondes (0) est réservé pour une utilisation future. Les mises en œuvre actuelles de TCP NE DOIVENT PAS l'envoyer et DOIVENT l'ignorer à réception.

 	4.	Questions d'interopérabilité

Cette section discute les questions d'interopérabilité relatives à l'introduction de l'option TCP User Timeout.

 	4.1	Boîtiers de médiation
Une mise en œuvre de TCP qui ne prend pas en charge l'option TCP User Timeout DOIT l'ignorer en silence [RFC1122], assurant donc l'interopérabilité. Dans une étude des effets des boîtiers de médiation sur les protocoles de transport, Medina et autres ont montré que la vaste majorité des piles TCP modernes traitent correctement les options TCP inconnues [MEDINA]. Dans cette étude, 3 % des connexions ont échoué quand une option TCP inconnue apparaissait au milieu d'une connexion. Parce que le nombre de défaillances causées par des options inconnues est faible et qu'elles résultent de mises en œuvre incorrectes de piles TCP qui violent les exigences existantes d'ignorer les options inconnues, elles n'appellent pas de mesures particulières. Donc, le présent document ne définit pas de mécanisme pour négocier la prise en charge de l'option TCP User Timeout durant la prise de contact en trois phases.

Les mises en œuvre peuvent vouloir échanger des options UTO sur les tout premiers segments de données après la prise de contact en trois phases pour déterminer si de tels boîtiers de médiation existent sur le chemin. Quand des segments portant des options UTO sont perdus de façon persistante, une mise en œuvre devrait désactiver l'utilisation de UTO pour la connexion. Quand la connexion elle-même est réinitialisée, une mise en œuvre peut être capable de rétablir de façon transparente une autre instance de connexion qui n'utilise pas UTO avant que des données d'application aient été échangées avec succès.

Les pare-feu à états pleins font généralement expirer l'état de connexion après une période d'inactivité. Si un tel pare-feu existe le long du chemin, il peut clore ou interrompre les connexions sans considération de l'utilisation de l'option TCP User Timeout. À l'avenir, de tels pare-feu pourraient apprendre à analyser l'option TCP User Timeout dans les segments TCP non chiffrés et adapter en conséquence la gestion de l'état de connexion.

 	4.2	Maintien en vie TCP
Certaines mises en œuvre de TCP, comme celles des systèmes BSD, utilisent une politique d'interruption différente pour le maintien en vie de TCP que pour les données d'utilisateur. Donc, le mécanisme de maintien en vie de TCP pourrait interrompre une connexion qui aurait autrement survécu à la période transitoire sans connexité. Donc, si une connexion qui permet les maintiens en vie utilise aussi l'option TCP User Timeout, alors le temporisateur de maintien en vie DOIT être réglé à une valeur supérieurs à celle du USER TIMEOUT adopté.

 	5.	Considérations de programmation et de gestion

La spécification de l'IETF pour TCP [RFC0793] inclut une simple interface de programmation d'application (API, Application Programming Interface) abstraite. De même, l'API pour l'extension UTO de la Section 3 reste abstraite. Les mises en œuvre de TCP fournissent cependant généralement des API plus complexes et riches en caractéristiques. L'API "prise" qui est à l'origine du BSD Unix et est maintenant normalisée par POSIX est un tel exemple [POSIX]. On s'attend à ce que les mises en œuvre de TCP qui choisissent d'inclure l'extension UTO étendent leur API pour permettre aux applications d'utiliser et configurer ses paramètres.

Les objets de MIB définis dans les [RFC4022] et [RFC4898] permettent la gestion des connexions TCP. On s'attend à ce que des révisions de ces documents incluent des définitions d'objets pour gérer l'extension UTO définie dans ce document.

 	6.	Considérations sur la sécurité

Le rallongement des temporisations d'utilisateur a des implications de sécurité évidentes. Des attaques par inondation causent un déni de service en forçant les serveurs à engager des ressources pour maintenir l'état des connexions éliminées. Cependant, les mises en œuvre de TCP ne deviennent pas plus vulnérables à une simple inondation de SYN par la mise en œuvre de l'option TCP User Timeout, parce que les temporisations d'utilisateur échangées durant la prise de contact affectent seulement les états synchronisés (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK) que de simples inondations de SYN n'atteignent jamais.

Cependant, quand un attaquant achève la prise de contact en trois phases de ses connexions éliminées, il peut amplifier les effets d'une attaque en épuisement de ressources parce que le serveur attaqué doit maintenir l'état de connexion associé aux connexions éliminées pour de plus longues durées. Parce que l'état de connexion est gardé plus longtemps, un trafic d'attaque à fréquence inférieure, qui peut être plus difficile à détecter, peut déjà exacerber l'épuisement de ressources.

Plusieurs approches peuvent aider à atténuer ce problème. D'abord, les mises en œuvre peuvent exiger une authentification préalable de l'homologue, par exemple, en utilisant IPsec [RFC4301] ou TCP-MD5 [RFC2385], avant d'accepter de longues temporisations d'utilisateur pour les connexions de l'homologue. (Les mises en œuvre qui décident d'utiliser TCP-MD5 pour cela sont encouragées à surveiller le développement de TCP-AO [RFC5925], son successeur désigné, et à se mettre à jour quand il sera publié comme RFC.) Une approche similaire est pour qu'un hôte ne commence à accepter de longues temporisations d'utilisateur pour une connexion établie qu'après que s'est produite l'authentification dans la bande, par exemple, après qu'une prise de contact TLS a réussi sur la connexion [RFC5246]. Bien que ces solutions soient indiscutablement les plus complètes, elles dépendent de mécanismes externes pour établir une relation de confiance.

Une seconde solution de remplacement qui ne dépend pas de mécanismes externes serait d'introduire une limite par homologue au nombre de connexions qui peuvent utiliser des temporisations d'utilisateur accrues. Plusieurs variantes de cette approche sont possibles, comme de fixer des limites ou de raccourcir les temporisations d'utilisateur acceptées avec un nombre croissant de connexions. Bien que cette solution de remplacement n'élimine pas les attaques en épuisement de ressources provenant d'un seul homologue, elle peut limiter leurs effets. Réduire le nombre de connexions à fort UTO que prend en charge un serveur en face d'une attaque transforme cette attaque en un déni de service contre le service de connexions à fort UTO.

Des limites par homologue ne peuvent pas protéger contre des attaques de déni de service distribuées, où plusieurs clients coordonnent une attaque d'épuisement de ressources qui utilise de longues temporisations d'utilisateur. Pour protéger contre de telles attaques, les mises en œuvre de TCP pourraient réduire la durée des temporisations d'utilisateur acceptées avec une utilisation de ressources croissante.

Les mises en œuvre de TCP attaquées peuvent être forcées de délester en réinitialisant les connexions établies. Des heuristiques de délestage, comme de réinitialiser d'abord les connections avec de longues périodes d'inactivité, peuvent affecter négativement le service pour des homologues de confiance connectés de façon intermittente qui ont suggéré de longues temporisations d'utilisateur. Par ailleurs, réinitialiser des connexions avec des homologues qui ne sont pas de confiance qui utilisent de longues temporisations d'utilisateur peut être efficace. En général, utiliser le niveau de confiance de l'homologue comme paramètre durant le processus de décision de délestage peut être utile. Noter que si TCP a besoin de clore ou interrompre des connexions avec une longue option TCP User Timeout pour un délestage de charge, ces connexions ne sont pas pires fermées que sans l'option.

Finalement, des limites supérieures et inférieures aux temporisations d'utilisateur, discutées au paragraphe 3.1, peuvent être un outil efficace pour limiter l'impact de ces sortes d'attaques.

 	7.	Considérations relatives à l'IANA

Cette section doit être interprétée conformément à la [RFC5226].

Le présent document ne définit aucun nouvel espace de noms. L'IANA a alloué un nouveau numéro d'option TCP de 8 bits (28) pour l'option UTO dans le registre "Numéros de type d'option TCP" tenu à http://www.iana.org.

 	8.	Remerciements

Les personnes suivantes ont amélioré ce document par des suggestions pertinentes : Mark Allman, Caitlin Bestler, David Borman, Bob Braden, Scott Brim, Marcus Brunner, Wesley Eddy, Gorry Fairhurst, Abolade Gbadegesin, Ted Faber, Guillermo Gont, Tom Henderson, Joseph Ishac, Jeremy Harris, Alfred Hoenes, Phil Karn, Michael Kerrisk, Dan Krejsa, Jamshid Mahdavi, Kostas Pentikousis, Juergen Quittek, Anantha Ramaiah, Joe Touch, Stefan Schmid, Simon Schuetz, Tim Shepard, et Martin Stiemerling.

Lars Eggert est partiellement financé par [TRILOGY], un projet de recherche soutenu par la Commission Européenne dans son septième programme cadre.

Fernando Gont souhaite remercier le Secrétariat de l'extension universitaire de la Universidad Tecnologica Nacional et de la Universidad Tecnologica Nacional/Facultad Regional Haedo qui l'a soutenu dans ce travail.

 	9.	Références
 	9.1	Références normatives

[RFC0793]	J. Postel (éd.), "Protocole de commande de transmission – Spécification du protocole du programme Internet DARPA", STD 7,  DOI 10.17487/RFC0793, septembre 1981. (Remplacée par 9293)

[RFC1122]	R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, DOI 10.17487/RFC1122, octobre 1989. (MàJ par RFC6633, 8029, 9293 )

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. (MàJ par RFC8174)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

 	9.2	Références pour information

[MEDINA]	Medina, A., Allman, M., and S. Floyd, "Measuring Interactions Between Transport Protocols and Middleboxes", Proc. 4th ACM SIGCOMM/USENIX Conference on Internet Measurement, octobre 2004.

[POSIX]	IEEE Std. 1003.1-2001, "Standard for Information Technology - Portable Operating System Interface (POSIX)", Open Group Technical Standard: Base Specifications Issue 6, ISO/IEC 9945:2002, décembre 2001.

[RFC2385]	A. Heffernan, "Protection des sessions de BGP via l'option de signature MD5 de TCP", août 1998. (P.S. ; MàJ par la RFC6691) ; remplacée par RFC5925)

[RFC2988]	V. Paxson, M. Allman, "Calcul du temporisateur de retransmission de TCP", novembre 2000. (P.S.)(Obs., voir RFC6298)

[RFC3344]	C. Perkins, éd., "Prise en charge de la mobilité IP pour IPv4", août 2002. (Obsolète, voir RFC5944) (P.S.)

[RFC4022]	R. Raghunarayan, éd., "Base de données d'informations de gestion pour le protocole de contrôle de transmission (TCP)", mars 2005. (Remplace RFC2452, RFC2012) (P.S.)

[RFC4301]	S. Kent et K. Seo, "Architecture de sécurité pour le protocole Internet", DOI 10.17487/RFC4301, décembre 2005. (P.S.) (Remplace la RFC2401)

[RFC4423]	R. Moskowitz, P. Nikander, "Architecture du protocole d'identité d'hôte (HIP)", mai 2006. (Info. ; remplacée par 9063)

[RFC4898]	M. Mathis et autres, "MIB de statistiques TCP étendues", mai 2007. (P.S.)

[RFC4987]	W. Eddy, "Attaques par inondation de segment SYN contre TCP et contre-mesures courantes",  DOI 10.17487/RFC4987, août 2007. (Information)

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

[RFC5925]	J. Touch, A. Mankin, R. Bonica, "Option Authentification de TCP",  DOI 10.17487/RFC5925, juin 2010. (Remplace RFC2385). (P. S.)

[SOLARIS]	Sun Microsystems, "Solaris Tunable Parameters Reference Manual", Part No. 806-7009-10, 2002.

[TCP_MOB]	Eddy, W., "Mobility Support For TCP", Travail en cours, avril 2004.

[TRILOGY]	"Trilogy Project", <http://www.trilogy-project.org/>.

 	Adresse des auteurs

Lars Eggert	Fernando Gont	
Nokia Research Center	Universidad Tecnologica Nacional / Facultad Regional Haedo	
P.O. Box 407	Evaristo Carriego 2644	
Nokia Group  00045	Haedo, Provincia de Buenos Aires  1706	
Finland	Argentina	
téléphone : +358 50 48 24461	téléphone : +54 11 4650 8472	
mél : lars.eggert@nokia.com	mél : fernando@gont.com.ar	
URI : http://research.nokia.com/people/lars_eggert/	URI : http://www.gont.com.ar/