Mon blog

Quels que soient les progrès des technologies, il n'y a jamais assez de capacité. Même aujourd'hui, les vieux modems restent en service (y compris dans un pays riche, mais étendu, comme les États-Unis) et certaines technologies récentes offrent une capacité limitée (par exemple sur les téléphones mobiles). Il est donc utile de pouvoir comprimer les données et aussi les en-têtes des paquets émis, qui sont souvent très redondants, ouvrant ainsi de bonnes perspectives pour la compression. Plusieurs mécanismes de compression ont été inventés et le projet ROHC (Robust Header Compression) a été créé pour mettre de l'ordre dans ces mécanismes, en développant un cadre commun. Ce RFC spécifie ce cadre.

La section 1 du RFC, l'introduction, donne quelques chiffres sur les gains qu'on peut tirer de la compression. Par exemple, si on utilise RTP (RFC 3550) pour transporter de la voix sur IP, il faudra transporter les 40 octets de l'en-tête (en IPv6), les 12 octets de l'en-tête UDP et les 8 octets de l'en-tête RTP (sans compter les en-têtes de la couche liaison). Ainsi, un paquet de données de 20 octets (une taille courante en voix sur IP) pourrait nécessiter 60 octets d'en-têtes TCP/IP.

Le RFC originel sur ROHC était le RFC 3095 qui incluait à la fois le cadre général et les profils de compression pour certains protocoles (un profil est un protocole de compression donné, adapté à un certain protocole). Une réforme générale de ROHC a eu lieu et il est désormais normalisé dans plusieurs RFC, notre RFC 4995, à l'origine, pour le cadre général, les RFC 4996 et RFC 5225 pour des profils pour, respectivement, TCP et les protocoles sans connexion comme IP ou UDP, le RFC 4997 pour le langage formel de définition des compressions, etc. (Le RFC 3095 n'est pas officiellement abandonné puisque le protocole est le même, il est juste mieux décrit.) Depuis, le RFC 5795 est sorti, remplaçant notre RFC 4995 en corrigeant quelques bogues.

La section 3 du RFC décrit les bases de la compression. Le principe est que le compresseur ne transmette pas certaines informations, car elles n'ont pas changé, ou bien peuvent être déduites automatiquement. Cela implique que le décompresseur puisse se souvenir de l'état de la compression, ce que ROHC nomme le contexte (la section 2.2 décrit toute la terminologie). Le maintien de ce contexte, même en présence de perturbations sur le réseau, est le principal défi de la compression. Sur des liens de mauvaise qualité (par exemple avec beaucoup de pertes), les mécanismes de compression pré-ROHC se comportaient plutôt mal (voir aussi la section 1).

Naturellement, rien n'est gratuit : le gain en capacité du réseau sera obtenu au détriment de la puissance de calcul, puisque compression et décompression nécessitent des calculs. La vitesse des processeurs des téléphones portables augmentant plus vite que leur capacité réseau, le choix de la compression semble raisonnable.

La section 3.2 rappelle l'histoire de la compression. Le premier grand travail dans le monde TCP/IP avait été la compression des en-têtes TCP par Van Jacobson en 1990 (RFC 1144), dont tous les utilisateurs de SLIP dans les années 1980 et 90 se souviennent (« Tu es sûr d'avoir activé la compression VJ ? »).

La section 4 décrit de manière relativement informelle le fonctionnement de ROHC, notamment (section 4.1), les différentes classes de changement dans les en-têtes, qui permettent leur prédiction par le décompresseur. Ainsi, la classe STATIC décrit les informations qui ne changent pas pendant la durée du flux de données (le numéro de version IP par exemple), la classe INFERRED étant composée des en-têtes qui peuvent se déduire ou se calculer à partir d'autres informations (comme la taille du paquet).

La vraie définition de ROHC est en section 5. C'est là qu'on trouve, par exemple, la description du mécanisme de rétroaction (section 5.2.4) qui permet au décompresseur de tenir le compresseur au courant du succès (ou de l'échec) de son travail. Autre exemple (section 5.1.2), chaque canal de communication ROHC a, parmi ses paramètres, un identificateur du profil utilisé (la liste des identificateurs possibles est dans un registre IANA, voir également la section 8). La section 5.4 normalise ainsi le profil d'identificateur 0x0000, le profil qui ne fait rien (en oubliant une partie, ce qui a été corrigé dans le RFC 5795), les profils « actifs » étant définis dans d'autres RFC.

Des déploiements de ROHC sont déjà faits dans les téléphones portables. Il existe une implémentation libre, RObust Header Compression (ROHC) library (merci à Didier Barvaux pour cela), tirée d'une plus ancienne bibliothèque. La section 6 du RFC 3095 contient une excellent section sur les problèmes concrets de mise en œuvre de ROHC (section qui ne semble pas avoir été reprises dans les RFC plus récents).

De même qu'il existe des adresses IP et des noms de domaine réservés à la documentation, les numéros d'AS de 64496 à 64511 et de 65536 à 65551 sont désormais réservés pour les auteurs des documentations sur le routage.

Écrire un cours sur le routage (comme mon cours BGP) nécessite de choisir les numéros d'AS qui apparaitront. Prendre des numéros existants est risqués car il y aura toujours un distrait pour copier-coller les configurations de routeurs qu'il a lu dans le cours, créant ainsi des problèmes avec l'AS qui a ce numéro.

Le même problème existe pour les adresses IP (d'où la réservation de 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24, dans le RFC 5737 ou de 2001:DB8::/32 dans le RFC 3849) ou pour les noms de domaine (pour lesquels .example a été réservé par le RFC 2606).

Comme le rappelle la section 1, même les numéros privés (pour les AS, de 64512 à 65534) ne conviennent pas puisqu'ils sont utilisés en production dans certains réseaux. C'est donc logiquement que notre RFC réserve deux plages de seize numéros d'AS pour la documentation : de 64496 à 64511 pour les AS sur deux octets et de 65536 à 65551 pour les AS sur quatre octets (ces derniers ayant été introduits par le RFC 4893, depuis remplacé par le RFC 6793).

Le programme traceroute est un des piliers de l'Internet. Cet outil de débogage a servi à des dizaines de milliers d'administrateurs réseaux, lors de difficiles sessions de recherche de panne ou de divers problèmes. Né de la nécessité, il n'a jamais eu de modèle de données formel, ni de norme de présentation des résultats. C'est désormais fait avec ce nouveau document.

Cette normalisation permet notamment de stocker les résultats d'un traceroute et de les comparer de manière automatique à un autre (il existe déjà de tels programmes de comparaison, par exemple sous forme d'un moniteur pour le logiciel de surveillance réseau mon, mais tous ne comparent que la sortie texte de traceroute et peuvent donc être perturbés par des changements purement de présentation). La section 1 détaille ce cahier des charges.

La section 3 rappelle le principe de fonctionnement de traceroute : envoyer des paquets UDP (certaines versions peuvent utiliser TCP ou ICMP ; l'annexe A contient une très intéressante description des différentes versions de traceroute) à une machine distante, en mettant délibérement des valeurs trop basses au TTL (ou Hop Count) des paquets IP. Les routeurs qui, après la décrémentation de ce champ, trouveront zéro, signaleront leur existence en envoyant un paquet ICMP TIME_EXCEEDED (RFC 792).

La section 4 liste ensuite les résultats qu'on obtient avec traceroute. Selon la version de ce dernier, on peut trouver :

• L'index du routeur dans le chemin,
• Son adresse IP,
• Le RTT,
• Les labels MPLS (RFC 4950),
• etc.

Enfin, la section 5 définit le modèle de données utilisé pour créer le fichier XML de résultats. 5.1 contient les types de données. Certains sont tirés des schémas du W3C comme Boolean ou DateTime, d'autres tirés d'autres RFC (par exemple le RFC 4001 pour InetAddress, les adresses IP), d'autres enfin définis ici. La section 5.2 donne la liste de tous les élements XML utilisés comme ProbeRoundTripTime (section 5.2.3.8) qui contient le RTT en millisecondes. On peut donc écrire :

<ProbeRoundTripTime>
   <roundTripTime>13</roundTripTime>
</ProbeRoundTripTime>

Cet élement ProbeRoundTripTime peut, alternativement, contenir un élément roundTripTimeNotAvailable.

La section 6 explique le choix de XML, notamment parce que les fichiers XML sont lisibles par un humain et parce qu'il existe un grand nombre d'outils existants. Cette section explique aussi pourquoi des modèles de données proches comme la MIB du RFC 4560 (également discutée en annexe C) ou l'encodage d'IPFIX dans le RFC 7011 n'ont pas été utilisés.

Enfin, une longue section 7 contient le schéma lui-même, défini avec le langage W3C Schema. L'élément ProbeRoundTripTime cité plus haut est ainsi défini comme le choix entre un entier ou la valeur roundTripTimeNotAvailable :

    <xs:element name="ProbeRoundTripTime"
                                 type="_roundTripTime">
    </xs:element>

    <xs:complexType name="_roundTripTime">
       <xs:choice>
  
       <xs:element name="roundTripTime">
           <xs:simpleType>
             <xs:restriction base="xs:unsignedInt"/>
           </xs:simpleType>
         </xs:element>

         <xs:element name="roundTripTimeNotAvailable">
           <xs:complexType/>
         </xs:element>

       </xs:choice>
     </xs:complexType>

Je ne connais pas encore d'implémentation « officielle » de traceroute qui produise ces fichiers XML. Si vous en écrivez une, attention aux caractères spéciaux (speciaux pour XML comme & ou <) dans les noms de machines : rien ne vous garantit qu'une requête DNS inverse ne va pas vous renvoyer des noms avec de tels caractères. Comme toujours quand un programme produit du XML, il ne doit pas se contenter de mettre des <balise> un peu partout, il doit aussi veiller à ces caractères spéciaux.

Il existe à ma connaissance une mise en œuvre expérimentale de traceroute qui produit du XML à ce format (dérivée du traceroute de NANOG). Elle est assez sommaire mais elle marche. traceroute-nanog-xml.c.

Il nécessite libxml2. Pour le compiler, sur GNU/Linux :

cc -DXML -lresolv  $(xml2-config --cflags) $(xml2-config --libs) \
             traceroute-nanog-xml.c -o traceroute-nanog-xml

Sur FreeBSD, même chose sans le -lresolv. Ensuite, on ne lance avec l'option -X pour produire du XML.

Une fois produits, les fichiers XML peuvent être vérifiés, par exemple avec xmllint :

% xmllint --noout --schema traceroute.xsd traceroute.xml
traceroute.xml validates

Voici des exemples de résultats stockés dans ce format, un exemple pris dans le RFC (annexe D) et un autre exemple, produit par mon programme.

Après de très longs débats, ce RFC normalise enfin un format pour représenter les numéros de systèmes autonomes de 32 bits. Ils seront affichés dans la notation ASPLAIN, c'est-à-dire sans séparateur interne, par exemple 101234.

Depuis que le RFC 4893, en mai 2007, avait normalisé les numéros de systèmes autonomes sur quatre octets (donc potentiellement supérieurs à 65536), le débat faisait rage, dans la communauté des opérateurs Internet, sur la meilleure représentation textuelle à leur donner. Deux solutions s'affrontaient pour écrire le numéro 101234 : celle qui l'a emportée, nommée ASPLAIN, où le numéro était écrit sans séparateur interne, et une première solution, ASDOT, où on écrivait le numéro en deux parties séparées par un point, ici 1.35698 (1 * 65536 + 35698). La méthode ASPLAIN convenait mieux aux programmes, ASDOT était préféré par les humains.

Il y avait aussi une méthode ASDOT+ où même les numéros inférieurs à 65536 étaient écrits en deux parties, 20768 se notant 0.20768. ASDOT avait semblé avoir le vent en poupe d'abord, mais avait échoué devant l'IESG.

La crainte des adversaires d'ASDOT était que beaucoup de programmes écrits pour gérer les routeurs (car un gros opérateurs ayant des centaines de Juniper ou de Cisco n'édite évidemment pas les centaines de configurations depuis une interface Web, il a un programme pour cela), des gros scripts Perl ou équivalent, n'aient pas été prévus pour des points au milieu d'un numéro d'AS... Pour prendre un exemple cité par Philip Smith :

Well, here is a regexp from a router I have with IOS-XR, just to show how the . notation impacts regexp work:

as-path-set 4byte-asn
   ios-regex '_2\.0_.*_[0-9]+\.[0-9]+_',
   ios-regex '_5\.1_',
end-set

This basically says:

• "from AS2.0 accept prefixes with 32-bit ASNs in the AS path"
• "from AS5.1 accept just prefixes originated by AS5.1"

I'm sure some ISPs around here must have similar 16-bit ASN regexps in use at the moment. To handle 32-bit ASNs, they'll need to convert all these to escape the "." as I did above...

Voir aussi http://www.swissix.ch/asn32/doku.php pour d'autres débats sur la question.

Notre RFC 5396 tranche donc en faveur d'ASPLAIN. C'est ce format qui sera utilisé dans la configuration des routeurs, dans les discussions sur les listes de diffusion d'opérateurs comme NANOG, ou dans les IRR par exemple au RIPE-NCC (qui avait failli développer sa propre politique, vue la difficulté de l'IETF à décider). Comme le note la section 3 du RFC, cette notation a l'avantage de refléter l'absence de structure interne du routage BGP (la notation ASDOT pouvait faire croire à une hiérarchie).

Voici un RFC qui s'adresse à l'administrateur système plutôt qu'au développeur. Il s'agit d'expliquer deux ou trois choses sur l'affectation des adresses IPv6 aux machines du réseau local, afin d'aider à la création d'un plan d'adressage.

Les principes de base de l'adressage IP sont décrits dans le RFC 4291. Une adresse est composée de deux parties, celle qui identifie le réseau et celle qui identifie l'interface de la machine, l'interface ID.

La section 1 du RFC rappelle les principales différences avec IPv4 :

• Il est plus courant d'avoir plusieurs adresses par machine,
• La taille de l'espace d'adressage fait qu'il n'est typiquement pas nécessaire de faire des économies.

La section 2 s'attaque ensuite à l'adressage de la partie réseau (le préfixe), que ce soit pour les adresses uniques mondialement (section 2.1) ou bien pour les adresses de site du RFC 4193 (section 2.2). Le gros morceau est en 2.4, qui détaille les bénéfices qu'on peut tirer du vaste espace d'adressage IPv6. Des schémas d'adressage « créatifs », par exemple où le préfixe est dérivé du numéro du VLAN sont désormais possibles. La croissance future du réseau peut être permise en laissant des trous dans l'allocation comme l'explique un excellent document, le RFC 3531.

La taille des préfixes est à étudier : le RFC 3177 posait comme principe l'affectation d'un /48 à chaque site, quel que soit sa taille, notamment pour éviter les problèmes en cas de rénumérotation. Mais la section 2.4.2 parle des problèmes d'économie d'adresses v6 (cf. RFC 3194). Et le RFC 6177 ne fait plus de recommandation unique.

La section 3 est dédiée à la question de la taille du préfixe d'un lien donné. Contrairement à IPv4 où on dispose d'une liberté complète, IPv6 suppose un préfixe de lien de /64 (RFC 4291, section 2.5.4). Choisir une autre valeur est théoriquement possible, mais casserait plusieurs protocoles importants comme SEND ou comme les adresses temporaires du RFC 8981. Pire, cela pourrait limiter le déploiement de futurs protocoles qui auraient eux-aussi besoin de 64 bits pour les adresses des machines. (Voir aussi l'annexe B.1 et B.2 ; on y trouve une exception pour les liens point-à-point entre deux routeurs, où un /126 est acceptable, mais pas un /127.)

Ensuite, les adresses des machines sur le lien peuvent être attribuées par plusieurs méthodes (section 4) :

• Auto-configuration sans état (RFC 4862), section 4.1
• Adresses anti-traçage du RFC 8981, section 4.2
• Adresses attribuées manuellement, section 4.3. Dans ce cas, il faut veuiller à ce que les adresses n'entrent pas en conflit avec des adresses bien connues, comme par exemple l'adresse « tout à zéro » qui identifie normalement les routeurs du lien (annexe B.2.5.1). Il faut également veiller à ce que le bit 'u' de l'adresse, le 71ème bit, soit à 0 et le bit 'g', le 72ème, également. En pratique, à l'heure actuelle, se tromper sur ces deux bits n'a pas de conséquences mais cela pourrait en avoir dans le futur (cf. annexe B.2.4). Donc, 2001:DB8:CAFE:1::1 est correct (les deux bits sont à zéro) mais pas 2001:DB8:CAFE:1:0200::1 (le bit 'u' est à un, dans le groupe 0200).

Deux études de cas concrètes, en annexe A, rendent ce RFC un peu plus facile à lire.

Le protocole IRIS d'accès aux informations dites « sociales » qui sont stockées dans un registre, par exemple un registre d'adresses IP, est défini indépendemment du schéma des données stockées. Il faut donc le compléter, pour chaque registre, par un schéma indiquant comment sont structurées les données. Notre RFC le fait pour les registres de noms de domaine.

Comme tous les schémas IRIS, ce document utilise le langage W3C Schema pour spécifier les éléments XML qui peuvent être présents dans les requêtes au serveur IRIS et dans ses réponses. Le schéma a reçu le nom de DREG (Domain Registry). La section 3 liste en langue naturelle les éléments possibles de DREG, la section 4 contenant le schéma formel.

Par exemple, l'élément <findDomainsByName> (section 3.1.3) permet des interogations analogues à celles de whois en interrogeant le registre sur les données liées à un domaine dont on connait le nom.

Mais il contient aussi des requêtes qui ne sont pas possibles avec tous les serveurs whois comme <findDomainsByContact> (section 3.1.2) qui permet de retrouver tous les domaines d'une personne ou d'une organisation donnée (très intrusive, cette requête ne sera probablement jamais disponible publiquement).

Et les réponses ? La section 3.2.2 décrit la forme d'un élément <domain>. Cet élément contient les informations associées à un domaine comme ses serveurs de noms, sa date de création ou son état (status). Les états possibles sont énumérés, on y trouve, par exemple, reservedDelegation (réservé mais pas publié dans le DNS, un état qui n'existe pas aujourd'hui dans .fr mais qui peut être présent dans d'autres TLD).

Il faut noter que la liste des états possibles n'est pas la même qu'avec EPP (RFC 4931), cela serait trop simple...

D'autres types d'objet peuvent être stockés par le registre et interrogés via IRIS, comme les contacts (les personnes ou organisations responsables d'un domaine), traités en section 3.2.4.

Ce schéma DREG ne semble pas encore utilisé dans aucun serveur IRIS publiquement accessible.

Emprunté à l'annexe A du RFC, voici un exemple de requête IRIS/DREG :

<?xml version="1.0"?>
<request xmlns="urn:ietf:params:xml:ns:iris1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
  <searchSet>
    <lookupEntity
      registryType="urn:ietf:params:xml:ns:dreg1"
      entityClass="domain-name"
      entityName="example.com" />
  </searchSet>
</request>

et la réponse possible d'un serveur IRIS :

<?xml version="1.0"?>
<iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <iris:resultSet>
    <iris:answer>
      <domain xmlns="urn:ietf:params:xml:ns:dreg1"
        authority="iana.org" registryType="dreg1"
        entityClass="domain-handle" entityName="example-com-1">

        <domainName>example.com</domainName>
        <domainHandle>tcs-com-1</domainHandle>

        <nameServer iris:referentType="host" authority="iana.org"
          registryType="dreg1" entityClass="host-handle"
          entityName="research7" />
        <nameServer iris:referentType="host" authority="iana.org"
          registryType="dreg1" entityClass="host-handle"
          entityName="nsol184" />

        <technicalContact iris:referentType="contact"
          authority="iana.org" registryType="dreg1"
          entityClass="contact-handle" entityName="dbarton" />

        <status>
          <assignedAndActive denied="true" />
        </status>

        <registry iris:referentType="registrationAuthority"
          authority="com" registryType="dreg1"
          entityClass="contact-handle" entityName="VGRS" />
        <initialDelegationDateTime xsi:nil="true"/>
        <iris:seeAlso iris:referentType="ANY" authority="iana.org"
          registryType="dreg1" entityClass="local"
          entityName="notice"  />
      </domain>
    </iris:answer>
  </iris:resultSet>
</iris:response>

Comment sont développées les normes Internet ? Qui les décide ? Comment les changer ? Ce RFC repond à toutes ces questions, en décrivant le processus de normalisation dans l'Internet. Bien sûr, comme pour beaucoup de processus sociaux, la réalité est parfois très éloignée de la description...

La plupart des normes techniques qui régissent l'Internet sont écrites dans des RFC (l'inverse n'est pas vrai : beaucoup de RFC ne sont pas des normes). Ces RFC de normalisation sont développés au sein de l'IETF et on peut trouver une description des activités de l'IETF dans mon exposé IETF à JRES.

Certains RFC ne décrivent pas un protocole ou un format mais des règles à suivre lors du développement des normes et c'est le cas de ce RFC. Son introduction rappelle que toute cette activité se déroule sous la responsabilité de l'ISOC (l'IETF n'est qu'une étiquette, elle n'a pas de personnalité juridique).

La section 1 résume les grands principes : il n'existe pas de « police des normes » (section 1.1) qui ferait respecter les RFC, la conformité à ces normes est volontaire (une norme industrielle n'est pas une loi). Et les normes Internet sont censées représenter une technique qui fonctionne, qui est bien comprise et pour laquelle existent au moins deux mises en œuvre interopérables (contrairement à une légende très répandue, il n'est pas exigé qu'une de ces mises en œuvre soit libre).

Le processus d'élaboration des normes lui-même est résumé en section 1.2. Il est ouvert à tous, est pratiqué par « la communauté » (community, mot fourre-tout dans le discours politique états-unien, qui n'est jamais clairement défini et qui exprime surtout la nostalgie du petit village fermé et regroupé autour de son église) et vise à obtenir un consensus de toutes les parties prenantes. Les procédures de ce RFC doivent être honnêtes, ouvertes et objectives. (Oui, la langue de bois est très présente dans ce RFC.)

Le RFC explique bien la difficulté de la normalisation dans un monde qui évolue aussi vite que celui des réseaux informatiques. La normalisation est forcément lente, à la fois pour des raisons sociales (construire le consensus) et techniques (écrire une norme correcte est un travail difficile), alors que la technique bouge très vite.

La section 2 décrit les documents qui sont produits par le processus de normalisation. Il commence évidemment (section 2.1) par les RFC. Ces textes, bien mal nommés (RFC voulait dire Request For Comments, ce que ne reflète plus leur statut et leur stabilité ; mais le nom est resté) existent depuis très longtemps (le RFC 1 a été publié en avril 1969). Ils sont largement et gratuitement disponibles (pendant longtemps, cela a été une des spécificités de ces normes, et une des raisons du succès de TCP/IP par rapport aux technologies concurrentes). Ils sont publiés par un organisme séparé, le RFC editor. C'est lui qui définit les règles (assez archaïques) de format, le texte brut, obligatoire pour les RFC qui ont le statut de norme.

Car ce n'est pas le cas de tous les RFC. Les normes proprement dites ne sont qu'un sous-ensemble des RFC. Dans l'index, on les reconnait au texte STDnnn qui indique leur numéro dans la série des normes (STanDard ; par exemple, UDP, RFC 768 est STD0006). D'autres RFC n'ont pas ce statut et peuvent être publiés par le RFC editor seul, sans implication de l'IETF. C'est un point important, souligné par le RFC 1796 : Not All RFCs are Standard.

Mais les RFC ne naissent certainement pas tout armés ? Comment évoluent-ils et à partir de quoi ? C'est l'objet de la section 2.2, consacrée aux Internet-Drafts (on dit aussi I-D), les RFC en gestation. Un I-D n'a aucune valeur normative et notre RFC sur les normes rappelle bien qu'il est déconseillé de s'appuyer sur un I-D, par exemple pour un appel d'offres. De même, un vendeur ne devrait pas citer d'I-D dans la liste des fonctions de son produit. En effet, les I-D ne sont pas stables et peuvent changer à tout moment (en outre, même si le RFC 2026 ne le rappelle apparemment pas, n'importe qui peut écrire un I-D et le faire distribuer par l'IETF, il n'y a pas de contrôle).

La section 3 introduit une distinction qui n'a guère été utilisée entre les spécifications techniques (TS pour Technical Specifications) et les consignes d'application (AS pour Applicability Statement), qui expliquent comment appliquer les premières. Même le vocabulaire n'est pas resté et les sigles TS et AS ne semblent plus utilisés à l'IETF.

La section 4 en arrive au chemin des normes (standards track, la route que suivent les RFC vers le nirvana du statut de « norme au sens strict »). À noter que cette partie a été réformée par la suite dans le RFC 6410, qui a réduit le nombre d'étapes à deux. Les détails des anciens trois statuts sont publiés dans la section 4.1. Une fois publiée en RFC, la technique qui a été lancée sur le chemin des normes a le statut de proposition de norme (proposed standard, section 4.1.1). Si tout va bien, lorsqu'elle mûrira, et que deux mises en œuvre distinctes existeront, un nouveau RFC sera publié, avec le statut de projet de norme (draft standard, section 4.1.2). Enfin, après de longs efforts, des tests d'interopérabilité et pas mal d'actions de lobbying, un dernier RFC sera publié, avec le statut de norme au sens propre (Standard ou Internet Standard ou Full Standard, section 4.1.3). C'est par exemple ce qui est arrivé au format ABNF, proposition de norme dans le RFC 2234, projet de norme dans le RFC 4234 et désormais norme complète dans le RFC 5234 (voir la section 6.2 pour des détails, notamment de délais obligatoires). Par contre, si l'expérience montre qu'une technique a des failles et qu'il faut modifier la spécification de manière non triviale, on repart de zéro (section 6.3).

Mais il faut noter que ces trois statuts ne correspondent pas toujours à la réalité. Des techniques très employées sont restées au statut de proposition (par exemple Sieve, RFC 5228), d'autres ont le statut de norme alors qu'elles ne sont plus utilisées (comme chargen du RFC 864). Il faut donc prendre ce classement avec prudence. (Je me souviens d'une réunion où une juriste d'un gros FAI, assez ignorante de tout ce qui concerne la normalisation, avait défendu leur politique de filtrage du courrier en ergotant sur le fait que le RFC 2821 n'était que proposition de norme...) C'est entre autre pour cela que le RFC 6410 a par la suite réduit le nombre de statuts possibles à deux.

Il existe aussi de nombreux RFC qui ne sont pas du tout sur le chemin des normes (section 4.2). C'est le cas des RFC « expérimentaux » (section 4.2.1), statut normalement réservé aux protocoles pas vraiment mûrs et sur lesquels il n'existe pas encore de consensus sur leur inocuité. Ce statut peut aussi être attribué pour des raisons politiques, comme ce fut le cas avec le RFC 4408, bloqué par la volonté de certains gros acteurs.

Le statut « pour information » (section 4.2.2) est notamment celui de tous les RFC qui ne décrivent pas un protocole ou un format mais rendent compte d'une expérience, ou formulent un cahier des charges, ou expliquent les raisons de certains choix. Pour éviter les collisions avec le travail de normalisation à proprement parler, l'IESG a son mot à dire sur ces RFC, pour pouvoir soulever d'éventuelles objections (section 4.2.3).

Enfin, le statut « historique » (section 4.2.4) revient aux RFC qui ont été officiellement considérés comme dépassés par les évolutions techniques et l'expérience acquise. C'est ainsi que, par exemple, le protocole whois++ qui devait remplacer whois, avait été normalisé dans le RFC 1913 qui, n'ayant jamais connu de déploiements significatifs, a été reclassé historique...

À noter que, de même que l'avancement d'une technique sur le chemin des normes nécessite une action délibérée de certains, le reclassement en « historique » demande que quelqu'un fasse le travail de documentation des raisons du reclassement. C'est pour cela que beaucoup de RFC sont simplement tombés en désuétude, sans même que quelqu'un se donne la peine de les faire formellement reclassifier (comme le RFC 1256).

Un statut particulier a droit à une section à lui : BCP (Best Current Practices, « Bonnes pratiques actuelles », section 5). Ces documents ne normalisent pas une technique mais une façon de l'utiliser « correctement ». Ils reçoivent également un numéro commençant par BCP. C'est ainsi que le RFC 2827, sur le filtrage des paquets trichant sur l'adresse source, est également BCP0038 et que le RFC 5226, sur la gestion des registres IANA est aussi le BCP0026. Un autre usage des BCP est de garder un pointeur vers la version actuelle de la norme. En effet, les RFC ne sont jamais modifiés mais remplacés. Si on se réfère à un RFC, on court donc le risque de pointer un jour vers un texte obsolète et il est donc recommandé d'utiliser plutôt le numéro de BCP. Par exemple, BCP0047 désignera toujours le RFC actuel sur les étiquettes de langue (actuellement le RFC 5646).

Le processus d'avancement des normes est décrit complètement en section 6. Je rappelle qu'il n'est pas automatique. Une norme n'avance pas toute seule mais seulement parce qu'un groupe de gens trouvait important de la faire avancer... et a su convaincre l'IESG (section 6.1.2).

L'IETF étant une organisation humaine et le fait de travailler sur des normes techniques ne supprimant pas les passions et les intérêts matériels, les conflits sont fréquents. Il n'est donc pas étonnant qu'il existe une section, la 6.5, sur les conflits et leur résolution. Elle détaille un mécanisme d'escalades successives. D'abord, faire appel aux présidents du groupe de travail considéré, puis au directeur de zone (une zone chapeautant plusieurs groupes), puis à l'IESG puis à l'IAB, ultime arbitre.

Il n'y a pas que l'IETF dans le monde et certaines normes très importantes sur Internet sont issues d'autres organisations (par exemple, HTML vient du W3C, Ethernet de l'IEEE et X.509 de l'UIT). La section 7 décrit donc l'interaction avec les autres SDO. Certaines normes sont qualifiées d'« ouvertes » et d'autres de « autres » mais sans que ces termes soient définis avec précision. Les normes « ouvertes » (ce terme a traditionnellement été utilisé à l'IETF de manière très laxiste, intégrant même des normes comme celles de l'ISO, qui ne sont pas publiquement accessibles) peuvent être référencées par les RFC. Les « autres » sont typiquement découragées mais peuvent être utilisées si nécessaire (section 7.1.2).

Le processus de développement des normes à l'IETF a toujours été ouvert, et les discussions elles-mêmes sont enregistrées et archivées (contrairement à l'ISO où tout, même les votes, est secret). La section 8 décrit les obligations de conservation que s'impose l'IETF.

Ce RFC 2026, dérivé du RFC 1602, lui même issu du RFC 1310, est assez ancien et c'est une autre raison pour laquelle il ne reflète pas toujours bien le processus actuel. Il a parfois été mis à jour (par exemple, sur la question des droits de propriété intellectuelle, qui était traitée en section 10, mais qui est maintenant du ressort des RFC 8721 et RFC 5378) mais de manière incomplète.

Le langage DSSSL (Document Style Semantics and Specification Language) est aujourd'hui bien oublié. Il était le langage favori de transformation de SGML. Comme j'ai utilisé ce langage pendant des années, il est temps de documenter un peu avant qu'il ne disparaisse complètement.

Un RFC un peu bureaucratique, pour détailler les mécanismes utilisés pour l'enregistrement dans les registres de l'IANA des paramètres liés au DNS. Il a depuis été remplacé par le RFC 6195 (qui à son tour a été remplacé par le RFC 6895).

Un certain nombre de paramètres, dans le DNS, sont enregistrés à l'IANA, afin de s'assurer d'une interprétation identique partout. C'est ainsi que l'IANA gère un registre des paramètres DNS où on trouve, entre autres, les types d'enregistrement (A, codé 1, pour une adresse IPv4, AAAA, codé 28, pour une adresse IPv6, LOC, codé 29, pour les positions géographiques du RFC 1876, etc). Cet espace n'étant pas de taille infinie, il faut y enregistrer de nouveaux paramètres avec prudence, selon les règles qui étaient expliquées dans le RFC 2929, que notre RFC modifie.

En effet, les règles du RFC 2929 étaient bien trop strictes à l'usage. Notamment, le processus d'enregistrement d'un nouveau type d'enregistrement était tellement pénible que beaucoup de protocoles (comme SPF à ses débuts) préféraient utiliser le fourre-tout TXT pour y mettre leurs enregistrements. Ce goulet d'étranglement était souvent cité comme un exemple typique des blocages liés à l'IETF.

Notre RFC assouplit donc les règles d'enregistrement des types de ressources DNS (les autres règles sont peu changées). Avant, il y avait deux solutions (voir le RFC 5226 pour plus d'explications), IETF Review (ex-IETF Consensus), un processus long et incertain imposant un RFC sur le chemin des normes, approuvé par l'IESG, ou Specification required, qui impose l'écriture d'une norme (pas forcément un RFC) « stable et permanente ».

Le nouveau système est plus léger (section 3.1.1) : il suffit désormais de remplir un formulaire décrivant le nouveau type d'enregistrement, de le soumettre sur la liste namedroppers@ops.ietf.org et d'attendre le jugement d'un expert, désigné parmi les noms fournis par l'IESG, qui décidera, sur la base du formulaire soumis, d'allouer ou pas la requête. Un tel processus est utilisé pour d'autres enregistrements à l'IANA, par exemple pour les nouvelles étiquettes de langue.

Le nouveau processus a été testé pour la première fois pour le type d'enregistrement ZS (Zone Status) qui a été accepté, sous un autre nom, NINFO, et figure désormais dans le registre IANA.

Notre RFC a depuis été remplacé par le RFC 6195, qui ne change que des points de détail (puis par le RFC 6895).

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. (Il a depuis été remplacé par le RFC 8085.)

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 7567), à 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, davantage 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 6347). 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.

Voilà, un rappel, ce RFC n'est plus d'actualité, il a été remplacé par le RFC 8085.

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 ou par la censure chinoise contre ses citoyens (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ésout 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.

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.

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à davantage 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 8721.

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 davantage 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 davantage 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 (on peut aussi consulter la FAQ du trust). 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.

Comme le travail a été plutôt bâclé, un gros problème n'est survenu que plus tard lorsque des auteurs se sont aperçus que le nouveau texte interdisait de réutiliser du texte d'anciens RFC... La chasse aux auteurs de ces anciens RFC a donc commencé, pour les convaincre d'abandonner leurs droits (voir l'article IETF Shoots Itself in the Foot).

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 ? (Il a depuis été remplacé par le RFC 8721.)

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 3978. 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 3978 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/ et il existe aussi une FAQ sur ces textes.) 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 non spécifié dans le RFC (cela a été choisi par la suite comme une liste publiée par l'IETF trust), le code sera marqué spécialement et l'implémenteur aura davantage de droits sur le code, notamment le droit de modification. Cela ne résout 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étadonné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 6532.

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.

Le NAT a toujours été une des plaies de l'Internet, entre autres parce qu'il perturbe les applications qui veulent transmettre une référence à leur adresse IP. STUN, décrit dans ce RFC, est un des protocoles qui permet de limiter les dégâts. (Ce RCF a depuis été remplacé par le RFC 8489, qui est désormais la norme STUN.)

Pour plusieurs raisons, dont le manque d'adresses IPv4, de nombreuses machines sont connectées à l'Internet derrière un routeur qui fait du NAT. Leur adresse étant alors privée, elles ne peuvent pas la transmettre à l'extérieur, ce qui est une gêne considérable pour tous les protocoles qui reposent sur la référence à des adresses IP, comme SIP. SIP lui-même (RFC 3261) marche à travers le NAT mais les données audio ou vidéo transmises (typiquement par RTP) le sont à une adresse IP que l'appelant donne à l'appelé et, si cette adresse est privée, le flux multi-média n'arrivera jamais.

La bonne solution serait de déployer IPv6, qui fournit des adresses en quantité illimitée, ou à la rigueur de permettre un meilleur contrôle du routeur NAT avec MIDCOM (RFC 3303) mais, en attendant, STUN est une solution simple et qui marche souvent. STUN avait à l'origine été normalisé dans le RFC 3489, que ce RFC met à jour, avec des changements assez importants, mais qui n'empêchent pas la compatibilité des anciens clients avec les nouveaux serveurs (ou réciproquement, sauf si le client utilise les nouvelles possibilités, comme la possibilité de fonctionner sur TCP et plus seulement UDP).

STUN s'inscrit donc dans la catégorie des protocoles de « réparation » du NAT, catégorie décrite dans le RFC 3424.

STUN résout partiellement le problème des NAT de la manière suivante : un serveur STUN doit être installé quelque part sur l'Internet public (il existe des serveurs STUN publics) et reçoit des demandes envoyées en UDP (ou TCP, voir la description de cette nouveauté en section 7.2.2) au port 3478. Le serveur STUN peut alors connaitre l'adresse publique, celle mise par le routeur NAT et, en répondant au client, il pourra informer celui-ci « Voilà à quoi tes paquets ressemblent, vus de l'extérieur ».

Le nom du serveur STUN est typiquement configuré dans le client, puis le serveur recherché dans le DNS via les enregistrements SRV (RFC 2782), comme détaillé dans la section 9. (Le client Unix en ligne de commande ne connait pas encore les SRV.)

Le principe est simple, mais le RFC est plus compliqué que cela, notamment en raison des problèmes de sécurité (la section 16 du RFC est très détaillée sur ce point). Par exemple, le client STUN doit en fait commencer par une connexion TCP pour obtenir un mot de passe temporaire. (d'autres méthodes d'authenfication sont possibles.)

Un autre problème est qu'il y a en fait plusieurs sortes de NAT (voir par exemple le RFC 2663). Par exemple, certains routeurs NAT (Symmetric NAT pour le RFC 3489) n'attribuent pas l'adresse externe uniquement en fonction de la source mais aussi en fonction de la destination. Ceux-ci ne fonctionnent pas avec STUN, qui a besoin de NAT cone, c'est-à-dire où les paquets d'une même machine auront toujours la même adresse IP externe.

Voici une démonstration d'un client STUN qui, en se connectant à un serveur STUN public va apprendre son adresse IP publique :

% ifconfig -a
hme0: [...] inet 172.19.1.2
(Adresse privée, probablement NATée...)

% ./client  stun.ekiga.net -v |& more
STUN client version 0.96
...
MappedAddress = 213.41.181.9:32143
(Voici mon adresse telle que vue de l'extérieur, à noter que ce RFC,
contrairement à son prédécesseur la nomme désormais ReflexiveAddress)
...

Une fois l'adresse extérieure détectée, tout n'est pas terminé car rien n'indique, par exemple, que les paquets vont effectivement passer. C'est pour cela que la section 14 insiste que STUN n'est qu'un outil, devant s'insérer dans une solution plus gobale, comme ICE (pas encore normalisé). À lui seul, STUN ne permet pas la traversée de tous les NAT. La section 14 décrit en détail ce concept d'utilisation de STUN et les règles que doivent suivre les protocoles qui utilisent STUN.

La section 6 décrit le format des paquets. Un paquet STUN doit comprendre l'indication d'une méthode, qui indique le genre de services que désire le client. Notre RFC 5389 ne décrit qu'une seule méthode, Binding, qui permet d'obtenir son adresse IP extérieure mais TURN (RFC 5766), par exemple, en définit d'autres. Après la méthode et un identificateur de transaction (qui sert au serveur STUN à séparer ses clients), suivent les attributs, encodés en TLV (la liste des attributs figure en section 15). Les numéros des attributs sont compris entre 0x0000 et 0x7FFF s'ils doivent être reconnus par le serveur (autrement, la requête est rejetée) et entre 0x8000 et 0xFFFF si leur compréhension est facultative (cette notion d'attributs obligatoires ou facultatifs facilite les évolutions ultérieures du protocole). Une partie de l'identificateur de transaction de la version précédente de STUN a été transformé en magic cookie, une valeur fixe (0x2112A442) qui sert à reconnaitre les agents STUN conformes à la nouvelle version.

Les sections 2, 12 et 19 décrivent en détail les changements par rapport à la norme précédente, le RFC 3489, notamment le fait que STUN (qui a changé de nom au passage, en gardant le même sigle) n'est plus présenté comme une solution complète mais comme un outil pour une solution plus générale (qui doit, notamment, tester que la connectivité fonctionne, comme le fait ICE). Même la découverte du comportement du NAT est désormais effectuée par des protocoles plus riches comme celui du RFC 5780. Parmi les autres changements, il faut noter que STUN encode désormais les adresses IP (par un simple XOR, section 15.2) pour les masquer, empêchant ainsi des stupides routeurs NAT de les réécrire (oui, certains routeurs NAT, profitant de l'absence de mécanisme de responsabilité pour le logiciel embarqué, examinaient toutes les données transitant par eux pour réécrire les adresses IP afin d'y mettre l'adresse publique ; le RFC parle poliment de misguided attempt at providing a generic ALG function mais le terme correct est « débilité monstrueuse »). Notez enfin que le RFC actuel sur STUN est, depuis février 2020, le RFC 8489.

L'ampleur des attaques DoS menées avec l'aide de serveurs DNS récursifs ouverts a mené à ce RFC qui résume les bonnes pratiques : un serveur DNS ne doit pas être récursif pour le monde entier.

L'accroissement du nombre d'attaques début 2006 a provoqué une prise de conscience, qui s'est manifesté par de nombreux avertissements aux administrateurs réseaux (comme celui de l'AFNIC). La vitesse de publication d'un RFC étant ce qu'elle est, c'est seulement maintenant qu'un RFC met par écrit cette règle simple (le RFC est très court). Un serveur DNS ne doit être récursif que pour ses clients connus, pas pour tout l'Internet.

En effet, s'il est récursif ouvert, il peut servir de base à une attaque par amplification. Il n'y a aujourd'hui aucune raison technique légitime de laisser un serveur récursif ouvert (vous pouvez tester le vôtre avec l'interface Web de the Measurement Factory et trouver des informations sur la configuration de votre logiciel dans le document, malheureusement ancien, Securing an Internet Name Server).

La section 4 détaille les configurations qui peuvent limiter l'accès à la récursion : par exemple, pour un boîtier SOHO qui sert également de résolveur DNS, discriminer selon l'interface (n'accepter les requêtes DNS que si elles viennent du réseau local). Ou bien, pour les machines en déplacement (un des arguments les plus souvent présentés par ceux qui voulaient maintenir la récursion ouverte à tous), utiliser un résolveur local à la machine, ou bien monter un VPN avec un résolveur de confiance.

À noter que notre RFC parle également beaucoup de BCP 38 (actuellement le RFC 2827) comme étant la « vraie » solution au problème. Mais c'est exagéré : BCP 38 ne résoud pas tous les problèmes, notamment les attaques entres clients d'un même opérateur.

Une technique non mentionnée par le RFC est de limiter le trafic du résolveur.

Comme son compagnon, le RFC 4787, qui concerne UDP, ce RFC décrit les règles que doit suivre un routeur NAT pour être utilisable sans trop de problèmes par les applications TCP.

La lecture préalable du RFC 4787 est recommandée, car il fixe le vocabulaire et les principes généraux. Notre RFC les complète ensuite pour le cas de TCP.

TCP a beaucoup évolué depuis le début (cf. le RFC 7414 pour une bonne description de cette évolution) mais le mécanisme de connexion initial, le fameux « Three-Way handshake », n'a pas changé, des tentatives comme T/TCP (cf. RFC 1644) ayant échoué. C'est cette connexion initiale qui est le plus gênée par le NAT.

Les exigences de notre RFC pour un routeur NAT sont principalement :

• Indépendance par rapport à la destination : la table de correspondance entre un port et un couple (adresse IP, port) ne doit dépendre que de la source,
• Le routeur doit accepter la totalité de la machine à états de TCP (décrite dans le RFC 793) et notamment, ce que beaucoup de routeurs NAT ne font pas, l'ouverture simultanée (où deux machines tentent une connexion TCP à peu près en même temps),
• Les éventuels délais avant qu'une session TCP « inactive » soit coupée doivent être d'au moins deux heures (aujourd'hui, il est courant que des routeurs NAT suppriment une connexion de leur table au bout de quelques minutes, car leurs concepteurs n'ont pensé qu'aux sessions HTTP, jamais à SSH, où il est courant qu'une session dure des jours et n'envoie pas de paquets tout le temps).

Depuis la sortie de ce RFC, le RFC 7857 a apporté quelques compléments.

L'IETF n'a jamais apprécié les identificateurs à portée purement locale, comme le TLD .local ou comme les adresses IP privées du RFC 1918. Ces identificateurs locaux, dont la signification est spécifique à un site donné, soulèvent plusieurs problèmes, par exemple une question pratique : que faire si deux organisations fusionnent et qu'elles utilisent toutes les deux de tels identificateurs, qui sont en collision ?

Les RFC successifs sur l'adressage IPv6 prévoyaient des identificateurs « site-local », spécifiques à un site, dans le préfixe FEC0::/10 (RFC 3513, section 2.5.6, ce RFC ayant depuis été remplacé par le RFC 4291). Toute organisation pouvait piocher librement dans ces adresses, tout en faisant attention à ne pas les laisser sortir de son site. Cela a permis à beaucoup d'organisations de commencer à expérimenter avec IPv6.

Mais ces identificateurs posaient des problèmes, en général communs avec tous les problèmes des identificateurs locaux. La section 2 du RFC les détaille :

• Si des applications se passent des adresses IP, comme le font FTP ou SIP, elles doivent connaitre les frontières de site pour savoir si elles peuvent passer des adresses privées (section 2.2).
• Commes les domaines privées, les adresses IP privées tendent à « fuir », à être transmises en dehors du site (par exemple dans les en-têtes Received: du courrier électronique ou via des requêtes DNS comme celles qu'absorbe l'AS112). Comme elles perdent toute signification en dehors du site d'origine, cela sème la confusion (section 2.3).
• Elles nécessitent un traitement spécial par les routeurs (section 2.4).
• Selon le RFC 3879, le concept de « site » lui-même n'est pas clairement défini (section 2.5). Est-ce une entité administrative unique ? Un site géographique unique ? Un AS ? Je dois avouer que cette section est la moins convaincante de tous et qu'elle donne l'impression que les auteurs ont voulu charger la barque. Puisque les adresses « site-local » sont spécifiques à un site, rien n'empêchait chaque site d'avoir sa propre définition.

Du point de vue pratique, pour l'opérateur d'un réseau, ces inconvénients pouvaient sembler légers et, de toute façon, un mécanisme de remplacement était nécessaire. C'est au développement de ce mécanisme que s'attaque la section 3 qui réclame un mécanisme alternatif assurant l'unicité des adresses « locales ». Cela ne supprimera pas, par exemple, les fuites, mais cela les rendra plus facile à déboguer. Ce mécanisme, les ULA (Unique Local Addresses) a finalement été créé par le RFC 4193.

Un détail important : la section 5, consacrée à la sécurité, rappelle que, contrairement à ce que croient beaucoup d'administrateurs réseaux débutants, le fait d'avoir des adresses privées n'offre à peu près aucune protection (par exemple parce que des techniques comme le changement DNS permettent d'attaquer de l'intérieur). La bonne technique est l'emploi de filtres et elle s'applique aux adresses privées comme aux publiques.

Il ne faut cependant pas considérer que les identificateurs locaux sont systématiquement une mauvaise idée. Ils sont nécessaires lorsque l'obtention d'identificateurs globaux, valables partout, est difficile ou coûteuse. C'est le cas des adresses IPv4 privées du RFC 1918 : vue la pénurie d'adresses IPv4 et les obstacles financiers et bureaucratiques à franchir pour en obtenir, il est logique d'utiliser ces adresses privées. C'était également le cas à l'époque pour les adresses IPv6 privées. Pendant longtemps, il était complètement impossible d'en obtenir (par diplomatie, pour éviter de vexer les RIR, le RFC 3879 évite de rappeler cet épisode). Il est donc déplorable que ce RFC aie été publié avant que son successeur, le RFC 4193, soit prêt. Désormais, les ULA de ce RFC fournissent une meilleure solution, qui évite notamment les collisions entre deux sites qui fusionneraient. On peut donc enterrer FEC0::/10 sans remords.

Aujourd'hui, l'administrateur réseau qui teste ses problèmes de performance utilise en général ping pour mesurer le RTT, le temps d'aller-retour avec la machine visée. Demain, utilisera t-il un programme nommé twping et le vieux ping sera t-il dépassé ? C'est en tout cas ce que visent les auteurs de ce protocole de mesure de RTT. (ping restera utile pour les tests de bon fonctionnement.)

ping, qui repose sur l'envoi de paquets ICMP echo request et echo reply (cf. RFC 792) a en effet des limites, décrites dans le RFC 2681, section 2.6 : notamment, il est difficile de savoir si les paquets ICMP ont été traités rapidement ou pas par la machine qui répond (un routeur Cisco renvoie la réponse très lentement, car elle doit passer par le processeur généraliste du routeur). En outre, il n'est pas possible de réserver l'usage de ces paquets echo à certains, sauf à filtrer par adresse IP (TWAMP, lui, permet l'authentification).

TWAMP (Two-way Active Measurement Protocol) hérite directement d'OWAMP (One-way Active Measurement Protocol, RFC 4656). Il reprend beaucoup de ses concepts, notamment la séparation en deux protocoles, celui de contrôle et celui de test. Notre RFC 5357 est d'ailleurs largement écrit sous forme de différences entre OWAMP et TWAMP, on ne peut donc pas implémenter ce dernier sans avoir lu le RFC 4656.

TWAMP met donc en œuvre la métrique décrite dans le RFC 2681 pour les mesures bidirectionnelles. Ces mesures ont l'avantage de ne pas dépendre de la présence d'une horloge correcte sur les deux machines et l'inconvénient de ne pas pouvoir séparer les contributions du trajet aller et du trajet retour. Un des deux est peut-être bien plus lent que l'autre mais les mesures bidirectionnelles ne pourront pas le détecter.

Comme l'explique la section 1.2, un système TWAMP peut comprendre jusqu'à quatre machines mais on peut supposer que, la plupart du temps, il n'y en aura que deux, la Control-Client/Session-Sender et la Server/Session-Reflector. Le programme sera lancé sur la première, qui émettra les paquets qui seront renvoyés par la seconde, permettant de calculer le RTT.

La section 2 décrit le protocole : le Control-Client établit une connexion avec le Server sur le port 862, ils se mettent d'accord sur le test, puis le Session-Sender envoie les paquets au Session-Reflector.

La section 3 décrit le protocole de contrôle, très proche de celui d'OWAMP. La section 4 est consacrée au protocole de test, dont la différence avec son prédécesseur est plus marquée, puisqu'il faut désormais renvoyer les paquets reçus. La procédure exacte suivie par le Reflector est décrite en 4.2. Le réflecteur renvoie la date d'arrivée, celle d'émission de la réponse et d'autres informations (section 4.2.1). Comme la réponse contient le TTL tel qu'il était à l'arrivée, une implémentation de TWAMP doit pouvoir accéder aux en-têtes IP, ce qui n'est pas pas toujours simple. Comme avec OWAMP, le diable est dans les détails et l'implémentation doit être faite très soigneusement pour limiter les erreurs et imprécisions.

TWAMP a depuis, bénéficié d'extensions au protocole de base, décrites dans le RFC 6038.

À noter que ce RFC est, je crois, le premier RFC qui normalise la prononciation du sigle du protocole (section 1.3) : « ti-ouampe ».

Il n'existe pas actuellement de mise en œuvre de TWAMP en logiciel libre. Compte-tenu de la proximité du protocole avec OWAMP, le meilleur moyen d'en écrire une serait sans doute de partir du programme owamp.

Pour une critique vigoureuse de ce RFC (pas du protocole, mais de la rédaction du RFC), voir « How NOT to Write a Protocol Specification », de Dustin D. Trammell.

Le RFC 2141 définissait une syntaxe pour les URN, un membre de la grande famille des URI. Dans cette syntaxe, immédiatement après la chaîne de caractères urn:, on trouve l'espace de noms (namespace), une chaîne de caractères qui identifie le domaine d'une autorité d'enregistrement. Notre RFC 3406 expliquait les procédures de création d'un nouvel espace de noms dans le registre des espaces de noms que tient l'IANA. Ces deux anciens RFC ont dépuis été remplacés par le RFC 8141.

Comme expliqué dans la section 1, ce mécanisme d'espaces de noms suppose que, dans chaque espace, il existe une autorité d'enregistrement qui accepte (ou refuse) les enregistrements et que, d'autre part, il existe une autorité qui enregistre les espaces de noms (en l'occurrence l'IANA). Tout le RFC 3406 est consacré aux procédures de cette dernière autorité et aux mécanismes pour enregistrer un identificateur d'espace de noms (NID pour namespace identifier). (La résolution des URN en autres identificateurs n'est par contre pas couverte.) Des exemples d'autorité d'enregistrement dans un espace de noms donné sont le gouvernement néo-zélandais (RFC 4350) ou l'OGC (RFC 5165).

La section 2 du RFC détaille ensuite ce qu'est un espace de noms (un ensemble d'identificateurs uniques géré, c'est-à-dire que tous les noms syntaxiquements corrects n'en font pas partie, uniquement ceux qui ont été enregistrés). Par exemple, les ISBN forment un tel espace (dont l'utilisation dans des URN a fait l'objet du RFC 3187). À l'intérieur d'un espace de noms, les règles d'enregistrement et le travail quotidien du registre ne sont pas gérés par l'IETF ou l'IANA mais par l'autorité d'enregistrement de cet espace.

La section 3 introduit les différents types d'espaces de noms. Il y a des espaces expérimentaux (section 3.1), qui ne nécessitent pas d'enregistrement auprès de l'IANA, et qui se reconnaissent à leur NID commençant par x- (leur usage est désomais découragé, cf. RFC 6963). Il y a les espaces informels (section 3.2), dont le NID commence par urn- et est composé de chiffres et les espaces formels (section 3.3) dont le NID est composé de lettres et qui, contrairement aux informels, sont censés fournir un bénéfice aux utilisateurs de l'Internet (les espaces informels ont le droit d'être réservés à une communauté déconnectée). Contrairement encore aux informels, l'enregistrement des espaces formels doit faire l'objet d'une spécification écrite, typiquement un RFC.

Un des principes des URN est la durabilité : un URN devrait être stable dans le temps. Mais cette stabilité dépend essentiellement de facteurs non-techniques, comme la permanence dans le temps du registre (une organisation privée et fermée comme l'IDF est, par exemple, typiquement un mauvais choix pour assurer la permanence). Toutefois, si on ne peut pas garantir la stabilité d'un espace de noms, on connait en revanche des facteurs qui diminuent la probabilité de permanence et l'IETF peut donc analyser les spécifications à la recherche de tels facteurs (c'est une variante du problème très riche mais bien connu de la stabilité des identificateurs).

Enfin, avec la section 4, on arrive au processus d'enregistrement lui-même. Il faut en effet un peu de bureaucratie pour s'assurer que le NID est bien enregistré et que le registre des NID soit lui-même stable. Les procédures sont différentes selon le type d'espace de noms. Les expérimentaux (section 4.1) ne sont pas enregistrés du tout. Les informels (section 4.2) ont leur propre registre, avec un processus d'enregistrement léger, mais très peu utilisé.

Le gros morceau est constitué des espaces de noms formels (section 4.3). Cette fois, le processus d'enregistrement est plus complexe, un RFC est nécessaire, mais on obtient un « vrai » NID comme MPEG (RFC 3614), OASIS (RFC 3621) ou 3gpp (RFC 5279).

Le formulaire d'enregistrement complet est disponible dans l'annexe A du RFC. Bon courage aux futurs enregistreurs. N'oubliez pas de lire tout le RFC.

Notre RFC succède au RFC 2611, les changements étant détaillés dans l'annexe C. Ils incluent une meilleure formalisation des différents types d'espace (expérimental, informel et formel) et une description plus détaillée des formalités d'enregistrement. Depuis, il a lui-même été remplacé par le RFC 8141.

Vieux de désormais trente et une années (la première norme était le RFC 724 en mai 1977), le format des messages électroniques vient donc de recevoir une nouvelle spécification. Pas de grands changements mais beaucoup de petites erreurs corrigées, elle marque l'avancée de la norme au statut de « projet de norme ».

Le courrier électronique d'Internet repose sur deux piliers : un protocole d'échange des messages, SMTP, normalisé dans le RFC 5321 et un format des messages, que traite notre RFC 5322. Les deux sont relativement indépendants, notamment dans le sens où on peut transporter des messages sur d'autres protocoles que SMTP, comme par exemple UUCP. Autre exemple, les adresses traitées par les deux RFC sont différentes (même si leur syntaxe est la même), SMTP gérant l'enveloppe du message et le format gérant son contenu (section 1). Cela justifie deux RFC séparés.

Que contient le RFC 5322 qui vient de remplacer le RFC 2822 ? Moins qu'on ne pourrait le croire. Des pans énormes de l'utilisation du courrier sont en dehors de ce RFC comme l'important format MIME (RFC 2045) ou comme les extensions d'internationalisation (RFC 6532).

Il reste donc un RFC sur l'envoi de messages textuels en ASCII. Mais, sans même prendre en compte des extensions comme MIME, c'est déjà assez complexe. La section 2 définit les règles lexicales des messages. Les messages sont découpés en lignes composées ce caractères. Le nombre maximal de caractères par ligne est de 998 caractères (section 2.1.1, qui recommande d'accepter également des longueurs plus grandes, mais sans générer soi-même de lignes plus longues).

La section 2.2 définit les en-têtes qui composent le début du message. Un message au format RFC 5322 ressemble, sur le câble, à :

Date: Tue, 9 Sep 2008 09:33:17 +0200
To: ubuntu-fr@lists.ubuntu.com
Message-ID: <20080909073317.GA23390@sources.org>
Subject: [Son] Silence complet sur mon ESS ES1978 Maestro 2E
From: Stephane Bortzmeyer <stephane@sources.org>

Le son, avec Linux, c'est vraiment p=E9nible.

J'ai un Dell Inspiron 7500 dont le son ne marche pas du tout. Silence
complet.

...

Le début, avant la ligne vide, est composé de cinq en-têtes (il y en a bien d'autres, non affichés ici. Avec mutt, c'est la commande h qui permet d'afficher tous les en-têtes). Chaque en-tête a un nom, suivi du deux-points et d'un corps. Si les premiers MUA affichaient directement les noms des différents champs, cela ne se fait plus guère aujourd'hui. En général, ce que voit l'utilisateur est bien différent de ce qui passe sur le câble, notamment à des fins de localisation (afficher « Objet » et pas « Subject », par exemple). Le corps du champ peut être non structuré (section 2.2.1, on y met ce qu'on veut, c'est le cas du champ Subject:) ou bien structuré (section 2.2.2, il obéit à une mini-grammaire spécialisée, c'est le cas de Date: ou de From:). Les champs peuvent être très longs et il est donc prévu (section 2.2.3) de pouvoir les plier sur plusieurs lignes. C'est un des points les plus souvent oubliés des auteurs d'analyseurs de ce format. Il faut donc rappeler qu'on ne peut pas utiliser d'outil orienté ligne comme grep sur un message électronique. (Une solution est d'utiliser l'excellente commande formail, dans le paquetage procmail, avec son option -c qui replie les lignes.)

Enfin, il y a le corps du message, après les en-têtes. Précédé d'une ligne vide, ce corps n'a pratiquement pas de structure dans notre RFC 5322 (section 2.3) mais d'autres normes comme MIME (RFC 2045) se chargent de combler ce manque et permettent, par exemple, de transporter plusieurs fichiers, y compris binaires, dans un seul message.

La section 3 décrit la syntaxe d'un message. La grammaire est très riche et très complexe. Pire, en raison de l'ancienneté de ce format, un grand nombre de productions grammaticales sont désormais abandonnées mais doivent toujours être reconnues par un analyseur, au cas où un logiciel les génère encore. Elles ont un nom commençant par obs- pour qu'on puisse les reconnaitre plus facilement. (La section 4 décrit cette grammaire abandonnée plus en détail. On y trouve, par exemple, un format pour les années sur deux chiffres, non compatible avec l'an 2000.)

Parmi les subtilités de cette grammaire :

• La syntaxe des dates, dans le champ (structuré) du même nom (section 3.3). Elle est très souvent violée : en pratique, on voit des dates de toutes les formes, même lorsque le logiciel est un programme payant et cher. Un exemple correct est Date: Tue, 30 Sep 2008 11:49:07 +0200 (le format du courrier est bien plus ancien que la norme ISO 8601). Ce champ est décrit en 3.6.1.
• Les adresses (section 3.4). C'est, encore plus que les dates, un des aspects les plus mal compris du courrier. Le Web abonde de programmes écrits dans des langages qui encouragent l'approximation (comme PHP ou Javascript) et qui refusent des adresses parfaitement légales. À leur décharge, il faut dire que la grammaire de la section 3.4.1 n'est pas triviale ! Un exemple d'adresse (on les utilise notamment dans les champs From: et To:) est stephane+blog@bortzmeyer.org. On notera que des normes comme NAI (RFC 7542) ou bien XMPP (RFC 7622) utilisent une syntaxe proche.

Enfin, la section 3.6 décrit tous les en-têtes. Citons entre autres :

• L'expéditeur, From:, Sender: et Reply-To:, section 3.6.2.
• Les destinataires, To: et Cc: (ceux qui reçoivent une copie), section 3.6.3.
• Message-ID:, section 3.6.4, un champ structuré qui contient un identificateur unique du message, par exemple <17b4fdcd0809290041i4323797al964ccf5a344b1c47@mail.gmail.com>.
• Subject:, section 3.6.5, qui indique l'objet du message et n'est pas structuré. Pour qu'il puisse contenir autre chose que des caractères ASCII, il faut utiliser l'encodage du RFC 2047 (ou le plus récent RFC 6532).
• Received:, section 3.6.7, qui sert à indiquer par quels relais est passé un message. Par exemple, Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by mx1.nic.fr (Postfix) with ESMTP id 98D821714088 for <bortzmeyer@nic.fr>; Mon, 29 Sep 2008 09:41:22 +0200 (CEST). C'est un excellent outil de débogage pour l'administrateur réseau.

La liste des en-têtes n'est pas figée, on la trouve dans un registre IANA (créé à l'origine par le RFC 4021) décrit en section 6.

Notre RFC 5322 remplace le RFC 2822, par rapport auquel il y a peu de changements. Le RFC 2822 remplaçait le RFC 822 qui est resté en service très longtemps, accompagnant l'essor du courrier électronique, et qui a été tellement influent que son numéro sert souvent à désigner le format (comme dans l'ancien module Python rfc822, remplacé depuis par email). L'annexe B donne la liste des changements par rapport au RFC 2822, essentiellement des corrections de bogues.

Ce RFC normalise la version actuelle de SMTP, le protocole de transfert de courrier électronique qui est un des grands succès de l'Internet et toujours une de ses applications les plus populaires, malgré les attaques des spammeurs et la concurrence des blogs et de la messagerie instantanée.

Ce protocole a été successivement normalisé par les RFC 788 (qui avait lui-même été précédé par des RFC décrivant des protocoles qui étaient très proches de SMTP), RFC 821, RFC 2821 et désormais notre RFC 5321. Le RFC 788 datant de novembre 1981, SMTP a donc vingt-sept ans.

Parmi ses caractéristiques principales, on trouve la simplicité, qui lui vaut son nom (écrire un client SMTP est simple), le fait qu'il permette le relayage du courrier par des serveurs intermédiaires et le fait qu'il ne spécifie que le transport du message, pas son contenu, qui fait l'objet du RFC 5322.

Il est intéressant de noter que, s'il a gagné en fonctions, SMTP en a aussi perdu dans certains cas. C'est ensuite que les fonctions de messagerie instantanée (voir annexe F.6) ont disparu avec le RFC 2821, le routage par la source également (annexe F.2) ou que la simple soumission du courrier par le logiciel client est désormais traitée par le RFC 6409, le SMTP complet étant réservé aux communications entre serveurs de messagerie.

La section 2 du RFC traite en détail du modèle de fonctionnement de SMTP. Le principe est que l'émetteur trouve le serveur distant (en général grâce aux enregistrements MX du DNS) puis ouvre une connexion TCP avec ce serveur distant, connexion sur laquelle on transmet l'adresse de l'expéditeur, celle du destinataire et le message (ces deux adresses forment donc ce qu'on appelle l'enveloppe, qui ne fait pas partie du message ; elles ne sont pas forcément identiques aux adresses qu'on trouve dans les champs From: et To: du message). (L'annexe B revient également sur certains aspects de la séparation entre l'enveloppe et le message. Ainsi, faire suivre un message en se fiant aux en-têtes To: du message, au lieu d'utiliser l'enveloppe, va très probablement produire des boucles sans fin.)

Le serveur distant n'est pas forcément la destination finale, il peut être un simple relais (un relais utilise SMTP des deux côtés) ou une passerelle (la passerelle parle SMTP d'un côté mais utilise un autre protocole, par exemple un protocole privé, de l'autre côté, cf. section 2.3.10).

En théorie (et la section 2.1 insiste sur ce point), le serveur qui a accepté un message doit le délivrer ou bien prévenir l'expéditeur. Aujourd'hui, avec la prolifération du spam et des joe jobs, ce principe n'est plus tenable et cette partie du RFC est donc celle qui est la plus ignorée. Une discussion sur ce point figure dans le RFC, aux sections 6.1, 6.2 et 7.8, qui admettent que « In today's world, [...] those principles may not be practical. » en rappelant toutefois qu'il faut être prudent, contrairement à beaucoup d'opérateurs de serveurs de messagerie qui jettent de nombreux messages sans garder de trace, ce qui jette un sérieux doute sur la fiabilité du service de courrier.

SMTP est simple, mais extensible. La section 2.2 résume le modèle d'extensibilité de SMTP, qui avait été intégré à partir du RFC 2821. Il repose sur une nouvelle commande pour s'annoncer au serveur distant, EHLO, qui remplace l'ancien HELO, et qui permet d'annoncer les extensions que l'ou ou l'autre MTA accepte. La section 2.2.1 insiste toutefois sur le fait que l'une des forces de SMTP est sa simplicité et qu'il ne faut donc peut-être pas trop le charger d'extensions, si elles ne sont pas clairement utiles.

La (longue) section 2.3 est consacrée à la terminologie. Elle rappelle notamment la distinction entre enveloppe et message, signalée plus haut. C'est ainsi que la définition des en-têtes du message comme Subject: ou bien Date: est laissée au RFC 5322, alors que celle du corps du message est du domaine de MIME (RFC 2045).

C'est également dans cette section de terminologie que sont définis des termes comme MTA ou MUA même si le RFC note (section 2.3.3) que, dans ce monde peu organisé, il ne faut pas toujours prendre les mots trop sérieusement.

La section suivante, 2.4, couvre les principes de base de la syntaxe SMTP, comme le fait que les commandes sont du texte, pas du binaire, qu'elles sont insensibles à la casse, et que les réponses à ces commandes sont des nombres de trois chiffres, conçus pour être interprétés par un programme (par exemple, 500 signifie « Erreur de syntaxe »).

Place ensuite, en section 3, aux procédures SMTP. Le cœur du protocole est là, notamment dans la section 3.3 qui explique l'enchaînement des commandes. Quatre sont particulièrement importantes, EHLO pour se connecter (section 4.1.1.1), MAIL FROM pour indiquer l'expéditeur (section 4.1.1.2), RCPT TO pour le destinataire (section 4.1.1.3) et DATA pour envoyer le message (section 4.1.1.4).

Voici un exemple d'une session SMTP, telle que l'affiche, pour nous aider au débogage, le client SMTP msmtp, lorsqu'il est lancé par echo TEST | msmtp --from=foobar@example.org --debug stephane@bortzmeyer.org (les lignes préfixées par <-- sont envoyées par le serveur SMTP de réception, celles commençant par --> par celui d'émission) :

<-- 220 relay1.nic.fr ESMTP Postfix
--> EHLO bortzmeyer.nic.fr
<-- 250-relay1.nic.fr
<-- 250-PIPELINING
<-- 250-SIZE 10240000
<-- 250-VRFY
<-- 250-ETRN
<-- 250-ENHANCEDSTATUSCODES
<-- 250-8BITMIME
<-- 250 DSN
--> MAIL FROM:<foobar@example.org>
--> RCPT TO:<stephane@bortzmeyer.org>
--> DATA
<-- 250 2.1.0 Ok
<-- 250 2.1.5 Ok
<-- 354 End data with <CR><LF>.<CR><LF>
--> TEST
--> .
<-- 250 2.0.0 Ok: queued as 92859A1D95D
--> QUIT
<-- 221 2.0.0 Bye

On voit, et c'est une des caractéristiques importantes de SMTP, que l'émetteur peut indiquer ce qu'il veut comme expéditeur. Cela permet les usurpations d'identité mais il n'est pas évident de résoudre ce problème de sécurité sans supprimer en même temps bien des usages utiles du courrier. Si le serveur SMTP initial peut à la rigueur authentifier ses clients, les serveurs suivants n'ont guère le choix, sinon de tout accepter.

Et voici ce qu'affiche un programme Python qui utilise la bibliothèque smtplib. Notons que les commandes de la bibliotèque portent le nom des commandes SMTP. Ici, on n'utilise que la commande de bienvenue initiale, EHLO :

% python
...
>>> import smtplib
>>> s = smtplib.SMTP("mail.example.org")
>>> s.set_debuglevel(True)
>>> s.ehlo("mail.foobar.example")
send: 'ehlo mail.foobar.example\r\n'
reply: '250-horcrux\r\n'
reply: '250-VRFY\r\n'
reply: '250-ETRN\r\n'
reply: '250-STARTTLS\r\n'
reply: '250-ENHANCEDSTATUSCODES\r\n'
reply: '250-8BITMIME\r\n'
reply: retcode (250); Msg: mail.example.org
VRFY
ETRN
STARTTLS
ENHANCEDSTATUSCODES
8BITMIME
(250, 'mail.example.org\nVRFY\nETRN\nSTARTTLS\nENHANCEDSTATUSCODES\n8BITMIME')

On trouve d'ailleurs des mises en œuvre de SMTP pour tous les langages de programmation, pour Emacs Lisp, pour Haskell...

En théorie, le serveur SMTP ne devrait pas du tout toucher au message qu'il convoie. Mais il existe quelques exceptions. Par exemple, la section 3.7.2 couvre le cas des en-têtes Received: dans le message (également discutés en section 4.4). Très utiles au débogage, ceux-ci doivent être ajoutés par chaque serveur SMTP qui a relayé le message. Pour le premier exemple ci-dessus, l'en-tête Received: ressemblera à :

Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69])
        by relay1.nic.fr (Postfix) with ESMTP id 92859A1D95D
        for <stephane@bortzmeyer.org>; Sun, 28 Sep 2008 03:56:11 +0200 (CEST)

Enfin, la section 4.1 décrit une par une toutes les commandes SMTP et leur syntaxe. La section 4.2 décrit, elle, les réponses. Composées de trois chiffres, le premier indique si la réponse est positive, négative ou incomplète (ainsi, 2xy indique que le serveur qui répond est satisfait, 5xy qu'il ne l'est pas et 4xy qu'il y a eu un problème temporaire). Le second chiffre, lui, indique le genre de la réponse : x0z pour ce qui concerne la syntaxe, x2z pour le réseau, etc. On peut donc en déduire que 421 signifie un problème temporaire avec le réseau, forçant à fermer la connexion (section 3.8).

Tout cela est bien beau, mais cela ne fait que spécifier le dialogue avec un serveur distant qu'on a déjà trouvé. Et comment le trouver ? Si je suis un MTA et que je veux transmettre un message envoyé à postmaster@gmail.com, comment est-ce que je trouve l'adresse du ou des serveurs responsables de gmail.com ? Si on refaisait SMTP en partant de zéro aujourd'hui, j'utiliserai sans doute les enregistrements SRV du RFC 2782. Mais le courrier électronique a été normalisé longtemps avant ce RFC et il utilise donc une sorte d'enregistrements SRV spécifique, les enregistrements MX. Le MTA regarde donc dans le DNS les MX de gmail.com :

% dig MX gmail.com.
gmail.com.		3600	IN	MX	5 gmail-smtp-in.l.google.com.
gmail.com.		3600	IN	MX	10 alt1.gmail-smtp-in.l.google.com.
...

et sait donc qu'il doit contacter gmail-smtp-in.l.google.com. La section 5 du RFC est consacrée à ce mécanisme.

Que faire s'il n'y a pas d'enregistrement MX ? La question a toujours été chaudement discutée chez les passionnés de SMTP, mais particulièrement lors de la rédaction de ce RFC 5321. En effet, l'ancienne règle (section 5 du RFC 2821) était qu'on utilisait, s'il était présent, un enregistrement A (une adresse IPv4), qualifié de « MX implicite ». Ce mécanisme est très critiqué : les domaines ont souvent un enregistrement A pour le Web (afin de pouvoir taper http://example.net/ et pas seulement http://www.example.net/) et la machine qu'il indique n'a pas forcément de serveur de courrier. En outre, que faut-il faire s'il n'y a pas d'enregistrement A mais un AAAA (une adresse IPv6) ? Notre RFC s'éloigne donc du RFC 2821 ici et décide de garder l'ancienne convention du MX implicite (au nom de la continuité), en l'étendant à IPv6 (voir la discussion en section 5.2). Les termes de « A RR » (A resource record, enregistrement de type A) ont ainsi disparus au profit de address RR qui regroupe A et AAAA.

On note qu'il n'existe pas de moyen normalisé de dire « Je ne veux pas recevoir de courrier » ; ne pas avoir de MX ne suffit pas, en raison de la règle maintenue d'un MX implicite ; la méthode la plus courante, mais non standard, est de publier un MX délibérement invalide, pointant par exemple vers . (la racine) ou vers localhost.

Notons que la section 5 précise qu'un émetteur SMTP doit essayer d'envoyer à toutes les adresses IP, pas uniquement à tous les MX (un serveur peut avoir plusieurs adresses).

La section 6 est consacrée aux problèmes et à tout ce qui peut aller mal. Par exemple, la sous-section 6.4 parle des rapports avec les implémentations qui violent la norme. Elles sont très nombreuses (historiquement, Lotus Notes semble avoir la médaille des problèmes). Depuis que le courrier existe, il y a des polémiques entre les « éradicateurs » qui demandent que les serveurs SMTP refusent de compenser ces violations et stoppent tout dialogue avec les logiciels trop bogués et les « conciliateurs » qui, après avoir fait trois génuflexions vers la statue de Jon Postel et cité son « principe de robustesse » (« Be conservative in what you send and liberal in what you accept »), demandent qu'on essaie malgré tout de parler avec les programmes ratés. Le problème est d'autant plus difficile que tous les développeurs ne sont pas égaux : on peut difficilement refuser de parler aux serveurs de messagerie d'AOL, quelles que soient les curieuses pratiques qu'ils utilisent. Même chose avec des logiciels très répandus comme Microsoft Exchange.

Une autre partie du problème est que certains MUA ont des capacités limitées et qu'on ne peut pas trop exiger d'eux. Ainsi, les serveurs SMTP ont pris l'habitude de réparer les messages, en rectifiant par exemple les champs Date: invalides (une bogue très fréquente). Ces réparations devraient, dit le RFC, être limitées aux clients locaux, que l'on connait, et ne pas s'étendre aux machines d'autres domaines. Cette approche est cohérente avec le RFC 6409 (qui sépare la soumission d'un message depuis un MUA vers le premier MTA, de l'envoi d'un message entre MTA) mais avec certains logiciels, comme Postfix, elle ne peut pas être configurée.

Toute aussi brûlante est la question de la sécurité du courrier électronique, qui fait l'objet de la section 7. D'abord (section 7.1), il y a le problème de l'authentification : un serveur SMTP peut toujours prétendre que le courrier vient de pape@nic.va, il n'y a aucun moyen de vérifier. (De très nombreux projets ont visé à traiter ce problème, voir par exemple les RFC 7208 et RFC 6376 mais il est bien plus compliqué qu'il n'en a l'air, notamment parce qu'il n'existe pas de système d'identité international et reconnu.) Le RFC recommande donc d'authentifier ses messages, par exemple avec le RFC 4880.

La section 7.9, elle, couvre les questions opérationnelles liées à la sécurité. Par exemple, certains fournisseurs de courrier (notamment AOL, qui s'en vante bruyamment), refusent le courrier de certains sites, sur des critères décidés unilatéralement et sans prévenir leurs propres utilisateurs. D'une certaine façon, c'est compréhensible, puisque l'ampleur du spam nécessite des mesures souvent radicales. Mais cela peut, si on poursuit cette logique, mener à un système de courrier qui serait réservé à un oligopole de quelques fournisseurs qui s'acceptent entre eux (le projet du MAAWG).

C'est la même section qui mentionne les relais ouverts, en des termes étonnamment prudents (la pratique générale est de les supprimer). Comme autre exemple de code Python pour faire du SMTP, voici un programme pour tester si un serveur est un relais ouvert.

Ce RFC ne marque guère de changements par rapport à son prédécesseur, le RFC 2821. Le but principal était de le faire avancer sur le chemin des normes, vers son nouveau statut de « Projet de norme ». Les changements ? Eh bien, le principal étant l'extension du « MX implicite » à IPv6.

Ce RFC a été longtemps retardé par une amusante et exaspérante « querelle des exemples » et a même fait l'objet d'un appel contre l'obstruction de l'IESG. Celle-ci estimait en effet que le RFC aurait dû utiliser, pour ses exemples, uniquement les noms de domaines du RFC 2606, malgré le fait que le RFC 2821 aie déjà utilisé des noms comme isi.edu (l'université de Jon Postel) ou generic.com depuis des années.

Des propositions d'architectures radicalement nouvelles, en général fondées sur un modèle où le récepteur « tire », comme avec Atom, plutôt que sur le modèle traditionnel du courrier où l'expéditeur « pousse » ont déjà été faites, par exemple par Dan Bernstein ou par Wietse Venema mais n'ont jamais débouché sur des protocoles finalisés, et encore moins sur des implémentations. Ces propositions visent en général à traiter le problème du spam en forçant l'expéditeur à garder le message chez lui, jusqu'au moment de la récupération par le destinataire. Cela résoudrait la question du stockage du spam, mais pas du tout celle de son traitement puisqu'il faut bien notifier le destinataire qu'il a un message, et qu'il doit bien le récupérer pour décider si c'est du spam ou pas.

Membre de la famille Rserpool (décrite dans le RFC 5351, ASAP (Aggregate Server Access Protocol) est le protocole de communication entre un client (le PU, pour Pool User) et le serveur ENRP (RFC 5353), ainsi qu'entre un élément du groupe de serveurs d'application (le PE pour Pool Element) et le serveur ENRP. ASAP permet aux PE de s'enregistrer auprès du serveur ENRP et aux PU de trouver l'adresse d'un PE avec lequel ils vont travailler.

Le groupe de serveurs de l'application, le pool, est identifié par un handle nommé PH (pool handle). ASAP permettra de résoudre cet handle en une ou plusieurs adresses IP. Le fait d'interposer cet intermédiaire entre le client et le serveur de l'application permet d'assurer des fonctions de répartition de charge ou de résistance aux pannes. Comme le rappelle la section 1.3, un handle n'a qu'une signification locale à une organisation, il ne prétend pas être unique pour tout l'Internet.

Les deux fonctions essentielles d'ASAP sont donc :

• Pour un PE, un des serveurs de l'application, de signaler sa disponibilité (message ASAP_REGISTRATION, section 2.2.1),
• Pour un PU, un client final, de trouver l'adresse IP d'un ou plusieurs serveurs du groupe, afin de le contacter (message ASAP_HANDLE_RESOLUTION, section 2.2.5).

ENRP, quant à lui (RFC 5353), est utilisé entre les serveurs ENRP, pour assurer leur synchronisation.

Une façon simple de décrire ce que fournit ASAP est de lire la section 6 qui décrit, en pseudo-code, les primitives d'ASAP. Par exemple, l'enregistrement d'un serveur dans le groupe est (section 6.1) :

         
Format: registration.request(poolHandle,
                             User Transport parameter(s))

La section 2 détaille le format des messages que portera ASAP. Le format de base est défini dans le RFC 5354. Ainsi, ASAP_REGISTRATION (section 2.2.1) porte le handle du groupe que le PE veut rejoindre. La réponse, ASAP_REGISTRATION_RESPONSE (section 2.2.3) comprendra un champ Reject qui, mis à 1, indiquera l'échec éventuel (un 0 signifiant le succès).

L'autre message important est ASAP_HANDLE_RESOLUTION (section 2.2.5) et sa réponse, ASAP_HANDLE_RESOLUTION_RESPONSE. Le premier permet de résoudre un handle en une adresse IP (ou une liste d'adresses IP, pour donner du choix au client, et lui permettre d'essayer d'autres serveurs en cas de défaillance, voir par exemple la section 6.8.1 et le RFC 5356).

Le principal protocole de transport utilisé par ASAP (sections 2.1 et 5) n'est pas TCP mais SCTP (RFC 4960), entre autres parce qu'il fournit déjà une certaine résistance aux pannes (plusieurs adresses IP peuvent être utilisées pour la même association). Le port par défaut est 3863 (3864 avec TLS). Notons qu'ASAP n'est pas purement requête-réponse : le serveur ENRP peut envoyer des messages non sollicités, par exemple si un pool change.

Il existe une implémentation d'ASAP en logiciel libre dans rsplib.

Il existe de très nombreux cas où une application cliente peut utiliser plusieurs serveurs parmi un groupe (le pool). L'idée de la suite de protocoles Reliable Server Pooling ( RSerPool) est de fournir un moyen standard de faire ce choix. Ce RFC explique les concepts de base de ce protocole, normalisé dans d'autres RFC.

La section 1 du RFC résume les raisons pour lesquelles on veut disposer d'un groupe, un pool, de serveurs plutôt que d'un serveur unique, par exemple, pour atteindre des objectifs de haute disponibilité ou de répartition de charge. Les nouveaux protocoles devront fournir notamment les services suivants :

• indépendance par rapport à l'application,
• liaison directe entre le client et le serveur, sans machine intermédiaire,
• séparation des fonctions de disponibilité et de changement en cas de panne, des fonctions propres à l'application.

Comment sont structurés les protocoles de la famille RSerPool ? (Le cahier des charges était le RFC 3237 et prévoyait un protocole relativement léger, interne à un domaine administratif, moins ambitieux, donc, que les grilles.) Le groupe (pool) a un identificateur, le PH (Pool Handle). Les serveurs du groupe se nomment les PE (Pool Element). Chaque PE s'enregistre auprès d'un serveur ENRP (Endpoint haNdlespace Redundancy Protocol) en utilisant le protocole ASAP (Aggregate Server Access Protocol), décrit dans le RFC 5352. Le client se nomme, lui, le PU (Pool User). Il utilise également ASAP pour parler au serveur ENRP, obtenant ainsi la correspondance entre le PH et l'adresse IP du serveur effectif. Le PU parlera ensuite directement au PE, utilisant un protocole spécifique à l'application. Enfin, le serveur ENRP peut se synchroniser avec d'autres serveurs ENRP (RFC 5353) pour fournir également un service à haute disponibilité.

Ces protocoles sont décrits dans différents RFC, le RFC 5352 pour ASAP, le RFC 5353 pour ENRP, le RFC 5354 pour le format des paramètres, le RFC 5356 pour les politiques de sélection des serveurs et le RFC 5355 pour l'analyse des risques de sécurité.

La section 2 décrit ASAP (Aggregate Server Access Protocol), le protocole de communication entre le PU et le serveur ENRP, ainsi qu'entre ce dernier et les PE, les membres du groupe. ASAP est normalisé dans le RFC 5352. Il permet aux PE de s'enregistrer auprès du serveur ENRP (section 2.2) et au PU d'obtenir l'adresse d'un membre du groupe (section 2.3). Dès qu'un PE s'enregistre sous un identificateur de groupe (un PH), ce groupe existe et, lorsque le dernier PE se désenregistre, le groupe disparait (section 2.1).

Comme la communication entre le PU, le client et le PE, le serveur, est directe (ce qui permet au protocole d'être indépendant de l'application), il n'y a pas d'état et il peut donc être difficile de passer d'un PE à un autre en cas de panne, le nouveau PE ne se souvenant pas du contexte de l'application. La famille de protocoles RSerPool fournit donc quelques mécanismes limités pour conserver un état (section 2.5). Ainsi, la section 2.5.1 permet un système de petits gâteaux, envoyés par le PE au PU et que celui-ci doit renvoyer lorsqu'il change de PE, permettant ainsi de garder trace de l'état de l'application.

La section 3 décrit ENRP, Endpoint haNdlespace Redundancy Protocol, le protocole de communication entre les serveurs ENRP. Ce protocole, normalisé dans le RFC 5353, permet aux serveurs ENRP d'un domaine de se synchroniser et de garder trace des PE enregistrés dans tel ou tel groupe.

La section 4, enfin, donne des exemples d'usage de la famille RSerPool. L'exemple de la section 4.1 est relativement simple, RSerPool y est utilisé pour sélectionner un serveur. La résolution d'un PH en adresse IP d'un serveur est donc le seul service invoqué. Cette section décrit les modifications nécessaires au code source de l'application :

• Spécifier un PH (identificateur de groupe) au lieu d'un nom (ou d'une adresse IP),
• Au lieu d'utiliser la fonction classique de résolution de nom, getaddrinfo, utiliser une fonction RSerPool de résolution,

À noter qu'il n'existe pas d'API standard pour les protocoles de la famille RSerPool. À noter également que, dans un exemple aussi simple, RSerPool n'était pas forcément nécessaire, les enregistrements DNS SRV du RFC 2782 auraient suffi.

L'exemple de la section 4.2 est plus complexe, faisant appel à toutes les fonctions de RSerPool, y compris pour la transmission de données entre le client, le PU et le serveur, le PE.

Il existe au moins une mise en œuvre de RSerPool. Elle est disponible en http://tdrwww.iem.uni-due.de/dreibholz/rserpool/. Elle est décrite dans la thèse Reliable Server Pooling -- Evaluation, Optimization and Extension of a Novel IETF Architecture. La page de l'auteur contient beaucoup d'autres informations sur la famille Rserpool.

Complétant la série des RFC sur la famille de protocoles Rserpool, famille dont le cahier des charges était le RFC 3237, ce document normalise le protocole ENRP (Endpoint Handlespace Redundancy Protocol) qui est le protocole utilisé entre les serveurs qui font la traduction des identifiants, les handles, en adresses IP.

Rappelons brièvement le fonctionnement de Rserpool (le RFC 5351 fournit une description plus détaillée) : un client, le PU (Pool User) veut accéder aux services fournis par un groupe (pool) de serveurs d'application, les PE (Pool Elements). Le client ne connait que l'identifiant du groupe, le PH (Pool Handle). Pour le traduire en adresses IP, le client utilise le protocole ASAP (RFC 5352) pour demander aux serveurs ENRP cette traduction. Les PE utilisent également ASAP pour s'enregistrer auprès des serveurs ENRP. Et comment les serveurs ENRP se synchronisent-ils ? Avec le protocole ENRP de notre RFC 5353. Grâce à lui, les serveurs ENRP forment un registre distribué et résistant aux pannes.

Notons qu'ENRP n'est conçu que pour fonctionner au sein d'un même domaine administratif, où toutes les machines sont configurées par la même équipe et peuvent donc, après authentification forte, se faire confiance (la section 6 détaille ces exigences de sécurité et impose TLS avec authentification réciproque). La conception d'un tel protocole pour l'Internet entier est encore un défi.

C'est la section 3 qui décrit le fonctionnement du protocole. Au démarrage, un serveur ENRP doit (section 3.2) générer son identifiant ENRP (un entier de 32 bits), trouver un mentor, le pair qui lui donnera les autres informations (la section 3.2.21 explique comment), obtenir la liste de ses pairs (et la garder à jour, cf. section 3.4) puis les tenir au courant des enregistrements/départs de PE (section 3.3) qu'il voit (chaque PE ne parle qu'à un serveur ENRP, son home server).

La section 3.5 détaille la procédure plus compliquée de remplacement (take over), qui permet à un pair de remplacer un pair en panne et de signaler aux PE (via le protocole ASAP) qu'ils doivent changer leur serveur ENRP.

La section 2 du RFC décrit les messages ENRP (s'appuyant sur la base fournie par le RFC 5354). Par exemple, ENRP_PRESENCE (section 2.1) permet à un serveur ENRP d'annoncer à un de ses pairs ENRP qu'il est toujours là. ENRP_HANDLE_TABLE_REQUEST (section 2.2) est utilisé lorsqu'un pair ENRP rejoint les autres et réclame une copie complète de la table des handles et des adresses IP associées. ENRP_HANDLE_UPDATE (section 2.4) servira ensuite aux mises à jour, au fur et à mesure que des PE s'enregistreront ou bien partiront.

ENRP_LIST_REQUEST (section 2.5) est également utilisé à l'initialisation d'un pair ENRP : il lui permet de demander une liste des pairs ENRP actuellement actifs.

Il existe au moins une mise en œuvre d'ENRP dans http://tdrwww.iem.uni-due.de/dreibholz/rserpool/.

Les mesures de performances sur l'Internet sont un sujet passionnant mais complexe. Comme il faut bien commencer par définir précisement ce qu'on mesure, ce RFC ne spécifie pas un protocole mais uniquement une métrique, une grandeur qu'on veut mesurer et qui doit faire l'objet d'une définition rigoureuse. Cette métrique est le temps d'aller-retour (RTT) d'un paquet IP.

Cette mesure du RTT est connue grâce à l'outil ping. Mais ping a, entre autres défauts, celui de ne pas reposer sur une métrique rigoureuse, ce qui rend souvent difficile de savoir ce qu'il mesure exactement. Notre RFC s'attache donc à une définition précise d'une telle métrique. Il s'appuie pour cela sur le cadre et les définitions du RFC 2330, et suit de près le RFC 2679, qui décrivait une telle métrique pour les allers simples.

La section 1.1 du RFC commence par expliquer pourquoi une telle métrique est utile : notamment parce que certaines applications, notamment les plus interactives, fonctionnent mal si le RTT est trop élevé, que sa valeur minimale donne une idée des caractéristiques intrinsèques du lien et que des augmentations de ce RTT peuvent indiquer une congestion du lien. Elle est donc pertinente dans beaucoup de cas.

Mais pourquoi, continue cette section 1.1, mesurer le temps d'aller-retour et pas seulement celui d'aller simple comme le fait le RFC 2679 ? En effet, le RTT a plusieurs défauts : en cas de routage asymétrique, le temps de parcours aller peut être très différent du temps retour (et le RTT ne permet pas de voir cette différence). Même chose si des mécanismes divers (par exemple l'asymétrie des débits en ADSL) font qu'une direction a des caractéristiques très différentes d'une autre. C'est vrai, mais le RTT a aussi des avantages, notamment le fait qu'il est beaucoup plus facile à mesurer que l'aller simple, puisqu'il ne nécessite pas que les horloges des deux machines soient synchronisées (c'est sur ce principe que fonctionne ping).

Les lecteurs étant désormais convaincus de l'intérêt de cette métrique, la section 2 passe donc à sa définition : baptisée du nom scientifique de Type-P-Round-trip-delay, le temps d'aller-retour a pour paramètre les adresses IP de la source et de la destination, le temps T de la mesure, pour unité la seconde et pour définition (section 2.4) le délai entre la mise du premier bit de la question sur le câble et la réception du dernier bit de la réponse. Type-P signifie simplement qu'il peut dépendre du type du paquet (par exemple TCP vs. UDP, ou bien le numéro de port, tout ce qui fait qu'un routeur peut traiter ce paquet rapidement ou pas). Ainsi, les mesures de ping ont pour Type-P « ICMP avec des paquets echo ». Ce terme de Type-P est défini dans la section 13 du RFC 2330.

Cette définition est donc très simple sur le papier. En pratique, elle pose quelques problèmes, signalés par la section 2.5 : le temps T de la mesure dépend, lui, d'une bonne synchronisation des horloges, la définition n'indique pas à partir de quand on renonce à attendre un paquet perdu (le résultat de la mesure est alors indéfini), etc.

Ce n'est pas tout : même lorsque la métrique est parfaite, les ordinateurs sont des machines physiques ayant plein de limitations, qui limitent la précision de la mesure. Il est symptomatique du mauvais état de la métrologie sur Internet qu'on voit souvent citer des résultats sans indiquer les marges d'erreur ou d'incertitude. La section 2.7 cite certaines de leurs causes :

• Les faiblesses des horloges (section 2.7.1) sont à prendre en compte. Si la mesure du RTT ne nécessite pas de synchronisation de celles-ci (sauf pour déterminer le temps T de la mesure), elle demande par contre un peu de stabilité. Une dérive (skew) très forte ou, plus probable, un changement brusque de l'heure par l'opérateur ou par un logiciel peut fausser un résultat. De même, la résolution des horloges peut être trop mauvaise pour la rapidité des réseaux modernes.
• La définition du RTT est lié au concept de « mise sur le câble » des bits (section 2.7.2). Un programme typique n'a pas accès à l'information sur l'instant exact où le bit est envoyé. Le temps qu'il mesure est celui de la machine, pas celui de la carte réseau. (Mon programme echoping, qui mesure le RTT, n'essaie même pas de déterminer ce wire time, je ne pense pas qu'il existe une méthode portable sur Unix pour cela.)
• Le temps de réaction de la machine visée est souvent difficile à prédire (section 2.7.3). Les routeurs Cisco, par exemple, ne génèrent pas la réponse aux paquets ICMP echo sur la carte (fast path) mais dans leur processeur généraliste, bien plus lent. Avec de telles machines, le temps mesuré par ping est largement dominé par le temps de réponse du routeur et pas par le réseau proprement dit. Sur une machine Unix, ICMP est mis en œuvre dans le noyau, ce qui fournit certaines garanties, notamment que le swapping n'interviendra pas. Mais cela ne garantit pas, par exemple, qu'une surcharge du processeur de la machine ne va pas ajouter un délai inattendu. Si le Type-P est TCP avec le port 80, comme HTTP est typiquement mis en œuvre en mode utilisateur, les incertitudes sont bien plus grandes (swapping, temps de réponse de l'application - par exemple Apache, ...)

Une fois ces problèmes surmontés, il faut indiquer à l'utilisateur le résultat des mesures. C'est l'objet de la section 2.8 qui insiste sur la nécessité de transmettre au dit utilisateur toutes les informations permettant d'interpréter les données : le Type-P (pour echoping, il faut utiliser l'option -v et encore, l'affichage du Type-P n'est pas vraiment clair), la façon dont une réponse en retard est considérée comme perdue, les résultats de l'étalonnage et le chemin suivi par les paquets (à noter que cette information n'est en général pas accessible au programme de mesure, à part éventuellement l'interface réseau de sortie).

Une fois cette première métrique établie, le RFC, dans sa section 3, définit un échantillonage de cette mesure, selon une distribution de Poisson. Cette seconde métrique, définie de 3.1 à 3.4, a deux paramètres supplémentaires, le temps de fin de la mesure et le taux d'envoi des paquets (le lambda de la distribution de Poisson).

La section 3.5 discute du choix du paramètre lambda, en citant le RFC 2330. En gros, comme il s'agit d'une mesure active, plus lambda est élevé et plus la mesure est précise, mais plus on a perturbé le réseau avec tous ces paquets de test.

Munis de cette deuxième métrique, le RFC cite quelques statistiques intéressantes (section 4) qui peuvent être obtenues :

• Le Xème centile (section 4.1), c'est-à-dire la valeur du RTT pour laquelle X % des mesures tombent en dessous. Ainsi, le 90ème centile est la valeur du RTT telle que 90 % des mesures donnaient une RTT plus faible. Le 50ème centile est presque équivalent à la médiane, décrite en section 4.2.
• Le délai d'aller-retour minimum (section 4.3) qui reflète le cas idéal (réseau peu ou pas chargé, machine distante peu ou pas chargée et qui répond donc aux mieux de ses capacités).

Enfin, la section 5 est consacrée aux questions de sécurité. Comme toutes les mesures actives, celles du RTT doivent garder à l'esprit la nécessité de ne pas surcharger le réseau (ne pas utiliser l'option -f de ping). Mais ce point concerne la sécurité du réseau vis-à-vis des mesures. Il y a aussi un problème de sécurité des mesures vis-à-vis du réseau. En effet, les équipements sur le trajet peuvent fausser la mesure en retardant ou en donnant la priorité à certaines paquets. En cas de mesure d'un réseau franchement hostile, il peut être nécessaire de recourir à des techniques cryptographiques pour préserver l'intégrité des mesures.

Un protocole utilisant cette métrique a été normalisé, TWAMP (RFC 5357).

Tout protocole sur Internet doit gérer la congestion et réagir proprement à celle-ci, sans aggraver le problème par un comportement égoïste. Si ce protocole fonctionne sur TCP, c'est fait automatiquement pour lui. Mais s'il fonctionne sur des protocoles sans notion de connexion, comme UDP, c'est plus complexe. Ce RFC spécifie un mécanisme que les protocoles peuvent utiliser pour assurer un contrôle de congestion compatible avec celui de TCP. Il s'applique aussi bien aux protocoles de la couche transport comme DCCP qu'aux protocoles de la couche application, si la couche transport ne fournit pas de contrôle de congestion.

Il est difficile de demander à chaque application de faire ce contrôle, qui est très complexe. Celles utilisant TCP ou bien DCCP (RFC 4340) voient ce contrôle fait automatiquement pour elles. Le protocole de notre RFC 5348, TFRC, peut être utilisé par DCCP, son principal client (RFC 4342), ou bien par une application utilisant UDP (section 1 du RFC). TFRC n'est d'ailleurs pas un protocole complet, spécifié dans les moindres détails, puisque certains points dépendent du protocole qui l'utilise (le RFC 4342 donne un exemple d'utilisation de TFRC).

Le nom de TFRC vient de son désir d'être « civil » envers TCP lorsqu'un flot de données TCP et un flot de données DCCP sont en compétition sur le même câble. Normalement, chacun des deux flots doit obtenir une part à peu près égale de la capacité disponible. (Un protocole « incivil » enverrait le plus de paquets possible, sans ralentir, malgré la congestion.)

TFRC met en œuvre ses mécanismes chez le récepteur des données (sections 3, 5 et 6). Celui-ci mesure le pourcentage de données perdues et en informe l'émetteur (par des paquets décrits en section 3.2.2), qui devra alors ralentir l'envoi (pour calculer le ralentissement nécessaire, l'émetteur dispose également du RTT, qu'il a mesuré à cette occasion). L'équation exacte est donnée dans la section 3.1 et est très proche de celle dite Reno.

Le contrôle de congestion est un problème complexe, très mathématique, et qui mène facilement à des textes longs, comme ce RFC. Les nombreuses formules qu'il contient sont d'autant plus difficile à lire que, comme tout RFC, il est en texte brut.

La section 4 décrit plus en détail ce que doit faire l'émetteur, notamment s'il ne reçoit pas les paquets d'information du récepteur (l'émetteur doit alors diviser son débit par deux, mesure drastique justifiée par le fait que, si aucun paquet d'information ne passe, c'est probablement que la congestion est sévère).

Notons qu'une variante de TFRC fonctionne avec des mesures du taux de perte de paquets faites par l'émetteur et pas par le récepteur. Elle est décrite en section 7.

TFRC avait été normalisé à ses débuts dans le RFC 3448. La section 9 résume les changements, peu importants. Le principal est que, dans l'ancien RFC, l'émetteur était tenu par le taux d'envoi que lui imposait le récepteur. Si l'émetteur envoyait peu, parce qu'il n'avait pas grand'chose à dire (data limited), le récepteur lui retournait un taux d'envoi faible. Ce problème a été traité.

Le groupe de travail de l'IRTF DTN (Delay-Tolerant Networking) continue son travail de création de protocoles de communication standards capables de fonctionner dans l'espace lointain, ou dans des milieux similaires. Après le protocole Bundle du RFC 5050, qui décrit un protocole de niveau Application pour le transfert de données, voici le protocole Licklider, de niveau Transport.

LTP (Licklider Transmission Protocol), ainsi nommé en l'honneur du pionnier de l'Internet, est donc sur le même créneau que des protocoles comme TCP, chargé de fournir un service de transport aux applications (ce que le RFC 5050 nomme un convergence layer). Il est normalisé dans le RFC 5326 et des extensions sont prévues par le RFC 5327. Notre RFC 5325, lui, expose les motivations derrière ce protocole.

Les milieux où LTP sera utilisé sont caractérisés (sections 1 et 2 du RFC) par des délais de transmission très longs (une heure pour joindre Jupiter depuis la Terre), une fiabilité faible des transmissions et le fait que celles-ci ne soient possibles que par intervalles, lorsque les deux astres ne sont pas masqués par un troisième. Le principal « client » de LTP sera donc la NASA. (Le problème général des communications spatiales avait été décrit dans le RFC 4838.)

La section 2.1 fait également remarquer que les limites de ces communications spatiales ne sont pas uniquement physiques (vitesse de la lumière) mais également économiques. Les antennes capables de communiquer avec les vaisseaux spatiaux, comme celles du DSN, sont rares et leur location coûte cher.

La même section 2.1 explique pourquoi ces caractéristiques condamnent les protocoles réseaux traditionnels : on ne peut pas attendre un accusé de réception avant de continuer à transmettre, vue la longueur du RTT ; on ne peut pas négocier des paramètres de transmission avec l'autre partie, la fenêtre de transmission est souvent trop courte pour cela ; l'évaluation du RTT par des mesures est en général impossible. LTP sera donc un protocole unidirectionnel, l'interactivité n'étant en général pas possible dans l'espace.

La section 2.2 détaille les limites de TCP ou SCTP pour ce problème. Avec une équation d'état comme celle du RFC 5348, une transmission de la Terre à Mars à seulement dix kilobits par seconde nécessiterait un taux de perte des données inférieur à 10^(-5), ce qui est irréaliste dans l'espace.

La section 3 explique les grandes lignes du protocole (il faut lire le RFC 5326 pour avoir la vraie norme). LTP transmet des blocs de données qui sont composés de deux parties, la « rouge » (ces données doivent faire l'objet d'un accusé de réception, sinon elles sont retransmises) et la « verte » (jamais retransmises). Chacune des deux parties peut être vide. Ainsi, une application de transfert de fichiers mettra typiquement toutes les données dans la partie rouge et rien dans la verte. LTP permet donc à l'application de choisir la sémantique de TCP ou bien d'UDP et ceci pour chaque bloc de données.

Vue la nature unidirectionnelle de LTP, il n'y a pas de négociation avec l'autre partie : la transmission des données se fait « en aveugle », LTP stockant les parties rouges pour pouvoir les retransmettre s'il n'y a pas d'accusé de réception. Seule la couche Liaison peut donner des indications à LTP (la section 3.1.1 détaille ces indications).

Justement, quand retransmettre ? Comme LTP ne peut pas mesurer le RTT, il doit dépendre de calculs réalisés avant la transmission (la section 3.1.3 détaille ces calculs), en se basant sur la vitesse de la lumière et les délais connus, par exemple dus à la disponibilité des antennes. Cela permet d'évaluer à partir de quand une non-réponse est le signe de données perdues. Il faudra alors retransmettre (section 3.2).

Le 14 septembre 2008, Le Trait a accueilli la seizième édition de la Fête du Cheval. Voici plusieurs photos.

I installed the operating system Ubuntu on a Dell Inspiron 7500 laptop machine. This article is to share the information that I obtained during the process.

While the basic functions are OK, there are problems. As often with laptops, even quite old machines, a lot of things do not work, or do not work out of the box.

De nombreux protocoles IETF s'appuient sur XML, par exemple pour stocker de l'information de configuration. Dans ce cadre, le besoin de modifier de l'information XML sans devoir transporter le fichier entier, en communiquant juste les différences, est fréquent.

Pour le texte brut, ce besoin est couvert depuis longtemps par le format diff / patch. Jusqu'à présent, il n'existait aucune norme équivalente pour XML. Plusieurs propositions de « langages de patch » pour XML ont été faites mais ce RFC est le premier où on atteint le stade de la normalisation.

Il a été développé au sein du groupe de travail Simple, qui normalise des extensions au protocole SIP (RFC 3261) et qui en avait besoin, entre autres, pour la mise à jour de configurations stockées en XCAP (RFC 4825). Mais il est très général et applicable à tous les domaines.

Le principe de cette technique est simple. La partie du document XML à modifier est identifiée par une expression XPath. Une fois cette partie localisée, du contenu est ajouté, modifié ou retiré, selon que le fichier de modifications contienne des éléments <add>, <replace> ou <remove> (la section 4 détaille chacun de ces éléments).

L'annexe A du RFC contient de nombreux exemples, en voici quelques uns pour illustrer :

   <diff>
     <add sel="/section"><para>Nouveau paragraphe, lorem, ipsum, dolor, etc</add>
   </diff>

Ce code ci-dessus ajoute un nouvel élément <para>. L'expression XPath pour localiser le point où l'ajouter est donnée par l'attribut sel. Ici, on ajoute le nouvel élément dans l'élément <section> de premier niveau.

 <diff>
     <replace sel="section[title='Bibliographie']">
         <bibliography>...</bibliography>
     </replace>
   </diff>

Ici, la section de titre « Bibliographie » est remplacée par un élément <bibliography>.

   
   <diff>
     <remove sel="article/section/para/text()"/>
   </diff>

Ici, le texte de l'élément <para> est supprimé.

La syntaxe complète de ce nouveau format est décrite dans la section 8, elle est exprimée en W3C Schema.

À noter qu'il existe déjà une mise en œuvre de ce format, xmlpatch. Voici un exemple d'utilisation avec un premier document toto.xml :

<article>
<abstract>Brouillon</abstract>
<section>
<title>Premier essai</title>
<para>À l'heure actuelle, on ne sait pas encore grand'chose.</para>
</section>
</article>

et sa deuxième version, totoplus.xml :

<article>
<section>
<title>Premier essai</title>
<para>Aujourd'hui, nous en savons bien plus.</para>
</section>
<section>
<title>Révélations</title>
<para>Nous avons même une seconde section.</para>
</section>
</article>

Appliquons xml_diff pour obtenir un fichier de différences, au format du RFC :

% xml_diff -f toto.xml -t totoplus.xml -o toto.xmlpatch

Ce fichier des différences contient :

<?xml version="1.0"?>
<x:changes xmlns:x="urn:xml-changes">
  <x:remove sel="*/*[1]" ws="after"/>
  <x:replace sel="*/*/*[2]/text()">Aujourd'hui, nous en savons bien plus.</x:replace>
  <x:add sel="*"><section>
<title>R&#xE9;v&#xE9;lations</title>
<para>Nous avons m&#xEA;me une seconde section.</para>
</section>
</x:add></x:changes>

Personnellement, je ne trouve pas les expressions XPath extraordinaires, elles manquent notamment de robustesse en cas de légers changements du document source. Mais elles sont correctes et on peut appliquer ce patch :

% xml_patch -f toto.xml -p toto.xmlpatch -o toto-patched.xml

et cela nous redonne un document qui a le même contenu que totoplus.xml. Attention, cela ne signifie pas qu'il soit identique au bit près (par exemple, les caractères UTF-8 de l'original ont été remplacés par des entités numériques XML) mais que son contenu informationnel (l'infoset XML) est le même.

Au passage, vous remarquerez que l'élement XML qui englobe les éléments patch n'est pas défini par le RFC. <diff> (dans les exemples du RFC) ou bien <changes> (dans l'exemple avec xml_patch) sont des choix arbitraires. Cela été fait ultérieurement dans le RFC 7351.

Dans la grande série des RFC décrivant les adresses de courrier internationalisées, ce document traite des modifications au protocole SMTP. Il a été remplacé quatre ans après par le RFC 6531 et n'est donc plus une lecture indispensable.

Plusieurs RFC composent la nouvelle norme EAI ou « Email Addresses Internationalized » (cf. RFC 4952, remplacé depuis par le RFC 6530). Les deux principaux concernent le format des messages (RFC 5335) et le dialogue entre deux serveurs de messagerie, suivant le protocole SMTP. Ce dernier cas est couvert dans notre RFC 5336.

Les adresses de courrier en Unicode ne sont pas en effet compatibles avec le SMTP « brut ». Ainsi, la commande RCPT TO qui permet d'indiquer le destinataire, ne prend en paramètre que de l'ASCII. Il faut donc étendre SMTP (actuellement normalisé en RFC 5321) pour permettre de l'UTF-8 en paramètre de commandes comme MAIL FROM et RCPT TO. Cette extension se signale avec l'option UTF8SMTP, dont l'usage permet de vérifier que le MTA situé en face comprend bien la nouvelle norme (sections 1 et 2 du RFC). Si ce n'est pas le cas, une adresse en ASCII facultative peut être utilisée.

La section 3 forme le gros du RFC en spécifiant rigoureusement le nouveau protocole. Voyons d'abord un exemple de dialogue SMTP avec la nouvelle extension (C est le client - l'appelant - et S le serveur - l'appelé) :

S: 220 mail.example.org ESMTP Foobar (Debian/GNU)
C: EHLO mail.iloveunicode.example 
S: 250-mail.example.org
 250-ENHANCEDSTATUSCODES
 250-8BITMIME
 250-UTF8SMTP
 250 DSN
C: MAIL FROM:<stéphane@internet-en-coopération.fr> ALT-ADDRESS=bortzmeyer@afnic.fr
S: 250 2.1.0 Ok
C: RCPT TO: <françoise@comptabilité.example.org>
S: 250 2.1.5 Ok

Notez les deux adresses, chacune comprenant des caractères non-ASCII, à gauche et à droite du @.

Les serveurs qui mettent en œuvre l'extension UTF8SMTP doivent également accepter la très ancienne extension 8BITMIME (RFC 1652) qui permet, depuis belle lurette, de ne pas se limiter à l'ASCII dans le contenu des messages, sans pour autant nécessiter des encodages comme Quoted-Printable (en dépit d'une légende tenace).

La section 3.1 présente la nouvelle extension, UTF8SMTP. Les extensions SMTP sont définies par le RFC 5321, section 2.2. Un MTA peut annoncer qu'il accepte UTF8SMTP, permettant à son pair, s'il l'accepte également, d'utiliser des adresses UTF-8. C'est également cette section qui définit ce que doit faire un MTA lorsqu'il tente de transmettre un message internationalisé à un ancien MTA qui ne gère pas cette extension. Quatre solutions sont possibles, la plus fréquente sera sans doute d'utiliser le mécanisme de repli (downgrade).

La section 3.3 décrit la nouvelle syntaxe pour les adresses. L'ancienne était limitée à ASCII mais très permissive (bien qu'on trouve, notamment derrière les formulaires Web, énormément de logiciels de « vérification » bogués). En gros, la syntaxe est qu'une adresse est formée de deux parties, la partie locale et le nom de domaine, tous les deux séparés par l'arobase. La nouveauté est que les deux parties peuvent désormais être en Unicode, avec peu de restrictions sur la partie locale (le nom de domaine étant soumis aux restrictions du RFC 3490).

Une adresse alternative tout en ASCII peut être fournie par le paramètre ALT-ADDRESS. C'est l'objet des sections 3.4 et 3.5. Elle doit s'utiliser conjointement à une modification du message (qui peut contenir des en-têtes en UTF-8) et l'ensemble du processus s'appelle le repli (downgrade). Sa spécification est publiée dans le RFC 5504. (Dans l'exemple de dialogue SMTP plus haut, seul l'expéditeur avait une adresse alternative.)

Il y a plein d'autres détails dans cette section, comme celui (section 3.7.1) que le paramètre de la commande EHLO (un nom de machine) doit être encodé en Punycode puisque, à ce stade, on ne sait pas encore si UTF8SMTP est accepté ou pas.

Je n'ai pas encore testé avec mes Postfix, ni vérifié quels étaient les plans des auteurs de ce logiciel vis-à-vis de cette extension de SMTP.

Dans l'ensemble des RFC sur l'internationalisation des adresses de courrier électronique, ce document traite le cas des accusés de réception et avis de non-remise (DSN pour Delivery Status Notification). Il est le prédécesseur du RFC 6533, la norme actuelle.

Puisque les RFC 5336 et RFC 5335 permettent désormais d'utiliser des adresses de courrier électroniques internationalisées, c'est-à-dire utilisant tout le jeu de caractères Unicode, il faut prévoir le cas où les courriers provoquent l'envoi d'avis de remise ou de non-remise (DSN pour Delivery Status Notification, RFC 3461 et RFC 3464) et d'accusés de réception (MDN, pour Message Disposition Notification, RFC 8098). C'est l'objet de ce RFC, qui met à jour les anciens documents qui limitaient ces accusés et avis au jeu ASCII.

Le format des DSN dans le RFC 3464 parle de « types d'adresse ». Les adresses en UTF-8 du RFC 5335 sont un nouveau type d'adresses. Si le serveur SMTP accepte l'extension UTF8SMTP du RFC 5336 et l'extension DSN du RFC 3461, il doit permettre d'utiliser ce type dans le paramètre ORCPT (Original Recipient, section 4.2 du RFC 3461). Si le serveur n'accepte pas UTF8SMTP, l'adresse à utiliser dans les DSN doit être encodée en 7bits, selon les règles exposées dans cette section 3 (et non pas selon les règles du RFC 5137, paru trop tard). Par exemple, stéphane@bortzmeyer.org peut s'écrire st\x{E9}phane@bortzmeyer.org. (La section 3 détaille plus complètement le traitement des adresses UTF-8.)

Une fois réglé le problème de la représentation des adresses, la section 4 traite les DSN en UTF-8. Les DSN traditionnels étaient composés d'un objet MIME de type multipart/report comportant trois objets décrivant le problème (un objet conçu pour être lu par un humain, un message/delivery-status et le message originel, message/rfc822). Pour le courrier internationalisé, de nouveaux types ont été créés :

• message/global-delivery-status qui, contrairement à son prédécesseur message/delivery-status, accepte l'UTF-8 et permet donc de placer directement les adresses UTF-8, sans encodage en ASCII. En outre, il dispose d'un nouveau champ, Localized-Diagnostic, qui permet de stocker des messages lisibles par un humain. La langue de ces messages est indiquée par une étiquette de langue (RFC 4646).
• message/global qui remplace message/rfc822 (dont le nom, hommage au vieux RFC 822, était de toute façon dépassé). À noter que le terme global (mondial) utilisé pour noter ce type avait fait l'objet de vives discussions et même d'un vote. Cet objet permet de transporter le message original (si on ne transporte que les en-têtes, on utilise message/global-headers.

On peut noter que la norme MIME (RFC 2046) interdisait l'usage de l'option Content-Transfer-Encoding pour les objets de type message/* mais cette règle a été assouplie par le RFC 5335.

La section 5 traite des MDN (Message Disposition NOtificatin, RFC 3798). Ils ne sont pas très différents des DSN et ont un format très proche, avec un type MIME message/global-disposition-notification.

La section 6 traite des registres IANA. Le type « UTF-8 » est ajouté au registre des types d'adresses (section 6.1), et les nouveaux types MIME comme message/global sont ajoutés au registre des types MIME (sections 6.3 à 6.5).

Enfin, la section 7 est dédiée aux questions de sécurité. Outre les problèmes de sécurité classiques des DSN et des MDN (non authentifiés, ils permettent de faire croire qu'un message a échoué, alors qu'il a bien été délivré, ou le contraire), le RFC nous prévient que des DSN ou des MDN délibérement incorrects peuvent être envoyés par un attaquant dans l'espoir de profiter d'erreur dans la programmation des analyseurs, par exemple pour déclencher un débordement de tampon. Le risque est plus important s'il y a beaucoup d'encodage, le décodage pouvant faire varier la taille des données.

Dans l'ensemble des RFC qui décrivent les adresses de courrier électronique internationalisées (c'est-à-dire pouvant utiliser tout le répertoire Unicode), celui-ci se consacre au nouveau format des en-têtes, mettant donc à jour le fameux RFC 2822 (en toute rigueur, il n'est mis à jour que par ceux qui participent à l'expérience, cf. section 1.2 du RFC). Il a été remplacé par la suite par le RFC 6532.

Désormais, on peut, si on participe à l'« expérience » (tel est son statut officiel) EAI (Email Address Internationalization), avoir dans un message un en-tête comme :

From: Stéphane Bortzmeyer <stéphane@sources.org>

Oui, avec du vrai UTF-8, y compris dans l'adresse proprement dite, pas seulement dans les commentaires, et encore, à condition de les surencoder selon le RFC 2047 comme c'était le cas avant.

L'éditeur du RFC travaille à TWNIC, le registre chinois de .tw. Les chinois ont, fort logiquement, été particulièrement actifs dans tout le processus EAI. Celui-ci visait à terminer l'internationalisation du courrier électronique, qui avait passé une étape décisive en novembre 1996, avec la sortie du RFC 2045 sur MIME. Mais cette norme MIME n'internationalisait que le corps des messages. EAI permet désormais d'internationaliser également les en-têtes comme From: ou Received: (mais pas, par exemple, Date: ou Message-ID:, qui resteront en ASCII pur, cf. section 4.3 ; Date:, par exemple, est censé être analysé par le MUA et présenté ensuite à l'utilisateur dans sa langue).

EAI comprend plusieurs RFC, par exemple à l'époque le RFC 4952 définit le cadre général, le RFC 5336, l'utilisation des adresses Unicode dans SMTP (avec l'extension UTF8SMTP), des futurs RFC qui traiteront le cas de POP ou IMAP et notre RFC 5335, qui se concentre sur le format des messages. Tous ont été remplacés en 2012 par la nouvelle série, autour du RFC 6530.

Concrètement, que change donc ce RFC ? La section 4 détaille ce qui est modifié :

• La grammaire ABNF qui décrit les en-têtes est changée (sections 4.1 et 4.3) pour accepter des caractères UTF-8, de préférence normalisés en NFC (cf. RFC 5198). Déjà très complexe, cette grammaire devient ainsi réellement difficile.
• La syntaxe des adresses (telles qu'on les trouve dans des en-têtes comme From: ou To:) est modifiée pour accepter UTF-8. Pour les sites qui utilisent une adresse électronique comme identificateur, comme le fait Amazon.com, ce sera un intéressant défi !
• Un nouveau type MIME est créé, message/global, pour permettre d'identifier un message EAI (section 4.6).

Parmi les conséquences pratiques de ce changement, il faut noter que les programmeurs qui écrivent des logiciels traitant le courrier doivent désormais gérer Unicode, même s'ils se contentent d'analyser les en-têtes... L'époque du courrier traité avec des scripts shell est bien passée.

La section 5 liste également quelques conséquences pour la sécurité comme le fait qu'un mécanisme d'authentification devra être prêt à gérer plusieurs adresses pour la même personne (car, pendant un certain temps, plusieurs utilisateurs auront à la fois une adresse en Unicode et une en ASCII pur).

Ce court RFC documente les types « MIME » (RFC 2045) à utiliser pour le format de fichiers multimédia Ogg, changeant sérieusement les anciens types du RFC 3534.

Dans un monde du multimédia dominé par des formats fermés comme WMF ou partiellement ouverts comme Flash (sans compter les innombrables et futiles brevets sur ces formats), Ogg, format maintenu par la fondation Xiph et décrit dans le RFC 3533, reste le principal format ouvert. Comme beaucoup de formats multimédia (par exemple AVI), Ogg ne permet que de créer des containers, des ensembles de flux de données, dont chacun a son propre format. Ainsi, un film stocké dans un container Ogg contiendra en général deux flux, un vidéo (typiquement au format Theora) pour l'image et un audio (typiquement au format Vorbis) pour le son. D'autres containers Ogg peuvent contenir plus de deux flux de données temporelles.

Cette façon de stocker les données complique un peu la définition d'un type de données pour étiqueter les containers Ogg, lorsqu'ils sont distribués par courrier électronique ou bien envoyés via le protocole HTTP. Le RFC originel, le RFC 3534, définissait un type unique, application/ogg. Le problème était qu'un container Ogg ne contenant que du son au format Vorbis se trouvait étiqueté avec le type très général application/ alors que le type audio/ aurait certainement mieux convenu. Notre RFC introduit donc deux nouveaux sous-types de video/ et audio/, soit video/ogg et audio/ogg, et redéfinit le type application/ogg.

La section 2 du RFC rappelle les changements depuis le RFC 3534, la principale étant ces deux nouveaux types.

La section 4 décrit les problèmes de compatibilité qui pourraient surgir avec les anciennes applications. Elle pose le principe que du contenu purement audio devrait être marqué avec le nouveau type audio/ogg (même chose pour la vidéo), réservant l'usage de application/ogg aux contenus plus complexes (par exemple dans le secteur scientifique, où ils sont plus fréquents que dans le monde du multimédia). Pour ces contenus, notre RFC impose l'extension Ogg Skeleton pour identifier les différents flux contenus. Elle décrit aussi l'utilisation du paramètre codecs qui permet de préciser le format des flux inclus, et donc le codec à utiliser. Ainsi, un flux Speex dans un fichier Ogg pourra être identifié par audio/ogg; codecs=speex. La section 5 du RFC précise davantage les relations entre les trois types désormais normalisés, du plus général, application/ogg au plus spécifique, audio/ogg.

La section 10 contient la « paperasse » nécessaire à l'enregistrement des trois types dans le registre IANA des types. La section 10.1 enregistre application/ogg, recommandant l'extension de fichier .ogx (.ogg étant souvent utilisé uniquement pour l'audio).

10.2 définit video/ogg (extension .ogv) et 10.3 audio/ogg, qui garde l'extension « historique » .ogg.

Ogg dispose d'une mise en œuvre de référence, sous une licence libre, la libogg (section 8 du RFC, sur l'interopérabilité).

Notons enfin une section 7 du RFC consacrée à la sécurité et qui donne quelques avertissements utiles : si Ogg en lui-même n'est qu'un format et ne pose pas de problème de sécurité en soi, certains contenus d'un fichier Ogg peuvent être exécutables et poser alors de redoutables problèmes de sécurité comme l'ont montré les nombreuses alertes de sécurité qui concernaient Flash. Ces contenus ne devraient pas être exécutés sans une validation (par exemple une signature électronique, service non fourni actuellement par Ogg lui-même mais qui peut être utilisé sur les flux transportés dans un container).

D'autre part, les contenus multimédia sont souvent de grande taille et des attaques par déni de service indirect sont toujours possibles, par exemple en envoyant une image qui, après décompression, sera ridiculement grande, ou un flux audio avec un rythme d'échantillonage impossible à suivre. Les programmes qui lisent les fichiers multimédia doivent donc être prudents.

I installed the operating system Ubuntu on a Packard-Bell EasyNote MX37 laptop machine. This article is to share the information that I obtained during the process.

While the basic functions are OK, there are problems. As often with laptops, especially very recent machines, a lot of things do not work, or do not work out of the box.

Une des particularités d'IPv6 est de disposer d'un mécanisme, l'autoconfiguration sans état qui permet à une machine de se fabriquer une adresse IP globale sans serveur DHCP. Ce mécanisme crée typiquement l'adresse IP à partir de l'adresse MAC de la machine et une même machine a donc toujours le même identifiant (les 64 bits les plus à droite de l'adresse IPv6), même si elle change de réseau et donc de préfixe. Il est donc possible de « suivre à la trace » une machine, ce qui peut poser des problèmes de protection de la vie privée. Notre RFC fournit une solution, sous forme d'un mécanisme de création d'adresses temporaires, partiellement aléatoires. (Elle a depuis été assez sérieusement révisée et améliorée dans le RFC 8981.)

L'autoconfiguration sans état, normalisée dans le RFC 4862 est souvent présentée comme un des gros avantages d'IPv6. Sans nécessiter de serveur central (contrairement à DHCP), ce mécanisme permet à chaque machine d'obtenir une adresse globale (IPv4, via le protocole du RFC 3927, ne permet que des adresses purement locales) et unique. Cela se fait en concaténant un préfixe (par exemple 2001:db8:32:aa12::), annoncé par le routeur, à un identifiant d'interface (par exemple 213:e8ff:fe69:590d, l'identifiant de mon PC portable - les machines individuelles, non partagées, comme les PDA sont particulièrement sensibles puisque la connaissance de la machine implique celle de son maître), typiquement dérivé de l'adresse MAC.

Partir de l'adresse MAC présente des avantages (quasiment toute machine en a une, et, comme elle est unique, l'unicité de l'adresse IPv6 est obtenue facilement) mais aussi un inconvénient : comme l'identifiant d'interface est toujours le même, cela permet de reconnaître une machine, même lorsqu'elle change de réseau. Dès qu'on voit une machine XXXX:213:e8ff:fe69:590d (où XXXX est le préfixe), on sait que c'est mon PC.

La solution initiale de ce problème avait été introduite par le RFC 3041, que notre RFC 4941 met à jour.

Les sections 1.2 et 2 du RFC décrivent le problème plus en détail. Elles notent entre autre que le problème n'est pas aussi crucial que l'avaient prétendu certains (une véritable campagne anti-IPv6 avait été montée à une époque par des gens mal informés). En effet, il existe bien d'autres façons, parfois plus faciles, de suivre une machine à la trace, par exemple par les fameux petits gâteaux de HTTP mais aussi par des moyens de plus haute technologie comme les caractéristiques matérielles de l'ordinateur, que l'on peut observer sur le réseau. Parmi les autres méthodes, notons aussi que si on utilise les adresses temporaires de notre RFC 4941 mais qu'on configure sa machine pour mettre dynamiquement à jour un serveur DNS avec cette adresse, le nom de domaine suffirait alors à suivre l'utilisateur à la trace !

La section 2.2, consacrée à la situation actuelle avec IPv4, fait d'ailleurs remarquer que la situation n'est pas parfaite avec IPv4 non plus, et que certains articles qui sonnaient l'alarme contre les dangers de IPv6 étaient donc vraiment peu informés. Aujourd'hui, en pratique, beaucoup de machines ont une adresse IPv4 qui change peu ou pas et elles sont donc plus vulnérables au « pistage » (sauf si elles changent de réseau souvent) que les machines IPv6 utilisant ce RFC 4941.

La section 2.4 commence à discuter des solutions possibles. DHCPv6 (RFC 3315, notamment la section 12) serait évidemment une solution, mais qui nécessite l'administration d'un serveur. L'idéal serait une solution qui permette, puisque IPv6 facilite l'existence de plusieurs adresses IP par machine, d'avoir une adresse stable pour les connexions entrantes et une adresse temporaire, non liée à l'adresse MAC, pour les connexions sortantes, celles qui « trahissent » la machine. C'est ce que propose notre RFC, en générant les adresses temporaires selon un mécanisme pseudo-aléatoire.

Enfin, la section 3 décrit le mécanisme de protection lui-même. Il y a deux cas, celui où on dispose d'un mécanisme de stockage des données, par exemple une mémoire Flash et celui où l'appareil, trop simple, n'a pas un tel mécanisme.

Le premier cas est détaillé dans la section 3.2.1 : on stocke une « valeur historique » à chaque génération d'une adresse. On utilise la valeur précédente, on la concatène à l'identifiant d'interface et on passe le tout à travers MD5. Les 64 premiers bits du résumé MD5 formeront le suffixe de l'adresse IPv6. La faiblesse cryptographique de MD5 n'est pas un problème, on ne cherche pas ici à résister à une attaque, juste à condenser un nombre aléatoire. Il n'est pas nécessaire que toutes les machines utilisent la même fonction de hachage et l'usage d'autres algorithmes que MD5 est donc autorisé.

La section 3.2.2 traite des cas où un dispositif de stockage n'existe pas et recommande alors l'usage d'une source réellement aléatoire, selon le RFC 4086.

Une fois l'adresse temporaire générée (les détails sont dans la section 3.3), il faut la renouveler de temps en temps (sections 3.4 et 3.5, cette dernière expliquant pourquoi renouveler une fois par jour est plus que suffisant). L'ancienne adresse peut rester active pour les connexions en cours mais plus pour de nouvelles connexions.

Maintenant que l'algorithme est spécifié, la section 4 du RFC reprend de la hauteur et examine les conséquences de l'utilisation des adresses temporaires. C'est l'occasion de rappeler un principe de base de la sécurité : il n'y a pas de solution idéale, seulement des compromis. Si les adresses temporaires protègent davantage contre le « flicage », elles ont aussi des inconvénients comme de rendre le débogage des réseaux plus difficile. Par exemple, si on note un comportement bizarre associé à certaines adresses IP, il sera plus difficile de savoir s'il s'agit d'une seule machine ou de plusieurs.

L'utilisation des adresses temporaires peut également poser des problèmes avec certaines pratiques prétendument de sécurité comme le fait, pour un serveur, de refuser les connexions depuis une machine sans enregistrement DNS inverse (un nom correspondant à l'adresse, via un enregistrement PTR). Cette technique est assez ridicule mais néanmoins largement utilisée.

Un autre conflit se produira, note la section 7, si des mécanismes de validation des adresses IP source sont en place dans le réseau. Il peut en effet être difficile de distinguer une machine qui génère des adresses IP temporaires pour se protéger contre les indiscrets d'une machine qui se fabrique de fausses adresses IP source pour mener une attaque.

Quelles sont les différences entre le RFC originel, le RFC 3041 et celui-ci ? Peu importantes, elles sont résumées dans la section 8. Les principales sont des demandes plus fortes sur la configurabilité de l'usage des adresses temporaires, l'acceptation explicite d'autres fonctions de hachage que MD5 et surtout le fait que le réglage standard par défaut doit désormais être de couper l'usage des adresses IP temporaires. En revanche, les changements ont été davantage prononcés avec la mise à jour suivante de cette technique, dans le RFC 8981.

Sur MS-Windows, ce mécanisme semble avoir été implémenté depuis Vista.

Sur Linux, notre RFC est mis en œuvre depuis longtemps (c'est l'option CONFIG_IPV6_PRIVACY de compilation du noyau), mais désactivé par défaut, comme demandé par le RFC (section 3.6). Le paramètre sysctl qui contrôle ce protocole est net.ipv6.conf.XXX.use_tempaddr où XXX est le nom de l'interface réseau, par exemple eth0. En mettant dans le fichier /etc/sysctl.conf :

# Adresses temporaires du RFC 4941
net.ipv6.conf.default.use_tempaddr = 2

On met en service les adresses temporaires, non « pistables » pour toutes les interfaces (c'est le sens de la valeur default). Il y a plusieurs pièges, très bien expliqués par Pascal Hambourg : au moment où le sysctl.conf est lu, le module noyau ipv6 n'est pas forcément chargé. Et certaines interfaces ont pu être configurées avant, alors que default ne s'applique qu'aux futures interfaces. Pour s'assurer que les réglages soient bien pris en compte, il vaut mieux faire en sorte que le module ipv6 soit chargé tout de suite (sur Debian, le mettre dans /etc/modules) et que les interfaces fixes aient leur propre réglage. Par exemple, sur Debian, on peut mettre dans /etc/network/interfaces :

iface eth2 inet dhcp
   pre-up sysctl -w net.ipv6.conf.eth2.use_tempaddr=2

Ou alors il faut nommer explicitement ses interfaces :

net.ipv6.conf.eth0.use_tempaddr = 2

Le comportement du noyau Linux face à ces options est souvent surprenant. Voir par exemple la bogue #11655. Notez aussi qu'ifconfig n'affiche pas quelles adresses sont les temporaires (mais ip addr show le fait).

Notons que l'adresse « pistable » est toujours présente mais vient s'y ajouter une adresse temporaire choisie au hasard. Selon les règles du RFC 6724, rappelées dans la section 3.1 de notre RFC, c'est cette adresse temporaire qui sera choisie, en théorie, pour les connexions sortantes. Avec Linux, il faut pour cela que use_tempaddr vale plus que un (sinon, l'adresse temporaire est bien configurée mais pas utilisée par défaut). ifconfig affichera donc :

wlan0     Link encap:Ethernet  HWaddr 00:13:e8:69:59:0d  
...
          inet6 addr: 2001:db8:32:aa12:615a:c7ba:73fb:e2b7/64 Scope:Global
          inet6 addr: 2001:db8:32:aa12:213:e8ff:fe69:590d/64 Scope:Global

puis, au démarrage suivant, l'adresse temporaire (la première ci-dessus) changera :

wlan0     Link encap:Ethernet  HWaddr 00:13:e8:69:59:0d
...
          inet6 addr: 2001:db8:32:aa12:48a9:bf44:5167:463e/64 Scope:Global
          inet6 addr: 2001:db8:32:aa12:213:e8ff:fe69:590d/64 Scope:Global

Sur NetBSD, il n'y a qu'une seule variable syscvtl pour toutes les interfaces. Il suffit donc de mettre dans /etc/sysctl.conf :

net.inet6.ip6.use_tempaddr=1

Par contre, je n'ai pas trouvé comment faire que l'adresse temporaire soit utilisée par défaut. Sur FreeBSD, je n'ai pas essayé, mais je suppose que les variables sysctl au nom bien parlant net.inet6.ip6.use_tempaddr et net.inet6.ip6.prefer_tempaddr sont là pour cela.

Ceux qui veulent configurer ce service sur une machine Linux peuvent aussi lire Stateless Network Auto Configuration With IPv6 ou IPv6 privacy extensions on Linux. Sur les autres systèms, je suggère Enabling Privacy Enhanced Addresses for IPv6.

Dans beaucoup de protocoles réseau, ce qui passe « sur le câble » est dans un format binaire incompréhensible pour un humain. Il est souvent utile de pouvoir le représenter sous forme texte, par exemple lorsque des programmes comme tcpdump le décodent. C'est encore mieux si ce format texte est normalisé, cela permet la communication facile entre humains. Regardons quelques exemples surtout empruntés à la famille TCP/IP. Ce sera l'occasion de voir que la syntaxe des adresses IPv4 n'a jamais été normalisée...

Le protocole de cryptographie TLS, autrefois nommé SSL, est un des protocoles de l'IETF les plus utilisés. À chaque seconde, des milliers de connexions TCP, en général HTTP, sont protégées contre l'écoute, et même parfois authentifiées par TLS. Ce RFC met à jour l'ancienne norme, le RFC 4346. (Depuis, la version 1.3, très différente, a été normalisée dans le RFC 8446.)

Aujourd'hui, plus personne n'aurait l'idée de faire circuler un mot de passe en clair sur le réseau, car il serait très facile à capturer (par exemple avec un programme comme dSniff). TLS fournit la confidentialité à une connexion TCP. (TLS peut aussi fonctionner avec d'autres protocoles de transport comme SCTP - RFC 3436 ou bien UDP - RFC 6347.)

L'authentification par mot de passe a par ailleurs des défauts, notamment que le mot de passe soit réutilisable. Si l'utilisateur a été victime d'un faux serveur, par exemple par suite d'un hameçonnage, il donne son mot de passe et le méchant qui contrôle le faux serveur peut l'utiliser sur le vrai site. Pour traiter ce problème, TLS fournit une solution d'authentification reposant sur les certificats X.509 ou bien sur les clés OpenPGP (RFC 5081). TLS permet aussi bien au client d'authentifier le serveur qu'au serveur d'authentifier le client (cette deuxième possibilité est à l'heure actuelle peu utilisée).

Les certificats X.509 sont composés de la partie publique d'une clé asymétrique et de métadonnées, comme la date d'expiration. Ils sont signés par une CA, qui a elle-même un certificat signé par une CA et ainsi de suite jusqu'à arriver aux CA racines installés dans le logiciel. La plupart du temps, l'utilisateur n'a jamais examiné ces certificats des CA racine et n'a aucune idée de leur fiabilité. C'est l'un des gros points faibles de l'authentification par TLS / X.509.

TLS n'est pas une solution miracle, il n'en existe pas en sécurité informatique. Par exemple, TLS ne protège pas dans les cas suivants :

• Si un programme espion tourne sur la machine de l'utilisateur (ce qui est le cas de beaucoup, peut-être la plupart des machines MS-Windows),
• Si le serveur est méchant ou mal protégé. Par exemple, un numéro de Carte Bleue transmis par TLS n'est protégé que pendant le voyage ! Si le serveur à l'autre bout stocke ces numéros et se fait pirater, TLS n'y pourra rien.

Passons maintenant au RFC proprement dit. Il fait plus de cent pages et pourtant de nombreux points n'y sont pas, comme la définition des algorithmes cryptographiques utilisés. La sécurité est un domaine compliqué, d'autant plus qu'une petite erreur peut annuler toute la sécurité de même que l'oubli de fermer à clé peut rendre inutile une lourde porte blindée.

TLS est composé de deux parties (section 1 du RFC), le Record Protocol, protocole de bas niveau qui transmet des messages en les chiffrant pour la confidentialité et l'intégrité et le Handshake protocol, bâti sur le premier, et qui se charge entre autres de négocier les paramètres de la session.

En effet, TLS fonctionne en négociant au début un algorithme de chiffrement ainsi qu'une clé cryptographique de cet algorithme pour la session. Le Record protocol va ensuite chiffrer les messages avec cette clé.

La section 4 du RFC détaille le langage de présentation. L'IETF n'a pas de langage unique de spécification, chaque RFC utilise des outils différents pour décrire ses protocoles ou algorithmes. TLS crée donc le sien, proche du C. Par exemple la section 4.4 décrit les nombres, tous créés à partir d'un type unit8, qui stocke un octet. La section 4.5 décrit les types énumérés comme enum { null, rc4, 3des, aes } BulkCipherAlgorithm; (le type qui sert à définir les valeurs de l'algorithme de cryptographie symétrique).

La section 6 décrit en détail le Record protocol. C'est un protocole qui va effectuer le chiffrement, mais aussi la compression, la fragmentation, etc.

La section 7 couvre le protocole de négociation (Handshake protocol). C'est le protocole qui permet l'authentification du serveur par le client (ou, plus rarement, le contraire) et la sélection des options, par exemple l'algorithme de chiffrement utilisé. L'authentification se fait en général en présentant un certificat X.509, certificat signé par un tiers de confiance (RFC 5280, en pratique, le tiers « de confiance » est une des CA installées par défaut avec le logiciel, dont personne ne sait pourquoi elles ont été choisies). Voici par exemple le résultat de ce protocole, tel qu'affiché par la commande gnutls-cli (qui est livrée avec GnuTLS) :

% gnutls-cli -d 9 www.example.org
Connecting to '192.0.2.20:443'...
...
|<3>| HSK[80708e8]: Selected cipher suite: DHE_RSA_AES_256_CBC_SHA

Le chiffrement AES en mode CBC a été choisi. gnutls-cli permet de voir le passage de tous les messages TLS de ce protocole, tels qu'ils sont décrits dans la section 7.4 :

      enum {
          hello_request(0), client_hello(1), server_hello(2),
          certificate(11), server_key_exchange (12),
          certificate_request(13), server_hello_done(14),
          certificate_verify(15), client_key_exchange(16),
          finished(20), (255)
      } HandshakeType;

Comme précisé dans la section 7.3, ce protocole de négociation a aussi ses propres vulnérabilités. Au démarrage, il n'y a évidemment pas d'algorithme de chiffrement ou de clé de session sélectionnés. Comme le précise la section 7.4.1, TLS démarre donc sans chiffrement. Un attaquant actif, capable de modifier les paquets IP, peut changer la liste des algorithmes acceptés, avant que le chiffrement ne soit actif, de façon à sélectionner un algorithme faible. (Le remède est de refaire la négociation une fois le chiffrement activé.)

Comme souvent avec TLS, le protocole est extensible. La section 7.4.1.4 décrit par exemple les extensions à l'annonce que font les machines TLS, possibilité qui est utilisée dans le RFC 5081 pour ajouter les clés OpenPGP aux certificats X.509. (Les extensions existantes étaient initialement décrites dans le RFC 4366 et sont désormais dans le RFC 6066. Le registre complet des extensions est maintenu à l'IANA.)

La section 9 indique l'algorithme de chiffrement obligatoire, RSA avec AES. Il est nécessaire de définir un algorithme obligatoire, autrement, deux mises en œuvre légales de TLS pourraient être incompatibles si les deux ensembles d'algorithmes n'avaient aucun élément en commun.

Par rapport à son prédécesseur, le RFC 4346, qui normalisait TLS 1.1, les changements sont de peu d'importance (la liste figure en section 1.2). Un client TLS 1.2 peut interagir avec un serveur 1.1 et réciproquement (voir l'annexe E pour les détails.) Il s'agit en général de clarifications ou bien du changement de statut de certains algorithmes cryptographiques. En effet, la cryptographie bouge et certains algorithmes, qui paraissaient solides à une époque, sont vulnérables aux attaques modernes (c'est par exemple ce qui est arrivé à MD5 et SHA1). C'est pour cela que l'algorithme « RSA avec AES » fait désormais partie des algorithmes obligatoires et que par contre IDEA et DES sont partis.

Contrairement à IPsec (RFC 4301), TLS fonctionne entre la couche de transport et les applications. Il n'est donc pas invisible aux applications, qui doivent être explicitement programmées pour l'utiliser. Pour cela, il n'existe malheureusement pas d'API standard. OpenSSL, l'implémentation la plus populaire de TLS, a la sienne, son concurrent GnuTLS en a une autre, etc. (GnuTLS dispose d'une couche d'émulation de OpenSSL mais elle est incomplète.)

Un programme comme echoping qui peut utiliser aussi bien OpenSSL que GnuTLS, doit donc recourir aux services du préprocesseur C, par exemple :

#ifdef OPENSSL
        ...
        SSL_set_fd(sslh, sockfd);
        if (SSL_connect(sslh) == -1)
#endif
#ifdef GNUTLS
...
        gnutls_transport_set_ptr(session, 
                                 (gnutls_transport_ptr) (long) sockfd);
        tls_result = gnutls_handshake(session);
...
#ifdef OPENSSL
        if ((rc = SSL_write(sslh, sendline, n)) != n) {
...
#ifdef GNUTLS
        if ((rc = gnutls_record_send(session, 
                                     sendline, strlen (sendline))) != n) {
...

Une autre solution pour une application qui veut faire du TLS sans se fatiguer est de compter sur le fait que TLS est indépendant du protocole utilisé par l'application et qu'on peut donc simplement créer un tunnel TLS, par exemple avec stunnel. Ainsi, on n'a même pas besoin de modifier le source de l'application.

Le déploiement de protocoles est toujours lent dans l'Internet. TLS 1.2, décrit dans ce RFC, ne s'est retrouvé dans le navigateur Firefox que cinq ans après.

Quand deux routeurs BGP échangent des routes, il est fréquent que certaines soient refusées par le routeur récepteur, par exemple parce qu'ils les estime invalides ou parce qu'elles ne correspondent pas à ses politiques de routage (section 2 du RFC). C'est donc un gaspillage que de les envoyer et ce nouveau RFC permet au routeur récepteur de signaler à l'avance à son pair BGP quelles routes il n'acceptera pas.

BGP, normalisé dans le RFC 4271 est le protocole d'échange de routes dans l'Internet. Pratiqué surtout entre organisations distinctes, il permet de faire du routage politique, cest-à-dire de rejeter certaines routes en fonction de la politique de chaque organisation. Pour cela, les routeurs BGP mettent typiquement en œuvre des filtres sur les routes reçues. Avec notre RFC, ces filtres peuvent être transmis au routeur pair sous le nom d'ORF (Outbound Route Filters) que le pair appliquera sur le jeu de routes qu'il allait annoncer, supprimant de ce jeu les routes qui ne conviennent pas à son pair.

La section 3 détaille ce qu'est un ORF. C'est un tuple composé de :

• l'AFI/SAFI (qui permet notamment d'indiquer si la route concerne IPv4 ou bien IPv6), termes définis dans le RFC 4760.
• le type d'ORF, qui sera enregistré dans un registre IANA (pas encore peuplé, cf. section 7).
• l'action à effectuer sur cet ORF, typiquement ADD (l'ajouter à la liste) ou REMOVE (le supprimer).
• la politique à appliquer aux routes qui corrspondent à ce critère (PERMIT ou DENY).
• Et la valeur, dont le contenu dépend de l'AFI/SAFI, c'est typiquement un préfixe réseau.

La section 4 explique ensuite comment encoder les ORF et les transmettre dans une session BGP. Les sections 5 et 6 précisent que le routeur qui gère les ORF doit l'annoncer (cf. RFC 5492) par la capacité BGP n° 3 Outbound Route Filtering Capability.

Le protocole MPLS de commutation de paquets selon une étiquette (label) utilise souvent LDP comme mécanisme d'attribution des étiquettes. LDP ne fonctionnait bien qu'à l'intérieur d'une même zone du système autonome et ce nouveau RFC étend LDP pour le cas où on dispose de plusieurs zones.

La section 1 du RFC explique la motivation pour cette modification : un certain nombre d'opérateurs ont tiré profit du caractère hiérarchique de protocoles de routage internes comme OSPF ou IS-IS pour créer plusieurs zones (areas) dans leur système autonome. Ce découpage en zones (section 3 du RFC 2328) permet de gérer des très grands systèmes autonomes, en évitant que chaque routeur connaisse tout le réseau.

Mais, sur les réseaux MPLS utilisant LDP, pour qu'un routeur qui reçoit une correspondance entre une étiquette MPLS et une FEC (Forwarding Equivalent Class, section 2.1 du RFC 3031) la prenne en compte, la norme LDP (section 3.5.7.1 du RFC 5036) impose que la table de routage du routeur possède une entrée qui corresponde exactement cette FEC. Par exemple pour monter un tunnel MPLS, le routeur MPLS doit avoir dans sa table une route avec une correspondance exacte avec le point de sortie du tunnel, c'est-à-dire en IPv4 le préfixe en /32 ; avoir une route en /24 qui couvrirait ce /32 ne suffit pas.

En pratique, sur les réseaux MPLS utilisant LDP et qui ont un IGP multi-zones, monter des tunnels vers ou depuis des routeurs appartenant à d'autres zones nécessitait donc des bricolages comme l'annonce des adresses (préfixes en /32 ou bien /128 en IPv6) dans tous les sens entre tout plein de zones en passant aussi par la zone qui sert d'épine dorsale, ce qui est très lourd à gérer et rend l'intérêt des zones douteux. Elles avaient justement été conçues pour éviter de transporter des détails internes à une zone, en agrégeant les annonces de préfixes...

La section 4 du RFC détaille le problème, notamment dans le cas de tunnels (RFC 4364, RFC 4761 et RFC 4762). La section 6 fournit des exemples, avec de jolis dessins.

La section 5 présente la solution. Notre RFC 5283 permet donc désormais de faire accepter à LDP des associations étiquette/FEC pour lesquelles le LSR (le routeur MPLS) aurait des routes moins spécifiques, par exemple parce qu'elles ont été agrégées. C'est donc simplement l'application de la traditionnelle règle IP de la « meilleure correspondance » (longest match) à la sélection d'une étiquette MPLS.

L'ancienne règle continue à s'appliquer par défaut (le RFC impose que la nouvelle extension ne soit pas activée automatiquement). En effet, si on arrête de publier les préfixes les plus spécifiques, il faut que tous les routeurs MPLS de la zone acceptent l'extension. Elle est donc déployable de manière progressive (section 7.1) mais à condition de faire attention.

Merci à Sarah Tharan pour ses explications détaillées sur cette extension.

3GPP dispose désormais d'une famille d'URN, identifiée par le NID (Namespace IDentifier) 3gpp.

3GPP est un groupe de normalisation privé, composé de fournisseurs de systèmes de téléphonie mobile (section 1). Ses activités nécessitent des identificateurs stables et 3GPP a choisi les URN (RFC 8141).

La description complète de leurs URN apparait dans la section 2 du RFC et est également documentée en ligne en http://www.3gpp.org/tb/Other/URN/URN.htm.

La section 3 donne quelques exemples de ces nouveaux URN comme urn:3gpp:featurephones ou bien urn:3gpp:acme.foo-serv (cette seconde URN utilisant un système hiérarchique, non documenté dans le RFC, où « acme » est un opérateur et « foo-serv » un de ses services).

L'Internet a toujours fonctionné sur le principe du « fais au mieux » (best effort), c'est-à-dire que les applications qui l'utilisent n'ont aucune garantie sur les caractéristiques quantitatives du réseau qui sera à leur disposition. Le débit, par exemple, ne peut pas être connu à l'avance ; lorsqu'on commence un transfert de fichiers, on ne sait pas quand il se terminera. Ce principe a assuré le succès de l'Internet, par rapport à des réseaux concurrents qui se vantaient de leurs « garanties de qualité de service » et qui, en conséquence, offraient un service moyen nettement inférieur. Mais il est contesté par certains qui voudraient la possibilité de garantir une « qualité de service » (QoS pour « Quality of Service ») dans le réseau. Ce nouveau RFC ne tranche pas sur la question de savoir si la QoS est une bonne idée ou pas, il rappelle uniquement l'intérêt qu'il y a à disposer d'un mécanisme équivalent au « fais au mieux », une offre très efficace et qui correspond à beaucoup d'usages.

À l'époque où l'Internet avait du mal à s'imposer face aux réseaux prônés par les gens des télécommunications, appuyés par les gouvernements, un des reproches qui lui étaient le plus souvent fait était de ne pas garantir de « qualité de service » (QoS). Avant un appel téléphonique avec SIP, en effet, on ne peut pas savoir quel sera la capacité disponible, quel sera le RTT ou quelle sera la gigue. On peut les mesurer mais rien ne garantit que ces grandeurs resteront constantes pendant l'appel. Cela peut gêner certaines applications. C'est pour cela que des mécanismes visant à gérer la QoS ont été développés sur Internet comme intserv (RFC 1633) ou bien diffserv (RFC 2475). En pratique, ces mécanismes ont été très peu déployés, ce qui relativise la soi-disant demande de QoS. En général, il est moins coûteux d'augmenter le débit des tuyaux que de déployer ces mécanismes complexes. Mais certains vont plus loin et réclament le déploiement généralisé de QoS dans Internet, au point de ne plus garder de service « fais au mieux ». C'est là qu'intervient notre RFC 5290.

Sa thèse de base est que le socle de l'Internet doit rester un service « fais au mieux » (quitte à ajouter quelques mécanismes de QoS par dessus). Ce service est défini comme « tout ce qui ne bénéficie pas d'un service différencié » (section 1). Un moyen simple d'assurer ce service est l'« équité entre les flux » (flow-rate fairness).

La section 2 expose les propriétés de ce service simple best effort. En 2.1, les auteurs listent les forces de ce service :

• Il ne demande pas trop d'efforts de la part de l'infrastructure réseau : les routeurs, par exemple, ont ainsi le minimum de travail. Ce service libère ainsi des ressources pour, par exemple, augmenter la capacité (les réseaux télécoms traditionnels passaient tellement de temps à gérer la QoS que leur débit total était sérieusement réduit).
• Il ne demande pas trop de mécanismes économiques entre les opérateurs. Une des principales raisons du très faible déploiement de diffserv est qu'il nécessite des mécanismes de compensation entre opérateurs. Autrement, tout le monde enverrait ses paquets avec la classe la plus favorisée ! Ces compensations sont complexes et nécessitent des accords entre opérateurs qui vont plus loin que les mécanismes actuels entre opérateurs, ou entre un opérateur et son client.
• Et, surtout, ce service « fais au mieux » est utile dans le monde réel. Il marche, pour une grande variété d'applications, et il propulse l'Internet depuis trente ans, malgré les affirmations (qu'on trouve par exemple dans la quasi-totalité des ouvrages universitaires sur les réseaux informatiques publiés en France) comme quoi un réseau sans QoS ne servait à rien.

Évidemment, tout n'est jamais uniformément rose. Le service « fais au mieux » a aussi des limites, que détaille la section 2.2. D'abord, certains utilisateurs veulent de la QoS et sont prêts à payer pour cela (section 2.2.1). Il ne faut pas les en priver mais cette demande soulève des questions très diverses. Par exemple, l'ensemble des ressources réservées pour les services « à garantie » ne doit pas mener à l'épuisement des ressources pour le service de base, autrement les riches utilisateurs pourraient s'approprier tout le réseau pour eux. Il existe une abondante littérature (le RFC donne quelques références) sur l'économie de l'Internet, la légitimité et l'efficacité de faire payer de manière différenciée, etc. Ensuite, les services avec QoS peuvent interférer avec la « transparence du réseau ». En effet, il n'est pas difficile d'imaginer des cas où, pour certaines applications, celui qui ne paierait pas le surcoût de la QoS serait, en pratique, exclu du réseau. Mais le débat est loin d'être clos sur la question de savoir quel niveau de QoS reste compatible avec cette transparence du réseau. (Le RFC 2990 donne des éléments de départ sur l'architecture de QoS.)

Une autre faiblesse du « fais au mieux » est sa sensibilité aux incivilités (section 2.2.2). Si un certain nombre d'utilisateurs ne jouent pas le jeu, le réseau peut s'effondrer puisqu'il n'y a pas de limites à l'allocation de ressources. Dans cette optique, les services différenciés ne seraient pas tant un moyen de « donner plus à ceux qui paient plus » qu'un mécanisme de contrôle de la congestion, même en présence d'implémentations « agressives » de TCP/IP, qui ne respecteraient pas les règles énoncées dans le RFC 2914.

Enfin, la dernière faiblesse (section 2.2.3) est le cas de « pics » de trafic brutaux (suite à une DoS ou tout simplement en cas de grand succès d'un site Web), pour lesquels le mécanisme « fais au mieux » mène en général à ce que personne ne soit servi...

Après ce tour des forces et faiblesses du mécanisme « fais au mieux », le RFC aborde, dans la section 3, le concept d'« équité entre les flux ». L'idée est que cette équité ne serait certes pas parfaite, mais assurerait un service « fais au mieux » qui soit convenable pour tout le monde. Notre RFC paraphrase Winston Churchill en disant que l'équité entre les flux est le plus mauvais des services, à l'exception de tous les autres.

En effet (section 3.1), cette équité serait relativement facile à mettre en œuvre (pour TCP, qui forme la grande majorité du trafic actuel, elle est déjà implémentée dans ses algorithmes), elle ne nécessite pas de calculs de facturation complexes, elle marche aujourd'hui et elle satisfait une notion sommaire, mais raisonnable, de la « justice » puisque chaque flot aura une part de la capacité du réseau.

Elle a par contre des limitations (section 3.2). Elle est difficile à faire respecter (section 3.2.1). En effet, dans l'Internet actuel, son respect dépend des machines aux extrémités du réseau, machines qui sont sous le contrôle d'un utilisateur qui peut être un méchant égoïste. Changer ce système pour que les routeurs fassent le contrôle serait un changement considérable d'architecture. Et, après tout, l'Internet s'en est passé jusqu'à présent.

Une deuxième question est qu'il n'existe pas de définition claire et consensuelle de ce qu'est l'équité entre les flux. Tout le monde est pour l'équité, c'est lorsqu'on essaie de la définir que les ennuis commencent (section 3.2.2). D'abord, « flux » (flow) n'est pas bien défini (cf. RFC 2309, RFC 2914, RFC 3124 et bien d'autres). Est-ce par connexion ? (Un concept qui n'existe pas pour tous les protocoles, par exemple UDP.) Ou bien pour tout trafic entre deux machines ? Ou bien, à une granularité intermédiaire, faut-il mettre toutes les connexions TCP démarrées par le même navigateur Web ou bien le même client BitTorrent dans le même flux ? Et l'équité doit-elle se mesurer en nombre de paquets ou en octets/seconde ? (Les protocoles interactifs comme SSH préféreraient certainement la première solution.) Et que faire avec les protocoles où le trafic tend à être très irrégulier ? Faut-il une équité « en moyenne » ? Si oui, sur quelle période ? Bref, si l'objectif politique est clair, le traduire en chiffres précis semble très difficile.

La section 4 du RFC 5290 s'attaque à un problème sur lesquels bien des protocoles se sont brisés : le déploiement. Pour reprendre l'exemple traditionnel du fax, celui qui a acheté le premier fax a fait preuve d'une confiance aveugle dans le succès de la technologie. Son fax ne lui servait à rien. Ce n'est qu'une fois qu'un nombre suffisant d'acheteurs s'en sont procuré un que son achat avait un sens. De même, une bonne partie des difficultés d'IPv6 s'explique par cet effet « œuf et poule ». Les premiers à déployer IPv6 n'ont aucun intérêt à le faire (ils ne pourront communiquer avec personne). Résultat, le déploiement ne se fait pas.

Et pour la QoS ? C'est le même problème : déployer un réel système de QoS sur l'Internet nécessiterait des actions par un certain nombre d'acteurs différents et ceux-ci ne voient pas de motivation à le faire. Voici pourquoi presque tous les déploiements actuels de QoS sont restés limités à une seule organisation.

Enfin, la section 5 décrit le travail qui a été fait, à l'IETF et ailleurs, sur ce problème. L'histoire de la qualité de service sur l'Internet est vieille, on trouve déjà une discussion dans le RFC 896, mais aussi, plus tard, dans le RFC 2212 et RFC 2475. Le RFC 2309 traite du cas où certains flux ne jouent pas le jeu et tentent d'occuper toute la capacité disponible et le RFC 3714 de la notion d'équité. La référence reste le RFC 2914 sur les principes de contrôle de congestion sur l'Internet.

La section 5.2 contient plusieurs autres références sur le travail fait à l'extérieur de l'IETF comme les articles Flow Rate Fairness: Dismantling a Religion ou Pricing the Internet.

Qu'est-ce qui fait qu'un protocole a du succès ou pas ? Pourquoi certains restent-ils dans une petite niche alors que d'autres accèdent à la domination mondiale ? Et y a t-il des leçons à tirer de ces succès et de ces échecs, pour améliorer les prochains protocoles ? C'est à ces questions que s'attaque le dernier RFC de l'IAB, « qu'est-ce qui fait un succès ? ».

Il n'y a évidemment pas de réponse simple et univoque. Le RFC 5218 ne tente bien sûr pas de trouver une recette simple qui garantirait le succès. Il liste plutôt des facteurs qui jouent un rôle, essayant d'évaluer l'importance de ce rôle. La moitié du RFC est constituée d'études de cas où plusieurs protocoles sont étudiés du point de vue de ces facteurs.

Ce qui est sûr, c'est que la qualité technique du protocole n'est qu'un des facteurs, et pas le plus important.

Au sein des protocoles IETF, pourquoi Diameter (RFC 3588, puis RFC 6733) n'a t-il jamais remplacé Radius (RFC 2865) ? Pourquoi SNMP v1 (RFC 1157) continue t-il à être tant utilisé ? Et, bien sûr, même s'il est très peu cité dans le RFC, pourquoi IPv6 (RFC 2460) n'a t-il pas remplacé IPv4 (RFC 791) ? Pourtant, à chaque fois, le protocole présenté comme « le successeur » avait bénéficié d'un marketing vigoureux.

Entre protocoles IETF et protocoles d'autres origines, pourquoi IP a t-il écrasé IPX, qui était probablement techniquement supérieur, ou bien OSI, qui bénéficiait d'un soutien politicien et bureaucratique marqué ?

La section 1.1 du RFC commence par tenter de définir ce qui fait le succès. BGP (RFC 4271) est un succès, bien qu'il ne soit installé que sur un petit nombre de machines et qu'il ne soit utilisé directement que par une petite minorité de personnes. DHCP (RFC 2131) est un autre exemple d'un succès qui ne se voit pas forcément, puisqu'il n'est utilisé qu'à l'interieur d'un site (DHCP est un « protocole TCP/IP » mais pas vraiment un « protocole Internet »). Même chose pour OSPF (RFC 2328). En revanche, les protocoles célèbres, utilisés à travers l'Internet, sont des succès incontestables comme HTTP (RFC 2616), SIP (RFC 3261) ou le DNS (RFC 1034).

La section 1.2 essaie de quantifier cette question en parlant des deux dimensions du succès : les usages et l'échelle. Un protocole est conçu pour certains usages. Le succès signifie souvent qu'il est utilisé pour d'autres usages. Un protocole est prévu pour une certaine échelle d'utilisation et le succès va souvent le conduire à la dépasser largement (par exemple, il y a bien plus de machines connectées à l'Internet que n'en prévoyaient ses concepteurs, même dans leurs rêves les plus fous). Le RFC invente même le concept de « succès fou » (wild success) pour désigner les protocoles qui, comme IPv4, ont dépassé toutes les espérances.

HTTP (section 1.2.1) est un exemple encore meilleur d'un succès fou. Il a dépassé les usages prévus (puisqu'on se sert de HTTP en dehors du Web, par exemple pour REST et XML-RPC, voire pour traverser les coupe-feux et « tunneler » le trafic). L'ampleur de son déploiement a aussi largement dépassé les ambitions initiales de Tim Berners-Lee !

Plus complexe, toujours en section 1.2.1, est le cas d'ARP (RFC 826). En ampleur du déploiement, c'est un grand succès. Mais ses usages ont été réduits : conçu pour fonctionner sur n'importe quel type de réseau local, il n'a jamais été déployé que sur Ethernet.

Alors, est-ce souhaitable pour un concepteur de protocole de voir son bébé devenir un « succès fou » ? Ce n'est pas évident, comme le note la section 1.3. Avoir un succès fou a des conséquences, certaines bonnes et d'autres mauvaises. Par exemple, le succès peut entraîner le protocole aux limites de ses capacités quantitatives, « problème » que connait actuellement IPv4, dont les quatre milliards d'adresses possibles ne sont plus suffisantes. (À l'époque de sa conception, le modèle dominant était « un ordinateur par organisation ». Il est passé ensuite à « un ordinateur par département » puis « un ordinateur par personne » et le modèle actuel de plusieurs ordinateurs par personne est une des causes de l'épuisement des adresses IPv4.)

De même, le succès peut aggraver ou révéler des problèmes de sécurité : le protocole qui réussit va attirer l'attention des craqueurs.

Et l'échec ? Symétrique du succès, c'est le sort de certains protocoles. La section 1.3 essaie de l'analyser. D'abord, il ne faut pas forcément être pressé. Au début, un protocole n'a aucun déploiement et aucune implémentation. Ce n'est qu'avec le temps qu'on peut dire que le protocole a réussi ou échoué. HTTP a mis plusieurs années à décoller, par exemple. IPv4 est resté le protocole d'un petit réseau inconnu des décideurs et des journalistes pendant de nombreuses années.

Les protocoles réseaux ont un problème particulier à surmonter, celui de l'œuf et la poule (un terme que critique notre RFC, d'ailleurs). En effet, le réseau ne sert à rien si on est tout seul. Si j'invente un protocole de courrier électronique supérieur à SMTP (avec l'expérience qu'on a aujourd'hui, ce n'est pas très difficile), ce protocole, si réussi soit-il, ne servira à rien puisque j'en serai le seul utilisateur et que je ne pourrai donc envoyer du courrier à personne. Le cercle vicieux s'enclenche facilement : personne n'a déployé le nouveau protocole donc les auteurs de logiciels ne se pressent pas pour l'intégrer dans leurs programmes donc les utilisateurs ne s'en servent pas, donc il n'y a pas de déploiement, etc. Tout le monde aurait intérêt à ce que le nouveau protocole réussisse mais les premiers convertis supporteraient tous les coûts. En l'absence d'une autorité centrale qui pourrait ordonner le déploiement du nouveau protocole, bien des propositions de réforme ont ainsi été victimes de ce que les économistes appellent un échec du marché.

Quelles sont les méthodes pour faire face au problème de l'œuf et de la poule ? La section 1.3 en cite plusieurs :

• Résoudre un problème immédiat et brûlant, ce qu'a fait, par exemple, le NAT (RFC 3022).
• Fournir un « service qui tue » (killer app), comme l'ont fait les services de distribution de fichiers en pair-à-pair, service tellement utile que les utilisateurs sont prêts à faire des efforts, par exemple à reconfigurer leur routeur.
• Être invisible, c'est-à-dire ne nécessiter aucun changement.
• Réduire les ambitions, en diminuant les usages prévus, ce qui rend le succès plus facile. C'est ainsi que la diffusion restreinte (multicast) sur tout l'Internet, telle qu'envisagée à l'origine, a été un échec mais cette même diffusion restreinte est largement pratiquée sur les réseaux locaux.
• Obtenir une aide ou une directive gouvernementale. La question est chaudement disputée, les adorateurs du marché aimant prétendre que l'Internet s'est créé tout seul, par le seul jeu non régulé des forces du marché. Rien n'est plus faux, l'Internet et son prédécesseur Arpanet ont vécu pendant quinze ans aux crochets de l'état états-unien. Mais l'intervention de l'État (à part sous une dictature extrême du genre Ivan le Terrible) ne marche pas toujours, les acteurs gardant leur liberté. Le RFC cite l'intervention du gouvernement japonais en faveur d'IPv6 mais, si cette aide a permis à Kame de faire un travail très intéressant sur IPv6, ce protocole reste minoritaire au Japon comme ailleurs. De même, les protocoles OSI ont nettement perdu face à TCP/IP malgré un soutien gouvernemental très obtus (par exemple en France). Et, dans un domaine différent de celui des réseaux, le langage de programmation Ada ne s'est pas imposé, en dépit d'une consigne officielle de n'utiliser que lui pour tous les programmes de l'armée états-unienne (le plus gros consommateur de logiciels du monde).

La section 2 explore les différentes causes de succès, en précisant bien qu'aucun succès n'a réuni toutes ces causes. 2.1 se spécialise dans les raisons du succès « de base », 2.2 dans celles du succès fou.

D'abord, le protocole doit évidemment avoir un intérêt et cet intérêt doit compenser les coûts (section 2.1.1). Si les coûts liés au matériel sont les plus visibles, ils ne sont pas forcément les plus importants. Ainsi, tout protocole qui nécessite de re-former les utilisateurs a un travail plus difficile pour s'imposer car le coût de cette formation est non-trivial. Les coûts liés à l'invalidation des anciens calculs économiques sont également à prendre en compte : si un FAI fonde son modèle économique sur des connexions Internet intermittentes, un protocole qui permet d'être connecté tout le temps comme l'ADSL, va remettre en cause ce modèle (de façon significative, mais étonnante pour un RFC, le paragraphe sur l'économie est le plus long de la section).

Et quels sont les bénéfices possibles ? Résoudre un problème lancinant (DHCP a ainsi mis fin au cauchemar des administrateurs réseaux courant de machine en machine pour faire un changement), permettre des choses qu'on ne faisait pas avant, ou rendre simplement plus efficace les choses qu'on faisait déjà (de tels protocoles sont souvent plus simple à déployer car ils ne remettent pas en cause les usages). Si le coût initial est élevé, le protocole peut avoir du mal à s'imposer, même si les bénéfices futurs sont prometteurs.

En outre, coûts et bénéfices ne sont pas équitablement répartis. Les techniques de NAT sont très coûteuses pour les développeurs d'applications, qui doivent coder des contournements compliqués mais apportent des bénéfices aux FAI, qui font des économies d'adresses IP. Tout dépend donc de qui décide. Le RFC note donc que le succès d'un protocole vient souvent de « l'alignement des coûts et des bénéfices », c'est-à-dire du fait que les bénéfices viennent à ceux qui supportent les coûts initiaux (même si, comme dans le cas du NAT, les coûts finaux sont payés par d'autres).

Ensuite, pour être un succès, le protocole a tout intérêt à être déployable petit à petit (section 2.1.2). En effet, le dernier flag day (tout l'Internet change de protocole le jour J à l'heure H) a eu lieu en janvier 1983 lors du déploiement d'IPv4 (et du passage à TCP/IP). Aujourd'hui, il est complètement impossible de changer tout l'Internet d'un coup et le nouveau protocole doit donc pouvoir s'intégrer à l'Internet existant (le grand drame d'IPv6 vient de là).

D'autres causes de succès non technique sont la disponibilité du code en logiciel libre ou quasi-libre (sections 2.1.3 et 2.1.4), le fait que le protocole soit ouvert (section 2.1.5) et maintenu par une SDO selon un processus ouvert (section 2.1.6, qui est un peu un plaidoyer pro domo pour l'IETF). Le succès d'IPv4 contre IPX ou OSI (ce dernier cas n'est pas cité par le RFC mais est encore plus net) tient largement à ces points. TCP/IP a gagné en bonne partie par sa disponibilité dans les Unix de Berkeley.

Le fait que la norme soit « ouverte » joue un rôle important, ce qui explique aussi la vigueur des débats dans le groupe de travail IPR de l'IETF. Les RFC ne sont pas les normes les plus ouvertes du monde, par exemple leur licence (RFC 5378) limite les usages qui peuvent en être faits...

Et la technique, alors, elle ne joue aucun rôle ? Un peu quand même, argumente la section 2.1.7, qui explique qu'un protocole bien conçu a davantage de chances.

Mais le succès est une chose et le succès fou en est une autre. Qu'est-ce qui cause un succès fou ? L'extensibilité et l'absence de limites aident (sections 2.2.1 et 2.2.2). DECnet était limité par construction à 65 536 machines, ce qui garantissait son échec à terme, même s'il avait connu de bons débuts.

L'un des points où il y a la plus grosse différence entre le succès et le succès fou concerne la sécurité (section 2.2.3). Au début, il n'est pas nécessaire qu'un protocole soit sûr (ce point est développé également en section 3). Compte-tenu des divers coûts associés à la sécurité, notamment les difficultés d'usage, faire l'impasse sur la sécurité est en général un bon moyen de réussir au début. Mais, lorsque le protocole devient très répandu, les craqueurs se précipitent dessus et cherchent à le subvertir. C'est alors que les impasses qui avaient été faites sur la sécurité peuvent se payer cher. Néanmoins, foncer d'abord et réfléchir ensuite à la sécurité semble être une bonne stratégie (les protocoles qui intègrent la sécurité dès le début ne sont souvent jamais déployés et donc jamais attaqués).

Notons que l'annexe A, qui représente la moitié du RFC, décline ces analyses pour une série d'étude de cas. C'est ainsi que sont examinés :

• Protocoles Web (HTTP et HTML) contre Gopher (section A.1). La qualité technique n'a guère joué (HTML à cette époque était très pauvre et, contrairement à ce que dit le RFC, n'avait même pas les formulaires). Mais le déploiement était simple et apportait des bénéfices immédiats.
• IPv4 contre IPX (section A.2). Il existait d'innombrables protocoles réseaux à l'époque. Tout administrateur réseau devait en gérer plusieurs. Aucun des protocoles concurrents n'était déployable progressivement mais la base installée était faible. Certains de ces protocoles avaient des limites fondamentales (comme AppleTalk) qui leur interdisaient d'être le protocole d'un réseau mondial. IPX n'avait pas ces défauts et avait bien des avantages techniques sur IPv4 (comme l'auto-configuration, alors que DHCP n'existait pas encore). Mais la grande force d'IPv4 était la disponibilité d'une mise en œuvre libre, dans BSD (financée par des fonds publics). Même chose pour la disponibilité d'une norme.
• SSH (section A.3). Ce protocole (RFC 4251) a remplacé telnet et rlogin en très peu de temps. Très simple à installer et à utiliser (beaucoup l'ont adopté uniquement pour la redirection des sessions X11, un énorme progrès à l'époque), ne nécessitant pas d'infrastructure centrale (contrairement aux solutions à base de Kerberos), SSH, malgré un statut légal peu clair au début, s'est vite imposé. Les puristes de la sécurité avaient pourtant critiqué cette simplicité (bien que beaucoup de solutions de sécurité aient échoué en raison de la grande complexité qu'elles imposaient aux utilisateurs). Le modèle TOFU (Trust On First Use) de SSH leur semblait une hérésie. Mais l'alternative était du telnet avec zéro sécurité. (Aujourd'hui, des techniques comme Perspectives tentent d'améliorer le système TOFU.)
• Diffusion restreinte (multicast) entre domaines distincts (section A.4). C'est cette fois un échec qui est analysé. Le multicast (RFC 5110) a souvent été présenté comme indispensable aux services multimédia sur Internet mais la réalité est qu'il n'a jamais connu d'utilisation significative. Pourquoi ? Il manquait de la plupart des facteurs de succès. Il n'est pas évident qu'il répondait à un problème réel (la diffusion est utile si tout le monde regarde la même chaîne de télévision en même temps, comme dans les années 60, mais elle ne sert à rien pour la VoD). Il nécessite des grands changements dans tous les routeurs du chemin. Bref, les coûts étaient importants et les bénéfices peu clairs.
• WAP (section A.5) est un autre échec, qui avait pourtant bénéficié d'un marketing très lourd et peu subtil, composé essentiellement d'affirmations tonitruantes comme quoi « 90 % des accès au Web se feraient en WAP dans cinq ans » et autre fumage de moquette de consultant. Coincé entre le classique HTTP et le plus perfectionné I-Mode, WAP n'apportait rien de précis. Très fermé (licences à acheter, normes non accessibles, évolution pilotée par une organisation où le coût d'adhésion était de 27 000 $), WAP n'est pas allé loin. Il est amusant a posteriori de compter le nombre d'articles sur WAP qui étaient parus dans la presse pour décideurs, alors qu'il n'avait connu aucun déploiement, par rapport au nombre d'articles qu'avait eu IP alors que l'Internet était déjà massivement utilisé.
• La lutte du protocole IETF Radius (RFC 2865) contre le protocole de Cisco Tacacs (section A.7) est un autre cas où la disponibilité d'une norme ouverte et sans entraves a été le facteur dominant. Tacacs a évolué par la suite, une implémentation libre est apparue, ainsi qu'une norme (RFC 1492) mais c'était trop tard.
• Plus douloureux est le succès du NAT (section A.8). Apportant un bénéfice immédiat à celui qui le déploie (le IP masquerading de Linux, première mise en œuvre répandue du NAT, avait été un succès foudroyant et avait beaucoup contribué au décollage de Linux), le NAT, propulsé par la pénurie d'adresses IPv4, s'est répandu partout, en dépit de l'opposition vigoureuse de l'IETF. Le fait qu'il apportait un bénéfice à court terme et qu'il était déployable sur un site sans aucune coordination avec les autres lui ont permis de progresser très vite.