lalahop

DNSSEC : OpenDNSSEC, roulement de KSK et DLV

En temps normal, le roulement d'une KSK se passe bien et en douceur avec OpenDNSSEC. Ici, on va s'attarder sur le cas spécial (et inutile) où un roulement de KSK approche et que l'on souhaite quitter un modèle arborescence pour les données + arborescence séparée pour les délégations signées (DLV) pour le modèle normal et classique de DNSSEC : une seule arborescence unifiée.

Si vous débutez avec DNSSEC, je vous recommande les lectures suivantes :

Rappel : DLV permet de séparer l'arborescence qui contient les données (enregistrements NS/A/AAAA/MX/SRV/DNSKEY/RRSIG/...) de celle qui contient les délégations signées. Cela permet de créer une chaîne de confiance avec des ilôts sécurisés (zone signée dont la zone parente n'est pas signée/n'accepte pas l'ajout de délégations signées, ...) tant que l'intégralité de l'arborescence pour arriver à ces ilôts n'est pas signée et/ou n'accepte pas l'ajout de délégations signées. DLV est très peu utilisé. Il existe plusieurs dépôts DLV, le plus important étant celui de l'ISC (dlv.isc.org). Un (ou plusieurs) dépôt doit être configuré sur un récursif-cache sinon DLV n'est pas utilisé par ledit récursif-cache. Quand DLV est configuré, le récursif-cache cherche d'abord une délégation signée valide via l'arborescence classique (racine, TLD, ...). Si le résultat est négatif, il utilise les dépôts DLV configurés pour tenter de trouver une délégation signée.

Historique : au moment où j'ai voulu signer mes zones (dont guiguishow.info.), info. n'acceptait pas encore la soumission de délégations signées (enregistrements de type DS qui pointent sur la KSK de la zone) ou, en tout cas, mon bureau d'enregistrement ne me permettait pas d'effecter une demande d'ajout. Juste pour découvrir et m'amuser, j'ai alors décidé d'utiliser le registre DLV de l'ISC.

Or, depuis quelques mois, je peux enfin soumettre un enregistrement DS via l'interface de mon bureau d'enregistrement. Donc, en tout logique, je souhaite arrêter d'utiliser DLV. La première idée qui vient à l'esprit est de profiter du roulement de la KSK qui approche pour effectuer cette transition.

Pour les plus perspicaces : oui, j'ai signé mes zones (sauf une) en janvier 2013 donc le roulement de la KSK aurait du avoir lieu en janvier 2014. Sauf que le passage de Squeeze à Wheezy ne s'est pas fait en douceur : OpenDNSSEC a supprimé les clés utilisées du HSM logiciel, me forçant à un roulement de clés d'urgence.

Réfléchissons à cette idée (profiter du roulement de KSK approchant pour ne plus utiliser DLV) en regardant le schéma des états que peuvent avoir les clés dans OpenDNSSEC ainsi qu'en révisant le schéma de pré-publication qui est utilisé.

Voilà ce qui se passerait si j'abandonnais DLV durant le roulement de la KSK (j'ai pris en compte uniquement les états visibles dans les outils OpenDNSSEC ce qui exclut les états « Générated » et « Dead ») :
État « Publish » :

  • Récursifs-cache utilisant le dépôt DLV de l'ISC : aucun impact car le seul changement est que le RRset DNSKEY comporte un RR supplémentaire (la partie publique de la nouvelle clé).
  • Récursifs-cache qui n'utilisent pas DLV : aucun impact pour la même raison.

État « Ready » :

  • Récursifs-cache utilisant le dépôt DLV de l'ISC : aucun impact. OpenDNSSEC considère simplement que la nouvelle clé est présente dans suffisamment de récursifs-cache et peut donc être utilisée.
  • Récursifs-cache qui n'utilisent pas DLV : aucun impact pour la même raison.

Je demande l'ajout d'un RR DS dans la zone info. À partir du moment où il est publié :

  • Récursifs-cache utilisant le dépôt DLV de l'ISC :
    • Récursifs-cache qui ont encore des données en cache : aucun impact. L'ancienne clé est toujours présente dans la zone et elle signe toujours ladite zone et les anciennes signatures ainsi que la délégation signée sont en cache.
    • Récursifs-cache qui n'ont plus rien en cache : ils feront une nouvelle résolution sans utiliser DLV et trouveront le DS pointant sur la nouvelle clé ... qui ne signe rien alors qu'il y a des signatures dans la zone : échec. Théoriquement, ils continueront à utiliser DLV et remettront donc les données en cache.
  • Récursifs-cache qui n'utilisent pas DLV : le DS pointe sur la nouvelle clé ... qui ne signe rien alors qu'il y a des signatures dans la zone : échec. A priori aucun impact pour les récursifs-cache qui ont encore des données en cache.

État « Active » (j'indique à DNSSEC que le DS est publié) :

  • Récursifs-cache utilisant le dépôt DLV de l'ISC :
    • Récursifs-cache qui n'ont plus rien en cache : ils referont une résolution sans utiliser DLV et trouveront le DS qui pointe sur la nouvelle clé qui signe la ZSK qui signe la zone : tout va bien.
    • Récursifs-cache qui ont obtenus des données entre la publication du DS et le passage à l'état « active » : ils ont toujours le bon DS et les anciennes signatures en cache : échec. Ils peuvent utiliser DLV tant qu'un élément de la chaîne de confiance n'est pas brisée dans leur cache (l'enregistrement DLV pointe désormais sur l'ancienne KSK qui ne signe plus rien).
  • Récursifs-cache qui n'utilisent pas DLV :
    • Récursifs-cache qui ont obtenus des données entre la publication du DS et le passage à l'état « active » : ils ont toujours le bon DS qui pointent sur la nouvelle KSK qui ne signe rien (ancienne signature du RRset DNSKEY) : échec.
    • Récursifs-cache qui n'ont plus rien en cache : le DS pointe sur la nouvelle clé qui signe la ZSK qui signe la zone : tout va bien.

Bien sûr, la période de temps entre le moment où la délégation signée est publiée dans la zone parente et le moment où on indique cette publication à OpenDNSSEC est plus ou moins grande en fonction de ma réactivité/disponibilité. Ce qui implique que le trouble que je décris durera plus ou moins longtemps.

Pour que l'analyse soit complète, il faudrait tenir compte du fait que le cache d'un récursif n'est pas tout vide ou tout plein pour un même domaine : toutes les données (délégation dans la zone parente, signatures, ...) n'expirent pas en même temps (TTL différents). Ça augmente les combinaisons possibles.

Néanmoins, la documentation d'OpenDNSSEC (ainsi que le man ods-ksmutil) nous conseille de ne pas changer les paramètres d'une politique de signature notamment les délais de "propagation" (terme pas vraiment correct car il induit en erreur sur la réalité du processus) pendant qu'un roulement de clés est en cours. Ce qui est logique. Je ne souhaite pas changer les délais de propagation mais je vais changer les TTL (DS/SOA de la zone parente) car ils sont utilisés par OpenDNSSEC pour affiner ses calculs.

En conséquence, soit je fais ce changement de politique pour ma zone avant le roulement ou après. Avant, ça ne convient pas si je laisse une délégation dans le registre DLV car la politique ne sera donc plus adaptée à la zone parente. Après, ça me semble un peu tard notamment car les calculs pour le roulement seront légèrement "faussés".

Une méthode beaucoup plus simple est d'ajouter une délégation signée dans la zone parente (info) qui pointe sur la KSK actuelle, avant le roulement. Les récursifs-cache qui utilisent DLV et ont des données en cache continueront à valider puis, à expiration des TTL, n'utiliseront plus DLV mais pourrons toujours valider les signatures. Les récursifs-caches qui n'utilisent pas DLV et qui ont des données en cache, continueront à ne pas valider, puis, à expiration des TTL, valideront les signatures. De plus, le roulement de la KSK tombera dans le cas général qui est très bien pris en charge par OpenDNSSEC.

Les étapes sont donc de se débarrasser de DLV puis de modifier la politique de signature utilisée par OpenDNSSEC pour la zone. J'ai fait ça le week-end du 10 mai pour un roulement de clé planifié pour le 19-20 mai 2014.

Pour la première étape, il suffit de demander la publication d'un enregistrement DS dans info. La prise en compte au plus tard par les récursifs sera : maintenant + temps de publication (moins de 15 minutes dans mon cas) + 3600 secondes (1h). Cela correspond au cache négatif dans info. (ça concerne tous les récursifs-cache, qu'ils utilisent DLV ou non) et au TTL des enregistrements DLV dans le dépôt DLV de l'ISC (ça concerne les récursifs-cache qui utilisent ce dépôt).

Après quelques temps (au bout d'une heure ça devrait être plié mais j'ai attendu 2 jours, sans raison), on pourra supprimer notre délégation du dépôt de l'ISC.

Pour la deuxième étape, il faut d'abord ajouter une politique dans le fichier de configuration « kasp.xml » d'OpenDNSSEC. J'ai simplement copié/collé la politique qui s'applique à toutes mes zones qui ont une délégation signée dans le dépôt DLV de l'ISC et j'ai changé les paramètres relatifs à la zone parente.

On synchronise le contenu de ce fichier avec la base de données d'OpenDNSSEC :

ods-ksmutil update kasp
zonelist filename set to /etc/opendnssec/zonelist.xml.
kasp filename set to /etc/opendnssec/kasp.xml.
Policy guiguishow found
Info: converting P1Y to seconds; M interpreted as 31 days, Y interpreted as 365 days

On modifie ensuite le fichier zonelist.xml pour changer la politique associée à la zone par la nouvelle politique.

On synchronise le contenu de ce fichier avec la base de données d'OpenDNSSEC :

ods-ksmutil update zonelist
zonelist filename set to /etc/opendnssec/zonelist.xml.
kasp filename set to /etc/opendnssec/kasp.xml.
Zone guiguishow.info found
Policy set to guiguishow.

On vérifie que le changement a bien été pris en compte.
Avant :

ods-ksmutil zone list
zonelist filename set to /etc/opendnssec/zonelist.xml.
Found Zone: guiguishow.info; on policy dlv

Après :

ods-ksmutil zone list
zonelist filename set to /etc/opendnssec/zonelist.xml.
Found Zone: guiguishow.info; on policy guiguishow

On utilise aussi la commande « ods-ksmutil key list » pour vérifier qu'on n'a pas fait d'erreur et que nos clés sont toujours là (même si la doc indique que la commande « update » ne touche pas aux clés).

Au moment venu du roulement de la KSK, on est tranquille, on laisse OpenDNSSEC faire le taff, on demande la publication d'un nouveau DS dans la zone parente quand il nous le demande (état « ready ») et c'est tout.

Découvrons la RIPE database

Le RIPE, comme tout RIR, dispose d'une base de données publique qui regroupe toutes (un maximum on va dire) les informations "technico-administratives" (à qui a été alloué telle ressource numérique unique ? qui est le responsable technique de ce réseau, quel AS doit annoncer tel préfixe IP ?, ...) concernant les réseaux informatiques publics en Europe (version large) et au Moyen-Orient.

Habituellement, on accède à cette base de données lorsque l'on fait une requête avec le protocole whois sur une ressource (plage d'IP, numéro d'AS, ...) allouée/assignée par le RIPE. Aujourd'hui, on va plutôt regarder de quoi est constituée cette base de données et comment les LIR et les opérateurs réseaux la mettent à jour (ou non, d'ailleurs).

Si tous les RIR ont une base de données, pourquoi je me focalise sur celle du RIPE ? Simplement car le RIPE est bien de chez nous et comme le format de la base (RPSL ou non, objets/attributs différents, ...) change entre RIR, autant étudier ce qui nous concerne. De plus, la RIPE DB est la mieux documentée, à mon humble avis.

Attention : ce billet n'est ni de la vulgarisation ni une source d'information fiable. Il s'agit juste d'un retour d'expérience et de quelques notes d'un n00b qui s'est penché sur le sujet.

Table des matières

De la documentation générale

Documentation spécifique

Quelques paramètres whois bien utiles

Ce que je retiens principalement des lectures précédentes, c'est des paramètres de la commande whois, qui sont spécifiques à certaines bases comme celle du RIPE mais qui n'en sont pas moins très utiles :

  • whois -t <type_objet> : afficher les attributs d'un type d'objet
  • whois -B : afficher toutes les infos (mail ...) de l'objet demandé (sans ça : « source: RIPE # Filtered »)
  • whois -L : remonter toute l'arborescence d'une allocation. Exemple pour un inetnum : organisation - LIR - RIR - IANA
  • whois -l : pareil que précédemment mais remonte uniquement d'un étage/d'une étape/d'un cran
  • whois -r -i org <id_organisation> : afficher toutes les ressources/objets assignés/alloués à une organisation (objet de type « organisation »)
  • whois -i origin <ASN> : afficher tous les préfixes déclarés comme étant annoncés par l'AS donné. En vrai, ça remonte les objets route(6) et la fioriture qui va avec. On peut également remonter tous les objets dont le tech ou l'admin sont un objet person passé en argument : whois -i person . On ne peut pas itérer sur tous les attributs. Les attributs possibles sont indiqués dans « RIPE Database Queries Reference Card » (https://www.ripe.net/manage-ips-and-asns/db/support/documentation )

RIPE TEST Database

Le RIPE met à disposition une base de données de test en libre-service pour que chacun puisse découvrir/s'entraîner à l'arrache. Je pense que c'est un excellent moyen de voir comment ça se passe de l'autre côté du whois. C'est vraiment intéressant et formateur.

Ci-dessous, je ne vais pas être exhaustif, juste donner des pistes et énoncer quelques "pièges" que j'ai rencontrés pour vous éviter de tomber dedans.

Dans mes exemples, je serai Jean-Kevin Boulay de l'association TESTASSO.

person/mntner

La première étape est de créer un objet de type « person ». Voyons les différents attributs disponibles :

whois -t person
person:         [mandatory]  [single]     [lookup key]
address:        [mandatory]  [multiple]   [ ]
phone:          [mandatory]  [multiple]   [ ]
fax-no:         [optional]   [multiple]   [ ]
e-mail:         [optional]   [multiple]   [lookup key]
org:            [optional]   [multiple]   [inverse key]
nic-hdl:        [mandatory]  [single]     [primary/lookup key]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
abuse-mailbox:  [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Hum ... mnt-by doit pointer un objet de type « mntner » (maintainer) ... Quels sont ses attributs ?

whois -t mntner
mntner:         [mandatory]  [single]     [primary/lookup key]
descr:          [mandatory]  [multiple]   [ ]
org:            [optional]   [multiple]   [inverse key]
admin-c:        [mandatory]  [multiple]   [inverse key]
tech-c:         [optional]   [multiple]   [inverse key]
upd-to:         [mandatory]  [multiple]   [inverse key]
mnt-nfy:        [optional]   [multiple]   [inverse key]
auth:           [mandatory]  [multiple]   [inverse key]
remarks:        [optional]   [multiple]   [ ]
notify:         [optional]   [multiple]   [inverse key]
abuse-mailbox:  [optional]   [multiple]   [inverse key]
mnt-by:         [mandatory]  [multiple]   [inverse key]
referral-by:    [mandatory]  [single]     [ ]
changed:        [mandatory]  [multiple]   [ ]
source:         [mandatory]  [single]     [ ]

Il y a une référence circulaire : un objet person dépend d'un objet de type maintainer mais un objet maintainer dépend aussi d'un objet de type person (attribut « admin-c »).

La solution ? Utiliser le formulaire pour les nouveaux arrivants dans la RIPE Database.

Mode d'emploi rapide :

  • Source : bien choisir la TEST Database
  • Person : prénom nom. Exemple : J-K Boulay
  • NIC hdl : ne peut pas être vide contrairement à ce qui est indiqué. Il s'agit de la clé primaire de l'objet. Elle doit être unique dans la base donc la base l'attribue elle-même. Vous pouvez mettre :
    • Soit une suite de caractères qui respecte le formalisme (« From 2 to 4 characters optionally followed by up to 6 digits optionally followed by a source specification. The first digit must not be "0". Source specification starts with "-" followed by source name up to 9-character length. »). Exemple : JKB1-TEST. Attention : un nic-hdl déjà pris générera une erreur « The nic-hdl "JKB1-TEST" is not available ».
    • Soit la valeur « AUTO-1 » pour laisser complètement le choix à la base ou « AUTO-1<abréviation> ». Abréviation est composée de 1 à 4 lettres. Exemple : AUTO-1JKB pour obtenir le nic-hdl : « JKB1-TEST ». Il est inutile d'essayer de mettre AUTO-42JKB pour tenter d'obtenir un nic-hdl « JKB42-TEST » : ça ne marche pas. Je n'ai pas trouvé comment forcer le nombre et c'est à mon avis bien normal : ID, on prend le suivant, même si un objet avec un ID inférieur a été supprimé depuis, tout ça.
  • Address : FR suffit, par exemple
  • Phone : +33123456789 suffit, par exemple
  • Email : ripedb@example.com suffit, par exemple
  • Pour le mntner, le nom est une clé et on reprend souvent le nom de l'organisation à laquelle la personne qui s'inscrit est rattachée. Exemple : Maintainer name : TESTASSO-MNT

Normalement, vous obtenez le message suivant :

We have created two RIPE Database objects for you, please make a note of the primary keys (shown in bold letters) for these two objects for future reference:
 
person nic-hdl: JKB1-TEST
 
person:         J-K Boulay
address:        FR
phone:          +33123456789
e-mail:         ripedb@example.com
nic-hdl:        JKB1-TEST
mnt-by:         TESTASSO-MNT
changed:        ripedb@example.com 20140418
source:         TEST
 
maintainer name: TESTASSO-MNT
 
mntner:         TESTASSO-MNT
descr:          Startup maintainer
admin-c:        JKB1-TEST
upd-to:         ripedb@example.com
auth:           MD5-PW blabla
mnt-by:         TESTASSO-MNT
referral-by:    TESTASSO-MNT
changed:        ripedb@example.com
source:         TEST

Petite note : un objet de type maintainer est un verrou qui empêche la modification et la suppression inopinée de vos enregistrements présents dans la base. Il recense également les moyens qui permettent d'authentifier le requérant d'une modification/suppression. Actuellement, la base supporte une auth par mot de passe (stocké sous forme de hash MD5 dans la base) ou par signature PGP des objets (uniquement par mail, pas par l'interface web. Oui, on peut créer/modifier des objets par mail.). Pour l'instant, nous n'avons qu'une auth par mot de passe.

Vous pouvez effectuer une recherche pour vérifier que vos objets ont bien été créés : https://apps.db.ripe.net/search/query.html.

Si vous souhaitez modifier vos objets, c'est par là : https://apps.db.ripe.net/webupdates/search.html. Cependant, lors de la soumission de vos modifications, vous allez recevoir l'erreur : « No authorisation has been supplied ». En effet, vous n'avez pas prouvé votre identité selon l'un des mécanismes prévus dans l'objet maintainer qui verrouille l'objet que vous souhaitez modifier. Pour vous authentifier, il suffit de saisir votre mot de passe de maintainer dans la zone « Session Passwords » dans le menu de droite.

À partir de maintenant, vous pouvez créer vos objets à l'adresse suivante : https://apps.db.ripe.net/webupdates/select-type.html. Deux méthodes de saisies sont disponibles : format brut (que du texte) ou formulaire avec uniquement les attributs obligatoires.

organisation

Un objet de type « organisation » permet de lier toutes les ressources associées/allouées à une organisation donnée. Très pratique mais pas obligatoire. Les autres objets peuvent pointer dessus avec un attribut « org ». L'attribut organisation fonctionne comme le NIC-hdl d'une person donc « AUTO-1<abréviation> ».

Exemple :

organisation: 	ORG-TSTA1-TEST
org-name: 	Association TESTASSO
org-type: 	OTHER
address: 	FR
e-mail: 	ripedb@example.com
mnt-ref: 	TESTASSO-MNT
mnt-by: 	TESTASSO-MNT
changed: 	ripedb@example.com 20140418
source: 	TEST

inetnum/inet6num

Passons au plus intéressant : une plage d'adresses IPv4 : un inetnum (ou v6 avec inet6num, ça fonctionne pareil).

En situation réelle, vous n'aurez pas besoin de créer cet objet : c'est le boulot de votre LIR qui vous mettra en mnt-* si vous le souhaitez pour que vous ayez des droits sur vos allocations. De plus, en situation réelle, le processus d'allocation de ressources ne se passe pas aussi facilement en mode "ho, cette plage est disponible, je la prends". Néanmoins, ici, je choisis 192.0.2.0/24 qui est une plage réservée à la documentation.

Ici, il faudra l'accord de la hiérarchie, c'est à dire de l'organisation (RIR ou LIR) a qui a été attribuée la plage d'adresses IP qui englobe celle que cette organisation vous a attribuée. Pour trouver quel est le maintainer responsable, il suffit de faire une recherche.

Via l'interface web :

  • Search term : 192.0.2.0 - 192.0.2.255
  • Sources : TEST Database
  • Hierarchy Flags : l (l comme lapin)

Ou via whois : whois -h whois-test.ripe.net -l 192.0.2.0 - 192.0.2.255

Voilà un extrait de la réponse :

inetnum:         0.0.0.0 - 255.255.255.255
netname:         IANA-BLK
descr:           The whole IPv4 address space
country:         EU # Country is really world wide
org:             ORG-TT1-TEST
admin-c:         AA1-TEST
tech-c:          AA2-TEST
status:          ALLOCATED UNSPECIFIED
remarks:         The country is really worldwide.
mnt-by:          TEST-ROOT-MNT
mnt-lower:       TEST-DBM-MNT
mnt-routes:      TEST-DBM-MNT
remarks:         This is an automatically created object.
source:          TEST # Filtered

On regarde l'attribut « mnt-lower: ». Le maintainer est « TEST-DBM-MNT ». Dans cette base de test, le mot de passe est donné dans un attribut « remark » de cet objet mntner. Je vous laisse le retrouver et l'ajouter à vos « Session Passwords » (menu de droite, tout ça ...).

Maintenant, vous pouvez enregistrer un inetnum. Exemple :

inetnum: 	192.0.2.0 - 192.0.2.255
netname: 	TESTASSO-MAIN
descr:		IPv4 TESTASSO allocation
country: 	FR
admin-c: 	JKB1-TEST
tech-c: 	JKB1-TEST
status: 	ASSIGNED PA
mnt-by: 	TESTASSO-MNT
changed: 	ripedb@example.com 20140418
source: 	TEST

Remarquez que le statut est fantaisiste et ne correspond pas à la réalité : l'IANA n'alloue pas directement des ressources. Le RIPE le faisait (PI + allocation directe). Mais c'est fini (famine IPv4, tout ça et il me semble que c'est pareil en IPv6). Donc, au minimum, il faudrait un RIR et un LIR entre TESTASSO et l'IANA avec autant d'objets. Si ça vous tente de faire une maquette plus réaliste ... Ce n'est pas difficile, juste répétitif.

ÉDIT du 26/04/2014 à 22h00 : Remarquez que le mnt-by est lui aussi fantaisiste : un LIR ne vous mettra pas en mnt-by car il s'agit de ses allocations à lui en tant que LIR tout comme le RIPE n'a pas défini le LIR comme mnt-by sur le(s) inet(6)num qu'il a attribué au LIR. C'est le rôle de ces organismes (RIR et LIR) de délimiter les allocations. Sur les inet(6)num, votre LIR vous mettra en mnt-lower pour gérer des découpages dans vos allocations (exemple : fourre-tout v6), en mnt-domain pour gérer les objets domain associés et en mnt-routes pour créer/modifier les objets de type route, ... Fin de l'édit

ASN

Pour un numéro de système autonome (ASN), le type d'objet est « aut-num ». Sa création ne pose pas de problèmes si vous êtes arrivé jusque-là.

Délégation zone reverse

Pour la délégation d'une zone reverse v4/v6, c'est un objet de type « domain » qu'il vous faut. Mais dans la base de test, sa création échouera car le niveau supérieur (0/0 en v4) n'a pas configuré les serveurs de noms qui font autorité sur cette zone reverse (et pour cause ...).

Politiques de routage inter-AS

Pour ce qui est des politiques de routage, on a les objets de type route/route6 qui permettent de dire : « tel préfixe IPv4 ou IPv6 est annoncé par tel AS » ou des choses plus marrantes comme « quelle est l'adresse IP de la machine que ce réseau met à disposition du public pour servir d'amer ? » (attribut « pingable » d'un route/route6.

Pour les politiques de routage, on a aussi d'autres objets (filter-set, par exemple) et des attributs dans l'objet « aut-num » : import, export et les types liés (as-set, route-set). Tout cela constitue l'Internet Routing Registry (IRR). Exemple :

aut-num: AS197422
as-name: TETANEUTRAL-NET-AS
[...]
from AS31576 accept ANY
from AS6777 accept ANY
from AS6939 accept ANY
[...]
to AS31576 announce AS197422
to AS6939 announce AS197422
to AS6777 announce AS197422
[...]

Ici, ce FAI toulousain annonce que ses pairs sont GIXE (transitaire), l'AMS-IX (point d'échange néerlandais) et Hurricane Electric (gros opérateur). Tetaneutral.net récupère toutes les routes auprès d'eux sans prioriser un pair vis-à-vis d'un autre. Enfin, Tetaneutral annonce ses préfixes à ses pairs.

ÉDIT du 05/05/2016 à 13h20 : Un jour, vous fournirez peut-être du transit IP à d'autres réseaux/organisations. Il faudra alors mettre à jour l'IRR pour dire : « à mes upstreams/pairs, j'annonce non seulement mon AS mais aussi celui de mes downstreams ». Si l'on procède comme on vient de voir, il faudrait une ligne « export: to AS64500 announce AS6500 » (AS64500 = upstream et AS6500 = downstream) pour chaque couple downstream+upstreams ainsi qu'une ligne « import: from AS6500 accept AS6500 » pour chaque downstream ainsi qu'une ligne « export: to AS65000 announce ANY » pour chaque downstream. Ces deux dernières lignes sont inévitables. En revanche, on peut factoriser les premières.

Pour se faire, on utilise un objet de type as-set qui regroupera les objets de type aut-num de vos downstreams + votre aut-num. Ensuite, pour chaque upstream, on aura une ligne : « export: to AS64500 announce <votre_as-set> ». Lors de l'ajout d'un nouveau downstream, il suffit de rajouter son aut-num à l'as-set et les lignes « import: from <son_aut-num> accept <son_aut-num> » et « export: to <son_aut-num> announce ANY » à votre aut-num et c'est fini. Évidemment, le downstream devra mettre à jour son IRR pour indiquer que votre organisation est l'un de ses upstreams/pairs.

Exemple :

aut-num:        AS60630
as-name:        ARN
[...]
import:         from AS174 accept ANY
export:         to AS174 announce AS-ARN
import:         from AS8928 accept ANY
export:         to AS8928 announce AS-ARN
import:         from AS204092 accept AS204092
export:         to AS204092 announce ANY
[...]

as-set:         AS-ARN
descr:          ARN and downstreams
members:        AS60630
members:        AS204092
[...]

aut-num:        AS204092
as-name:        GRIFON
[...]
import:         from AS60630 accept ANY
export:         to AS60630 announce AS204092
[...]

Ici, ce FAI alsacien annonce lui (AS60630) + Grifon (AS204092) à ses upstreams (Cogent - AS174 et Interoute - AS8928), récupère les routes de Grifon et lui annonce la full view.

Il y a deux intérêts à faire ça. Premièrement, avoir une base de données à jour ce qui, en plus d'être du bon sens civique, permet de ne pas se faire filtrer ses préfixes par des opérateurs qui construisent leurs filtres automatiquement à partir de la RIPE DB. Deuxièmement, certains transitaires (comme Interoute) vérifient ces informations avant de vous autoriser à relayer les annonces de vos downstreams lors de votre appel à leur NOC. Tous les transitaires ne vérifient pas : Cogent, par exemple, croit ses clients sur parole. Fin de l'édit

ÉDIT du 17/10/2017 à 9h25 : Comme la politique de routage IPv4 peut être différente de la politique de routage IPv6 (pairs différents, priorité différente, etc.), le RIPE recommande, dans ses formations, de publier les deux politiques de routage dans l'IRR. Cela se fait avec les attributs « mp-import » et « mp-export ». Exemple :

aut-num:        AS60630
[…]
import:         from AS174 accept ANY
export:         to AS174 announce AS-ARN
[…]
mp-import:      afi ipv6.unicast from AS174 accept ANY
mp-export:      afi ipv6.unicast to AS174 announce AS-ARN

Dans cet exemple, l'opérateur déclare être relié à Cogent (AS174) en IPv4 et en IPv6, qu'il lui annonce son réseau et celui de ses clients (AS-ARN) et que Cogent lui envoie la full view (ANY), c'est-à-dire toutes les routes qu'il connait.

Note : on peut remplacer « import » et « export » par « mp-import: afi ipv4.unicast » et par « mp-export: afi ipv4.unicast ». Les deux syntaxes sont équivalentes, la deuxième est plus moderne et plus lisible. Fin de l'édit du 17/10/2017 à 9h25

ÉDIT du 17/10/2017 à 9h40 : Il est possible de se connecter à des collecteurs (ring nlnog, route views, ripe stat, etc.) c'est-à-dire, à des projets qui sont des vigies d'observation d'Internet depuis lesquelles on voit battre le cœur d'Internet, on voit la topologie générale du réseau varier, on peut diagnostiquer et comprendre les pannes techniques, etc. Généralement, on envoie toutes nos routes à ces projets-là, mais lui ne nous envoie rien. Comment explicite-t-on cela dans la politique de routage ? Comme ceci :

aut-num:        AS60630
[…]
import:         from AS199036 accept NOT ANY
export:         to AS199036 announce ANY
[…]
mp-import:      afi ipv6.unicast from AS199036 accept NOT ANY
mp-export:      afi ipv6.unicast to AS199036 announce ANY

Dans cet exemple, l'opérateur déclare être connecté au looking glass du nlnog (AS199036), en IPv4 et en IPv6. Il déclare lui envoyer toutes les routes qu'il connaît (« export: […] ANY ») et que le nlnog ne lui envoie rien (« import: […] NOT ANY »). Oui, cette syntaxe « NOT ANY » n'est pas la plus intuitive qui soit… Fin de l'édit du 17/10/2017 à 9h40

Cogestion

Et pour faire de la cession de droits ou, à minima, de la cogestion sur des objets ? Il suffit de leur associer de nouveaux objets de type mntner dans leurs attributs « mnt-by » ou « mnt-* » pour des droits plus fins. Exemples : mnt-routes pointe sur un objet maintainer qui aura le droit d'ajouter des objets de type route/route6 en rapport avec l'objet courant ; mnt-domain = même principe mais pour les reverse v4/v6. L'authentification fonctionne selon un OU logique : toute personne qui aura un des mécanismes d'authentification d'un des maintainers pourra modifier l'objet.

ÉDIT du 26/04/2014 à 23h55 :

Modifier la base par mail avec signature PGP

Documentations : PGP Authentication in the RIPE Database — RIPE Network Coordination Centre ainsi que le tutoriel « Maintenance whois de Lulu » que j'ai linké en début de billet.

Notez qu'il n'est pas nécessaire d'utiliser PGP : vous pouvez envoyer vos modifications par mail en y ajoutant un attribut « password » contenant le mot de passe de votre objet maintainer en clair. Mais c'est mal, très mal. La réciproque n'est pas vraie : l'interface web ne supporte pas les signatures PGP.

Les robots à contacter (source) :

  • auto-dbm(at)ripe(dot)net pour la vraie DB
  • test-dbm(at)ripe(dot)net pour la DB de test (un greylisting est en place sur cette adresse)

La première étape pour soumettre vos modifications signées avec PGP par mail est de créer un objet de type « key-cert ». Il semble que le formulaire « individual fields » est cassé (il retourne toujours l'erreur « certif value is required ») donc utilisez le formulaire « single text area ».

KEY-CERT : PGPKEY-<ID_de_votre_cle>

CERTIF : votre clé publique au format ASCII obtenu avec gpg --armor --export <ID_de_votre_cle>. Il faut autant de lignes « certif » que de lignes dans la sortie gpg. Il faut conserver les lignes vides et les marqueurs de début et de fin de la clé.

Les autres attributs sont soit générés automatiquement (« method », « owner », « fingerpr ») soit facultatifs. On supprime les premiers. On complète ou non les seconds.

Exemple :

KEY-CERT:        PGPKEY-698DB1DD
CERTIF:          -----BEGIN PGP PUBLIC KEY BLOCK-----
CERTIF:          Version: GnuPG v1.4.12 (GNU/Linux)
CERTIF:          
CERTIF:          mQINBEvXHzcBEACwopvTtQLlh+vfqwolOHaplhV8x1zFjd1lT1E0CLwpsC5qpmQb
CERTIF:          o5bNlSoDDqlMG6IHP98TUWM24mZU626MuWHte/vMOE5X1Q7tk0TRREeYjXxBftaa
CERTIF:          9pGhynrjdk4FSDSZjZ5N0CgCDeX61j1TgCH0LT1EPB0/hJ+Tv2jDHc0vfCq6tnCg
CERTIF:          a3GoKrAlPOWff/nNFpXQwpLbeFDizurGXNDpGa5yBPfn0k8bKzhPa+h9geYIx+4e
CERTIF:          NbtG0J/g+GJuLhmlZyMVQ5+VYgeggbwLw8CvvcsH82v5PG5XIyceMqEXOvji5BOL
CERTIF:          jzuYFYF/XinPbWgz5q2+5hV3HsJz8jMHlkPZnj1hbHa9mT1A+xSFUQ95gbvRXgF2
CERTIF:          iOmewYUVPKoOfIhGis1cq1f4SlhrgO0vS32bBb/6hPp8EVeblGzMUhAyfc+RNbof
CERTIF:          IvUUlbp6CDy2qrCV4C0UHlyFMC4/11p2mZ63J0o88qL5sIAzwi7wuYfep+xjaYFv
CERTIF:          W8for8VZPtu9Fui6LyRvgv9OvUy5R+1wW2F1IChM9G4AbxdaYrtjtXuCuTVkfgdC
CERTIF:          CYabxcEQeh4uhjNqhP3hxAag7CI3KUud26w4Q/9kQ2BWxXMheZpDGkapfzJypbbe
CERTIF:          jLC7OHhqV6r+GoD8VmNMlKNQ/Jzvrf23Z2QLCuzSuIGwVIyKJG5y5ifecwARAQAB
CERTIF:          tCdKb25hdGhhbiBNaWNoYWxvbiA8am9obmRlc2NzQGdtYWlsLmmvbT6JAjcEEwEI
CERTIF:          ACEFAkvXHzcCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQqS0qaGeNoc1Z
CERTIF:          EA//YQ13Sl5rxBQuXZcxWvsBlON4ZjqfZB6HnOdeeIdEnR7hEVgICDD/3AEZKXs5
CERTIF:          38uwTO1h++2T47KsbBaKFK+bCJfzivSVHj6SWWlvhJZo5WUcNZ6NxX5iBfM+IZ9r
CERTIF:          /2z8LS+t/iv6jy0tNeziVCxIDf3KJ9FIUl0QOrKRMIaj9q66rkVk9qZuNQRfx+3B
CERTIF:          9g1eKyhLj/CFjzz1yANIK7Ga74bgYhXTxHEGK+JKOf+tq4RymYpdRu87YauwL3ZY
CERTIF:          KbQbG4JzNWsqnJint7pueiEOrCcTHecUgkpQpPXrk/J2Xt07XudvteUcArOoRNP4
CERTIF:          qdb9ku1kkbtlsc74DQwE9sysbZbYoIT1YD1y0x2S9IqYsW/NpsOCek+8viRUSTHK
CERTIF:          mHnYcR2RDB/6EkkU2Rwjjt3c1idnrl2u40jTtU6ZZ/3Cbqjs/HEvf5EFacxx1JVA
CERTIF:          RQI0pTja56qn3sk85avJfM1I4P0swG9Ga+wnb/K1nyuIBQJZO3W+SfpJFOgzmXBu
CERTIF:          M1IiXIjdCbzhHTcrbc9xnvaqXCf5L13ZQy+CpEyvVpAWOTd4s6Ia9PldlPaRWwIG
CERTIF:          faZKVjCKLaDKle75vrP48pinCFu5JJ+6BrTVR0LxJRsd/XF8fbcOwk4TH1z2/bOt
CERTIF:          N1N1dqHMx3RD/NZW+5nMae/MugVWZZUXJEremM3WpopvdciIRgQQEQgABgUCTL75
CERTIF:          gQAKCRD41bgH8Cma2QcnAKCWEllqpyiJn0Usj9iJa0xxsUKv2wCdFr7Buq1Ib+iu
CERTIF:          ufv5awslcQYCaNW0MEpvbmF0aGFuIE1pY2hhbG9uIChQZXJzbykgPGpvbmF0aGFu
CERTIF:          QG1pY2hhbG9uLmV1PokCNwQTAQgAIQUCUcNc4wIbAwULCQgHAwUVCgkICwUWAgMB
CERTIF:          AAIeAQIXgAAKCRCpLSpoZ42hzYaHEACqIwSOGZBPK6oT1S5PEweHC4MxgeaQQl/0
CERTIF:          uF3u4G/hEo20zVzrv4PSBuRwdBfCjnZE3NakRfJGx5Y4T2dkYrZXNrB2DG+kqyqw
CERTIF:          KMa06gC4ZGK+DyVusU5+qCLDeTXvtY6W5z7GQo1SV6iHE0iFKqoqjuaXXG8Wuh3t
CERTIF:          C12VoQOxWUi6VE6Z8Ys+E76YpLztOhy4nFeEBL8w1NIq8KDKlydjbLnBkhUes0IP
CERTIF:          tIdLynxqm+tkRUA9WaPSIY/KQoFAbTLP3WAjnNM7wCqShAwgTBhH8v66pYKt/qpk
CERTIF:          jvVCEx3C48TTDgmHXlhrZTYR5jA4wpnrJwP+FhyBdA+fKPmJHzmsNwT321fH1Z40
CERTIF:          x+xfTZSVjfkgoW9cl95Sy3JGeD1omHjmR5cURz7Iwyg02z+k86Ve44/TKMXgXa2F
CERTIF:          H7D8Zjv9AYP4xKzDF+QnPrl55KzotMX9r501AaYB913jJ14xRMFjqWphB2hijrhQ
CERTIF:          hebW5a/HI+aKLyWkdNOA7N0AYhJ5MAjaKjsG7LfOo69X7HUtWtLeOATjJFT8CgFB
CERTIF:          FfVJBrK5GQ1v6l7dgUKMgUsKCAhKE7TbU6sqWTT+ohFTHcHhlziwWA+3jEfhhR2y
CERTIF:          JFUBhZ/nFo2v69Okav29LKTooHKaFpHzXLbvUb4P/G/wX15LffHHYb9JvU+PXP1r
CERTIF:          ddSIxmwKRw==
CERTIF:          =zj2g
CERTIF:          -----END PGP PUBLIC KEY BLOCK-----
org:             ORG-TSTA1-TEST
admin-c:         JKB1-TEST
tech-c:          JKB1-TEST
MNT-BY:          TESTASSO-MNT
CHANGED:         ripedb@example.com 20140426
SOURCE:          TEST

Ce qui nous donne l'objet suivant une fois le formulaire validé :

whois -h whois-test.ripe.net -B -r PGPKEY-698DB1DD
% Information related to 'PGPKEY-698DB1DD'
 
key-cert:       PGPKEY-698DB1DD
method:         PGP
owner:          Jean-Kevin Boulay <jkb@example.net>
fingerpr:       E99E BD56 AA68 C0CD FEC2  EB25 A92D 2A68 698D B1DD
certif:         -----BEGIN PGP PUBLIC KEY BLOCK-----
certif:         Version: GnuPG v1.4.12 (GNU/Linux)
certif:          
certif:         mQINBEvXHzcBEACwopvTtQLlh+vfqwolOHaplhV8x1zFjd1lT1E0CLwpsC5qpmQb
certif:         o5bNlSoDDqlMG6IHP98TUWM24mZU626MuWHte/vMOE5X1Q7tk0TRREeYjXxBftaa
certif:         9pGhynrjdk4FSDSZjZ5N0CgCDeX61j1TgCH0LT1EPB0/hJ+Tv2jDHc0vfCq6tnCg
certif:         a3GoKrAlPOWff/nNFpXQwpLbeFDizurGXNDpGa5yBPfn0k8bKzhPa+h9geYIx+4e
certif:         NbtG0J/g+GJuLhmlZyMVQ5+VYgeggbwLw8CvvcsH82v5PG5XIyceMqEXOvji5BOL
certif:         jzuYFYF/XinPbWgz5q2+5hV3HsJz8jMHlkPZnj1hbHa9mT1A+xSFUQ95gbvRXgF2
certif:         iOmewYUVPKoOfIhGis1cq1f4SlhrgO0vS32bBb/6hPp8EVeblGzMUhAyfc+RNbof
certif:         IvUUlbp6CDy2qrCV4C0UHlyFMC4/11p2mZ63J0o88qL5sIAzwi7wuYfep+xjaYFv
certif:         W8for8VZPtu9Fui6LyRvgv9OvUy5R+1wW2F1IChM9G4AbxdaYrtjtXuCuTVkfgdC
certif:         CYabxcEQeh4uhjNqhP3hxAag7CI3KUud26w4Q/9kQ2BWxXMheZpDGkapfzJypbbe
certif:         jLC7OHhqV6r+GoD8VmNMlKNQ/Jzvrf23Z2QLCuzSuIGwVIyKJG5y5ifecwARAQAB
certif:         tCdKb25hdGhhbiBNaWNoYWxvbiA8am9obmRlc2NzQGdtYWlsLmmvbT6JAjcEEwEI
certif:         ACEFAkvXHzcCGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQqS0qaGeNoc1Z
certif:         EA//YQ13Sl5rxBQuXZcxWvsBlON4ZjqfZB6HnOdeeIdEnR7hEVgICDD/3AEZKXs5
certif:         38uwTO1h++2T47KsbBaKFK+bCJfzivSVHj6SWWlvhJZo5WUcNZ6NxX5iBfM+IZ9r
certif:         /2z8LS+t/iv6jy0tNeziVCxIDf3KJ9FIUl0QOrKRMIaj9q66rkVk9qZuNQRfx+3B
certif:         9g1eKyhLj/CFjzz1yANIK7Ga74bgYhXTxHEGK+JKOf+tq4RymYpdRu87YauwL3ZY
certif:         KbQbG4JzNWsqnJint7pueiEOrCcTHecUgkpQpPXrk/J2Xt07XudvteUcArOoRNP4
certif:         qdb9ku1kkbtlsc74DQwE9sysbZbYoIT1YD1y0x2S9IqYsW/NpsOCek+8viRUSTHK
certif:         mHnYcR2RDB/6EkkU2Rwjjt3c1idnrl2u40jTtU6ZZ/3Cbqjs/HEvf5EFacxx1JVA
certif:         RQI0pTja56qn3sk85avJfM1I4P0swG9Ga+wnb/K1nyuIBQJZO3W+SfpJFOgzmXBu
certif:         M1IiXIjdCbzhHTcrbc9xnvaqXCf5L13ZQy+CpEyvVpAWOTd4s6Ia9PldlPaRWwIG
certif:         faZKVjCKLaDKle75vrP48pinCFu5JJ+6BrTVR0LxJRsd/XF8fbcOwk4TH1z2/bOt
certif:         N1N1dqHMx3RD/NZW+5nMae/MugVWZZUXJEremM3WpopvdciIRgQQEQgABgUCTL75
certif:         gQAKCRD41bgH8Cma2QcnAKCWEllqpyiJn0Usj9iJa0xxsUKv2wCdFr7Buq1Ib+iu
certif:         ufv5awslcQYCaNW0MEpvbmF0aGFuIE1pY2hhbG9uIChQZXJzbykgPGpvbmF0aGFu
certif:         QG1pY2hhbG9uLmV1PokCNwQTAQgAIQUCUcNc4wIbAwULCQgHAwUVCgkICwUWAgMB
certif:         AAIeAQIXgAAKCRCpLSpoZ42hzYaHEACqIwSOGZBPK6oT1S5PEweHC4MxgeaQQl/0
certif:         uF3u4G/hEo20zVzrv4PSBuRwdBfCjnZE3NakRfJGx5Y4T2dkYrZXNrB2DG+kqyqw
certif:         KMa06gC4ZGK+DyVusU5+qCLDeTXvtY6W5z7GQo1SV6iHE0iFKqoqjuaXXG8Wuh3t
certif:         C12VoQOxWUi6VE6Z8Ys+E76YpLztOhy4nFeEBL8w1NIq8KDKlydjbLnBkhUes0IP
certif:         tIdLynxqm+tkRUA9WaPSIY/KQoFAbTLP3WAjnNM7wCqShAwgTBhH8v66pYKt/qpk
certif:         jvVCEx3C48TTDgmHXlhrZTYR5jA4wpnrJwP+FhyBdA+fKPmJHzmsNwT321fH1Z40
certif:         x+xfTZSVjfkgoW9cl95Sy3JGeD1omHjmR5cURz7Iwyg02z+k86Ve44/TKMXgXa2F
certif:         H7D8Zjv9AYP4xKzDF+QnPrl55KzotMX9r501AaYB913jJ14xRMFjqWphB2hijrhQ
certif:         hebW5a/HI+aKLyWkdNOA7N0AYhJ5MAjaKjsG7LfOo69X7HUtWtLeOATjJFT8CgFB
certif:         FfVJBrK5GQ1v6l7dgUKMgUsKCAhKE7TbU6sqWTT+ohFTHcHhlziwWA+3jEfhhR2y
certif:         JFUBhZ/nFo2v69Okav29LKTooHKaFpHzXLbvUb4P/G/wX15LffHHYb9JvU+PXP1r
certif:         ddSIxmwKRw==
certif:         =zj2g
certif:         -----END PGP PUBLIC KEY BLOCK-----
org:            ORG-TSTA1-TEST
admin-c:        JKB1-TEST
tech-c:         JKB1-TEST
mnt-by:         TESTASSO-MNT
changed:        ripedb@example.com 20140426
source:         TEST

La deuxième étape est de lier votre nouvel objet key-cert à votre objet de type mntner. Cela se fait avec un attribut « auth » dans l'objet mntner. Exemple : « auth: PGPKEY-698DB1DD ».

Vous pouvez désormais soumettre des objets signés par mail au robot du RIPE :

  1. Il faut obtenir une copie complète (-B) de l'objet que vous souhaitez modifier. Exemple :
    whois -h whois-test.ripe.net -B -r JKB1-TEST > jkb1
  2. On modifie avec notre éditeur de texte favori. Dans mon cas, j'ajoute un attribut « remarks » et un attribut « changed ».
  3. On signe en gardant le texte en clair (on ajoute la signature à la fin, voir : Gnu Privacy Guard (GnuPG) Mini Howto (Français)) :
    gpg -u <id_de_votre_cle> --armor --clearsign jkb1

    On obtient un fichier jkb1.asc qui contient quelque chose dans ce genre :

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256
     
    Avertissement : des options RIPE ont été utilisées avec un serveur classique.
    % This is the RIPE Database query service.
    % The objects are in RPSL format.
    %
    % The RIPE Database is subject to Terms and Conditions.
    % See http://www.ripe.net/db/support/db-terms-conditions.pdf
     
    % Information related to 'JKB1-TEST'
     
    person:         J-K Boulay
    address:        FR
    phone:          +33123456789
    e-mail:         ripedb@example.com
    nic-hdl:        JKB1-TEST
    mnt-by:         TESTASSO-MNT
    remarks:        Ceci est un test
    changed:        ripedb@example.com 20140418
    changed:        jkb@example.net 20140426
    source:         TEST
     
    % This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS4)
     
     
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.12 (GNU/Linux)
     
    iQIcBAEBCAAGBQJTXBLSAAoJEKktKmhnjaHNb4MP/0aF2GABfKvilKSrGiCn7RUH
    yQ9k4D8SN7nJi6jJK9skvcELTp7eTEuCQmvNTuO2RFg5362bm1UNOcjKZep5++8h
    i79wcjolfyxjkFrlOJaLVDmF1fVR+aqo5+ZoWNfbnba5pP8HyVY+n7027OvDO2yL
    mwcGSKD7h/Za2dYl0wnWF9dlmcIGcYk+m5ruKb3bqjpTF79n4S3/ua+WzACkX9UH
    Mg2B60xJoVIAO0A/o7y6UvxCO7+8mI/E3Y2B4AVYOvRaJ1QnJpU/Ty1csx9pDbJg
    dicChmOaZ+EbXYHLi0axc8ixucpo0mFIXQ4nIV1lear3E5EaVv7wx/wr1r7d5BYi
    g8BpLGB60hYBISpoEUlWF/V8hxf7pM3QNUagm+MjLzvMFLLcx9s58P0urVzijPPX
    b1H4Tzorx6Lcm512Gcu2IfHGVVxO0JTfCXPgubDTV2QcSS4RL5vF7C8J0nrGr59m
    Nw5hUBW+J0nV1418yVB4oXIC+Q0LFN5rfFRRlahhTZ5aGR/ieU+Ftk6MPE+Nt43o
    bfO64IfCkrb4XKSFzwbpCcFlAkImFuun74L+dOfVstzEMYc0p5XetN1IEhPeppiv
    j0S/p1tmCDHEkUZUkl51xAeRiQdqqVwx4P20tW7P9Dt7H4yqABgas6Yyia5DVjLj
    MZYvC/9Fm4s1ysKQctwP
    =74PE
    -----END PGP SIGNATURE-----
  4. On envoie notre objet signé avec notre MUA préféré. Exemple :
    mail -s "" test-dbm@ripe.net < jkb1.asc

On reçoit un mail récapitulatif : réussite ou échec, ce qui ne s'est pas bien passé, ... Exemple :

SUMMARY OF UPDATE:
 
Number of objects found:                   1
Number of objects processed successfully:  1
  Create:         0
  Modify:         1
  Delete:         0
  No Operation:   0
Number of objects processed with errors:   0
  Create:         0
  Modify:         0
  Delete:         0
 
DETAILED EXPLANATION:
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following object(s) were processed SUCCESSFULLY:
 
---
Modify SUCCEEDED: [person] JKB1-TEST   JK Boulay
 
 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The following paragraph(s) do not look like objects
and were NOT PROCESSED:
 
Avertissement : des options RIPE ont été utilisées avec un serveur classique.
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
 
% Information related to 'JKB1-TEST'
 
% This query was served by the RIPE Database Query Service version 1.72 (DBC-WHOIS4)
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
The RIPE Database is subject to Terms and Conditions:
http://www.ripe.net/db/support/db-terms-conditions.pdf
 
For assistance or clarification please contact:
RIPE Database Administration <ripe-dbm@ripe.net>
 
Generated by RIPE WHOIS Update version 1.72 on DBC-WHOIS2
Handled email update (TEST, 2014-04-26 23:42:04)

Il est possible de soumettre plusieurs objets en même temps, signés (avec la même clé ou non) ou non-signés (il faudra alors un mot de passe dans un attribut « password ») ce qui est très pratique pour une modification de masse. Un maintainer peut avoir plusieurs clés PGP. L'authentification se fait "en OU LOGIQUE" sur tous les moyens d'authentification (clé PGP ou non) associés à un des objets maintainer qui sont associés à l'objet à modifier.

Merci à Johndescs pour ces tests.
Fin de l'édit

Faire le ménage dans la base de test

Pour supprimer tous les objets que vous avez créés dans la base de test, il faut les rechercher et choisir l'option « delete ». À cause de la référence circulaire entre vos objets de types mntner et person, vous ne pourrez pas les supprimer directement. Néanmoins, sur cette base de test, on peut ruser : casser la référence circulaire en définissant « TEST-DBM-MNT » comme mntner de l'objet personn et « AA1-TEST » comme admin-c de l'objet mntner. Ça fonctionne uniquement car nous avons le mot de passe de « TEST-DBM-MNT ». J'imagine qu'il existe une méthode plus pragmatique voire un bête formulaire web mais je ne l'ai pas trouvé. Notons quand même que cette base de données est purgée tous les jours à 0h.

Dernières remarques

On notera que les attributs « tech-c » et « admin-c » de tous les objets peuvent pointer sur un seul et même objet de type person.

Enfin, si l'on souhaite visualiser les objets de la base du RIPE sous un format graphique conviviale, l'onglet « Database » de l'outil Ripestat est là pour ça.

ÉDIT du 26/04/2014 à 22h00 :
L'attribut « changed » doit dire qui a modifié/créé un objet et quand. Qui est une adresse email. Quand est une date au format AAAAMMJJ. Il n'est pas nécessaire de remplir la date, elle est auto-complétée. L'attribut changed ne se met pas à jour tout seul lors d'une modification. 😉 Il peut y avoir plusieurs attributs changed pour un même objet, ce qui permet d'avoir un historique des modifications de cet objet.

Ne pas créer/modifier deux objets en parallèle dans deux onglets différents du même navigateur si les deux objets ne sont pas dans la même source (RIPE/TEST) sinon l'application web se prend les pieds dans le tapis et vous hurle dessus : « Unrecognized source: TEST ». Dans cet exemple, ça parle de TEST alors que je voulais soumettre un objet dans RIPE mais comme j'avais ouvert ce formulaire puis ouvert un autre onglet dans TEST pour faire un test ...

Ce formulaire permet d'avoir rapidement l'adresse mail à contacter en cas d'abus. Il suffit de saisir une adresse IP, un ASN ou un inet(6)num. Cela retourne la valeur de l'attribut « abuse-mailbox » d'un objet de type « role » (qui représente une personne/un groupe de personnes dédié à la même tâche (administratif, adminsys, ...) au sein d'une organisation) lui même associé à un objet de type « organisation » (avec un attribut « abuse-c ») lui même associé à la ressource recherchée (aut-num ou inet(6)num). Si cette recherche est infructueuse (car pas d'objet organisation, car pas d'attribut « abuse-c », ...), elle se poursuit récursivement sur les ressources englobantes (as-block englobant, inet(6)num englobant). Merci à Lulu pour la découverte de ce formulaire.
Fin de l'édit

Ce billet relate la mise en œuvre d'un pare-feu redondant en utilisant OpenBSD, Packet Filter, CARP et pfsync.

Même si cette mise en œuvre se situe dans un cadre scolaire (« bouh c'est nul, on ne fait pas comme ça en vrai ! » diront certains), je pense qu'elle vaut la peine d'être partagée. La partie installation d'OpenBSD est un peu bête mais quand c'est exigé ... L'installation d'un pare-feu redondant n'était qu'une partie d'un travail plus vaste, cela explique certaines choses (adressage IP, CPE, ...).

Ce travail a été réalisé avec Hamza Hmama et Frédéric Deveaux.

Il y a déjà une masse de tutoriels concernant une telle mise en œuvre sur le web. Celui-ci se démarquera en montrant, de manière assez précise, comment valider le bon fonctionnement du pare-feu.

Table des matières

Présentation détaillée

L'objectif est de déployer un pare-feu hautement disponible pour protéger des serveurs publics qui se situent dans une DMZ.

Le firewall est un service indispensable dans un réseau pour assurer la sécurité des connexions entrantes et sortantes. Utiliser un firewall redondant permet de diminuer énormément le risque que celui-ci soit hors service. En effet, il faut que toutes les machines physiques qui composent le cluster du firewall soient hors service (panne, maintenance, ...) à un instant précis, ce qui est moins probable qu'une seule machine.

Quelques exemples de déploiements d'une solution de ce type en entrée de gros sites : université de Rennes 1 (500 Mbps en entrée) et École normale supérieure. Voir : présentation « OpenBSD/Packet-Filter retour d'expérience » par Patrick LAMAIZIERE aux JRES 2013.

Pour ce faire, nous allons utiliser deux PC, sur lesquelles nous allons installer OpenBSD et configurer CARP et pfsync.

CARP est un protocole réseau qui autorise plusieurs machines à se partager un groupe d'IP dites virtuelles. Cela permet la haute disponibilité : pour que le service ne soit plus accessible, il faut que l'intégralité des machines qui se partagent le groupe d'IP soit hors service. CARP peut aussi servir à faire du partage de charge entre plusieurs machines (mode actif/actif (voir 4.2.2) en utilisant plusieurs groupes de redondance qui se partagent une même VIP). Nous n'utiliserons pas cette fonctionnalité mais resterons en mode actif/attente). CARP est l'équivalent du protocole propriétaire HSRP de Cisco et du protocole VRRP publié à l'IETF.

Pfsync permet de synchroniser les états de Packet Filter entre toutes les machines du cluster. Ainsi, une connexion qui a commencé en passant par FW1 n'est pas interrompue quand FW1 tombe (panne) et que FW2 prend la main.

Il n'existe aucun outil pour effectuer la synchronisation des règles du pare-feu entre les différentes machines du cluster. Un simple transfert sécurisé (scp) du jeu de règles puis un chargement des règles sur chaque machine avec ssh suffit amplement et s'automatise avec un simple script shell. Des scripts shell plus complets peuvent être trouvés sur le web. Exemple : Script to sync pf rules for CARP fws .

L'équivalent GNU/Linux serait keepalived (démon VRRP) ou ucarp (implémentation de CARP pour GNU/Linux) et conntrackd (équivalent pfsync). Exemple de mise en pratique : Firewall HA with conntrackd and keepalived.

Voici un schéma de l'infrastructure que nous allons déployer :

Schéma de notre pare-feu hautement disponible

Schéma de notre pare-feu hautement disponible.

Nous utilisons un préfixe d'interconnexion /30 entre FW1 et FW2 pour le trafic pfsync. Le CPE est tout bêtement un PC qui exécute Dynamips. Derrière lui se trouve le réseau des utilisateurs.

Mise en œuvre

Il existe plusieurs manières de faire à chaque étape, plusieurs valeurs sont possibles pour chaque paramètre, ... Référez-vous à la documentation OpenBSD pour plus d'informations.

Installation d'OpenBSD

D'abord, on crée un médium d'installation. Malgré le fait d'avoir suivi plusieurs tutoriels disponibles sur le web (sauf ceux impliquant l'utilisation d'une machine virtuelle et/ou une première installation sur la clé elle-même, manque de temps), nous n'avons pas réussis à obtenir une clé USB bootable d'installation d'OpenBSD. Dans ce cas, il faut récupérer et graver l'ISO du CD d'installation de la dernière version stable d'OpenBSD. À l'heure actuelle, elle est disponible à cette URL : ftp://ftp.fr.openbsd.org/pub/OpenBSD/5.4/amd64/install54.iso.

Ensuite, il faut installer OpenBSD sur FW1 et FW2. On peut aussi effectuer une seule installation puis cloner le disque dur sur la deuxième machine, via le réseau, en utilisant Clonezilla. Ci-dessous, la procédure d'installation d'OpenBSD :

  1. Il faut aller dans le BIOS pour configurer le boot à partir du CD d'installation. Ce réglage dépend du type de BIOS, de la version, ... Dans notre cas, pour accéder à l'interface de configuration, il faut appuyer sur la touche « Suppr » du clavier au début de la procédure de démarrage du PC. Il faut ensuite se déplacer dans « Advanced BIOS Features » puis positionner la valeur « USB-CDROM » pour le paramètre « First Boot Device ». Il faut vérifier que le paramètre « Second Boot Device » est bien configuré à la valeur « Hard Disk ». Enfin, il faut revenir au menu principal à l'aide de la touche « Echap » et choisir « Save & Exit Setup ». Au reboot automatique, la machine démarrera sur le CD d'installation OpenBSD.
  2. À l'invite « boot> », il faut appuyer sur la touche « Entrée » du clavier.
  3. « (I)nstall, (U)pgrade or (S)hell? » : Choisir « Install » en tapant « I » et « Entrée ».
  4. « Choose your keyboard layout » : taper « fr » et « Entrée ».
  5. « System hostname? » : taper « FW1 » ou « FW2 » et « Entrée ».
  6. Configuration réseau :
    • « Which one do you wish to configure? » : « done » et « Entrée ».
    • « DNS domain name? » : accepter la proposition par défaut en appuyant sur « Entrée ».
    • « DNS nameservers? » : accepter la proposition par défaut en appuyant sur « Entrée ».
  7. « Password for root account? » : taper le mot de passe de votre choix (ici : « toor ») et « Entrée ». « again » : retaper votre mot de passe et « Entrée ».
  8. « Start sshd by default? » : accepter la proposition par défaut (yes) en appuyant sur « Entrée ».
  9. « Start ntpd by default? » : accepter la proposition par défaut (no) en appuyant sur « Entrée ». La synchronisation de l'horloge est importante, notamment pour la cohérence des logs mais comme notre maquette n'est pas connectée à Internet, nous ne pouvons accéder à aucun serveur de temps.
  10. « Do you expect to run the X Window System ? » : « no » et « Entrée ».
  11. « Setup a user? » : accepter la proposition par défaut (no) en appuyant sur « Entrée ».
  12. Configuration des disques durs/partitionnement :
    • « Which disk is the root disk? » : accepter la proposition par défaut en appuyant sur « Entrée ».
    • « Use DUIDs in fstab? » : accepter la proposition par défaut (yes) en appuyant sur « Entrée ».
    • « Whole disk or edit the MBR? » : accepter la proposition par défaut (whole) en appuyant sur « Entrée ».
    • « (A)uto layout, (E)dit auto layout, or create (C)ustome layout? » : accepter la proposition par défaut (auto layout) en appuyant sur « Entrée ».
  13. Source de l'installation :
    • « Location of sets? » : accepter la proposition par défaut (cd) en appuyant sur « Entrée ».
    • « Which one contains the install media? » : accepter la proposition par défaut (cd0) en appuyant sur « Entrée ».
    • « Pathname to the sets? » : accepter la proposition par défaut (5.4/amd64) en appuyant sur « Entrée ».
    • « Set name(s)? » : accepter la proposition par défaut (done) en appuyant sur « Entrée ».
  14. L'installation s'effectue ...
  15. « Location of sets » : nous ne voulons rien installer de plus donc accepter la proposition par défaut (done) en appuyant sur « Entrée ».
  16. « What timezone are you in? » : taper « Europe/Paris » puis « Entrée ».
  17. Taper « reboot » puis « Entrée ».

Configuration réseau

Configuration des interfaces réseau de FW1
echo "inet 170.16.3.129 255.255.255.248 NONE" > /etc/hostname.em0
echo "inet 170.16.3.193 255.255.255.192 NONE" > /etc/hostname.em1
echo "inet 192.168.1.1 255.255.255.252 NONE" > /etc/hostname.em2
Configuration des interfaces réseau de FW2
echo "inet 170.16.3.130 255.255.255.248 NONE" > /etc/hostname.em0
echo "inet 170.16.3.194 255.255.255.192 NONE" > /etc/hostname.em1
echo "inet 192.168.1.2 255.255.255.252 NONE" > /etc/hostname.em2
Configuration de la route par défaut sur FW1 et FW2

On configure une route par défaut via le CPE :

echo "170.16.3.132" > /etc/mygate
Activation de l'IP forwarding sur FW1 et FW2

On active l'ip forwarding en décommentant la ligne « net.inet.ip.forwarding=1 » dans le fichier /etc/sysctl.conf.

Configuration de l'interface réseau du CPE
conf t
  int fastEthernet 0/3
    ip address 170.16.3.132 255.255.255.248
    no sh
Ajout d'une route sur le CPE

Sur le CPE, on ajoute une route pour joindre le réseau des serveurs (170.16.3.192/26) via les FW

conf t
  ip route 170.16.3.192 255.255.255.192 170.16.3.131
Configuration de l'interface de notre serveur de test

Pour cela, on ajoute les lignes suivantes au fichier /etc/network/interfaces :

iface eth0 inet static
  address 170.16.3.196
  netmask 26
  gateway 170.16.3.195

CARP

Configuration des paramètres généraux de CARP sur FW1 et FW2

Pour cela, il faut rajouter les lignes suivantes dans le fichier /etc/sysctl.conf :

net.inet.carp.allow=1
net.inet.carp.preempt=1

« net.inet.carp.allow=1 » permet d'accepter les paquets du protocole CARP qui arrivent par le réseau.

« net.inet.carp.preempt=1 » permet d'optimiser l'élection du maître dans un groupe de redondance. Cela permet également de basculer toutes les interfaces d'un même groupe de redondance sur un même hôte en même temps.

Configuration des deux interfaces CARP sur FW1
echo "inet 170.16.3.131 255.255.255.248 170.16.3.135 vhid 1 carpdev em0 advskew 1 pass toor" > /etc/hostname.carp0
echo "inet 170.16.3.195 255.255.255.192 170.16.3.255 vhid 2 carpdev em1 advskew 1 pass toor" > /etc/hostname.carp1

« vidh X » : Virtual Host ID. C'est un numéro unique par réseau qui permet d'identifier un groupe de redondance CARP sur ce réseau. Les valeurs possibles sont comprises dans l'intervalle [1,255].

« carpdev » permet de spécifier l'interface réseau physique à utiliser pour ce groupe de redondance CARP.

« advskew X » permet d'introduire un biais pour forcer le choix lors de l'élection du maître du groupe de redondance. Plus la valeur de ce paramètre est élevée, moindre sont les chances de cet hôte de devenir le maître. Dans notre cas, c'est utile pour que les deux IP virtuelles (une sur le réseau d'interconnexion, l'autre sur le réseau des serveurs) soient attribuées au même hôte.

« pass <mot_de_passe> » est le mot de passe à utiliser lors de la communication avec les autres machines du même groupe de redondance. Évidemment, ce mot de passe doit être identifique sur toutes les machines d'un même groupe de redondance.

Configuration des interfaces CARP sur FW2
echo "inet 170.16.3.131 255.255.255.248 170.16.3.135 vhid 1 carpdev em0 advskew 100 pass toor" > /etc/hostname.carp0
echo "inet 170.16.3.195 255.255.255.192 170.16.3.255 vhid 2 carpdev em1 advskew 100 pass toor" > /etc/hostname.carp1

Configuration de Packet Filter

Règles de filtrage

On crée notre propre jeu de règles de filtrage minimaliste puis on l'insère dans le fichier /etc/pf.conf (en supprimant l'existant) de FW1 et FW2 afin qu'il soit appliqué automatiquement à chaque démarrage des deux machines :

# On bloque tout sauf ce qui passe sur la loopback
block
set skip on lo
 
# CARP
pass on { em0 em1 } proto carp keep state
 
# SSH depuis le réseau utilisateur vers les serveurs
pass in on em0 inet proto tcp from 170.16.3.0/24 to 170.16.3.196 port 22 keep state
 
# ICMP partout
pass inet proto icmp from any to any keep state

pfsync

Configuration de l'interface pfsync sur FW1
echo "up syncpeer 192.168.1.2 syncdev em2" > /etc/hostname.pfsync0

Par défaut, les mises à jour des états se font en multicast. Le paramètre « syncpeer » permet de faire les mises à jour d'état en unicast avec uniquement l'hôte spécifié.

« syncdev » permet de spécifier l'interface réseau physique à utiliser pour envoyer/recevoir le trafic pfsync.

Il faut noter que pfsync est assez gourmand en fonction de l'usage et donc du type de trafic qui passe par le pare-feu redondant, c'est pour cela qu'on conseille un lien réseau dédié à pfsync. Dans l'exemple de l'université de Rennes 1 cité plus haut, ils ont une majorité de trafic web. Rappel : pour une même page web, il faut établir XX connexions pour récupérer le contenu (js (comme jquery) stocké ailleurs, polices stockées ailleurs, pubs, ...). Cela génère des états au niveau des firewall et donc, du trafic pfsync pour échanger ces états. En pointe, ils observent 150 Mbps de trafic sur leur lien dédié pfsync.

Configuration de l'interface pfsync sur FW2
echo "up syncpeer 192.168.1.1 syncdev em2" > /etc/hostname.pfsync0
On autorise le protocole pfsync dans Packet Filter, sur FW1 et FW2

Pour cela, on ajoute la règle suivante aux fichiers /etc/pf.conf :

# pfsync
pass on em2 proto pfsync keep state

Valider le bon fonctionnement de notre pare-feu redondant

Il suffit de rebooter toutes les machines (FW1, FW2, serveur de test) pour que la configuration soit appliquée. Ou, de manière plus pragmatique, on peut appliquer les changements à chaud. Sur FW1 et FW2 :

# Recharger le réseau
sh /etc/netstart
 
# IP forwarding et CARP
sysctl -w net.inet.ip.forwarding=1
sysctl -w net.inet.carp.allow=1
sysctl -w net.inet.carp.preempt=1 
 
# Charger le jeu de règles dans PF et activer PF
pfctl -f /etc/pf.conf 
pfctl -e

Sur la machine de test :

ifup eth0

On peut ensuite vérifier que tout fonctionne comme attendu.

Connectivité

On vérifie que le réseau est fonctionnel en faisant passer un ping depuis une machine de test dans le réseau des utilisateurs vers notre serveur de test :

toto@client: # ping 170.16.3.196
PING 170.16.3.196 (170.16.3.196) 56(84) bytes of data.
64 bytes from 170.16.3.196: icmp_req=1 ttl=63 time=1.99 ms
64 bytes from 170.16.3.196: icmp_req=2 ttl=63 time=1.45 ms
64 bytes from 170.16.3.196: icmp_req=3 ttl=63 time=1.16 ms
64 bytes from 170.16.3.196: icmp_req=4 ttl=63 time=1.45 ms

CARP

On constate que CARP est fonctionnel en regardant la sortie de l'outil ifconfig.

Sur FW1 :

# ifconfig carp
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:01
        priority: 0
        carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 1
        groups: carp
        status: master
        inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x6
        inet 170.16.3.131 netmask 0xfffffff8 broadcast 170.16.3.135
carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        lladdr 00:00:5e:00:01:02
        priority: 0
        carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 1
        groups: carp
        status: master
        inet6 fe80::200:5eff:fe00:102%carp1 prefixlen 64 scopeid 0x7
        inet 170.16.3.195 netmask 0xffffffc0 broadcast 170.16.3.255

On constate que FW1 est bien le maître des deux groupes de redondances (« carp: MASTER »).

Sur FW2 :

# ifconfig carp
carp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    lladdr 00:00:5e:00:01:01
    priority: 0
    carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
    groups: carp
    status: backup
    inet6 fe80::200:5eff:fe00:101%carp0 prefixlen 64 scopeid 0x6
    inet 170.16.3.131 netmask 0xfffffff8 broadcast 170.16.3.135
carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    lladdr 00:00:5e:00:01:02
    priority: 0
    carp: BACKUP carpdev em1 vhid 2 advbase 1 advskew 100
    groups: carp
    status: backup
    inet6 fe80::200:5eff:fe00:102%carp1 prefixlen 64 scopeid 0x7
    inet 170.16.3.195 netmask 0xffffffc0 broadcast 170.16.3.255

On constate que FW2 est bien en backup sur les deux groupes de redondances (« carp: BACKUP »).

Une capture réseau depuis FW2 nous montre que FW1 est le maître sur l'IP virtuelle 170.16.3.131 et qu'en conséquence, il diffuse des messages « CARP advertisement » à fréquence régulière (ici : 1 seconde, paramétrable en changeant la valeur du paramètre « advbase ») :

# tcpdump -tttttvvni em0
tcpdump: listening on em0, link-type EN10MB
1.019374 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=1 demote=0 (DF) [tos 0x10] (ttl 255, id 10529, len 56)
2.040085 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=1 demote=0 (DF) [tos 0x10] (ttl 255, id 19703, len 56)
3.060098 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=1 demote=0 (DF) [tos 0x10] (ttl 255, id 41787, len 56)
4.080206 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=1 demote=0 (DF) [tos 0x10] (ttl 255, id 55471, len 56)

Si nous coupons l'interface carp0 sur FW1, celui-ci cesse d'émettre, les FW restants émettent des advertisement, une nouvelle élection a lieu entre les FW restants (dans notre cas : uniquement FW2) et FW2 devient le nouveau maître pour l'IP virtuelle 170.16.3.131 :

# tcpdump -tttttvvni em0
tcpdump: listening on em0, link-type EN10MB
5.099795 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=1 demote=0 (DF) [tos 0x10] (ttl 255, id 16645, len 56)
6.119458 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=1 demote=0 (DF) [tos 0x10] (ttl 255, id 20322, len 56)
7.4294686187 carp 170.16.3.129 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=255 advskew=255 demote=0 (DF) [tos 0x10] (ttl 255, id 33756, len 56)
7.4294688491 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 22655, len 56)
8.129407 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 31522, len 56)
10.4294507802 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 35522, len 56)
11.4294916715 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 35096, len 56)
12.359366 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 63215, len 56)
14.4294736635 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 17132, len 56)
15.179471 carp 170.16.3.130 > 224.0.0.18: CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10] (ttl 255, id 32836, len 56)

Les logs (/var/log/messages) de FW2 nous montrent également la transition :

fw2 /bsd: carp0: state transition: BACKUP -> MASTER
fw2 /bsd: carp1: state transition: BACKUP -> MASTER

Quand FW1 est remis en état, il reprend la main et, dans les logs de FW2, nous lisons :

fw2 /bsd: carp1: state transition: MASTER -> BACKUP
fw2 /bsd: carp0: state transition: MASTER -> BACKUP

Pfsync

On vérifie que les interfaces pfsync sont up.

Sur FW1 :

# ifconfig pfsync0
pfsync0: flags=41<UP,RUNNING> mtu 1500
        priority: 0
        pfsync: syncdev: em2 syncpeer: 192.168.1.2 maxupd: 128 defer: off
        groups: carp pfsync

Note : « defer » est un paramètre qui peut être positionné à la valeur « on » pour faire en sorte qu'une connexion n'est réellement acceptée que si le pair pfsync a acquitté la modification de la table des états ou que le délai d'attente pour cet acquittement a expiré. Cela permet une plus grande cohérence entre les pare-feu et est indispensable lorsque plus d'un pare-feu doit s'occuper activement des paquets (typiquement : répartition de la charge).

Sur FW2 :

# ifconfig pfsync0
pfsync0: flags=41<UP,RUNNING> mtu 1500
        priority: 0
        pfsync: syncdev: em2 syncpeer: 192.168.1.1 maxupd: 128 defer: off
        groups: carp pfsync

On constate aussi l'existence d'un trafic réseau pfsync sur le lien d'interconnexion entre les deux pare-feux :

# tcpdump -tttttvvni em2
tcpdump: listening on em2, link-type EN10MB
0.007794 192.168.1.1 > 192.168.1.2: PFSYNCv6 len 276
    act UPD ST COMP count 3
    ...
 (DF) [tos 0x10] (ttl 255, id 38708, len 296)
0.410334 192.168.1.2 > 192.168.1.1: PFSYNCv6 len 276
    act UPD ST COMP count 3
    ...
 (DF) [tos 0x10] (ttl 255, id 22377, len 296)
0.410597 192.168.1.2 > 192.168.1.1: PFSYNCv6 len 108
    act UPD ST COMP count 1
    ...
 (DF) [tos 0x10] (ttl 255, id 51022, len 128)
0.410692 192.168.1.2 > 192.168.1.1: PFSYNCv6 len 108
    act UPD ST COMP count 1
    ...
 (DF) [tos 0x10] (ttl 255, id 40898, len 128)
0.410730 192.168.1.1 > 192.168.1.2: PFSYNCv6 len 276
    act UPD ST COMP count 3
    ...
 (DF) [tos 0x10] (ttl 255, id 65488, len 296)
0.410774 192.168.1.2 > 192.168.1.1: PFSYNCv6 len 108
    act UPD ST COMP count 1
    ...
 (DF) [tos 0x10] (ttl 255, id 24885, len 128)

Enfin, en établissant une session SSH depuis le réseau des utilisateurs vers notre serveur de test, alors que FW1 est le maître sur les deux interfaces CARP, nous constatons que les tables d'états des deux pare-feux sont synchronisées.

Sur FW1 :

# pfctl -ss
all carp 170.16.3.129 -> 224.0.0.18       SINGLE:NO_TRAFFIC
all carp 170.16.3.193 -> 224.0.0.18       SINGLE:NO_TRAFFIC
all pfsync 192.168.1.1 -> 192.168.1.2       MULTIPLE:MULTIPLE
all carp 224.0.0.18 <- 170.16.3.129       NO_TRAFFIC:SINGLE
all carp 224.0.0.18 <- 170.16.3.193       NO_TRAFFIC:SINGLE
all tcp 170.16.3.196:22 <- 170.16.3.132:33607       ESTABLISHED:ESTABLISHED
all tcp 170.16.3.132:33607 -> 170.16.3.196:22       ESTABLISHED:ESTABLISHED

Sur FW2 :

# pfctl -ss
all carp 170.16.3.129 -> 224.0.0.18       SINGLE:NO_TRAFFIC
all carp 170.16.3.193 -> 224.0.0.18       SINGLE:NO_TRAFFIC
all pfsync 192.168.1.2 <- 192.168.1.1       MULTIPLE:MULTIPLE
all carp 224.0.0.18 <- 170.16.3.129       NO_TRAFFIC:SINGLE
all carp 224.0.0.18 <- 170.16.3.193       NO_TRAFFIC:SINGLE
all tcp 170.16.3.196:22 <- 170.16.3.42:33607       ESTABLISHED:ESTABLISHED
all tcp 170.16.3.42:33607 -> 170.16.3.196:22       ESTABLISHED:ESTABLISHED

Si l'on coupe brutalement les interfaces réseau de FW1 (ou FW1 lui-même), on constate que FW2 prend le relais et que la session SSH n'est pas interrompue car les états des deux pare-feux sont cohérents et synchronisés.

Sources

Bilan et perspectives de la première lecture du Parlement européen d'une proposition de règlement européen concernant, entre autres, la neutralité des réseaux.

Ce billet est dans la continuité du précédent, que je vous recommande de lire si la neutralité des réseaux au Parlement européen ne vous évoque rien.

Table des matières

De la victoire au Parlement européen

Le 3 avril dernier, le Parlement européen, en séance plénière, a adopté la proposition d'un règlement européen nommé « Marché Unique des Communications Électroniques visant à faire de l'Europe un continent connecté », y compris les amendements 234-244 qui vont dans le sens d'une protection forte de la neutralité des réseaux déposés par les groupes S&D, Verts/ALE, GUE/NGL et, dans une moindre mesure, ADLE (leurs amendements 234-236 sont moins complets sur les considérants, l'article 12bis et l'article 24).

Pour savoir quel député européen a voté quoi, en vue des prochaines élections européennes par exemple 😉 , c'est par ici : Procès Verbal - Résultat des votes par appel nominal - Annexe (page 33 à 52).

De la mobilisation citoyenne

Cette première victoire, comme toutes les victoires déjà remportées (HADOPI, ACTA, IEF, ...), a été possible uniquement parce que des citoyens se sont bougé le cul. Les amendements pro-neutralité des réseaux n'auraient jamais été adoptés sans cela, ne vous faites pas d'illusions !

On parle de plus de 20000 fax envoyés et de plus de 360 appels téléphoniques effectués ! Et cela, c'est uniquement sur la plateforme savetheinternet.eu. Impossible de quantifier les fax, les appels téléphoniques et les emails qui n'ont pas été effectués depuis cette plateforme. Cela représente un nombre d'appels téléphoniques et de fax supérieur à ce qui a été fait contre ACTA !

Du lulz

Quelques épisodes rigolos se sont produits aux alentours du vote du Parlement européen du 3 avril dernier :

  • La députée S&D UK Arlene McCarthy qui appelle ses collègues S&D UK à voter contre les amendements pro-neutralité des réseaux déposés par les groupes S&D/Verts/GUE sous prétexte de la pédopornographie (source) ... mais qui finalement ne vient pas voter. Son appel sonne comme "on n'est pas foutu de faire coopérer nos polices nationales donc on va taper autrement". Ce n'est pas en bloquant bêtement l'accès aux contenus pedoporn' qu'on va sauver les victimes. Fermer les yeux plutôt que de combattre ... Drôles de comportements ... Il faut dire que la censure des réseaux actuellement en cours en Angleterre a permis de sauver des enfants et n'a bien évidemment pas bloqué tout un tas de ressources légitimes ... (ironie), voir : Le filtre du gouvernement britannique contre les sites porno bloque bien plus que ça.
  • « @laquadrature wants to limit the European Internet and restrict the freedom of the consumers. Why? @markscott82 #ETNO » - Luigi Gambardella, président exécutif de l'association européenne des opérateurs réseaux (source). Je trouve ça savoureux : accuser les autres du mal que l'on fait soi-même.

Et après ?

Le 3 avril dernier, ce n'était que la première lecture du Parlement européen, soit une étape parmi d'autres dans le processus législatif. La prochaine étape sera la première lecture de ce texte par le Conseil de l'Union Européenne (co-législateur, comme le Sénat et l'Assemblée Nationale en France). Il délibérera sur un premier rapport d'orientation le 6 juin prochain (« CONSEIL TRANSPORTS, TELECOM ET ENERGIE (TELECOM) »).

Chaque État membre délègue son ministre concerné par le sujet des débats à l'ordre du jour d'une réunion du Conseil. Ministre, nommé par le Président lui-même élu par les citoyens : on sent bien que les citoyens ne sont pas représentés au Conseil et n'ont quasiment aucun moyen d'action. En revanche, les lobbies de l'industrie des télécoms ont le champ libre pour se faire entendre ...

Avec du bon sens, on pourrait penser que la ministre qui sera déléguée de la France au Conseil de l'Union européenne sera Christiane Taubira puisque la neutralité des réseaux est beaucoup plus une question de libertés à l'heure numérique qu'autre chose. Mais il n'en sera rien. Le texte étant relatif aux télécoms, les télécoms étant rattachées à l'industrie, l'industrie étant du redressement productif (source, à partir de 2h24m27s), la probabilité qu'Arnaud Montebourg soit le ministre délégué de la France est forte.

La position actuelle du gouvernement français est sans ambiguïté à ce sujet : oui aux services spécialisés et non à tous les amendements pro-neutralité des réseaux qui ont pourtant été adoptés le 3 avril dernier par le Parlement. Voir : Neutralité du net : la France plaide pour les services spécialisés chez Next Inpact.

Une démobilisation des citoyens, croyant avoir gagné, serait une grande erreur : nous n'avons pas encore gagné et nous ne gagnerons peut-être pas !

Comment agir ?

  • En se tenant informer. Par exemple, chez la Quadrature du Net.
  • En diffusant l'information.
  • En cherchant quel sera le ministre français délégué au Conseil de l'Union Européenne (Arnaud Montebourg ?) et en le contactant pour tenter de le convaincre que la neutralité des réseaux est importante.
  • Financer un lobby citoyen (par exemple : La Quadrature du Net) ... Puisque les députés n'écoutent que les lobbies et puisque les opérateurs réseaux (ou les producteurs de CD/DVD/Blu-ray, ...) sont capables de se liguer en de puissants lobbies bah ... formons un lobby citoyen pour nous faire entendre. Vous n'aimeriez pas faire bénévolement l'immense travail quotidien que fait la Quadrature alors que les lobbies n'ont que ça à faire de leurs journées.

Nous avons approximativement 2 mois, jusqu'au 5 juin au plus tard, pour nous bouger.

Mon humble avis

  • Il est évident que le texte tel qu'il est amendé actuellement va se faire amocher au Conseil de l'Union Européenne, particulièrement sur la notion de services spécialisés/gérés.
  • Néanmoins, je pense qu'un certain nombre d'États membres écouteront leurs citoyens et iront dans le sens d'une protection forte d'un internet neutre, ouvert et libre. Je pense aux Pays-Bas (qui ont déjà une loi pro-neutralité des réseaux au niveau local et qui ne voudront sûrement pas la perdre), à la Suède (qui a déjà des lois plus adaptées au numérique que les nôtres), à la Pologne (les eurodéputés polonais avaient fait un travail magnifique sur ACTA. J'espère que le gouvernement polonais est aussi protecteur des libertés fondamentales), à l'Allemagne (culture hacker très forte et intégrée qui se fait écouter) et aux pays baltes (qui sont fortement connectés et doivent, peut-être, mieux comprendre les enjeux de la neutralité des réseaux).
  • À l'inverse, d'autres pays, comme la France ou l'Angleterre, iront totalement contre la neutralité des réseaux.
  • Le vote au Conseil est à la majorité qualifiée. Un vote favorable de la part d'un regroupement de petits pays (en terme de nombre d'habitants) sera insuffisant pour obtenir cette majorité qualifiée.
  • Il va y avoir un bras de fer entre Parlement et Conseil, entre lobbies citoyens et lobbies de l'industrie des télécoms. Ce texte de loi est important pour les deux parties. Pour les citoyens : limiter les atteintes, garantir un Internet neutre, ouvert et libre ainsi que les libertés fondamentales. Pour l'industrie des télécoms : obtenir une définition biaisée de la neutralité des réseaux, notamment en ce qui concerne les services spécialisés/gérés, dans toute l'Union Européenne, sans avoir à craindre d'éventuelles futures législations nationales contraignantes. Les deux parties ont donc intérêt à accepter des contre-parties plutôt que de voir le texte rejeté dans son intégralité soit par le Parlement, soit par le Conseil si aucun compromis n'est trouvé.
  • Au-delà du processus législatif, il faudrait voir comment les opérateurs réseaux utiliseront les flous et les manques actuels (articles 23.5.c, article 23.5.d selon moi, voir mon précédent billet) et à venir (en fonction des compromis Parlement/Conseil), pour contourner le principe de neutralité des réseaux. Ensuite, il faudra voir comment tout citoyen pourra agir contre une atteinte de son FAI et quelles seront les sanctions. Sans sanctions, pas d'autorité. L'article 24 du Règlement prévoit deux-trois trucs, comme « Les autorités réglementaires nationales mettent en place des mécanismes clairs et compréhensibles de notification et de recours pour les utilisateurs finaux victimes de discrimination, de limitation, d'interférence, de blocage ou d'étranglement du trafic tant en ce qui concerne les contenus et les services que les applications en ligne. ». Ça me semble extrêmement léger puisque, actuellement, l'ARCEP (autorité française de régulation des télécoms) ne peut pas s'auto-saisir quand elle constate un problème et que les citoyens ne peuvent pas la saisir car il faut avoir un intérêt à agir donc que votre FAI porte atteinte à vos intérêts économiques. De plus, l'ARCEP gère uniquement des conflits entre opérateurs ... (source : Benjamin Bayart - Programme de travail législatif - à partir de la 50éme minute)

Bilan personnel

Je retiens que depuis ACTA, rien n'a changé :

  • Le processus législatif et les textes produits sont toujours aussi compliqués alors que les sujets qu'ils traitent sont d'une simplicité effarante ... Le merdier est assez dur à suivre ... Heureusement que de bonnes volontés comme La Quadrature du Net rendent tout cela plus accessible.
  • On a toujours autant de mal à avoir un dialogue actif/actif, un dialogue constructif et pas juste des réponses clé en main voire des communiqués de presse avec nos représentants. C'est vraiment dommage de ne pas pouvoir avoir des dialogues plus humains et plus horizontaux avec nos représentants. Je comprends sans peine que ça puisse démotiver des citoyens de les contacter.
  • Un entête « Reply-to / Répondre à », ça sauve la vie quand vous êtes plusieurs auteurs derrière un mail (mail co-écrit/co-signé) et que nous ne voulez pas que l'expéditeur principal passe son temps à vous transférer les éventuelles réponses des députés.
  • Le Parlement européen grouille de logiciels privateurs : serveurs de mails Microsoft/Clearswift, streaming des sessions avec des technos Microsoft, travail législatif sous Microsoft Word (le site web du Parlement propose tout de même une version PDF). La souveraineté et l'indépendance de l'Union qu'ils disent.
  • Les serveurs de mails du Parlement ne causent pas TLS ... Elle a dit quoi, déjà, Angela Merkel ? Ha oui : pour lutter contre l'espionnage des puissances étrangères, il nous faut un Internet européen (voir, par exemple Angela Merkel réclame un Internet européen. Qu'est-ce que ça veut dire?). C'est idiot et on peut commencer par des choses toutes simples qui ont du sens, qui existent déjà et qui ne coûtent rien à déployer.

Ressources

Quelques ressources supplémentaires qui peuvent aider à la compréhension / élargir les horizons :

De la neutralité des réseaux en Union européenne

Un billet pour rappeler ce qui se joue en ce moment au Parlement européen en ce qui concerne un Internet ouvert et libre ainsi que pour vous donner envie de vous bouger avant qu'il ne soit trop tard.

ÉDIT du 20/04/2014 à 15h55 : Ce billet, en dehors des définitions qu'il pose est inutile depuis le 3 avril 2014, date du vote au Parlement européen. J'ai écris un nouveau billet dans la foulée pour dresser un bilan et les perspectives de la première lecture au Parlement européen. Fin de l'édit

Table des matières

Un Fournisseur d'Accès à Internet ?

Oui, bonne réponse, les membres de la fédération FDN ! Bon si vous avez répondu Orange/Free/Bouygues/Numéricable, ça marche aussi, c'est juste pour ouvrir vos horizons. Bref, vous savez tous ce que c'est, c'est pas là où j'veux en venir.

Un opérateur réseau tel un fournisseur d'accès à Internet est un intermédiaire technique indispensable, un point de passage obligatoire, entre une personne et sa vie numérique. Essayez d'aller sur Internet sans FAI, vous n'y arriverez pas (non, le cybercafé du coin aussi a recours à un FAI ; non, votre université/entreprise aussi a recours a un FAI).

En conséquence, un opérateur réseau a les pleins pouvoirs : il peut surveiller, censurer, discriminer, altérer, ralentir les communications électroniques de ses abonnés. À l'heure où la plus grande partie de nos vies se déroule via le numérique (notre accès à l'information, notre correspondance privée (Voix sur IP, mail, tchat, ...), nos relations sociales, nos amours, nos démarches administratives, notre expression (non, je parle pas de faire kikolol sur Facebook mais d'avoir votre propre lieu d'expression, comme un blog)), on voit bien les risques que cela fait peser sur les libertés fondamentales de chaque citoyen.

Internet est aujourd'hui indissociable de la démocratie. Le censurer, l'altérer, le surveiller, le ralentir et le discriminer en tout ou partie est un marqueur clé d'une démocratie à la dérive.

La neutralité des réseaux ?

La neutralité des réseaux, souvent nommée, à tort, « neutralité du Net », est un des principes fondateurs d'Internet sans lequel ce dernier n'existerait pas. La neutralité des réseaux, c'est le fait de pouvoir envoyer et recevoir les contenus et applications de son choix sans aucune discrimination (ni sur le contenu, ni sur l'expéditeur ni sur le destinataire ni sur le protocole, ni sur quoi que ce soit).

Cela signifie que tout opérateur réseau doit fournir un accès à Internet sans censure de droit privé, sans surveiller ni altérer les communications et sans ralentir un service ou une application au détriment d'une autre (de même nature ou non).

Encore plus simplement, cela signifie qu'Internet doit être considéré, par tout un chacun, comme un réseau de transport : il achemine des informations, quelles qu'elles soient, d'un point A à un point B sans rien faire d'autre, sans faire de traitements supplémentaires que celui nécessaire au bon acheminement lui-même. En fait, cela fait d'Internet un réseau de transport passif au même titre que tous les autres réseaux que nous connaissons : Poste, téléphone, ...

Sources : diverses interventions de Benjamin Bayart ainsi que : la neutralité des réseaux en une image.

Les enjeux de la neutralité des réseaux

La neutralité des réseaux, ce n'est pas un truc de geek, c'est un principe qui a de lourdes implications :

  • La neutralité des réseaux garantit un accès universel à tout ce qui est disponible sur Internet (contenus, applications, services) là où son absence signifie que chaque opérateur réseau pourra faire payer un coût supplémentaire pour accéder à tels ou tels contenus, applications ou services. Exemples : pour accéder à Twitter, il faudra débourser 2€/mois de plus que le forfait de base. Pour accéder à Youtube, ça sera +10€/mois, ... Seules les organisations ayant le plus de moyens pourront bénéficier d'un accès à Internet complet, universel et rapide là où les citoyens pourront accéder uniquement à des morceaux présélectionnés d'Internet à une vitesse réduite.
  • La neutralité des réseaux permet également d'éviter des distorsions de la concurrence et des atteintes commerciales. Si un fournisseur de services doit payer un supplément à tous les opérateurs réseau de la planète (il y en a environ 47000 à l'heure actuelle) pour que son contenu soit accessible aux abonnés de cet opérateur réseau, à la vitesse nominale du réseau, alors il est évident que seuls les plus gros fournisseurs de services peuvent survivre. De même, favoriser et prioriser tel ou tel service au détriment des concurrents de ce service alors que tous sont techniquement équivalents et/ou proposent le même service à l'utilisateur, met là aussi en danger la diversité qui fait la force d'Internet.
  • La neutralité des réseaux est la garante de l'innovation et de la liberté d'entreprendre à l'heure du numérique. Si Internet avait été filtré, bridé, amputé de certaines parties dès sa création, l'apparition de services innovants qui sont aujourd'hui massivement utilisés (Wikipédia, Google, Facebook, ...) et d'applications innovantes (exemple : le Web, le mail, ...) aurait été impossible. Si Internet devient fermé, non neutre et non libre alors il n'y aura plus d'innovation. N'oublions pas que le numérique représente les emplois de demain, 3,7 % du PIB français et 1/4 de la croissance économique en 2012 (source : economie.gouv.fr). C'est d'ailleurs ce meurtre de l'innovation qui avait poussé de grands acteurs de l'Internet (Wikipédia, Google, Mozilla, ...) à manifester, en 2012, contre les lois américaines SOPA et PIPA (voir : http://sopastrike.com/) qui étaient, elles aussi des lois liberticides remettant en cause la neutralité des réseaux.
  • Enfin, la neutralité des réseaux garantit l'existence des libertés fondamentales comme la liberté d'accès à l'information et la liberté d'expression. Ni les opérateurs réseau ni les hébergeurs (de serveurs informatiques, de sites web, ...) ni un quelconque autre intermédiaire technique ne doit avoir le droit d'agir comme une police privée et de juger, censurer et/ou de limiter l'accès à un contenu, à un service ou à une application sans l'aval du pouvoir judiciaire. Plusieurs organismes ont reconnu la nécessité d'un Internet ouvert, neutre et libre pour le bon exercice des libertés fondamentales : voir la décision n°2009-580 DC du Conseil Constitutionnel datée du 10/06/09 ainsi que la Résolution A/HRC/20/L.13 du Conseil des droits de l'homme de l'ONU datée du 29/06/12.

TL;DR : la neutralité des réseaux est nécessaire aux libertés fondamentales (accès à l'information, expression, correspondance privée, ...), aux progès sociaux et sociétaux, ainsi qu'à l'économie à travers la liberté de commerce et de libre entreprise.

Pfff, que des conneries !

Vous pouvez penser qu'il n'y a jamais eu aucune atteinte à un Internet ouvert et libre, que c'est que dans la tête de certains geeks et que les opérateurs réseaux (comme les FAI) sont trop gentils toussa. Hé bah non, il y a des atteintes à un Internet ouvert et libre depuis que l'industrie des télécoms s'est dit que "ho tiens, ça a l'air d'avoir du succès, on va en vendre pour gagner plus de blé".

Ces atteintes se produisent partout dans le monde : en France, en Europe, aux USA, ... Pour vous faire une idée, le plus simple est de consulter le site Respect My Net, qui est mis en ligne par deux regroupements citoyens européens qui défendent les libertés fondamentales à l'heure du numérique.

Deux cas n'y sont pas listés :

  • L'altération : 3G SFR : Oui, SFR altère bien mon « expérience utilisateur »… et pire encore, il altère mes usages professionnels !. Certains vont répondre que c'est un cas limité, comme les pubs que les FAI intégraient sur les pages web en échange de la gratuité de l'accès au temps du 56k ... Fournir de fausses réponses aux requêtes DNS pour rediriger les noms de domaine inexistants (erreur de frappe, par exemple) vers le portail spécial pub du FAI, c'était pas grave non plus (pour les détails techniques, ce n'est pas de la vrai altération de données, on est bien d'accord) ... Demain, ça sera remplacer un mot par un autre dans une page web d'un journal mais ça ne sera toujours pas grave ... Bullshit.
  • Les distorsions de la concurrence : les cas Netflix, Apple TV et Free (avec Youtube d'une part et avec son « pass prioritaire » pour son replay d'autre part).

Et alors, il se passe quoi au Parlement européen ?

J'vous la fais court parce que c'est un vrai merdier pas sexy du tout ...

La Commission européenne a décidé de légiférer sur la neutralité des réseaux et a pondu une proposition de Règlement européen nommé « Marché Unique des Communications Électroniques » (non, il ne cause pas que de neutralité des réseaux) totalement anti-neutralité.

Un règlement européen, contrairement à une directive européenne, s'applique directement, tel quel, sans transposition dans tous les états membres. Tout le contenu est obligatoire, les états membres n'ont aucune liberté (alors qu'avec une directive, seul l'objectif et le délai sont fixés, les états membres fixent eux-mêmes la forme et les moyens à employer pour y parvenir). La neutralité des réseaux (ou son absence) d'un seul coup dans toute l'Union européenne, sans blabla au niveau national !

Plusieurs commissions du Parlement européen ont été consultées sur cette proposition de règlement. La commission industrie (ITRE) est la commission leader (saisie sur le fond) alors que la commission libertés (LIBE) est consultée uniquement pour avis : on sent tout de suite le sens du vent. La commission LIBE a pondu un bon rapport qui protège la neutralité des réseaux mais n'a malheureusement par été suivie par la commission industrie qui a rendu son rapport le 18 mars dernier.

La prochaine étape, c'est le 3 avril prochain (oui, les délais entre les échéances sont serrés et ce, depuis le début !) : en séance plénière, tous les membres du Parlement européen devront voter le rapport de la commission ITRE, ce qui inclus l'amender.

Et alors, qu'est ce qui ne va pas dans le rapport de la commission ITRE ? Il reste encore quelques lacunes, délibérées ou non, qui permettront aux opérateur réseaux de contourner ce règlement et donc de piétiner Internet, parmi lesquelles :

  • La neutralité des réseaux doit être définie dans un article, pas seulement dans un considérant.
  • Il faut un encadrement plus strict des services spécialisés car là, il suffit qu'un opérateur passe un accord avec n'importe quel fournisseur de service (GMail, Youtube, ...) pour avoir le droit de prioriser/mettre en avant un service ou une application plutôt qu'une autre.
  • Il faut mieux encadrer les cas de congestions pour éviter les fausses excuses de congestion de la part des opérateurs qui ne veulent pas investir dans l'infrastructure (exemple : Free / Youtube) ou les opérateurs qui prendront des mesures de gestion du trafic en prévision d'une congestion qui n'aura pas lieu, le tout, de manière permanente (alors qu'une opération de maintenance doit être ciblée, proportionnée et temporaire).

Une liste plus précise et complète se trouve dans ces deux ressources : Neutralité du Net : de dangereuses failles subsistent après le vote de la commission « industrie » du Parlement européen et neutralité des réseaux : les amendements à adopter.

ÉDIT du 28/03/2014 à 17h00 :
Les groupements politiques S&D, Verts et GUE ont déposé des amendements pro neutralité des réseaux pour la plénière de jeudi prochain. Ils suivent de près les recommandations de la Quadrature donc c'est du tout bon.

Il faut maintenant exiger le soutien inconditionnel de ces amendements par les autres formations politiques (notamment PPE et ECR). Continuons de contacter nos députés européens !

À mon humble avis, il manque encore quelques corrections de points problématiques :

  • L'amendement 6 empêche la discrimination entre des services et applications spécialisés/gérés et les services et applications non-priorisés si le service ou l'application est équivalent en terme de service rendu à l'utilisateur (« functionally equivalent services or applications »). Or, on peut décrire un service ou une application en utilisant des termes techniques ou en terme de services qu'il rend à l'utilisateur. Selon le point de vue que l'on adopte, on peut trouver des équivalents ou non ... et donc prioriser ou non. C'est évidemment là-dessus que les opérateurs réseaux vont jouer. Proposition de patch : « technically or functionally equivalent services or applications ».
  • Il faudrait supprimer l'article 23.5.b car il permettra aux opérateurs de rendre légitimes certaines mesures de gestion du trafic qui ne le sont pas sous prétexte de la sécurité de leur réseau ou de celle du terminal de leur client. Une atteinte évidente qui me vient à l'esprit : les FAI bloquent le port tcp/25 en sortie, parfois sans possiblité de l'ouvrir (pas d'options dans la box), ce qui empêche d'installer son serveur mail chez soi. Pour quel motif font-ils ça ? Car, il paraît (c'est pas aussi évident que ça en pratique, même sur un réseau associatif pour étudiants) que les Windows gavés de virus envoient du spam. Précisément ce que l'on peut qualifier de « sécurité de leur réseau et du terminal de l'utilisateur » ! C'est une atteinte évidente et parfaitement inacceptable à la neutralité des réseaux qu'il convient d'encadrer. Oui, une option pour désactiver un blocage du port 25 est tolérable mais aller expliquer ça aux députés européens me semble bien compliqué. Et ça ne protégera pas des autres dérives que les opérateurs classeront dans « sécurité de leur réseau et du terminal de l'utilisateur ».
  • Il est nécessaire de mieux encadrer les cas de congestions pour éviter les fausses excuses de congestion de la part des opérateurs qui ne veulent pas investir dans l'infrastructure (exemple : Free / Youtube) ou les opérateurs qui prendront des mesures de gestion du trafic en prévision d'une congestion qui n'aura pas lieu, le tout, de manière permanente (alors qu'une opération de maintenance doit être ciblée, proportionnée et temporaire). C'est l'article 23.5.d qu'il faut encore élargir.

Fin de l'édit

Il y a une forte mobilisation des lobbies des industriels des télécoms qui vont expliquer aux députés européens que la neutralité des réseaux est une utopie, qu'elle est intenable financièrement, qu'elle nuit aux investissements dans les réseaux, que les services spécialisés/gérés sont indispensables, etc., Je trouve cette position assez curieuse : la neutralité des réseaux est l'un des principes fondateurs d'Internet, qui a été viable jusqu'à ce jour, qui est viable pour les FAI associatifs et sans lequel il n'y a plus d'Internet et donc plus d'accès à Internet à vendre. Sans neutralité des réseaux, les géants des télécoms n'auront plus rien à vendre !

Pfff, pourquoi agir ?

Bon, à cette étape, on reçoit plein de réponses très typées :

  • « Trop la fleeeeemme » : je ne peux plus rien pour vous mais n'oubliez pas : Ne rien voir, ne rien entendre, ne rien dire !
  • « Je n'ai pas compris en quoi défendre la neutralité des réseaux c'est super important » : je n'ai peut-être pas été suffisamment clair ci-dessus. Je vous invite à consulter les ressources suivantes : neutralité des réseaux - les bases, neutralité des réseaux - plus détaillé ou mieux, une conférence de Benjamin Bayart : neutralité des réseaux - définitions et enjeux.
  • « Pfff, ça sert à rien, on va perdre » : c'est sûr qu'avec une mentalité pareil ... Souvenez-vous d'HADOPI I tranchée par le Conseil Constitutionnel qui nous a même pondu un magnifique considérant affirmant qu'Internet est nécessaire à l'exercice des libertés de nos jours ! Souvenez-vous d'ACTA, rejetée au Parlement européen (alors qu'il y avait beaucoup plus de lobbies/forces en présence : producteurs de CD/DVD/Blu-ray, industrie pharmaceutique, industrie des semences). Même à un niveau plus modeste, sur l'Instruction en famille (certes, pas les mêmes forces/lobbies de l'autre côté, on est d'accord), de grandes batailles ont déjà été gagnées. La seule chose qui a fait la différence, c'est notre mobilisation collective.
  • « Haha ! Ça ne sert à rien, avec la technique, on pourra toujours tout contourner ! » : d'une part, je n'ai pas la certitude qu'il n'y ai pas une limite aux contournements que l'on pourra trouver. Je préfère prévenir que guérir. D'autre part, on laissera 99% des personnes sur le carreau, peut-être même vous ! Il faut être d'une prétention incroyable pour penser que vous serez toujours capable de tout contourner. Ha, au fait, ça sera génial de se retrouver entre élites sur des simulacres d'Internet sans aucun intérêt, je n'en doute pas. 😉 Enfin, car ça signifie vivre en résistance permanente, être au taquet, tous les jours pour trouver/savoir quelle la nouvelle technique de contournement qui fonctionne. Mais si vous avez que ça à faire, pourquoi pas. Je pari que vous en aurez marre assez vite. 🙂
  • « Boarf, tu dis des conneries, les opérateurs réseaux feront toujours que des atteintes minimales, ça changera pas le cours de nos vies » : haha, on pari ? Vous êtes bien sûr de vous ? 🙂

Comment agir ?

  • En se tenant informer. Par exemple, chez la Quadrature du Net.
  • En diffusant l'information.
  • En contactant les députés européens. Pour se faire entendre, l'ordre en terme de médium à utiliser est celui-là : téléphone > fax > mail. La plateforme Sauvons Internet, maintenue par la Quadrature du Net et 6 autres organisations qui luttent en faveur des libertés fondamentales, permet de téléphoner et d'envoyer des fax gratuitement aux députés européens. Écrire un petit mail ou un fax personnalisé et l'envoyer à quelques députés voire passer quelques appels téléphoniques ne vous prendra pas beaucoup de temps entre deux parties de 2048, soyons honnêtes ! Personne ne vous demande d'être un expert des télécoms, d'Internet ou que sais-je (je ne le suis pas non plus hein), juste d'être un citoyen inquiet pour les libertés fondamentales à l'heure numérique. Et la plateforme est assez intuitive et juste fonctionne. Si mail/fax : évitez le spam bête et méchant ... C'est évident mais ça va mieux en le disant.
  • Financer un lobby citoyen (par exemple : La Quadrature du Net) ... Puisque les députés n'écoutent que les lobbies et puisque les opérateurs réseaux (ou les producteurs de CD/DVD/Blu-ray, ...) sont capables de se liguer en de puissants lobbies bah ... formons un lobby citoyen pour nous faire entendre. Vous n'aimeriez pas faire bénévolement l'immense travail quotidien que fait la Quadrature alors que les lobbies n'ont que ça à faire de leurs journées.

Aucune de ces actions, effectuée individuellement ne peut suffire, il faut les combiner.

Il nous reste une semaine pour nous bouger !

Mon humble avis

À mon humble avis, on va perdre sur ce dossier qu'est le neutralité des réseaux au niveau européen cette fois-ci. En tous cas, c'est mon sentiment.

À mon avis, cela s'explique :

  • Par un texte perçu comme étant technique alors que la neutralité des réseaux c'est avant tout une histoire de libertés fondamentales à l'heure numérique !
  • Un domaine trop précis. ACTA était transversal, regroupait un grand nombre de secteurs (Internet, contrefaçon, médicaments, semences, ...). Cela donnait une base plus grande de personnes se sentant concernées.
  • Pas la même épaisseur médiatique. Même sur les PCInpact, Numérama et autres, l'information est traitée mais on passe vite à autre chose. Je me souviens qu'ACTA avait eu une plus grande épaisseur médiatique ... Pareil pour les blogs bien connus ... Dans les deux cas, on relaye à peine voire pas du tout la procédure pour inviter les lecteurs à se bouger. Dommage.
  • Un manque de mobilisation. C'est flagrant, quasiment personne bouge ...

Mais vous n'avez aucune raison de croire à mon délire pessimiste ! Bougez-vous et nous obtiendrons une protection forte de la neutralité des réseaux dans toute l'Union européenne !

Ressources

Quelques ressources supplémentaires qui peuvent aider à la compréhension (attention aux dates sinon ça va vous faire bizarre 😛 ) :

Voilà, j'espère vous avoir motivé et que vous allez vous réveiller. Plus qu'une semaine pour agir !