Mon blog

Unicode est un jeu de caractères permettant de représenter toutes les écritures du monde. Il serait donc logique qu'il soit documenté dans plusieurs langues mais, sauf erreur, ce livre de Patrick Andries est le premier à parler d'Unicode en français.

Le sujet est très riche et très complexe. Certaines personnes, ignorant l'ampleur du problème, disent parfois qu'Unicode est « trop complexe ». La réalité est que le monde est complexe ; Unicode choisissant de suivre les usages existants (au lieu que les usages se plient aux limites de la technique), il doit traiter d'innombrables cas et le résultat est certainement complexe, mais pas inutilement complexe. Patrick Andries connait bien Unicode pour être membre du Consortium Unicode depuis des années et pour être un promoteur de cette norme en français (son site http://hapax.qc.ca/ regorge d'informations sur Unicode). Il s'est donc attaqué à la tâche d'écrire le premier livre en français sur Unicode.

Cela suppose quelques défis, notamment de trouver des traductions correctes et compréhensibles pour certains termes. Je n'ai pas reconnu du premier coup le word joiner (U+2060) derrière le « gluon de mots » et les « seizets d'indirection » m'ont également dérouté, même si le terme est bien plus correct que l'anglais surrogates. D'une manière générale, ce livre est peut-être un peu trop difficile à lire à force de vouloir être exact et de toujours utiliser des termes corrects, en évitant raccourcis et approximations. Il parait que le langue française est bien adaptée à cela...

Le plan du livre est classique ; concepts de base sur les écritures (chapitre 1) ; les jeux de caractères (chapitre 1) ; les concepts de base d'Unicode (chapitres 3 et 4) ; grand tour d'horizon des caractères dont on dispose dans Unicode (chapitres 5 à 8) ; applications d'Unicode, notamment dans le monde des protocoles et formats Internet (chapitres 9 à 11) ; l'internationalisation de logiciels (chapitre 12, très intéressant mais dont le lien avec Unicode est ténu) ; Unicode et les polices (chapitre 13, dont je n'ai vu aucun équivalent dans les autres livres sur Unicode).

Les exemples de programmation du chapitre 12 sont presque tous empruntés à C# ou à Java, des langages plutôt « costard / cravate », qui ont souvent l'avantage d'un grand nombre de bibliothèques pour manipuler l'Unicode (par exemple via un accès facile à ICU) et le défaut d'un modèle de caractères peu Unicodien (par exemple, dans Java, les caractères en dehors du Plan Multilingue de Base ne sont pas des caractères Unicode comme les autres, contrairement à Python ou Haskell). Pour avoir une petite idée du support Unicode dans d'autres langages, on peut regarder mon article Unicode en divers langages.

De même, la plupart des exemples concrets, par exemple sur la saisie de caractères Unicode, ne concernent que MS-Windows et les utilisateurs d'Unix qui ont des difficultés avec Unicode ne trouveront pas beaucoup à se mettre sous la dent.

L'écriture même d'un tel livre est un exploit, dans un monde où les systèmes informatiques sont encore rares d'avoir un parfait support d'Unicode. Peu de logiciels permettent de composer un ouvrage avec d'innombrables exemples Unicode (LaTeX en est hélas peu capable). Le livre a été écrit avec MS-Word, puis porté sur InDesign pour l'édition finale. InDesign s'est parfois montré trop intelligent, par exemple en remplaçant des caractères qu'il pensait inadaptés par d'autres. C'est ainsi qu'un exemple discutant le guillemet anglo-saxon, " (U+0022), présente en fait un guillemet français, le « (U+00AB). Une page Web d'errata présente les erreurs recensées dans le livre.

Au final, c'est un livre que je recommande chaudement. Les programmeurs qui veulent mettre en œuvre Unicode (et pas seulement l'utiliser) trouveront plus d'informations dans le livre de Gillam mais ceux qui veulent se servir d'Unicode dans un contexte Internet/XML seront au contraire bien plus satisfaits avec le livre d'Andries (qui est plus proche, par le public visé, du livre - en anglais - de Korpela).

Ce RFC, héritage d'une époque où le Web n'existait pas, est simplement un récapitulatif des normes actuelles de l'Internet, récapitulatif qui peut aussi se trouver en ligne en http://www.rfc-editor.org/rfcxx00.html. Mais c'est l'occasion de revenir sur les normes Internet et leur signification.

Autrefois, il n'était pas facile d'accéder à l'information en ligne, ou bien elle n'était tout simplement pas accessible et l'état de bases de données comme la base du registre IANA ou bien la liste des RFC étaient publiées sous forme de RFC. Pour la base des numéros et noms de protocoles, ce furent les RFC 317, puis le RFC 604, puis plusieurs autres jusqu'au dernier, le RFC 1700 en 1994. Après, cette information n'a plus été distribuée qu'en ligne (le RFC 3232 explique pourquoi). Mais la liste des protocoles normalisés continue à être publiée, en plus de la version en ligne, sous forme de RFC, comme notre RFC 5000, qui remplace le RFC 3700.

Que contient ce RFC 5000 ? Une liste de RFC, classés selon leur statut. Sur le chemin des normes, un RFC peut avoir trois statuts, proposition de norme, projet de norme et norme complète. Mais ces trois statuts, décrits dans le RFC 2026, sont peu significatifs. En effet, l'IETF étant fondée sur le volontariat, le passage d'un protocole d'un statut à un autre nécessite une action volontaire, pour un gain douteux (peu de gens font attention au niveau de normalisation). On voit donc des protocoles très utilisés rester au statut de proposition et des protocoles abandonnés depuis longtemps garder leur statut de norme complète. L'IETF n'a pas de ramasse-miettes pour les reclasser.

Parmi les normes complètes, on trouve évidemment IPv4 (RFC 791) et le DNS (RFC 1034 et RFC 1035) mais aussi les désormais quasiment abandonnés RARP (RFC 903) ou bien complètement abandonnés comme le serveur de citations (RFC 865) ou comme IP sur ARCnet (RFC 1201). En revanche, HTTP n'y figure pas (le RFC 2616 n'est que « projet de norme ») et SMTP y est représenté par une version dépassée, le RFC 821 (la version actuelle est dans le RFC 2821 mais qui n'est pas considéré comme « norme complète »). Tout ceci décrédibilise sérieusement le classement.

Le RFC contient également la liste des RFC de « bonnes pratiques » comme le RFC 2870 (alias BCP 40) sur le fonctionnement des serveurs de noms de la racine ou comme le RFC 2277 (BCP 18) sur la politique de l'IETF concernant les jeux de caractères et les langues.

Notre RFC 5000 contient aussi des RFC expérimentaux, qui ne sont pas sur le chemin des normes. Il est exceptionnel que, une fois l'expérience terminée, elle soit documentée et que le RFC soit reclassifié en « historique » (une des exceptions est le RFC 3197 qui a documenté l'échec du RFC 1611). On y trouve par conséquent une très longue liste d'expériences assez amusantes comme le défunt RFC 1383 qui tentait de remplacer BGP par le DNS...

Appliquant le cahier des charges qui avait été défini dans le RFC 4058, le protocole PANA vient d'être normalisé dans le RFC 5191 et notre RFC accompagne cette spécification, pour décrire les caractéristiques de haut niveau du protocole.

PANA sert à transporter un protocole d'authentification, typiquement EAP (RFC 3748), entre une machine qui veut accéder à un réseau (la PaC, PANA Client) et une machine d'authentification, le PAA (PANA Authentication Agent). (Ces rôles sont expliqués dans la section 2 du RFC, la section 3 détaillant les différentes communications entre eux.) Après le succès de l'authentification, le PAA indiquera à l'EP (Enforcement Point, typiquement un routeur ou un commutateur) qu'il peut laisser passer le trafic du client, du PaC.

Ces rôles peuvent être situés sur des machines différentes ou pas. Par exemple, en ADSL, le PAA et l'EP seront typiquement situés dans le même BRAS. Le protocole PANA ne spécifie que la communication entre le PaC et le PAA.

À noter que, pour prendre sa décision, le PAA pourra être lui-même client d'un protocole d'AAA comme Radius (RFC 2865) ou Diameter.

PANA a été conçu pour s'adapter à des environnements très différents, notamment du point de vue de la sécurité (section 4 du RFC). Par exemple, il peut y avoir un canal sûr entre le PaC et le PAA, avant même que PANA ne tourne ou pas. S'il existe un tel canal sûr (cas du WiFi avec WPA ou bien cas où la liaison physique entre le PaC et le PAA est considérée comme sûre), PANA est très simple. Dans le cas contraire, il est important d'utiliser des méthodes EAP résistantes à l'espionnage ou à la modification des paquets.

Aujourd'hui, les questions d'identités numériques sont partout sur Internet. Est-il légal de donner un nom qui n'est pas celui de l'état civil lorsqu'on remplit un de ces milliers de formulaires qui existent sur le Web ? Est-ce grave que les contributeurs de Wikipédia soient identifiés par des « pseudos » comme ©éréales Kille® ou Anthere ? Est-ce normal de devoir se souvenir de dizaines de mots de passe différents ? Pourquoi ne pas utiliser son compte Google pour tout, de ma banque en ligne aux blogs où je mets des commentaires ? Si mon avatar dans Second Life tue quelqu'un, suis-je responsable ? Toutes ces questions sont relatives au concept d'identité numérique. La notion d'identité paraissait simple dans le monde physique où beaucoup de gens (à tort selon Olivier Iteanu) l'assimilaient à la seule identité délivrée par l'État. Comment faire désormais sur les réseaux ?

Le livre répond réellement à toutes ces questions et à bien d'autres. Olivier Iteanu est un avocat, expert reconnu des aspects juridiques des NTIC et défenseur des droits des citoyens face à des dangers comme l'utilisation abusive de leurs données personnelles ou comme leur traçage excessif.

Ce livre est court et n'épuise pas la question, qui est très vaste. Mais il éclaire bien des aspects de celle-ci. Mon chapitre préféré est le 4, sur le « pseudo », où Iteanu défend l'idée que le pseudo est une identité valable, reconnue mais soumise à certaines limites (ne pas choisir un pseudo dans le but de tromper, se méfier du droit des marques).

Mais il y a aussi l'intéressante introduction du livre, sur le manque d'un service d'identité générique sur Internet, manque probablement dû (c'est une des hypothèses évoquées) au choix de la simplicité. Des projets comme OpenID tentent d'apporter une partie de la solution de ce manque.

Parmi les autres chapitres utiles, le chapitre 2 est une explication et une défense de l'anonymat, dont Iteanu pense que, bien que légal actuellement, il pourrait être mieux reconnu par la loi. Le chapitre 9 est consacré aux menaces liées à l'usurpation d'identité comme le hameçonnage et le chapitre 10 à la redoutable efficacité du moteur de recherche Google, « plus fort que le casier judiciaire » car il n'oublie rien et n'est soumis à aucun contrôle.

La conclusion du livre est un appel à maîtriser nos identités numériques, plutôt que des les voir créées, copiées et volées par des forces peu sympathiques. Cela implique, dit Iteanu, un vrai droit à l'anonymat, une meilleure définition juridique de l'identité et le déploiement de techniques d'identité décentralisées permettant à chacun de créer et de contrôler ses identités sur le réseau.

Un peu de publicité personnelle pour finir : j'ai fait un article sur OpenID à JRES, article qui place cette technique au milieu des grandes manœuvres sur l'identité numérique. OpenID pourrait être une des briques permettant de construire le système d'identité distribué dont parle Iteanu.

OSPF est le protocole de routage interne de l'IETF. Si RIP est encore utilisé à certains endroits, si des protocoles non-standard, spécifiques à un fabricant de routeurs sont parfois utilisés sur des sites où l'intérêt des normes ouvertes n'a pas été compris, si son concurrent ISO 10589, IS-IS a connu quelques déploiements, OSPF est de loin le plus répandu. Ce RFC est la spécification normative d'OSPF version 2, la version pour IPv4.

Par définition, les IGP, comme OSPF, sont utilisés uniquement à l'intérieur d'un système autonome. Il est donc toujours difficile de produire des statistiques fiables directes, rien ne permettant de dire, vu de l'extérieur, quel IGP utilise une organisation. Mais il n'y a pas de doute qu'OSPF est de loin le plus répandu. Son histoire a parfois été cahotique, et vient d'une grande discussion à l'IETF pour créer un IGP moderne, discussion très chaude qui avait opposé les partisans des protocoles à vecteur de distance, comme RIP aux protocoles à état des liens, comme OSPF. (Christian Huitema, dans son excellent livre « Et Dieu créa l'Internet » décrit ce débat).

OSPF a finalement été normalisé dans le RFC 1131 en octobre 1989, qui connaitra plusieurs successeurs, les plus récents étant le RFC 2178, et son successeur, notre RFC 2328. L'annexe G décrit les différences avec le RFC 2178, aucune n'étant vitale (il s'agit bien du même protocole).

Notre RFC 2328 est un des plus longs jamais publiés par l'IETF, avec presque deux cent pages. Il n'est pas spécialement pédagogique, son but étant de permettre le développement d'implémentations compatibles du protocole. Il ne cherche pas à aider l'administrateur réseau, ni à informer le curieux de passage. La table des matières est déroutante, conçue selon une logique qui a un sens, mais pas celui du nouveau venu. Pour une explication de plus haut niveau (mais pas forcément facile) d'OSPF, on peut consulter le livre écrit par l'auteur du RFC. Pour une présentation plus orientée vers l'ingénieur en charge du réseau, on peut citer mon cours OSPF. Mais, de toute façon, OSPF est compliqué, il ne faut pas se faire d'illusions.

Quels sont les principes de base d'OSPF ? Comme décrit dans le résumé du RFC et dans la section 1, OSPF est un protocole à état des liens (link state et ce terme se retrouve partout dans le RFC). Chaque routeur diffuse par inondation ( flooding) l'état de ses interfaces réseaux et tout routeur connait donc l'état de tout le réseau, tous les routeurs ont la même information. À partir de celle-ci, chaque routeur fait tourner l'algorithme SPF pour trouver les routes à suivre. Le fait que tous les routeurs aient la même information facilite le calcul de routes sans boucles.

Le routage proprement dit se fait ensuite uniquement sur les en-têtes IP, sans encapsulation ultérieure.

Comme le système autonome a en général des connexions avec d'autres systèmes autonomes, certains des routeurs apprennent également des routes par d'autres protocoles comme BGP (RFC 4271) et OSPF permet d'importer ces routes dans la base de données, comme « routes externes ».

OSPF dispose d'un mécanisme hiérarchique, les zones (areas), qui permet de limiter la diffusion de l'information, rendant ainsi ce protocole moins sensible aux changements d'échelle. La règle « tous les routeurs ont exactement la même base de données des états des liens » doit donc être nuancée : elle n'est valable qu'à l'intérieur d'une seule zone.

Tout le vocabulaire d'OSPF est rassemblé dans la section 1.2. Comme souvent avec les documents informatiques en anglais, il n'y a pas une seule traduction en français qui fasse autorité. J'ai repris ici le vocabulaire de mon cours.

Vue la taille du protocole, il est impossible de citer toutes les sections du RFC. Seules celles qui me semblent les plus importantes sont listées ici.

La section 2 du RFC détaille la base des états de liens, le cœur d'OSPF. Sa section 2.1 précise comment sont représentés les routeurs et les réseaux. Ces derniers peuvent être point à point, à diffusion comme Ethernet, ou bien NBMA (Non-Broadcast Multiple Access, qui font l'objet de la section 2.1.1 et pour lesquels les choses sont assez complexes) comme le relais de trames. La représentation du lien dépend du type de réseau auquel le routeur est connecté.

La section 2.1.2 illustre tout ceci avec un exemple de base de données pour un réseau petit mais relativement complexe. La section 2.2 montre ensuite le résultat du SPF sur ce réseau.

La 2.3 explique la modélisation des informations externes, obtenues depuis un autre protocole. Elles sont de deux types, le type 1 pour les informations venant du système autonome (et donc dont le coût peut être comparé aux coûts OSPF) et le type 2 pour les informations extérieures, non seulement à OSPF, mais également au système autonome, et pour lesquelles le coût est toujours supérieur au coût OSPF.

La section 4 décrit le fonctionnement du protocole : chaque routeur OSPF, au démarrage, rassemble les informations sur ses propres interfaces réseau, puis apprend l'existence de ses voisins, et forme une adjacence sur chaque réseau. Il échange ensuite l'information sur l'état des liens avec le routeur adjacent (rappelons que tous les voisins ne sont pas adjacents, seuls le DR - Designated Router - et le BDR - Backup Designated Router le sont).

Cette information sur les états des liens est transmises sous forme d'unités nommés LSA (Link State Advertisment), qui sont transmis par inondation (procédure décrite en détail en section 13), jusqu'à ce que tous les routeurs de la zone aient la même information.

Plus concrète, la section 4.3 normalise le format des paquets OSPF. Celui-ci fonctionne directement sur IP, avec le numéro de protocole 89. Les champs du protocole sont de taille fixe, pour faciliter la mise en œuvre. Les détails du format sont renvoyés à l'annexe A. Le traitement des paquets figure dans la section 8.

La section 5 est dédiée aux différentes structures de données que doit manipuler le routeur OSPF. Par exemple, le Router ID est un entier de 32 bits qui identifie de manière unique un routeur du système autonome. Cet entier est en général représenté avec la même syntaxe qu'une adresse IPv4 (même pour la version d'OSPF conçue pour IPv6). D'autres structures de données sont décrites dans les sections 9 (les interfaces réseaux) ou 10 (les routeurs voisins).

La section 7 explique le protocole par lequel les routeurs OSPF d'un même segment de réseau se trouvent et s'échangent des informations. Tous les routeurs du lien envoient des paquets de type Hello à une adresse de diffusion restreinte, 224.0.0.5 (les valeurs numériques nécessaires au protocole, comme cette adresse, sont dans l'annexe A). Ici, tcpdump montre ces paquets émis par le routeur de Router ID 192.134.7.252, de la zone 0 (l'épine dorsale) :

22:29:04.906209 IP (tos 0xc0, ttl 1, id 22064, offset 0, flags [none], proto OSPF (89), length 64) 192.134.7.252 > 224.0.0.5: OSPFv2, Hello, length: 44
        Router-ID: 192.134.7.252, Backbone Area, Authentication Type: none (0)
        Options: [External]
          Hello Timer: 10s, Dead Timer 40s, Mask: 255.255.255.240, Priority: 1
          Designated Router 192.134.7.252

Sur un réseau à diffusion comme Ethernet, un routeur est élu routeur principal (Designated Router, DR, section 7.3 mais l'algorithme d'élection figure, lui, dans la section 9.4). Les adjacences ne se forment qu'avec lui et tous les échanges OSPF passent par lui (il existe aussi un routeur de secours, le BDR, Backup Designated Router, section 7.4).

La section 12 présente les paquets LSA (Link State Advertisment, ou annonces de l'état des liens), par lesquels les routeurs OSPF se tiennent au courant de leur situation. La section est très longue car il y a beaucoup d'informations possibles à transmettre !

Une fois que les routeurs ont toute l'information nécessaire, ils peuvent faire tourner l'algorithme SPF de Dijkstra et calculer ainsi les routes, selon la procédure que décrit la section 16. (RIP utilisait Bellman-Ford.)

D'autres sections couvrent des parties plus « exotiques » du protocole, moins nécessaires en première approche.

La section 3 est consacrée au découpage en zones. (Notez toutefois que seuls les plus grands réseaux OSPF en ont besoin. Dans un document plus pédagogique, les zones auraient été reléguées à la fin.) Les routeurs d'une zone ne connaissent pas la topologie interne aux autres zones, seulement le moyen de joindre un routeur ABR (Area Border Router, section 3.3) attaché à cette zone. Les zones OSPF sont forcément attachées à une zone principale, numérotée 0 (section 3.1), qui sert d'épine dorsale au réseau.

La section 14 explique le mécanisme d'expiration des LSA dans la base (ils ne restent en effet pas éternellement).

La section 15 spécifie les liens virtuels qui permettent de connecter des parties physiquement disjointes d'une zone.

Les annexes B et C contiennent les paramètres d'OSPF, les valeurs numériques qui gouvernent le comportement du routeur. L'annexe B décrit les constantes, dont la valeur est fixe, comme MaxAge, la durée de vie maximale d'un LSA (fixée à une heure). L'annexe C contient les variables, que l'on peut modifier via la configuration du routeur (attention, il est souvent nécessaire que tous les routeurs du lien, ou bien tous les routeurs de la zone, soient d'accord sur la valeur). Par exemple, avec Quagga, on peut changer Interface output cost (le « coût » d'une interface réseau) en mettant dans le fichier ospfd.conf :

interface xxx0
  ! Ligne lente, son usage est découragé
  ip ospf cost 10000

L'annexe D est consacrée à l'authentification. OSPF trouvant ses voisins par diffusion, un routeur méchant peut assez facilement s'insérer dans un réseau et diffuser de fausses informations. Sur un réseau partagé par plusieurs organisations, par exemple un point d'échange Internet, il n'est pas rare de voir passer des paquets OSPF, émis, espérons-le, suite à une erreur de configuration et pas par malveillance. Pour éviter que les adjacences ne se forment entre deux voisins, OSPF permet d'utiliser un secret partagé que doivent connaitre les routeurs.

Il existe aujourd'hui deux mises en œuvre libres d'OSPF :

• Quagga
• Xorp

mais on trouve évidemment ce protocole dans tous les routeurs, des Cisco aux Juniper en passant par les Vyatta.

Ce livre est un recueil d'articles produits par différents acteurs de la gouvernance Internet un peu partout dans le monde. On n'y trouvera aucune unité, chacun a juste dévelopé un thème qui lui tenait à cœur (comme Latid Latif expliquant qu'IPv6 va sauver le monde). Il n'y a pas non plus grande originalité dans un livre où la plupart des auteurs avaient déjà eu de nombreuses occasions de faire connaitre leur point de vue.

Les articles sont courts et il y a peu de questions originales traitées. Le spectre des idées politiques est large, personne n'a été oublié, ce qui fait qu'un article d'Anriette Esterhuysen de l'APC, qui appelle à l'intervention publique pour s'assurer que tous les citoyens sont connectés, et qui met en garde contre les extensions des privilèges des titulaires de propriété intellectuelle est immédiatement suivi d'un article de George Sadowsky, de l'ISOC, qui explique que seul le Dieu Marché doit être autorisé à intervenir et qu'il est crucial de maintenir et d'étendre les droits déjà exorbitants dont jouissent les titulaires de propriété intellectuelle.

La plupart des articles n'apprendront rien à celui qui a déjà un peu étudié la gouvernance Internet, d'autant plus que la langue de bois est fort active (articles de Vint Cerf ou de Hamadoun Touré). Seuls quelques auteurs se sont aventurés hors de leur domaine habituel (comme Louis Pouzin qui écrit sur les identités numériques).

ROHC est un mécanisme de description des compressions possibles des en-têtes des paquets IP. Ce RFC décrit les profils de compression qui peuvent être utilisés pour un certain nombre des protocoles les plus courants (la définition de ROHC lui-même étant dans le RFC 4995, la section 3 de notre RFC fait quelques rappels).

Mettant à jour les RFC précédents, le RFC 3095, mais aussi les RFC 3843 et RFC 4019, ce RFC est l'état de l'art en ce qui concerne la compression d'en-têtes. La principale innovation est l'utilisation du langage formel ROHC-FN du RFC 4997 (la section 4.2 résume les principaux changements).

Le gros du RFC commence avec la section 5 qui expose les principes de chaque profil. Un canal ROHC relie un compresseur et un décompresseur. Le compresseur indique les changements par rapport aux prévisions, l'absence de changements signifiant au décompresseur qu'il peut appliquer la règle par défaut. Les systèmes de compression en réseau doivent toujours faire un compromis entre la robustesse (qui nécessite de la redondance, donc de ne pas trop comprimer) et l'efficacité (qui impose de supprimer toute la redondance). Voir par exemple la section 5.1.2, qui discute ce compromis.

Enfin, la section 6 contient les profils eux-mêmes, exprimés en partie en ROHC-FN. Cette section contient des fonctions de compression et les règles ROHC-FN qui les utilisent. Parmi les fonctions primitives, qui ne sont pas en ROHC-FN, la section 6.6.6 (fonction inferred_ip_v4_length) dit comment comprimer la champ Length d'IPv4. Étant déductible de la longueur du datagramme, il n'est pas indispensable et peut donc être comprimé à une taille de... zéro bits. La section 6.6.9 décrit une méthode bien plus complexe (fonction timer_based_lsb) pour les champs dont la valeur change approximativement en fonction linéaire du temps (elle nécessite donc que les horloges du compresseur et du décompresseur ne dérivent pas trop l'une par rapport à l'autre).

Un exemple en ROHC-FN est au contraire la définition de la fonction scaled_ts_lsb (qui sert pour RTP), qui s'exprime ainsi :

scaled_ts_lsb(time_stride_value, k)
{
  UNCOMPRESSED {
    timestamp [ 32 ];
  }

  COMPRESSED timerbased {
    ENFORCE(time_stride_value != 0);
    timestamp =:= timer_based_lsb(time_stride_value, k,
                                  ((2^k) / 2) - 1);
  }

  COMPRESSED regular {
    ENFORCE(time_stride_value == 0);
    timestamp =:= lsb(k, ((2^k) / 4) - 1);
  }
}

L'annexe A est une excellente étude des en-têtes de divers protocoles, avec une classification de leur comportement, selon qu'il permet la compression ou pas. C'est une lecture recommandée pour tous ceux qui s'intéressent à la compression d'en-têtes mais n'ont pas envie de relire le RFC original du protocole. Ils trouveront résumées de façon claire les caractéristiques de chaque champ de l'en-tête. Par exemple, pour IPv6 (annexe A.2) :

• Version is STATIC-KNOWN c'est-à-dire constante pour toute la durée du flot et à une valeur « bien connue », en l'occurrence 6.
• Hop Limit est RACH (RArely CHanging), c'est-à-dire changeant rarement (ce nombre ne bouge que lorsque les routes sont modifiées)
• Source Address est STATIC-DEF, c'est-à-dire constant pour toute la durée du flot et pouvant d'ailleurs servir à définir le flot.

Il n'existe apparemment pas d'implémentation libre de ROHC. Mais plein de déploiements sont déjà faits dans les téléphones portables. La thèse d'Ana Minaburo contient une bonne introduction à ROHC.

Complétant la série des RFC sur DNSSEC, ce RFC 4034 décrit les types d'enregistrements utilisés par ce protocole, DNSKEY, RRSIG, DS et NSEC.

DNSSEC, décrit dans les RFC 4033 et RFC 4035, permet de signer cryptographiquement les enregistrements DNS de faon à garantir leur authenticité. Pour cela, DNSSEC ne modifie pas le format des paquets DNS, mais il ajoute plusieurs types d'enregistrement nouveaux. Notre RFC fait partie de la série de RFC qui décrit DNSSEC-bis (la première version de DNSSEC, assez différente, n'ayant eu aucun succès) et il succède au RFC 2535.

La plupart des exemples ci-dessous ont été obtenus pour la zone sources.org qui est désormais signée. Vous pouvez interroger en DNSSEC ses serveurs de noms (dig NS sources.org. vous en donnera la liste).

Chacun des nouveaux types d'enregistrement va faire l'objet d'une section. La section 2 est consacrée à DNSKEY, les clés publiques des zones. Un de ces enregistrements stocke notamment l'algorithme de chiffrement utilisé et la clé. La représentation texte officielle (chaque type d'enregistrement DNS a une représentation binaire, utilisée sur le câble, et une représentation texte, utilisée par exemple dans les fichiers de zone de BIND), décrite en section 2.2, affiche la clé encodée en Base64 :

sources.org.                        86400   DNSKEY  256 3 3 (
   CL9vwM+5gCMZdycMOYJQ7lSspHDTsaZmZkDR
   l+KNx/VytmbPSfcdYmhJJHyTdGpzqXmm6qEd
   4Kpyqbd59RXv9JCVVM3MntiX/hruxbB3WsV0
   hlVej1IuWFDncJFLWhaD9UjgGm+UoqlQJGVJ
   rGZf7KvwL4iKZhr1fiDEJFD7e9cxU8dojhHp
   mmAOZLjEYKytDMB0rj8/Mnm5cVVu29UFS+0y
   jvkdbQD0EJ9FwF/8MwG4DHj6ZtFwxeNp2NCD
   6oj0kxDi5ktY0rQtSv506aAMmGBqS6tNno+g
   9KgCLZ5jk5e8fpl9Rlmd2SlVMAyf8E3C9joB
   ZqCqYX+VcooSrcvgn/4m6CTDPxK+DuE+KW5/
   NiE062MKdID7xAxiCj14Suj9K9TKL60buuFa
   gJ3qTjhS5C62uPk8U9+zHpQ0qjcb0gv3/M+l
   RcXi46g0OF17cTLy83lgU6s2ApMmaboeUbm2
   3lfCEl8B6R2BhE98mfoDNg+Xlj63X8w93LCo
   XP/c1SZivNolol/Ky6apULe3euFuwdOFfYCR
   ) ; key id = 55957

Ici, la clé 55957 utilise DSA/SHA-1 (valeur 3). Ces clés peuvent être générées, par exemple, par le programme dnssec-keygen, qui fait partie de BIND. Bien lire la liste des algorithmes utilisables pour une zone dans l'annexe A.1 sinon, on aura un message du genre a key with algorithm 'HMAC-SHA256' cannot be a zone key.

Les enregistrements RRSIG sont le cœur de DNSSEC, puisqu'ils stockent les signatures des autres enregistrements. Ce sont les RRSIG que vérifie un validateur DNSSEC. Un enregistrement RRSIG contient notamment :

• le type de l'enregistrement couvert par la signature,
• l'algorithme de chiffrement utilisé (la liste des algoritmes possibles à l'origine figure dans l'annexe A.1 et la liste actuelle est maintenue par l'IANA),
• les dates de signature et d'expiration,
• la signature elle-même.

Sous la forme texte décrite en section 3.2, voici un tel enregistrement :

laperouse.sources.org.  86400   IN MX   10 aetius.bortzmeyer.org.
                        86400   RRSIG   MX 3 3 86400 20080522104407 (
                                        20080422104407 55957 sources.org.
                                        CIxBOzsaxBexcAQQE1ukqNfBz5yDnPBVhgxr
                                        MNR7FrfM2iH/AOWoO/8= )

Ici, ce RRSIG signe un MX.

La section 4 est consacrée à NSEC, un type d'enregistrement qui va résoudre un problème délicat, la « preuve de non-existence ». En effet, DNSSEC fonctionne en joignant une signature aux enregistrements existants, ce qui permet de prouver leur existance. Mais si un nom n'existe pas et que le serveur veut renvoyer NXDOMAIN (No Such Domain) ? On ne peut pas signer un enregistrement qui n'existe pas. La solution DNSSEC est de créer des enregistrements NSEC qui sont signés et qui indiquent l'enregistrement suivant (l'ordre est défini dans la section 6, c'est simplement l'ordre des codes ASCII). Ainsi, si je demande nexistepas.example.org et que je récupère :

lulu.sources.org.    43200   IN      NSEC    patou.sources.org. AAAA RRSIG NSEC

je sais que nexistepas.sources.org n'existe pas, puique le NSEC ci-dessus me garantit qu'il n'y a rien entre lulu et patou.

Un autre type d'enregistrement permettant la « preuve de non-existence », le NSEC3, est décrit dans le RFC 5155. En effet, le NSEC a un gros inconvénient, il permet l'énumération complète de la zone, en suivant simplement les NSEC. Cette faiblesse des NSEC est une des raisons pour lesquelles DNSSEC n'a pas été d'avantage déployé.

C'est très bien de signer sa zone mais ensuite, comment les résolveurs partout dans le monde vont-ils connaitre sa clé ? Ils ont pu l'obtenir par un autre moyen et la mettre dans leur configuration (ce qu'on nomme une trust anchor). Mais un tel mécanisme ne se généralise évidemment pas à tout l'Internet. Il faut donc un seul trust anchor, la clé de la racine (DLV, décrit dans le RFC 5074, permet que la racine DNSSEC ne soit pas forcément la racine classique) et un système de délégations. Ces délégations sont mises en œuvre par les enregistrements DS, décrits en section 5. Ces enregistrements contiennent un condensat cryptographique de la clé :

sources.org.            IN DS 55957 3 1 A12F149F84B34E09501C32CC9F984FB9E1ED196A

Ici, 55957 est l'identité de la clé, 3 l'algorithme de la clé et 1 celle du condensat (SHA-1, la liste complète est maintenue par l'IANA).

HIP, par défaut, nécessite que l'initiateur d'une association connaisse le localisateur, l'adresse IP du répondeur. Si celui-ci bouge souvent, et qu'il n'est donc pas pratique de mettre cette adresse dans le DNS, une solution est d'utiliser le mécanisme de rendez-vous, décrit par ce RFC, où l'initiateur contacte un serveur de rendez-vous qui relaie vers le répondeur.

Le schéma est clairement expliqué dans la section 3 du RFC. En fonctionnement habituel de HIP, l'initiateur trouve l'identificateur et le localisateur du répondeur (typiquement, dans le DNS, cf. RFC 5205), puis le contacte directement. Si le localisateur n'est pas connu (ce qui est fréquent si le répondeur est un engin mobile, changeant souvent d'adresse IP), l'initiateur envoie le premier paquet (I1) au serveur de rendez-vous, qui le relaie au répondeur. Les autres paquets (R1, I2 et R2) seront transmis directement entre les deux machines HIP. Le mécanisme est détaillé dans la section 3.3 (il faut notamment procéder avec soin à la réécriture des adresses IP, en raison entre autre du RFC 2827).

Et comment l'initiateur trouve t-il le serveur de rendez-vous ? En général dans le DNS, via les enregistrements de type HIP. Et comment le répondeur avait-il fait connaitre au serveur de rendez-vous son adresse IP ? Via le protocole d'enregistrement du RFC 5203, comme l'explique la section 4.

HIP, décrit dans ce RFC, est un protocole très ambitieux, puisqu'il vise à compléter IP en fournissant une séparation de l'identificateur et du localisateur, permettant d'améliorer la sécurité (notamment la résistance aux DoS) et de mieux gérer la mobilité et le multi-homing.

L'architecture générale de HIP est décrite dans le RFC 4423. Notre RFC normalise, lui, le protocole concret. HIP repose d'abord sur la séparation entre un nouvel identificateur, le HI (Host Identifier) et un localisateur, plus concret, qui sera simplement l'adresse IP, réduite à un rôle moins visible, sans exigence de stabilité. Par exemple, HIP permettra le changement de localisateur (d'adresse IP) en cours de connexion, sans rompre celle-ci, ce qui sera précieux pour la mobilité.

HIP est donc déployable uniquement en modifiant les machines terminales du réseau (si les coupe-feux le laissent passer), sans toucher aux routeurs . Il en existe des mises en œuvres pour FreeBSD et Linux. Le projet OpenHIP adapte également des logiciels comme Wireshark pour qu'ils aient un support HIP. InfraHIP travaille également à l'infrastructure HIP. L'article HIP Implementation for FreeBSD donne des détails intéressants sur la mise en œuvre de HIP, notamment sur les questions liées à l'API.

Si on ne veut pas lire le RFC 4423, on peut néanmoins avoir une bonne introduction à HIP en lisant les sections 1 et 2 de ce RFC. Elles expliquent le vocabulaire (par exemple, HIP, étant un protocole situé en haut de la couche 3 n'utilise pas le terme de connexion mais celui d'association), le nouvel espace de nommage et les principes du protocole.

L'espace de nommage fait l'objet de la section 3. On distingue les HI (Host Identifier), qui sont des clés publiques d'un couple clé privée / clé publique et qui sont de taille variable, et les HIT (Host Identifier Tag, décrits dans la section 3.1), qui sont un résumé cryptographique des HI. Ils sont de taille fixe (donc plus faciles à traiter), 128 bits, la taille d'une adresse IPv6. Un préfixe ORCHID (RFC 4843), le 2001:10::/28, sert à éviter toute collision avec les « vraies » adresses IPv6. Avec OpenHIP, la clé peut être générée par le programme hitgen qui fabrique un fichier XML ressemblant à ceci :

<?xml version="1.0" encoding="UTF-8"?>
<my_host_identities>
  <host_identity alg="RSA" alg_id="5" length="128" anon="no" incoming="yes" r1count="10">
    <name>horcrux-1024</name>
    <N>C6EBA2894C33A1312B38853A8ECC0D7967496237A65529807EDF23C4DA753EE88F8FBF71BE38B6910181D5B75DB075B9962326D9BB50C65121DBFD712F1B7F4E2B035953AD650EB5C96B56295FE2731B3B36E8AFED7FB5CD48B73C31A224D4CE4F097D84888EC2E3CA8F3A78939D89B7BCFC5E6DEEAF670695349BFFFE8445F1</N>
    <E>010001</E>
    <D>383A51165838DBDE872611DACC94775692D09677BE87A214954843D7181D3E2C04B0905FF9721481069909AD2C497DED78B7F4FA64CD5F517DADAE8538D89FF21B0498A72F1132545328ABD371B1BAC8ED46441D900921523B78BA55F3FC227F432F2061C92CE9665CB99C1CF425AA90CFC6345FA4E7DA43E477EAF69F86A801</D>
    <P>FF03F93454C9C2D8EC47FE8C9DBF0D82F05E13905F304A5ACA42C45E579F917B4C8CEFEF6B06AAB9BCB7A911D5514B7AEE685DA91E7CC60DDC4C37BA94A22E71</P>
    <Q>C7B0394EB5506B2B75E19E5654262E843659BB76A465C2A7AC47A430749944378E3161FF805B4C6CB037B5CB111F0EF49FF03047FB1CFC51DC0D72DEDAD64F81</Q>
    <dmp1>7426C128DEBD8EEBF2A2D004080D6F0006AF32C5FD352788B6BB3669AA0B59DE08FDE082F202755C67E25735722DB6ED650D502BA961376C34BCDA5D3739AF61</dmp1>
    <dmq1>1B97DE5361FA9AD4869586ABA7351F78658A40BD443A4B8B9FE2C66D6BAF421DEB2827C2869A17156DC444FAAA83002E0D6BC3402F12F24ADD7D7E420D3B5001</dmq1>
    <iqmp>7499A27F59CA1746F1A6E5DE832592F8ACF80B814DD511C490614C44DC92B5CD1650AC944ED5751F28846487C221E8C17E68264DFEF748B86E38EB1F238D94A9</iqmp>
    <HIT>2001:1f:cd4:7125:2427:f77c:d1b6:e15f</HIT>
    <LSI>1.182.225.95</LSI>
  </host_identity>
</my_host_identities>

Notez bien que le fait d'utiliser XML est un choix de OpenHIP, qui n'est utilisé qu'en local. Il n'est pas imposé par la norme qui, sur le câble, n'utilise que du binaire. Les éléments comme P, Q ou iqmp sont les éléments d'une clé RSA (HIP peut utiliser d'autres formats que RSA). Le HIT est représenté en utilisant la syntaxe des adresses IPv6, puisqu'il a la même taille et a été conçu pour être stocké comme une adresse par les applications.

La section 3.2 explique comment générer un HIT à partir du HI. Étant un résumé cryptographique (fait avec SHA-1), il est sûr, on ne peut pas fabriquer facilement un HI qui aurait le même HIT.

Pour signer les paquets, les deux machines utiliseront au début un échange de Diffie-Hellman.

La section 4 donne une vision générale du protocole, qui sera ensuite détaillée dans les sections ultérieures. HIP a reçu le numéro de protocole 139.

La section 4.1 décrit comment former une association entre deux machines HIP. Celle qui demande l'association est nommée l'initiateur, celle qui l'accepte le répondeur. Le protocole d'association nécessite quatre paquets. En effet, avec seulement trois paquets, comme le fait TCP (RFC 793) lors de l'établissement d'une connexion (Three-way handshake), on ne peut pas à la fois se protéger contre les DoS et permettre des options par connexion. Se protéger contre les DoS nécessite de ne pas garder d'état tant que le pair n'est pas authentifié, même faiblement. Les techniques qui permettent à TCP de ne pas garder d'état sur le « répondeur », telles que les SYN cookies du RFC 4987 sont incompatibles avec les options TCP.

Voici pourquoi les protocoles plus récents comme SCTP (RFC 3286) ou comme HIP nécessitent quatre paquets.

Dans HIP, ils sont nommés I1, R1, I2 et R2. Les paquets I sont envoyés par l'initiateur et les paquets R par le répondeur.

L'établissement d'une association se passe donc comme ceci :

• L'initiateur envoie I1 au répondeur. Le paquet contient l'identificateur (le HIT) du répondeur et (optionnellement) celui de l'initiateur. Aucun état n'est créé chez le répondeur.
• Le répondeur envoie R1. Ce paquet contient un puzzle cryptographique que l'initiateur devra résoudre. Il contient également les paramètres de la session Diffie-Hellman. Et ce paquet est signé.
• L'initiateur envoie I2, qui contient la solution du puzzle. les paramètres Diffie-Hellman de l'initiateur. Ce paquet est signé.
• Le répondeur envoie R2 pour accepter l'association. Ce paquet est signé.

Le puzzle, détaillé en section 4.1.1, est un petit problème de calcul que l'initiateur doit résoudre pour montrer qu'il est près à « payer », à faire un effort pour que l'association soit acceptée. La difficulté du puzzle peut être réglée par le répondeur. En pratique, il est très difficile d'imaginer un puzzle qui soit dissuasif contre des attaquants disposant d'un botnet entier, tout en étant soluble par des appareils simples, genre téléphone portable, ne possédant guère de puissance de calcul. (La section 4.1.1 détaille ce problème et les solutions possibles.)

La section 4.1.3 détaille l'utilisation du Diffie-Hellman.

Une des grandes forces de HIP est la possibilité de mettre à jour une association existante (section 4.2). À tout moment, pendant la session, un paquet de type UPDATE peut être envoyé pour changer certains paramètres de la session, comme les localisateurs (les adresses IP) utilisées. La signature des paquets permet de s'assurer que le paquet UPDATE est authentique.

La section 5 est longue car elle détaille le format, bit par bit, de to