Stéphane Bortzmeyer a écrit 645 commentaires

Ben, le NAT protège contre des attaques très rares (attaques par connexion directe, comme du temps de SQL Slammer) et ne protège pas contre les attaques qui sont de loin les plus fréquentes aujourd'hui (attaques par charge utile). Donc, il sert à quoi ?

Bof, cette sécurité est largement illusoire. http://www.bortzmeyer.org/nat-et-securite.html

Sur ce point, le RFC 6092 (recommandations aux auteurs de boxes) est une bonne lecture http://www.bortzmeyer.org/6092.html

Tous les pays sont dans ce cas. La plupart des entreprises états-uniennes ne cherchent même pas dans la base des brevets chinois pour voir s'ils n'en enfreignent pas un.

La licence choisie par les développeurs d'Opus n'a aucune importance. Les brevets sont détenus par des tiers (comme Microsoft) et ceux-ci n'ont aucune raison de se sentir liés par une licence qu'ils n'ont pas écrite.

D'abord, la plupart des ces brevets sont illégaux en Europe. Donc, il suffit de ne pas voyager ou vendre aux USA ou en Chine (l'autre pays du brevet futile) pour être tranquille.

Ensuite, même aux USA, rien ne dit que ces brevets tiennent le coup devant un tribunal. Il suffit donc d'embaucher plusieurs avocats et de faire annuler ces brevets. Fastoche.

Sérieusement, l'IETF publie les revendications de brevet, elle n'évalue pas leur mérite.

Dans l'image Debian que j'ai testée (qui était l'image officielle il y a deux semaines), pas du tout d'IPv6, même pas en module.

J'ai eu la flemme de recompiler et puis, avec l'image ArchLinux, IPv6 marchait très bien.

Les six ans, c'était à partir de la dissolution du groupe et de la publication des premiers RFC, en 2006. Deux ans étaient annoncés, cela en a pris six.

Si. C'était mieux avant la correction.

6686, pas 6696. Désolé mis j'ai l'impression qu'on ne peut pas modifier un journal, juste ajouter des commentaires.

Oui, elle peut être négative mais c'est peu probable : la Terre ne fait que ralentir, je ne vois pas bien quel phénomène physique la ferait accélerer d'une seconde…

Malheureusement, Unix ne donne accès qu'à UTC (et pas à TAI ni à une autre échelle strictement monotone) donc des applications qui n'ont pas besoin de l'heure « civile » sont quand même forcées de l'utiliser :

http://www.bortzmeyer.org/leap-second-or-not-leap-second.html

Encore faut-il qu'il y a des câbles alternatifs ! Comme cela coûte cher, ce n'est pas toujours le cas. En prime, lorsque les câbles alternatifs passent dans la même tranchée, une seule pelleteuse coupe tout (cas de la coupure « tramway » du datacenter de Prosodie dans les Yvelines).

Et cela ne couvre que les pannes matérielles. Mais les pannes logicielles peuvent potentiellement avoir des conséquences plus graves (pensez au nombre incroyable de zones DNS qui n'utilisent que BIND : en cas de bogue BIND, on peut planter beaucoup de domaines).

Désolé pour le lien, linuxfr a considéré que le guillemet fermant en faisait partie. Le bon lien est http://www.ssi.gouv.fr/fr/menu/actualites/l-anssi-et-l-afnic-publie-un-etat-des-lieux-de-l-internet-francais.html

Concernant la possibilité d'une panne majeure de l'Internet (qui ne touche pas qu'une ville ou un site Web mais une grande partie de l'Internet), je trouve très imprudent d'affirmer « du coup Internet ne me parait pas pouvoir être en panne ». Certes, cela ne s'est jamais produit. Mais, si on ne fait pas attention, cela pourrait arriver un jour. Si tout le monde utilise des Cisco et qu'une faille premier-jour d'IOS est exploitée par un méchant… il peut planter une bonne partie de l'Internet. Des alertes sérieuses ont déjà eu lieu. http://www.bortzmeyer.org/bgp-attribut-99.html

Cela ne me semble pas une bonne idée. Cela interdirait, lors de la normalisation d'un paramètre, de changer son nom (je prends X-billgates-est-un-con et ensute, je demande l'enregistrement officiel) ou de changer sa sémantique (ce qui est souvent le cas en pratique).

Sinon, pour savoir lesquels sont officiels, il ne faut surtout pas « compulser les RFC » (beaucoup de registres de paramètres n'exigent pas forcément un RFC, juste une doc stable) mais le registre pertinent sur le site de l'IANA http://www.iana.org/

J'ai l'impression que vous utilisez un vocabulaire non-standard. Vous voulez dire que vous avez plusieurs enregistrements MX (il y en a toujours au moins un), pointant vers des serveurs différents ? Si c'est le cas, c'est en général une mauvaise idée pour un petit site http://www.bortzmeyer.org/mx-secondaire.html

Et le fait que les spammeurs attaquent en premier le MX de plus faible priorité a été souvent observé.

Sinon, le cas de plusieurs MX est couvert dans les articles cités.

Ce problème est connu et longuement décrit dans les documents cités (avec les solutions).

Mais c'est justement une énorme limite. Combien de pare-feux autorisent l'UDP ?

Ce caratère n'est pas autorisé par la norme IDN (seules les lettres et les chiffres le sont et quelques rares autres). Alors, à part pour troller bêtement, à quoi bon le citer ?

http://www.bortzmeyer.org/5892.html

Excellent document, oui. Mais il faut le lire jusqu'au bout, notamment dans la conclusion qui dit que le problème est très exagéré « It is also important to recognize that the use of visually confusable characters in spoofing is often overstated. Moreover, confusable characters account for a small proportion of phishing problems: most are cases like "secure-wellsfargo.com". » Et, pour revenir au vote, ce document approuve les IDN…

Un peu agaçé de cette allusion répétée au phishing quand la totalité des études sérieuses sur le phishing (et il y en a beaucoup) montrent que les utilisateurs ne tiennent pas compte de ce qui est dans l'URL (et qu'il n'est donc pas nécessaire de faire un nom de domaine qui ressemble à celui phishé).

http://www.bortzmeyer.org/idn-et-phishing.html

Et il y a beaucoup d'autres propositions d'améliorations dans la besace de Google, dont une qui accélère le « slow start », nommée IW10

Vous pouvez ne pas le croire mais l'article de Google sur TCP Fast Open donne de nombreux chiffres, issus de l'analyse du trafic chez Google qui montrent que, si, le temps d'établissement de connexion a une contribution essentielle. (Et ils expliquent pourquoi les connexions persistentes de HTTP 1.1 ne résolvent pas le problème.)

Et ? Le fait que le "chat" Facebook marche sur le réseau de l'expérience ne prouve pas que Facebook soit accessible en IPv6 (le réseau de l'expérience avait une passerelle NAT64, c'est elle qui permet l'accès aux sites Web purement v4 comme facebook).

La question de l'utilisation ou pas d'un nom de domaine spécifique est discutée dans le RFC 6589 http://www.bortzmeyer.org/6589.html