#rfc

RFC 6949 : RFC Series Format Requirements and Future Development

Cela fait longtemps que le format des #RFC est critiqué, à l’#IETF ou ailleurs. Pour d’excellentes raisons (détaillées plus loin), ce format est très ancien et très rigide, sans concessions aux gadgets modernes. Il n’a pas encore été possible de le modifier, à la fois en raison des difficultés de prise de décision au sein de la communauté, et aussi parce que le problème est réellement difficile. Contrairement à ce que prétendent certains yakafokon, trouver un format idéal n’est pas trivial. Ce RFC est la première étape d’une tentative de réforme, commençant par un cahier des charges sur les changements souhaitables. Les règles rigides de formatage (longueur des pages et des lignes) disparaissent, l’Unicode fait son entrée dans les RFC, et la possibilité d’inclure des images apparait.

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

RFC 6946 : Processing of IPv6 "atomic" fragments

Une particularité amusante de la gestion de la fragmentation dans #IPv6 est qu’un paquet peut très bien avoir un en-tête de fragmentation sans être fragmenté du tout. Cela se nomme un « fragment atomique ». Ils n’ont aucun intérêt pratique mais sont engendrés par certains systèmes lorsqu’ils reçoivent un message #ICMP Packet too big indiquant une MTU inférieure à 1280 octets (la taille miminale pour une MTU IPv6). Le problème est que ces fragments atomiques sont ensuite traités par bien des systèmes comme des vrais fragments, permettant ainsi certaines attaques subtiles. Ce nouveau #RFC demande donc que les fragments atomiques soient gérés à part, compte tenu de leurs particularités.

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

RFC 6943 : Issues in Identifier Comparison for Security Purposes

Utiliser des identificateurs (noms de domaine, URI, noms d’utilisateur, adresses de courrier, etc) comme clés d’accès à des informations de sécurité est courant. Par exemple, on autorise machin@truc.example et lui seul à accéder à certains contenus. Cela implique une comparaison entre l’identificateur présenté et ceux stockés dans une base. En apparence, rien de plus simple que de comparer deux chaînes de caractères. En réalité, il existe plein de pièges, que documente ce #RFC de l’IAB. Si tout le monde n’utilise pas exactement le même algorithme de comparaison (et certains sont mal spécifiés ou mal connus et permettent donc des variations), alors on peut avoir aussi bien des dénis de service (utilisateur légitime refusé) que des augmentations de privilèges (utilisateur illégitime accepté).

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

#sécurité #programmation #identificateurs

RFC 6927 : Variants in Second-Level Names Registered in Top Level Domains

Il y a beaucoup d’utilisateurs des noms de domaine qui pensent que deux noms qui, pour eux, sont « le même », devraient être traitées d’un bloc par le #DNS et/ou par les systèmes d’enregistrement de noms. Tout le problème est évidemment de définir « le même » : il n’y a en général pas d’accord entre les utilisateurs sur ce point. Ainsi, des anglophones peuvent penser que meter.example et metre.example sont « le même nom » et devraient donc se comporter ainsi. D’autres pensent que pizzeria-napoli.example et pizzerianapoli.example sont « le même nom ». Et, évidemment, depuis l’arrivée des #IDN, le potentiel pour des noms « identiques » a encore augmenté. Il a donc été proposé que ces variantes d’un « même » nom soient explicitement reconnues. Ce #RFC ne suggère pas de mécanisme en ce genre (je pense personnellement que le problème est bien trop flou et subjectif pour cela). Il se contente de regarder les pratiques actuellement déployées par les registres en matière de « variantes ».

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

#Unicode

RFC 6944 : Applicability Statement : DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status

Mais quel algorithme de #cryptographie choisir pour mes signatures #DNSSEC, se demande l’ingénieur système ? Il y a bien un registre IANA des algorithmes normalisés mais c’est juste une liste non qualifiée, qui mêle des algorithmes de caractéristiques très différentes. Ce nouveau #RFC vise à répondre à cette question en disant quels sont les algorithmes recommandés.

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

RFC 6935 : IPv6 and UDP Checksums for Tunneled Packets

Ne dites plus qu’en #IPv6, la somme de contrôle est toujours obligatoire dans les en-têtes des paquets #UDP. Depuis ce #RFC 6935, ce n’est plus vrai dans tous les cas. Lors de l’encapsulation de paquets dans un tunnel UDP, on a désormais le droit de ne pas mettre de somme de contrôle dans les paquets UDP, essentiellement pour des raisons de performance.

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

Après les adresses IPv4 et les adresses MAC, encore un truc où l’espace de nommage était trop petit et a été rempli...

RFC 6929 : Remote Authentication Dial In User Service (RADIUS) Protocol Extensions

#RADIUS, un protocole utilisé pour l’authentification (et la configuration) d’accès à l’Internet, est ancien et marche toujours. Lorsque vous accédez à l’Internet depuis chez vous, sans vous en rendre compte, vous avez probablement indirectement utilisé RADIUS. Il marche toujours très bien mais, rançon du succès, il a été tellement étendu qu’un certain nombre de champs du message RADIUS sont désormais pleins : toutes les options possibles seront allouées très bientôt. Ce nouveau #RFC décrit un mécanisme d’extension de RADIUS, permettant de continuer l’enregistrement de nouvelles options, au prix de quelques bricolages.

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

RFC 6888 : Common requirements for Carrier Grade NATs (CGNs)

Qu’on les approuve (ce qui n’est pas mon cas) ou pas, les #CGN, ces gros routeurs #NAT installés dans le réseau du FAI et gérant des centaines ou des milliers de clients, sont d’ores et déjà une réalité douloureuse dans de nombreux pays d’Asie et peut-être demain sur d’autres continents. Pour limiter les dégâts qu’ils causent, ce #RFC 6888 pose un certain nombre de règles que devraient respecter ces CGN.

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

RFC 6887 : Port Control Protocol (PCP)

Aujourd’hui, l’utilisateur de l’Internet ne bénéficie que rarement d’une connexion neutre, d’un simple tuyau le connectant à toutes les autres machines de l’Internet. La plupart du temps, il est au contraire bloqué derrière des engins comme les routeurs #NAT ou les pare-feux. Par défaut, ces engins bloquent les connexions entrantes, limitant l’utilisateur à un usage type Minitel. Dans ce cas, on a souvent besoin de dire à l’engin sur le trajet « laisse entrer des connexions vers tel port » (par exemple pour le pair à pair). Cela se fait aujourd’hui en général par une interface spécifique (par exemple une page Web d’administration du routeur NAT) ou par le protocole privé #UPnP. Il y avait donc une demande pour un protocole standard, adapté aux mécanismes d’aujourd’hui comme les CGN : c’est ce nouveau protocole, #PCP (Port Control Protocol).

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

#RFC

RFC 6890 : Special-Purpose IP Address Registries

Un certain nombre de préfixes d’adresses #IP sont spéciaux, réservés à des tâches comme les exemples dans la documentation, ou bien prévus pour des protocoles particuliers. Ces préfixes n’étaient pas documentés à un endroit unique, ils étaient dans certains #RFC, avec parfois des registres #IANA. Ce RFC restructure le système, désormais la seule source faisant autorité est le registre IANA (un pour IPv4 et un pour IPv6). En outre, ces deux registres ont désormais une structure bien définie, notamment pour indiquer les propriétés d’un préfixe spécial.

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

RFC 6928 : Increasing TCP’s Initial Window

Sur l’Internet, il y a des choses qu’on hésite à toucher. Depuis quelques épisodes fameux de « catastrophes congestives », où tout l’Internet s’est arrêté en raison de l’encombrement des tuyaux, la mémoire collective du réseau, incarnée notamment par l’#IETF, voit avec une extrême méfiance toute modification des algorithmes de #TCP, qui sont la principale ligne de défense de l’Internet face à la congestion. Néanmoins, le réseau évolue, les choses changent et il y a des gens qui insistent pour essayer des changements. Cela fait un certain temps que #Google réclame une modification connue sous le doux nom de #IW10 (pour Initial Window 10 segments) et ce #RFC est le premier à la documenter officiellement, après trois ans de discussion dans le groupe de travail. Pour l’instant, c’est encore étiqueté comme « expérimental ».

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

RFC 6911 : RADIUS attributes for IPv6 Access Networks

Le protocole #RADIUS joue un rôle important dans l’accès à l’Internet : c’est le principal mécanisme utilisé pour faire communiquer la machine qui contrôle l’accès physique avec la machine qui contient la base des utilisateurs et les informations sur les autorisations, les configurations spécifiques... RADIUS avait bien sûr déjà la capacité de transporter des informations #IPv6 mais ce nouveau #RFC en ajoute quelques unes.

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

RFC 6895 : Domain Name System (DNS) IANA Considerations

Un #RFC un peu bureaucratique, pour détailler les mécanismes utilisés pour l’enregistrement dans les registres de l’#IANA des paramètres liés au DNS. Il met très légèrement à jour son prédécesseur, le RFC 6195, libéralisant encore un peu plus l’enregistrement de nouveaux types de données dans le #DNS.

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

RFC 6912 : Principles for Unicode Code Point Inclusion in Labels in the DNS

Ce #RFC de l’#IAB expose les principes que, selon l’IAB, devraient suivre les registres de noms de domaine lorsqu’ils décident quels caractères #Unicode sont autorisés ou pas, pour l’enregistrement de noms de domaine internationalisés.

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

#IDN #DNS #noms_de_domaine

RFC 6922 : The application/sql Media Type

Premier enregistrement d’un nouveau type de données (type #MIME) fait depuis les nouvelles règles du RFC 6838, ce #RFC enregistre un type très ancien mais qui n’avait jamais été normalisé, application/sql, pour le code source #SQL.

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

Tout le monde (à commencer par SeenThis) fait du #JSON aujourd’hui, donc voici deux nouvelles extensions normalisées qui peuvent aider :

http://www.bortzmeyer.org/6901.html (pointeurs en JSON)

http://www.bortzmeyer.org/6902.html (patches en JSON)

#RFC

RFC 6908 : Deployment Considerations for Dual-Stack Lite

DS-Lite est une des nombreuses techniques de transition / co-existence IPv4 / #IPv6. Elle est normalisée dans le RFC 6333 http://seenthis.net/messages/31069 . Ce nouveau #RFC se penche plutôt sur des problèmes opérationnels : comment déployer DS-Lite, quels pièges éviter, etc.

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

RFC 5575 : Dissemination of Flow Specification Rules

Lorsqu’on a un grand réseau compliqué, diffuser à tous les routeurs des règles de filtrage, par exemple pour faire face à une #attaque_par_déni_de_service, peut être complexe. Il existe des logiciels permettant de gérer ses routeurs collectivement mais ne serait-il pas plus simple de réutiliser pour cette tâche les protocoles existants et notamment #BGP ? On profiterait ainsi des configurations existantes et de l’expérience disponible. C’est ce que se sont dit les auteurs de ce #RFC. « #FlowSpec » (nom officieux de cette technique) consiste à diffuser des règles de traitement du trafic en BGP, notamment à des fins de filtrage.

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

#DoS #sécurité

RFC 6903 : Additional Link Relation Types

Allez, encore tout un lot de types de liens #Web qui sont enregistrés. Pas de point commun entre les types créés par ce #RFC, juste quelques types intéressants. « about », « preview », « privacy-policy », « type » et « terms-of-service ».

Pour #SeenThis_TODO, je pense qu’il serait bon d’avoir un lien « terms-of-service » pointant vers ►http://seenthis.net/fran%C3%A7ais/mentions/article/propri%C3%A9t%C3%A9-intellectuelle et un lien « privacy-policy » pointant vers... une page à écrire.

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

RFC 6906 : The ’profile’ Link Relation Type

Les liens sont à la base du #Web, tout le monde le sait, mais on sait moins que les liens sont typés, marqués avec un type qui indique leur sémantique. Ainsi, le type profile, décrit dans ce #RFC, indique que le lien pointe vers un profil, une spécification du format utilisé qui restreint les possibilités d’un format donné. [Pas trouvé d’utilisation astucieuse pour SeenThis. Ou alors, mettre du DublinCore dans les seens ?]

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

RFC 6885 : Stringprep Revision and PRECIS Problem Statement

Dans bien des protocoles, il y a besoin de comparer deux chaînes de caractères, pour voir si elles sont égales. Par exemple, un protocole d’authentification va comparer un identificateur à ceux enregistrés dans sa base, pour voir s’il est présent. Si les chaînes de caractères sont uniquement en US-ASCII, il n’y a guère de problèmes, à part décider si la comparaison est sensible à la casse. Mais si elles sont en Unicode ? Alors, c’est plus compliqué. Dans ce cas, on décide de préparer les chaînes avant la comparaison, pour les ramener à une forme de référence (en ASCII, un exemple simple de préparation serait de tout mettre en minuscules). Beaucoup de protocoles IETF utilisaient pour cette opération le #stringprep du RFC 3454, popularisé par son utilisation dans les noms de domaines internationalisés. Mais la mise à jour de ces noms de domaines, en 2010, a abandonné stringprep. Dans ces conditions, les autres protocoles se retrouvaient privés d’une référence bien pratique. Le groupe de travail PRECIS a été créé pour étudier la mise en place d’un cadre général de préparation des chaînes Unicode pour tous les protocoles. Ce RFC 6885 est son premier #RFC et il décrit le problème, sans proposer encore de solution.

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

[Tiens, au fait, est-ce qu’un compte SeenThis peut être en Unicode, par exemple « stéphane » au lieu de « stephane » ?]

#internationalisation

Pas sûr que ça puisse servir à SeenThis mais c’est rigolo : RFC 6892 : The ’describes’ Link Relation Type

Dans le registre des types de liens, il y avait déjà un describedby qui indiquait une ressource Web décrivant la ressource courante. Désormais, il y a aussi l’inverse, describes, qui va d’une ressource à celle qu’elle décrit.

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

#RFC #Web #lien

Cinq nouveaux #RFC viennent de paraitre, autour du courrier électronique entièrement internationalisé (donc, y compris les en-têtes, les adresses, etc) :

– RFC 6854 (pas directement lié à l’internationalisation) qui change légèrement la syntaxe du champ From : pour avoir plusieurs expéditeurs

– RFC 6855 qui normalise l’usage d’#IMAP avec le courrier complètement internationalisé (accès à des boîtes aux lettres qui contiennent des messages internationalisés) Voir http://www.bortzmeyer.org/6855.html

– RFC 6856 qui fait la même chose pour #POP

– RFC 6857 et 6858, deux algorithmes (un simple et un compliqué) pour le cas où le serveur IMAP stocke des messages internationalisés et où un vieux client IMAP demande à accéder à la boite. Ces deux RFC spécifient des algorithmes de « repli », où le message va être massacré pour s’adapter au client. Voir http://www.bortzmeyer.org/6857.html et http://www.bortzmeyer.org/6858.html

#internationalisation #courrier_électronique

RFC 6883 : IPv6 Guidance for Internet Content Providers and Application Service Providers

Ce nouveau #RFC sur #IPv6 ne spécifie pas un protocole réseau mais rassemble simplement un ensemble de conseils pour les gens qui gèrent des serveurs Internet et qui veulent les rendre accessibles en IPv6 (par exemple SeenThis qui, #SeenThis_TODO, n’est toujours pas accessible en IPv6). Bien sûr, en 2013, tous les serveurs devraient depuis longtemps être ainsi accessibles. Mais le déploiement d’IPv6 a pris du retard et ce RFC est une des nombreuses tentatives pour tenir la main des retardataires qui hésitent encore à traverser le gué.

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

Tout le monde le sait, un des meilleurs moyens de casser ou de détourner l’Internet, c’est de pirater un ou plusieurs routeurs. Ceux-ci ne sont pas toujours gérés de manière très propre, question sécurité (il est vrai qu’ils n’incluent pas d’applications écrites en PHP ou VB.net...). Pour ceux qui font de l’OSPF, par exemple, une question à laquelle il faut répondre honnếtement : depuis combien de temps n’avez-vous pas changé les mots de passe OSPF ? Combien d’employés connaissant ces mots de passe ont quitté l’entreprise/l’association sans que les mots de passe soient changés ? La pénibilité de la gestion des mots de passe, pour les principaux protocoles de routage, fait que les bonnes pratiques de sécurité ne sont pas toujours suivies. Deux nouveaux RFC viennent d’être publiés :

RFC 6862 : Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements : le tour d’horizon des problèmes auxquels va s’attaquer le groupe de travail KARP de l’IETF (gestion des clés dans les routeurs) http://www.bortzmeyer.org/6862.html

RFC 6863 : Analysis of OSPF Security According to KARP Design Guide : l’analyse d’OSPF selon la méthode publiée dans le RFC 6518 http://www.bortzmeyer.org/6863.html J’y ai appris des choses, notamment qu’OSPF est sensible aux attaques par rejeu

#OSPF #routeur #routage #sécurité #maya2012 #RFC #IETF #KARP