Mon blog

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, 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 tous les paquets échangés. Il y a huit types de paquets (section 5.3) comme I1, R1, I2, R2 ou comme UPDATE, présenté plus haut.

Enfin, la section 6 détaille le traitement des paquets, ce qu'il faut faire en les recevant, les erreurs et la façon de les gérer (règle simple : ne pas renvoyer de paquets HIP en cas d'anomalie, seulement des ICMP, et avec un débit limité, car on ne peut pas être sûr du pair s'il y a une erreur), etc.

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.

Le protocole HIP n'avait pas encore de mécanisme pour trouver l'identificateur d'une machine distante. C'est désormais chose faite grâce à ce RFC qui permet de trouver l'identificateur dans le DNS.

HIP fait partie de la famille des protocoles qui visent à séparer l'identificateur du localisateur. Les identificateurs HIP se nomment les HI (Host Identifier) et, jusqu'à présent, le seul moyen de trouver l'HI d'une autre machine était d'attendre qu'elle vous contacte, ou bien de le configurer manuellement. Désormais, avec ce RFC, on peut trouver l'HI, comme une adresse IP, dans le DNS.

Notre RFC crée donc un nouveau type d'enregistrement DNS, nommé logiquement HIP, qui stocke, en échange d'un nom de domaine, le HI, son résumé cryptographique - le HIT (Host Identifier Tag) - et les éventuels serveurs de rendez-vous, serveurs qui, dans le protocole HIP, servent d'intermédiaires facultatifs lorsqu'on veut contacter une machine distante (cf. RFC 5204).

Notre RFC permet de trouver l'identificateur à partir du nom mais pas le localisateur ; les serveurs de rendez-vous sont une solution possible pour cela ; une autre est d'utiliser les traditionnels enregistrements A et AAAA du DNS, le localisateur HIP étant une adresse IP.

Curieusement (pour moi), le HIT est donc stocké dans les données DNS, alors que celles-ci n'offrent aucune sécurité au point que le RFC exige en section 4.1 de recalculer le HIT qui vient d'être obtenu dans le DNS.

Le tout ressemble donc aux enregistrements IPSECKEY du RFC 4025, ce qui est normal, le HI étant une clé cryptographique publique.

Voici un exemple d'enregistrement HIP tel qu'il apparaitrait dans le fichier de zone de BIND. On y trouve l'algorithme cryptographique utilisé (2 = DSA), le HIT (en hexadécimal), le HI (encodé en Base64) et les éventuels serveurs de rendez-vous (ici, deux, indiqués à la fin) :

www.example.com.      IN  HIP ( 2 200100107B1A74DF365639CC39F1D578
                                AwEAAbdxyhNuSutc5EMzxTs9LBPCIkOFH8cIvM4p
9+LrV4e19WzK00+CI6zBCQTdtWsuxKbWIy87UOoJTwkUs7lBu+Upr1gsNrut79ryra+bSRGQ
b1slImA8YVJyuIDsj7kwzG7jnERNqnWxZ48AWkskmdHaVDP4BcelrTI3rMXdXF5D
                                rvs1.example.com.
                                rvs2.example.com. )

L'ensemble du RFC est assez court, ce mécanisme d'annuaire qu'est le DNS étant simple et bien connu.

Régulièrement, un nouveau RFC vient enrichir la grande famille des URN (RFC 2141 et RFC 3406, qui décrit les règles d'enregistrement), ces identificateurs prévus pour être stables et pérennes. Cette fois, les URN ogc viennent s'ajouter, pour stocker les normes et schémas de l'Open Geospatial Consortium.

Ce consortium produit des normes utilisés dans le monde de la géographie comme le format GML et qui servent à communiquer des informations spatiales, utilisées dans de nombreux secteurs (sections 1 et 5 du RFC).

Les URN de l'OGC utiliseront le NID (Namespace IDentifier) ogc. Ce NID sera suivi d'un type de ressource et des coordonnées de la ressources (section 2). L'OGC mettra en place un résolveur permettant de transformer ces URN en URI, à l'adresse http://urn.opengis.net/. Le reste de la section décrit les procédures de l'OGC, notamment pour garantir l'unicité de ces URN.

Un exemple des nouveaux URN (section 3) est urn:ogc:specification:gml:doc-is(02-023r4):3.0.0 qui identifiera une version particulière de la norme GML (d'où l'utilisation de la ressource « specification »).

Les URI disposent depuis longtemps d'un moyen de désigner une partie d'un document, par les biais des « identificateurs de fragments », précédés d'un dièse, comme par exemple http://www.example.org/foobar.html#section3. Entièrement interprétés par le client Web, ces identificateurs étaient définis seulement pour XML et HTML et notre RFC ajoute le texte brut.

La façon classique d'utiliser ces identificateurs est de modifier le document cible pour y ajouter un élément à viser, par exemple :

<p id="avertissement-sante">Fumer est dangereux pour la santé.</p>

fera qu'un navigateur pourra, lorsqu'on lui demandera http://www.example.org/document.html#avertissement-sante, aller directement à ce paragraphe. On peut aussi utiliser, au lieu d'un simple nom comme avertissement-sante, utiliser une expression XPath, si le navigateur accepte XPointer. En outre, avec XLink, on peut même pointer vers un document qu'on ne peut ou ne veut modifier, ce qui évite de devoir ajouter des attributs id ou name.

Le texte brut (normalisé dans MIME par le RFC 2046) n'étant pas, lui, structuré, on ne pouvait pas compter sur des « marques » particulières. D'où le choix de notre RFC de compter les caractères ou bien les lignes.

C'est ainsi que les URI de ce RFC ressembleront à http://library.example/2007/11/5311.txt#char=6234 (le curseur du navigateur ira sur le 6234ème caractère) ou bien http://library.example/2004/03/228.txt#line=534,580 (le navigateur affichera le texte compris entre la 534ème ligne et la 580ème).

Mais les documents accessibles sur le Web tendent à changer. De tels identificateurs de fragments sont clairement moins robustes que ceux utilisant un attribut du document XML (comme avertissement-sante plus haut), ou bien que ceux utilisant une expression XPath. Comment détecter le cas où un paragraphe a été ajouté, faussant ainsi les liens ? Cette norme permet d'ajouter à l'URI un mécanisme de contrôle d'intégrité, en indiquant la longueur ou bien la somme de contrôle MD5 (RFC 1321) du document. Si elles ne correspondent pas, le navigateur sait qu'il ne doit pas utiliser l'identificateur de fragment. Ainsi, http://www.myblog.example/2006-12/mespensees.php#line=50;length=19576,UTF-8 amènera le navigateur à compter le nombre de caractères du document et à ignorer l'identificateur de fragment s'il ne trouve pas 19576 caractères.

Notre RFC doit aussi traiter des problèmes plus subtils comme la façon de compter les fins de ligne du document (il existe plusieurs façons de les représenter, et la norme décide qu'une fin de ligne compte toujours pour un caractère).

Un autre problème subtil est la nécessité de tenir compte de l'encodage des caractères. En effet, char= compte bien le nombre de caractères, pas le nombre d'octets.

Deux implémentations existent, une dans Amaya et une en Python, incomplète mais quand même utile: TextFrag.py.

À noter aussi une présentation par un des auteurs et un amusant et intéressant article de Tim Bray, Matthew-6:9.txt#line=,1.

La sécurité du protocole BGP, par lequel les routeurs Internet échangent l'information sur les routes existantes, est depuis longtemps un sujet de préoccupation. Actuellement, BGP (RFC 4271) n'offre quasiment aucune sécurité contre les usurpations (un routeur annonce une route qu'il n'a pas « le droit » d'annoncer, comme lors de la récente usurpation perpétrée par Pakistan Telecom). Pourquoi ne valide t-on pas les routes annoncées ? En partie parce que c'est plus compliqué que ça n'en a l'air, comme l'explique ce récent RFC.

Beaucoup de gens, étonnés qu'un technicien incompétent à Karachi puisse stopper l'activité d'un site Web stratégique et essentiel uniquement en détournant son trafic grâce à BGP, réclament des mesures drastiques et notamment la validation des routes annoncées par BGP. Certains opérateurs, rares, font une validation partielle, en général basée sur le contenu des IRR. Pourquoi cette pratique n'est-elle pas plus répandue ?

Les mécanismes existants de sécurité comme BGP-MD5 (RFC 2385) ne sécurisent que le canal de communication entre deux routeurs. Ils permettent d'être sûr de l'identité du pair BGP, mais pas de valider ce qu'il annonce. Le routeur de Pakistan Telecom était authentique, il était aussi menteur et BGP-MD5 ne protège pas le message, uniquement le canal.

Notre RFC fait donc la liste des points à vérifier lors d'une validation. Le premier (section 1.1) est évidemment de savoir si l'AS d'origine est autorisé à annoncer cette route. C'est un point crucial mais qui n'est pas le sujet de notre RFC, qui se consacre au devenir ultérieur de cette annonce. Plusieurs autres questions sont ensuite posées dans le RFC. Par exemple, la section 1.3 demande « Est-ce que l'annonce par un routeur qui n'est pas de l'AS d'origine est autorisée ? » et explique que la question est bien plus subtile qu'elle ne le semble puisqu'il y a en fait trois sous-questions derrière cette question apparemment simple :

• L'autorisation d'annoncer une route particulière, par exemple 192.0.2.128/25 (route authorization).
• L'autorisation d'annoncer un préfixe qui inclus la route, par exemple 192.0.2.0/24 (reachability authorization).
• L'autorisation de faire transiter les paquets par son réseau (transit authorization).

Ces trrois autorisations, à première vue équivalentes, peuvent en fait donner des résultats différents, comme le montrent les exemples ultérieurs.

Citons uniquement un exemple, présenté en section 2.2, qui exploite le fait que le route réellement empruntée n'est pas contrôlé par la source mais par chaque AS intermédiaire. Un AS annonce à son voisin une route avec un chemin d'AS, mais, en interne, il a une route statique qui prend un autre chemin. L'annonce est-elle valide ? L'AS annonceur était autorisé à annoncer cette route (route authorization et reachability authorization) mais il est impossible de déterminer s'il y avait transit authorization puisque le chemin réellement emprunté n'apparait pas dans l'annonce.

Globalement, ce RFC fait à mon avis œuvre utile en expliquant la complexité du routage Internet. Il donne parfois un peu trop dans le pinaillage en montant en épingle des cas intéressant mais très rares. Le vrai problème de la validation des routes en BGP est plutôt l'absence d'un système de « droit d'usage » permettant de savoir qui a le droit d'annoncer telle route. Sans un tel système, les protocoles sécurisés de diffusion de routes (qui existent, et reposent sur la cryptographie) n'ont rien sur lequel se baser. (Un groupe de travail de l'IETF, RPSEC, travaille actuellement à un cahier des charges pour un routage sécurisé.)