L. Eggert (Nokia)F. Gont (UTN/FRH)March20092009-03-17
Le , qui normalise
TCP, prévoit un paramètre local
user timeout qui permet de régler la « patience » de
TCP. S'il n'arrive pas à échanger des données avec son partenaire
avant l'expiration de ce délai, TCP renonce et coupe la
connexion. Notre RFC étend l'utilité de ce paramètre, en permettant de
le communiquer au partenaire, pour qu'il soit prévenu de la patience
ou de l'impatience de celui avec qui il communique. On augmente ainsi
les chances des connexion TCP de survivre aux longues coupures ou, au
contraire, de détecter plus rapidement la coupure du réseau.
Ce paramètre user timeout peut être spécifié par
l'application qui utilise TCP (ceci-dit, je ne trouve pas l'option de
setsockopt qui permettrait de le faire sur tout
Unix ; d'après le RFC, Solaris a une telle option). Il vaut cinq minutes par défaut (section
3.8 du ). Mais il n'était jamais connu de
l'autre machine avec laquelle on est connecté en TCP. C'est ce que
change notre RFC qui permet de communiquer ce paramètre.
Cette communication se fait via le mécanisme
d'option de TCP, décrit dans la section 3.1 du
. La nouvelle option porte le nom d'UTO
(User Timeout Option) et est strictement indicative
: le TCP qui la reçoit peut parfaitement l'ignorer. S'il l'accepte, il
va ajuster son propre user timeout à la valeur
indiquée. Ainsi, TCP pourra, par exemple, survivre à de longues périodes de déconnexion, sans que le partenaire ne raccroche.
La section 1 fournit d'autres cas où cette option UTO est utile :
pour des mobiles utilisant une technique qui conserve l'identificateur
comme HIP () ou
Mobile-IP (), les périodes
pendant lesquelles le mobile n'a pas de connexion risquent d'être
longues. Le fait de garder l'identificateur (adresse IP ou
Host Identity) constant permet en théorie de garder
les sessions TCP lorsqu'on se déconnecte et se reconnecte mais, avant
l'option UTO, cela ne servait à rien puisque TCP coupait la connexion
qui lui semblait en panne.
De même, l'application peut dans certains cas connaître la durée
d'une déconnexion et utiliser UTO pour prévenir son partenaire (le RFC
cite l'exemple amusant d'une sonde spatiale qui
sait, grâce aux lois de la mécanique céleste,
qu'elle ne sera pas en vue de sa base pendant une longue période).
La section 3 définit rigoureusement la nouvelle option. Quatre
paramètres définissent le comportement du TCP local :
USER_TIMEOUT, qui existe déjà (mais n'est pas
réglable sur tous les systèmes d'exploitation, cf. sections 3.1 et 5),
ADV_UTO, la valeur de l'UTO communiquée au pair
(typiquement identique à USER_TIMEOUT), ENABLED qui indique si le pair doit être notifié
par la nouvelle option UTO et CHANGEABLE qui
indique si USER_TIMEOUT doit être ajusté en
fonction des notifications du pair (ou bien s'il doit être ignoré, ce
qui est permis).
La section 3.1 contient une discussion détaillée des « bonnes »
valeurs pour USER_TIMEOUT (notons que ce ne sera
pas forcément le même pour les deux pâirs). Le
donnait quelques recommandations à ce sujet (par exemple, les valeurs
inférieures à 100 s sont découragées). La 3.2 discute de la fiabilité
de la transmisson d'UTO (inexistante, comme toutes les options TCP ;
il ne faut donc pas tenir pour acquis qu'elle a été reçue par le
pair). Et 3.3 décrit le format concret de l'option : numéro 28
(enregistré dans le registre IANA), un
bit qui indique l'unité utilisée (minutes ou secondes) et 15 bits qui
contiennent la valeur elle-même.
La section 4 passe aux problèmes pratiques que peut rencontrer le
déploiement de l'option. Le RFC rappelle en section 3 que l'espace des options dans TCP est
limité (40 octets) et que l'ajout d'UTO peut nécessiter de renoncer à
certaines options. Il faut aussi dire que beaucoup de
pare-feux bogués rejettent tout paquet TCP
ayant des options (cf. Probing the
viability of TCP extensions)
et que celles-ci sont donc difficiles à utiliser en pratique. En
théorie, une implémentation de TCP qui ne connait pas cette option
devrait l'ignorer () et le RFC décrète que, bien
qu'il y aie quelques violations de cette règle (cf. Measuring interactions between transport protocols
and middleboxes), elles ne méritent pas
qu'on renonce à une option utile (section 4.1). Notez aussi qu'un
pare-feu à état a typiquement ses propres
délais de garde et peut donc couper une connexion sans tenir compte de
l'UTO annoncée (les pare-feux futurs tiendront peut-être compte de
cette option).
J'ai déjà mentionné la difficulté qu'il y a à changer la valeur de
USER_TIMEOUT. La section 5 revient sur cette
question de l'API mais ne fournit pas de
proposition de normalisation de l'API des prises.
Bien sûr, l'UTO introduit des problèmes de sécurité nouveaux,
discutés en section 6. Par exemple, un méchant pourrait spécifier de
très longs délais de garde, puis s'en aller pendant que sa victime
serait forcée de garder une connexion ouverte pendant de longues
minutes, malgré l'absence de trafic. Notre RFC propose des mécanismes
pour limiter les risques comme n'accepter les UTO qu'après
authentification IP (par exemple par IPsec), ou
bien seulement après que l'application aie indiqué à TCP qu'elle avait
réussi une authentification à son niveau, par exemple par
TLS. Sans authentification, TCP pourrait aussi
mettre des limites au délai de garde total d'un pair (s'il a ouvert
plusieurs connexions) et au délai de garde total (pour limiter les
risques dus aux dDoS).
Je n'ai pas trouvé tout de suite de trace de mises en œuvre de TCP qui
incluent cette option UTO mais, depuis, il y a cet article expérimental.