Il y avait belle lurette que les messages
ICMP « Répression de la source »
(Source Quench) n'étaient plus utilisés. Ces
messages devaient servir, à l'origine, à signaler à un émetteur qu'il
exagérait et qu'il devrait ralentir l'envoi de données. Divers
problèmes, notamment de sécurité, font que ces messages sont désormais
ignorés par toutes les mises en œuvre de
TCP/IP. Mais cet abandon de fait n'avait jamais
été documenté. Voilà qui est fait, ce marque donc
l'abandon officiel de la répression de la source.
À l'origine, cette répression (quench) avait été
normalisée dans le RFC sur
ICMP pour IPv4, le . De type 4 et de code 0, le message
Source Quench était censé limiter la
congestion en disant à l'émetteur qu'un
récepteur n'arrivait plus à suivre. Inefficace et injuste, le
Source Quench n'a jamais été très utilisé. Les
routeurs ont
officiellement arrêté de s'en servir avec le , dès 1995. Ce RFC notait déjà
les limites et problèmes du Source Quench (dans sa
section 4.3.3.3, qui fournissait des références).
En outre, les messages Source Quench, n'étant
pas authentifiés, posaient un gros problème de sécurité : un méchant
pouvait générer de faux messages pour réduire le débit de son ennemi,
comme expliqué dans le (et la section 8
de notre RFC). C'est d'ailleurs à cause de cela que des
IDS comme Snort couinent
lorsqu'ils voient passer des messages de répression de la source (voir
Anderson, D., Fong, M., et A. Valdes, « Heterogeneous
Sensor Correlation: A Case Study of Live Traffic
Analysis », Proceedings of the 3rd Annual IEEE Information
Assurance Workshop New York, NY, USA, 2002).
Restaient les
protocoles de transport. Le
disait dans sa section 4.2.3.9 que les
machines terminales devaient réagir aux
Source Quench en diminuant le débit émis. La
méthode recommandée pour TCP était de revenir au démarrage en douceur
().
De fait, le problème est réglé depuis longtemps, comme le
documentait le : les mises en
œuvre de TCP et autres protocoles de
transport ignorent les messages Source Quench
depuis au moins 2005, ou pas . L'annexe A de
notre fait le tour des implémentation TCP/IP et note
que Linux a commencé à ignorer ces messages en
2004, FreeBSD,
NetBSD et Solaris depuis
2005, etc. Voici par exemple ce que fait NetBSD (fichier sys/netinet/tcp_subr.c, routine tcp_ctlinput() :
if (cmd == PRC_QUENCH)
/*
* Don't honor ICMP Source Quench messages meant for
* TCP connections.
*/
return NULL;
Bref, ce RFC ne fait que documenter l'état des choses déjà existant.
En outre, ces messages Source Quench
sont largement filtrés et ont donc peu de chances d'atteindre les
machines qui émettent les données. Une étude de
1994 (Floyd, S., « TCP and Explicit
Congestion Notification », ACM CCR Volume 24, Issue 5) notait déjà qu'on trouvait très peu de
tels messages dans la nature. À la place, les routeurs sont censés
utiliser ECN () et (même si le
RFC ne le rappelle pas), les machines terminales doivent de toute
façon réagir aux pertes de paquets en ralentissant leur émission ().
Donc, le Source Quench est désormais
officiellement abandonné. La section 3 de notre RFC modifie le en demandant aux
machines terminales de ne pas émettre de tels messages et d'ignorer
ceux qu'elles recevraient. La section 4 fait de même pour les
routeurs. La section 9 demande à l'IANA de
marquer ces messages comme abandonnés dans le registre
ICMP.
Il n'y avait pas de règle précise dans le passé pour d'autres
protocoles de transport comme
UDP ou SCTP. Les sections
5 et 6 de notre RFC leur applique la même règle : il faut ignorer
complètement les messages de répression de la source qu'on pourrait recevoir.
Ah, et puis quelqu'un avait proposé une utilisation des messages
Source Quench dans le . Suivant
l'idée générale d'abandonner ces messages, la mise en œuvre de
ce RFC est donc désormais déconseillée (cf. section 7).
De toute façon, le problème aurait disparu avec
IPv4 : IPv6, lui, n'a
jamais eu de message Source Quench ().