Mon blog

La grande majorité des applications Internet tourne sur le protocole de transport TCP. Mais son concurrent UDP, normalisé dans le RFC 768, prend de l'importance avec le multimédia et les jeux en ligne pour lesquels il est souvent bien adapté. Mais, contrairement à TCP, UDP ne fournit aucun mécanisme de contrôle de la congestion. C'est donc aux applications de fournir ce contrôle, suivant les règles expliquées par ce RFC.

UDP est apprécié pour certaines applications car il est simple et léger et le fait qu'il ne garantisse pas l'acheminement de la totalité des paquets n'est pas forcément un problème dans les applications multimédia : si on perd quelques secondes d'une communication téléphonique RTP, il vaut mieux passer à la suite que de perdre du temps à la retransmettre comme le ferait TCP. Mais UDP ne fournit pas non plus de contrôle de la congestion. C'est pourtant nécessaire (RFC 2914 et RFC 2309), à la fois pour assurer que le réseau continue à être utilisable et également pour assurer une certaine équité entre les différents flux de données, pour éviter qu'une seule application gourmande ne monopolise le réseau pour elle.

UDP ne le faisant pas, il faut bien que l'application le fasse et, pour cela, qu'elle mette en œuvre les conseils de ce RFC. (Notre RFC contient également des conseils pour d'autres aspects de l'utilisation d'UDP que le contrôle de congestion : mais c'est le plus important.)

Le gros du RFC est dans la section 3 qui détaille ces conseils (la section 5 contient un excellent résumé sous forme d'un tableau des conseils à suivre). Le premier est qu'il vaut peut-être mieux ne pas utiliser UDP. Beaucoup de développeurs d'applications pensent à UDP en premier parce qu'il est simple et facile à comprendre et qu'il est « plus rapide que TCP ». Mais, rapidement, ces développeurs se rendent compte qu'ils ont besoin de telle fonction de TCP, puis de telle autre, ils les mettent en œuvre dans leur application et arrivent à une sorte de TCP en moins bien, d'avantage bogué et pas plus rapide. Notre RFC conseille donc d'abord de penser aux autres protocoles de transport comme TCP (RFC 793), DCCP (RFC 4340) ou SCTP (RFC 4960). Ces protocoles sont d'autant plus intéressants qu'ils ont souvent fait l'objet de réglages soigneux depuis de nombreuses années et qu'il est donc difficile à un nouveau programme de faire mieux. D'autant plus qu'il existe souvent des réglages spécifiques pour les adapter à un usage donné. Par exemple, on peut dire à TCP de donner la priorité à la latence (paramètre TCP_NODELAY de setsockopt) ou bien au débit.

Si on ne suit pas ces sages conseils, et qu'on tient à se servir d'UDP, que doit-on faire pour l'utiliser intelligemment ? La section 3.1 couvre le gros morceau, le contrôle de congestion. Celui-ci doit être pris en compte dès la conception de l'application. Si cette dernière fait de gros transferts de données (section 3.1.1, c'est le cas de RTP, RFC 3550), elle doit mettre en œuvre TFRC, tel que spécifié dans le RFC 5348, donc faire à peu près le même travail que TCP. Et ce mécanisme doit être activé par défaut.

Si l'application transmet peu de données (section 3.1.2), elle doit quand même faire attention et le RFC demande pas plus d'un datagramme par RTT, où le RTT est un cycle aller-retour avec la machine distante (calculé selon le RFC 2988 ; si le calcul n'est pas possible, le RFC demande une durée de trois secondes). L'application doit également détecter les pertes de paquet pour ralentir son rythme si ces pertes - signe de congestion - sont trop fréquentes.

Le cas où l'application est un tunnel au dessus d'UDP est également couvert (section 3.1.3).

En suivant toutes ces règles, l'application gère proprement la congestion. Et le reste ? La section 3.2 fournit des pistes sur la gestion de la taille des paquets (rester en dessous de la MTU, utiliser la découverte de MTU spécifiée dans des RFC comme le RFC 4821, etc). La 3.3 explique la question de la fiabilité : par défaut, UDP ne retransmet pas les paquets perdus. Si c'est nécessaire, c'est l'application qui doit le faire. Elle doit aussi gérer l'eventuelle duplication des paquets (qu'UDP n'empêche pas). Le RFC note que les retards des paquets peuvent être très importants (jusqu'à deux minutes, normalise le RFC) et que l'application doit donc gérer le cas où un paquet arrive alors qu'elle croyait la session finie depuis longtemps.

La section 3.4 précise l'utilisation des sommes de contrôle (facultatives pour UDP sur IPv4 mais qui devraient être utilisées systématiquement). Si une somme de contrôle pour tout le paquet semble excessive, et qu'on veut protéger uniquement les en-têtes de l'application, une bonne alternative est UDP-Lite (RFC 3828), décrit dans la section 3.4.1.

Beaucoup de parcours sur l'Internet sont encombrés de « middleboxes », ces engins intermédiaires qui assurent diverses fonctions (NAT, coupe-feu, etc) et qui sont souvent de médiocre qualité logicielle, bricolages programmés par un inconnu et jamais testés. La section 3.5 spécifie les règles que devraient suivre les applications UDP pour passer au travers sans trop de heurts. Notamment, beaucoup de ces « middleboxes » doivent maintenir un état par flux qui les traverse. En TCP, il est relativement facile de détecter le début et la fin d'un flux en observant les paquets d'établissement et de destruction de la connexion. En UDP, ces paquets n'ont pas d'équivalent et la détection d'un flux repose en général sur des heuristiques. L'engin peut donc se tromper et mettre fin à un flux qui n'était en fait pas terminé. Si le DNS s'en tire en général (c'est un simple protocole requête-réponse, avec en général moins de deux secondes entre l'une et l'autre), d'autres protocoles basés sur UDP pourraient avoir de mauvaises surprises. Elles doivent donc se préparer à de soudaines interruptions de la communication, si le timeout d'un engin intermédiaire a expiré alors qu'il y avait encore des paquets à envoyer. (La solution des keepalives est déconseillée par le RFC car elle consomme de la capacité du réseau et ne dispense pas de gérer les coupures, qui se produiront de toute façon.)

La section 3.6 fera le bonheur des programmeurs qui y trouveront des conseils pour mettre en œuvre les principes de ce RFC, via l'API des prises (sockets, RFC 3493). Elle est largement documentée mais en général plutôt pour TCP que pour UDP, d'où l'intérêt du résumé qu'offre ce RFC, qui ne dispense évidemment pas de lire le Stevens. Par exemple, en l'absence de mécanisme de TIME_WAIT (la prise reste à attendre d'éventuels paquets retardés, même après sa fermeture par l'application), une application UDP peut ouvrir une prise... et recevoir immédiatement des paquets qu'elle n'avait pas prévus, qui viennent d'une exécution précédente.

Le protocole ICMP fournit une aide utile, que les applications UDP peuvent utiliser (section 3.7). Mais attention, certains messages ICMP peuvent refléter des erreurs temporaires (absence de route, par exemple) et ne devraient pas entraîner de mesures trop drastiques.

Après tous ces conseils, la section 4 est dédiée aux questions de sécurité. Comme TCP ou SCTP, UDP ne fournit en soi aucun mécanisme d'intégrité des données ou de confidentialité. Pire, il ne fournit même pas d'authentification de l'adresse IP source (authentification fournie, avec TCP, par le fait que, pour établir la connexion, il faut recevoir les réponses de l'autre). L'application doit-elle mettre en œvre la sécurité seule ? Le RFC conseille plutôt de s'appuyer sur des protocoles existants comme IPsec (RFC 4301) ou DTLS (RFC 4347). En effet, encore plus que les protocoles de gestion de la congestion, ceux en charge de la sécurité sont très complexes et il est facile de se tromper. Il vaut donc mieux s'appuyer sur un système existant plutôt que d'avoir l'hubris et de croire qu'on peut faire mieux que ces protocoles ciselés depuis des années.

Pour authentifier, il existe non seulement IPsec et DTLS mais également d'autres mécanismes dans des cas particuliers. Par exemple, si les deux machines doivent être sur le même lien (un cas assez courant), on peut utiliser GTSM (RFC 3682) pour s'en assurer.

Le protocole BTNS (Better Than Nothing Security), expliqué dans le RFC 5387, est normalisé dans ce RFC 5386. Il permet d'utiliser IPsec sans authentification des autres machines, ce qui pourrait simplifier son déploiement.

BTNS ne change pas le protocole IPsec (RFC 4301), ni les protocoles associés comme IKE (RFC 4306). Sur le câble, ce sont les mêmes paquets qui passent, les changements se concentrant sur les machines terminales, dans la PAD (Peer Authentication Database, section 4.4.3 du RFC 4301) et la SPD (Security Policy Database, section 4.4.1 du RFC 4301).

Ce RFC reste assez court car il ne normalise pas encore toutes les idées prévues dans le RFC 5387 comme par exemple la liaison entre une SA (Security Association) IPsec et une connexion dans les couches hautes (cf. section 4.1) ou comme la mémoire des SA précédentes, pour n'avoir à faire confiance à un inconnu que la première fois (cf. section 4.2, qui propose un futur mécanisme analogue à celui de SSH).

La section 2 décrit BTNS par rapport à l'IPsec traditionnel. Le principal changement est que, après l'examen de toutes les entrées de la PAD, une implémentation de BTNS peut simplement accepter un pair uniquement pour sa clé publique, ou même pour n'importe quelle clé (cas où on accepte les connexions de tout le monde).

La section 3 décrit quelques exemples de scénarios avec BTNS. Ainsi, 3.3 décrit un serveur NFS qui veut protéger le trafic NFS avec IPsec, tout en acceptant n'importe quel client NFS (accepter au niveau IPsec : les couches hautes peuvent toujours imposer une authentification). La PAD (Peer Authentication Database) ressemblera à :

         Rule Remote ID        IDs allowed  SPD Search by
         ---- ---------        -----------  -------------
          1   PUBLICKEY:any    ANY          by-IP

(Une seule règle, accepter tout le monde. Une telle règle n'était pas possible en IPsec avant BTNS.) Et la SPD (Security Policy Database) pourra être :

        Rule Local Remote Next Layer BTNS  Action
               addr  addr   Protocol   ok
         ---- ----- ------ ---------- ----  -----------------------
          1    [C]    ANY      ANY      yes  PROTECT(ESP,transport,
                     with                               integr+conf)
                     port
                     2049

          2    [C]    ANY      ANY      N/A  BYPASS

(Utilisation IPsec, avec protection ESP pour le port 2049 (NFS) et ne pas toucher aux autres applications.)

La section 4 revient sur les problèmes de sécurité déjà étudiées dans la section 5 du RFC 5387. BTNS est notamment vulnérable aux attaques d'un attaquant situé au milieu.

En matière de sécurité, le mieux peut être l'ennemi du bien. Un protocole très exigeant peut, en partie à cause de ces exigences, ne pas être déployé et laisser donc l'Internet aussi vulnérable qu'avant. C'est en partie ce qui est arrivé à IPsec et a justifié le travail sur le mécanisme « Mieux que rien » qui fait l'objet de plusieurs RFC dont notre RFC 5387 qui décrit les motivations et le domaine d'application de ce nouveau mécanisme ou dont le RFC 5386 qui normalise le nouveau protocole.

C'est une banalité que de dire que l'Internet n'est pas sûr. N'importe qui peut envoyer un paquet avec une fausse adresse IP, il est très facile d'écouter ce qui passe sur le réseau et il est facile de s'insérer dans une session déjà commencée. On peut se demander pourquoi le problème n'a pas encore été traité. Il l'a été, pourtant. Par exemple, IETF a depuis 1998 un protocole, IPsec (actuellement RFC 4301), qui permet de sécuriser n'importe quelle connexion Internet contre l'écoute ou la modification, en utilisant la cryptographie. IPsec est exigeant : pour établir une SA (Security Association, association de sécurité entre deux machines, qui leur permettra de communiquer en toute sécurité), il faut s'authentifier, ce qui veut dire un secret partagé (un mot de passe) ou bien une signature reconnue par une autorité commune. Si IPsec peut utiliser plusieurs identités dans sa base , les adresses IP, noms de domaine et bien d'autres, toutes doivent être authentifiées (voir aussi la section 2.1). C'est lourd et compliqué et cela a pesé sérieusement dans le peu de déploiement d'IPsec (section 1 du RFC).

Alors, faut-il supprimer l'obligation d'authentification ? Après tout, si IPsec est utilisé entre deux pairs BitTorrent, quel besoin ont-ils de s'authentifier ? La plupart du temps, les pairs acceptent de servir n'importe quelle autre machine. Même chose pour un serveur Web public. Mais ce n'est pas si simple (section 1.1) car l'authentification sert aussi à empêcher les attaques de « l'Homme au Milieu », un attaquant situé entre les deux machines et qui se fait passer pour leur correspondant. Si un tel intermédiaire est présent, la cryptographie ne servira à rien puisque les clés utilisées sont connues du méchant.

C'est pourtant la voie que suit (avec prudence) le nouveau protocole BTNS (Better Than Nothing Security ou « Mieux vaut un peu de sécurité que pas de sécurité du tout - ce qui arrive si on impose des contraintes trop élevées. »).

Ainsi, le protocole telnet était bien connue pour son extrême vulnérabilité, puisque les mots de passe passaient en clair, mais, pendant longtemps, les seules solutions proposées étaient horriblement compliquées comme Kerberos (RFC 1411 pour un telnet « kerberisé »). Elles n'avaient donc jamais été déployées sérieusement avant la sortie de SSH en 1995. SSH, lui, remplacera telnet en quelques années, bien que certains experts en sécurité aient froncé le sourcil lors de son lancement en l'estimant insuffisamment blindé.

Une des solutions qu'utilise BTNS pour limiter les risques est de dépendre d'une authentification faite dans les couches hautes (IPsec travaille dans la couche 3). La section 1.3 décrit comment de tels mécanismes rendent BTNS moins dangereux qu'il n'en a l'air.

On peut se demander quel est l'intérêt de BTNS si un protocole comme TLS s'occupe de toute la sécurité. Mais BTNS est IPsec, donc protège également contre certaines attaques dans les couches basses, contre lesquelles TLS ne peut rien. Ainsi, un paquet TCP RST (Reset, qui va couper la connexion) imité peut couper une session TLS, puisque TLS n'authentifie et ne protège que la couche application. Une telle attaque, pratiquée par exemple par Comcast contre ses propres clients (voir aussi la section 2.2.1), ne marcherait pas avec BTNS.

Les sections 2 et 3 du RFC décrivent plus en détail le problème que BTNS résoud et la manière dont il le résoud (en permettant les connexions non authentifiées). La section 4, elle, revient sur le domaine d'application de BTNS. BTNS n'a pas d'intérêt pour les connexions très sécurisées, par exemple entre deux organisations qui veulent établir entre elles un VPN aussi solide que possible. Pour celles-ci, le IPsec actuel est une bonne approche. Mais BTNS est utile si :

• Un serveur public veut accepter tous les clients mais souhaite protéger les connexions après leur établissement,
• Un serveur sait authentifier ses clients après l'établissement de la connexion.

La section 4.1 explique les bénéfices de BTNS dans ce cas (pas d'infrastructure d'authentification à gérer) et la 4.2 ses faiblesses (le risque d'établir la connexion avec un imposteur).

Enfin, la section 5 analyse plus complètement les questions de sécurité parfois subtiles qui naissent de ce tournant dans IPsec. BTNS protège la connexion établie, mais pas l'établissement. Il est donc proche des autres protocoles TOFU (Trust On First Use ou, plus méchamment, leap of faith, « acte de foi ») comme SSH. Contrairement à SSH, BTNS ne se souvient pas forcément des clés précédemment présentées, et ne peut donc pas détecter l'arrivée d'un imposteur (cf. section 5.7).

BTNS est donc vulnérable aux attaques de l'homme au milieu (section 5.3) mais aussi à certaines attaques DoS comme tout protocole de cryptographie. En effet (section 5.4), une machine qui établit une connexion IPsec avec vous (ce qui est plus facile avec BTNS puisqu'il n'y a plus d'authentification) peut vous faire exécuter des calculs de cryptographie assez coûteux.

À l'heure actuelle, je ne connais pas d'implémentation de BTNS dans les grands projets IPsec comme Openswan.

Autrefois, les sociétés de mercenaires, qui louaient leurs services aux États pour des coups tordus divers, notamment en Afrique, étaient de petites sociétés européennes ou sud-africaines, comme Sandline ou Executive Outcomes. Pas de bureaux connus, peu de frais de fonctionnement, pas de paperasses, pas de scrupules excessifs. En France, avec Bob Denard, on avait même des organisations complètement informelles, juste un groupe de brutes qui se connaissaient bien et pouvaient répondre à un coup de téléphone en cinq minutes. Mais les États-Unis sont rentrés sur ce marché et ils l'ont sérieusement professionnalisé. La plus importante société de mercernariat privée au monde, Blackwater, marque l'entrée du mercenariat dans l'ère corporate : bataillons d'avocats, service de propagande (pardon, de « communication ») étoffé, et activités de lobbying et de marketing intenses.

Le journaliste Jeremy Scahill a enquêté pendant des annnées sur Blackwater et en a sorti ce livre, la référence sur le monde des « sociétés militaires privées » (il s'agit de la seconde édition). Suivant la mode idéologique du moment, développement de la sous-traitance et réduction du rôle du service public, ces sociétés s'attaquent à ce qui semblait le dernier bastion de la puissance publique, la violence armée. En Irak, il y a déjà d'avantage de mercenaires que de soldats réguliers. Et cela devrait continuer puisque, comme le dit franchement le PDG de Blackwater, « Quand vous voulez envoyer un colis, vous ne faites pas confiance à la Poste, vous le passer à FedEx. C'est pareil pour les questions de sécurité. ».

Si, au début, les tâches des mercenaires (appelés « sous-traitants civils » désormais) se limitaient à des missions peu glorieuses de gardiennage, désormais, ils sont parfois engagés dans des combats, jusqu'à commander des troupes régulières. S'ils se limitaient aux terres lointaines et exotiques, ils sont maintenant également utilisés sur le sol national, comme à la Nouvelle-Orléans après Katrina.

Scahill décrit en détail ce monde, les budgets considérables dont il dispose, les liens étroits entretenus avec le gouvernement de Washington, la façon dont il s'est rendu indispensable au fur et à mesure du dégraissage de l'armée régulière. Blackwater réussit à payer ses hommes bien plus chers que l'armée (mais sans retraite et sans aucun avantage social), tout en se prétendant moins cher qu'elle (mais les budgets sont tellement opaques qu'il est difficile de savoir ce qu'il en est).

Dans des pays comme l'Irak, les « sous-traitants » opèrent dans la plus totale impunité. N'étant pas aux États-Unis, ils ne sont pas soumis aux lois de ce pays. N'étant pas des militaires d'active, ils ne sont pas soumis aux lois militaires ; si indulgentes soient-elles pour les tortionnaires d'Abou Ghraib, il faut noter que plusieurs soldats ont été poursuivis devant la justice militaire pour des crimes contre des civils irakiens, ce qui n'a jamais été le cas des mercenaires, même après des massacres comme celui de la place Nisour.

La puissance de cette armée privée (qui dispose même désormais de son aviation) est d'autant plus inquiétante que ses dirigeants ont un autre but dans la vie que de gagner de l'argent. Tous professent un christianisme intégriste et guerrier, et voient leur rôle comme une composante d'une croisade. Peut-être y a t-il une part de marketing dans cette attitude. Ce serait encore le moins effrayant.

Ce ne serait pas la seule contradiction de Blackwater : les lois du capitalisme sont rudes et la concurrence (DynCorp, Triple Canopy) est très présente. Après avoir clamé bien fort son patriotisme et son chauvinisme, Blackwater a fini par embaucher des chiliens et des salvadoriens car ils coûtent moins cher que les états-uniens et leur famille ne risque pas de faire un procès s'ils meurent en Afghanistan.

Peu d'hommes politiques aux États-Unis se risquent à regarder de près ce que fait le Pentagone avec les mercenaires. Scahill épingle ainsi l'inactivité de Clinton au Sénat et note qu'Obama a été plus inquisiteur... mais aussi que le recours au mercenariat est tellement présent partout qu'il sera difficile au nouveau président de revenir en arrière.

Un excellent livre, donc, sur ce monde dangereux et fermé. Il a été composé à partir d'articles parus dans la presse et il y a donc souvent des redites (parfois mot pour mot) mais c'est un reproche mineur, l'important est d'avoir des informations soigneusement vérifiées et à jour sur ce milieu.

Pendant longtemps, l'IETF a vécu avec l'illusion qu'elle était une organisation purement technique, vouée uniquement à produire les meilleures normes possibles, sans considération pour les questions « vulgaires » comme le droit. Désormais, l'IETF est rattrapée par la judiciarisation croissante de la société, surtout aux ÉUA, où se trouve la majorité des structures formelles qui comptent pour l'IETF (notamment l'ISOC, l'IETF elle-même restant informelle et non enregistrée). Avec l'enthousiasme des néophytes, une partie de l'IETF s'est donc engagée dans la voie d'un travail sur les questions de propriété intellectuelle (un terme d'ailleurs très contestable, puisque mêlant des choses aussi différentes que le droit d'auteur, les brevets et le droit des marques). Ce RFC décrit les « droits entrants », c'est-à-dire ceux dont l'IETF a besoin, et qui doivent lui être accordés par les participants aux travaux et notamment par les auteurs de RFC (la convention de Berne faisant que les auteurs ont automatiquement certains droits sur leur œuvre).

Si des notions de « propriété intellectuelle » apparaissaient déjà dans le RFC 2026 en octobre 1996, le premier RFC fournissant un cadre complet à ces questions a été le RFC 3667 en février 2004, remplacé par le RFC 3978 puis par notre RFC 5378. Le principal changement (section 10) est la séparation plus claire entre les droits « entrants » (ce que le contributeur donne à l'IETF) et les droits « sortants » (ce que l'IETF donne aux utilisateurs), décrits dans le RFC 5377.

Ce dernier RFC, écrit par un « grand ancien » de l'IETF (dont l'activité récente est essentiellement consacrée aux questions de propriété intellectuelle) et un avocat (qui, logiquement, pousse toujours l'IETF vers d'avantage de judiciarisation), est donc la version actuelle de la politique de l'IETF. Il détaille les droits que les contributeurs (participants au processus IETF) doivent transmettre à l'IETF trust, l'organisme (largement indépendant de l'IETF et étroitement contrôlé par l'ISOC et CNRI) qui est censé administrer la propriété intellectuelle de l'IETF (voir RFC 4748).

L'IETF trust ne peut en effet pas donner aux utilisateurs des RFC des droits qu'il n'a pas lui-même reçu. Pour pouvoir distribuer un RFC, le traduire, ou en extraire des parties, les droits automatiquement donnés par l'auteur (comme le droit de citation ou comme le fair use) ne suffisent pas. Il faut que les auteurs donnent explicitement d'avantage de droits.

La section 5 décrit les droits en question. 5.3 porte sur les droits donnés à l'IETF trust : droits de publication (évidemment), de traduction, d'utilisation des marques que contient le document, etc. 5.5 explique que ces droits n'impliquent pas de licence d'utilisation des technologies présentées dans le RFC (l'IETF, contrairement au W3C ou, dans certains cas, à OASIS, accepte de normaliser des technologies brevetées).

Pour que tout le monde puisse connaître ses droits, la section 6 explique le mécanisme de publication de ceux-ci par le biais d'un boilerplate, officiellement appelé legend. Ce boilerplate, un texte légal attaché à chaque RFC, ne figure pas dans notre RFC 5378. En effet, l'évolution des lois états-uniennes, les changements d'interprétation, peuvent nécessiter une évolution du texte, alors qu'un RFC n'est pas facile à changer. L'IETF trust reçoit donc un quasi-chèque en blanc pour rédiger le texte en question et le tenir à jour sur son site Web (c'est le second grand changement par rapport au RFC 3978).

La section 3 du RFC explique le raisonnement derrière les choix effectués. Par exemple, 3.3 explique que l'auteur doit donner le droit de faire certaines modifications (derivative works) car l'IETF doit pouvoir faire évoluer le RFC suivant l'évolution de la technologie. Elle explique aussi pourquoi cette règle peut comporter des exceptions, par exemple lorsque l'IETF re-publie sous forme de RFC une norme d'une autre organisation.

Une fois les droits de publication, et de modification, offerts par le(s) auteur(s) d'un RFC à l'IETF trust, quels droits ce dernier va t-il transmettre aux lecteurs d'un RFC ? Le RFC 5378 spécifiait les droits « entrants » à l'IETF trust, et notre RFC 5377 spécifie les droits sortants : que puis-je faire avec un RFC ? Ai-je le droit de le lire ? De le redistribuer ? De le traduire ?

Pendant longtemps, l'IETF avait été réputée plus généreuse que les autres SDO car ses RFC étaient distribués librement (alors que l'ISO ou l'ITU faisaient payer une somme considérable, qui n'était même pas justifiée par les frais de distribution puisque ces dinosaures interdisaient la reproduction et la redistribution). Mais les temps ont changé : d'autres SDO ont suivi ce chemin, à commencer par le W3C, certaines organisations traditionnelles se sont ouvertes, comme l'ITU. L'IETF est désormais dans la moyenne, plus ouverte que l'ISO mais beaucoup moins que le W3C ou OASIS.

Compte-tenu de cette tendance à l'ouverture, et du développement du logiciel libre, accompagné d'un mouvement en faveur de formats ouverts, l'IETF devait donc libéraliser sa politique de licence, qui était spécifiée dans le RFC 3979. Celle-ci spécifiait notamment que les RFC étaient distribués et redistribués librement mais que toute modification était interdite. Ce problème n'était pas purement théorique : du texte issu de RFC se retrouve souvent verbatim dans des documentations de logiciel ou dans des manuels en ligne comme la page getaddrinfo (RFC 3493) sur beaucoup d'Unix. Le texte du RFC n'étant pas modifiable, ce logiciel devenait non libre. Pire, les RFC comportent souvent du code (définitions des MIB, exemples de code, schémas XML, implémentation du protocole, etc) et celui-ci n'était pas non plus modifiable et ne pouvait donc pas être inséré dans un logiciel libre !

Il était donc nécessaire de libéraliser. Mais une partie de la « vieille garde » de l'IETF s'est opposé à toute évolution et ce RFC 5377 ne représente donc finalement qu'une libéralisation très modérée. La principale innovation par rapport au RFC 3979 est la séparation du RFC entre code et texte, avec des règles différentes, plus ouvertes pour le code.

La section 1 du RFC rappelle un point important : c'est désormais l'IETF trust qui décide. Le RFC 5377, publié par l'IETF, n'est qu'indicatif et ne fixe que des grands principes. Le texte exact de la licence des RFC est écrit par l'IETF trust (http://trustee.ietf.org/license-info/.) La section 2 revient d'ailleurs sur les raisons de ce choix (pouvoir s'adapter aux changements légaux aux ÉUA, pays de l'IETF trust et de l'ISOC).

On pourra trouver ce texte standard, ce boilerplate, sur le site du Trust.

La section 2 du RFC décrit les buts que suit l'IETF en publiant des RFC (cf. RFC 3935). Clairement, l'élaboration d'une licence doit se faire en gardant ces buts à l'esprit : faire fonctionner l'Internet le mieux possible.

La section 3 explique l'articulation de ce RFC avec le RFC 5378 : les droits sortants (ceux que l'IETF trust accorde aux utilisateurs) doivent être inférieurs ou égaux aux droits entrants (ceux que l'auteur a accordé à l'IETF trust). Autrement dit, l'IETF ne peut pas donner de droits qu'elle n'a pas. Si l'auteur d'un RFC interdit toute modification à son texte, le RFC publié ne permettra pas de modifications (et ne pourra d'ailleurs pas être publié sur le chemin des normes).

La section 4 s'attaque aux droits que l'IETF trust devrait donner aux utilisateurs :

• Droit de publier et de republier (section 4.1), une très ancienne politique de l'IETF,
• Droit (évidemment) d'implémenter la technique décrite dans le RFC (section 4.3). C'est ici qu'apparait la distinction entre code et texte. Par un mécanisme qui reste à spécifier (par l'IETF trust), le code sera marqué spécialement et l'implémenteur aura d'avantage de droits sur le code, notamment le droit de modification. Cela ne résoud pas, et de loin, tous les problèmes. Par exemple, cela ne permet pas de modifier du texte d'un RFC qui est inclus dans la documentation d'un logiciel.
• Droit de modifier le texte ? Non, ce droit est exclu par la section 4.4. La montagne a donc accouché d'une souris : si ce RFC représente une libéralisation, elle reste très modérée et limitée au code.

Les discussions sur le groupe de travail IPR ont été longues et passionnées. Elles opposaient surtout la vieille garde IETF, attachée à ne rien changer et effrayée par les changements survenus avec le développement du logiciel libre, mais aussi du Web (avec ses mashups, son Wikipédia et autres preuves de l'importance du droit de modification) aux partisans du logiciel libre comme Simon Joseffson ou Lawrence Rosen. Notons que Joseffson a écrit quatre RFC, comportant souvent du code. Je cite ce point car un des arguments les plus vicieux d'un débat qui en a compté beaucoup était que les partisans d'une libéralisation n'avaient jamais écrit de RFC et donc devaient se taire !

Pourquoi donc cet acharnement à refuser les modifications ? La raison la plus souvent invoquée était le désir d'éviter l'apparition de « RFC non officiels », incompatibles avec les « vrais », qui pourraient semer la confusion. Ainsi, un « méchant » pourrait créer un document mettant à jour le RFC 5321 en remplaçant EHLO par GDAY. Outre que cette « attaque » reste très théorique, plusieurs participants ont fait remarquer que les nouvelles règles ne l'empêchent pas et que la seule protection contre ce genre de problèmes serait dans le droit des marques, par exemple en faisant déposer la marque RFC pour empêcher le document du méchant de se présenter comme RFC. Or, ce point n'a jamais été considéré...

Notons enfin que beaucoup de participants à l'IETF n'ont pas du tout suivi ce qui se passait dans ce petit groupe, en général par manque d'intérêt pour les questions politiques et juridiques.

La série de RFC sur MIME, qui a introduit les caractères composés (et les écritures non-latines), ainsi que les objets multimédia, dans le monde du courrier électronique, comprend, entre autres, ce RFC qui normalise une méthode pour mettre des caractères non-ASCII dans les en-têtes du courrier, ces méta-données situées avant le corps du message et structurées en nom: valeur.

Normalement, le courrier, tel qu'il était normalisé par le RFC 822 (aujourd'hui RFC 5322), ne permettait que le jeu de caractères ASCII dans les en-têtes. C'est ainsi qu'il fallait écrire :

From: Stephane Bortzmeyer <bortzmeyer@sources.org>
Subject: Du cafe bien fort !

au lieu de la forme correcte en français :

From: Stéphane Bortzmeyer <bortzmeyer@sources.org>
Subject: Du café bien fort !

Notre RFC 2047 vise tout simplement à fournir une solution à ce problème, en encodant les caractères non-ASCII, en Quoted-Printable ou en Base64. Les en-têtes ci-dessus apparaitront donc sur le réseau comme :

From: =?iso-8859-1?q?St=E9phane?= Bortzmeyer <bortzmeyer@sources.org>
Subject: Du =?iso-8859-1?q?caf=E9?= bien fort !

Ainsi, le message pourra passer à travers toute l'infrastructure du courrier qui n'accepte que l'ASCII. Ce sera au MUA de les remettre sous une forme lisible (voir par exemple mon article Décoder les en-têtes du courrier électronique).

L'approche de notre RFC est donc conservatrice : on ne demande pas à tous les logiciels sur le trajet de connaître MIME, autrement ce dernier n'aurait jamais été déployé. (MIME n'utilise même pas, par prudence, certaines fonctions du RFC 822 qui auraient pu aider mais qui sont trop souvent boguées, cf. section 1.) Aujourd'hui où l'infrastructure du courrier est très différente, une méthode plus radicale pourrait être réaliste et c'est l'approche du bien plus récent RFC 5335.

La section 2 du RFC donne la grammaire exacte : un terme encodé est précédé de =? suivi de l'encodage des caractères. (Pour le corps du message, tel que normalisé dans le RFC 2045, l'encodage est indiqué dans un en-tête, Content-Type. Pour les en-têtes eux-mêmes, il a fallu trouver une autre solution.) Puis on trouve le surencodage appliqué par MIME, Q pour Quoted-Printable et B pour Base64 puis le terme lui-même, ainsi encodé. Le tout est terminé par un ?=. Voici le résultat, produit par un programme Python avec le module email :

% python
>>> from email.header import Header
>>> h = Header('niçoise', 'iso-8859-1')
>>> print h
=?iso-8859-1?q?ni=E7oise?=

Notons que l'encodage utilisé est appelé charset (jeu de caractères) par MIME, ce qui n'est pas vraiment le terme correct (« utf-8 » est un encodage, le jeu de caractères est Unicode). La section 3 normalise ce paramètre, pour lequel les valeurs standard de MIME sont utilisées.

La section 4 décrit en détail les surencodages possibles, Quoted-Printable et Base64. Le premier (RFC 2045) convient mieux lorsque le texte comprend des caractères latins, avec quelques caractèrs composés. Le second (RFC 4648) est préférable si le texte est composé de caractères non-latins. La section 4.2 détaille quelques spécificités de Quoted-Printable et notamment l'utilisation du _ à la place de l'espace comme dans :

% python
>>> from email.header import Header
>>> h = Header("réveillés dans une Citroën niçoise", "ISO-8859-1")
>>> print h
=?iso-8859-1?q?r=E9veill=E9s_dans_une_Citro=EBn_ni=E7oise?=

Pour le même genre de tâches, les programmeurs Perl peuvent utiliser Encode::MIME::Header.