#rfc

RFC 6454 : The Web Origin Concept

Chaque jour, plusieurs failles de #sécurité sont annoncées frappant un site #Web, ou, plus rarement, un navigateur. Ces failles proviennent souvent de l’exécution de code, par exemple Java ou #JavaScript, téléchargé depuis un serveur qui n’était pas digne de confiance, et exécuté avec davantage de privilèges qu’il n’aurait fallu. Une des armes principales utilisées par la sécurité du Web, pour essayer d’endiguer la marée de ces attaques, est le concept d’origine (#SOP). L’idée est que toute ressource téléchargée (notamment le code) a une origine, et que cette ressource peut ensuite accéder uniquement à ce qui a la même origine qu’elle. Ainsi, un code JavaScript téléchargé depuis www.example.com aura le droit d’accéder à l’arbre DOM de www.example.com, ou à ses cookies, mais pas à ceux de manager.example.net. Ce concept d’origine semble simple mais il y a plein de subtileries qui le rendent en fait très complexe et, surtout, il n’avait jamais été défini précisément. Ce que tente de faire ce #RFC.

►http://www.bortzmeyer.org/6454.html

RFC 6441 : Time to Remove Filters for Previously Unallocated IPv4 /8s

Pour limiter certains risques de sécurité, des opérateurs réseaux filtraient en entrée de leur réseau les adresses IP non encore allouées (dites bogons). Les adresses #IPv4 étant désormais totalement épuisées, cette pratique n’a plus lieu d’être et ce #RFC demande donc que ces filtres soient démantelés.

►http://www.bortzmeyer.org/6441.html

RFC 6419 : Current Practices for Multiple Interface Hosts

Il fut une époque où la machine terminale connectée à l’Internet n’avait typiquement qu’une seule interface réseau. Seuls les routeurs avaient plusieurs interfaces et donc des décisions difficiles à prendre comme « quelle adresse source choisir pour le paquet que je génère ? » Aujourd’hui, les machines les plus ordinaires ont souvent, à leur tour, plusieurs interfaces réseau. Mon smartphone a une interface WiFi et une 3G. Mon ordinateur portable a une interface filaire, une 3G, une Wifi et une Bluetooth. Qui dit plusieurs interfaces dit décisions à prendre. Quel serveur DNS utiliser ? Celui appris via l’interface filaire ou bien celui appris en Wifi ? Par quelle interface envoyer un paquet qui sort de la machine ? La question est d’autant plus difficile que les différentes interfaces fournissent en général des services très différents, en terme de qualité et de prix. Le groupe de travail MIF de l’#IETF travaille à normaliser le comportement des machines sur ce point. Son premier #RFC (un autre, le RFC 6418, concerne l’exposé du problème) commence par examiner l’état de l’art : que font aujourd’hui les divers systèmes d’exploitation confrontés à cette question ?

►http://www.bortzmeyer.org/6419.html

#Android #S60 #Blackberry #Windows_Mobile

RFC 6430 : Email Feedback Report Type Value : not-spam

►http://www.bortzmeyer.org/6430.html

Il existe un format standard pour la transmission de rapports d’abus entre acteurs de l’Internet qui permet, par exemple, à des opérateurs de serveurs de messagerie de signaler un spam, et de traiter automatiquement ces rapports. Ce format se nomme #ARF et est normalisé dans le RFC 5965. Chaque rapport ARF indique un type d’abus et ce nouveau #RFC 6430 ajoute le type not spam, qui permet d’attirer l’attention sur un message classé à tort.

RFC 6386 : #VP8 Data Format and Decoding Guide

►http://www.bortzmeyer.org/6386.html

Le monde des formats #vidéo est très hostile pour ceux qui apprécient la liberté et l’ouverture : formats privés, non documentés, contrôlés par une seule compagnie, plombé de brevets tous plus futiles les uns que les autres... Aujourd’hui, il est à peu près impossible de regarder une vidéo, quelle qu’elle soit, avec du logiciel entièrement libre, et sans enfreindre une centaine de brevets. Ce #RFC documente est un des très rares #codecs vidéos ouverts, qui puisse être mis en oeuvre dans du logiciel libre sans trop de crainte juridique. Il a été produit par #Google, documenté pour l’#IETF et se nomme VP8.

#WebM

Question #atom ou plutôt #app pour @stephane :

Le schéma de base d’une <entry>, au départ c’est calqué sur un système de blog : titre+résumé+auteurs+texte et basta. Pourtant le standard est déjà utilisé pour des applications bien plus complexes (les API Google l’utilisent toutes : ►http://code.google.com/intl/fr/apis/gdata/docs/2.0/basics.html).

Pourtant, je n’arrive pas à trouver une doc « simple » (pas le #RFC complet quoi) qui explique comment ça se passe dans #AtomPub quand on a plein d’autres champs. Comment ça doit être implémenté ? Il faut ajouter d’autres namespaces avec des schémas en plus, et c’est au serveur de savoir ou pas les gérer ?

Une appli tierce pourrait renvoyer ça en POST ou PUT :

<title>Titre de mon objet</title>
<monappli:champ>Truc</monappli:champ>

Un serveur classique saura forcément gérer le « title », mais après libre à un serveur de gérer n’importe quel autre élément et/ou attribut en plus ?

Il n’existe pas encore de #standard pour qu’un serveur déclare les « champs » d’une ressource et que donc un client sache les découvrir ? (Ça serait cool comme standard ! :D )

Vous êtes chercheur en réseaux informatiques ? Vous avez mis au point un super-algorithme ? Faites-en un #RFC !

►http://www.bortzmeyer.org/6417.html

Nourri de la vaste expérience de ses auteurs (tous chercheurs et tous ayant écrit des RFC), ce document essaie de combler une partie du fossé entre la communauté des chercheurs et la normalisation, en encourageant ces chercheurs à participer à l’#IETF, et en leur expliquant ce à quoi ils doivent s’attendre.

RFC 6394 : Use Cases and Requirements for DNS-based Authentication of Named Entities (DANE)

Le projet #DANE (DNS-based Authentication of Named Entities), vise à améliorer et/ou remplacer les certificats #X.509 utilisés dans des protocoles comme #TLS. Ces certificats souffrent de plusieurs problèmes, le principal étant qu’une Autorité de Certification (AC) malhonnête ou piratée peut créer des certificats pour n’importe quelle entité, même si celle-ci n’est pas cliente de l’AC tricheuse. C’est ce qui s’est produit dans les affaires #Comodo et #DigiNotar et ces deux affaires ont sérieusement poussé aux progrès de DANE. Ce premier #RFC du groupe de travail DANE établit les scénarios d’usage : quels problèmes veut résoudre DANE et selon quels principes ?

►http://www.bortzmeyer.org/6394.html

RFC 6392 : A Survey of In-network Storage Systems

Cette intéressante étude des systèmes de stockage de données en ligne (le RFC n’utilise pas le terme de #cloud, pourtant bien plus vendeur) fait le tour les principales solutions d’aujourd’hui. Son but est de préparer le travail ultérieur du groupe de travail #IETF DECADE, dont le rôle est de normaliser une architecture pair à pair pour ce stockage en ligne. Ce #RFC, le premier produit par DECADE, étudie l’offre existante, afin de voir dans quelle mesure elle est réutilisable pour DECADE.

►http://www.bortzmeyer.org/6392.html

#Amazon-S3 #Flickr #Dropbox #OceanStore #Usenet #P2P #etpleindautres

RFC 6382 : Unique Per-Node Origin ASNs for Globally Anycasted Services

Ce court #RFC propose un changement radical dans la gestion des annonces #BGP par les services anycastés. Actuellement, ils utilisent presque tous un seul numéro d’AS pour tous les noeuds d’un nuage #anycast. Notre RFC 6382, au contraire, suggère d’utiliser un numéro d’AS par noeud.

►http://www.bortzmeyer.org/6382.html

RFC 6385 : General Area Review Team (Gen-ART) Experiences

Comme souvent à l’#IETF, les expériences les plus réussies ne sont pas documentées, ou alors le sont longtemps après. Les examens des Internet-Drafts par Gen-ART (General Area Review Team) ont commencé en 2004 mais viennent juste d’être formalisées. Gen-ART, dont l’expérience est décrite dans ce nouveau #RFC, est un groupe d’experts volontaires qui regardent les Internet-Drafts lorsqu’ils sont prêts de devenir un RFC. Le terme de « Gen-ART » apparait de plus en plus souvent dans les discussions à l’IETF, mais que recouvre-t-il exactement ?

►http://www.bortzmeyer.org/6385.html

RFC 6410 : Reducing the Standards Track to Two Maturity Levels

Ce très court #RFC met fin (provisoirement ?) à un très long et très agité débat au sein de l’#IETF. Après de longs efforts, il réussit à réformer une vache sacrée du processus de normalisation des protocoles TCP/IP. Les RFC spécifiant ces protocoles avaient trois étapes sur le chemin des normes. Il n’y en a désormais plus que deux.

►http://www.bortzmeyer.org/6410.html

RFC 6390 : Guidelines for Considering New Performance Metric Development

Le groupe de travail #IETF PMOL était chargé de travailler à la définition de métriques de haut niveau, proche de l’utilisateur (le groupe IPPM s’occupant, lui, des couches plus basses). Désormais fermé, il condense son expérience dans ce #RFC, qui explique comment définir de nouvelles métriques, comme PMOL l’avait fait dans les RFC 5814 sur MPLS et RFC 6076 sur SIP.

►http://www.bortzmeyer.org/6390.html

Deux nouveaux #RFC sur la technologie d’authentification du courrier #DKIM :

La nouvelle version de la norme, RFC 6376 « DomainKeys Identified Mail (DKIM) Signatures ». Le courrier électronique, on le sait, n’offre, en natif, aucun mécanisme d’authentification des utilisateurs. Il est donc assez facile d’envoyer un courrier prétendant venir de Bill.Gates@microsoft.com. DKIM, spécifié dans notre RFC, est la dernière tentative de combler ce manque. (La première version de DKIM était normalisée dans le RFC 4871. Cette nouvelle version n’apporte pas de changements cruciaux.) ►http://www.bortzmeyer.org/6376.html

Et un RFC sur DKIM et les listes de diffusion, RFC 6377 « DKIM And Mailing Lists ». La sécurité, c’est compliqué. Ce n’est pas tout de définir des normes techniques comme DKIM, pour sécuriser le courrier électronique. Il faut encore étudier leurs conséquences pour tous les cas. Le courrier électronique ayant débuté il y a très longtemps, et n’ayant pas vraiment été spécifié dans tous les détails, il représente un défi particulier pour tous ceux qui essaient de le sécuriser a posteriori. C’est ainsi que ce nouveau RFC s’attaque au cas particulier des listes de diffusion et étudie comment elles réagissent avec le mécanisme d’authentification DKIM. ►http://www.bortzmeyer.org/6377.html

L’#internationalisation des protocoles développés par l’#IETF est depuis quinze ans un des sujets chauds de cette organisation. Réussir à rendre tous les protocoles Internet adaptés aux différentes langues, écritures et cultures nécessite d’avoir un socle linquistique commun et c’est le rôle de ce #RFC, qui décrit la terminologie en usage à l’IETF. Il remplace le RFC 3536 dans le rôle du texte « l’internationalisation pour les débutants ». Le texte est long car le sujet est complexe.

►http://www.bortzmeyer.org/6365.html

►http://www.bortzmeyer.org/6366.html

Début 2010, l’#IETF avait lancé un travail pour la normalisation d’un #codec libre pour l’Internet, c’est-à-dire qui ne serait pas plombé par des brevets ou autres appropriations intellectuelles et pourrait donc être utilisé par n’importe quel protocole Internet. Ce #RFC est le premier produit par le groupe de travail, et contient le cahier des charges du futur codec.

RFC 6335 : IANA Procedures for the Management of the Port Number and Service Name Registry

C’est aussi bien que les noms de domaine, ou que les adresses IP. L’enregistrement des numéros de port a désormais ses règles, ses conflits et ses procédures d’arbitrage :-}

Ce #RFC parle autant de gouvernance que de technique. Il refond considérablement les procédures utilisées pour enregistrer les numéros de port à l’#IANA. Cet enregistrement des ports a déjà suscité des conflits, et peut en faire encore plus maintenant qu’une des plages utilisées approche de la saturation.

L’ancien mécanisme d’enregistrement était peu documenté, avait plusieurs limites techniques, et était éclaté entre plusieurs registres ayant des règles différentes. Le nouveau vise à unifier tout cela et à suivre de bons principes, soigneusement explicités.

►http://www.bortzmeyer.org/6335.html

RFC 6350 : vCard Format Specification

#vCard, désormais en version 4 avec ce #RFC est le format standard de carnet d’adresses sur l’Internet. Tous les logiciels de gestion de carnet d’adresses peuvent (ou devraient pouvoir) lire et écrire du vCard. Ce RFC met à jour la norme vCard. vCard est simplement un modèle de données (très léger) et une syntaxe pour représenter des données permettant de contacter des individus ou organisations.

►http://www.bortzmeyer.org/6350.html

Sinon, de même que le format de fichiers iCal, décrivant des événements, avait son protocole CalDav pour synchroniser des agendas entre machines, le format vCard décrivant des informations sur une personne a désormais son protocole #CardDAV, pour synchroniser des carnets d’adresses.

►http://www.bortzmeyer.org/6352.html

RFC 6346 : The A+P Approach to the IPv4 Address Shortage

Pendant longtemps, le problème technique posé à l’#IETF par l’épuisement des adresses #IPv4 était traité par la perspective d’une migration vers IPv6, et les efforts de l’IETF allaient vers la création de jolis mécanismes de transition vers ce nouveau protocole. Mais la migration est très loin d’être terminée et, dans des régions comme l’Asie, les adresses IPv4 ne sont plus seulement difficile à obtenir et chères, elles sont tout simplement toutes utilisées. Il faut donc maintenant, en urgence, mettre au point des mécanismes qui permettront de vivre pas trop mal en attendant le déploiement d’IPv6. C’est le cas du mécanisme #A+P (Address plus Port) de ce #RFC.

►http://www.bortzmeyer.org/6346.html

RFC 6360 : Conclusion of FYI RFC Sub-Series

Les #RFC, textes sacrés de l’Internet, comportaient un sous-ensemble, dénommé FYI (For Your Information), qui visait un public plus large que les ingénieurs réseaux et les programmeurs. Cette sous-série n’a pas été un grand succès, malgré la qualité des documents produits, et est officiellement abandonnée.

►http://www.bortzmeyer.org/6360.html

La mesure des performances du réseau intéresse évidemment fortement les utilisateurs (combien de temps me faudra-t-il pour télécharger justin-bieber.flac ?) et les décideurs qui cherchent à savoir, par exemple, quelle capacité offre un FAI, s’il délivre bien le service promis, ou encore s’il limite artificiellement les débits. La plupart des métriques définies rigoureusement, et des outils qui les mettent en oeuvre, concernent des phéonomènes de bas niveau, comme le taux de perte de paquets, C’est ainsi que, lorsqu’il existe des SLA formalisés, ils portent en général sur ces phénomènes proches du réseau. Ces métriques sont utiles et relativement faciles à mesurer objectivement, mais elles sont très éloignées de l’expérience ressentie par l’utilisateur final. Ce dernier voudrait plutôt savoir comment l’intégration de toutes ces métriques de bas niveau se traduit en un petit nombre de chiffres faciles à comprendre. Ce n’est pas une tâche triviale que de passer des métriques de base au ressenti utilisateur, et ce #RFC est une première étape sur le chemin.

►http://www.bortzmeyer.org/6349.html

#TCP #performances-réseau #capacité #débit #bande-passante

RFC 6333 : Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion

Il existe une myriade de techniques de coexistence entre l’ancien protocole IPv4 et le nouvel #IPv6, à tel point qu’on peut même avoir du mal à faire son choix. Et le groupe de travail Soft Wires (réseaux virtuels variés) de l’#IETF en invente de temps en temps des nouvelles. Pour ne pas s’affoler devant cette multitude, il faut se rappeler que chacune de ces techniques a un but bien précis et sert dans un cas donné. DS-Lite (Dual-Stack Lite), objet de ce #RFC, vise les FAI récents, qui n’ont jamais eu d’adresses IPv4 publiques en quantité et dont le réseau interne est en IPv6 depuis le début.

►http://www.bortzmeyer.org/6333.html

RFC 6280 : An Architecture for Location and Location Privacy in Internet Applications

Aujourd’hui, de nombreuses applications des réseaux informatiques dépendent de la localisation physique de l’appareil mobile. La récolte de ces données de localisation (« le 31 mai 2011, à 08:04, l’appareil était en 40,756° Nord et 73,982° Ouest, ±150m »), leur transmission à travers le réseau, et leur traitement par le service qui héberge l’application posent de graves questions de protection de la #vie_privée, surtout quand on lit les conditions d’utilisation de ces services (si on pouvait comprendre le jargon juridique, elles se résumeraient à « nous faisons ce que nous voulons, nous nous occupons de tout, ne vous inquiétez pas »). D’où ce #RFC qui essaie de définir une architecture de gestion de la vie privée pour ces informations de localisation.

►http://www.bortzmeyer.org/6280.html

RFC 6314 : NAT Traversal Practices for Client-Server SIP

Aujourd’hui, il est rare pour une machine individuelle (ordinateur de bureau, ordinateur portable, smartphone, tablette, etc) d’avoir un vrai accès Internet. Presque toujours, la malheureuse machine est limitée à une adresse IP privée et coincée derrière un #NAT qui traduira cette adresse à la volée. Cela ne gêne pas trop certains protocoles mais est beaucoup plus pénible pour d’autres, notamment le protocole de téléphonie sur IP #SIP. Ce RFC décrit l’ensemble des techniques que doivent mettre en oeuvre les clients SIP pour arriver à passer quand même. C’est la meilleure lecture pour commencer à se pencher sur le problème « pourquoi a-t-on si souvent des problèmes avec SIP ? ».

►http://www.bortzmeyer.org/6314.html

Voir aussi #Skype (concurrent fermé et privateur, de SIP) et #STUN, #TURN et #ICE (les protocoles de traversée de NAT cités par ce #RFC)

Ce #RFC sur le projet #AS112 n’a pas seulement un intérêt technique et opérationnel (bien que ce projet aide beaucoup le #DNS) mais c’est aussi un exemple de coopération (des dizaines de sites fonctionnant ensemble, sous une coopération souple, sans chef, et sans structures), et de projet concret réalisé sans paperasserie et sans procédures (ce RFC n’est venu que neuf ans après la mise en service de l’AS112).

►http://www.bortzmeyer.org/6304.html
►http://www.bortzmeyer.org/6305.html