Mon blog

Ce curieux RFC répond à une question apparemment paradoxale : comment tirer au hasard de manière publiquement vérifiable ? Par exemple, les membres d'un des comités de l'IETF, le Nomcom, sont choisis au hasard. Comment permettre à tous les participants à l'IETF de vérifier que le tirage était bien aléatoire, alors que l'opération se fait sur l'Internet, sans qu'on puisse vérifier le dé ou la roulette ?

Une solution traditionnelle est de désigner une autorité arbitraire, considérée comme digne de confiance, et dont on n'a pas le droit de remettre l'honnêteté en doute. C'est ce que font toutes les loteries qui se déroulent « sous contrôle d'huissier ». Une telle méthode, basée sur la confiance aveugle en une entité particulière, ne colle pas avec la culture IETF.

Une autre méthode est proposée par notre RFC 2777. Utiliser un certain nombre de sources d'entropie, publiquement consultables, et les passer à travers une fonction de hachage qui garantira la dispersion des résultats, rendant ainsi très difficile d'influencer ceux-ci. Et chacun pourra faire tourner l'algorithme chez lui, vérifiant ainsi que le résultat est honnête.

La section 1 du RFC rappelle le problème original, la désignation du Nomcom (Nominating Committee, cf. RFC 2727) de l'IETF. Mais, depuis, la méthode de ce RFC a été utilisée dans bien d'autres cas.

La section 2 décrit les étapes à suivre :

• Identifier les candidats possibles (le RFC décrit le cas du Nomcom mais cette étape existe pour toute désignation),
• Publication de l'algorithme et des sources d'entropie utilisées, pour permettre la future vérification. Cette étape est indispensable car la possibilité de tous les participants de contrôler eux-même l'honnêteté du processus est vitale. (À noter que c'est justement cette possibilité qui est retirée au citoyen dans le cas de mesures anti-démocratiques comme le vote électronique.)
• Faire tourner l'algorithme et publier le résultat.

Ça, c'était le principe général. Maintenant, le gros problème est évidemment le choix de bonnes sources aléatoires. Toute la section 3 est vouée à cette question. La source doit produire un résultat qui ne peut pas être facilement influencé et qui doit être accessible publiquement. (La section 6 détaille les problèmes de sécurité.)

La section 3.1 analyse les sources possibles et en identifie trois :

• Les loteries sérieusement organisées, notamment celles faites par l'État. Notez qu'une loterie particulière peut être truquée mais, d'une part, l'algorithme repose sur plusieurs sources, d'autre part les gens qui sont prêts à truquer une loterie le feront plutôt pour des gains financiers, pas pour perturber l'IETF.
• Les résultats financiers comme le prix de vente d'une action à la clôture de la Bourse ou le volume d'actions échangée en une journée. Ce ne sont pas des nombres aléatoires mais leur valeur dépend des actes de beaucoup d'opérateurs séparés, en pratique, le résultat exact sera imprévisible.
• Les événements sportifs mais ils posent pas mal de problèmes pratiques comme les risques d'annulation ou de retard.

Attention à ne pas mettre les plus mauvaises sources en dernier, car, avec la connaissance des autres sources, publiées avant, un attaquant qui peut influencer la dernière source aurait un pouvoir excessif.

On pourrait penser qu'il faut multiplier le nombre de sources, pour limiter le pouvoir de nuisance d'une source manipulée. Mais le RFC note que le mieux est l'ennemi du bien : chaque source supplémentaire est également une source de problème, par exemple si elle ne produit aucun résultat (évenement annulé, par exemple). Il recommande environ trois sources.

Aucun des types de source cités plus haut ne produit une distribution uniforme. C'est une des raisons pour lesquelles on doit les faire passer à travers une fonction de hachage (cf. RFC 4086) pour obtenir cette uniformité. Une autre raison est que, pour certaines sources, leur valeur approximative peut être influencée (le cours en Bourse d'une action peut grimper ou descendre selon la volonté d'un gros opérateur) mais pas la totalité des chiffres. Le hachage empêchera donc ledit influenceur d'obtenir le résultat qu'il désire (section 3.2).

La section 3.3 calcule la quantité d'entropie nécessaire pour sélectionner P vainqueurs parmi N possibilités. Par exemple, pour 100 candidats et 10 places, il faut 44 bits d'entropie. (À noter que la fonction de hachage MD5, utilisée par notre RFC en suivant le RFC 1321 ne fournit « que » 128 bits d'entropie.)

Un algorithme détaillé est ensuite présenté en section 4. Les valeurs obtenues des diverses sources sont transformées en chaînes de caractères (en les séparant par des barres obliques). Ce sont ces chaînes qui sont ensuite condensées par MD5. Un exemple complet figure dans la section 5. Notez la précision avec laquelle les sources sont définies !

Une mise en œuvre de référence figure en section 7. Je l'ai rassemblée dans une archive tar. On la compile ainsi :

% make
cc -c -o rfc2777.o rfc2777.c
cc -c -o MD5.o MD5.c
cc -lm -o rfc2777 rfc2777.o MD5.o
rfc2777.o: In function `main':
rfc2777.c:(.text+0x16a): warning: the `gets' function is dangerous and should not be used.

et on l'utilise ainsi (sur l'exemple de la section 5) :

% ./rfc2777 
Type size of pool:
(or 'exit' to exit) 25
Type number of items to be selected:
(or 'exit' to exit) 10
Approximately 21.7 bits of entropy needed.

Type #1 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
9 18 26 34 41 45
9 18 26 34 41 45 
Type #2 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
2 5 12 8 10
2 5 8 10 12 
Type #3 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
9319
9319 
Type #4 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
float 13.6875
13.6875

Type #5 randomness or 'end' followed by new line.
Up to 16 integers or the word 'float' followed by up
to 16 x.y format reals.
end
Key is:
 9.18.26.34.41.45./2.5.8.10.12./9319./13.6875/
index        hex value of MD5        div  selected
 1  746612D0A75D2A2A39C0A957CF825F8D  25  -> 12 <-
 2  95E31A4429ED5AAF7377A15A8E10CD9D  24  ->  6 <-
 3  AFB2B3FD30E82AD6DC35B4D2F1CFC77A  23  ->  8 <-
 4  06821016C2A2EA14A6452F4A769ED1CC  22  ->  3 <-
 5  94DA30E11CA7F9D05C66D0FD3C75D6F7  21  ->  2 <-
 6  2FAE3964D5B1DEDD33FDA80F4B8EF45E  20  -> 24 <-
 7  F1E7AB6753A773EFE46393515FDA8AF8  19  -> 11 <-
 8  700B81738E07DECB4470879BEC6E0286  18  -> 19 <-
 9  1F23F8F8F8E5638A29D332BC418E0689  17  -> 15 <-
10  61A789BA86BF412B550A5A05E821E0ED  16  -> 22 <-

Done, type any character to exit.

On note l'affichage de la clé (les valeurs séparées par des barres obliques) et celui du nombre de bits d'entropie nécessaires.

Outre les exemples de sélection du Nomcom qu'on trouve dans le RFC, cette méthode a été utilisé pour sélectionner le préfixe xn-- des IDN. Voici la description de la méthode et l'annonce du résultat.

Un autre exemple intéressant sera l'utilisation de ce RFC 2777 pour sélectionner les /8 à donner aux RIR lors de l'épuisement final des adresses IPv4.

L'infrastructure juridique des « nouveaux » RFC, désormais répartis en plusieurs voies selon leur source, continue à se mettre en place. Ce RFC 5744 décrit les procédures pour les droits liés aux RFC soumis par la voie « indépendante » (RFC soumis par un individu, ni l'IAB, ni un groupe de travail de l'IETF). Actuellement, il existe des dizaines de documents approuvés techniquement, qui attendent dans la file du RFC Editor car ils ont été soumis par cette voie et son statut n'a pas été clarifié depuis le déploiement des « nouveaux » RFC (RFC 5620). Sans doute vont-ils enfin être publiés mais on ne sait pas encore quand.

C'est que la publication d'un RFC, acte essentiellement technique au début, est devenue une grosse affaire juridico-politique. Des centaines de pages de discussions juridiques ont été noircies sur les problèmes de droits donnés par les auteurs (incoming rights, cf. RFC 5378) et les droits (forcément inférieurs ou égaux) que reçoivent les lecteurs (outgoing rights, cf.RFC 5377). Ces deux derniers RFC ne concernaient que les documents produits par l'IETF et, depuis, les documents produits par des individus languissaient sans statut et ne pouvaient être publiés.

Après tant de débats, il est ironique de constater que la procédure pour les RFC « indépendants » est finalement très proche de celle des RFC « IETF ».

Pour se saisir du contexte, la section 2 de notre RFC 5744 rappelle que le systèmes des voies (streams) a été défini dans les RFC 4844 (et RFC 4846, spécifiquement pour la voie indépendante). Cette dernière est une vieille tradition, et permet de publier des RFC qui sont proposés par des individus isolés, ou bien qui ont rencontré le veto de certaines parties à l'IETF (comme le RFC 4408). Tout RFC n'est donc pas le produit d'un groupe de travail IETF.

Depuis le RFC 5620, qui « éclatait » l'ancienne fonction de RFC Editor, la responsabilité des RFC soumis par voie indépendante revient au Independent Stream Editor, qui ne sera finalement désigné qu'en février 2010.

La section 3 pose les buts des nouvelles règles. Reprenant la politique traditionnelle, suivie informellement depuis l'époque de Jon Postel, elle pose comme principe que l'utilisation des RFC doit être la plus libre possible (« Unlimited derivative works »). Toutefois, tous les RFC de la voie indépendante ne sont pas équivalents. Certains sont des republications de documents édités ailleurs (par exemple par d'autres SDO) et les auteurs ont donc la possibilité de demander des restrictions supplémentaires. À noter que ces principes s'appliquent également au code inclus dans les RFC.

Enfin, les règles formelles elle-mêmes, en section 4. La procédure est proche de celle des autres RFC, l'auteur devant donner certains droits pour permettre la publication (par défaut, il donne presque tous les droits, en gardant évidemment l'attribution de son travail). Les termes exacts (le boilerplate) seront fixés par l'IETF Trust.

Le respect de la procédure par l'auteur ne préjuge pas de l'adoption du RFC. L'éditeur de la voie indépendante, l'ISE, reste seul juge de l'intérêt de publier le RFC. Le choix d'un auteur de ne pas permettre la réutilisation du RFC (« no derivative worlks ») peut, par exemple, être motif de rejet.

L'implémentation de cette politique nécessite une action de la part de l'IETF Trust, décrite en section 5. Celui-ci devra accepter la responsabilité de la gestion des droits de propriété intellectuelle pour ces RFC « indépendants » et devra écrire les termes exacts qui seront inclus dans chaque RFC.

Quant aux questions de brevets et de marques déposées, elles sont réglées dans la section 6. Les règles des RFC 2026 et RFC 8179 s'appliquent aux RFC de la voie indépendante comme aux autres : toute prétention de propriété intellectuelle doit être déclarée, de façon à ce que l'ISE puisse décider en toute connaissance de cause (notez bien qu'en pratique, cette règle est parfois violée). Comme d'habitude à l'IETF, il n'y a pas d'a priori sur les conditions de licence des brevets (tout est théoriquement possible) mais notre RFC précise que les termes de licence les plus favorables possibles seront privilégiés, notamment des licenses gratuites, voire implicites.

Les algorithmes de cryptographie de la famille des courbes elliptiques prennent de plus en plus d'importance, concurrençant les traditionnels RSA et DSA. Ce RFC spécifie l'utilisation de certains de ces algorithmes dans le protocole SSH.

Il y a déjà plusieurs RFC qui utilisent les courbes elliptiques : les RFC 4050, RFC 4492, RFC 5349, etc. SSH n'est donc pas, et de loin, le premier protocole IETF à en bénéficier. Mais il est plus répandu et l'intégration des courbes elliptiques leur donnera donc une bien meilleure exposition.

Outre des avantages techniques comme des clés de faible taille (voir la section 1 du RFC pour des chiffres précis), l'intérêt des courbes elliptiques est que, compte-tenu du risque toujours existant de percées soudaines en cryptanalyse, il est prudent de garder « plusieurs fers au feu ». Si une nouvelle méthode de factorisation en nombres premiers apparait, menaçant RSA, la disponibilité d'algorithmes utilisant les courbes elliptiques fournira une solution de repli.

Notre RFC 5656 étend donc SSH, tel qu'il est spécifié dans les RFC 4251 et RFC 4253. Pour davantage d'information sur les courbes elliptiques, il renvoie à « SEC 1: Elliptic Curve Cryptography » et « SEC 2: Recommended Elliptic Curve Domain Parameters ».

La section 3 de notre RFC attaque les détails pratiques de l'algorithme ECC. Le format des clés (section 3.1), l'algorithme utilisé pour la signature (nommé ECDSA), avec la fonction de hachage SHA-2 et l'encodage de la signature y sont normalisés.

Un protocole d'échange de clés utilisant les courbes elliptiques, ECDH, occupe la section 4. Un autre, ECMQV, figure en section 5 (mais seul ECDH est obligatoire dans SSH).

Le tout est enregistré dans le registre des paramètres SSH, tel que décrit en section 6. Comme le terme de « courbes elliptiques » désigne une famille, pas un seul algorithme, il faut ensuite préciser l'algorithme exact utilisé. Trois courbes elliptiques sont ainsi mise en avant, nommées nistp256, nistp384 et nistp521. Un mécanisme utilisant l'OID de la courbe est prévu pour celles sans nom (section 6.1). Ces courbes peuvent être utilisées pour ECDSA (section 6.2), ECDH (section 6.3) et ECMQV (section 6.4). Ainsi, le nom complet de l'algorithme utilisé pour ECDSA avec la courbe nistp256 est ecdsa-sha2-nistp256.

Comment vont faire les mises en œuvres de SSH avec ces nouveaux algorithmes et interopéreront-elles avec les anciennes ? Oui, répond la section 8 : le protocole SSH a toujours prévu un mécanisme de négociation des algorithmes utilisés et les programmes ignorent simplement les algorithmes inconnus (section 8.2). La section 8 couvre d'autres problèmes concrets comme les performances des nouveaux algorithmes (en général meilleure que celle de RSA ou DSA, en raison de la taille plus faible des clés).

Une très riche section 9 analyse en détail les caractéristiques de sécurité des courbes elliptiques et leur résistance à la cryptanalyse. D'abord, il faut bien retenir que « courbes elliptiques » désigne une famille, pas un seul algorithme. Certains membres de la famille sont plus vulnérables que d'autres, par exemple à des attaques comme la descente de Weil. Il faut donc considérer avec prudence une courbe qui n'est pas listée dans la section 10 (qui résume la liste des courbes utilisées pour SSH).

Ppur les courbes ainsi spécifiées, il n'existe pas actuellement d'autres attaques que la force brute. Les seules exceptions concernent les algorithmes pour ordinateurs quantiques (comme celui de Shor). Or, ces ordinateurs ont déjà le plus grand mal, à l'heure actuelle, à additionner 2 + 2 et le RFC note qu'il est peu probable qu'ils deviennent une menace réelle dans les prochaines années. Les lois de la physique et celle de l'ingéniérie ne sont pas faciles à faire plier !

La section 10 rassemble les caractéristiques des courbes obligatoires (section 10.1) et recommandées (section 10.2), donnant pour chacune l'OID attribué. Toutes sont dérivées de normes NIST. Ainsi, nistp256 a l'OID 1.2.840.10045.3.1.7. Tous ces algorithmes sont enregistrés dans le registre SSH, suivant le RFC 4250.

La mise en œuvre la plus répandue de SSH, OpenSSH, a intégré ces algorithmes à courbes elliptiques sa version 5.7, livrée en janvier 2011 (voir un résumé en http://pthree.org/2011/02/17/elliptic-curve-cryptography-in-openssh/). Il y a quelques années, un interview d'un des développeurs indiquait qu'un des problèmes était celui des brevets logiciels (il parlait aussi de l'absence de normalisation, ce qui n'est plus vrai avec la sortie de notre RFC).

Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux noms de domaine.

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 5730, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping, on pourrait aussi l'appeler une classe) pour les noms de domaine.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

On note que ce schéma, se voulant adaptable à de nombreux registres différents, ne colle parfaitement à la politique d'aucun. Par exemple, <infData> est spécifié ainsi :

    <sequence>
      <element name="registrant" type="eppcom:clIDType"
       minOccurs="0"/>
      <element name="contact" type="domain:contactType"
       minOccurs="0" maxOccurs="unbounded"/>
      <element name="ns" type="domain:nsType"
       minOccurs="0"/>

ce qui veut dire que des « règles métier » très courantes comme « un titulaire et un seul » ou bien « au moins deux serveurs de noms » ne sont pas respectés avec le schéma EPP seul.

Ce RFC remplace son prédécesseur, le RFC 4931 mais ce ne sont que des modifications de détail, résumées en annexe A. Elles vont en général dans le sens d'une plus grande latitude laissée aux implémenteurs.

Voici un exemple d'une réponse à une requête <epp:info> (section 3.1.2) pour le domaine example.com (comme avec whois mais, typiquement, non public) :

<response>
  <result code="1000">
    <msg>Command completed successfully</msg>
  </result>
  <resData>
    <domain:infData
     xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:name>example.com</domain:name>
      <domain:roid>EXAMPLE1-REP</domain:roid>
      <domain:status s="ok"/>
      <domain:registrant>jd1234</domain:registrant>
      <domain:contact type="admin">sh8013</domain:contact>
      <domain:contact type="tech">sh8013</domain:contact>
      <domain:ns>
        <domain:hostObj>ns1.example.com</domain:hostObj>
        <domain:hostObj>ns1.example.net</domain:hostObj>
      </domain:ns>
      <domain:host>ns1.example.com</domain:host>
      <domain:host>ns2.example.com</domain:host>
      <domain:clID>ClientX</domain:clID>
      <domain:crID>ClientY</domain:crID>
      <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate>
      <domain:upID>ClientX</domain:upID>
      <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate>
      <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate>
      <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate>
      <domain:authInfo>
        <domain:pw>2fooBAR</domain:pw>
      </domain:authInfo>
    </domain:infData>
  </resData>
...

On y voit les serveurs de noms du domaine, ns1.example.com et ns1.example.net, son titulaire, identifié par un code, ici jd1234, sa date de création, le 3 avril 1999, etc.

De même, pour créer un domaine, on appele <epp:create> (section 3.2.1) avec des éléments de l'espace de nom urn:ietf:params:xml:ns:domain-1.0, par exemple :

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">2</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.example.com</domain:hostObj>
          <domain:hostObj>ns1.example.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>jd1234</domain:registrant>
...

La liste complète des commandes EPP utilisables pour ce type « domaine » figure dans la section 3.

La syntaxe utilisable pour un nom de domaine est celle du RFC 1123, bien plus restrictive que celle utilisée dans le DNS (section 2.1). Ce type « domaine » ne peut donc pas être utilisé pour tout nom de domaine légal.

Chaque domaine a un « statut », ceux mis par le client (typiquement un registrar) étant préfixés par client (section 2.3). Par exemple, clientHold indique que, à la demande du registrar, ce nom, quoique enregistré, ne doit pas être publié dans le DNS.

Ce n'est pas tout de normaliser des protocoles. Pour qu'ils ne rendent pas la vie impossible aux administrateurs réseaux, il faut encore qu'ils soient faciles à administrer. Cela peut être plus facile si ces questions opérationnelles ont été prises en compte dès le début. Ce RFC 5706 demande donc que tout nouveau protocole fait à l'IETF reçoive, dès le début, une sérieuse attention pour ses problèmes de gestion. Le faire a posteriori est en effet souvent moins efficace.

Ce RFC est essentiellement composé d'une liste de recommandations (très détaillées) aux auteurs de nouveaux protocoles, expliquant les étapes qu'ils doivent suivre pour que leur protocole soit « gérable ». Cette liste est résumé dans l'annexe A, qu'il suffit normalement de suivre pas-à-pas pour que le protocole soit complet.

La section 1.1 resitue la question : cela fait longtemps que l'IETF demande aux auteurs de protocole de prévoir les mécanismes de gestion pratique dès le début. Un cadre existe pour cela, autour du SMI (modèle décrivant les variables du protocole) du RFC 2578 (et du protocole qui lui est le plus souvent associé, SNMP ; voir le RFC 3410). Mais ce modèle est trop étroit et ne couvre pas l'intégralité de ce qu'il faut savoir pour le déploiement et l'administration d'un protocole. Sans aller jusqu'à formellement imposer une section Management Considerations dans les RFC (comme il existe une Security Considerations obligatoire), notre RFC 5706 demande une attention sérieuse portée, dès le début, aux questions de gestion et d'opération des réseaux.

La différence entre « gestion » (management) et « opération » (operation) est décrite en section 1.2. Les opérations, c'est faire fonctionner le réseau, même sans mécanisme de gestion. La gestion, c'est utiliser des mécanismes qui ont été créés dans le but d'améliorer les opérations.

Contrairement à l'idée dominante à l'IETF depuis quinze ans, et depuis les grandes luttes entre SNMP et CMIP, il n'est plus envisagé (section 1.3) d'atteindre le Graal du mécanisme unique. Toutes les solutions sont désormais acceptables, pourvu qu'elles marchent. (Parmi les échecs du SMI, on peut noter celui décrit par le RFC 3197. Aujourd'hui encore, les serveurs DNS sont gérés par des mécanismes non-standard comme la commande rndc de BIND.)

Le RFC 5706 va donc donner des lignes directrices et des conseils, plutôt que des obligations. C'est donc un assouplissement par rapport à l'ancienne politique de l'IESG qui exigeait une MIB (description des variables en suivant le SMI) pour tout protocole, au grand désespoir de certains auteurs.

Les sections 1.4 et 1.5 rappellent l'histoire tourmentée des mécanismes de gestion des réseaux TCP/IP. Par exemple, une date importante avait été le RFC 1052 en 1988, qui séparait le langage de modélisation (celui qui sert à écrire la MIB) du protocole d'accès aux données (aujourd'hui SNMP). Une autre avait été le RFC 3139 en 2001, qui listait les obligations d'un mécanisme de gestion. Le RFC 3535 en 2003, faisait le bilan des mécanismes utilisés et critiquait notamment la dépendance vis-à-vis d'un format binaire, celui de SNMP.

La première grande section de notre RFC 5706 est donc la section 2, consacrée aux opérations : comment le nouveau protocole va t-il fonctionner ? Il ne suffit pas pour cela que le protocole soit lui-même bien conçu. Il doit aussi s'insérer dans l'environnement humain et technique existant. Ses concepteurs doivent donc réflechir au débogage, à la configuration, à la mise à jour depuis une précédente version...

Comme exemple de mauvaise interaction avec l'existant, le RFC cite l'exemple du damping de BGP (RFC 2439). Lorsqu'une route annoncée en BGP change trop souvent, les routeurs BGP commencent à ignorer cette route. Mais cette technique n'avait pas pris en compte l'interaction avec d'autres techniques comme la path exploration et avait donc créé autant de problèmes qu'elle en avait résolu, menant certains administrateurs à couper le damping.

Avant même que le protocole ne fonctionne, il faut le configurer. C'est le but de la section 2.2 qui commence en rappelant un sage principe du RFC 1958 : « tout ce qui peut être configuré peut être mal configuré ». Ce RFC (et son lointain successeur, le RFC 5505) recommandait de préférer les configurations automatiques. Pour les cas où une valeur par défaut a un sens, il faut éviter toute configuration (mais permettre de connaitre les valeurs effectivement configurées).

Parfois, il y avait déjà une version plus ancienne du protocole qui tournait (ou bien un ancien protocole jouant le même rôle). La norme doit alors prévoir un mécanisme de migration, dit la section 2.3. D'autres principes de ce genre forment le reste de la section 2.

La section 3, elle, s'occupe de la gestion de réseaux. Il ne s'agit plus uniquement de faire marcher le réseau, il faut encore le faire marcher bien. Cela passe par l'identification des entités à gérer, puis de la méthode à utiliser. L'ancienne approche qui répondait à toutes ses questions par « il faut écrire une MIB » a montré ses limites. Un ensemble de variables n'est pas un protocole, d'autant plus qu'elle ne concerne en général qu'une des deux extrémités de la communication. Comme le dit le RFC 3535, « une MIB est souvent une liste d'ingrédients sans une recette ». L'introduction de la section 3 donne des pistes pour améliorer les choses.

Un des credos principaux de l'IETF est l'interopérabilité, couverte dans la section 3.1. Appliquée à la gestion du réseau, l'interopérabilité veut dire qu'on devrait pouvoir choisir librement le programme utilisé pour gérer un équipement, et l'utiliser quel que soit l'équipement réseau qu'on gère. Cela implique un protocole standard de gestion.

Beaucoup d'équipements réseau peuvent être gérés via une page Web (elle-même souvent très peu standard, avec abus de fonctions qui ne marchent que sur certains navigateurs, même si le RFC ne mentionne pas ce point), ou parfois via la ligne de commande. Mais cela ne suffit pas. Si on gère des dizaines d'équipements différents, ce qui est courant dans un réseau de taille moyenne, la complexité devient vite unsupportable. Pour que la gestion du réseau soit simplifiée et soit automatisable, une normalisation de ces interfaces est nécessaire.

Historiquement, tout le monde était d'accord sur le papier avec une telle approche. Mais, en pratique, ces interfaces, même celles en ligne de commande, plus faciles à spécifier, n'ont jamais été standardisées. L'IETF n'a pas aidé, en se focalisant sur un seul schéma de données (le SMIv2 du RFC 2578) et un seul protocole (SNMP, du RFC 3410). Ces mécanismes ne convenaient pas à tous et les « autres » interfaces, ignorées de l'IETF, étaient développées mais sans norme unificatrice. Désormais, l'IETF a une vision plus ouverte, et considère d'autres langages de schéma (comme les W3C Schema) ou d'autres protocoles (comme Netconf, dans le RFC 6241, ou syslog, dans le RFC 5424).

La normalisation est plus facile à dire qu'à faire. Normaliser au niveau de la syntaxe est déjà délicat mais, idéalement, il faudrait aussi normaliser la sémantique, pour qu'un même nom décrive bien le même concept partout. Cela impose de développer des modèles, aussi bien des modèles d'information que des modèles de données. (La différence est expliquée dans le RFC 3444 et la section 3.2 couvre les modèles d'information.)

Un protocole ne fonctionne jamais sans pannes. La très riche section 3.3 se penche sur la gestion des pannes. Bien sûr, les mécanismes de gestion du réseau ne vont pas réparer la panne tout seuls. Mais ils peuvent aider à la diagnostiquer. Par exemple, tout protocole devrait avoir un mécanisme de détection de la vie d'un élément du réseau, pour pouvoir répondre à la question simple « Est-il encore en marche ? ». C'est le but de protocoles aussi variés que l'ICMP echo du RFC 792, du protocole echo de TCP ou UDP (RFC 862, mis en œuvre dans des programmes comme echoping et malheureusement presque abandonné aujourd'hui), les appels NULL dans Sun-RPC (section 11.1 du RFC 1831), etc.

Dans un ordre surprenant, la section 3 passe ensuite à la gestion de la configuration (sous-section 3.4). Quels paramètres de configuration, lesquels survivent au redémarrage, que dit le RFC 3139, etc. Cette section, comme le reste du RFC, est trés détaillée, abordant même le problème de l'internationalisation (et, oui, il faut permettre l'UTF-8 dans les fichiers de configuration). D'autre part, le RFC demande également qu'on puisse vérifier la configuration avant de la charger dans l'équipement réseau, pour éviter de laisser celui-ci dans un état invalide, voire de gêner le bon fonctionnement du réseau.

Pour beaucoup d'opérateurs, notamment dans les réseaux traditionnels de téléphonie, il n'y a pas de gestion de réseau sans comptabilisation du trafic. C'est le sujet de la section 3.5, qui renvoie au RFC 2975, et qui dit bien que la comptabilisation n'est nullement obligatoire, qu'elle doit faire l'objet d'un choix réfléchi.

Plus importante est la gestion des performances : tout le monde veut que le réseau aille vite. Pour cela, le point de départ (section 3.6) est de mesurer les performances, pour déterminer, par exemple, si un changement les améliore ou bien les dégrade. Deux groupes de travail de l'IETF se consacrent à ce sujet, BMWG pour les mesures en laboratoire et IPPM pour celles dans la nature.

La sécurité est un gros sujet en soi, lors de la configuration d'un système, et est traitée dans la section 3.7. Par exemple, un nouveau protocole devrait comporter une analyse des menaces et des solutions possibles. Certains protocoles prévus pour la gestion de réseau ont une utilisation directe en sécurité. Par exemple, les traps SNMP et syslog sont couramment utilisés pour alerter les administrateurs sur des phénomènes qui peuvent être une attaque.

Une fois les problèmes des opérations (section 2) et de la gestion (section 3) ainsi décrits, qu'en faire, lorsqu'on définit un nouveau protocole ? Documenter, dit la section 4. Il devrait idéalement y avoir une section Manageability Considerations dans les RFC, juste avant les Security Considerations, et contenant les informations essentielles pour ceux qui auront à opérer et à gérer le nouveau protocole. Si le ou les concepteur(s) du protocole estiment que cette section n'a pas lieu d'être pour leur création, alors ils devraient l'indiquer explicitement (ce qui garantit que l'absence d'une Manageability Considerations n'est pas un oubli). Le premier RFC à avoir suivi cette règle (avant même qu'elle soit formalisée) est apparemment le RFC 5440 (dans sa section 8).

Malgré la concurrence de la messagerie instantanée, du courrier, du Web avec la syndication, Usenet / Netnews, un des plus anciens outils numériques de communication et de distribution d'information continue à vivre. Plus ancien que l'Internet sur beaucoup de sites (Usenet était souvent distribué via UUCP), ce dinosaure continue à faire la joie et le désespoir de millions d'utilisateurs. Mais ses normes avaient un peu vieilli et pas subi de mise à jour depuis longtemps. C'est heureusement ce qui vient de leur arriver, dans une série de RFC dont les premiers publiés sont le RFC 5537 et notre RFC 5536, qui normalise le format des messages. Ces documents ont pris plus de huit ans à être élaborés et approuvés.

Notre RFC 5536 est le successeur du célèbre RFC 1036, publié en décembre 1987, et qui spécifiait avant lui le format des messages (comme ce que fait le RFC 5322 pour le courrier). Depuis des années, les mises en œuvres existantes de Usenet utilisaient un sur-ensemble du RFC 1036, sur-ensemble qui vient d'être normalisé. (Avant cela, ces améliorations étaient contenues dans un document informel, « Son of RFC 1036 », qui a finalement été publié en RFC 1849.)

Les news comprennent plusieurs parties : le protocole de transport des messages, aujourd'hui essentiellement NNTP (RFC 3977), le format des messages (notre RFC 5536) et des conventions plus ou moins formelles entre les sites qui s'envoient des messages NetNews, ces sites formant le réseau Usenet (ou des réseaux privés).

Que contient concrètement notre RFC ? La section résume les concepts de base. « NetNews » est composé d'un ensemble de protocoles pour stocker, transmettre et lire des articles, organisés en groupes (newsgroups). Ces articles sont typiquement distribués au sein d'Usenet par un algorithme d'inondation. Pour retrouver facilement un article, et déterminer s'il est déjà présent localement, le serveur Usenet utilise un Message ID (section 3.1.3) qui est présent dans chaque article, et est unique. Le format NetNews est très proche de celui du courrier, tel que décrit dans les RFC 5322 et RFC 2045. La définition de la syntaxe d'un article (section 1.4) emprunte également beaucoup au RFC 5322 (voir annexe C, qui développe les différences entre les deux formats ; notre RFC 5536 a une syntaxe plus stricte).

La section 2 décrit en détail ce format, en partant du RFC 5322, mais en ajoutant des restrictions (section 2.2). L'internationalisation, comme pour le courrier, est assurée par MIME (section 2.3) et notamment les RFC 2049 et RFC 2231 (voir aussi la section 4).

Une fois les principes de base du format posés dans la section 2, la section suivante décrit chaque en-tête possible. Certains sont obligatoires dans tout article (section 3.1) comme Date: (section 3.1.1) ou From: (3.1.2). Est également obligatoire Message-ID: (section 3.1.3) qui est un identifiant unique de l'article, sur lequel les serveurs se basent pour mettre en œuvre l'algorithme d'inondation. Les identificateurs d'articles sont transmis à tous les serveurs voisins, ceux-ci pouvant alors dire s'ils acceptent ou refusent (car ils ont déjà un article de même Message-ID:). (Le Message-ID: sert également aux recherches d'un article, par exemple, via GoogleGroups.)

Dans les en-têtes obligatoires, on trouve également Newsgroups: (section 3.1.4) qui donne la liste des groupes dans lequel l'article a été envoyé et Path: (3.1.5), qui est la séquence des serveurs par lesquels est passé l'article, séparés par des !. Cet en-tête vise à empêcher les boucles dans l'algorithme d'inondation : même si la détection d'un Message-ID: connu ne marche pas, le fait que le serveur apercevra son nom dans le path: lui indiquera qu'il doit rejeter l'article.

L'ancienneté des NetNews fait que beaucoup de points de la norme s'expliquent par des raisons historiques. Ainsi, le fait de mettre le nom de l'expéditeur au début du Path: et la ressemblance d'un Path: avec une adresse UUCP avec route explicite ne sont pas un hasard. Dans les réseaux UUCP, le Path: pouvait être utilisé comme adresse de courrier, pour écrire à l'expéditeur (cet usage s'est perdu et notre RFC recommande de mettre not-for-mail comme adresse d'expéditeur).

Bien sûr, il y a aussi des en-têtes facultatifs, décrits dans la section 3.2 : c'est le cas par exemple de Archive: (section 3.2.2) qui indique si l'expéditeur veut que son message puisse être archivé (Google permet de chercher dans tous les articles échangés sur Usenet depuis 1981).

Expires: (section 3.2.5) sert à indiquer au bout de combien de temps l'article peut être supprimé d'un serveur qui veut faire de la place (en l'absence de cet en-tête, le serveur décide seul de la date d'expiration).

Et il y a bien d'autres en-têtes possibles dans cette section 3.2.

Quelle est la sécurité offerte par Usenet ? Nulle, rappelle la section 5. Les articles ne sont pas confidentiels et leur intégrité n'est pas garantie.

La liste complète des changements depuis le RFC 1036 apparait en annexe B. MIME est désormais formellement reconnu (la plupart des logiciels le géraient depuis longtemps mais il n'existait pas à l'époque du RFC 1036). Certains en-têtes largement acceptés par les logiciels deviennent officiels, comme Archive:. Autrement, les changements sont surtout du toilettage de syntaxe.

Voici, tel qu'il passe sur le réseau (affiché dans un logiciel de lecture, cela peut évidemment être très différent) un article à ce format :

Path: news.free.fr!xref-2.proxad.net!spooler1c-1.proxad.net!cleanfeed2-a.proxad.net!nnrp3-2.free.fr!not-for-mail
From: Stephane Acounis <panews@free.fr>
Subject: =?iso-8859-1?b?wA==?= donner: Sun(s) SS20 sur Nantes
Date: Mon, 09 Jun 2008 19:24:17 +0200
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-Id: <pan.2008.06.09.17.24.16.590396@free.fr>
Newsgroups: fr.comp.ordinosaures
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit

Bonsoir,

J'ai deux stations Sun SS20, une bi-pro (SM75), l'autre mono-pro (SM75),
à donner sur Nantes (ou Nançay mercredi/jeudi ou Brest vendredi).
256Mo de mémoire vive, disque 9Go, carte vidéo.
Je doit avoir des claviers, des câbles divers, des cartes SBus en plus.

...

Notez l'en-tête Subject: encodé selon le RFC 2047.

NetNews est mis en œuvre dans de nombreux logiciels aujourd'hui, souvent dans les logiciels de courrier, vu la ressemblance des formats. C'est ainsi que le célèbre MUA Thunderbird est également un bon lecteur de News.

L'antique RFC 1036 qui, pendant les vingt dernières années, était la seule norme gouvernant le système de news, vient d'être remplacé par une série de RFC dont celui qui fait l'objet de cet article, le RFC 5537 qui décrit l'architecture générale des news.

Les news (ou Netnews, dit le RFC) sont un extraordinaire système de distribution de messages, organisés en groupes de discussion (newsgroups). Chacun de ces groupes peut être un vecteur d'annonces ou bien un forum de discussion, où la vigueur de ces discussions sont une caractéristique fréquente des news. Les news existaient avant que l'Internet ne se répande et, jusqu'à très récemment, était souvent distribuées avec des protocoles non-TCP/IP tel qu'UUCP. Mille fois, la fin des news a été annoncée, au profit de gadgets récents accessibles via le Web et à chaque fois, elles ont continué à inonder les serveurs et à passionner des dizaines de milliers de participants. À l'époque où n'importe quel système de communication via le Web fait immédaitement l'objet de l'attention des médias et des experts, les news reste un outil « invisible » (en tout cas invisible aux chefs, aux experts, aux ministres et aux journalistes), ce qui fait une bonne partie de leur charme.

Maintenant, place à la technique. Comment les news fonctionnent-elles (section 1 de notre RFC) ? Les serveurs de news s'échangent des articles, dans un format normalisé. Les articles sont regroupés en groupes comme fr.reseaux.internet.hebergement ou soc.culture.belgium. Les groupes qui partagent un préfixe commun comme fr forment une hiérarchie. Chaque serveur transmet ses articles à ses voisins qui, à leur tour, le transmettent à leurs voisins, un protocole dit d'inondation (il existe d'autres protocoles fondés sur le bavardage de proche en proche dans l'Internet). Un ensemble de serveurs ainsi reliés est un réseau et le principal se nomme Usenet (il existe aussi des réseaux privés, bien plus petits). Lorsque les gens disent qu'ils lisent les news ils font en général allusion à celles d'Usenet.

Les deux principaux RFC de la nouvelle série, celle qui remplace le RFC 1036, sont le RFC 5536, qui normalise le format des messages, un format très inspiré de celui du courrier électronique, et notre RFC 5537 qui décrit le cadre général. L'annexe A est consacrée aux changements depuis le RFC 1036. Le développement de cette nouvelle série de RFC a finalement pris près de dix ans. (Une documentation du premier effort se trouve dans le RFC 1849, « Son of RFC 1036 ».)

Parmi les serveurs de news, la section 1.2 fait la distinction entre :

• injecting agent le premier serveur qui reçoit un article, article à qui il manquera peut-être quelques caractéristiques pour être tout à fait conforme à la norme,
• relaying agent un serveur qui recevra et transmettra un article, typiquement sans le modifier,
• serving agent, un serveur qui permettra la lecture par les clients finaux,
• user agent, le logiciel qui tourne sur le bureau de l'utilisateur final, lui-même séparé en posting agent qui permet d'écrire et reading agent qui permet de lire,
• et les passerelles, qui connectent le monde des news à d'autres systèmes, comme le courrier électronique ou le Web

mais, en pratique, beaucoup de logiciels assurent plusieurs fonctions à la fois. Par exemple, INN est injecting agent, relaying agent et serving agent.

Les devoirs des différents logiciels sont résumés dans la section 3. Il y a des grands principes (section 3.1), comme le Principe de Robustesse « Soyez restrictif dans ce que vous envoyez et ouvert pour ce que vous recevez » ou bien comme le principe d'Hippocrate, « Avant tout, ne pas nuire », c'est-à-dire que, en cas de doute, le logiciel doit s'abstenir d'intervenir. D'autant plus que le RFC rappelle que tous les lecteurs doivent voir le même article, ce qui interdit les modifications qui ne soient pas purement techniques.

Et il y a des règles plus pratiques. Par exemple, la section 3.2 est consacrée au champ Path: des en-têtes. Il sert à indiquer le chemin parcouru par le message entre les relaying agent et donc à éviter les boucles. Tout serveur doit donc indiquer son identité dans ce champ (section 3.1.5 du RFC 5536, l'identité est en général le nom de domaine du serveur). Les sections 3.2.1 et 3.2.2 détaillent le processus de formation du champ Path:, bien plus riche que dans le RFC 1036. Un Path: peut être aussi complexe que :

Path: foo.isp.example!.SEEN.isp.example!!foo-news
            !.MISMATCH.2001:DB:0:0:8:800:200C:417A!bar.isp.example
            !!old.site.example!barbaz!!baz.isp.example
            !.POSTED.dialup123.baz.isp.example!not-for-mail

qui utilise la plupart des possibilités comme celle de noter que la machine 2001:DB::8:800:200C:417A n'avait peut-être pas le droit de se prétendre bar.isp.example.

Tout aussi important que Path: qui permet d'éviter les boucles et de détecter les problèmes, par exemple les injections de spam, est l'en-tête Message-ID: (section 3.1.3 du RFC 5536) qui sert à assurer l'unicité des articles et à garantir que l'algorithme d'inondation se termine : un serveur refuse les articles qu'il a déjà. Pour s'en souvenir, il doit donc stocker les Message-ID: dans une base de données, souvent nommée history (section 3.3).

La section 3.4 se penche ensuite sur le cas des posting agents, le logiciel avec lequel l'utilisateur va interagir pour écrire sur les news. Parmi leurs nombreuses tâches figure celles liées aux réponses à des messages existants (sections 3.4.3 et 3.4.4). Le logiciel doit notamment construire un champ References: qui citera le Message-ID: du message auquel on répond, permettant ainsi au lecteur de news de reconstituer les fils de discussion (même s'il y aura toujours des ignorants pour voler les fils, comme avec le courrier). Voici la partie de l'en-tête qui montre une réponse au message <l_CdnfgkWe7PWyLUnZ2dnUVZ8viWnZ2d@giganews.com> :

Newsgroups: fr.comp.reseaux.ethernet
References: <l_CdnfgkWe7PWyLUnZ2dnUVZ8viWnZ2d@giganews.com>
Subject: =?iso-8859-1?Q?Re:_Debogage_d'une_panne_r=E9seau?=
Message-ID: <49bfceec$0$2734$ba4acef3@news.orange.fr>

Les news ne sont pas seulement une technique mais avant tout un réseau social (même si le mot n'était pas encore à la mode lors de leur création). Certains groupes sont donc modérés et il faut donc aussi spécifier les règles techniques que doivent observer les modérateurs (section 3.9).

Il n'y a pas que les news dans la vie et certains groupes peuvent intéresser des gens qui ne veulent ou ne peuvent pas accéder aux news. Le rôle des passerelles est donc de convertir les articles depuis, ou vers le monde des news. Par exemple, une passerelle peut traduire les news d'un groupe en HTML et les mettre sur une page Web (voyez par exemple l'archive de comp.os.research). Mais les passerelles les plus répandues sont celles entre les news et le courrier électronique, permettant aux utilisateurs du courrier d'écrire sur les news ou bien de recevoir des news par courrier. Historiquement, les passerelles ont souvent été responsables de problèmes sur les news, par exemple de boucles sans fin (article transmis du réseau A au réseau B puis retransmis vers A et ainsi de suite éternellement) et la section 3.10 normalise donc ce qu'elles doivent faire et ne pas faire. Les passerelles doivent notamment conserver le Message-ID:, principale protection contre les boucles, puisque permettant de voir qu'un message est déjà passé. La section 3.10.4 donne un exemple complet pour le cas d'une passerelle bidirectionnelle avec le courrier.

Aujourd'hui, la plupart des news sont transportées par le protocole NNTP, dont le RFC 3977 date d'un peu plus de deux ans. Mais, historiquement, UUCP (RFC 976) avait été très utilisé. La section 2 du RFC détaille les obligations de ces protocoles de transport, notamment le fait de pouvoir faire passer des caractères codés sur 8 bits (permettant ainsi des encodages comme Latin-1). Cette obligation, nécessaire à l'internationalisation a fait l'objet de longues luttes, depuis l'époque où les logiciels devaient encoder les messages écrits en français avec le Quoted-Printable. L'obligation s'applique aussi aux en-têtes des messages et un logiciel de news a donc davantage d'obligations ici qu'un logiciel de messagerie.

Une des particularités des news est que les messages de contrôle (comme ceux demandant la création ou la suppression d'un groupe) sont des messages comme les autres, distribués par le même mécanisme d'inondation. La section 5 normalise ces messages. Le principe de base est que le message de contrôle se reconnait par la présence d'un champ Control: (section 3.2.3 du RFC 5536). Dans l'ancien RFC 1036, les messages de contrôle pouvaient aussi se reconnaitre par un sujet spécial, commençant par cmsg mais cet usage est désormais officiellement abandonné.

Il n'y a aucune sécurité dans les news en général. Certains réseaux peuvent ajouter leurs propres mécanismes mais Usenet, par exemple, n'a pas de mécanisme général. Les messages de contrôle peuvent donc facilement être imités, même s'il existe des méthodes non officielles pour les authentifier (section 5.1). Usenet étant un réseau très animé et très peu policé, cette absence de sécurité a donc entrainé souvent des surprises. Le RFC rappelle donc l'importance de tenter de s'assurer de l'authenticité d'un message de contrôle (les méthodes pour cela ne sont pas normalisées mais, par exemple, INN peut vérifier les signatures PGP).

Les messages de contrôle permettent, par exemple, d'annuler un message, de stopper sa diffusion (section 5.3). Comme on s'en doute, ce sont parmi les messages les plus souvent usurpés. Le RFC 1036 demandait, dans l'espoir de renforcer la sécurité, que l'expéditeur (tel qu'indiqué par le champ From:) soit le même dans le message de contrôle et dans le message initial. Comme il est trivial d'usurper cette identité, cela ne faisait que diminuer la traçabilité, en décourageant les « annulateurs » de s'identifier. Cette règle est donc supprimée par notre RFC.

Les messages de contrôle liés à la gestion des groupes sont décrits dans la section 5.2. Par exemple, newgroup (section 5.2.1) permet de créer un nouveau groupe. Il ressemble à :

From: "example.* Administrator" <admin@noc.example>
Newsgroups: example.admin.info
Control: newgroup example.admin.info moderated
...

Parlant de sécurité, la section 6 lui est entièrement consacrée. Elle résume dès le début la situation : NetNews avait été conçu pour la diffusion large de l'information, et la sécurité en est presque totalement absente. Des grosses erreurs de mise en œuvre avaient en outre aggravé les choses comme le fait que certains logiciels appliquaient (il y a longtemps) les messages de contrôle... en les passant, verbatim, au shell !

Avant de participer aux news il faut donc bien être conscient ce ces problèmes : vulnérabilité aux dénis de service (section 6.2), non-authentification de l'expéditeur (attention donc si un message semble particulièrement outrancier, son vrai expéditeur n'est peut-être pas celui affiché dans le champ From:) et diffusion très large, parfois au delà de ce qui était prévu (section 6.3).

Les articles de news étaient traditionnellement marqués, dans le système MIME comme message/news. Ce type n'a jamais été un grand succès et notre RFC 5537 le remplace par trois nouveaux types, décrits en section 4, application/news-transmission pour un articles en route vers un injecting agent ou bien un modérateur et deux types pour les messages de contrôle, application/news-groupinfo et application/news-checkgroups.

L'annexe A résume les changements depuis le RFC 1036. Parmi eux :

• Un format beaucoup plus riche du champ Path:, permettant de mettre davantage d'informations comme la notification de suspicions sur l'origine d'un message,
• Les nouveaux types MIME de la section 4,
• Les nouvelles règles pour le format des messages de contrôle, notamment la suppression de la règle du sujet commençant par cmsg,
• La suppression de la règle de pseudo-authentification des messages d'annulation (qui obligeait à ce que le champ From: du message et de l'annulation correspondent),
• Et de nombreuses précisions ou des normalisations de pratiques que tout le monde faisait mais qui n'étaient pas dans le précédent RFC.

Il existe aujourd'hui de nombreuses mises en œuvre des news en logiciel libre. Par example, parmi les logiciels client (lecture et écriture), xrn ou Thunderbird (ce dernier ne sert donc pas qu'au courrier). Parmi les serveurs, INN. Personnellement, je regrette que mon lecteur de courrier habituel, mutt, n'aie pas de fonction de lecture des news, même si plusieurs modifications non officielles ont déjà été proposées.

En 2001, l'achat par Google de la société DejaNews a mis à la disposition du géant de la recherche sur Internet une archive de tous les messages Usenet depuis 1981. Cette archive est désormais cherchable par date sur Google Groups. Si vous voulez chercher mon premier article envoyé sur les news... (Avec une double signature, une erreur de débutant.) Ou bien une discussion en 1993 sur le DNS...

Le courrier électronique, on le sait, n'offre guère de sécurité, que cela soit contre la lecture illégitime des messages ou bien contre l'injection de faux messages. Vue la complexité de son architecture (cf. RFC 5598), fruit d'une histoire longue et agitée, il ne faut pas espérer trouver la solution parfaite à tous les problèmes de sécurité du courrier. Aussi, ce RFC 3207 se contente d'apporter juste une brique à l'édifice, l'utilisation de TLS pour protéger le canal de communication entre deux MTA.

La communication normale entre deux de ces serveurs de messagerie se fait, avec le protocole SMTP, en clair. Aucune protection contre l'écoute ou la modification de données (section 1). Il n'y a pas non plus de moyen d'être sûr de l'authenticité du serveur en face. TLS, normalisé aujourd'hui dans le RFC 5246, fournit ces services de confidentialité (via le chiffrement) et d'authentification (via les certificats). Il faut noter que TLS ne sécurise ici que le canal entre deux serveurs, pas le message qui est transporté. Un message passe typiquement par plusieurs serveurs et toutes les communications ne seront pas forcément protégées par TLS. Même si elles le sont, si un des serveurs intermédiaires est malhonnête, TLS ne protégera pas (voir la section 6 du RFC qui détaille ce point de manière très complète). Au contraire, les solutions de sécurité de bout en bout comme PGP protégeront le message (mais sont peut-être plus difficiles à déployer).

Donc, le principe de ce RFC est de faire tourner SMTP au dessus de TLS. Cela se fait par le biais d'une nouvelle extension SMTP, STARTTLS, décrite en section 2 (contrairement à HTTP, il n'y a pas de port spécial où on utiliserait toujours TLS).

Cette extension est composée d'une option qu'annonce le serveur distant, STARTTLS :

220 mail.generic-nic.net ESMTP Postfix (Debian/GNU)
EHLO chezmoi.example.net
250-mail.generic-nic.net
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
...

et d'une nouvelle commande, également nommée STARTTLS, décrite en section 4 :

STARTTLS
220 2.0.0 Ready to start TLS
...

À cette commande, le serveur distant peut parfois répondre 454 (TLS not available due to temporary reason) auquel cas l'initiateur de la connexion devra décider s'il continue sans TLS (et est donc vulnérable à une attaque par repli, où un attaquant actif essaie de faire croire que la sécurisation n'est pas possible, voir la section 6 du RFC) ou de renoncer. Voir par exemple l'option smtp_tls_security_level = encrypt" de Postfix. Le RFC suggère (section 6) d'enregistrer le fait qu'un pair donné utilise TLS et de refuser les connexions ultérieures si TLS a été abandonné mais je ne connais aucune mise en œuvre de SMTP sur TLS qui fasse cela.

Pour que le courrier puisse continuer à fonctionner dans l'Internet, le RFC impose qu'un serveur annoncé publiquement (par exemple, placé en partie droite d'un enregistrement MX) accepte les connexions sans TLS. En revanche, l'option TLS est particulièrement intéressante (section 4.3) si l'utilisateur humain est authentifié et donc si on utilise le port de soumission (RFC 4409).

Si la commande STARTTLS est un succès (code 220), la négociation TLS habituelle commence. Les deux parties examinent ensuite ses résultats (par exemple l'algorithme de cryptographie négocié, ou bien le certificat du pair distant) et décident de continuer ou pas (section 4.1).

Parlant du certificat, faut-il vérifier celui du voisin ? En pratique, quasiment personne ne le fait, en raison du prix des certificats et de la difficulté à les obtenir et les gérer. De nos jours, SMTP sur TLS procure donc la confidentialité par rapport à des écoutants passifs mais aucune authentification. À la rigueur, on peut toujours regarder les en-têtes du message pour avoir quelques informations supplémentaires :

Received: from mail.bortzmeyer.org (unknown [IPv6:2001:4b98:41::d946:bee8:232])
        (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
        (Client CN "mail.bortzmeyer.org", Issuer "ca.bortzmeyer.org" (not verified))
        by mx1.nic.fr (Postfix) with ESMTP id 964A71714088
        for <echo@nic.fr>; Thu, 26 Nov 2009 12:08:08 +0100 (CET)

Si le MTA vérifie l'authenticité de son partenaire, le RFC lui laisse le choix des détails, recommandant seulement d'accepter un serveur situé dans le même domaine que celui qu'on cherche à contacter.

Une fois TLS négocié avec auccès, les machines doivent ignorer tout ce qui a été tapé avant et reprendre la négociation SMTP (EHLO et la suite), puisque l'information obtenue sans TLS n'est pas fiable (section 4.2).

Ce RFC est une mise à jour de la première norme, le RFC 2487, en bien plus détaillé, notamment sur les attaques possibles (une annexe résume les changements).

La plupart des MTA aujourd'hui ont la capacité de faire du TLS, comme décrit pour Postfix dans mon article. Parmi les auto-répondeurs de test, certains acceptent TLS.

Le protocole EPP d'avitaillement d'un registre (par exemple un registre de noms de domaine), normalisé dans le RFC 5730, manipule des objets qui sont des instances d'une classe (nommée mapping). Par exemple, il existe une classe (un mapping) pour les noms de domaine, décrite dans le RFC 5731. Notre RFC 4310 (remplacé depuis par le RFC 5910) décrit, lui, une extension EPP à ce mapping permettant de spécifier les données nécessaires à DNSSEC, notamment la clé publique d'une zone signée.

DNSSEC, normalisé dans le RFC 4033, utilise la même délégation que le DNS. La zone parente d'une zone signée délègue en indiquant la clé publique de sa zone fille. Plus exactement, la zone parente publie un condensat cryptographique de la clé publique de la zone fille, l'enregistrement DS (pour Delegation Signer), normalisé dans la section 5 du RFC 4034 (voir aussi le rappel en section 2.1 de notre RFC 4310).

Lorsqu'un bureau d'enregistrement crée un nom de domaine signé, ou bien informe le registre qu'un domaine est désormais signé, comment indique t-il ce DS ? Il y a plusieurs façons, et notre RFC propose d'utiliser EPP.

L'extension nécessaire est résumée en section 2. Elle fonctionne en ajoutant des éléments à la classe Domaine du RFC 5731. Un élément obligatoire est le condensat cryptographique de la clé (alors qu'il n'est pas forcément unique : cette erreur a été corrigée dans le RFC 5910). Mais le client EPP peut aussi fournir la clé elle-même (le RFC 6781 explique pourquoi le condensat, le futur DS, est obligatoire alors que la clé est facultative). Le RFC prévoit également que le registre de la zone parente peut également récupérer la clé dans le DNS (enregistrement DNSKEY) pour tester si le condensat reçu est correct (et il est donc recommandé que ladite DNSKEY soit publiée avant de prévenir le parent par EPP). La clé transmise au registre doit être une clé de confiance, c'est-à-dire avoir le bit SEP à 1 (cf. RFC 3757). En terminologie moderne, cette clé doit être une KSK (Key Signing Key).

Les commandes EPP pour gérer cette information font l'objet de la section 3. Ainsi, les réponses à <info> doivent désormais contenir un élément <secDNS:infData>, qui contient lui-même des éléments comme <secDNS:dsData> qui a son tour contient les champs qu'on trouve dans un enregistrement DS comme <secDNS:keyTag> (l'identificateur de la clé), <secDNS:alg> (l'algorithme utilisé), etc. L'espace de noms urn:ietf:params:xml:ns:secDNS-1.0 (ici avec le préfixe secDNS) est enregistré dans le registre IANA (voir section 6). (C'est désormais secDNS-1.1, depuis le RFC 5910.) Voici un exemple de réponse à <info> sur le domaine example.com :

<resData>
...
<domain:name>example.com</domain:name>
...
<extension>
  <secDNS:infData
   xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
   xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
    <secDNS:dsData>
      <secDNS:keyTag>12345</secDNS:keyTag>
      <secDNS:alg>3</secDNS:alg>
      <secDNS:digestType>1</secDNS:digestType>
      <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
    </secDNS:dsData>
  </secDNS:infData>
</extension>

Le condensat est de type SHA1 (<digestType>1</digestType>), la clé elle-même étant DSA/SHA1 (<alg>3</alg>).

L'extension DNSEC permet évidemment de créer un domaine signé, avec <create> (section 3.2.1) :

<domain:create>
  <domain:name>example.com</domain:name>
  ...
  <extension>
  <secDNS:create xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
    xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
  <secDNS:dsData>
    <secDNS:keyTag>12345</secDNS:keyTag>
    <secDNS:alg>3</secDNS:alg>
    <secDNS:digestType>1</secDNS:digestType>
    <secDNS:digest>49FD46E6C4B45C55D4AC</secDNS:digest>
    <!-- <secDNS:keyData>, la clé elle-même, est *facultatif* -->
  </secDNS:dsData>
</secDNS:create>
 ...

Une fois le domaine ainsi créé, le registre publiera typiquement un enregistrement DS comme :

example.com.  IN DS 12345 3 1 49FD46E6C4B45C55D4AC

Bien sûr, on peut aussi ajouter DNSSEC à un domaine existant, ou bien changer une clé existante. Cela se fait avec <update> :

    <domain:update>
        <domain:name>example.com</domain:name>
    ...
    <extension>
      <secDNS:update
       xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.0"
       xsi:schemaLocation="urn:ietf:params:xml:ns:secDNS-1.0 secDNS-1.0.xsd">
        <secDNS:add>
          <secDNS:dsData>
            <secDNS:keyTag>12346</secDNS:keyTag>
            <secDNS:alg>3</secDNS:alg>
            <secDNS:digestType>1</secDNS:digestType>
            <secDNS:digest>38EC35D5B3A34B44C39B</secDNS:digest>
            <!-- <secDNS:keyData>, la clé elle-même, est *facultatif* -->
          </secDNS:dsData>
        </secDNS:add>
      </secDNS:update>
     ...

Et, en utilisant <secDNS:rem> au lieu de <secDNS:add>, on peut retirer une délégation sécurisée (« dé-signer » le domaine).

Comme la grande majorité des extensions et mappings d'EPP, celle-ci est spécifiée en utilisant la syntaxe formelle des W3C schemas, ici en section 4.

Il existe un très grand nombre de systèmes pair-à-pair et leur succès est un témoignage de la capacité de l'Internet à accepter des applications complètement imprévues à l'origine. Cette variété est telle qu'il est difficile de s'y retrouver, par exemple pour d'éventuels travaux de normalisation sur les protocoles pair-à-pair. D'où ce document de l'IAB, qui définit ce qu'est un système pair-à-pair, et propose une taxonomie de ceux-ci. Ce RFC propose également des méthodes pour analyser si un système pair-à-pair est adapté à un problème donné.

Pourtant, on ne manque pas de textes sur les systèmes pair-à-pair. Il y a eu de très nombreuses publications scientifiques, plusieurs conférences uniquement consacrées à ce sujet, et un groupe de travail de l'IRTF lui est entièrement voué. Et, bien sûr, il existe de nombreuses applications pair-à-pair, certaines avec un code source disponible, et parmi lesquelles se trouvent des applications parmi les plus populaires sur l'Internet.

Mais il n'existe pas encore de compréhension commune de ce qu'est le pair-à-pair et, pire, beaucoup de gens, de bonne ou de mauvaise foi, assimilent « pair-à-pair » aux seules activités illégales de transfert de fichiers (section 1 du RFC).

Le but de de document est donc d'aider à la construction de cette compréhension commune et de montrer que le pair-à-pair est largement utilisé pour des activités tout à fait légitimes.

La section 2 du RFC s'attaque à la définition du pair-à-pair. Il existe plusieurs définitions, qui ne sont pas forcément équivalentes, d'autant plus que le marketing s'en mêle et que « pair-à-pair » est souvent un terme vendeur. En outre, la section 2 prévient aussi que certains systèmes souvent qualifiés de « pair-à-pair » ne correspondront que partiellement à cette définition et ne pourront donc pas être considérés comme complètement « pair-à-pair ». Ce n'est pas forcément un défaut : le but est de bâtir le meilleur système possible, pas de coller à la définition du « pair-à-pair ». Bien des systèmes réussis sont « mixtes », mélangeant « pair-à-pair » et « centralisé ».

La définition de ce RFC 5694 est donc : « Est pair-à-pair un système où les éléments qui le composent partagent leurs ressources pour fournir le service pour lequel le système est prévu. Chaque élément du système fournit des services et en reçoit. » En théorie, cette définition impose que tous les éléments partagent leurs ressources mais, en pratique, il existe des systèmes où certains éléments sont des clients purs, ne fournissant aucune ressource. Le RFC considère qu'un système où les clients seraient nettement plus nombreux que les pairs ne serait pas réellement pair-à-pair. Par contre, le RFC note explicitement que le fait que certaines parties du système soient centralisées ne l'empêche pas d'être pair-à-pair. L'exemple cité est celui d'un système où il y aurait un serveur central pour enregistrer les nouveaux pairs. Un tel système serait pair-à-pair, selon la définition proposée.

On peut ensuite faire varier cette définition à l'infini, en ajoutant que les pairs doivent participer à des transactions qui ne leur bénéficient pas directement, ou que les pairs doivent pouvoir communiquer sans passage par un intermédiaire, ou que le contrôle doit être entièrement distribué (sans aucun serveur central, contrairement à ce qu'accepte la définition du RFC 5694).

Il est d'autant plus difficile de classer les systèmes pair-à-pair que beaucoup sont composites, faits de plusieurs services, pas forcément pair-à-pairs. Ainsi, si j'utilise un moteur de recherche BitTorrent accessible par le Web, comme btjunkie, pour récupérer ensuite un fichier avec le protocole BitTorrent, suis-je en pair-à-pair ou pas, le Web étant client/serveur ?

Notre définition étant posée, le reste de la section 2 va l'appliquer à divers systèmes existants, pour voir s'ils peuvent être considérés pair-à-pair ou pas.

La section 2.1 commence ces applications avec le DNS. Les résolveurs DNS étant des clients purs, qui ne fournissent aucun service, le DNS ne peut pas être considéré comme pair-à-pair selon la définition de notre RFC.

Et SIP (RFC 3261) ? La section 2.2 en rappelle les principes, notamment le fait que les user agents sont à la fois client et serveurs. Mais un user agent ne participe qu'aux transactions qui ont un intérêt pour lui (parce qu'il appelle ou bien qu'il est appelé) et le SIP traditionnel ne peut pas être considéré comme pair-à-pair. En revanche, P2PSIP, décrit en section 2.3, est différent : les user agents ne s'enregistrent plus auprès d'un serveur mais entre eux et la fonction de rendez-vous nécessite donc la participation d'autres pairs, qui n'y tirent pas de bénéfice personnel. P2PSIP est donc bien pair-à-pair.

L'un des protocoles pair-à-pair les plus connus est BitTorrent. La section 2.4 examine son cas. Comme un pair BitTorrent, non seulement récupère des fichiers pour son usage personnel, mais en outre en envoie à d'autres, sans que cela ne présente d'interêt pour eux, BitTorrent est bien pair-à-pair. Toutefois, le monde réel est toujours plus compliqué que cela et le RFC note que, si la majorité de l'essaim (l'ensemble des pairs), est composée de pairs ayant récupéré tous leurs fichiers et ne faisant plus que les distribuer (des seeders dans la terminologie BitTorrent), alors, l'essaim ne fonctionne plus vraiment en pair-à-pair.

Après ces études de cas, le RFC se penche, dans sa section 3, sur les fonctions qu'il faut assurer pour qu'un système pair-à-pair fonctionne. Au minimum, et quel que soit le service fourni par ce système, il faut assurer :

• Le recrutement, c'est-à-dire le mécanisme d'authentification et d'autorisation auxquels sont soumis les nouveaux pairs,
• La découverte des pairs : le nouveau nœud du réseau doit trouver un ou plusieurs pairs pour commencer la communication.

Dans certains systèmes pair-à-pairs (par exemple eDonkey), ces fonctions sont centralisées. Un serveur de recrutement (dit parfois bootstrap server) est contacté par les nouveaux venus, et il peut, après les avoir autorisés, les mettre en contact avec les autres pairs. Ce serveur est évidemment un point vulnérable du réseau mais notre RFC 5694 ne considère pas que son existence empêche le système d'être authentiquement pair-à-pair. En effet, les fonctions considérées comme significatives sont celles qui ont un rapport direct avec le service fourni.

À noter que ces fonctions peuvent avoir été programmées une fois pour toutes dans un ensemble logiciel qui sert de base pour la construction d'un système pair-à-pair (cf. section 5.4). C'est le cas par exemple de JXTA.

Celles-ci dépendent du service et ne sont donc pas présentes systématiquement. On trouve parmi elles :

• L'indexation des données présentes dans le système.
• Le stockage des données présentes dans le système.
• Les calculs que doit faire le système.
• L'acheminement de messages d'un pair à l'autre, acheminement qui peut impliquer plus de deux pairs.

Il reste à classer les différents systèmes pair-à-pair. La section de taxonomie est la numéro 4. Le problème n'est pas simple puisqu'il existe déjà plusieurs classifications incompatibles des systèmes pair-à-pair. Pire, le vocabulaire n'est même pas identique entre les auteurs (par exemple pour des termes comme « première génération » ou « deuxième génération »). Notre RFC propose de partir de la fonction d'indexation. Un index peut être centralisé, local ou distribué (cf. RFC 4981). Dans le premier cas, une seule machine garde trace de toutes les données (Napster fonctionnait ainsi). Dans le second, chaque machine se souvient des données qui l'intéressent (les premières versions de Gnutella fonctionnaient ainsi). Avec un index distribué, les références aux données se trouvent sur plusieurs machines. Les DHT sont un bon exemple d'un tel système.

On peut aussi classer les index entre ceux avec ou sans sémantique. Les premiers contiennent des informations sur les relations entre les données et les métadonnées mais pas les seconds. Les index avec sémantique permettent donc des recherches plus riches mais ne trouvent pas forcément toutes les données présentes.

D'autres auteurs ont classé les systèmes pair-à-pair entre systèmes hybrides (pas complètement pair-à-pair, par exemple parce qu'ils ont un index centralisé) et purs. Les systèmes purement pair-à-pair peuvent continuer à fonctionner même quand n'importe laquelle des machines qui les composent est en panne ou arrêtée.

Une autre classification est selon la structure. Les systèmes non structurés sont ceux où un nouveau pair peut se connecter à n'importe quel pair existant. Les systèmes structurés imposent au pair arrivant de ne se connecter qu'à certains pairs bien définis, en fonction de leur identité (c'est par exemple le cas des DHT, où les pairs sont en général organisés en un anneau virtuel dans l'ordre des identificateurs). Mais, là encore, la distinction n'est pas absolue et on trouve, par exemple, des systèmes non structurés où certains pairs ont des rôles particuliers.

Une autre classification qui a eu un relatif succès médiatique est par « génération ». Certains auteurs ont classé les systèmes à index centralisé dans une « première génération du pair-à-pair », ceux à index local dans la seconde génération et ceux utilisant une DHT dans la troisième. Cette classification a plusieurs problèmes, l'un des principaux étant qu'elle laisse entendre que chaque génération est supérieure à la précédente.

Aucune de ces classifications ne prend en compte les fonctions de recrutement et de découverte : un système peut donc être pair-à-pair même si un des ces fonctions, ou les deux, est effectuée par un mécanisme centralisé.

Si on développe des systèmes pair-à-pair, c'est parce qu'ils ont une utilité concrète. La section 5 décrit les principaux domaines d'application des systèmes pair-à-pair. Le plus connu est évidemment la distribution de contenu, qui fait l'objet de la section 5.1. Parfois, ce contenu est composé de fichiers illégalement distribués, par exemple parce que ledit contenu n'est pas encore monté dans le domaine public dans tous les pays. Mais le pair-à-pair va bien au delà des utilisations illégales. La distribution de contenu sur Internet se fait par de nombreux moyens, HTTP, RFC 7230 et FTP, RFC 959 étant les plus traditionnels, et personne ne prétend que HTTP est néfaste parce que du contenu illégal est parfois distribué par HTTP.

Parmi les exemples importants de distribution de contenu légal par le pair-à-pair, il y a les systèmes d'exploitation dont les images ISO sont distribués en BitTorrent (comme Debian ou NetBSD), soulageant ainsi les serveurs de l'organisation, qui n'a pas en général de grands moyens financiers pour leur fournir une capacité réseau suffisante. Il y a aussi les mises à jour de logiciel commerciaux comme World of Warcraft et bien d'autres.

Le gros avantage du pair-à-pair, pour ce genre d'applications, est le passage à l'échelle. Lorsqu'une nouvelle version de NetBSD est publiée, tout le monde la veut en même temps. Un serveur FTP ou HTTP central, même avec l'aide de dix ou vingt miroirs, s'écroulerait sous la charge, tout en restant très sous-utilisé le reste du temps. Au contraire, un protocole comme BitTorrent marche d'autant mieux qu'il y a beaucoup de téléchargeurs (les leechers dans la terminologie BitTorrent). L'effet est équivalent à celui de milliers de miroirs, sans que l'utilisateur n'aie à les choisir explicitement.

Cette question de la sélection du pair d'où on télécharge le fichier est centrale pour l'efficacité d'un système pair-à-pair. L'un des problèmes que pose cette sélection est que les intérêts des différentes parties peuvent être contradictoires. Les utilisateurs veulent le pair le plus rapide, les gérants du système de distribution du contenu voudraient que les pairs possédant les parties les plus rares soient sélectionnés en premier (pour augmenter la fiabilité globale de la distribution), les FAI voudraient que les pairs situés sur leur propre réseau soient privilégiés. Il n'est pas étonnant que la sélection du pair aie été tant discuté au IETF workshop on P2P Infrastructure de 2008 (dont un compte-rendu figure dans le RFC 5594). Le groupe de travail Alto de l'IETF est chargé de travailler sur ce point.

La section 5.1 se termine sur un exemple original, Zebranet, un système de collecte de données sur les zèbres en liberté. Chaque animal porte un collier qui collecte des informations et les transmet aux stations qui se déplacent dans la savane. Mais il arrive souvent qu'un zèbre ne passe jamais près d'une station ! Zebranet permet alors la transmission de données de collier à collier. Chaque zèbre rassemble ainsi les données de plusieurs autres animaux, et le passage d'un seul zèbre près de la station permet de récolter toutes ces données d'un coup. Le RFC note toutefois que Zebranet n'est pas vraiment pair-à-pair puisque le collier ne fait que donner et la station que recevoir.

Une autre utilisation courante du pair-à-pair est le calcul distribué (section 5.2). Une tâche de calcul y est divisée en plusieurs sous-tâches, chacune confiée à une machine différente. Il est général bien moins coûteux d'avoir beaucoup de machines bon marché et relativement lentes plutôt qu'un seul supercalculateur. Contrairement à une grappe, les pairs sont typiquement très éloignés les uns des autres. Il existe aujourd'hui bien des systèmes de calcul distribué (comme Boinc) mais la plupart ne peuvent pas être considérés comme pair-à-pair et seraient mieux qualifiées de « maître-esclave ». En effet, en général, il existe un nœud central, qui décide des calculs à effectuer et les différentes machines lui obéissent, sans tirer elle-mêmes profit du calcul fait (un exemple typique est SETI@home). Tous les systèmes compris sous l'appelation marketing de grille sont dans ce cas.

C'est également la même chose pour l'une des plus grosses applications du calcul distribué, les botnets. Même lorsqu'ils reposent sur une technique pair-à-pair comme Storm, qui dépend d'une DHT, le zombie ne tire pas de profit des actions du botnet, que ce soit l'envoi de spam ou bien la dDoS. Il ne fait qu'obéir aveuglément au C&C (Command and Control Center, la ou les machines qui dirigent le botnet.

La troisième grande catégorie, les applications de collaration, fait l'objet de la section 5.3. Les plus connues de ces applications sont celles de voix sur IP et de messagerie instantanée. Si la conversation elle-même se fait entre deux machines, le rendez-vous initial peut être réalisé en pair-à-pair, comme ce que permet P2PSIP (cf. section 2.3).

Bien, il y a donc de nombreuses applications qui utilisent le pair-à-pair. Mais est-ce à juste titre ? Dans quels domaines le pair-à-pair est-il fort et dans quels domaines vaut-il mieux s'en méfier ? C'est l'objet de la section 6 qui donne des critères d'évaluation des avantages et inconvénients du pair-à-pair. Notre RFC note qu'il n'existe pas de règle simple, la réponse à la question « Vaut-il mieux utiliser le pair-à-pair ? » dépend de beaucoup de choses. Parmi les points importants, le RFC note que les systèmes pair-à-pair sont particulièrement adaptés aux cas où il n'existe pas d'infrastructure existante et où il serait difficile de l'installer, ce qui est le cas des réseaux ad hoc.

Autre point fort du pair-à-pair, le passage à l'échelle. Avec lui, augmenter les ressources du système se fait simplement en ajoutant de nouveaux pairs. Si l'application envisagée doit pouvoir grossir jusqu'à la taille de l'Internet, le pair-à-pair est souvent une option à regarder sérieusement. (En fait, tout n'est pas toujours si simple et la fin d'OpenDHT a montré que le pair-à-pair ne se fait pas forcément tout seul.)

Si on est désireux d'avoir une application fiable (cf. RFC 4981), les systèmes pair-à-pair sont également intéressants. Si chaque pair individuel est en général considéré comme peu fiable, le système complet est conçu pour fonctionner alors même que les pairs individuels arrivent ou repartent du groupe en permanence. Il peut donc être très robuste.

Et les performances ? Il est difficile de dire si le pair-à-pair est plus rapide ou pas, cela dépend de nombreuses choses. Des « pique-assiettes » (free riders), qui profitent du système mais ne lui fournissent rien, peuvent sérieusement dégrader ces performances. D'où la recherche permanente de bons mécanismes d'incitation pour que les pairs ne se conduisent pas en parasites.

Un système pair-à-pair réel doit parfois choisir entre toutes ces caractéristiques. Le RFC cite l'exemple d'une base de données pair-à-pair : si toutes les données sont dupliquées sur tous les pairs, elle serait très robuste face aux pannes et très rapide en lecture. Mais l'arrivée d'un nouveau pair serait très lente parce qu'il devrait commencer par tout recopier. Et les écritures prendraient un temps fou.

Et les questions de sécurité ? Lorsque des tas de machines, parfois placées sous des administrations différentes, travaillent ensemble, ces problèmes de sécurité prennent une autre ampleur. La section 7 leur est consacrée. D'abord, toutes les machines du système sont-elles de confiance ? Certains systèmes pair-à-pair n'enrôlent pas n'importe qui mais uniquement des machines appartenant à la même entité. Dans ces conditions, le problème est plus facile à résoudre. Par contre, avec un système pair-à-pair ouvert à tout l'Internet, que n'importe quelle machine peut joindre quand elle veut, le problème devient un défi...

Dans tous les cas, la liste des problèmes de sécurité potentiels posés par les systèmes pair-à-pair est longue. Par exemple :

• Pour les systèmes qui ont un composant centralisé, une DoS réussie contre ce composant stoppe tout service,
• Pour les (nombreux) systèmes pair-à-pair où les messages ne sont pas transmis directement mais routés d'un pair à un autre jusqu'à la destination finale (cas de DHT comme Chord par exemple), les pairs intermédiaires ont des capacités de nuisance très importantes. Une attaque Sybil peut aboutir à ce qu'une grande partie des intermédiaires ne soient pas dignes de confiance,
• Si le protocole utilisé ne chiffre pas les messages, ceux-ci peuvent être écoutés par les routeurs IP mais aussi par les pairs intermédiaires (si on chiffre, il faut quand même laisser ceux-ci déchiffrer ce qui concerne le routage),
• Pour les systèmes pair-à-pair qui permettent le stockage des données, comme les DHT, un attaquant peut essayer d'épuiser les ressources. Un quota peut donc être nécessaire (ou une politique de nettoyage, comme le faisait OpenDHT),
• Si l'attaquant ne réussit pas à faire enrôler des machines à lui pour s'insérer dans le système, il peut, dans certains cas, subvertir le routage pour arriver à recevoir quand même les messages (attaque Eclipse, voir « Eclipse Attacks on Overlay Networks: Threats and Defenses).

Les registres, par exemple les registres de noms de domaine fonctionnent parfois sur un modèle registry/registrar c'est-à-dire où le client final doit passer par un intermédiaire, le bureau d'enregistrement (registrar) pour enregistrer son nom de domaine. Le registrar souhaite en général avoir un protocole de communication avec le registre afin d'automatiser ses opérations, dans son langage de programmation favori. EPP, décrit dans ce RFC, est un de ces protocoles d'avitaillement (provisioning, et merci à Olivier Perret pour la traduction). (EPP n'emploie pas le terme de registrar mais celui de sponsoring client, plus neutre. EPP peut donc en théorie être utilisé en cas de vente directe.)

Notre RFC remplace le second RFC sur EPP, le RFC 4930, mais les changements sont mineurs (cf. annexe C, le principal étant que le RFC rend plus clair le fait que la liste des codes de retour est limitative : un registre ne peut pas créer les siens, ce qui est une des plus grosses limitations de EPP). EPP est désormais une norme complète (Full Standard).

EPP a été réalisé sur la base du cahier des charges dans le RFC 3375. Au lieu de s'appuyer sur les protocoles classiques de communication comme XML-RPC ou SOAP, ou même sur l'architecture REST, EPP crée un protocole tout nouveau, consistant en l'établissement d'une connexion (authentifiée) puis sur l'échange d'éléments XML, spécifiés dans le langage W3C Schemas.

Par exemple, l'ouverture de la connexion se fait en envoyant l'élément XML <login> (section 2.9.1.1) :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
     epp-1.0.xsd">
  <command>
    <login>
      <clID>ClientX</clID>
      <pw>foo-BAR2</pw>
      <newPW>bar-FOO2</newPW>
      <options>
        <version>1.0</version>
        <lang>fr-CA</lang>
      </options>
      <svcs>
        <objURI>urn:ietf:params:xml:ns:obj1</objURI>
        <objURI>urn:ietf:params:xml:ns:obj2</objURI>
        <objURI>urn:ietf:params:xml:ns:obj3</objURI>
      </svcs>
    </login>
    <clTRID>ABC-12345</clTRID>
  </command>
</epp>

Les espaces de noms utilisés, comme urn:ietf:params:xml:ns:epp-1.0 sont enregistrés dans le registre IANA (cf. section 6). Le <clTRID> est un identifiant de transaction (celui-ci est choisi par le client) et il facilite la traçabilité des opérations EPP. L'exécution de ces éléments doit être atomique (section 2 du RFC).

Chaque commande EPP entraîne une réponse (section 2.6) qui inclus notamment un code numérique à quatre chiffres (section 3) résumant si la commande a été un succès ou un échec (reprenant le schéma expliqué dans la section 4.2.1 du RFC 5321). Le premier chiffre indique le succès (1) ou l'échec (2) et le second la catégorie (syntaxe, sécurité, etc). Par exemple 1000 est un succès complet, 1001 un succès mais où l'action n'a pas encore été complètement effectuée (par exemple parce qu'une validation asynchrone est nécessaire), 2003, une erreur syntaxique due à l'absence d'un paramètre obligatoire, 2104 une erreur liée à la facturation (crédit expiré, par exemple), 2302, l'objet qu'on essaie de créer existe déjà, etc.

EPP est donc typiquement un protocole synchrone. Toutefois, il dispose également d'un mécanisme de notification asynchrone. La commande EPP <poll> (section 2.9.2.3) permet d'accéder à des messages qui avaient été mis en attente pour un client, et lui donnaient l'état des traitements asynchrones.

Le RFC 5730 spécifie une dizaine de commandes EPP comme <check>, qui permet de s'assurer qu'un objet peut être créé, <info>, qui permet d'accéder aux informations disponibles à propos d'un objet existant (comme whois sauf que whois est typiquement public et EPP typiquement réservé aux bureaux d'enregistrement), <create> pour créer de nouveaux objets (par exemple réserver un nom de domaine), etc.

Comme tout objet géré par EPP a un « sponsoring client », l'entité qui le gère (dans le cas d'un registre de noms de domaine, il s'agit typiquement du bureau d'enregistrement), EPP fournit une commande pour changer ce client, <transfer> (section 2.9.3.4). Des options de cette commande permettent d'initier le transfert, d'annuler une demande en cours, de l'approuver explicitement (pour le client sortant), etc.

La syntaxe formelle des éléments XML possibles est décrite dans la section 4, en utilisant le langage W3C schema.

Le transport de ces éléments XML sur le réseau peut se faire avec différents protocoles, s'ils respectent les caractéristiques listées en section 2.1. Par exemple, le RFC 5734 normalise EPP reposant directement sur TCP.

Un des points délicats de la conception d'un tel protocole est que chaque registre a sa propre politique d'enregistrement et ses propres règles. Quoi que dise ou fasse l'ICANN, cette variété va persister. Par exemple, l'expiration automatique d'un domaine existe dans .com mais pas dans .eu ou .fr. Le protocole EPP ne prévoit donc pas d'éléments pour gérer telle ou telle catégorie d'objets (les domaines mais aussi les serveurs de noms ou les contacts). Il doit être complété par des mappings, des schémas définissant une classe d'objets. Certains de ces mappings sont spécifiés pas l'IETF comme le domain mapping (gestion des domaines) dans le RFC 5731. L'annexe A fournit un exemple de mapping. Plusieurs registres utilisent des mappings non-standard, pour s'adapter à leurs propres règles d'enregistrement, ce qui limite la portabilité des programmes EPP (le cadre d'extension de EPP fait l'objet de la section 2.7). C'est ce qu'ont fait les français, les brésiliens ou les polonais.

Dans tous les cas, chaque objet manipulé avec EPP reçoit un identificateur unique (par exemple SB68-EXAMPLEREP), dont les caractéristiques sont normalisées dans la section 2.8. Les dépôts possibles sont enregistrés dans un registre IANA.

Complexe, EPP n'a pas été reçu avec enthousiasme chez les registres existants, sauf ceux qui refaisaient complètement leur logiciel comme .be. On notera que certains gros TLD comme .de n'utilisent pas EPP (Denic utilise son protocole MRI/RRI). Il existe d'autres protocoles d'avitaillement comme :

• Le registre Adams' Names a son protocole au dessus de XML-RPC,
• Le registrar Gandi utilise son protocole, au dessus de XML-RPC pour ses revendeurs,
• Le registrar BookMyName utilise son protocole, au dessus de SOAP pour ses revendeurs,
• OVH a aussi une API SOAP très riche,

et beaucoup d'autres qui ne semblent pas forcément documentés publiquement.

Il existe plusieurs mises en œuvres d'EPP en logiciel libre par exemple le serveur EPP OpenReg de l'ISC, le logiciel Fred du registre de .cz ou bien le client EPP Net::DRI de Patrick Mevzek. Si vous voulez expérimenter avec EPP, vous devez installer votre propre serveur, il n'existe pas de serveur public pour tester.

Quelques photos du festival Dreamination, festival de sculptures lumineuses, qui se tient en ce moment à Hiroshima.

Il existe désormais de nombreuses villes dans le monde avec un système de vélos en libre-service. Hiroshima est en train de beta-tester le sien, baptisé E-cycle. J'ai pu le tester à l'occasion de la réunion IETF dans cette ville.

Le groupe de travail Alto de l'IETF est chargé de développer un protocole permettant aux participants d'un réseau pair-à-pair de trouver le pair le plus « proche », pour améliorer la communication ultérieure et consommer moins de ressources réseau. Ce premier RFC officiel du groupe décrit le problème à résoudre.

Le fond du problème est que les pairs ne connaissent pas la topologie du réseau. Disposant de trop peu d'informations, ils risquent de choisir, parmi les pairs potentiels, un pair situé très loin d'eux, ce qui se traduira par une capacité réseau inférieure, et une utilisation exagérée des lignes à longue distance, alors que des réseaux à courte distance, moins chargés, étaient disponibles. Le but d'Alto est donc de donner aux pairs le moyen de faire des choix meilleurs que le simple hasard.

Le problème n'est d'ailleurs pas limité aux applications pair-à-pair. Comme le rappelle la section 1, les applications client/serveur traditionnelles ont également parfois à choisir entre plusieurs sources, pour une même ressource (« vais-je télécharger mon image ISO de NetBSD depuis ftp.nl.netbsd.org ou bien ftp.de.netbsd.org ? »). L'Internet est actuellement exploitée de manière très peu « développement durable ». Les applications gourmandes comme le chargement de vidéos ou l'échange de fichiers multimédia consomment beaucoup de capacité du réseau, sans faire d'effort pour minimiser cette consommation.

Comme dans l'exemple de la distribution de NetBSD ci-dessus, la ressource convoitée est aujourd'hui souvent disponible depuis plusieurs sources, chacune ayant une réplique de la ressource (section 1.1). Mais les applications ne disposent pas d'éléments suffisants pour choisir la réplique la plus proche. Des heuristiques comme le pays (dans l'exemple de NetBSD ci-dessus) sont très insuffisantes car la connectivité n'épouse pas les frontières nationales. Les mesures comme celle du RTT (mises en œuvre par un logiciel comme netselect) ne donnent pas d'informations sur la capacité du réseau (cf. RFC 5136), ni sur le coût des différentes lignes (par exemple entre transit et peering). Voici un exemple avec netselect, où il affiche le serveur ayant le plus faible RTT (l'algorithme exact de netselect est plus riche, voir la documentation) :

% netselect  ftp.be.netbsd.org ftp.nl.netbsd.org  ftp.de.netbsd.org ftp.es.netbsd.org  
   25 ftp.be.netbsd.org

et, en plus détaillé :

% netselect -vv ftp.be.netbsd.org ftp.nl.netbsd.org  ftp.de.netbsd.org ftp.es.netbsd.org
Running netselect to choose 1 out of 5 addresses.       
....................................
ftp.be.netbsd.org                       11 ms  11 hops  100% ok (10/10) [   23]
192.87.102.43                         9999 ms  30 hops    0% ok
192.87.102.42                         9999 ms  30 hops    0% ok
ftp.de.netbsd.org                       24 ms  10 hops  100% ok (10/10) [   48]
ftp.es.netbsd.org                       17 ms  10 hops  100% ok (10/10) [   34]
   23 ftp.be.netbsd.org

Face à ce problème, plusieurs groupes ont expérimenté des solutions visant à donner davantage d'information aux applications (cf. par exemple le RFC 5632, et le RFC 6029 pour une étude détaillée des propositions techniques existantes). Si cela viole un peu le modèle en couches (pour lequel l'application devrait être totalement ignorante du réseau sous-jacent), cela permet en général une nette augmentation des performances et une diminution de la consommation de ressources.

L'état de l'art est résumé dans la section 1.2 du RFC. Outre le RFC 5632, on peut consulter les références données dans le RFC comme « P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers ». Ces solutions ont en commun de fournir un mécanisme de découverte de la source d'information et, une fois qu'on a trouvé celle-ci, un mécanisme d'interrogation de la source, pour récupérer les informations qui permettront de prendre une bonne décision.

La section 2 définit les (nombreux) termes utilisés par Alto. Le schéma des protocoles est particulièrement recommandé, il illustre notamment le fait qu'Alto n'est concerné que par la récupération de l'information depuis les serveurs Alto, pas par la manière dont cette information a été récoltée par les serveurs.

Enfin, le problème qu'Alto veut résoudre est défini rigoureusement dans la section 3. Dans un environnement où on veut une ressource (un fichier MP3, par exemple), pas une machine spécifique, il s'agit de trouver la meilleure machine pour la communication, parmi un ensemble de machines qui hébergent la même ressource. « Meilleure » peut signifier plusieurs choses, débit, coût ou même d'autres critères comme la volonté de ne pas concentrer tous les « clients » sur un seul « serveur ». En tout cas, « meilleur » doit être simplement « meilleur qu'en tirant au hasard », ce choix aléatoire étant la référence de base.

Dans quels cas un protocole de type Alto serait-il utile ? La section 4 donne des exemples de scénarios. Par exemple, le partage de fichiers (section 4.1) est une application courante et très gourmande, les fichiers en question étant souvent du gros multimédia. Si je veux télécharger un film, la quantité de données à faire passer par le réseau justifie certainement de passer quelques secondes à choisir la ou les meilleures machines d'où le charger.

Même chose lorsqu'il faut choisir, dans un protocole client/serveur traditionnel comme HTTP (section 4.2), le meilleur « miroir » d'un site donné (comme dans l'exemple de NetBSD plus haut).

Il existe encore plusieurs exemples comme l'utilisation d'Alto pour aider à construire une DHT (section 4.5).

Alto soulève plein de questions (comme l'avait montré la réunion animée à Dublin). La section 5 tente d'y répondre. D'abord, quelle information doit être distribuée par Alto (section 5.1) ? Pour éviter de surcharger le protocole, il faut développer des critères permettant de dire ce qu'on distribue et ce qu'on ne distribue pas. On ne distribue certainement pas avec Alto de l'information très temporaire comme la congestion. Alto devrait servir à transporter de l'information relativement stable et, surtout, que l'application ne peut pas obtenir facilement elle-même. La mesure du RTT, par exemple, n'a pas besoin d'Alto. Mais séparer les liens Internet chers de ceux bon marché ne peut jamais être découvert par l'application et doit donc être fourni par Alto. Même chose pour toutes les notions « comptables » comme le quota restant, dans le cas d'une connexion Internet facturée à l'usage (notez que la plupart des offres Internet sur mobile sont dans ce cas, même si la publicité mensongère des opérateurs les nomme « Internet illimité ».

Et qui va rassembler l'information que les serveurs Alto distribueront (section 5.2) ? A priori, on pourrait imaginer que cela soit fait par les opérateurs (qui connaissent leur réseau), des tiers qui bénéficient de certaines informations fournies par les opérateurs (un bon exemple est Akamai) ou bien, en style davantage « 2.0 », des communautés d'utilisateurs travaillant de manière décentralisée.

Le service Alto pourra donc être présenté de manière différente (section 5.3). Il pourrait être un service centralisé ou bien être lui-même pair-à-pair. Il faudra donc prévoir un mécanisme de découverte, pour savoir où s'adresser.

Évidemment, les applications utilisée peuvent manipuler des données privées. Si j'utilise une application pair-à-pair pour récupérer des films pornos, je n'ai pas forcément envie que mon FAI soit au courant, même si c'est une activité parfaitement légale. La section 5.4 explore donc la question de la protection de la vie privée. Le serveur Alto souhaiterait avoir le plus d'informations possibles pour prendre la meilleure décision, mais l'utilisateur doit avoir un moyen de ne pas trop en dire. Un problème analogue est celui de la protection des données confidentielles de l'opérateur réseau. Celui-ci ne souhaite pas forcément que ses clients soient au courant de la topologie du réseau (section 5.5).

Enfin, le problème de la coexistence avec les caches fait l'objet de la section 5.6.

Alto pose aussi des questions liées à la sécurité (section 6). Si les problèmes de mise en œuvre du contrôle des contenus sont explicitement exclus, d'autres questions restent posées. Par exemple, comme le serveur Alto peut influencer le processus de choix d'un pair (c'est son but), Alto introduit une tierce partie dans le dialogue pair-à-pair et donc un composant de plus pour l'analyse de la securité.

Ainsi, si le serveur Alto est géré par le FAI, certains utilisateurs peuvent ne pas avoir envie de l'utiliser car ils craignent (à juste titre quand on voit le comportement de certains FAI) que le FAI ne se serve d'Alto pour imposer les quatre volontés de Warner ou de Disney, ou bien pour espionner l'activité de certains utilisateurs, ou encore pour appliquer des politiques de sélection qui sont dans l'intérêt du FAI mais pas dans celui des utilisateurs (faire passer par des routes lentes mais moins chères, par exemple).

Toutefois, il n'est pas envisagé de rendre Alto obligatoire. Si certains serveurs Alto n'agissent plus dans l'intérêt des utilisateurs, le plus simple sera de ne pas les utiliser.

La cryptanalyse progresse sans cesse et, comme aiment le répéter les experts, « Les attaques ne deviennent jamais pires, elles ne font que s'améliorer ». Les menaces contre la fonction de hachage SHA-1 devenant de plus en plus précises, cet algorithme est petit à petit remplacé par la famille SHA-2. Ce RFC 5702 spécifie ce futur remplacement pour le protocole DNSSEC.

Normalisé dans le RFC 4033 et suivants, DNSSEC, qui vise à garantir l'authenticité des ressources DNS par le biais d'une signature numérique, n'est pas lié à un algorithme particulier. Aussi bien l'algorithme asymétrique utilisé pour les signatures que celui de hachage qui sert à créer un condensat des données à signer ne sont pas fixés en dur dans le protocole. SHA-1 avait été spécifié dans le RFC 3110. Un registre IANA des algorithmes possibles existe et notre RFC 5702 marque l'entrée de la famille SHA-2 dans ce registre.

Il n'est pas évident de savoir si SHA-1 est vraiment vulnérable dès aujourd'hui. Plusieurs attaques ont été publiées dans la littérature ouverte (et il y en a donc sans doute bien d'autres, gardées secrètes) mais elles ne semblent pas facilement exploitables, surtout dans le cas de l'utilisation particulière qu'en fait DNSSEC. Néanmoins, le remplacement de SHA-1 était une nécessité, compte-tenu du fait que les attaques ne peuvent que s'améliorer (voir la section 8 pour un exposé plus détaillé), et parce qu'un tel remplacement prend du temps (par exemple, l'élaboration de ce RFC a été très longue).

Le remplaçant, SHA-2, décrit dans la norme FIPS 180-3 de 2008, n'est pas vraiment un algorithme unique mais une famille d'algorithmes. DNSSEC n'en retient que deux, SHA-256 (code 8) et SHA-512 (code 10). Voir la section 1 du RFC pour ces rappels.

SHA-2 est utilisable dans les enregistrements de type DNSKEY (clés cryptographiques distribuées par le domaine) et RRSIG (signature cryptographiques). Le RFC 4034 décrit tous ces types d'enregistrement.

La section 2 décrit les enregistrements DNSKEY. Comme la clé publique ne dépend pas de l'algorithme de hachage utilisé ultérieurement, on pourrait penser qu'ils ne sont pas modifiés. Mais il est important d'indiquer au résolveur cet algorithme de hachage car tous les résolveurs ne connaissent pas SHA-2 du jour au lendemain. Il faut donc qu'ils sachent tout de suite, en examinant la clé, s'ils pourront valider la zone ou pas. (Sinon, ils considéreront la zone comme étant non signée.) Les DNSKEY avec RSA + SHA-256 sont donc stockés avec le même format qu'avant, mais avec le numéro d'algorithme 8. Les DNSKEY avec RSA + SHA-512 auront, eux, le numéro d'algorithme 10.

Les signatures (enregistrements RRSIG) sont, elles, plus largement modifiées. La section 3 décrit ces modifications. Elle indique la représentation à suivre pour les RRSIG, suivant le standard PKCS #1 (RFC 3447).

Les signatures faites avec RSA + SHA-256 seront stockées avec le numéro d'algorithme 8 et leur codage aura un préfixe spécifique, pour les distinguer des signatures faites avec d'autres fonctions (section 3.1). Idem pour celles faites avec RSA + SHA-512 (section 3.2).

Et les problèmes pratiques du déploiement ? Pas de panique, ils sont dans la section 4. La taille des clés elle-mêmes n'est pas couverte (section 4.1) mais déferrée aux recommendations du NIST. La taille des signatures dépend de celle de la clé, pas de l'algorithme de hachage et ne changera donc pas (section 4.2).

Quels logiciels peuvent aujourd'hui utiliser ces algorithmes ? Pour BIND, ce sera à partir de la version 9.7 (actuellement en béta publique, mais sans SHA-2). Pour ldns, c'est déjà disponible dans la version actuelle, la 1.6.1 (mais tous les paquetages binaires de ldns n'ont pas forcément été compilés avec l'option --enable-sha2). La section 5 donne quelques détails pour les programmeurs, notamment sur la raison pour laquelle il n'y a plus de version spécifique à NSEC3 (section 5.2 et RFC 5155).

Voici un exemple d'utilisation du programme ldns-keygen (livré avec ldns) pour générer des clés utilisant SHA-256 pour la zone vachement-secure.example :

% ldns-keygen -a RSASHA256 vachement-secure.example
Kvachement-secure.example.+008+23094

% cat Kvachement-secure.example.+008+23094.key 
vachement-secure.example.       3600    IN      DNSKEY  256 3 8 \
      AwEAAc87fkhQ3RehZ9AWUtataphm6Ku+DLKgtUPp/Zi0mwhtDN36oWBhzUt5a82Zeat4zsbC6WjIDWWqOx33cWh3ISMKDK0cOu1kMRCZTXS98WoSA0TgfMBdGdaK/Z+yLX+COq8HL72gBDG/RuDqIOwdtCBhbDluIwafzPAw3l2rIEiR \
      ;{id = 23094 (zsk), size = 1024b}

Et lorsqu'on la signe :

% ldns-signzone  vachement-secure.example.zone Kvachement-secure.example.+008+23094

% cat vachement-secure.example.zone.signed
...
.       3600    IN      SOA     localhost. root.localhost. 1 604800 86400 2419200 604800
.       3600    IN      RRSIG   SOA 8 0 3600 \
                    20091125150944 20091028150944 23094 . nvIldICQaBpHR/Fn264gL
7bl5RCzzM6h3S5o6k/yq9cFRhYpOO4FQGfozP2q8A7whoHfymCg1D6harOt7b0ffO+TA1iBddpF1DJLQ/DKPhfS2REqXbXjpveU3uQNK
g0jOdj7G6hrSQl9wXg3Co5yL84jG33oSlDWQM9QhKUyAUk= \
                    ;{id = 23094}

Comme il y a déjà eu des attaques de cryptanalyse contre SHA-1 publiées, la section 8, qui synthétise les questions de sécurité, recommande donc d'utiliser SHA-2 pour les futurs déploiement de DNSSEC.

Enfin, la section 8.2 explique pourquoi SHA-2 n'est pas vulnérable aux attaques par repli : si une zone a deux clés, utilisant SHA-1 et SHA-2, un méchant ne peut pas forcer l'utilisation de l'algorithme le plus faible car les enregistrements DNSSEC doivent être signés avec toutes les clés présentes.

Si on veut voir des signatures en vrai, la racine, et des TLD comme .pm sont signés (au 28 juin 2010) avec SHA-256, tandis que .cat est signé avec SHA-512. Sinon, on peut trouver des exemples de DNSKEY et de RRSIG utilisant SHA-2 dans la section 6 du RFC, ou bien les générer soi-même comme dans l'exemple ci-dessus.

Depuis le RFC 1997 en août 1996, les annonces BGP effectuées par un routeur sont fréquemment marquées par une communauté, un nombre qui identifie des caractéristiques particulières d'une route, comme, par exemple, le fait qu'elle ne doive pas être réexportée vers d'autres AS. Ces communautés étaient traditionnellement encodées sous la forme { numéro d'AS : valeur de la communauté } en profitant du fait que les communautés du RFC 1997 faisaient quatre octets (deux pour l'AS et deux pour la valeur spécifique à l'AS). Avec l'arrivée des AS sur quatre octets, il fallait un nouveau type de communauté.

Le RFC 1997 recommandait ce type d'encodage, qu'on retrouve dans la documentation des politiques de routage de nombreux AS. Par exemple, whois -h whois.ripe.net AS3356 nous montre :

remarks:        --------------------------------------------------------
remarks:        prefix type communities
remarks:        --------------------------------------------------------
remarks:        3356:123  - Customer route
remarks:        3356:666  - Peer route
remarks:        --------------------------------------------------------
remarks:        error type communities
remarks:        --------------------------------------------------------
remarks:        3356:911  - "internal use" communities received from peer
remarks:        --------------------------------------------------------
remarks:        city communities (some cities not listed as they home off
remarks:        one of the below)
remarks:        --------------------------------------------------------
remarks:        3356:2001 - CHI1 - Chicago
remarks:        3356:2002 - SDG1 - San Diego
remarks:        3356:2003 - LAX1 - Los Angeles
remarks:        3356:2004 - DEN1 - Denver
...

où on voit une communauté encodée sous forme de numéro d'AS (3356), d'un deux-points et d'une valeur.

Mais, depuis le RFC 4893, en mai 2007, les numéros d'AS peuvent faire quatre octets et, à partir du 1er janvier 2010, ce sera même la taille par défaut, distribuée par les RIR. L'ancien encodage ne convenait pas.

Notre RFC 5668 propose donc un nouveau mécanisme. Il s'appuie sur les « communautés étendues » du RFC 4360, qui normalisait un type de communauté n'ayant plus la limitation des quatre octets et où les deux premiers octets indiquaient le type de communauté.

Notre RFC 5668 déclare donc un nouveau type de communauté étendue, pour les AS à quatre octets. Sa structure est détaillé dans la section 2. Le premier octet du champ Type du RFC 4360 vaut 0x02 pour les communautés transitives et 0x42 pour les autres (le tout est enregistré dans le registre IANA). Le champ Valeur de la communauté étendue, pour qui le RFC 4360 réserve six octets est séparé en deux, la partie Global Administrator, qui stocke l'AS sur quatre octets, et la partie Local Administrator, qui stocke une valeur spécifique à l'AS, sur les deux octets restants.

Petit piège mentionné en section 3, bien que ces communautés étendues pour AS 4-octets permettent de représenter les anciens AS 2-octets (en ajoutant des zéros devant), cela ne doit pas être fait, pour éviter qu'une communauté puisse être codée de deux façons différentes (ce qui compliquerait les comparaisons).

Il n'y a pas de nouvelle représentation texte standard de ces communautés, on reprend l'existante, comme dans l'exemple de l'AS 3356 plus haut.

Le système de transmission radio par micro-ondes Wimax, normalisé par l'IEEE sous le numéro de 802.16, offre une interface Ethernet aux protocoles de couche réseau comme IP. À première vue, on pourrait penser qu'il n'y a donc rien de spécial à faire pour faire fonctionner IP sur Wimax. En fait, ce système offre suffisamment de particularités par rapport à l'Ethernet filaire pour que ce RFC soit nécessaire, pour normaliser les points de détails où il faut s'écarter de l'usage classique d'Ethernet.

Parmi les points importants de Wimax, système conçu pour fonctionner à grande distance, contrairement au Wifi :

• Il n'est pas pair-à-pair. Les machines connectées (nommées SS pour Subscriber Station) ne peuvent pas se parler directement, elles doivent passer par la station de base (BS pour Base Station).
• Wimax est orienté connexion et non pas datagramme : la machine ne peut pas transmettre avant une négociation avec la station de base, qui lui alloue un canal et des ressourecs.
• Il n'y a pas de vraie diffusion : une machine qui veut parler à toutes les autres doit transmettre à la station de base, qui diffusera.
• Comme souvent avec les transmissions radio, les machines qui l'utilisent peuvent avoir des ressources limitées, notamment en électricité, et il faut éviter de les activer pour un oui ou pour un non.
• Wimax offre, entre autres, une interface (un convergence layer, dans la terminologie IEEE) Ethernet. Mais Ethernet avait été prévu pour un bus, un média partagé, alors que Wimax est point-à-multipoint.

La norme IEEE 802.16 est très riche et complexe et beaucoup d'options qu'elle présente peuvent avoir une influence sur IP.

Le défi de ce RFC 5692 (section 1) est donc de profiter de l'interface Ethernet de Wimax, tout en l'optimisant pour l'usage d'IPv4 et IPv6, sans abandonner les principes de base de l'IP sur Ethernet. Le cahier des charges détaillé avait fait l'objet du RFC 5154.

La section 4 décrit le modèle d'IEEE 802.16. Chaque connexion entre la SS (la machine qui se connecte) et la BS (la station de base) reçoit un identificateur sur 16 bits, le CID (Connection Identifier). Il peut y avoir plusieurs connexions entre une BS et une SS. L'acheminement des paquets se fait avec le CID, pas avec l'adresse MAC de l'interface Ethernet.

La section 4.2 couvre les subtilités de l'adressage 802.16. Chaque SS a une adresse MAC sur 48 bits, comme avec Ethernet. Mais la commutation des paquets par la BS se fait uniquement sur la base des CID, les identificateurs des connexions SS<->BS. L'adresse MAC sources des paquets sur un lien radio n'est donc pas forcément celle d'une des deux stations, puisque la BS peut relayer des messages, jouant le rôle d'un pont.

Contrairement au vrai Ethernet, il n'y a pas de diffusion (globale ou restreinte) avec Wimax. La BS peut diffuser à toutes les SS mais si une SS veut en faire autant, elle doit transmettre à la BS, qui reflétera le paquet vers toutes les stations (section 4.3 et annexe A).

Les concepteurs de 802.16, conscients de l'importance d'Ethernet dans le monde des réseaux, avaient prévu dans la norme un mécanisme (et même deux) pour la transmission de paquets au format Ethernet. Comme l'explique la section 4.4, le premier de ces mécanismes, Packet Convergence Sublayer permet d'affecter différents protocoles au dessus d'Ethernet à des connexions différentes (et donc d'avoir des QoS différentes).

Ethernet n'est pas seulement un format de paquets, c'est aussi un modèle de réseau où toute station d'un même Ethernet peut parler directement à n'importe quelle autre. Ce n'est pas le cas, on l'a vu, pour 802.16, et il a donc fallu introduire un pont, rôle joué par la station de base, la BS (section 5). Ce mécanisme n'est pas très différent de celui de l'Ethernet filaire commuté (section 5.1). Comme un commutateur, la BS transmet aveuglément les paquets d'une station d'abonné, une SS, à une autre.

Il reste à réaliser la diffusion (broadcast). Comme indiqué plus haut, et précisé en section 5.2, la BS réalise une diffusion en dupliquant les paquets, un exemplaire par SS destinataire.

Bien, maintenant que le modèle de la liaison et celui de l'émulation Ethernet sont clairs, comment faire passer IP là-dessus ? C'est le rôle des techniques exposées en section 6. Les sections 6.1 et 6.2 font un rappel de la méthode habituelle de transmission d'IP sur Ethernet. Décrite dans les RFC 894 pour IPv4 et RFC 2464 pour IPv6, cette méthode décrit l'encapsulation d'IP dans Ethernet, et la résolution d'adresses IP en adresses MAC par les protocoles ARP (RFC 826, pour IPv4) et NDP (RFC 4861, pour IPv6). IP sur Wimax continue dans la même veine et utilise les mêmes techniques.

C'est ici que se nichent les subtiles différences entre IP sur Ethernet et IP sur 802.16. Par exemple, la section 6.2.2.1 recommande des valeurs particulières pour certaines variables comme l'écart maximum entre deux annonces par un routeur. Comme les machines connectées en Wimax peuvent dépendre d'une batterie, qu'il faut économiser, les valeurs recommandées sont plus importantes que pour un réseau où la majorité des machines est connectée au secteur.

La section 7 détaille ces améliorations qui doivent être apportées à « IP sur Wimax ». Par exemple, la mise en œuvre de la diffusion restreinte Ethernet par les BS consiste à répéter la trame sur tous les liens virtuels, réveillant ainsi même les machines qui n'étaient pas membres du groupe multicast considéré. La section 7.1.1 demande donc que l'information sur qui est membre ou pas soit traitée par la BS, de façon à ce qu'elle sache sur quels liens transmettre la trame. Pour cela, la BS doit donc écouter le trafic lié à la diffusion restreinte, comme expliqué dans le RFC 4541.

Et la diffusion générale (broadcast) ? Elle est encore plus gourmande en électricité. La section 7.1.2 demande donc que la station de base procède intelligement et ne transmette pas les trames de diffusion des protocoles comme ARP, DHCP ou IGMP, qu'elle doit plutôt intercepter et traiter elle-même. La section 7.2 explique comment assurer ce traitement pour DHCP et la 7.3 pour ARP. Dans ce dernier cas, la BS, connaissant toutes les stations des clients et donc leurs adresses MAC, doit assurer un rôle de relais ARP. À noter que l'équivalent d'ARP pour IPv6, NDP, ne fonctionne pas de la même manière (les trames sont transmises en diffusion restreinte) et peut donc être traitée par le mécanisme général de la diffusion restreinte.

La section 10 clôt le RFC avec les questions de sécurité. Comme IP sur Wimax est très proche de IP sur Ethernet, les problèmes de sécurité liés à Ethernet sont souvent les mêmes, et les solutions aussi. Ainsi, les paquets NDP (Neighbor Discovery Protocol) peuvent être mensongers et les techniques de sécurité comme SEND peuvent être utilisées.

Deux annexes reviennent sur des choix qui ont été faits lors de l'adaptation d'IP à 802.16. L'annexe A discute la possibilité d'utiliser des CID (Connection Identifier) pour la diffusion restreinte, mais la rejette car la diffusion restreinte de 802.16 ne fonctionne que dans un seul sens, de la BS vers les SS. De plus, elle nécessite un traitement par toutes les machines à qui la BS a envoyé la trame, les forçant ainsi à se réveiller et à consommer du courant.

L'annexe B discute pour sa part les avantages et les inconvénients d'un pont centralisé entre les SS, par rapport à un ensemble de ponts connectés entre eux.

Tout le monde a parlé de Google Wave au moment de sa sortie, alors, pourquoi pas moi ? je vais expliquer ce que j'y ai compris, en commençant par des choses qui peuvent intéresser tous les utilisateurs de l'Internet, puis en passant à une analyse un peu plus technique.

Deux jeux de métriques (grandeur à mesurer, définies de façon formelle) sont normalisés dans ce RFC, l'un pour des mesures « spatiales », l'autre pour la diffusion de groupe.

Dans le cadre du RFC 2330, il existe plusieurs métriques pour mesurer des « performances » d'un réseau de bout en bout. On peut ainsi mesurer le temps de trajet (RFC 7679), le taux de perte (RFC 7680), les changements d'ordre des paquets (RFC 4737), etc. Notre RFC 5644 étend ces métriques :

• aux cas où on ne mesure pas seulement de bout en bout mais également aux routeurs intermédiaires,
• aux cas où il y a plusieurs destinations pour un paquet (multicast).

Ici, je parlerais surtout des premières, les métriques dites « spatiales » (voir les sections 7 et 8 pour les autres).

Comme les précédentes, ces nouvelles métriques sont enregistrées dans le registre créé par le RFC 4148. Les définitions nécessaires figurent dans la section 2. Ainsi, métrique multipartite (multiparty metric) est définie (section 2.4) comme le cas où il existe plusieurs points de mesure, une métrique spatiale (spatial metric) est (section 2.5) celle où certains des points de mesure ne sont ni la source, ni une destination du paquet (mais des routeurs situés sur le trajet). Et la métrique de groupe est (section 2.6) celle où il existe plusieurs destinations.

La section 2.7 introduit la notion de points intéressés (points of interest). Ce sont les machines où se fait la mesure. Pour les métriques spatiales, c'est un sous-ensemble des routeurs du chemin suivi par le paquet. Pour les métriques de groupe, ce sont les machines de destination.

Autre terme important, celui de vecteur (vector), défini en section 2.9. C'est simplement une liste de valeurs obtenues en différents points. Par exemple, si on mesure le temps que met un paquet multicast pour aller de la source à N destinations, le résultat de la mesure est un vecteur dont chaque composante est le temps qu'a pris le trajet de la source à un des récepteurs.

Une fois qu'on a les vecteurs, les matrices ne sont pas loin (section 2.10). Une matrice est simplement une liste de vecteurs. Dans le contexte de notre RFC, la matrice a une dimension d'espace (mesures effectuées à différents points, comme dans le vecteur cité en exemple ci-dessus) et une dimension de temps (mesures répétées dans le temps). Si on met le temps horizontalement et l'espace verticalement, une colonne est un vecteur (mesures à différents points, d'un même paquet) et une ligne est un échantillon (mesures de paquets successifs au même point).

Les métriques elles-mêmes sont introduites dans la section 3, en reprenant les concepts des RFC 2330, RFC 2679, RFC 2680, RFC 3393 et RFC 3432. Petit rappel : Type-P indique le type du paquet (TCP ou UDP, taille du paquet, etc) car les performances peuvent en dépendre. Par exemple, Type-P-Spatial-One-way-Delay-Vector reprend la métrique Type-P-One-way-Delay du RFC 2679 et l'étend en vecteur. Elle désigne donc le temps de trajet mesuré à différents points successifs du chemin (différents routeurs).

Pourquoi avoir créé ces nouvelles métriques ? La section 4 reprend les motivations du travail du groupe ippm. Pour les métriques spatiales (section 4.1), il y avait le souhait de comprendre la contribution de chaque étape du chemin au temps total (ce que fait l'ingénieur réseaux lorsqu'il regarde ce qu'affichent traceroute ou mtr avant de dire « Ça coince à tel endroit »).

Venons-en maintenant aux définitions formelles. La section 5 le fait pour les métriques spatiales. Il faut avoir bien lu avant les définitions pour les métriques de bout en bout, les métriques spatiales étant simplement une généralisation. Type-P-Spatial-One-way-Delay-Vector est définie en section 5.1 et, comme indiquée plus haut, c'est simplement l'ensemble des délais d'acheminement d'un paquet, mesuré à plusieurs points du trajet. Je ne recopie pas ici la définition détaillée et très précise du RFC mais je dis juste un mot sur la discussion en section 5.1.5. Cette métrique peut rencontrer des cas pathologiques par exemple si le temps au point N+1 est supérieur au temps au point N. Cela peut être dû à plusieurs choses comme une désynchronisation des horloges (section 3.7.1 du RFC 2679) ou bien un changement dans le routage. Entre le moment où on a déterminé l'ordre des points de mesure (par exemple en faisant un traceroute) et le moment de la mesure, le routage a pu changer et le routeur N+1 passer avant le N.

De même qu'on peut définir Type-P-Spatial-One-way-Delay-Vector en « vectorisant » Type-P-One-way-Delay, la section 5.2 crée Type-P-Spatial-Packet-loss-Vector en vectorisant Type-P-Packet-loss, le taux de perte de paquets du RFC 2680. Et la section 5.3 crée Type-P-Spatial-One-way-ipdv-vector à partir de l'IPDV (Inter-Packet Delay Variation) du RFC 5481.

Les mesures « spatiales » posent des problèmes de méthodologie particuliers qui font l'objet de la section 5.4. Ainsi, la perte d'un paquet est définie par le RFC 2680 comme la non-arrivée de ce paquet au bout d'un temps fini. Si deux points de mesure n'utilisent pas la même valeur pour ce temps, un paquet peut être considéré comme perdu à un point de mesure... mais pas à un point situé en aval, qui utilise un délai maximum plus élevé (section 5.4.1). Il est donc important que tous les points de mesure utilisent des valeurs cohérentes.

Les vecteurs de notre RFC 5644 sont ordonnés : chaque point mesure a une place, qui est l'ordre dans lequel ils voient passer le paquet. Toutes les métriques spatiales dépendent donc de cet ordre. Or, celui-ci n'est pas constant sur l'Internet. Par exemple, une instabilité temporaire du routage peut entraîner une micro-boucle où le paquet passe plusieurs fois par le même routeur et est donc observé plusieurs fois (section 5.4.2). Les points de mesure doivent donc pouvoir détecter de pareils cas, pour les éliminer des statistiques. (La section 10.2.1 mentionne aussi l'importance d'indiquer le chemin suivi par le paquet dans les publications.)

Un vecteur désigne des mesures qui varient dans l'espace, une mesure par point d'observation. Les mesures varient aussi dans le temps, ce qui mène aux métriques de la section 6. Type-P-Segment-One-way-Delay-Stream (section 6.1) est ainsi l'observation dans le temps du délai d'acheminement entre deux routeurs.

Les vecteurs étant évidemment plus gros que les scalaires, les métriques de notre RFC posent des problèmes techniques liés à l'espace de stockage nécessaire et à la capacité du réseau pour les transporter. La section 9 discute de ces détails pratiques. Par exemple, la section 9.3 expose deux méthodes de réduction des matrices avant de les envoyer, réduction sur le temps (agréger les mesures faites à des moments différents) ou bien sur l'espace (agréger les mesures de tous les routeurs). Comme seule la première méthode de réduction peut être effectuée localement, sur chaque point de mesure, c'est elle qui permet de minimiser le trafic réseau lié à ces mesures.

La plaie de DNSSEC, comme celle de tous les systèmes de cryptographie, est la gestion des clés. Avec DNSSEC, la clé de signature des autres clés, la KSK (Key Signing Key) est censée être remplacée (rolled over) régulièrement. Si un résolveur a une KSK dans sa configuration, cela oblige l'administrateur du résolveur à effectuer le remplacement à la main, ce qui peut être contraignant. Notre RFC 5011 propose une autre solution : le domaine signe la nouvelle KSK avec l'ancienne et le résolveur accepte alors automatiquement cette nouvelle clé.

Le résolveur peut ainsi construire une chaîne de confiance menant de la première clé pour laquelle il a été configuré, jusqu'à la clé actuelle. Cela implique que ledit résolveur ait un espace où écrire les clés successives qu'il a authentifié et décidé de garder.

La méthode de notre RFC présente des risques (cf. section 8.3) mais pas plus que la situation actuelle où les clés sont entièrement gérées à la main.

Ce RFC 5011 fournit donc un moyen de ne configurer la clé d'un domaine qu'une seule fois (cette configuration initiale reste manuelle), même si elle est remplacée par la suite. Le principe est simple (et le RFC est donc très court). La section 2 le décrit : quand une clé est configurée pour une zone du DNS (cette clé est dite un « trust anchor ») et qu'une nouvelle KSK apparait dans la zone, signée par l'ancienne, le résolveur accepte cette nouvelle KSK comme trust anchor et l'enregistre dans sa configuration. Une machine à états complète figure en section 4.

Le principal piège avec cette méthode est que, si une clé privée est volée, l'attaquant pourra continuer à générer une chaîne de confiance : le retrait de la clé compromise par le gérant de la zone ne suffira pas à annuler son usage. Il faut donc un mécanisme de révocation (section 2.1). Lorsqu'une KSK est publiée, signée mais que le nouveau bit REVOKE est mis, alors le résolveur doit retirer cette clé de sa configuration.

Un autre risque est que la clé privée soit volée sans que le gérant de la zone ne s'en rende compte immédiatement. Pour éviter que l'attaquant ne fasse accepter une nouvelle clé, le résolveur est supposé attendre lorsqu'une clé apparait (section 2.2). La durée d'attente est typiquement de 30 jours (section 2.4.1).

Le résolveur qui met en œuvre ce RFC 5011 doit périodiquement vérifier que la clé est toujours en service. La section 2.3 expose les règles à suivre pour cette vérification (il faut demander souvent pour détecter les nouvelles clés, sans attendre l'expiration du TTL mais pas trop pour ne pas surcharger les serveurs).

On l'a vu, ce RFC crée un nouveau booléen dans les enregistrement DNSKEY, pour indiquer la révocation. Le format est donc légèrement modifié, comme spécifié en section 3. C'est le bit n° 8 du champ DNSKEY Flags (voir section 2.1.1 du RFC 4034) qui servira à cet effet.

Si toutes les clés d'une zone sont révoquées, la zone devient non-validable (section 5), ce qui signifie qu'elle sera traitée comme si elle n'était pas signée du tout (insecure en terminologie DNSSEC).

Le bon fonctionnement de l'algorithme nécessite que la zone signée procède au remplacement des clés d'une manière particulière, décrite en section 6. Ainsi, le remplacement (rollover) va nécessiter la révocation de l'ancienne clé.

Le logiciel BIND a introduit le système de ce RFC dans sa version 9.7. (Voir le fichier README.rfc5011 dans le code source.) Cela se configure avec la directive managed-keys, qui ressemble beaucoup à trusted-keys (sauf l'ajout d'un mécanisme pour trouver la première clé, ici avec le paramètre initial-key), par exemple ainsi :

managed-keys {
    "example.com."     initial-key             257 3 5 
                                "AwEAAeeGE5unuosN3c8tBcj1/q4TQEwzfNY0GK6kxMVZ
                                1wcTkypSExLCBPMS0wWkrA1n7t5hcM86VD94L8oEd9jn
                                HdjxreguOZYEBWkckajU0tBWwEPMoEwepknpB14la1wy
                                3xR95PMt9zWceiqaYOLEujFAqe6F3tQ14lP6FdFL9wyC
                                flV06K1ww+gQxYRDo6h+Wejguvpeg33KRzFtlwvbF3Aa
                                pH2GXCi4Ok2+PO2ckzfKoikIe9ZOXfrCbG9ml2iQrRNS
                                M4q3zGhuly4NrF/t9s9jakbWzd4PM1Q551XIEphRGyqc
                                bA2JTU3/mcUVKfgrH7nxaPz5DoUB7TKYyQgsTlc=";
                                // key id = 8779
};

Une fois que BIND démarre, il crée un journal pour une zone bidon, managed-keys.bind et commence le processus décrit dans le RFC :

23-Oct-2009 10:55:10.152 zone managed-keys.bind/IN/_meta: loaded serial 0
23-Oct-2009 10:55:10.169 zone managed-keys.bind/IN/_meta: Initializing automatic trust anchor management for zone 'example.com'; \
   DNSKEY ID 49678 is now trusted, waiving the normal 30-day waiting period.

On voit que example.com a déjà une nouvelle clé, 49678, signée avec l'ancienne (celle que j'ai configurée dans manage-keys) et que BIND commence la période d'attente. Voici, avec une zone différente, le contenu de managed-keys.bind au moment où une deuxième clé vient d'être publiée :

$ORIGIN .
$TTL 0	; 0 seconds
@			IN SOA	. . (
				2          ; serial
				0          ; refresh (0 seconds)
				0          ; retry (0 seconds)
				0          ; expire (0 seconds)
				0          ; minimum (0 seconds)
				)
			KEYDATA	20150703040258 20150702160258 19700101000000 257 3 8 (
				AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbd
				pD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sM
				SoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRN
				a6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc
				2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5
				WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToT
				DNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMA
				ITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s=
				) ; KSK; alg = RSASHA256; key id = 55954
			KEYDATA	20150703040258 20150702160258 19700101000000 257 3 8 (
				AwEAAchb6LrHCdz9Yo55u1id/b+X1FqVDF66xNrhbgnV
				+vtpiq7pDsT8KgzSijNuGs4GLGsMhVE/9H0wOtmVRUQq
				Q50PHZsiqg8gqB6i5zLortjpaCLZS7Oke1xP+6LzVRgT
				4c8NXlRBg3m/gDjzijBD0BMACjVGZNv0gReAg2OCr9dB
				rweE6DnM6twG7D2NyuGjpWzKeJfNd3Hek39V9NGHuABG
				kmYG16XCao37IWcP/s/57HuBom5U3SNfuzfVDppokatu
				L6dXp9ktuuVXsESc/rUERU/GPleuNfRuPHFr3URmrRud
				4DYbRWNVIsxqkSLrCldDjP1Hicf3S8NgVHJTSRE=
				) ; KSK; alg = RSASHA256; key id = 24439

Pour Unbound, la configuration de ce RFC se fait en préfixant les directives par auto-. Ainsi, au lieu d'avoir une clé statique et qui ne bougera pas :

trust-anchor-file: "root.key"

On aura une clé modifiable :

auto-trust-anchor-file: "autokey/root.key"

Il faut bien sûr veiller à ce que le répertoire (ici autokey/) soit accessible à Unbound en écriture. Voici un fichier pour les mêmes clés que l'exemple BIND plus haut :

; autotrust trust anchor file
;;id: . 1
;;last_queried: 1435856265 ;;Thu Jul  2 16:57:45 2015
;;last_success: 1435856265 ;;Thu Jul  2 16:57:45 2015
;;next_probe_time: 1435899044 ;;Fri Jul  3 04:50:44 2015
;;query_failed: 0
;;query_interval: 43200
;;retry_time: 8640
.	86400	IN	DNSKEY	257 3 8 AwEAAaP3gGQ4db0tAiDEky0dcUNGeI1aTDYP5NFxzhbdpD60ZhKLVV4KyxPmoSNUpq5Fv5M0iBwK1Tyswsyq/9sMSoZ8zx8aT3ho1YnPsSqQeJfjTT1WsX6YZ5Kw6B2QkjRNa6OMGZ96Kn8AI/slqsw+z8hY49Sn3baeo9iJxHPzloNc2dQkW4aLqzNEYxnuoJsthCfGrPSAXlUjY9m3YKIaEWR5WFYQk770fT+gGWLk/54Vp0sG+Lw75JZnwhDhixPFaToTDNqbHQmkEylq1XJLO15uZ/+RZNRfTXZKO4fVR0tMEbMAITqRmyP8xLXY4RXbS4J32gnenQbzABX8sQmwO7s= ;{id = 55954 (ksk), size = 2048b} ;;state=1 [ ADDPEND ] ;;count=2 ;;lastchange=1435813814 ;;Thu Jul  2 05:10:14 2015
.	85667	IN	DNSKEY	257 3 8 AwEAAchb6LrHCdz9Yo55u1id/b+X1FqVDF66xNrhbgnV+vtpiq7pDsT8KgzSijNuGs4GLGsMhVE/9H0wOtmVRUQqQ50PHZsiqg8gqB6i5zLortjpaCLZS7Oke1xP+6LzVRgT4c8NXlRBg3m/gDjzijBD0BMACjVGZNv0gReAg2OCr9dBrweE6DnM6twG7D2NyuGjpWzKeJfNd3Hek39V9NGHuABGkmYG16XCao37IWcP/s/57HuBom5U3SNfuzfVDppokatuL6dXp9ktuuVXsESc/rUERU/GPleuNfRuPHFr3URmrRud4DYbRWNVIsxqkSLrCldDjP1Hicf3S8NgVHJTSRE= ;{id = 24439 (ksk), size = 2048b} ;;state=2 [  VALID  ] ;;count=0 ;;lastchange=1434990786 ;;Mon Jun 22 16:33:06 2015

Notez qu'Unbound, lui, écrit l'état des clés, VALID pour celle en cours d'utilisation et ADDPEND (Add, Pending) pour celle qui la remplacera.

Un très bon article de test de notre RFC, avec OpenDNSSEC, BIND et Unbound, par Jan-Piet Mens.

Ce court RFC spécifie comment utiliser le protocole d'avitaillement EPP au dessus d'une simple connexion TCP.

EPP, décrit dans le RFC 5730 est à sa base uniquement un format XML pour les requêtes d'avitaillement (création, mise à jour et destruction d'objets) et leurs réponses. Ces éléments XML peuvent être transmis de différence façon (au dessus de HTTP, de BEEP, par courrier électronique, etc), et notre RFC normalise la plus commune aujourd'hui, une simple connexion TCP. Il remplace le RFC 4934, avec uniquement des modifications de détail, portant notamment sur l'utilisation de TLS (section 9).

Le RFC est court car il n'y a pas grand'chose à dire, juste l'utilisation des primitives de TCP (ouverture et fermeture de connexion, section 2 du RFC), l'ordre des messages (section 3), le port utilisé (700, 3121 ayant été abandonné, section 7) et le fait que chaque élément EPP soit précédé d'un entier qui indique sa taille (section 4). Sans cet entier (qui joue le même rôle que l'en-tête Content-Length de HTTP), il faudrait, avec la plupart des implémentations, lire les données octet par octet (sans compter que la plupart des analyseurs XML ne savent pas analyser de manière incrémentale, il leur faut tout l'élément). En outre, sa présence permet de s'assurer que toutes les données ont été reçues (voir l'excellent article The ultimate SO_LINGER page, or: why is my tcp not reliable).

L'entier en question est fixé à 32 bits. Si on programme un client EPP en Python, l'utilisation brutale du module struct ne suffit pas forcément. En effet :

struct.pack("I", length)

force un entier (int) mais pas forcément un entier de 32 bits. Pour forcer la taille, il faut utiliser également, comme précisé dans la documentation, les opérateurs < et >, qui servent aussi à forcer la boutianité (merci à Kim-Minh Kaplan pour son aide sur ce point). Voici une démonstration (un "l" standard fait 4 octets alors que le type long de C peut faire 4 ou 8 octets) :

# Machine 32 bits :

Python 2.4.4 (#2, Apr  5 2007, 20:11:18) 
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
4
>>> print struct.calcsize(">l")
4

# Machine 64 bits :

Python 2.4.5 (#2, Mar 11 2008, 23:38:15) 
[GCC 4.2.3 (Debian 4.2.3-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> print struct.calcsize("l")
8
>>> print struct.calcsize(">l")
4

Si on a quand même un doute, on peut tester la taille obtenue mais ce code est probablement inutile (merci à David Douard pour son aide ici) :

# Get the size of C integers. We need 32 bits unsigned.
format_32 = ">I"
if struct.calcsize(format_32) < 4:
    format_32 = ">L"              
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
elif struct.calcsize(format_32) > 4:
    format_32 = ">H"                
    if struct.calcsize(format_32) != 4:
        raise Exception("Cannot find a 32 bits integer")
else:
    pass
...
def int_from_net(data):
    return struct.unpack(format_32, data)[0]

def int_to_net(value):
    return struct.pack(format_32, value)

L'algorithme complet d'envoi est :

epp_as_string = ElementTree.tostring(epp, encoding="UTF-8")
# +4 for the length field itself (section 4 mandates that)
# +2 for the CRLF at the end
length = int_to_net(len(epp_as_string) + 4 + 2)
self._socket.send(length)
self._socket.send(epp_as_string + "\r\n")

et la lecture :

data = self._socket.recv(4) # RFC 5734, section 4, the length 
                            # field is 4 bytes long
length = int_from_net(data) 
data = self._socket.recv(length-4)
epp = ElementTree.fromstring(data)
if epp.tag != "{%s}epp" % EPP.NS:
     raise EPP_Exception("Not an EPP instance: %s" % epp.tag)
xml = epp[0]

Le code Python complet (qui ne met en œuvre qu'une petite partie de EPP, le but était juste de tester ce RFC 5734), utilisant la bibliothèque ElementTree, est disponible en ligne. Le code ci-dessus comporte une grosse faiblesse (mais classique) : rien ne garantit que recv(n) retournera autant d'octets que réclamé. Il en renverra au plus n mais peut-être moins. Pour de la programmation sérieuse, il faut donc le réécrire avec une fonction du genre :

   def safe_recv(s, n):
       data = ''
       while (n > 0):
           tmp = s.recv(n)
           data += tmp
           n -= len(tmp)
       return data

(Merci à Kim-Minh Kaplan pour son aide sur ce point.)

Pour Perl, ce code ressemblerait (merci à Vincent Levigneron), pour envoyer un élément EPP stocké dans la variable $out, à :

print pack('N', length($out) + 4).$out;

et pour lire un élément EPP :

my $length = unpack "N", $buf;
...
$rc = read STDIN, $buf, $length;

Puisque le format N désigne un entier non signé gros boutien (cf. http://perldoc.perl.org/functions/pack.html).

À noter que cette lecture du champ longueur présente un risque de sécurité : si le serveur malloque aveuglément la taille indiquée dans ce champ, comme il fait quatre octets, le serveur naïf risque de consommer quatre giga-octets de mémoire.

La section 8, consacrée à la sécurité, et surtout la nouvelle section 9, consacrée à TLS, détaillent le processus d'authentification du client et du serveur. L'utilisation de TLS (RFC 5246) est obligatoire, ne serait-ce que pour protéger les mots de passe qui circulent en clair dans les éléments EPP. TLS permet également au client d'authentifier le serveur et au serveur d'authentifier le client, par la présentation de certificats X.509. Leur présentation et leur usage sont désormais obligatoires dans EPP. Notons que, comme toujours avec X.509, la difficulté est de déterminer ce qu'on vérifie. La section 9 détaille le cas où on vérifie un nom et celui où on vérifie une adresse IP. Il serait intéressant de savoir quels registres et quels bureaux d'enregistrement effectuent réellement ces validations...

La liste des changements par rapport au RFC 4934 se trouve dans l'annexe A. Le principal changement consiste en une meilleure spécification des règles de vérification du certificat X.509 lorsque TLS est utilisé (cf. la nouvelle section 9).

Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux contacts, c'est-à-dire aux personnes physiques ou morales responsables d'un objet de la base et qui peuvent être contactées à son sujet. (L'objet étant typiquement un nom de domaine ou bien un préfixe IP.)

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 5730, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type, la classe (EPP dit le mapping) pour les contacts. Il remplace le RFC 4933, avec très peu de changement, et marque l'arrivée de cette norme au statut de « norme complète », la dernière étape du chemin des normes de l'IETF.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

Un contact est donc composé d'un identificateur (type clIDType du RFC 5730). Cet identificateur (on l'appelait traditionnellement le handle) est, par exemple, SB68-GANDI (section 2.1).

Les contacts ont également un statut (section 2.2) qui est toujours mis par le client EPP, typiquement le bureau d'enregistrement. Ce mapping ne permet pas aux contacts d'être maîtres de leur propre information et de la changer directement (ce qui est cohérent avec l'approche d'EPP où un intermédiaire, le bureau d'enregistrement, a l'exclusivité des changements).

Les contacts ont aussi évidemment des moyens d'être contactés, via numéro de téléphone, adresse postale, etc. Par exemple, l'adresse de courrier du contact est spécifiée en section 2.6. La syntaxe formelle est celle du RFC 5322, par exemple joe.o'reilly+verisign@example.com. (Mais le schéma XML a une syntaxe plus bien laxiste, presque tout est accepté.)

Les contacts pouvant être des personnes physiques, pour protéger leur vie privée, la section 2.9 du RFC décrit aussi un format pour spécifier si ces informations doivent être publiées ou pas. Insuffisant pour tous les cas, ce format est en général remplacé, chez les registres européens, par un mapping spécifique (par exemple, EPP parameters for .pl ccTLD pour les polonais qui utilisent un élément <individual> pour indiquer si le contact est une personne physique, et a donc droit à la protection des lois européennes sur les données personnelles).

La section 3 normalise ensuite l'usage des commandes standards d'EPP (comme <create>) pour les objets de notre classe « contact ». À titre d'exemple, voici la réponse d'un serveur EPP à une requête <epp:info> (section 3.1.2) pour le contact SB68-GANDI :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:infData
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>SB68-GANDI</contact:id>
        <contact:roid>SH8013-REP</contact:roid>
        <contact:status s="clientDeleteProhibited"/>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Exemple SA</contact:org>
          <contact:addr>
            <contact:street>123 rue de l'Exemple</contact:street>
            <contact:city>Trifouillis-les-Oies</contact:city>
            <contact:cc>FR</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+33.7035555555</contact:voice>
        <contact:fax>+33.7035555556</contact:fax>
        <contact:email>jdoe@example.com</contact:email>
        <contact:crDate>1997-04-03T22:00:00.0Z</contact:crDate>
        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice/>
          <contact:email/>
        </contact:disclose>
      </contact:infData>
    </resData>
  </response>
</epp>

L'espace de noms XML pour les contacts est urn:ietf:params:xml:ns:contact-1.0.

Comme rappelé par la section 5, EPP utilise XML dont le modèle de caractères est Unicode depuis le début. Logiquement, on devrait donc pouvoir enregistrer des noms et prénoms comportant des accents (comme « Stéphane ») mais je ne suis pas sûr que cela marche avec tous les registres : c'est une chose de transporter la chaîne de caractères Unicode jusqu'au registre et une autre de la stocker dans la base et de la ressortir proprement.

La classe « Contact » permet de représenter certains éléments (comme l'adresse postale) sous deux formes, une en Unicode complet (en indiquant type="loc" et l'autre sous une version restreinte à l'ASCII (en indiquant type="int", notez que ces labels doivent être lus à l'envers, la forme restreinte en labelisée int pour « internationale » et la forme complète loc pour « locale » alors que le contraire aurait été plus logique.)

Ce RFC remplace son prédécesseur, le RFC 4933 mais ce ne sont que des modifications légères, détaillées dans l'annexe A.

La représentation des serveurs de noms (host, dans ce contexte) dans un registre de noms de domaine a toujours été une source de confusion et de désaccords. Le protocole EPP d'avitaillement (provisioning) d'un registre a tranché arbitrairement et décidé que la bonne méthode était d'avoir des objets « serveur de noms » (host) explicitement mis dans le registre. C'est ce que normalise notre RFC, successeur du RFC 4932, qui lui-même succédait au RFC 3732.

Un registre de noms de domaine stocke en effet au moins deux classes d'objets : les domaines, bien sûr, et les contacts, les entités (personnes physiques ou organisations) qui gèrent les domaines. Mais cela laisse ouverte la question des serveurs de noms. Pour pouvoir déléguer un domaine, le registre a besoin de ces serveurs, qui se retrouveront en partie droite des enregistrements de type NS, comme ici, dans le registre de .org :

example.org.      IN     NS    ns1.example.org.
                  IN     NS    galadriel.lothlorien.net. 

Comme souvent lors de l'élaboration d'un schéma de données, on peut se poser la question : objet ou attribut ? Les serveurs de noms doivent-ils être des objets « de première classe », gérés en tant que tels, accessibles via whois ou bien doivent-ils être de simples attributs des objets de la classe domaine ?

Les deux approches sont possibles. .com utilise la première. Un serveur de noms est un objet de première classe, vous pouvez le voir avec whois :

% whois ns.kimsufi.com 
...
   Server Name: NS.KIMSUFI.COM
   IP Address: 213.186.33.199
   Registrar: OVH

D'autres registres ont choisi de faire des serveurs de noms de simples attributs. Quelle approche fallait-il retenir pour le protocole d'avitaillement EPP, normalisé dans le RFC 5730 ? Celui-ci sépare le protocole proprement dit de la définition des classes d'objets (classes nommées, dans EPP, mappings. Il existe une classe (un mapping) pour les domaines (RFC 5731), une pour les contacts (RFC 5733) et notre RFC 5732 pour les serveurs de noms. Toutes sont optionnelles. Un registre n'est pas obligé de mettre en œuvre tous ces mappings et peut donc, s'il ne gère pas les objets hosts, ignorer le RFC 5732.

Si un registre choisit, par contre, de gérer des objets « serveur de noms » comme dans ce RFC, la section 1 décrit les relations entre ces objets et les domaines. Ainsi, tout serveur de noms est subordonné à un domaine (le parent) : ns1.example.org est subordonné à example.org et la relation doit être conservée par EPP (par exemple, l'objet host ne peut être créé que par le client EPP qui gère l'objet domaine parent). À noter que le parent peut être externe au registre (par exemple galadriel.lothlorien.net pour le registre de .org).

La section 2 de ce RFC énumère ensuite les attributs de l'objet « serveur de noms ». Le serveur a un nom (par exemple ns2.example.net), conforme aux règles syntaxiques du RFC 1123. Comme tous les objets manipulés avec EPP, il a un identificateur unique spécifique à EPP, le client identifier (voir le RFC 5730). Il a aussi un état (status), qui peut être une combinaison par exemple ok combiné avec linked (qui indique qu'il est utilisé dans au moins un domaine).

Il a enfin une adresse IP facultative. Le RFC recommande de ne la stocker que si elle est nécessaire pour publier la colle, les enregistrements qui permettent de trouver l'adresse IP d'un serveur de noms qui sert la zone dont il fait lui-même partie par exemple dans :

example.org.      IN     NS    ns1.example.org.
                  IN     NS    galadriel.lothlorien.net.

Ici, ns1.example.org est dans la zone qu'il sert (example.org), il faut donc transmettre au registre son adresse IP, pour qu'il puisse publier la colle :

ns1.example.org.          IN   AAAA    2001:db8:314::1:53

alors que cela n'est pas nécessaire pour galadriel.lothlorien.net. Les RFC 2874 et RFC 3596 contiennent des détails sur cette question. La section 3.2.1 de notre RFC, sur la commande <create> revient également sur ce point en insistant que cette commande n'impose pas de transmettre des adresses IP, bien au contraire.

Le cœur d'EPP est décrit dans le RFC 5730, qui inclus une description des commandes possibles (comme <create> ou <delete>). Toutes ne s'appliquent pas à tous les objets et chaque norme d'un mapping doit donc décrire quelles commandes ont un sens pour lui. C'est ici l'objet de la section 3. Par exemple (section 3.1.3), le passage d'un registrar à un autre (transfer) n'a pas de sens pour un objet « serveur de noms » et n'est donc pas défini. L'espace de noms XML du host mapping, de notre classe « serveur de noms » est urn:ietf:params:xml:ns:host-1.0 (voir section 6).

Les commandes <check> et <info> ont leur sens habituel (section 3.1), celui de récupérer des informations sur un objet, ici en donnant son nom. Voici l'exemple donné par le RFC pour la réponse à une commande <info> pour le serveur ns1.example.com :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <host:infData
       xmlns:host="urn:ietf:params:xml:ns:host-1.0">
        <host:name>ns1.example.com</host:name>
        <host:roid>NS1_EXAMPLE1-REP</host:roid>
        <host:status s="linked"/>
        <host:status s="clientUpdateProhibited"/>
        <host:addr ip="v4">192.0.2.2</host:addr>
        <host:addr ip="v4">192.0.2.29</host:addr>
        <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
        <host:clID>ClientY</host:clID>
        <host:crID>ClientX</host:crID>
        <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
        <host:upID>ClientX</host:upID>
        <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
        <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
      </host:infData>
    </resData>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54322-XYZ</svTRID>
    </trID>
  </response>
</epp>

Les informations spécifiques à notre classe sont dans l'espace de noms urn:ietf:params:xml:ns:host-1.0 dont le préfixe est ici host.

La syntaxe formelle complète de cette classe figure dans la section 4, sous la forme d'un schéma W3C.

L'annexe A rassemble les changements depuis le RFC 4932. Les changements, à part la mise à jour des RFC cités en référence, consistent surtout en une nouvelle licence pour le schéma XML et une précision sur le code de retour 2201 (permission refusée).

Dans son processus de normalisation, l'IETF a toujours accordé une grande importance au caractère réaliste et pratique de ses normes. Contrairement à d'autres SDO, qui n'hésitent pas à publier comme norme des pavés incompréhensible et inimplémentables, l'IETF veille à ce que l'avancement d'une norme sur le chemin des normes s'accompagne d'une vérification que cette norme peut être mise en œuvre et que les différents programmeurs ont bien compris la même chose. Cette vérification se traduit par des rapports analysant l'état actuel des implémentations d'une norme et le but de ce RFC est de guider les auteurs de ces rapports.

Le processus du chemin des normes est décrit dans le RFC 2026 (cf. section 1 de notre RFC 5657). Il comprenait trois étapes, proposition de norme (Proposed Standard), projet de norme (Draft Standard) et enfin norme tout court (Standard). Leur nombre a toutefois été réduit à deux par le RFC 6410. Lors du passage de la première à la deuxième étape, pour devenir projet de norme, un RFC doit (section 4.1.2 du RFC 2026) avoir été mis en œuvre au moins deux fois, par des équipes indépendantes, et ces deux mises en œuvre doivent interopérer (pouvoir travailler ensemble).

Le dossier présenté à l'IESG pour l'avancement d'une norme au statut de projet de norme doit comprendre un rapport (même section 4.1.2 du RFC 2026) décrivant les tests effectués entre ces mises en œuvre, leurs résultats, etc. Historiquement, ces rapports, dont la forme n'était spécifiée nulle part, ont été de qualité très variable ; certains étaient très courts, se contentant de dire « On a testé et ça marche ». D'autres détaillaient à l'extrême un aspect particulier des tests mais oubliaient les résultats. Le but de ce RFC 5657 est de limiter cette variation. Il met donc à jour légèrement le RFC 2026. Lui-même a été amendé par le RFC 6410, qui a rendu ce rapport facultatif.

L'espoir est que ce RFC contribuera également à clarifier les tâches à accomplir pour faire avancer une norme : aujourd'hui, peu de gens s'y retrouvent et bien des normes stables et très utilisées sont restées au début du chemin des normes car personne n'avait eu le courage de lancer le processus d'avancement.

La section 2 définit donc ce que doit contenir le rapport d'interopérabilité. Sur certains points, il est moins strict que le RFC 2026. Par exemple, il n'est plus obligatoire de nommer les implémentations testées (cela défrisait certains vendeurs). Si seulement une partie des implémentations existantes est testée, le rapport doit dire comment la sélection s'est faite.

Le RFC 2026 parlait d'implémentations « indépendantes » sans définir ce que voulait dire ce terme. Notre RFC 5657 précise que cela veut dire qu'elles ont été écrites par des personnes différentes, dans des organisations différentes et qu'elles n'aient pas de code en commun (il est fréquent que plusieurs logiciels dérivent de la même souche et n'aient donc guère de mérite à interopérer correctement).

La section 3 décrit le format du rapport d'interopérabilité. C'est le même que celui des RFC. La section indique aussi les parties obligatoires et leur contenu. Un résumé doit préciser les points importants. La méthodologie de test doit être décrite. Les éventuelles exceptions (points de la norme sur lesquels l'interopérabilité échoue) doivent être précisement listées.

Un point délicat des rapports d'interopérabilité est la question des fonctions qu'on teste. Faut-il tout tester dans le moindre détail ou bien a t-on le droit d'omettre des fonctions qui sont dans la norme ? La section 4 analyse la question. En gros, si on teste seulement des grandes fonctions, on ne pousse pas les implémentations dans leurs limites mais si on teste tous les détails et leurs combinaisons, la matrice des tests explose, notamment pour les protocoles ayant beaucoup d'options. Il faut donc trouver un niveau intermédiaire raisonnable. Le RFC cite en exemple le rapport sur RTP qui liste les fonctions testées sous forme de services importants, et non pas sous la forme, trop détaillée, de chaque bit possible de l'en-tête.

Le pragmatisme reste nécessaire. La section 5 explique comment gérer des cas particuliers. Par exemple, si le protocole est déjà largement déployé, on peut (section 5.1) privilégier l'analyse de son fonctionnement réel plutôt que des tests en laboratoire. Une étude ou un questionnaire sont donc sans doute la meilleure méthode. Par contre, si le protocole n'a pas encore connu de déploiement significatif (section 5.2), les tests sont la meilleure approche. Le RFC insiste quand même sur le fait qu'il faut essayer d'anticiper les problèmes opérationnels comme la congestion ou la gestion.

Un autre cas particulier est celui des RFC qui normalisent des formats et pas des protocoles, traité dans la section 5.3. Par exemple, le RFC 5234 normalise les grammaires ABNF et le RFC 4287 le format de syndication Atom. L'interopérabilité, dans ce cas, se juge notamment à la capacité des différentes implémentations à considérer comme corrects les mêmes fichiers (et même chose pour les incorrects). ABNF a ainsi fait l'objet d'un rapport de mise en œuvre.

Parmi les autres cas couverts par notre RFC, celui des protocoles pour lesquels il existe une suite de tests comme WebDAV, avec Litmus. Cette suite ne permet pas forcément de tester l'interopérabilité (section 5.5) car elle ne teste pas des vraies mises en œuvre les unes contre les autres. Avec Litmus, par exemple, le client WebDAV est un client artificiel, qui n'est pas forcément représentatif des vrais clients.

Tous les rapports de mise en œuvre existants sont disponibles en ligne. La section 6 de notre RFC 5657 cite quelques exemples particulièrement instructifs comme le rapport sur PPP-LCP pour sa concision ou celui sur OSPF (publié également dans le RFC 2329), jugé trop long mais quand même de qualité. Celui sur le « pipelining » SMTP est jugé très court, à la limite de la taille minimale.

Comme son titre l'indique, ce livre est pour l'amoureux des langues, celui qui est prêt à se pencher sur la néologie en islandais (article « Islandais ») ou sur les risques pesant sur le qawasqar (article « Danger (langues en) »). Si, au contraire, vous voulez annuler Babel et pensez qu'il vaudrait mieux que tout le monde ne parle qu'une seule langue, il vaudrait mieux trouver une autre lecture.

Claude Hagège est connu pour ses travaux de linguiste que, dans ce livre, il essaie de faire partager à tous. La forme est celle d'un dictionnaire mais, en fait, chaque article est plutôt encyclopédique, détaillant un des points qui touchent particulièrement l'auteur.

Ainsi, l'article « Témoignages » explique qu'en français, les conditions dans lesquelles on a appris une information (« Jean n'est pas allé travailler aujourd'hui ») doivent être exprimées en plus (« Irène m'a dit que Jean n'était pas allé travailler aujurd'hui ») alors qu'en turc, il y a deux verbes différents selon qu'on sait l'information de première main, ou bien indirectement. (Et le tuyuca a cinq niveaux différents, selon qu'on est témoin immédiat, ou plus ou moins éloigné de la source originale.) Ainsi, on ne peut pas être ambigu en turc lorsqu'on rapporte une information : la grammaire oblige à dire si on était vraiment là pour la constater.

« Composés et dérivés » explique, lui, comment former des nouvaux mots, selon les langues, certaines, comme le chinois, privilégiant la composition (faire un mot avec deux), d'autres, comme les langues sémites, la dérivation (ajouter des affixes à un radical).

Autre article passionnant, « Hybridation » explique les mécanismes par lesquelles les langues se mélangent. L'emprunt massif de vocabulaire est l'exemple le plus connu mais il y a aussi des mélanges bien plus intimes comme dans le cas du maltais où l'hybridation avec l'italien et l'anglais rend parfois difficile de détecter le fond arabe. (Il y a aussi un article « Emprunt », sur le même sujet.)

L'article « Traduire » est évidemment un des plus longs car cette activité a une longue histoire d'auto-introspection. Comment traduire le chinois « une moustache en huit » sans savoir que l'expression fait allusion à la forme du caractère représentant ce chiffre en chinois ? Et si un français parlait de « moustache à la gauloise », le traducteur en chinois aurait sans doute besoin de se renseigner sur l'histoire de France...

Mon principal regret est que beaucoup d'articles passionnants (comme « Difficiles (langues) ») soient assez gâchés par l'anglophobie militante de l'auteur qui passe beaucoup trop de temps à cracher son venin contre le rôle excessif de la langue d'Obama et de Ballmer, en dérapant souvent sérieusement.

Le livre est très technique, et nécessite, si on n'a pas de connaissances préalables en linguistique, une attention soutenue. Mais l'auteur a fait de gros efforts pour tout expliquer et rendre ces concepts accessibles et il y est bien arrivé.

Pour trouver l'adresse MAC d'un voisin, une machine IPv6 utilise le protocole NDP (Neighbor Discovery Protocol), normalisé dans le RFC 4861. Ce protocole ressemble beaucoup au traditionnel ARP (RFC 826) d'IPv4 et il partage notamment sa principale vulnérabilité : une machine peut tout à fait se faire passer pour une autre et recevoir ainsi les paquets qui ne lui sont pas destinés. En outre, NDP dispose d'autres fonctions qu'ARP, comme la découverte des routeurs, fonctions qui sont tout aussi critiques et tout aussi vulnérables. Au début d'IPv6, l'enthousiasme pour IPsec était sans limite et il était donc censé résoudre ce problème, comme beaucoup d'autres. En réalité, IPsec a été peu implémenté et encore moins déployé et il a donc fallu trouver une autre solution, SEND (SEcure Neighbor Discovery) qui fait l'objet de ce RFC.

Les détails sur les vulnérabilités de NDP figurent dans le RFC 3756. Ils sont aussi résumés dans la section 11.1 du RFC 4861 et rappelés dans la section 1 de notre RFC 3971. Exemple ironique, à chaque réunion physique de l'IETF, certains portables sont configurés pour créer des réseaux ad hoc et envoient des annonces RA (Router Advertisement) concurrents de ceux du routeur légitime. La seule solution est de donner au micro les adresses MAC des routeurs « pirates » pour les filtrer.

Cette section 1 explique aussi, en plus des problèmes généraux d'IPsec, pourquoi il ne peut pas être utilisé pour sécuriser un protocole de découverte des voisins et du réseau, en raison des limites du bootstrap (on a besoin du réseau pour IKE mais on a besoin d'IPsec pour initialiser le réseau..).

Sur un réseau local qui n'offre pas de sécurité physique (Ethernet sans 802.1x ou bien WiFi), NDP est très vulnérable et c'est la raison d'être de SEND.

Résumé brièvement, SEND consiste à utiliser des adresses CGA (adresses auto-signées) sur les machines non-routeuses et des signatures cryptographiques avec certificat pour authentifier les annonces des routeurs.

La section 3 résume les fonctions de NDP :

• Découverte automatique des routeurs (une autre solution étant d'utiliser DHCP),
• Auto-configuration, sans état, des adresses IP des machines (RFC 4862),
• Détection des conflits d'adresses (lorsque deux machines ont reçues la même adresse IP),
• Résolution d'adresses IP en adresses MAC (section 7.2 du RFC 4861).

Toutes ces fonctions sont mises en œuvre par des messages portés sur ICMP (RFC 4443) qui contiennent des données et des options encodées en TLV. (Voir la liste dans le registre IANA.)

Comment fonctionne SEND ? C'est l'objet du reste du RFC, à commencer par la section 4 qui décrit le fonctionnement général. SEND comprend :

• Un système de certificats, permettant de valider les annonces d'un routeur, en suivant un chemin de certificats signés (l'annonce du routeur n'a pas besoin d'inclure tous les certificats du chemin, des nouveaux messages NDP permettent au récepteur de demander les certificats qui lui manquent).
• Des adresses cryptographiques, les CGA du RFC 3972, permettent de s'assurer que la machine qui répond aux requêtes Neighbor Discovery est bien la « propriétaire » de l'adresse. (Donc, contrairement aux annonces des routeurs, SEND n'utilise pas de certificat pour authentifier les simples machines. Cette possibilité est uniquement mentionnée pour un usage possible dans le futur.)
• Une nouvelle option NDP, RSA signature, permet de vérifier l'intégrité du message. La clé publique utilisée pour la signature est récupérée, soit par les certificats, si l'émetteur est un routeur, soit, pour le cas de CGA par une autre option qui permet d'inclure cette clé dans les messages. À noter que RSA est le seul algorithme normalisé, pour garantir l'interopérabilité (puisque SEND tourne dans des environnements où il ne serait pas réaliste de se lancer dans des négociations entre émetteur et récepteur). S'il fallait changer d'algorithme, par exemple suite aux progrès de la cryptanalyse, il faudrait alors développer une nouvelle version de SEND (ce qui est précisement en cours).
• Et enfin un mécanisme de nonce contre les attaques par rejeu.

Le détail de ces nouvelles options et de leur format figure en section 5. Par exemple, l'option CGA (section 5.1) permet au répondeur qui utilise des adresses IP CGA d'inclure la clé publique utilisée dans la réponse. La section 5.1.1 détaille comment l'émetteur doit remplir cette option et la 5.1.2 comment le récepteur peut l'utiliser pour vérifier que le détenteur de la clé est bien celui de l'adresse

La section 5.2, elle, normalise l'option CGA signature, où le message SEND contient une signature au format PKCS#1. Là encore, la section décrit en détail ce que doit faire l'émetteur pour remplir cette option et le récepteur pour la vérifier. Toute aussi indispensable, la section 5.2.3 traite de la configuration de l'option par l'administrateur système et note qu'une mise en œuvre de SEND doit pouvoir être configurée pour vérifier cette signature par différents moyens, comme une trust anchor, une clé publique de départ, à laquelle on fait confiance et qui peut à son tour signer d'autres clés.

Un enjeu de sécurité important de SEND est la protection contre le rejeu. Pour cela, les options Timestamp et Nonce, décrites en section 5.3 sont indispensables. Timestamp indique le temps de l'émetteur et permet, si les horloges de l'émetteur et du récepteur sont raisonnablement synchronisées (la section 5.3.4.2 précise les tolérances admises), d'empêcher qu'un méchant n'enregistre une réponse tout à fait légitime et ne la réutilise plus tard, alors qu'elle n'est plus valable. Nonce, elle, stocke un nombre aléatoire (de taille variable, au moins 48 bits) envoyé par le solliciteur et retourné par le répondant. Ainsi, on peut être sûr que le paquet SEND est bien une réponse à une question qu'on avait posé. Les règles de génération imposent l'usage de ces deux options (et les récepteurs doivent considérer les messages SEND sans une de ces options comme étant non-SEND donc non sûrs).

La section 6 entreprend de résoudre le difficile problème de la validation des certificats des routeurs. La méthode normale, si on n'a pas déjà l'information dans son magasin de certificats, est d'aller la chercher sur l'Internet. Mais, ici, comme il s'agit de découvrir le routeur, cette solution n'est pas possible puisque, justement, on n'a pas encore de routeur pour aller sur l'Internet. Comment SEND traite t-il ce problème ?

Le modèle général est celui de X.509, comme l'utilisent, par exemple, les navigateurs Web. Chaque machine doit avoir un magasin de certificats (qui ne sont pas forcément les mêmes que ceux utilisés, après la configuration d'IP, pour des activités comme le Web) et se sert de ce ou ces certificats comme trust anchors, comme points de départ de la validation (sections 6.1 et 6.5). La machine terminale n'a pas de certificats à elle (à part avec CGA, elle ne s'authentifie pas, seul le routeur le fait). Le routeur, lui, reçoit son certificat et sa clé privée. Le certificat l'autorise non seulement à agir comme routeur mais également à annoncer certains préfixes IP et pas les autres.

Qui attribue ces certificats ? La section 6.2 mentionne une autorité de certification mondiale unique pour les routeurs... qui n'existe pas (et n'est sans doute pas près d'exister). Elle pourrait émaner de l'IANA ou bien d'un consortium formé par les RIR.

Une autre solution mentionnée par le RFC (nommée dans le RFC le « modèle décentralisé », un terme incorrect), et la seule possible aujourd'hui, est celle d'un nuage de diverses autorités de certification, chacune reconnue par certains sites mais pas par d'autres. Cela rend très difficile la mobilité (un portable en visite sur un autre site n'a aucun moyen de valider les annonces SEND du routeur local).

Le format des certificats, lui, est expliqué en section 6.3. C'est du X.509 v3, avec le profil des RFC 3779 et RFC 5280, RFC qui permet de décrire dans le certificat les ressources Internet qu'on peut annoncer (les adresses IP, par exemple, section 4.2.1.6 du RFC 5280).

Enfin, pour permettre la réception de certificats non contenus dans le magasin, mais nécessaires pour boucler la chaîne de validation, la section 6.4 prévoit des types de messages ICMP Certificat Path Solicitation et Certification Path Advertisement. Avec elles, on peut construire des messages pour demander ou obtenir des certificats.

L'usage des adresses IP par SEND fait l'objet de la section 7. Une machine SEND est censée n'utiliser que CGA (section 7.1) et donc pas les adresses IP temporaires du RFC 4941. Sécurité ou vie privée, il faut choisir ! Pour travailler avec d'autres adresses, rien n'est encore trop précisé, à part l'API du RFC 5014. Autre exemple (section 7.4), SEND ne fournit aucun moyen d'authentifier les messages NDP pour les adresses IPv6 statiques, ou bien les adresses autoconfigurées à partir de l'adresse MAC.

SEND est aujourd'hui très peu déployé. Comme tous les protocoles récents (il date quand même de plus de quatre ans), il fait face à des problèmes de transition avec l'ancienne méthode (qui est de ne pas sécuriser du tout). La section 8 expose ces problèmes. Comme, en pratique, une machine SEND va certainement rencontrer des réseaux non-SEND, le RFC demande que les messages non sécurisés soient également acceptés. La machine SEND qui reçoit deux sortes de messages doit évidemment donner la priorité à ceux qui sont sécurisés. Le RFC recommande également une option de configuration « paranoïaque » où seuls les messages NDP sécurisés soient acceptés (à condition qu'elle ne soit pas active par défaut). Inversement, le RFC admet une option de ne pas envoyer de messages SEND (au cas où ils perturbent le réseau mais, si tout le monde suit la norme IPv6 correctement, cela ne devrait pas arriver, les options SEND des messages NDP devraient simplement être ignorées) mais cette option doit être activée explicitement.

La cohabitation de réseaux SEND (sécurisés) et non-SEND (non sécurisés) peut avoir pour conséquence la réception d'un message non sécurisé qui essaie de remplacer l'information issue d'un message sécurisé. Notre RFC 3971 impose que les caches (comme celui des voisins qui, sur Linux, peut être affiché avec ip -f inet6 neighbour show) doivent garder trace du caractère sûr ou non sûr de l'information et ne doivent pas remplacer une information sûre par une non sûre.

SEND est entièrement voué à la sécurité donc l'obligatoire section Sécurité pourrait être inutile mais, ici, la section 9.1 couvre un problème utile : les menaces que SEND ne résout pas. Ainsi, SEND ne protège pas la confidentialité des échanges NDP. SEND ne rend pas complètement sûr un réseau physique non sûr (par exemple, une machine malveillante peut toujours envoyer des paquets avec une adresse MAC source mensongère).

À l'heure actuelle, un groupe de travail de l'IETF, csi, travaille à améliorer SEND. Par exemple, SEND est limité à SHA1 et RSA alors que le groupe de travail explore la meilleure façon d'utiliser de nouveaux algorithmes cryptographiques.

Quells mises en œuvres de SEND sont disponibles ? DoCoMo en avait une mais qui n'est plus maintenue. On trouve quelques bouts de code par ci par là, quelques projets pas finis, mais apparemment pas d'implémentation libre complète qui marche sur des systèmes comme Linux ou FreeBSD. Donc, je ne crois pas que je pourrai activer SEND sur ma Freebox. En revanche, Cisco a une mise en œuvre de SEND sur ses routeurs (mais pas, semble t-il, Juniper).

Pourquoi SEND n'est-il pratiquement pas déployé ? Il y a sans doute plusieurs raisons : le déploiement est difficile puisqu'il faut mettre la clé publique des routeurs dans chaque machine et la sécurité du protocole NDP n'est pas vraiment un problème aujourd'hui (à part sur le réseau de Defcon, les attaques réelles sont rares).

Beaucoup de FAI se demandent comment limiter la charge qui provient de l'intense activité pair-à-pair de leurs clients. Les plus bas de front tentent l'interdiction (comme dans les conditions générales d'utilisation de SFR pour certaines de ses offres Internet mobile, où le pair-à-pair est explicitement interdit), d'autres cherchent des solutions techniques. L'une de ces solutions, P4P, qui permet au FAI d'informer les logiciels pair-à-pair de la topologie de son réseau, dans l'espoir qu'ils choisiront des pairs plus proches, est activement promue par certaines entreprises comme Pando. Comcast, un gros FAI, a testé P4P pour nous et en fait le compte-rendu dans ce RFC.

Ce gros FAI états-unien connecte essentiellement des particuliers, par le câble. Comcast est un des participants au groupe de travail qui élabore P4P. Le principe du système P4P (Proactive network Provider Participation for P2P) est de déployer des iTrackers qui sont des serveurs informant les clients pair-à-pair de la topologie du réseau, quels sont les liens recommandés, quelles adresses IP sont externes ou internes au dit réseau, etc (section 1 du RFC). Le logiciel peut alors choisir le pair le plus proche, économisant ainsi les ressources.

P4P a été discuté dans des forums comme le IETF workshop on P2P Infrastructure (raconté dans le RFC 5594) ou à la BoF Alto de l'IETF. Le test en vrai grandeur dont notre RFC 5632 rend compte a eu lieu en juillet 2008.

La section 2 du RFC résume le principe du test. Cinq essaims de machines, avec des iTrackers programmés différemment à chaque fois, participaient. Les statistiques étaient enregistrées par chaque client puis rassemblées. Témoignage de la puissance du pair-à-pair, le seeder (la machine qui avait le contenu original) n'a envoyé que dix copies alors qu'il y a eu un million de téléchargements.

Quels étaient les différents types de iTrackers utilisé ? Si, dans le premier essaim, les pairs étaient choisis au hasard, les autres utilisaient les politiques suivantes :

• Grain fin (section 3.1). De loin le plus complexe à configurer, ce iTracker avait toute l'information sur le réseau de Comcast, incluant tous les liens avec l'extérieur. Non seulement l'élaboration et la mise à jour de sa configuration étaient très complexes (le fichier faisait plus de cent mille lignes) mais cet iTracker est très indiscret, permettant aux clients de récupérer une information que le FAI n'a pas forcément envie de livrer.
• Gros grain (section 3.2). Présentant une vue moins précise du réseau (notamment de ses connexions externes), cet iTracker ne faisait plus que mille lignes et surtout (du point de vue de Comcast) était plus discret.
• Pondéré génériquement (section 3.3). Identique au iTracker à gros grain, sauf que les poids attribués aux différents liens étaient définis par une autre équipe.

Qu'est-ce que ça a donné ? La section 4 résume les résultats (mais il faut aussi lire la section 5, qui détaille les pièges d'interprétation possibles) : chaque essaim de machines a réalisé environ 25 000 téléchargements par jour. Le plus gros essaim a atteint une taille de 11 700 machines. Les iTrackers à grain fin ou à gros grain ont vu leur débit de téléchargement (section 4.2) augmenter de 13 % (en moyenne) mais de 57 à 82 % pour les machines de Comcast, qui avaient le plus d'informations. Et la politique à gros grain s'est montrée plus efficace que celle à grain fin, contrairement à ce qu'on aurait pu attendre.

La section 4.2 donnait les résultats individuels, l'amélioration pour une machine qui télécharge. Mais pour le FAI, quel était le résultat ? La section 4.3 les résume : le trafic sortant de Comcast a diminué de 34 %, l'entrant vers Comcast de 80 %. À noter également qu'il y a d'avantage d'annulations (l'utilisateur s'impatiente et arrête le téléchargement) avec le premier essaim, celui qui n'utilisait pas P4P. Il est possible que les débits plus faibles entrainent davantage de découragement et donc d'annulation. En tout cas, le trafic à l'intérieur de Comcast augmente avec P4P : quand ça marche, les utilisateurs s'en servent plus.

La section 6 formule donc une conclusion relativement optimiste et recommande que l'IETF considère sérieusement P4P dans le cadre du groupe de travail Alto.

Successeur du souvent cité RFC 2581, ce RFC 5681 présente les algorithmes que doivent utiliser les mises en œuvres de TCP pour limiter les risques de congestion sur l'Internet. Comme TCP (RFC 793) est, de très loin, le principal protocole de transport de l'Internet, ces quatre algorithmes sont donc la principale ligne de défense contre la congestion.

Leurs noms en anglais sont tellement répandus qu'il n'est pas facile de concevoir une traduction. Essayons :

• Démarrage en douceur (slow start),
• Évitement de la congestion (congestion avoidance),
• Retransmission rapide (fast retransmit),
• Récupération rapide (fast recovery).

Mis au point à l'origine par Van Jacobson, ces algorithmes ont d'abord été normalisés dans le RFC 1122 (avant les RFC 2001, une lecture très recommandée, et RFC 2581). Des RFC comme le RFC 3390 ont également contribué. Richard Stevens décrit ces algorithmes dans son livre TCP/IP Illustrated (explications dans le premier volume et code source dans le deuxième). Ce livre est de très loin le meilleur pour quiconque veut apprendre le délicat fonctionnement de TCP.

Si TCP envoyait des données à la vitesse maximale que permet la carte réseau et la machine, l'Internet s'écroulerait rapidement. Le but de ces algorithmes est donc de freiner TCP et la section 3 note qu'une mise en œuvre de TCP est autorisée à être plus prudente que ces algorithmes (à envoyer moins de données) mais pas à être plus violente.

La section 3.1 décrit le Démarrage en douceur. Le principe est, au démarrage d'une connexion TCP, de ne pas envoyer trop de données sans avoir vu qu'elles pouvaient arriver au même rythme. L'envoyeur garde une variable, cwnd, la fenêtre de congestion, qui indique combien de données il peut envoyer sans recevoir d'accusé de réception (ACK). TCP commence avec une fenêtre assez petite (la section 3.1 donne la méthode de calcul, un exposé complet figure dans le RFC 3390) et l'ouvre au fur et à mesure de l'arrivée des accusés de réception (là encore, les valeurs précises figurent dans le RFC).

Si vous lisez le code source du noyau Linux 2.6, ces variables supplémentaires sont déclarées dans include/linux/tcp.h. Tous les noms de fichiers donnés plus loin concernent ce noyau.

Quant la fenêtre de congestion a été augmentée au delà d'un certain seuil, noté ssthresh, le second algorithme, l'Évitement de congestion prend le relais. Cet algorithme augmente différemment, de manière plus rapide, la fenêtre de congestion (quand tout va bien) et réagit à la congestion (détectée par l'expiration d'un délai de garde) en réduisant ssthresh, voire la fenêtre de congestion (ce qui peut la faire tomber en dessous de ssthresh, réactivant le démarrage en douceur). Ce second algorithme est décrit en détail dans la même section 3.1. Pour la mise en œuvre sur Linux, voir le très joli net/ipv4/tcp_cong.c.

Attention, comme l'ont montré plusieurs alertes de sécurité (la dernière datant de quelques jours après la publication du RFC), le fait de réagir aux messages de l'hôte distant présente toujours un risque, si celui-ci essaie de vous tromper. Diverses contre-mesures sont citées (cf. RFC 3465).

Les deux autres algorithmes, la Retransmission rapide et la Récupération rapide, sont décrits dans la section 3.2. Tous les deux reposent sur les accusés de réception dupliqués. Ceux-ci (définis formellement en section 2) sont des accusés de réception pour des données qui ont déjà fait l'objet d'un tel accusé. Notre RFC 5681 recommande que le TCP récepteur envoie un accusé de réception immédiatement lorsqu'il reçoit des données qui ne sont pas dans l'ordre des numéros de séquence (fonction __tcp_ack_snd_check dans net/ipv4/tcp_input.c). Cet accusé, considéré comme « dupliqué », permet à l'envoyeur de voir tout de suite que des données ont probablement été perdues (rappelez-vous que les accusés de réception, pour TCP, indiquent simplement le rang du dernier octet reçu avec succès, pas une plage ; les données hors-séquence ne suscitent normalement pas d'accusé de réception immédiat, TCP attend plutôt que les données manquantes arrivent).

La Retransmission rapide est utilisée lorsque TCP reçoit des accusés de réception dupliqués. Dans ce cas, TCP doit retransmettre tout de suite les données non encore acceptées par son pair, sans attendre que le délai de garde expire. La Récupération rapide consiste à ne pas utiliser le Démarrage en douceur lorsqu'on détecte des accusés de réception dupliqués. Elle a fait depuis l'objet de perfectionnements, décrits plus longuement dans le RFC 6582.

Après ces quatre algorithmes à utiliser, le RFC, dans sa section 4.1, couvre aussi le problème du redémarrage des sessions qui ont été longtemps inactives. Dans ce cas, TCP ne peut plus compter sur l'arrivée des accusés de réception pour calibrer le réseau (tous les ACK sont arrivés depuis longtemps) et son calcul de la fenêtre de congestion peut être désormais dépassé. Il risque donc d'envoyer un brusque flux de données. Le RFC recommande donc une variante du Démarrage en douceur, lorsque la session a été inactive pendant longtemps.

La section 4.2 revient sur le problème de l'envoi des accusés de réception. Le RFC 1122 (dans sa section 4.2.3.2) spécifie un algorithme pour cet envoi, dont le principe de base est d'attendre un peu avant d'envoyer l'ACK (dans l'espoir que d'autres données arriveront, permettant de se contenter d'un seul ACK), mais sans attendre trop pour éviter que l'émetteur ne s'impatiente et ne réemette. Notre RFC 5681 précise simplement les règles (ambigües) du RFC 1122.

En prime de la Retransmission rapide et du Redémarrage rapide, certains algorithmes ont été proposés et parfois déployés, pour récupérer des pertes de données. La section 4.3 les énumère, sans forcément prendre position sur leur opportunité. Certains, comme celui du RFC 3517, dépendent de l'option SACK (Selective Acknowledgment) du RFC 2018, d'autres, comme celui du RFC 3782 n'en dépendent pas.

Il est important de noter que le bon fonctionnement de l'Internet dépend de la mise en œuvre correcte de tous ces principes, par chaque implémentation de TCP. Deux machines « inciviles » qui désireraient envoyer le plus de données possibles, et tant pis pour la congestion, peuvent techniquement le faire (section 5, consacrée à la sécurité). C'est un des aspects les plus étonnants de l'Internet que peu de vendeurs aient eu l'idée de promouvoir un TCP « optimisé », c'est-à-dire égoïste. On trouve toutefois des cas limites comme Fast TCP.

Enfin, les changements par rapport au RFC 2581 sont présentés dans la section 7. Les principaux sont :

• Une définition rigoureuse de la notion d'accusé de réception dupliqué (en section 2),
• La recommandation d'utiliser le RFC 3465 pendant le Démarrage en douceur,
• La recommandation d'utiliser le RFC 3042 pendant les Retransmission rapide et Récupération rapide.

(Je trouve personnellement que le RFC 2001 était le plus clair de tous et que la précision des mises à jour suivantes a plutôt brouillé les explications.)

Ce RFC, compagnon du RFC 5646, décrit le nouvel état du registre des langues de l'IANA. Comme son prédécesseur, le RFC 4645 avait servi à initialiser le registre des langues, notre RFC 5645 servira à la grande mise à jour qu'est l'intégration des normes ISO-639-3 et ISO 639-5. Le nombre de langues enregistrées passe de 500 à plus de 7 000.

Le registre est écrit dans le format dit record-jar, décrit dans le livre The Art of Unix programming.

Il sert juste à lister l'état du nouveau registre IANA avec des affectations comme ici pour le Nandi ou l'écriture du Bamum :

%% Description d'une langue, ici le Nandi (niq)
Type: language
Subtag: niq
Description: Nandi
Added: 2009-07-29
Macrolanguage: kln   
%%
%% Description d'une écriture, ici le Bamum
Type: script
Subtag: Bamu
Description: Bamum
Added: 2009-07-30
%%

Le registre va ensuite vivre sa vie et accepter de nouveaux enregistrements, suivant les procédures du RFC 5646. Une des façons de suivre ces futures évolution est de s'abonner au flux de syndication http://www.langtag.net/registries/lsr.atom.

Comment a été construit le nouveau registre ? La section 2 répond à cette question. Le point de départ était le registre existant, celui qui avait été créé par le RFC 4646. Les fichiers d'ISO 639-3 (disponibles chez SIL car l'ISO ne distribue quasiment jamais ses normes) et ISO 639-5 ont ensuite été intégrés, mais pas aveuglément :

• Les langues qui n'avaient pas déjà de code dans le registre (comme l'ankave - code aak - ou le ghotuo - code aaa) ont été ajoutées. A contrario, celles qui avaient déjà un code ont été ignorées.
• Les langues qui avaient une macrolangue (une nouveauté d'ISO 639-3, la macrolangue est une catégorie regroupant des langues qui sont parfois considérées comme distinctes et parfois comme une seule langue) ont été traitées comme les autres à l'exception de six langues pour lesquelles le groupe de travail LTRU de l'IETF a estimé qu'elles présentaient des caractéristiques particulières, notamment le fait que la macrolangue était souvent utilisée. Ces six exceptions sont l'arabe (ar), le konkani (kok), le malais (ms), le swahili (sw), l'ouzbèque (uz) et le chinois (zh). Pour les six exceptions, un extended language subtag a été créé dans le registre, pour indiquer la macrolangue et cela permettra d'écrire des étiquettes comme zh-yue (le cantonais, dont l'étiquette canonique est juste yue) pour le cas où l'ajout de la macrolangue semble important. Les autres langues ayant une macrolangue voient juste cette macrolangue ajoutée comme un champ de l'enregistrement.
• Les descriptions présentes dans le registre ont parfois été complétées ou modifiées pour avoir une présentation cohérente. Cela aboutit parfois à élargir la portée d'un code. Ainsi, la collection afa « Autres langues afro-asiatiques » est devenue « Langues afro-asiatiques » ce qui est bien plus large.
• Le RFC 5646 a inclus dans les codes de pays les éléments de ISO 3166 qui étaient marqués comme « exceptionellement réservés ». Cela a permis l'arrivée de EU, on peut donc désormais utiliser l'étiquette en-EU pour l'anglais parlé à Bruxelles. D'autres codes étaient déjà présents pour d'autres raisons comme l'amusant FX (France Métropolitaine).

Successeur du RFC 4646 (qui lui-même succédait au RFC 3066), notre RFC décrit les noms des langues (langues humaines, pas langages informatiques). Toute application qui a besoin d'indiquer une langue doit s'en servir.

Le protocole HTTP par exemple permet à un navigateur Web d'indiquer au serveur quelle langue il préfère (en-tête Accept-Language: dans le RFC 7231, section 5.3.5), au cas où le serveur aie plusieurs versions d'une page et soit correctement configuré (ce que Apache permet). Cela marche très bien avec des sites comme http://www.debian.org/.

Des normes non-IETF (notamment XML) se réfèrent à ce RFC.

Les noms des langues ont deux ou trois lettres et sont tirés de la norme ISO 639. Par exemple :

• "fr" pour le français (à ne pas confondre avec le TLD ".fr", qui désigne la France),
• "ar" pour l'arabe,
• "br" pour le breton,
• "en" pour l'anglais,
• etc.

La norme complète est plus complexe : par exemple, l'anglais parlé aux États-Unis n'est pas tout à fait le même que celui parlé en Grande-Bretagne. Aussi, notre RFC permet de décrire la langue de manière plus fine par exemple fr-CH désigne le français tel qu'il est parlé en Suisse.

Il y a d'autres caractéristiques que la langue ou le pays. Ainsi, sr-Latn-CS représente le serbe (sr) écrit dans l'alphabet latin (Latn) tel qu'il s'utilise en Serbie (CS).

La question étant sensible (le croate est-il une langue différente du serbe, par exemple ?) l'IETF a évité les problèmes en s'appuyant sur des normes existantes (ISO 639 pour les langues comme le RFC 1591 s'appuie sur ISO 3166 pour éviter l'épineuse question de « qu'est-ce qui est un pays »). Néanmoins, le RFC confie un rôle de registre à l'IANA pour garantir une stabilité des noms (l'ISO ne la garantit pas, ne s'intéressant qu'au présent, alors que l'Internet a besoin de stabilité sur le long terme, cf. la section 3.4 pour la politique de stabilité du registre des langues).

ISO 639-1 et 2 reflétaient plutôt les besoins des bibliothécaires, soucieux de simplifier la classification en évitant la multiplication des langues. ISO 639-3 adopte plutôt le point de vue des linguistes, qui tendent à voir bien plus de langues. Ce débat entre mergers (les bibliothécaires) et splitters (les linguistes) ne cessera pas de sitôt. L'intégration de ISO 639-3 fait que le registre des étiquettes de langues passe plutôt du côté des splitters.

Les étiquettes de langue sont donc composées de sous-étiquettes, et les diverses restrictions qui existent sur leur longueur et leur place font qu'il est possible d'analyser une étiquette, de déterminer où est la langue, où est le pays, etc, sans avoir d'accès au registre (section 2.2). Une étiquette peut être bien formée (obéir à la syntaxe) même si ses sous-étiquettes ne sont pas enregistrées (section 2.2.9 pour la définition de la conformance à cette norme, et la notion de « bien formée » et de « valide »). Le registre stocke des sous-étiquettes, pas des étiquettes entières, et ces sous-étiquettes peuvent être combinées librement, même si le résultat n'est pas forcément sensé. Par exemple, ar-Cyrl-AQ est à la fois bien formée - elle obéit à la grammaire, valide (toutes ses sous-étiquettes sont enregistrées) et néanmoins inutile car désignant l'arabe en écriture cyrillique tel que pratiqué en Antarctique.

Les différentes parties d'une étiquette sont décrites en section 2.2. Par exemple, l'écriture est complètement traitée en section 2.2.3 est dérive d'ISO 15924.

La section 2.2.6, sur les extensions (qu'il ne faut pas confondre avec les extlangs) n'est pas encore utilisée ; pour l'instant, aucune extension n'a été enregistrée.

Le format et la maintenance du registre sont décrits en section 3. Le registre est au format record-jar (section 3.1.1, ce format est décrit dans le livre The Art of Unix programming) et, par exemple, l'enregistrement du français est :

Type: language
Subtag: fr
Description: French
Added: 2005-10-16
Suppress-Script: Latn

et celui du cantonais est :

Type: language
Subtag: yue
Description: Yue Chinese
Added: 2009-07-29
Macrolanguage: zh

et cet enregistrement comporte la mention de la macrolangue (le chinois).

Désormais, le registre est en UTF-8 ce qui permet des choses comme :

Type: language
Subtag: pro
Description: Old Provençal (to 1500)
Description: Old Occitan (to 1500)
Added: 2005-10-16

L'ajout d'éléments au registre est possible, via une procédure décrite en sections 3.5 et 3.6. Si vous voulez enregistrer une sous-étiquette, la lecture recommandée est « How to register a new subtag ». La procédure inclus un examen par un Language Subtag Reviewer (section 3.2), actuellement Michael Everson. Je préviens tout de suite : comme indiqué en section 3.6, la probabilité qu'une demande refusée par l'ISO soit acceptée dans le registre IANA est très faible (malgré cela, des demandes sont régulièrement reçues pour des « langues » que seuls certains radicaux considèrent comme telles). Une liste complète des demandes d'enregistrement effectuées est archivée en https://www.iana.org/assignments/lang-subtags-templates. Un exemple réel est décrit dans « Enregistrement de l'alsacien dans le registre IETF/IANA ».

Lorsqu'on est occupé à étiqueter des textes, par exemple à mettre des attributs xml:lang dans un document XML, on se pose parfois des questions comme « Dois-je étiqueter ce texte comme fr ou bien fr-FR, lorsque les deux sont légaux ? » La réponse figure dans la section 4.1, qui est résumée dans « Tag wisely » (la réponse, ici, est « En général, fr tout court, sauf s'il est important de le distinguer des dialectes étrangers à la France »).

Les changements les plus importants par rapport au RFC 4646 (section 8) sont :

• Intégration des normes ISO 639-3 et 5 (section 2.2.1) ce qui fait passer le nombre de langues de 500 à 7000.
• L'arrivée de ISO 639-3 a apporté les extlangs (Extended Language Subtag, section 2.2.2) et 639-5 les collections, groupes de langues reliées entre elles.
• Meilleure description du rôle de l'IANA, surtout pour l'archivage des requêtes.
• Quelques changements pour les implémenteurs : grammaire différente mais meilleure (section 2.1) (notamment par une meilleure séparation des aspects syntaxiques et sémantiques) et registre désormais en UTF-8 et plus en ASCII.
• Et plein de petits détails.

Le changement de grammaire ne change pas grand'chose aux étiquettes bien formées ou pas mais il facilitera la tâche des implémenteurs. Les étiquettes patrimoniales (grandfathered) sont ainsi séparées en deux catégories, selon qu'elles obéissent quand même à la syntaxe standard ou pas.

L'augmentation importante de la taille du registre fait que, encore plus qu'avant, la récupération automatique du registre nécessite donc de faire attention pour ne pas charger les serveurs de l'IANA (la méthode recommandée est le GET conditionnel de HTTP RFC 7232 (If-Modified-Since, section 3.3), par exemple, avec curl, curl --time-cond "20090702" https://www.iana.org/assignments/language-subtag-registry )

Les extlangs ont été une question particulièrement délicate. Parmi les macrolangues (une collection de langues qui, dans certaines cicronstances, peuvent être vues comme une langue unique), le piège spécifique à l'arabe et au chinois est que le mot « chinois » désigne à la fois une macrolangue et une langue particulière couverte par cette macrolangue (le mandarin). Pire, dans les deux cas (chinois et arabe), les communautés locales ont du mal à admettre le verdict des linguistes. Ceux-ci disent que l'« arabe » n'est pas une langue, et que le marocain et le syrien sont des langues distinctes. Les arabophones ne sont pas tous d'accord avec l'analyse scientifique.

Les autres macrolangues n'ont pas de « langue de référence » et elles sont typiquement pratiquées par des communautés ayant moins de poids que le gouvernement de Pékin.

L'IETF a tranché que, pour certaines langues, l'extlang serait PERMIS, la forme sans extlang RECOMMANDÉE (voir notamment la section 4.1.2 sur l'usage des extlangs). Les vainqueurs sont donc : 'ar' (Arabe), 'kok' (Konkanî), 'ms' (Malais), 'sw' (Swahili), 'uz' (Ouzbèke), et 'zh' (Chinois).

Donc :

• pour le cantonais, zh-cmn permis, cmn recommandé,
• idem pour l'arabe, ar-arz est permis pour l'égyptien, arz est recommandé,
• pour le Cri, il n'a pas bénéficié de l'exception donc le Cri des Plaines est forcément crk, pas cr-crk.

Les transparents d'un exposé sur ces language tags sont disponibles. Ils ne parlent que de la version précédente, celle du RFC 4646. Le site Web officiel sur les étiquettes de langues est http://www.langtag.net/.

Un analyseur de language tags en logiciel libre existe, GaBuZoMeu et gère cette nouvelle norme. On peut trouver d'autres mises en œuvre en http://www.langtag.net/.

Toujours soucieux d'explorer l'espace et de voir comment les sociétés l'occupent et le transforment, les auteurs des « Ghettos du Gotha » ont écrit un guide touristique original de Paris : quinze promenades sociologiques dans quinze quartiers différents.

Guide en main, on suit les auteurs, rue par rue, dans ces quinze quartiers, visitant à chaque fois, non seulement les bâtiments, mais surtout ce qu'ils nous disent du quartier, qui y habite, quelles évolutions il a connu.

Les Pinçon, ce qui n'étonnera pas les lecteurs de leurs précédents ouvrages, traitent en connaisseurs les quartiers des ultra-riches (la villa Montmorency dans le chapitre XI consacré aux « villas de Paris ») mais aussi les quartiers populaires comme la Goutte d'Or (chapitre XII).

Ils travaillent aussi sur des espaces négligés mais où beaucoup de parisiens (et de banlieusards) passent une bonne partie de leur journée : les transports en commun avec le chapitre VI sur la gare Saint-Lazare et le chapitre V sur un « quartier » un peu spécial, le métro. Dans ce dernier chapitre, la visite de la ligne 13 permet d'analyser les quartiers traversés et aussi ce quartier virtuel qu'est le métro, l'un des rares endroits où se croisent, au moins physiquement, toutes les classes sociales.

Même dans la capitale où tout changement s'opère sous l'œil de beaucoup d'autorités, les urbanistes ne peuvent pas changer la ville simplement en construisant : les quartiers échappent parfois à leur destin prévu comme le 13ème arrondissement dont une partie avait été semée de tours (à la grande époque du gaullisme immobilier) pour jeunes cadres dynamiques, tours dont les destinataires n'ont pas voulu (elles faisaient trop HLM) et qui ont finalement été recupérées par les immigrés du Sud-Est asiatique (chapitre IX, Chinatown).

Paris a été pendant longtemps une ville dangereuse pour les pouvoirs en place, pleine d'artisans et d'ouvriers prompts à la barricade. Aujourd'hui, beaucoup d'anciens quartiers populaires ont été « gentrifiés » et les chapitres VII (la reprise de la Bastille) et VIII (un nouveau quartier nocturne : la rue Oberkampf) étudient en détail ce phénomène en cours de réalisation.

Les conquêtes ne sont pas forcément éternelles. Si le monde du luxe a réussi à mettre la main sur Saint-Germain-des-Prés, chassant les fantômes de Sartre et Beauvoir (chapitre III), les Champs-Élysées, eux, semblent petit-à-petit être abandonnés par la bourgeoisie riche (chapitre IV).

Pour tous ceux qui sont rentrés de vacances et habitent à Paris ou dans les environs, voici donc quinze idées de promenades intelligentes pour le week-end, le guide à la main.

(Cette deuxième édition est la réédition et mise à jour d'un livre de 2001.)

Comment représente-t-on une date sur l'Internet ? Il existe beaucoup de RFC qui ont besoin d'un format de date et, si certaine restent fidèles à des vieux formats, la plupart des RFC modernes se réfèrent à ce RFC 3339 qui définit un sous-ensemble d'ISO 8601 pour la représentation des dates.

Un des exemples les plus connus des vieux formats est le RFC 5322 qui garde, pour le courrier électronique, l'ancien format (initialement normalisé dans le RFC 724) difficile à analyser, et qui ressemble à Date: Thu, 27 Aug 2009 08:34:30 +0200. Ce format n'a été gardé que parce qu'on ne peut plus changer la norme du courrier sur un point aussi fondamental. Mais les RFC récents définissent un autre format, celui de notre RFC 3339. C'est, par exemple, le cas du RFC 4287 qui dit que les éléments XML d'un flux de syndication Atom doivent utiliser ce format, par exemple <published>2009-08-25T00:00:00Z</published>.

Pourquoi un RFC sur ce sujet et ne pas simplement se référer à la norme ISO 8601 ? Il y a plusieurs raisons. L'une est politique, c'est le fait que l'ISO ne distribue pas librement le texte de la plupart de ses normes (une version provisoire non redistribuable traine sur le serveur de l'ISO). L'autre est que ISO 8601, comme beaucoup de normes ISO, est mal spécifiée, très complexe et pleine de détails inutiles (cf. section 5.5). L'IETF a donc choisi la voie d'un sous-ensemble de ISO 8601, le format du RFC 3339.

La section 1 du RFC résume le problème général de la transmission et de l'affichage des dates. Beaucoup de programmes se sont cassés le nez sur ce sujet (je me souviens d'un logiciel commercial de gestion de tickets, très cher, qui envoyait des messages avec des dates invalides, ce qui décidait un autre logiciel commercial très cher, chargé de la lutte contre le spam, à les jeter).

Le RFC est bâti sur quelques principes, exposés dans cette section 1. On utilise évidemment le calendrier grégorien. Comme le but est de dater des événements Internet, on se limite aux dates de l'ère actuelle (i.e. après Jésus-Christ), on suppose que le décalage entre l'horloge locale et UTC est connu, etc.

Le problème de l'heure locale fait l'objet de la section 4. Les règles définissant l'heure légale étant très compliquées et changeantes (en raison de la stupide heure d'été), le choix est de s'appuyer sur UTC (section 4.1). Puisque le décalage entre l'heure locale et UTC est supposé connu, il est prévu de permettre d'indiquer ce décalage (section 4.2). Cela se fait toujours sous forme numérique, les noms alphabétiques des fuseaux horaires n'étant pas normalisés. Enfin, la section 4.4 réenfonce le clou au sujet des horloges qui ne connaissent que l'heure locale et pas son décalage avec UTC : de telles horloges sont inutilisables sur l'Internet puisqu'elles les indications temporelles transmises à partir d'elles sont fausses 23 fois sur 24 (dès qu'on n'est pas dans le même fuseau horaire).

Les historiens notent que c'était le cas des systèmes d'exploitation Microsoft pendant longtemps : l'horloge du PC ne stockait que l'heure locale, ce qui a créé d'innombrables problèmes lorsque Windows a dû se résigner à accepter les connexions avec l'Internet.

Voici pour le concept de temps. Et le format ? Quel est le cahier des charges précis ? La section 5 commence par énumérer les caractéristiques souhaitées. Les temps doivent pouvoir être comparées lexicographiquement (section 5.1), par exemple avec strcmp() en C ou sort avec le shell Unix. Contrairement à une idée répandue, ISO 8601 ne garantit pas cette possibilité (voir la section 5.1 pour une liste des règles à observer pour qu'une telle comparaison soit possible).

Autre critère important, le format doit être compréhensible par un humain (section 5.2). C'est une caractéristique fréquente des protocoles Internet ; les formats binaires sont relativement rares. Ceci dit, un format trop lisible peut mener à des erreurs. Par exemple, le format de date du RFC 5322 a mené certains programmeurs à croire qu'ils pouvaient traduire les noms de jour et de mois, puisque ceux-ci apparaissent sous une forme non-numérique (c'était l'erreur du logiciel commercial dont je parlais plus tôt). Le format de notre RFC est donc compréhensible mais pas forcément familier à tout être humain et les logiciels doivent donc se préparer à l'afficher sous une forme plus conforme aux habitudes locales.

Autre erreur du format du RFC 5322, la redondance de l'information (section 5.4). Inclure le nom du jour est redondant (puisqu'on peut le calculer à partir de la date, l'annexe B donne un exemple de code) et augmente donc les risques d'erreur (que faire si ce jour n'est pas correct, qui croire ?).

Assez de préliminaires, quel format utiliser, maintenant ? La section 5.6 va le décrire rigoureusement, en utilisant le langage ABNF (RFC 5234). Il existe quelque options comme le fait que le temps peut être écrit en heure locale, si le décalage avec UTC est indiqué. La section 5.8 donne quelques exemples de temps corrects. Voici comment les produire avec GNU date (le fait de séparer la date et le temps par un espace et pas par la lettre T est une violation de la grammaire mais le RFC est ambigu sur ce point) :

% date --rfc-3339='ns'
2009-07-12 11:03:08.434344377+02:00

% date --rfc-3339='seconds'
2009-07-12 11:03:12+02:00

% date --rfc-3339='date'
2009-07-12

et voici un programme Python qui affiche la date actuelle en UTC (donc avec le Z à la fin, Z étant l'équivalent de +00:00) :

import time

# date+time but no fractional seconds
rfc_3339_nosecfrac = "%Y-%m-%dT%H:%M:%SZ"

# gmtime = UTC (old name)
print time.strftime(rfc_3339_nosecfrac, 
                    time.gmtime(time.time()))

Et, en C, voici un exemple possible :

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>

#define MAX_SIZE 256
#define RFC_3339_NOFRAC_UTC "%Y-%m-%dT%H:%M:%SZ"

int
main()
{
    char           *result = malloc(MAX_SIZE);
    struct timeval  tv;
    struct tm      *time;
    size_t          result_len;
    (void) gettimeofday(&tv, NULL);
    time = gmtime(&tv.tv_sec);
    result_len = strftime(result, MAX_SIZE, RFC_3339_NOFRAC_UTC, time);
    if (result_len != 0) {
        printf("%s\n", result);
        exit(0);
    } else {
        printf("Error in strftime\n");
        exit(1);
    }
}

Y a t-il des problèmes de sécurité cachés derrière l'affichage de la date ? Oui, la section 7 en cite un : la connaissance de l'heure locale d'un système peut permettre à un attaquant de déterminer les heures où le système est le plus suceptible d'être surveillé et le paranoïaque peut donc avoir intérêt à n'émettre que des temps en UTC…

Notre RFC compte plusieurs annexes intéressantes. Par exemple, l'annexe A est une rétro-ingénierie de la norme ISO 8601. Comme celle-ci ne spécifie pas formellement de grammaire pour le format des dates, ce sont les auteurs du RFC qui en ont établi une, à partir de la norme. Elle est bien plus riche (avec beaucoup plus d'options) que celle de la section 5.6. L'annexe D donne les détails sur la gestion des secondes intercalaires, qu'on peut trouver en ligne.

Un des ennuis les plus fréquents sur l'Internet est l'attaque par déni de service. Répondre à ce genre d'attaques ne peut pas se faire par une mise à jour logicielle ou par un changement de configuration ; d'une manière ou d'une autre, il faut éliminer le trafic anormal qui constitue la DoS. Notre RFC 5635 présente une technique permettant de déclencher le filtrage à distance, et en le faisant en fonction de l'adresse source des paquets IP de l'attaquant.

Plusieurs techniques ont déjà été développées pour faire face aux DoS, résumées dans la section 1 du RFC. Filtrer le trafic sur son propre routeur ou pare-feu est souvent inefficace : le trafic anormal a déjà transité sur votre liaison Internet et cela suffit souvent à la rendre inutilisable. Le mieux est en général de filtrer chez le FAI. Filtrer par le biais d'ACL marche bien mais les routeurs sont en général bien plus rapides à router qu'à filtrer à l'aide d'ACL. Il est donc préférable d'utiliser le routage en créant des routes « bidon », qui aboutissent dans le vide (Null0 sur IOS, par exemple, ou bien route ... discard sur JunOS), et à qui on envoie le trafic indésirable. L'élimination des paquets sera ainsi faite à la vitesse maximale du routeur.

Autre problème avec le filtrage chez le FAI : le faire à la main, après échange de coups de téléphone, n'est pas très pratique, et impose des détails alors que l'attaque est déjà en cours. D'où l'utilité de pouvoir déclencher le filtrage à distance, selon la technique dite RTBH (Remote Triggered Black Hole), qui est décrite dans le RFC 3882. Dans ce RFC, on se sert de BGP pour annoncer le filtrage à un autre routeur, en marquant les annonces en question avec une communauté BGP particulière (une communauté est une sorte d'étiquette numérique attachée à l'annonce BGP).

C'était l'état de l'art documenté avant la sortie de ce RFC 5635. Le problème de cette méthode du RFC 3882 est que les routes, dans le protocole IP, sont en fonction de la destination. On va par exemple filtrer tout le trafic à destination du serveur victime d'une attaque. On empêche ainsi les dommages collatéraux sur les autres machines mais on rend le serveur attaqué complètement inaccessible (section 1 du RFC). Lors d'une attaque, on préférerait parfois filtrer selon la source.

Le principe est donc de combiner le RTBH (Remote Triggered Black Hole) classique avec les techniques RPF du RFC 3704. C'est là l'apport de notre RFC, détaillé en section 4.

Avant cela, le RFC rappelle, dans sa section 3, le fonctionnement du RTBH par destination tel que décrit dans le RFC 3882, en fournissant des détails nouveaux. Le principe du RTBH est que l'annonce BGP indique comme routeur suivant (next hop) une route vers un trou noir, où tous les paquets sont détruits. Les détails pratiques sont en section 3.2. Parmi eux, attention aux importants filtres de sortie, qui empêcheront les annonces BGP de destruction de fuir en dehors du réseau de l'opérateur.

Le déclenchement du filtrage par le client nécessite que celui-ci puisse communiquer ses desiderata. Il le fait en général en marquant ses annonces par une communauté BGP, choisie par l'opérateur. Celui-ci a même intérêt à prévoir plusieurs communautés, pour un filtrage plus fin.

La section 4 présente la nouvelle technique. Le principe est de réutiliser le mécanisme uRPF (unicast Reverse Path Forwarding) du RFC 3704. uRPF vérifie qu'il existe une route légitime pour l'adresse source du paquet entrant, afin d'éliminer des paquets dont l'adresse source est fausse. Si le routeur sait qu'une route vers un trou noir n'est pas légitime, alors, il peut filtrer en fonction de la source, si des routes vers ces adresses sources ont été installées par RTBH. Pour l'instant, aucun routeur ne fournit apparemment la possibilité de refuser uniquement les adresses pour lesquelles la route va dans un trou noir, mais elle devrait apparaitre bientôt.

La section 4.1 fournit les étapes exactes à suivre lorsqu'on met en œuvre ce filtrage. Lorsqu'on veut bloquer les paquets venant de 192.0.2.66, on doit :

• Activer RPF sur les routeurs du FAI,
• Annoncer, depuis le client, une route vers 192.0.2.66/32, marquée avec la communauté BGP de filtrage indiquée par le FAI. (Attention, cela veut dire que le client va annoncer des réseaux qui ne lui appartiennent pas : le FAI devra accepter ces annonces mais faire très attention à ce qu'elles ne se propagent pas au delà de son réseau.)
• La route sera alors installée dans les routeurs du FAI, pointant vers un trou noir. Les tests RPF échoueront alors pour les paquets émis par l'attaquant et les paquets seront rejetés.

Permettre à n'importe quel client de vouer ainsi n'importe quelle adresse source au trou noir est évidemment dangereux et le RFC conseille de ne pas activer cette possibilité par défaut (contrairement à ce qu'on peut faire pour le filtrage selon la destination). Le RTBH reste utile même s'il n'est utilisé que dans le réseau de l'opérateur, car il évite de configurer manuellement tous les routeurs de ce dernier. La section 5 détaille les risques de cette technique et les précautions à prendre.

L'annexe A détaille la configuration des routeurs pour cette famille de techniques, avec des exemples concrets pour IOS et JunOS.

Un bon article sur RTBH est « Mitigating DoS/DDoS attacks with Real Time Black Hole (RTBH) filtering », avec exemples pour Cisco IOS.

Depuis sa publication, le RFC 4871, qui normalise DKIM, le mécanisme d'authentification du courrier électronique, le RFC, donc, a connu un certain nombre d'implémentations et de déploiements. Ceux-ci ont mis en évidence des problèmes dans la norme. D'où ce nouveau RFC, un erratum, qui corrige la norme sur quelques points. Une nouvelle version de DKIM, dans le RFC 6376, a ensuite été adoptée, rendant ce RFC 5672 inutile.

Quel était le principal problème ? Comme l'explique la section 1 de notre RFC 5672, DKIM sert à prouver une identité, sous la forme d'un identificateur, typiquement un nom de domaine. Quelle est la sémantique de cet identificateur ? C'est justement ce qui n'était pas clair dans le RFC 4871. Celui-ci spécifiait deux identités, indiquées par les marques d= et i= de la signature. Un exemple de signature est :

DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
         c=simple/simple; q=dns/txt; i=joe@football.example.com;
...

et on y voit deux identités légèrement différentes, example.com et joe@football.example.com. Je ne maintiens pas le suspense : la bonne, celle à indiquer l'utilisateur, est bien celle marquée par d=, ici example.com, ce qui n'était pas évident dans le RFC 4871. C'est ce nom qui devrait être affiché par le MUA comme ayant été authentifié (cf. section 15).

Les sections suivantes du RFC mettent chacune à jour une partie du RFC 4871 original, sous la forme « texte original / nouveau texte ». Certaines sections sont entièrement nouvelles, notamment pour introduire beaucoup de nouveau vocabulaire. C'est ainsi qu'est introduit, dans la section 6, le terme de SDID (Signing Domain IDentifier), qui désigne la « vraie » identité de l'émetteur du message. Le SDID de l'exemple précédent est donc example.com. La section 9 de notre RFC corrige la section 3.5 du RFC original en remplaçant le vague terme « domaine » par SDID. Et la section 10 de notre RFC, pour parler du nom qui figure après la marque i=, emploie désormais AUID (Agent or User Identifier) à la place du trop imprécis « identité ». (Le RFC 5672 précise aussi la sémantique de ce champ, insistant notamment sur le fait que sa ressemblance syntaxique avec une adresse de courrier électronique ne doit pas être prise trop au sérieux : le AUID n'est pas une adresse.)

La connexion à l'Internet typique du particulier ou de la petite entreprise passe aujourd'hui par une boîte aux fonctions mal définies. Parfois, celle-ci assure, parmi ses autres tâches, le rôle d'un relais DNS. Et ces relais, programmés en général avec les pieds par un stagiaire en Chine, violent souvent les règles du protocole DNS, et causent d'innombrables problèmes. Ce RFC dresse la liste des problèmes potentiels et formule les règles que doivent suivre les relais pour ne pas trop casser le DNS. Cela servira, pour le cas improbable où les bricoleurs qui écrivent le logiciel de ces boîtes lisent les RFC...

Ces « boîtes » sont parfois nommées box (en anglais, ça fait plus sérieux) parfois « décodeurs » (en souvenir de Canal+, première entreprise qui a réussi à mettre des boîtes chez ses clients), parfois « modem », parfois « routeur », ce qui est techniquement souvent correct, mais insuffisant, vue la variété des fonctions qu'elles assurent. Au minimum, la « boîte » devrait faire passer les paquets IP d'un côté à l'autre (du réseau local vers celui du FAI et réciproquement). Mais, pour des raisons comme celles expliquées par le RFC dans sa section 5.3, beaucoup de boîtes s'arrogent des rôles comme celui de relais DNS, rôle qu'elles remplissent mal.

La section 1 du RFC rappelle l'excellente étude qu'avait fait le même auteur, Ray Bellis, employé du registre de .uk, pour le compte du SSAC de l'ICANN : cette étude, et celle du registre DNS suédois, montraient que la grande majorité des boîtes existantes, dans leur configuration par défaut) violaient largement le protocole DNS et qu'elles contribuaient ainsi à l'ossification de l'Internet (le fait qu'on ne puisse plus déployer de nouveaux services car les boîtes intermédiaires abusent de leur rôle et bloquent ce qu'elles ne comprennent pas). Des nouveaux services comme DNSSEC risquent donc d'être très difficiles à installer.

La boîte qui fait relais DNS (et pas simplement routeur IP, comme elle le devrait) n'a en général pas un vrai serveur DNS, avec capacités de cache et gestion complète du protocole. Elle est un être intermédiaire, ni chair, ni poisson, violant le modèle en couches, et dépend des résolveurs du FAI auquel elle transmet les requêtes. Le RFC commence donc par recommander de ne pas utiliser de tels relais. Néanmoins, s'ils existent, il faudrait au minimum qu'ils suivent les recommandations du document.

La section 3 remet ces recommandations dans le contexte du principe de transparence. Un relais DNS ne peut espérer mettre en œuvre toutes les fonctions du DNS, surtout celles qui n'existent pas encore. En effet, la boîte a en général des ressources matérielles assez limitées, elle n'a souvent pas de mécanisme de mise à jour simple, ce qui veut dire qu'elle tournera toute sa vie avec le même code, et son interface de configuration doit idéalement être simple.

Alors, le relais, puisqu'il ne peut pas gérer complètement le DNS, devrait le laisser en paix. L'étude du SSAC montrait que, plus la boîte joue un rôle actif dans le protocole DNS, plus elle fait de bêtises. Le relais devrait donc juste prendre les paquets d'un côté et les envoyer de l''autre, sans jouer à les interpréter, ce qu'il fait toujours mal. Et, dans tous les cas, le RFC recommande que les machines du réseau local puissent écrire directement au résolveur DNS de leur choix, si celui de la boîte est vraiment trop mauvais (ce n'est pas toujours possible, par exemple dans les hôtels où le port 53, celui du DNS, est souvent filtré).

Dans le cadre de ce principe de transparence, la section 4 du RFC détaille ensuite point par point toutes les règles à respecter particulièrement. Ainsi, la section 4.1 rappelle que les relais ne doivent pas jeter un paquet DNS simplement parce que des options inconnues apparaissent dans celui-ci. Beaucoup de boîtes jettent les paquets où les bits AD (Authentic Data) ou CD (Checking Disabled) sont à un, simplement parce qu'ils n'existaient pas à l'époque du RFC 1035 (section 4.1), le seul que le stagiaire qui a programmé la boîte a lu (quand il en a lu un). (Ces bits sont dans la plage Reserved for future use, notée Z.)

De même, certaines boîtes ne laissent pas passer les types d'enregistrement inconnus, la section 4.3 rappelle donc, suivant le RFC 3597 qu'une mise en œuvre correcte du DNS doit laisser passer les types inconnus, sinon il sera impossible de déployer un nouveau type.

Un autre point sur lequel les logiciels des boîtes (mais aussi beaucoup de pare-feux) sont en général défaillants est celui de la taille des paquets DNS. Là encore, si le programmeur a lu un RFC (ce qui est rare), il s'est arrêté au RFC 1035, sans penser que, depuis vingt-deux ans qu'il existe, des mises à jour ont peut-être été faites et que la taille maximum de 512 octets n'est donc plus qu'un souvenir. La section 4.4 doit donc rappeler que les paquets DNS ne sont pas limités à 512 octets et que des réponses de plus grande taille sont fréquentes en pratique. Le relais doit donc gérer TCP correctement (section 4.4.1), et accepter EDNS0 (section 4.4.2, voir aussi le RFC 6891..

Les boîtes maladroites peuvent aussi interférer avec la sécurité. La section 4.5 rappelle que TSIG (RFC 8945) peut être invalidé si la boîte modifie certains bits des paquets (ce qui existe) ou bien retourne des réponses non signées à des requêtes signées (ce qui est courant sur les points chauds Wifi).

Une autre section, la 5, couvre les questions de l'interaction avec DHCP. La plupart du temps, la machine de M. Toutlemonde obtient l'adresse IP du résolveur DNS via DHCP (option 6, Domain Name Server, RFC 2132, section 3.8). La plupart des boîtes indiquent leur propre adresse IP ici. Et, en général, il n'est pas possible de modifier ce paramètre (par exemple, la Freebox ne permet pas d'indiquer un autre serveur DNS, choisi par le client ; même chose chez SFR). La seule solution pour court-circuiter le service DNS par défaut est donc d'indiquer en dur les résolveurs souhaités, dans la configuration de chaque machine. La section 5.1 appelle donc à une option de la boîte permettant de changer les serveurs DNS annoncés.

DHCP permet également une option indiquant le nom de domaine du réseau (option 15, section 3.17 du RFC 2132) et la section 5.2 du RFC 5625 demande qu'elle soit vide par défaut, en l'absence d'un domaine local normalisé.

La section 5.3 est consacrée à une discussion sur la durée du bail DHCP. Une des raisons pour lesquelles beaucoup de boîtes indiquent leur propre adresse IP comme résolveur DNS est que, au démarrage, la boîte ne connait pas forcément les adresses des résolveurs DNS du FAI. Mais cette technique oblige ensuite la boîte à agir comme relais DNS, ce qui est précisément la source de beaucoup de problèmes. Une solution possible, suggérée par notre RFC, est d'annoncer l'adresse IP de la boîte avec une durée de bail ultra-courte, tant que la boîte n'est pas connectée à l'Internet, puis d'annoncer les résolveurs du FAI ensuite, avec une durée de bail normale.

Les interférences provoquées par les boîtes mal conçues peuvent aussi avoir un impact sur la sécurité. C'est l'objet de la section 6. Il y a des boîtes qui, ignorant le RFC 5452, réécrivent le Query ID, rendant ainsi les utilisateurs davantage vulnérables à la faille Kaminsky (section 6.1). Il y en a qui répondent aussi aux requêtes DNS venues du WAN, permettant ainsi les attaques décrites dans le RFC 5358 (section 6.2).