OpenBSD v3.8 va sortir bientot et je lis
(http://securityfocus.com/columnists/361)
qu'ils ont particulierement travaille sur
la securistaion d'ICMPv4:
. blind connection-reset attacks, car openBSD
verifie que chaque icmp correspond a une
connection en cours avant de l'accepter.
. blind throughput-reduction attacks, base
sur de l'icmp source quench et openBSD droppe
par defaut tout le source quench (qui n'est
de toute facon pas utilise)
. blind-performance degrading attacks, base
sur des envois de "fragmentation needed and
DF bit set", et openBSD trace de son cote
les MTU acceptes precedemment.
Existe t'il un papier du meme genre sur
ICMPv6? (openBSD ou pas).
(Tout pointeur autre que la RFC serait
bienvenu)
Merci
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Mehdi BENKIR
wrote:
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP. Puisqu'il n'existe aucun protocole par lequel un host peut informer son routeur de l'éventuelle existence d'une congestion signalée au niveau TCP, mieux vaut que les routeurs ou intermédiaires s'informent d'eux-mêmes l'un l'autre. Mais il est vrai que personne n'est obligé d'utiliser OpenBSD comme routeur :-)
Existe t'il un papier du meme genre sur ICMPv6? (openBSD ou pas).
(Tout pointeur autre que la RFC serait bienvenu) Merci
Pourtant, le RFC 792 fournit quelques précisions intéressantes sur le rôle d'ICMP :
"Le protocole Internet n'est pas, dans sa définition, absolument fiable. Le but de ces messages de contrôle est de pouvoir signaler l'apparition d'un cas d'erreur dans l'environnement IP, pas de rendre IP fiable. Aucune garantie que le datagramme soit acheminé ni qu'un message de contrôle soit retourné, de peut être donnée. Certains datagrammes pourront se perdre dans le réseau sans qu'aucun message de contrôle ne le signale. Les protocoles de niveau supérieur s'appuyant sur une couche IP devront implémenter leurs propres mécanismes de contrôle d'erreur et de retransmission si leur objet nécessite un circuit de communication sécurisé."
octane@alinto.com wrote:
.. blind throughput-reduction attacks, base
sur de l'icmp source quench et openBSD droppe
par defaut tout le source quench (qui n'est
de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre
équipements intermédiaires à deux autres établissant une connection TCP.
Puisqu'il n'existe aucun protocole par lequel un host peut informer
son routeur de l'éventuelle existence d'une congestion signalée au
niveau TCP, mieux vaut que les routeurs ou intermédiaires s'informent
d'eux-mêmes l'un l'autre. Mais il est vrai que personne n'est obligé
d'utiliser OpenBSD comme routeur :-)
Existe t'il un papier du meme genre sur
ICMPv6? (openBSD ou pas).
(Tout pointeur autre que la RFC serait
bienvenu)
Merci
Pourtant, le RFC 792 fournit quelques précisions intéressantes sur le
rôle d'ICMP :
"Le protocole Internet n'est pas, dans sa définition, absolument fiable.
Le but de ces messages de contrôle est de pouvoir signaler l'apparition
d'un cas d'erreur dans l'environnement IP, pas de rendre IP fiable.
Aucune garantie que le datagramme soit acheminé ni qu'un message de
contrôle soit retourné, de peut être donnée. Certains datagrammes
pourront se perdre dans le réseau sans qu'aucun message de contrôle ne
le signale. Les protocoles de niveau supérieur s'appuyant sur une couche
IP devront implémenter leurs propres mécanismes de contrôle d'erreur et
de retransmission si leur objet nécessite un circuit de communication
sécurisé."
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP. Puisqu'il n'existe aucun protocole par lequel un host peut informer son routeur de l'éventuelle existence d'une congestion signalée au niveau TCP, mieux vaut que les routeurs ou intermédiaires s'informent d'eux-mêmes l'un l'autre. Mais il est vrai que personne n'est obligé d'utiliser OpenBSD comme routeur :-)
Existe t'il un papier du meme genre sur ICMPv6? (openBSD ou pas).
(Tout pointeur autre que la RFC serait bienvenu) Merci
Pourtant, le RFC 792 fournit quelques précisions intéressantes sur le rôle d'ICMP :
"Le protocole Internet n'est pas, dans sa définition, absolument fiable. Le but de ces messages de contrôle est de pouvoir signaler l'apparition d'un cas d'erreur dans l'environnement IP, pas de rendre IP fiable. Aucune garantie que le datagramme soit acheminé ni qu'un message de contrôle soit retourné, de peut être donnée. Certains datagrammes pourront se perdre dans le réseau sans qu'aucun message de contrôle ne le signale. Les protocoles de niveau supérieur s'appuyant sur une couche IP devront implémenter leurs propres mécanismes de contrôle d'erreur et de retransmission si leur objet nécessite un circuit de communication sécurisé."
Kevin Denis
Le 15-10-2005, Mehdi BENKIR a écrit :
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
ICMP source quench peut servir aussi a UDP. Dans ce cas, c'est a l'application au dessus d'UDP de traiter ou non l'information. Meme si, comme on le voit plus bas, ICMP type 4 n'a plus vraiment d'avenir.
Puisqu'il n'existe aucun protocole par lequel un host peut informer son routeur de l'éventuelle existence d'une congestion signalée au niveau TCP,
ECN ? RFC 3168
mieux vaut que les routeurs ou intermédiaires s'informent d'eux-mêmes l'un l'autre. Mais il est vrai que personne n'est obligé d'utiliser OpenBSD comme routeur :-)
Une RFC (1812? de memoire, je suis offline pour verifier) indique que
les routeurs ne doivent plus envoyer des sources quench. Dans la theorie, le source quench, c'est une bonne idee mais dans la pratique ca n'arrange pas grand chose. Donc les seuls a envoyer des source quench sont les hosts. Et suite au papier plus haut, les hotes n'envoient meme plus de source quench. Exit le source quench, alors. Les reseaux ne s'en sortent pas plus mal.
-- Kevin
Le 15-10-2005, Mehdi BENKIR <medhib142@hotmail.com> a écrit :
.. blind throughput-reduction attacks, base
sur de l'icmp source quench et openBSD droppe
par defaut tout le source quench (qui n'est
de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre
équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
ICMP source quench peut servir aussi a UDP. Dans ce cas, c'est a
l'application au dessus d'UDP de traiter ou non l'information. Meme
si, comme on le voit plus bas, ICMP type 4 n'a plus vraiment d'avenir.
Puisqu'il n'existe aucun protocole par lequel un host peut informer
son routeur de l'éventuelle existence d'une congestion signalée au
niveau TCP,
ECN ? RFC 3168
mieux vaut que les routeurs ou intermédiaires s'informent
d'eux-mêmes l'un l'autre. Mais il est vrai que personne n'est obligé
d'utiliser OpenBSD comme routeur :-)
Une RFC (1812? de memoire, je suis offline pour verifier) indique que
les routeurs ne doivent plus envoyer des sources quench.
Dans la theorie, le source quench, c'est une bonne idee mais dans
la pratique ca n'arrange pas grand chose. Donc les seuls a envoyer
des source quench sont les hosts. Et suite au papier plus haut,
les hotes n'envoient meme plus de source quench. Exit le source
quench, alors. Les reseaux ne s'en sortent pas plus mal.
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
ICMP source quench peut servir aussi a UDP. Dans ce cas, c'est a l'application au dessus d'UDP de traiter ou non l'information. Meme si, comme on le voit plus bas, ICMP type 4 n'a plus vraiment d'avenir.
Puisqu'il n'existe aucun protocole par lequel un host peut informer son routeur de l'éventuelle existence d'une congestion signalée au niveau TCP,
ECN ? RFC 3168
mieux vaut que les routeurs ou intermédiaires s'informent d'eux-mêmes l'un l'autre. Mais il est vrai que personne n'est obligé d'utiliser OpenBSD comme routeur :-)
Une RFC (1812? de memoire, je suis offline pour verifier) indique que
les routeurs ne doivent plus envoyer des sources quench. Dans la theorie, le source quench, c'est une bonne idee mais dans la pratique ca n'arrange pas grand chose. Donc les seuls a envoyer des source quench sont les hosts. Et suite au papier plus haut, les hotes n'envoient meme plus de source quench. Exit le source quench, alors. Les reseaux ne s'en sortent pas plus mal.
-- Kevin
Mehdi BENKIR
Kevin Denis wrote:
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
Je parlais de la communication entre routeurs : un routeur n'a aucune raison particulière d'accepter de devenir un node TCP. Par contre, l'intérêt d'un protocole de signalisation entre équipements intermédiaires est une autre question.
Une RFC (1812? de memoire, je suis offline pour verifier) indique que les routeurs ne doivent plus envoyer des sources quench.
Tu sais, il existe une RFC pour le mail en HTML, qui ne semble guère appréciée de la majorité des intéressés faisant un choix conscient. Après, chacun fait ses choix, mais, en théorie, au delà de l'inter-opérabilité, l'important est déjà que les différents choix puissent opérer les uns et les autres en partageant les mêmes tuyaux.
Dans la theorie, le source quench, c'est une bonne idee mais dans la pratique ca n'arrange pas grand chose.
Il est vrai que le choix de la plupart des administrateurs de firewall consiste à le filtrer, brisant ce qui peut exister et a la malchance de traverser leurs équipements.
Kevin Denis wrote:
.. blind throughput-reduction attacks, base
sur de l'icmp source quench et openBSD droppe
par defaut tout le source quench (qui n'est
de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre
équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
Je parlais de la communication entre routeurs : un routeur n'a aucune
raison particulière d'accepter de devenir un node TCP. Par contre,
l'intérêt d'un protocole de signalisation entre équipements
intermédiaires est une autre question.
Une RFC (1812? de memoire, je suis offline pour verifier) indique que
les routeurs ne doivent plus envoyer des sources quench.
Tu sais, il existe une RFC pour le mail en HTML, qui ne semble guère
appréciée de la majorité des intéressés faisant un choix conscient.
Après, chacun fait ses choix, mais, en théorie, au delà de
l'inter-opérabilité, l'important est déjà que les différents choix
puissent opérer les uns et les autres en partageant les mêmes tuyaux.
Dans la theorie, le source quench, c'est une bonne idee mais dans
la pratique ca n'arrange pas grand chose.
Il est vrai que le choix de la plupart des administrateurs de firewall
consiste à le filtrer, brisant ce qui peut exister et a la malchance de
traverser leurs équipements.
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
Je parlais de la communication entre routeurs : un routeur n'a aucune raison particulière d'accepter de devenir un node TCP. Par contre, l'intérêt d'un protocole de signalisation entre équipements intermédiaires est une autre question.
Une RFC (1812? de memoire, je suis offline pour verifier) indique que les routeurs ne doivent plus envoyer des sources quench.
Tu sais, il existe une RFC pour le mail en HTML, qui ne semble guère appréciée de la majorité des intéressés faisant un choix conscient. Après, chacun fait ses choix, mais, en théorie, au delà de l'inter-opérabilité, l'important est déjà que les différents choix puissent opérer les uns et les autres en partageant les mêmes tuyaux.
Dans la theorie, le source quench, c'est une bonne idee mais dans la pratique ca n'arrange pas grand chose.
Il est vrai que le choix de la plupart des administrateurs de firewall consiste à le filtrer, brisant ce qui peut exister et a la malchance de traverser leurs équipements.
Kevin Denis
Le 16-10-2005, Mehdi BENKIR a écrit :
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
Je parlais de la communication entre routeurs : un routeur n'a aucune raison particulière d'accepter de devenir un node TCP. Par contre, l'intérêt d'un protocole de signalisation entre équipements intermédiaires est une autre question.
Pour les routeurs, c'est la RFC 3168. Ni l'une ni l'autre n'utilise
le source quench.
Une RFC (1812? de memoire, je suis offline pour verifier) indique que les routeurs ne doivent plus envoyer des sources quench.
Tu sais, il existe une RFC pour le mail en HTML, qui ne semble guère appréciée de la majorité des intéressés faisant un choix conscient.
As tu lu cette RFC 1812?
Après, chacun fait ses choix, mais, en théorie, au delà de l'inter-opérabilité, l'important est déjà que les différents choix puissent opérer les uns et les autres en partageant les mêmes tuyaux.
Le source quench est categorise comme "injuste et inefficace".
Dans la theorie, le source quench, c'est une bonne idee mais dans la pratique ca n'arrange pas grand chose.
Il est vrai que le choix de la plupart des administrateurs de firewall consiste à le filtrer, brisant ce qui peut exister et a la malchance de traverser leurs équipements.
Ne soit pas si catastrophique. Ca ne brise rien, le source quench est obsolete et en voie de disparition.
Le gros probleme du source quench est qu'il permet des attaques par deni de service. Cf le draft: draft-gont-tcpm-icmp-attacks-04.txt ?
Face a un ICMP obsolete, qui ne joue pas son role et qui devient un vecteur potentiel d'attaque, quelle est l'attitude a prendre?
L'ICMP source quench est droppe par defaut dans linux depuis 2004 et les [Free|Net|open]BSD depuis 2005. -- Kevin
Le 16-10-2005, Mehdi BENKIR <medhib142@hotmail.com> a écrit :
.. blind throughput-reduction attacks, base
sur de l'icmp source quench et openBSD droppe
par defaut tout le source quench (qui n'est
de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre
équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
Je parlais de la communication entre routeurs : un routeur n'a aucune
raison particulière d'accepter de devenir un node TCP. Par contre,
l'intérêt d'un protocole de signalisation entre équipements
intermédiaires est une autre question.
Pour les routeurs, c'est la RFC 3168. Ni l'une ni l'autre n'utilise
le source quench.
Une RFC (1812? de memoire, je suis offline pour verifier) indique que
les routeurs ne doivent plus envoyer des sources quench.
Tu sais, il existe une RFC pour le mail en HTML, qui ne semble guère
appréciée de la majorité des intéressés faisant un choix conscient.
As tu lu cette RFC 1812?
Après, chacun fait ses choix, mais, en théorie, au delà de
l'inter-opérabilité, l'important est déjà que les différents choix
puissent opérer les uns et les autres en partageant les mêmes tuyaux.
Le source quench est categorise comme "injuste et inefficace".
Dans la theorie, le source quench, c'est une bonne idee mais dans
la pratique ca n'arrange pas grand chose.
Il est vrai que le choix de la plupart des administrateurs de firewall
consiste à le filtrer, brisant ce qui peut exister et a la malchance de
traverser leurs équipements.
Ne soit pas si catastrophique. Ca ne brise rien, le source quench est
obsolete et en voie de disparition.
Le gros probleme du source quench est qu'il permet des attaques par
deni de service. Cf le draft: draft-gont-tcpm-icmp-attacks-04.txt ?
Face a un ICMP obsolete, qui ne joue pas son role et qui devient
un vecteur potentiel d'attaque, quelle est l'attitude a prendre?
L'ICMP source quench est droppe par defaut dans linux depuis 2004 et
les [Free|Net|open]BSD depuis 2005.
--
Kevin
.. blind throughput-reduction attacks, base sur de l'icmp source quench et openBSD droppe par defaut tout le source quench (qui n'est de toute facon pas utilise)
Pourtant, le source-quench est le seul protocole à disposition entre équipements intermédiaires à deux autres établissant une connection TCP.
Pour TCP: RFC 2581
Je parlais de la communication entre routeurs : un routeur n'a aucune raison particulière d'accepter de devenir un node TCP. Par contre, l'intérêt d'un protocole de signalisation entre équipements intermédiaires est une autre question.
Pour les routeurs, c'est la RFC 3168. Ni l'une ni l'autre n'utilise
le source quench.
Une RFC (1812? de memoire, je suis offline pour verifier) indique que les routeurs ne doivent plus envoyer des sources quench.
Tu sais, il existe une RFC pour le mail en HTML, qui ne semble guère appréciée de la majorité des intéressés faisant un choix conscient.
As tu lu cette RFC 1812?
Après, chacun fait ses choix, mais, en théorie, au delà de l'inter-opérabilité, l'important est déjà que les différents choix puissent opérer les uns et les autres en partageant les mêmes tuyaux.
Le source quench est categorise comme "injuste et inefficace".
Dans la theorie, le source quench, c'est une bonne idee mais dans la pratique ca n'arrange pas grand chose.
Il est vrai que le choix de la plupart des administrateurs de firewall consiste à le filtrer, brisant ce qui peut exister et a la malchance de traverser leurs équipements.
Ne soit pas si catastrophique. Ca ne brise rien, le source quench est obsolete et en voie de disparition.
Le gros probleme du source quench est qu'il permet des attaques par deni de service. Cf le draft: draft-gont-tcpm-icmp-attacks-04.txt ?
Face a un ICMP obsolete, qui ne joue pas son role et qui devient un vecteur potentiel d'attaque, quelle est l'attitude a prendre?
L'ICMP source quench est droppe par defaut dans linux depuis 2004 et les [Free|Net|open]BSD depuis 2005. -- Kevin
Mehdi BENKIR
Pour les routeurs, c'est la RFC 3168. Ni l'une ni l'autre n'utilise le source quench.
Je t'invite à lire les paragraphes 1,2 et 3 et tout particulièrement la dernière phrase du troisième chapitre du point 6 de la RFC 3168. La contribution de Gont fait particulièrement allusion au problème du respect du protocole Source Quench en présence de services reposant sur la fiabilité de connexions TCP à très longue durée de vie, d'où mon rappel de la RFC 792 dans le premier message.
Bilan ? ECN adresse pour l'essentiel TCP. Et pour le reste ? Hé bien puisque le protocole public destiné à cette fin "pose problème", reste à se replier sur un protocole maison, lequel, par prudence, aurait grandement intérêt à se laisse encapsuler dans TCP, ce qui ne facilitera pas son décodage en situation intermédiaire sur un lien gros débit : mais ce n'est pas grave en soi, je l'admets, surtout pour une poignée de PCs.
As tu lu cette RFC 1812?
Oui. Quel point de cette RFC est sensé poser problème ? le 4.3.3.3 ? Bien. Quel est le problème ?
Sauf erreur de ma part, l'interprétation d'un protocole est la responsabilité de qui se déclare partementaire (client) ou de qui s'oblige (serveur). J'avoue ne pas bien imaginer en quoi l'existence d'un protocole obsolète que personne n'est contraint d'interpréter pose problème à qui que ce soit.
Face a un ICMP obsolete, qui ne joue pas son role et qui devient un vecteur potentiel d'attaque, quelle est l'attitude a prendre?
Quelle raison récemment révélée nécessite de changer l'existant ? La difficulté qu'éprouvaient de nombreux constructeurs à gérer ce protocole n'est pas nouvelle : la RFC 1812 la mentionnait déjà.
L'ICMP source quench est droppe par defaut dans linux depuis 2004 et les [Free|Net|open]BSD depuis 2005.
Puisque le comportement est configurable, quel intérêt y-a-t-il à retirer une option de configuration ? (du moins, si je comprends bien l'annonce du devteam).
Pour les routeurs, c'est la RFC 3168. Ni l'une ni l'autre n'utilise
le source quench.
Je t'invite à lire les paragraphes 1,2 et 3 et tout particulièrement la
dernière phrase du troisième chapitre du point 6 de la RFC 3168. La
contribution de Gont fait particulièrement allusion au problème du
respect du protocole Source Quench en présence de services reposant sur
la fiabilité de connexions TCP à très longue durée de vie, d'où mon
rappel de la RFC 792 dans le premier message.
Bilan ? ECN adresse pour l'essentiel TCP. Et pour le reste ? Hé bien
puisque le protocole public destiné à cette fin "pose problème", reste à
se replier sur un protocole maison, lequel, par prudence, aurait
grandement intérêt à se laisse encapsuler dans TCP, ce qui ne facilitera
pas son décodage en situation intermédiaire sur un lien gros débit :
mais ce n'est pas grave en soi, je l'admets, surtout pour une poignée de
PCs.
As tu lu cette RFC 1812?
Oui. Quel point de cette RFC est sensé poser problème ? le 4.3.3.3 ?
Bien. Quel est le problème ?
Sauf erreur de ma part, l'interprétation d'un protocole est la
responsabilité de qui se déclare partementaire (client) ou de qui
s'oblige (serveur). J'avoue ne pas bien imaginer en quoi l'existence
d'un protocole obsolète que personne n'est contraint d'interpréter pose
problème à qui que ce soit.
Face a un ICMP obsolete, qui ne joue pas son role et qui devient
un vecteur potentiel d'attaque, quelle est l'attitude a prendre?
Quelle raison récemment révélée nécessite de changer l'existant ? La
difficulté qu'éprouvaient de nombreux constructeurs à gérer ce protocole
n'est pas nouvelle : la RFC 1812 la mentionnait déjà.
L'ICMP source quench est droppe par defaut dans linux depuis 2004 et
les [Free|Net|open]BSD depuis 2005.
Puisque le comportement est configurable, quel intérêt y-a-t-il à
retirer une option de configuration ? (du moins, si je comprends bien
l'annonce du devteam).
Pour les routeurs, c'est la RFC 3168. Ni l'une ni l'autre n'utilise le source quench.
Je t'invite à lire les paragraphes 1,2 et 3 et tout particulièrement la dernière phrase du troisième chapitre du point 6 de la RFC 3168. La contribution de Gont fait particulièrement allusion au problème du respect du protocole Source Quench en présence de services reposant sur la fiabilité de connexions TCP à très longue durée de vie, d'où mon rappel de la RFC 792 dans le premier message.
Bilan ? ECN adresse pour l'essentiel TCP. Et pour le reste ? Hé bien puisque le protocole public destiné à cette fin "pose problème", reste à se replier sur un protocole maison, lequel, par prudence, aurait grandement intérêt à se laisse encapsuler dans TCP, ce qui ne facilitera pas son décodage en situation intermédiaire sur un lien gros débit : mais ce n'est pas grave en soi, je l'admets, surtout pour une poignée de PCs.
As tu lu cette RFC 1812?
Oui. Quel point de cette RFC est sensé poser problème ? le 4.3.3.3 ? Bien. Quel est le problème ?
Sauf erreur de ma part, l'interprétation d'un protocole est la responsabilité de qui se déclare partementaire (client) ou de qui s'oblige (serveur). J'avoue ne pas bien imaginer en quoi l'existence d'un protocole obsolète que personne n'est contraint d'interpréter pose problème à qui que ce soit.
Face a un ICMP obsolete, qui ne joue pas son role et qui devient un vecteur potentiel d'attaque, quelle est l'attitude a prendre?
Quelle raison récemment révélée nécessite de changer l'existant ? La difficulté qu'éprouvaient de nombreux constructeurs à gérer ce protocole n'est pas nouvelle : la RFC 1812 la mentionnait déjà.
L'ICMP source quench est droppe par defaut dans linux depuis 2004 et les [Free|Net|open]BSD depuis 2005.
Puisque le comportement est configurable, quel intérêt y-a-t-il à retirer une option de configuration ? (du moins, si je comprends bien l'annonce du devteam).
