Mon blog

C'était un RFC de récapitulation. Il ne normalisait rien de nouveau mais dressait une liste commentée des RFC dont la connaissance est indispendable, ou simplement utile, au programmeur qui met en œuvre TCP. Il a depuis été remplacé par le RFC 7414.

Depuis sa normalisation, il y a exactement un quart de siècle (dans le RFC 793), TCP a complètement remplacé NCP. TCP est un des grands succès de l'Internet : quasiment toutes les applications Internet s'appuient sur ce protocole.

Mais le RFC normatif, le RFC 793, quoique toujours valable, est bien vieux et beaucoup de choses ont été ajoutée ou retirées à TCP depuis. Comme pour beaucoup d'autres protocoles Internet (par exemple le DNS), TCP met donc le programmeur en face d'une rude tâche : avant de commencer à coder, il doit d'abord dresser la liste de tous les RFC dont il aura besoin. C'est cette tâche que lui épargne notre RFC en dressant cette liste.

Par exemple, le document original ne contient rien sur le contrôle de congestion, qui ne sera décrit que dans le RFC 2001. Ce RFC (ou plus exactement son successeur, le RFC 5681) fait désormais partie de ceux qu'il faut lire, ainsi que le RFC 1323 qui décrit plusieurs extensions nécessaires pour tirer des performances élevées, ou bien le RFC 3168 qui normalise ECN.

La sécurité ayant bien plus d'importance aujourd'hui, d'autres RFC décrivent comment se défendre contre certaines vulnérabilités par exemple la lecture du RFC 6528 est indispensable pour empêcher un attaquant d'insérer des paquets dans une session TCP existante.

D'autres extensions sont moins consensuelles et restent plutôt expérimentales à ce jour comme l'algorithme Eifel du RFC 3522.

Enfin certaines extensions ont été abandonnées, l'expérience ayant montré leur inutilité ou leur nocivité. C'est ainsi que la proposition du RFC 1146 de tenter de nouveaux moyens de calcul de la somme de contrôle n'a pas pris.

Le protocole T/TCP, normalisé dans le RFC 1644, aurait permis de diminuer nettement la durée des connexions courtes, celles où on échange peu de données (beaucoup de connexions HTTP sont dans ce cas). Promu par des experts comme Stevens, implémenté dans des systèmes comme FreeBSD (option MSG_EOF de sendto), il a été remisé au grenier après que des analyses plus poussées aient montré ses failles de sécurité (il facilite l'utilisation de TCP avec usurpation d'adresses IP).

Les RFC de ces extensions abandonnées ont été reclassifiés comme « intérêt historique seulement » dans le RFC 6247.

Notre RFC décrit ensuite les RFC qui s'appliquent à certains environnements difficiles comme les lignes satellite qui font l'objet des RFC 2757 et RFC 2760 ou les lignes fortement asymétriques, comme le sont les lignes ADSL (traitées dans le RFC 3449).

De nombreux autres cas sont ensuite traitées dans notre RFC. Notre implémenteur n'a pas fini de tout lire !

La section 7 couvre enfin un cas délicat : les extensions à TCP qui, bien que largement utilisées, n'ont jamais fait l'objet d'un RFC ni même, souvent, d'une description formelle.

C'est le cas par exemple des syncookies, option indispensable sans laquelle un serveur Internet peut être mis à genoux très vite par une attaque SYN flood pour laquelle il n'y a même pas besoin de développements spécifiques, l'outil hping suffisant à l'attaquant. Ces petits gâteaux n'ont jamais été normalisés.

Voilà, rappelez-vous qu'un tel travail est forcément temporaire, de nouveaux RFC apparaissent, des idées qui semblaient bonnes sont abandonnées, et il faut donc refaire ce catalogue de temps en temps. Notre RFC est dépassé et la version actuelle est dans le RFC 7414.