Security Considerations (Considérations de sécurité)
Security Considerations (Considérations de sécurité)
Une implémentation BGP DOIT (MUST) prendre en charge le mécanisme d'authentification spécifié dans RFC 2385 [RFC2385]. L'authentification fournie par ce mécanisme peut être effectuée par pair.
BGP utilise TCP pour le transport fiable de son trafic entre les routeurs pairs. Pour fournir une intégrité orientée connexion et une authentification de l'origine des données sur une base point à point, BGP spécifie l'utilisation du mécanisme défini dans RFC 2385. Ces services sont destinés à détecter et rejeter les attaques d'écoute active contre les connexions TCP inter-routeurs. En l'absence de l'utilisation de mécanismes qui effectuent ces services de sécurité, les attaquants peuvent perturber ces connexions TCP et/ou se faire passer pour un routeur pair légitime. Étant donné que le mécanisme défini dans le RFC ne fournit pas d'authentification d'entité pair, ces connexions peuvent être soumises à certaines formes d'attaques de rejeu qui ne seront pas détectées à la couche TCP. De telles attaques pourraient entraîner la livraison (depuis TCP) de messages BGP « cassés » ou « usurpés ».
Le mécanisme défini dans RFC 2385 augmente la somme de contrôle TCP normale avec un code d'authentification de message (MAC) de 16 octets qui est calculé sur les mêmes données que la somme de contrôle TCP. Ce MAC est basé sur une fonction de hachage unidirectionnelle (MD5) et l'utilisation d'une clé secrète. La clé est partagée entre les routeurs pairs et est utilisée pour générer des valeurs MAC qui ne sont pas facilement calculables par un attaquant qui n'a pas accès à la clé. Une implémentation conforme doit prendre en charge ce mécanisme et doit permettre à un administrateur réseau de l'activer par pair.
RFC 2385 ne spécifie pas de moyen de gestion (par exemple, génération, distribution et remplacement) des clés utilisées pour calculer le MAC. RFC 3562 [RFC3562] (un document informatif) fournit des conseils dans ce domaine et fournit une justification pour soutenir ces conseils. Il note qu'une clé distincte devrait être utilisée pour la communication avec chaque pair protégé. Si la même clé est utilisée pour plusieurs pairs, les services de sécurité offerts peuvent être dégradés, par exemple, en raison d'un risque accru de compromission sur un routeur qui affecte négativement d'autres routeurs.
Les clés utilisées pour le calcul MAC devraient être changées périodiquement, pour minimiser l'impact d'une compromission de clé ou d'une attaque cryptanalytique réussie. RFC 3562 suggère une période crypto (l'intervalle pendant lequel une clé est utilisée) d'au maximum 90 jours. Des changements de clé plus fréquents réduisent la probabilité que des attaques de rejeu (comme décrit ci-dessus) soient réalisables. Cependant, en l'absence d'un mécanisme standard pour effectuer de tels changements de manière coordonnée entre pairs, on ne peut pas supposer que les implémentations BGP-4 conformes à ce RFC prendront en charge des changements de clé fréquents.
Évidemment, chaque clé devrait également être choisie pour être difficile à deviner pour un attaquant. Les techniques spécifiées dans RFC 1750 pour la génération de nombres aléatoires fournissent un guide pour la génération de valeurs qui pourraient être utilisées comme clés. RFC 2385 demande aux implémentations de prendre en charge les clés « composées d'une chaîne d'ASCII imprimable de 80 octets ou moins ». RFC 3562 suggère que les clés utilisées dans ce contexte soient de 12 à 24 octets de bits aléatoires (pseudo-aléatoires). Ceci est assez cohérent avec les suggestions pour des algorithmes MAC analogues, qui utilisent généralement des clés dans la plage de 16 à 20 octets. Pour fournir suffisamment de bits aléatoires à l'extrémité inférieure de cette plage, RFC 3562 observe également qu'une chaîne de texte ASCII typique devrait être proche de la limite supérieure pour la longueur de clé spécifiée dans RFC 2385.
L'analyse des vulnérabilités BGP est discutée dans [RFC4272].