12. Security Considerations (Considérations de sécurité)
12. Security Considerations (Considérations de sécurité)
Tant que les Flow Specifications sont limitées à correspondre aux chemins de routage unicast appropriés pour les préfixes concernés (Section 6), les propriétés de sécurité de cette proposition sont équivalentes aux propriétés de sécurité existantes du routage unicast BGP. Tout assouplissement du processus de validation décrit en Section 6 peut permettre la propagation de Flow Specifications indésirables et potentiellement l'application de Traffic Filtering Actions indésirables sur les flux.
Si les mécanismes ci-dessus ne sont pas en place, cela peut ouvrir la porte à d'autres attaques par déni de service, telles qu'un filtrage de trafic indésirable, un re-marquage ou une redirection.
Le déploiement à l'intérieur des frontières administratives d'un réseau d'assouplissements spécifiques de la validation peut être utile pour certains réseaux afin de distribuer rapidement des filtres pour contrer les attaques par déni de service. Pour qu'un réseau exploite un tel assouplissement, la politique BGP DOIT prendre en charge un filtrage supplémentaire, car le champ source AS est vide. Les spécifications qui assouplissent les contraintes de validation DOIVENT inclure des considérations de sécurité détaillant le filtrage supplémentaire requis. Par exemple, la validation d'origine peut fournir un filtrage renforcé au sein d'une confédération d'AS.
Le routage inter-domaine repose sur un réseau de confiance. Les systèmes autonomes adjacents sont supposés annoncer des informations de joignabilité valides. Si ce modèle de confiance est violé, un système autonome adjacent peut provoquer une attaque par déni de service en annonçant des informations de joignabilité pour un préfixe donné pour lequel il ne fournit pas de service (détournement d'espace d'adressage non filtré). Étant donné que la validation des Flow Specifications est liée à l'annonce du meilleur routage unicast, un échec dans la validation du meilleur chemin peut empêcher le routeur local d'utiliser la Flow Specification. Des mesures d'atténuation possibles sont [RFC6811] et [RFC8205].
Sur les Internet Exchange Points (IXP), le routage est souvent échangé via des route servers qui n'étendent pas AS_PATH. Dans ce cas, il n'est pas possible d'imposer que l'AS le plus à gauche dans AS_PATH soit l'AS voisin (l'AS du route server). Comme la validation des Flow Specifications (Section 6) s'appuie sur cela, une extrême prudence s'impose. Il est recommandé d'utiliser une politique de routage entrante stricte dans de tels scénarios.
L'activation de fonctionnalités de type pare-feu dans les routeurs sans administration centralisée peut rendre certains défauts plus difficiles à diagnostiquer. Par exemple, des paquets TCP peuvent être autorisés entre une paire d'adresses, mais pas des paquets ICMP. Des paquets de taille inférieure à 900 ou supérieure à 1000 octets peuvent être autorisés entre une paire d'adresses, mais pas ceux dont la longueur est comprise entre 900 et 1000. Un tel comportement peut prêter à confusion; que ce soit par configuration manuelle ou coordonnée via les extensions de protocole décrites dans ce document, ces fonctionnalités DEVRAIENT être utilisées avec prudence.
Un locuteur BGP Flow Specification (par exemple, un contrôleur DDoS automatisé), s'il est mal programmé, si l'algorithme ne se comporte pas comme prévu, ou s'il s'agit simplement d'un système malveillant, peut annoncer des Flow Specifications inattendues, envoyer des mises à jour à haut débit ou générer un grand nombre de Flow Specifications. Cela peut stresser les systèmes récepteurs au-delà de leur capacité ou entraîner l'application de Traffic Filtering Actions indésirables sur les flux.
Un système peut être incapable de localiser toutes les valeurs d'en-tête nécessaires pour identifier un paquet. Cela pose particulièrement problème pour les paquets fragmentés qui ne sont pas le premier fragment, faute d'en-tête de protocole de couche supérieure ou de chiffrement ESP (Encapsulating Security Payload) NULL [RFC4303].
Bien que la validation générale du NLRI Flow Specification soit spécifiée dans ce document (Section 6), la réception de Traffic Filtering Actions de tiers peut nécessiter une validation ou un filtrage personnalisés. En particulier, toutes les actions autres que le débit de trafic peuvent permettre à un tiers de modifier les attributs de transfert de paquets et potentiellement d'accéder à d'autres tables de routage/VPN ou à des files d'attente non souhaitées. Cela peut être évité en filtrant correctement les communautés Traffic Filtering Action aux frontières du réseau et en n'exposant aux tiers qu'un sous-ensemble prédéfini de Traffic Filtering Actions (voir Section 7). Une façon d'y parvenir est de mapper des communautés définies par l'utilisateur, configurables par des tiers, vers des Traffic Filtering Actions, et de ne pas accepter les Extended Communities Traffic Filtering Action provenant de tiers.
Cette extension ajoute des informations supplémentaires aux routeurs Internet. Ceux-ci sont limités par le nombre maximal d'éléments de données qu'ils peuvent héberger et par le nombre d'événements qu'ils peuvent traiter par unité de temps. Les fournisseurs de services DOIVENT tenir compte de la capacité maximale de leurs équipements et peuvent devoir limiter le nombre de Flow Specifications acceptées et traitées.