Protection anti-abus du relais aveugle

La protection anti-abus du relais aveugle (Blind Relay Abuse Guard) est l'ensemble des limites qu'un nœud AeroNyx applique avant de transmettre du trafic de relais chiffré pour le compte d'un autre nœud. Elle contient les pairs abusifs ou instables en s'appuyant uniquement sur des métadonnées de routage signées et sur des compteurs locaux. Elle n'analyse jamais le texte chiffré, ne conserve jamais d'historique de routes et n'expose jamais qui communique avec qui.

Périmètre

La règle du nœud aveugle

Un relais peut authentifier les métadonnées de routage, appliquer une politique bornée, transmettre une enveloppe opaque et renvoyer un accusé de réception signé. Il ne doit jamais inspecter la charge utile ni exposer des métadonnées qui permettraient de reconstituer une route, l'identité d'un utilisateur ou une relation. En particulier, les relais n'enregistrent ni n'exposent :

• le texte en clair des messages, paquets, médias ou souvenirs
• les requêtes DNS, destinations, domaines, URL ou l'historique de navigation
• les identifiants de routes, les chemins complets, les URL de points de terminaison ou les adresses IP des clients
• les clés publiques complètes, les identités des destinataires, les identifiants de messages ou les liens du graphe social
• les clés privées, les secrets des bons, le trafic au niveau du portefeuille ou le matériel de déchiffrement

Pipeline d'admission

Chaque requête passe les contrôles suivants avant de pouvoir utiliser la capacité de transmission. Les étapes 1 à 6 s'exécutent dans cet ordre. À l'étape 7, une requête adressée à ce nœud est confiée à son propre traitement terminal ou en oignon, tandis qu'une requête destinée à un autre nœud est réservée une fois son saut suivant résolu.

1. request gate: process-wide admission window and in-flight limit (64 requests)
2. crypto admission: a free slot for signature and onion work, or Backpressure
3. authenticate the signed previous hop and envelope
4. previous-hop rate limit and quarantine check
5. envelope metadata: size, age and future-skew limits
6. self-loop check
7. route loop, TTL and next-hop descriptor checks, plus the route replay reservation
8. forward the opaque ciphertext, or peel the terminal layer and deliver

Chaque décision s'appuie sur des métadonnées de routage signées et sur un état agrégé local, jamais sur du contenu déchiffré.

Limites d'exécution

Voici les valeurs par défaut actuelles dans le code source du nœud. Ce sont des valeurs de fonctionnement, et non des engagements permanents du protocole.

Limitation de débit et mise en quarantaine du saut précédent

Les limites de débit sont indexées sur l'identité signée du saut précédent. Plus de 120 requêtes provenant d'un même saut précédent en 60 secondes déclenchent une quarantaine locale de cinq minutes pour ce saut. Un score d'échecs distinct déclenche la même quarantaine après 12 échecs comptabilisés en cinq minutes. Seuls les motifs suivants comptent dans le score :

invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted

Les délais d'attente de transport dépassés, les accusés de réception perdus, les nouvelles tentatives en double et les conflits de rejeu n'augmentent pas le score : un pair sain n'est donc pas mis en quarantaine à cause de problèmes réseau. Le magasin de compartiments est borné et les compartiments inactifs sont évincés, de sorte que la protection ne peut pas se transformer en graphe de communication à long terme.

Rejeu de routes et nouvelles tentatives

Chaque requête de relais porte un identifiant de route. Lorsque le magasin de relais de messagerie du nœud est activé ([memchain.chat_relay] enabled = true), les réservations de routes et les réponses terminées sont conservées dans sa base de données SQLite, de sorte que la protection anti-rejeu résiste à un redémarrage. Sinon, le nœud utilise un registre en mémoire de même capacité et de même fenêtre. Si les 8192 emplacements contiennent tous des routes actives, les nouvelles routes sont rejetées avec replay_capacity jusqu'à l'expiration d'emplacements.

Un identifiant de route répété aboutit à l'un des quatre résultats suivants :

Le dernier résultat s'applique au magasin durable. Les accusés de réception signés ne sont valables qu'en tant que preuve récente : le nœud n'en rejoue donc pas un au-delà de 120 secondes.

Lorsque la transmission vers le saut suivant échoue en raison d'un délai d'attente dépassé, d'une erreur de connexion ou d'une erreur de requête, le nœud réessaie, jusqu'à trois tentatives au total. Le court délai précédant chaque nouvelle tentative est dérivé de l'identifiant de route, du saut suivant et du numéro de tentative. Les échecs que le nœud en aval signale comme des rejets définitifs ne font pas l'objet de nouvelles tentatives.

Admission cryptographique (note de capacité pour les opérateurs)

Les vérifications de signatures, le retrait des couches d'oignon et la signature des accusés de réception sont limités par le CPU ; chaque processus de nœud les limite donc :

• Emplacements au total : la moitié des threads CPU signalés par l'hôte, arrondie au supérieur, avec au moins 4 et au plus 8, de sorte qu'un hôte à un ou deux threads dispose quand même de 4 emplacements.
• Requêtes entrantes : un emplacement de moins que le total, afin que la création de routes sortantes et la finalisation des accusés de réception puissent toujours progresser. Sur les plus petits hôtes, les requêtes entrantes disposent donc de 3 emplacements.
• Lorsque tous les emplacements sont occupés : la requête est immédiatement rejetée avec HTTP 429 et le motif backpressure. Elle n'attend pas dans une file.

Sur un petit hôte, un relais délaisse donc la charge tôt en cas de pics. Un compteur backpressure_dropped en hausse signifie que le nœud a besoin de plus de CPU ou de moins de trafic de relais.

Compteurs d'exécution agrégés

Les nœuds signalent dans leur heartbeat des compteurs cumulés approximatifs et des horodatages de fraîcheur, sous :

system_stats.discovery_status.peer_store.runtime.blind_relay
system_stats.discovery_status.peer_store.blind_relay_quality
system_stats.discovery_status.peer_store.peer_health_summary

Ces compteurs décrivent le fonctionnement du nœud. Ce ne sont ni des journaux de messages ni des données de facturation, et ils ne prouvent pas qu'une conversation donnée a eu lieu.

Qualité des preuves

Le résumé de qualité distingue quatre types de preuves : le travail de relais opaque accepté, les sondes synthétiques d'accessibilité, les sondes synthétiques à deux sauts et les accusés de réception signés par le nœud terminal pour les remises initiées par des clients. real_relay_ready exige un accusé de réception de remise client récent et authentifié. Les preuves synthétiques ne sont jamais présentées comme du trafic utilisateur.

proof_scope indique la preuve la plus forte observée : client_message_delivery, relay_acceptance, message_delivery, control_plane, single_hop_control_plane, attempted ou none.

Santé des pairs sans relations de trafic

peer_health_summary permet aux opérateurs de repérer un pair défaillant ou en quarantaine sans voir qui communique avec qui.

Inclus : un préfixe raccourci de l'identifiant du nœud, l'état approximatif de santé et du descripteur, la fraîcheur de la diffusion et des succès de routes, le nombre agrégé de succès et d'échecs de routes, l'état de quarantaine, le temps restant et des catégories approximatives de motifs.

Jamais inclus : les clés publiques complètes des nœuds, les identifiants de routes, les listes de points de terminaison, les blocs chiffrés ou les hachages de charges utiles, les identifiants de messages, les identités des destinataires, les adresses IP des clients, les destinations, les données DNS ni les liens du graphe social.

Plan du code source

Le logiciel de nœud est open source sous licence AGPL-3.0 sur github.com/AeroNyxNetwork/AeroNyx. Consultez Découverte des nœuds et relais chiffré multisaut pour savoir comment les routes sont construites.

Questions fréquentes

Un nœud relais peut-il lire ou journaliser le trafic qu'il transmet ?

Non. Un relais vérifie les métadonnées de routage signées et transmet une enveloppe opaque. Il ne conserve que des compteurs agrégés, jamais de charges utiles, d'historiques de routes ni d'identités de destinataires.

Que se passe-t-il lorsqu'un nœud réessaie la même route ?

Si la première tentative est terminée, le nœud rejoue sa réponse stockée et ne remet rien une seconde fois. Si la première tentative est toujours en cours, le nœud renvoie route_in_flight, qui peut être réessayé. Une requête différente sous le même identifiant de route est rejetée avec replay_conflict.

La protection anti-rejeu résiste-t-elle à un redémarrage du nœud ?

Oui, lorsque le magasin de relais de messagerie du nœud est activé. Les réservations de routes et les réponses terminées sont alors conservées dans SQLite. Sans ce magasin, le nœud utilise un registre en mémoire qui est effacé au redémarrage.

Pourquoi un pair est-il mis en quarantaine ?

Un pair est mis en quarantaine pendant cinq minutes après avoir envoyé plus de 120 requêtes en 60 secondes, ou après 12 échecs de validation comptabilisés en cinq minutes. Les délais d'attente dépassés, les accusés de réception perdus et les nouvelles tentatives en double ne comptent pas comme des échecs.

Pourquoi mon nœud renvoie-t-il backpressure sous charge ?

Tous ses emplacements cryptographiques de relais étaient occupés. Un nœud alloue environ la moitié de ses threads CPU (au moins 4 et au plus 8) aux opérations de signature et d'oignon, et rejette immédiatement les requêtes excédentaires au lieu de les mettre en file d'attente.