13. Security Considerations (Considérations de sécurité)
13. Security Considerations (Considérations de sécurité)
Comme ce document décrit un protocole de sécurité, de nombreux aspects d'intérêt pour la sécurité sont décrits dans les sections pertinentes. Cette section souligne les problèmes qui peuvent ne pas être évidents dans d'autres sections.
Cache Validation (Validation du cache): Pour qu'une collection de caches telle que décrite dans la section 11 garantisse une vue cohérente, ils doivent recevoir des ancres de confiance cohérentes à utiliser dans leur processus de validation interne. La distribution d'une ancre de confiance cohérente est supposée être hors bande.
Cache Peer Identification (Identification des pairs de cache): Le routeur initie une connexion de transport vers un cache, qu'il identifie par adresse IP ou nom de domaine complet. Soyez conscient qu'une attaque par usurpation DNS ou d'adresse pourrait rendre le cache correct inaccessible. Aucune session ne serait établie, car les clés d'autorisation ne correspondraient pas.
Transport Security (Sécurité du transport): La RPKI repose sur la confiance des objets, et non sur la confiance du serveur ou du transport. C'est-à-dire que l'ancre de confiance racine IANA est distribuée à tous les caches par des moyens hors bande et peut ensuite être utilisée par chaque cache pour valider les certificats et les ROA jusqu'en bas de l'arbre. Les relations inter-caches sont basées sur ce modèle de sécurité d'objet; par conséquent, le transport inter-cache peut être légèrement protégé.
Cependant, ce document de protocole suppose que les routeurs ne peuvent pas effectuer la cryptographie de validation. Par conséquent, le dernier lien, du cache au routeur, est sécurisé par l'authentification du serveur et la sécurité au niveau transport. Ceci est dangereux, car l'authentification du serveur et le transport ont des modèles de menace très différents de la sécurité des objets.
Ainsi, la force de la relation de confiance et du transport entre le(s) routeur(s) et le(s) cache(s) est critique. Vous pariez votre routage là-dessus.
Bien que nous ne puissions pas dire que le cache doit être sur le même LAN, ne serait-ce qu'en raison du problème d'une entreprise voulant décharger la tâche de cache vers son (ses) FAI en amont, la localité, la confiance et le contrôle sont des problèmes très critiques ici. Le(s) cache(s) DEVRAI(EN)T vraiment être aussi proche(s) que possible, dans le sens d'un transport contrôlé et protégé (contre DDoS, MITM), du (des) routeur(s). Il DEVRAIT également être topologiquement proche afin qu'un minimum de données de routage validées soit nécessaire pour amorcer l'accès d'un routeur à un cache.
L'identité du serveur de cache DEVRAIT être vérifiée et authentifiée par le client routeur, et vice versa, avant que des données ne soient échangées.
Les transports qui ne peuvent pas fournir l'authentification et l'intégrité nécessaires (voir section 9) doivent s'appuyer sur la conception du réseau et les contrôles opérationnels pour fournir une protection contre les attaques d'usurpation/corruption. Comme souligné dans la section 9, TCP-AO est le plan à long terme. Les protocoles qui fournissent l'intégrité et l'authenticité DEVRAIENT être utilisés, et s'ils ne peuvent pas l'être, c'est-à-dire si TCP est utilisé comme transport, le routeur et le cache DOIVENT être sur le même réseau contrôlé de confiance.