http://www.linux-france.org/prj/inetdoc/securite/tutoriel/tutoriel.securite.destruction.dos.html
lis "udp flood"
De la même manière que pour le SYN flooding, l'attaquant envoie un grand nombre de requêtes UDP sur une machine. Le trafic UDP étant prioritaire sur le trafic TCP, ce type d'attaque peut vite troubler et saturer le trafic transitant sur le réseau.
Franchement, je n'appelle pas celà une référence
L'UDP n'a rien de prioritaire et rien ne le défini comme tel dans les 'normes' IETF. Si vous trouvez la phrase dans ces normes qui me prouve le contraire, je m'incline (mais je ne risque rien
)
Jusqu'à il y a encore pas si longtemps que celà, il n'existait pas de modèle de gestion de la congestion gérant UDP au niveau des routeurs, comme il existe depuis longtemps des modèles comme RED ou dérivés qui ne s'appliquent malheureusement qu'à TCP. C'est donc vrai qu'alors UDP passait mieux encore les routeurs même en cas de saturation des lignes, ce qui d'ailleurs avait effet de diminuer d'autant la bande passante dispo pour tcp qui saturait alors encore plus.
A ce moment là, la seule manière d'éviter que UDP devienne 'de fait' (et non pas par 'norme') prioritaire était de le rendre physiquement moins prioritaire que tcp pour eviter cet effet, et beaucoup ont utilisé ce moyen de limiter la bp dispo pour udp. Donc beaucoup de routeurs sont configurés pour 'virer' d'abord l'UDP pour éviter ce phénomène.
Maintenant que UDP revient en force dans des applis de transfert (RTP par exemple) il a fallu mettre en place des mécanismes à la 'RED de TCP' pour répartir convenablement la charge entre tcp et udp. MAIS celà n'est possible que pour les protocoles de couches hautes sur udp gérant par eux même une gestion de la session udp (contrôle qualité, gestion des reprises, ...) et seuls les protocoles 'normalisés' et effectivement dotés de ces mécanismes sont potentiellement aptent à être géré par les routeurs pour la gestion intelligente de la bd.
Comme donc seuls ces protocoles 'normalisés' sous udp (estampillés 'IETF', RFC xxxx) sont potentiellement 'gérables' par les mécanismes de gestion de congestion udp, tout ce qui n'est pas 'gérable' se voit alloué très certainement une priorité minimale pour ne pas reproduire le phénomène de 'priorité de fait' et entraver les flots udp et tcp gérables. Donc des protocoles 'persos' comme ceux utilisés en udp en p2p, ou le test de transfert iperf seront de moins en moins efficaces que leurs équivalents en tcp (la gestion de congestion étant intrinsèque à tcp et pas au protocole de niveau supérieur), à moins que devienne normalisés ces 'protocoles' (je doute de voir un jour une RFC sur le protocole P2P de emule, de bittorrent, ...)
Seuls les équipements vieillissants pas assez puissant ne pouvant être mis à jour pour gérer équitablement udp vis à vis de tcp peuvent encore permettre à tout udp d'être plus 'efficace', mais nul doute que la plupard intègreront d'ici peu un mécanisme minimal de priorisation des flux udp en fonction de ce qui est 'porté' au dessus (détecter un flux RDP, c'est une simple histoire de test de quelques octets et ports particuliers dans les paquets), donc même ces vieux routeurs vont vite limiter en udp tout ce qui n'est pas normalisé, et appliquer alors une priorité ultra faible à ces flux 'inconnus' pour les jeter en premier.
Actus fibre SFR